However, when I open localhost:8888, I do not get the option to Build > iOS like above. Is there some flag or similar that I need to set in order to get this option so that I can test the iOS port?
That server is offered for people who want to build their apps for iOS. It's based on the ucr branch on GitHub with yet-to-be released changes that enable the buildserver to produce IPA files.
For testing your custom map URL changes, you should be able to test them by building your own copy of the companion. To do so, create the AICompanionApp.xcconfig file as detailed in the README. Then you should be able to open AppInventor.xcworkspace in Xcode and build the AICompanionApp scheme.
I am guessing ucr is something like upcoming-release? Does it have a flag to enable iOS Ad Hoc (.ipa) building - it does not look like it. Or maybe you're saying that the https://iosbuildservertest.appinventor.mit.edu/ build is only based on (but not exactly) ucr - would it be possible to see the branch for this, to see the changes I would need to make to get my appengine to offer iOS Ad Hoc building?
I followed your instructions to build the AICompanionApp in XCode. I Product > Archived the app as an .ipa file. I was not able to upload it to TestFlight as the bundle ID (edu.mit.appinventor.aicompanion3) was already taken (by MIT) - see my comment at Update README.ios.md by petersmythe · Pull Request #3186 · mit-cml/appinventor-sources · GitHub about maybe providing instructions to change this to your suggestion of a developer controlled namespace.
I proceeded to sideload it to the test phone using https://altstore.io/, which eventually worked. The version that it shows is 2.64.5 (build 1) (from aicompanionapp/src/Info.plist, I believe). However, when connecting to appengine via QR code, it kinda works (i.e. sometimes connects via rendezvous) but if it does connect, the iOS AICompanionApp screen remains blank (not even showing the title Screen 1). Most of the time it scans the QR code, placing the 6-character code in the white textbox, but does nothing further.
Switching to your beta AICompanionApp (2.64.6 (build 8)) does more - I can see a Map component, but there is an expected error (irritant = customUrl, or similar) because your beta does not support my customUrl changes.
I select Use Legacy Connection for both app versions.
This is where I am now stuck.
How can I debug what is going wrong? Should I build against a different branch other than master?
The rendezvous server is fine. My guess is what is happening is that WebRTC is finding a route that appears viable using one of the virtual network addresses between the localhost instance running App Inventor on the host machine and the companion app within the virtual machine. This leads WebRTC to attempt to establish an invalid connection. I'd be curious if you run the test server on another machine whether you experience the same issue (where the route of last resort goes through MIT's servers, but possible through your home router depending on how your VM is configured).
Edit: Alternatively, you could run the dev server inside of the VM as well to eliminate that as a potential issue.
The test above was on my Windows host laptop and a physical iPhone on the same network.
I have not tried to run the server on the MacOS virtual machine and an emulator in that VM as there is not enough RAM, but I could experiment more with that (appengine on the VM, physical iPhone)
I'll get back to you.
Could you provide more info about point 1, please?
If I use the official Android AICompanionApp (v2.70), I understandably get an error for my customUrl code which has not been released yet, but other standard components work, with all 3 appengines above.
Ditto for the iPhone beta app (v2.64.6-b8)
For my Xcode built AICompanionApp (reporting v2.64.5-b1):
https://ai2.appinventor.mit.edu
After scanning the QR code (non-legacy mode), the 6 character code is inserted into the white textbox and then the screen disappears, being replaced by a pure white, almost empty window (with an open book icon top right, same as on the initial screen). The browser/appengine stops polling rendezvous but makes 4-5 other rendezvous2 calls. Browser console output includes iceCandidate, webrtc messages, add-component/set-and-coerce-property etc. There is also a ice disconnect later & webrtc data closed.
My Windows & My MacOS VM appengine
After scanning the QR code (legacy mode), the 6 character code is inserted into the white textbox and then the screen disappears, being replaced by a pure white, almost empty window (with an open book icon top right, same as on the initial screen). The browser/appengine stops polling rendezvous but does NOT makes 4-5 other rendezvous2 calls, just one _values call. Popup Needed: Please click Continue button below, Special Window opens, move to corner, as usual. Browser console output includes iceCandidate, webrtc messages, add-component/set-and-coerce-property etc. There is also a ice disconnect later & webrtc data closed. I assume the struck-through output above relates to non-legacy mode.
I do see failure to connect to localhost:8004/reset - what is that about?
Also included is set-and-coerce-property MapType 4 (customUrl) which might cause a problem, but normally the app just warns with a toast message: The MapType must be 1 2 or 3 and continues
Should I try building the AICompanionApp in Windows for Android? I haven't done that yet.
Should I rebuild in Xcode using a different branch?
The WebRTC data closed event indicates a potential problem since that is the channel used in non-legacy mode to send code over to the companion. Do you see any errors in the log prior to that event that suggest an error occurring? The data channel closing amounts to the connection dying, which would explain why you don't observe any further changes to the companion app (white screen).
Hmm. This could be the potential cause. You'll want to adjust the logic on or about line Map.swift:350 to enable support for MapType 4.
We don't require any additional capabilities beyond the defaults.
The build process for individual apps is different from building the companion in Xcode. The latter is fully supported and is how we deploy the companion to the App Store, as well as for testing internal changes.
As a test, try loading a project such as HelloPurr on the public server and connecting your custom-built iOS companion. Does that succeed?
No cat image is shown, no sound is made if the image is tapped.
I suspect that it might be the Provisioning Profile capabilities. I do not know what "defaults" you are talking about. From what I can see, nothing is ticked. I will try now with everything ticked, but it means building again, or maybe only Archiving the .ipa again?
Is this using ai2.appinventor.mit.edu or localhost? If you're using localhost, then that app won't work because assets are loaded from the server and localhost always refers to the device's loopback.
Interesting. It might be worth just trying the "Reset Connection" option and then reconnecting. I recall there was a bug once where assets would not transfer over correctly sometimes. I thought we had fixed it but maybe this is another manifestation. Using the reset connection menu item should restore the correct internal state.
I am struggling to create an Apple app ID in Sign In - Apple, because I do not know what defaults or bare minimum is required.
My observation is that if the Bundle ID is a wildcard, then no Capabilities or App Services can be selected at all.
If it is Explicit, then I can select one or more of them, but having done so, at the next step I get the error The selected team does not have a program membership that is eligible for this feature so clearly I am selecting too many. I have been through it again and only selected the Capabilities applicable to iOS, but that also gives the same error.
Also, I get the error: 'edu.mit.appinventor.aicompanion3' is not available. so I will be trying to change this to a namespace I control and rebuild.
I selected 2 capabilities, and I was able to register a new App ID. Testing ...
