Apple’s closed-source approach is losing out to AI app builders
telkins.dev
telkins.dev
The linked tweet (https://x.com/Baconbrix/status/1888633966938276267) is only about shopping apps.
I say that as someone who uses Expo precisely for this reason.
It seems to be as long as you don't significantly alter the primary purpose of the app, then it's "allowed". But that's a very broad interpretation and puts native Swift apps at a huge disadvantage.
Like I use them, I can't not and it beats ordering stuff over the phone or whatever. But most of them at best can rise to the dizzying heights of "tolerable."
You can see a ranking of the top non-native apps here.
Does it make real apps? Or only prototypes and trash?
Do we need quantity or quality apps?
I don't use it for everything, but it is a 2x-10x multiplier.
It's basically electric screwdriver. You can open & close your laptop with old piece of iron. It even won't be worse in terms of quality, but if you want to fix 20 of them in a day it doesn't make sense.
However, the fact that integrating these tools with any sort of Apple toolchain is a nightmare is still a problem. Because even if you don't care about AI slop coding, there's plenty of other things that developers are used to that become far more difficult when the only option[0] is proprietary dev tools with very strict hardware licensing requirements attached to it. This puts a very real cost on iOS development.
The only reason why developers put up with iOS now is because it has half the US mobile market, so brown-nosing Apple is mandatory for certain app classes. This doesn't make the cost go away, it just means it gets spread around[1], like how everyone has to pay credit card fees or mobile storefront fees even when they're paying with cash or buying straight from the developer. But when that market power isn't there, such as on macOS[2] or visionOS (lol), developers just straight-up don't bother supporting the platform because Apple is disrespectful to developers.
[0] I am aware of that one non-Apple iOS toolchain, it still requires you grab the SDK files yourself off a Real Mac™ which is a pain in the ass and not going to pass a corporate compliance department's muster.
[1] The exact mechanism that forces cost-sharing is called a most favored nation agreement. You are required to offer the best pricing to people paying your junk fee and cannot discount around the fee.
[2] People often blame Metal for macOS gaming being terrible. This is missing the point. iOS has the same core technology requirement; so all the middleware has to support Metal anyway. But if you don't need to be on mobile, you don't need to support any Apple platforms, which is preferable.
1. I know what I want.
2. I don't know off the top of my head how to accomplish it.
3. However, I do know enough to tell whether what the AI generated works right.
So for me it covers cases like "I know databases and I know programming, but I don't know enough Python to do a DB query without looking for docs. Have Copilot generate some working sample code, and then I can pick things up from there".
I'm sure bigger things can be done but I think just that alone is extremely useful. Saves a bunch of time on googling, making it past all the ads, the requests to subscribe, the far too long introductions, etc. Sometimes all I want is 20 lines of sample code and nothing else, and AI seems to do very well at that without leaving the IDE.
Momento mori to anything raising tens of billions of dollars from VCs and PE's. The UX is going to get much worse, surprisingly quickly.
User: How do I do X?
AI: Well {FAANG} has this great product ...
AI: This is how you do X but doing Y which is just like X you can save $100 a month with {MAMAA}.
User: I just want to do X.
AI: It is too complicated for a single person to do X. Why not contact {BUSINESS} and they can do it for you because they specialize in X.
AI: Are you sure you don't want to save money with {MAMMA}. Here is a coupon to save even more.
The only type of quality that matters to me is I can achieve what I want to do quickly, so sorry your fancy native components and animation actually get in the way of it.
Yes, it already has fundamentally shifted software development and it will continue to do so. We're just getting started. And it's not going away.
> Does it make real apps?
Yes, it can, in whole or in part.
> Or only prototypes and trash?
Not only, but yes, it creates plenty of that, too.
False.
I’ll admit you’re right when AI can generate a replacement for Explorer.exe for Windows 11 from a single prompt. We’re still a long way off from that.
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.
Clarification: While Swift Assist was announced at WWDC in June 2024, it has yet to ship. Predictive code completion is available in Xcode 16, though.
I've attributed it to the general lack of open source projects to train off.
OpenAI demo’d native swift development with Xcode on day 11 of their 12 days of releases in December, see 6:00 in here: https://www.youtube.com/live/g_qxoznfa7E?si=BXd88NmbjHSUyPAM
At the time it seemed compelling, but am curious if anyone who regularly crafts in Xcode can comment on that release / its sustained value as an AI workflow to pair with Xcode?
We support chat (with cmd+L), agent, tab autocomplete, cmd+k, and voice mode. And the ability to add Xcode errors/warnings in bulk to the chat.
Isn't Swift literally open source software lol
And for those of you hissing at my previous comment you might be interested to know that this joke was written by AI.
Now you don't know what to do.
Rip Norm Macdonald
Apple is being boneheaded by going their own way. But closed systems lorded over by tyrannical giants typically are.
Now I understand that accessibility is most likely not a high concern for a React dev, but there are people out there who want to give the users of their platform of choice the best possible experience, and that best experience would be delivered with said platforms native tools, because they have the best integration with that platform.
Your argument is a straw man. When we agree upon standards, wonderful things happen.
HTML, Email, TCP, DNS, and every other protocol are an example of what happens when we collaborate openly and don't have one company lording over everything.
Apple just wants to control the iPhone and the money printer it has built. It has distorted computing for over a decade.
Mobile computing belongs to two companies, not to us.
I would agree with your statement. However...
No self respecting developer would pick SwiftUI over React Native.
But that is too generic of a statement to stand by. I just personally have prioritized development time over... uh.. fandom?
Apple isn't viewed as friendly to open source since you can't even distribute software to their platform without going through their censorship/taxation centralized review process. (And an army of people will rush to tell you this is okay.)
The meme of Swift being useful to anything but Apple devs needs to die.
That doesn’t mean good art is impossible with, say, an iPhone’s digital camera and its AI-powered capabilities. Nor will it mean LLM-powered tools can’t be helpful to writers or other workers. But all creative pursuits — programming included — are already democratic without Apple or Google or whatever corporation butting in looking for more rent.
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.
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
I also imagine that Linux is going to have quite the edge over microsoft on AI based programs.
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.
I don't think this is true, either.
Is it possible? Yes, of course. Bazel and Buck iOS builds have existed for a long time, and many large teams use them. You can even use Gradle to build an iOS project.
Does Apple officially support any of those? No, you won't find any Apple instructions telling you how to do any of this, Apple expects iOS apps submitted to the store to be built with Xcode. You're on your own with these solutions. And setting up Bazel for an iOS project is not an easy undertaking.
The codesign tool is documented and clearly supported by Apple, as is the manual provisioning portal, itself a website clearly designed for people to directly futz with. There is copious documentation on how to use clang, as well as on how .app bundles are organized.
The only even sort of awkward thing -- like the closest you can get to an argument that any of this "isn't officially supported" -- is some awkward keys you have to place in your Info.plist... but like, that's it (and for all I know it is, too, documented somewhere... I haven't ever looked as it was just a few lines of XML to copy).
Even the tool for uploading your build to the App Store without using Xcode--the one step that I'd agree might feel off the beaten path if you have never tried to look into how to do it before--is fully documented by Apple.
https://help.apple.com/itc/transporteruserguide/en.lproj/sta...
Yes: you have to know how to put the steps into order, but it is a stretch to say it isn't officially supported as Apple clearly is not merely not rejecting people who do this... they are going out of their way to support all of this tooling. They could have only provided a way to do this in Xcode, but they didn't.
As for "being on your own"... that's software development! We might as well claim there is not only no officially supported way to build a C/C++ command line tool, or even a JavaScript-enabled website, as there is no official upstream. Yet, on the other side, there are numerous supported ways to build such programs in myriad frameworks, some more difficult than or with more build steps than others, each supported by the open source community.
If you don't know how to build a binary, how to make a .app folder, how to run codesign, or how to use Transporter, maybe your fancy LLM can do it for you? Isn't that what people are using them for anyway? To quickly generate and manage all of the boilerplate of a project? I bet it can even help you set up Bazel (though I recommend just using GNU Make, as it really isn't difficult to hand-build a binary).