As a long-time iOS developer, it's frustrating — to say the least — as I watch the entire development landscape change while we are stuck in place. I've tried lovable.dev, bolt.new, and a0.dev to build some websites and apps and the experiences feel magical. Meanwhile, we barely have a working Github Copilot in Xcode and every developer I know has disabled Apple "Intelligence".
According to Evan Bacon, one of the developers leading the Expo project, 40 of the top 100 iOS shopping apps (*) are now non-native. And with the proliferation of AI app builders, the future is starting to look even more non-native.
Where is the Cursor experience for iOS development?
The reason for this, in my opinion, is due to Apple's closed-source history. This is a story of how long-held company decisions can accumulate and become disastrous. Let's take a look at what it would take to build an a0.dev experience for iOS.
(*): I originally said "all" apps which was a mistake, sorry!
Code editor
When a user prompts for changes they want, we need a way to update the code and see if it builds. This should be easy, right?
For starters, you need a Mac machine. From there, compiling code for iOS is notoriously difficult and not officially supported outside of using Xcode. For example, there is an xcodebuild command you can run, but it often doesn't work with table stakes features like incremental builds. And there are tons of slow papercuts you'll encounter such as it pinging the Apple servers several times to check for provisioning profile updates and whether your app has the correct entitlements (permission to use OS features). Again, features to lock down your app that nobody asked for.
In a local test project I'm able to get this command working. I added a compilation error to show how that looks:
➜ Snake git:(main) ✗ xcodebuild -scheme Snake -configuration Debug -json -destination 'platform=iOS Simulator,id=C286A4E0-BC6C-49EA-A0C7-BBAB40CB0E0B' -quiet build
/Users/telkins/dev/ios/Snake/SnakeTabView.swift:8:4: error: unknown attribute 'States'
@States private var path: [Screen] = []
^
/Users/telkins/dev/ios/Snake/SnakeTabView.swift:8:4: error: unknown attribute 'States'
@States private var path: [Screen] = []
^
/Users/telkins/dev/ios/Snake/SnakeTabView.swift:15:29: error: cannot find '$path' in scope
NavigationStack(path: $path) {
^~~~~
** BUILD FAILED **
This works and is probably parseable by an LLM since we want to automatically fix build errors for the user. Awesome, some progress!
What if our AI prompt results in creating a new file. Adding a new file should be easy, right?
Unfortunately this is also more challenging than necessary because Xcode's propietary project format requires you to track file references, so we need a way to edit this file and hope it doesn't get out of sync. I'm not aware of any official tool or library to help edit this file, although there's a commonly used xcodeproj Ruby gem.
In 2025 it's recommended to put as much of your code into Swift Packages, which work great, but they still need to be integrated into your project file. We're still in a weird transition period where we can't fully build an app with Swift Packages.
Luckily all hope is not lost, there are a few projects in development worth mentioning:
- Swift Build was recently open sourced, so I expect a lot of improvements in this area soon.
- Buildable folders were added in Xcode 16 which do help a lot for code not in a package. Now you only need to add a project file reference to a folder and not every file within it.
- Some folks have been working on a VSCode extension called Sweetpad which simplifies a lot of this.
But really this is all too little too late. iOS development as a whole is still closed source for the time being.
Previewing
Now let's pretend we've used AI to make some code changes, it successfully compiled, and we want to preview the result. From what I can tell with services like Lovable.dev, they run a local development server on a VM and your browser simply has to view the right page. For a0.dev with React Native apps it's basically the same thing, you are viewing a react-native-web instance in your browser. a0.dev is essentially displaying:
<foreignObject
x="21.25"
y="19.25"
width="389.5"
height="843.5"
clip-path="url(#roundedCorners)"
class="overflow-hidden"
>
<iframe
src="https://a0.dev/v2/52/index.html?initialUrl=exp%3A%2F%2Fu.expo.dev%2F933fd9c0-1666-11e7-afca-d980795c5824%3Fruntime-version%3Dexposdk%253A52.0.0%26channel-name%3Dproduction%26snack%3Dcc18e8a0-8c69-4bdd-8df0-7d15181cac48%26snack-channel%3D5PYBIUJa1n&origin=https%3A%2F%2Fa0.dev&verbose=false"
class="w-full h-full border-0"
allowfullscreen=""
allow="cross-origin-isolated; accelerometer; ambient-light-sensor; autoplay; battery; camera; fullscreen; gamepad; geolocation; gyroscope; idle-detection; magnetometer; microphone; midi; payment; picture-in-picture; screen-wake-lock; usb"
></iframe>
</foreignObject>
And that <iframe> is loading the react-native-web HTML page, which you can see by inspecting the element. Since React Native is just React code, it's possible to swap out the underlying platform target and get a nice preview in your browser.
On the other hand, iOS development targets an iOS runtime, so you have to run your app on a Simulator device. Everything becomes much more complicated. You have to manage launching simulators (which require a lot of memory), deal with device updates and simulator runtimes, and figure out how to pipe video output to a browser while sending user interactions back to the simulator. Not an easy task.
So it appears the iOS runtime is a big blocker here. What if we could target SwiftUI for the web through WASM or some other mechanism? Sorry, SwiftUI is closed source! We're at Apple's mercy to ever develop such a feature. There is a neat project OpenSwiftUI, but it's achieved through painstakingly reverse engineering the framwork. Why Apple made SwiftUI closed source I will never understand, especially when the Android competitor, Jetpack Compose, is open source and thriving in cross-platform development with Compose Multiplatform. There are some neat projects like Skip but that only targets Android and not the web.
Building at scale
Now let’s pretend we managed to solve the simulator problem and want to scale our solution so thousands of developers can use it. Server virtualization is a solved problem, right?
Not when it comes to iOS. Since we need to run a simulator, we also need macOS machines. Here’s the snag: deploying macOS servers at scale is extremely difficult.
For starters, macOS virtual machines can only legally run on real Apple hardware. Then, according to Apple’s licensing terms, you have to reserve these bare-metal Mac instances for a minimum of 24 hours. (Check out the hoops you jump through with AWS bare-metal Mac instances.)
Second, once you do get a Mac instance running, Apple’s Virtualization Framework limits you to just two concurrent VMs. You’d want to run your build service in a VM because simulator devices have access to the host filesystem—and a malicious app could potentially read or steal data from the host or other users. Therefore, running at scale means lots and lots of bare-metal Macs.
Finally, macOS simply isn’t built to be a headless server OS. You’ll run into a ton of quirks that you don’t see on Linux, which “just works” for server purposes.
What about Android?
It's worth quickly mentioning Google's Android since it's open-source. Does it fare better than Apple?
In theory it should, most projects will compile successfully with a simple ./gradlew assembleDebug command, although compilation time is too long for a worthwhile developer flow. The emulator problem is largely the same as iOS. Running Android emulators at scale is possible but has its own set of headaches.
For this to be practical, your Android app would likely have to target a web platform using Compose Multiplatform. I've seen projects that render Compose views in a browser so it's definitely possible right now, just a matter of making the developer experience much better to match Expo.
Takeaway
Thank you for making it this far. So what’s the lesson? From my perspective, Apple’s secretive, closed-source approach to software has finally caught up with them, leaving them behind in the AI race. The UI platforms thriving right now are all built on open source software. More and more teams are building apps in React Native rather than Swift—especially now that AI services make bootstrapping an app unbelievably fast. I would love to see something like Lovable or A0 for building truly native iOS apps, but the quirks of Apple’s ecosystem make it unfeasible.
For years, developers have complained about the terrible developer experience (DX) on Apple platforms, yet Apple never tackled the root problems. Now, they’ve dug themselves quite a hole.