MIT App Inventor builds a real Android app. On iPhone it builds a live test, and packaging is still a closed beta.
Android gets a signed, installable file you can hand to anyone or upload to Google Play. iPhone and iPad get your app running inside the MIT AI2 Companion app, which is a real and genuinely useful thing, and is not the same as a file. MIT does document a route from App Inventor to an .ipa and to the App Store, and on the same page where it says so, it lists that route under Future Work and calls it a closed beta. Every claim about App Inventor below comes from a page MIT publishes, read on 22 October 2026, and each page is named. If you arrived here wanting an app on the store without writing code, the honest overview is build mobile app without coding.
There is also a free answer that most people never find, and MIT puts it in its own FAQ. If all you need is the app on the phones in one classroom, you can save it inside Companion and run it offline forever, with no developer account and no store. Read the next four sections before you spend a penny.
Start hereThe short version
Two platforms, two very different end states.
App Inventor is a block editor that runs in a browser and a build server that runs at MIT. On Android the build server hands you a finished app, signed with a key it keeps for you. On iOS the same build server can produce an .ipa, and MIT is open about the price of getting there: an Apple developer account, a certificate you renew yearly, a provisioning profile per app, and a device list if you are installing outside the store.
So the useful question is not which platform App Inventor supports. It supports both. The question is which of the eight routes below matches what you actually need, because three of them are free and two of them involve a yearly bill and a signing process. Teachers who plan this badly discover the difference in the last week of term.
What does MIT App Inventor actually build?
Three artefacts, and it helps to keep them apart. The first is a live session: the MIT AI2 Companion app on a phone, showing your project as you edit it, with the browser and the phone talking to each other through MIT's server. The second is an Android package. MIT's FAQ puts it in one sentence, that for Android you can build an installable app with an .apk extension that runs on its own, without Companion. The third is the project itself, an .aia file you export from the File menu, which MIT describes as the source code and blocks for your project. An .aia is readable by another App Inventor account and by nothing else.
There is a fourth output that MIT's publishing page does not mention, which is worth knowing because Google requires it. MIT added App Bundle builds in release nb187, dated 22 August 2021, and the release note says that AAB files can only be used to upload a packaged app to the Google Play Store and cannot be loaded directly into a device or emulator, and that this is now the required way to upload a new app to Google Play. Meanwhile the page titled Publishing Apps to Google Play still walks you through downloading a .apk from a dropdown it calls Package for phone. Both pages are MIT's. The release notes are the more current of the two.
One more figure for anyone whose app has to stay in the Play Store. MIT's release notes for nb206, dated 28 August 2026, record Android SDK 36 support and say App Inventor now targets SDK 36 because that is what Google requires for apps in the Play Store. The newest entry on that page at the time of reading is nb206a, dated 24 September 2026, a bugfix release with no new Companion apps.
MIT App Inventor, Make iPhone Apps with App Inventor, read 22 October 2026
Pick your route
Eight documented ways out of App Inventor
Tick the ones you are considering. The left note is what MIT documents, read on 22 October 2026. The right note is what it asks of you, which is where most classroom plans come apart.
Nothing ticked. If you only need the app on the phones in one room, the second button is almost certainly your answer and it costs nothing.
Is iOS supported, and in what form?
Supported, and the form matters. MIT's iOS page opens by saying App Inventor has worked with iPhones and iPads since March 2021 and that almost all the apps in its tutorial list work well on the iOS Companion app. Its FAQ answers the question with a flat yes and dates it to early 2021. The system requirements page asks for iOS 9.0 or later on an iPhone, iPad or iPod Touch, or macOS 11 or higher on a Mac with Apple M1 silicon, where an iPhone app will run on the desktop.
The limit shows up in MIT's own capability table, which carries its meaning in ticks. iOS gets a tick for live testing, for the Android emulator and for sharing source code. The extensions column is blank for iOS, and MIT states elsewhere on the page that extensions written for Android are not supported on iOS. The last column, installing apps on a phone or tablet, carries a footnote marker instead of a tick. That footnote says you can build, package and install iOS apps, but that the current process is costly and complex because of strict Apple developer requirements, and that MIT is working on something friendlier.
Then, lower on the same page, the Future Work list says that building and packaging .ipa files for permanent installation on an iOS device or for distribution on the App Store is currently in a closed beta. Those two statements sit a screen apart and they do not say quite the same thing. If you are deciding whether a class can ship to the App Store this term, the closed beta sentence is the one to plan around, and MIT's detailed iOS build document currently lives on its iOS build server test host rather than on the main documentation site, which points the same way.
The Future Work list is also the honest list of what a cross platform lesson cannot assume. It names the Translator, Charts, Spreadsheets and Navigation components, clickable images, Near Field Communication, Bluetooth support, Internet of Things extensions such as micro:bit, and AI extensions such as PersonalImageClassifier. It notes that the PhoneCall component's MakePhoneCallDirect and Texting are blocked by iOS privacy and security restrictions, and that iOS hardware has no hygrometer, thermometer or barometer, with a suggestion to check each sensor's Available property in code.
MIT App Inventor, iOS capability table and Future Work list, read 22 October 2026
MIT's platform table, with the footnote spelled out
The row labels below are MIT's own column headings, copied from its iOS page on 22 October 2026. The only change is in the last row, where MIT prints two asterisks and we print what the asterisks mean. A table whose meaning is carried by a tick is easy to misread, and this is the row people misread.
| What MIT lists | iOS | Android |
|---|---|---|
| Live test apps while coding | Yes | Yes |
| Test apps with an Android emulator | Yes | Yes |
| Share app source code | Yes | Yes |
| Use extensions in your code | No | Yes |
| Install apps on phone or tablet | Marked with a footnote, not a tick | Yes |
What does MIT say about publishing to Google Play?
That you can, and then it spends the rest of the page on the two things people lose. The page is called Publishing Apps to Google Play (App Inventor 2) and its first line is that applications built with App Inventor can be uploaded to Google Play. The mechanics it gives are short. Set VersionCode and VersionName in the properties panel for Screen1 in the designer. VersionCode is an integer that Play Store users never see, it defaults to 1, and MIT says it should go up by one with every successive change, major or minor. VersionName is a string that defaults to 1.0 and can be anything. Both have to change when you upload a new version.
Then comes the part the page shouts about, in capital letters, and it deserves the shouting. Your app is signed during the build with a private digital key tied to your account, held in a keystore file that MIT's server creates and stores for you. An Android phone remembers which key signed the app it has installed, so an update has to be signed by the same key. MIT's advice is to export the keystore yourself from the Projects menu and keep it somewhere safe and not publicly readable, and there is an Import Keystore option for moving it to another App Inventor server. The page then states that a lost or deleted keyfile cannot be recovered, by you or by MIT, and that no amount of effort will bring it back. Source code you could retype. A signing key you cannot.
The same page asks you to keep your own project backups through Project, then Export selected project (.aia) to my computer. It says that MIT and Google, which operate the App Engine service App Inventor relies on, make best efforts not to lose projects, and then says in capitals that no guarantee is offered and that your own backups are essential. For a teacher with a term of student work on the server, that sentence is the whole argument for a weekly export. The mechanics of the store side of this, once you have a file, are in publish to app store.
What does the App Store route actually cost?
MIT states the price in the first paragraph of its iOS build document: you need an active Apple Developer License, which it puts at typically 99 dollars a year, and it adds that non-profit and educational organizations can often get a waiver for the fee. Apple's own enrollment page agrees on both halves. It gives the Apple Developer Program annual fee as 99 USD and the Apple Developer Enterprise Program at 299 USD, in local currency where available, and it says accredited educational institutions worldwide can enroll in the Apple Developer Program with a fee waiver. Both figures read on 22 October 2026.
Apple's page answers a second question teachers ask, with a no. There is no developer program specifically for students. What it says instead is that learning to develop for Apple platforms does not require membership at all, because an Apple Account is enough to download the tools and test your apps on your own devices. That is the same shape as App Inventor's Companion route: free to build and free to run on a device you hold, with the fee attached to distribution.
The money is the smaller half of the cost. MIT's build document walks through generating a Certificate Signing Request from the Projects menu, which it notes is tied to the same keystore that signs your Android apps, then creating an Apple Distribution certificate, an App ID with a bundle identifier, and a provisioning profile that you upload into your project's Media section. For an Ad Hoc build you register the UDID of every device that is allowed to run the app. Certificates expire after a year, so this is a yearly chore rather than a one-off. For an App Store build you also create an app-specific password on your Apple account and store it in App Store Settings, and MIT warns that those credentials are encrypted on its server and cannot be retrieved afterwards. One last trap from the same document: from iOS 16 onwards, Apple requires Developer Mode to be switched on in Settings, under Privacy and Security, before an Ad Hoc app will install, and the device may need a restart to enable it.
Apple Developer Support, Enrollment, fees and education fee waivers, read 22 October 2026
What you keep if you build it somewhere else
Not the blocks. An .aia file opens in App Inventor and in nothing else, so a move to another tool is a rebuild rather than an import. What you keep is the design, and in a working app that is most of the value. You already know the screens, the order people move through them, the fields you store, what happens on every tap, and which of your users are on an iPhone. That list is a specification, and writing it out takes an afternoon rather than a term.
Newly is one way to turn that list into a shippable app. You describe the app in plain English and it writes a real React Native and Expo project that you own, with two-way GitHub sync so the code is never locked inside somebody's server. It uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK. It costs $25 a month and there is no free tier, which is a real difference from App Inventor and worth saying plainly. What it will not do is press submit on the App Store for you, because Apple requires the owner of the content to submit it, so the developer account and the submission stay yours.
Two neighbouring pages cover the same move from a different starting point. If your team already writes code and you are weighing an autonomous agent against a block editor, read devin to mobile app. If you have been prototyping in an AI editor and want to know what it takes to get a phone build out of it, that is windsurf to mobile app.
One recommendation, since this page has a lot of teachers reading it. Do not move a class off App Inventor to get an app onto a phone. MIT's own free route already does that, and the save inside Companion costs nothing, needs no developer account and works offline, which covers the school fair and the parents evening. Move when the app has an audience outside the room: a listing the public can find, an update you can push to people you have never met, a push notification. Those are the jobs that need a store, and a store is where the fee, the certificate and the signing key start to matter.
Questions people ask about MIT App Inventor and mobile apps
On Android it builds a signed, installable app. MIT's own FAQ says that for Android you can build an installable app (.apk) that runs on its own, without Companion, and its release notes added App Bundle (.aab) builds in release nb187, dated 22 August 2021, for uploading to Google Play. On iPhone and iPad the normal output is a live test session inside the MIT AI2 Companion app rather than a file. It also exports your project as an .aia source file that another App Inventor account can import. Read from MIT's pages on 22 October 2026.
Keep the design. Change the build.
Write out your screens, your fields and the one thing Companion cannot do for you. That page of notes is the brief, and it is worth more than the blocks it came from.
Start building