Skip to main content

Ten Years of iOS

Oct 20, 2026 evan's Blog


A Decade in the Making: Pulling Back the Curtain on App Inventor for iOS

Today marks a milestone that feels both distant and immediate. Ten years ago, during a quiet long weekend in 2016, I sat at my computer and asked myself a question that every engineer loves (and occasionally regrets): “How hard could it be to create a brand new runtime for my product?” Many people had been asking about iOS support for App Inventor, and it made sense to dive in and find out the answer to that question.

At the time, the goal was modest: I wanted to see if we could get a project like Hello Purr to run on an iPhone. But as I quickly discovered, the gap between a “simple idea” and a working implementation was a great technical puzzle that ended up having a lot of moving parts. To make it happen, I had to architect four distinct pieces:

  1. A Scheme Runtime: Because App Inventor generates Scheme code, the companion app essentially needed to function as a Scheme read-eval-print loop (REPL).
  2. iOS Component Implementation: I needed to build iOS-compatible versions of the components that Hello Purr relied on to actually function (i.e., Screen, Button, Sound).
  3. The “Glue” Code: I had to write the bridge that allowed the Scheme runtime to instantiate and customize those native iOS components, and allowed the components to trigger Scheme code (event handlers). This code also has to manage the memory relationship between the Swift code and the Scheme code, since each has its own resource management model.
  4. A Web Server: We needed a way to receive Scheme code and respond to App Inventor over HTTP—a system we now refer to as “Legacy mode” in the companion app. WebRTC support came later.

It took about a week of intense experimentation to get the first prototype humming. I found Picrin, a Scheme interpreter written in C, and managed to cross-compile it for iOS, while using the GCDWebServer framework to handle the HTTP endpoint.

While the prototype worked quickly, the road to a public release took another four years. This involved implementing over 70 components and implementing every single block that was added in the Android version, and making sure that the behaviors roughly matched. It was a substantial project that involved staff engineers, masters students, and undergraduates in our lab at MIT to accomplish.

But the story didn’t end in 2020 when we pushed through the MIT App Inventor companion app through Apple’s App Store Review process.

With the companion successfully published, my sights turned to the next major hurdle: the “Build” problem. Apple requires a paid development license to install apps on a device, a fee that is often prohibitive for our primary users: students and minors. We didn’t want a paywall to stand between a student and their creativity.

This led to the creation of the Saved Apps Library. Instead of requiring a complex, licensed build process, we created a way for users to store their finished projects in a cloud library to show off to friends and family. By integrating shortcuts, we allowed users to add these projects to their home screens, mimicking the experience of a compiled app without the financial barrier. The Saved Apps Library has also found its way to Android as well. There are other iOS-inspired projects, such as the augmented reality work done by Nichole Clarke and Cindy Bishop, that are making their way to the Android version as well.

Looking back from 2026, the impact of that long weekend in 2016 is clear. Today, roughly 20% of our community—about 200,000 monthly users—use iOS to test and build their apps. Before our 2020 release, these creators were limited to emulators; today, they have the same power and immediacy as our Android users.

It’s been a long journey from a C-based interpreter and a “what if” question to a platform supporting hundreds of thousands of students. Here’s to the next ten years of breaking down barriers to computational action!