Build > iOS Ad Hoc (.ipa)

I understand that the iOS building is possibly still in Beta? There is a test server - who is this for? What exactly is the status, please?


I am working on extending the Map component: Add custom url for map component by petersmythe · Pull Request #3160 · mit-cml/appinventor-sources · GitHub, now moving on to the iOS port. I have created a MacOS VM to build on, and that is now successful Update by petersmythe · Pull Request #3186 · mit-cml/appinventor-sources · GitHub

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?

I have also followed Building Apps for iOS with MIT App Inventor and have the Apple profile downloaded.

I am aware of Join the MIT App Inventor beta - TestFlight - Apple but this iOS Companion beta version would not have my port in it.

Hi @psm

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.

Thanks for your reply Evan.

  1. 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 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?

  2. 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 ( was already taken (by MIT) - see my comment at Update 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, 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?

Thanks for your guidance


Is there maybe a problem with the rendezvous server? I can see my appengine polling but I don't know if the iOS AICompanionApp is doing the other half of the connection. (I can hit the above URL in the phone browser, FWIW)

My appengine reports version:
Built: May 12 2024 Version: v185a-1017-g9f65523da-dir_ty

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?


The problem appears to be in the AICompanionApp that I built in Xcode. The symptoms are consistent, whether I use:

Turning to AICompanionApp:

  • 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):

      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?


Maybe related: what Capabilities does my Provisioning Profile need to include, and if it doesn't maybe that is what is causing the problem?

Ah, some extra background about iOS status here: When will the iOS build server be released? - #25 by ewpatton

Sorry, I was not aware that iOS was not fully supported (for various reasons) yet.

Is it worth me pursuing this further, or should I just stick to improving the Android Maps component for now?

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?

Good call to load a known project. That shows that my custom-built iOS companion app is not working:

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?


Chunk: (begin (require <>) (process-repl-input -1 (begin (do-after-form-creation (set-and-coerce-property! 'Screen1 'AppName "HelloPurr" 'text)
(set-and-coerce-property! 'Screen1 'ScreenOrientation "unspecified" 'text)
(set-and-coerce-property! 'Screen1 'Scrollable #t 'boolean)
(set-and-coerce-property! 'Screen1 'ShowListsAsJson #f 'boolean)
(set-and-coerce-property! 'Screen1 'Sizing "Fixed" 'text)
(set-and-coerce-property! 'Screen1 'Theme "Classic" 'text)
(set-and-coerce-property! 'Screen1 'Title "Screen1" 'text)

(add-component Screen1 Button1
(set-and-coerce-property! 'Button1 'Image "kitty.png" 'text)


(add-component Screen1 Label1
(set-and-coerce-property! 'Label1 'BackgroundColor #xFF0000FF 'number)

(set-and-coerce-property! 'Label1 'FontSize 30 'number)

(set-and-coerce-property! 'Label1 'HasMargins #f 'boolean)

(set-and-coerce-property! 'Label1 'Text "Pet the Kitty!" 'text)

(set-and-coerce-property! 'Label1 'TextColor #xFFFFFF00 'number)


(add-component Screen1 Sound1
(set-and-coerce-property! 'Sound1 'Source "meow.mp3" 'text)


Yes, this I have done a while ago, but the code is obviously not present in the standard AICompanionApp, nor your iOS beta.

Is this using 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.

The HelloPurr test above was done on the public server, as you suggested.

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: '' 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 ...

Yes, you should define an explicit App ID in your own namespace. As far as capabilities are concerned, App Inventor does not require any.