Apple’s closed-source approach is losing out to AI app builders

> According to Evan Bacon, one of the developers leading the Expo project, 40 of the top 100 iOS apps are now non-native. And with the proliferation of AI app builders, the future is starting to look even more non-native.

The linked tweet (https://x.com/Baconbrix/status/1888633966938276267) is only about shopping apps.

Is gen ai app development really that important?

Does it make real apps? Or only prototypes and trash?

Do we need quantity or quality apps?

The author's opening complaint is that the AI coding assistant features in Xcode aren't state of the art.

Note: Xcode does have predictive code completion models and Swift Assist. GitHub Copilot for Xcode is an open source extension, proving that it is possible to extend Xcode with newer capabilities.

The author cites examples of superior AI app builders that can generate non-native mobile apps, and claims that this will lead to growth in non-native iOS apps because native development is not keeping up.

The author argues that the lack of AI native app builders is because Xcode is closed source and iOS development is too heavily tied to Xcode. Counterargument: Doesn't the existence of all these non-native iOS apps the author cites suggest that this isn't really true?

The argument takes shift toward imagining a web-based third-party tool for app development and then describing the obstacles to this, like having to run the iOS simulator in virtual machines on Apple hardware. Where is the argument for why these hypothetical AI app builder tools have to be cloud-based, SaaS, web apps? This is at odds with the author's earlier stated preference for native apps. The idea of cross-compiling SwiftUI to WASM to run in the browser is the exact kind of thing that makes non-native apps buggy and unpleasant to use.

"The platforms thriving right now are all built on open source software. More and more teams are building apps in React Native rather than Swift"

Isn't Swift literally open source software lol

Xcode need a better plugin system. The one they have right now is very restrictive. You will see stuff like ChatGPTs “work with” that looks at open windows or copilots plugin that does crappy autofills/completions but it resorts to accessibility hacks to do it and you cannot do multi file stuff

If you take a look around x, reddit or linkedin nowadays it seems full of non tech people or parents proud of their children making "complete functioning apps" without any coding. Usually they're nothing more than specialized todo lists or calendaring apps for keeping track of some habits. Do we really need all those apps? I'm worried that if I have a good idea and it happens I can execute it well, then the app would be buried in the millions of "v0" apps out there. And no, Apple won't review them all, it's impossible... maybe an AI will lol

This "problem" of not being able to use Claude or GPT-4o for Swift iOS apps is news to me as an aider.chat + Xcode user.

Last summer I used aider.chat to develop a new feature along with a new and complex animated multi view, leveraging SwiftUI as well as a number of new Swift 5.9 and Swift 5.10 features, for a Swift 5.9 upgraded to 5.10 iOS application built using Xcode and the new live view (instead of the simulator), with auto-commits and each push to GitHub causing a Testflight build.

I worked with Xcode open, but a separate MacOS "Terminal.app" window for aider.chat, with Xcode using a first class git repo. Since aider.chat does git commits to add and undo, Xcode followed along perfectly, contrary to the article's claims.

In fact, as fast as aider committed code, the code changes recompiled and the live view updated, which felt about as "live" as a JS fiddle or other live JS preview tool.

More amazing to me -- views usually updated with aider's changes without restarting the app or losing any state.

I still prefer the hybrid of aider in terminal along side a git-savvy IDE over Cursor or Cline.

> According to Evan Bacon, one of the developers leading the Expo project, 40 of the top 100 iOS apps are now non-native. And with the proliferation of AI app builders, the future is starting to look even more non-native.

This is easy for Apple to regulate away. Just put in “Apps shall not use cross platform frameworks” in the developer agreement and bam - all the enterprise companies (BMW, GM, etc) will switch away for fear of being banned

The thing is Apple doesn’t care if apps are native or not, as long as they bring in the money

AI assistance in IDEs was the final nail in the coffin for Apple's development environment, which had already —and consistently— been lagging behind for over a decade.

Apple have this promised Swift Assist feature but over a year and still nothing. Their 2gb completion model is useful for really simple boiler code, but it helps when it does

Wow this is interesting AF actually.

I also imagine that Linux is going to have quite the edge over microsoft on AI based programs.

> From there, compiling code for iOS is notoriously difficult and not officially supported outside of using Xcode.

I mean, this is a stretch... you really have to go out of your way to narrowly define "officially supported" to the point of absurdity: Apple clearly supports compiling for iOS outside of Xcode, as Xcode doesn't even do the compilation, never has, and--we can be pretty confident in saying--never will. Meanwhile, despite many people using automatic provisioning, Apple's portal let's you do it all manually: it isn't as if there are a bunch of missing pieces if you aren't using Xcode to do your build. Very large companies routinely deploy code for the most popular applications without using Xcode and smaller projects are often built in languages or frameworks using tooling that completely bypasses Xcode... if you don't think Xcode is a win (and it isn't: there is a good reason why the really large-scale projects don't use it) just don't use it and your life will get better. And, if working in AI is really the competitive advantage people claim, it would seem like a no-brainer to finally get around to porting your project build to escape Xcode.