> 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.
I think there is an implicit assumption that the top 40 apps is reflective of what all app developers should be doing. The top 40 apps are probably also all made my mega corps with enormous budgets and desires to be multi-platform right out of the gate, and also have already vetted necessary issues like "does app performance matter" versus "does developer productivity and app-parity across platforms" matter. Just because a top 40 app is high, maybe it's something like Amazon's shopping app, maybe the trade-offs are heavily towards slow-starting but very feature rich and also equivalent across platforms is necessary. If someone writes a note-taking app that takes 10 seconds to start because it's loading some JavaScript updates and spinning up the non-native code execution hamsters, I already forgot my note. Native is obviously desirable. Or a game is interesting because maybe people are patient for a slow load, but still desire very fast native performance. My main point is there are quite a few trade-offs, and it's unsurprising the leads at Expo are saying look how awesome this stack is. I've used Expo and it was awesome, but it comes with costs too.
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.
From a strictly UX perspective, I'm strongly of the opinion that most shopping apps also suck industrial quantities of ass.
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."
I find it reasonably useful given these conditions:
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.
I’m really not looking forward to the day when they start serving ads through LLMs. Hopefully local is solid enough by then to do most of the same stuff.
This is a good point and it reminds me of a link to an news article someone had shared some weeks earlier about how AI-generated literature in the form of ebooks is already flooding public libraries that subscribe to certain lending platforms. In a sense, it could be an advantage to have systems where it is so cumbersome to get LLMs to help you with generation so that people have to put at least a little bit of effort.
This is a pretty big range. Are you saying the overall multiplier for all of your work is somewhere between 2 and 10x, or that some tasks are 2x and others are 10x?
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.
It saves a lot of time. You don't need it to generate whole app - just do some tedious bits.
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.
Maybe... quantity? Of apps an features. The idea that software is some sort of art form that should be upheld is largely dev/designer centric instead of consumer-centric.
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.
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.
Lacking predictive code completion as a beta in Xcode 15 felt like a miss. I realize it would have jumped the gun on Apple Intelligence, but the company has released features prior to the marketing: evidence Spatial Audio.
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?
Why would a company hire iOS developers when they can build everything for all platforms in a single language and framework? It's fungible, interchangeable, easy to maintain, and easy to hire for.
Apple is being boneheaded by going their own way. But closed systems lorded over by tyrannical giants typically are.
Using RN doesn’t preclude need for native devs except for the most basic things like local restaurant wrapper apps. As scale increases (codebase complexity, app feature set, number of users, etc), the more you’ll need someone who understands and can work with all the native bits that leaky abstractions like RN wrap.
Maybe all humans should speak 1 language. Maybe there should be no countries. Maybe we all should be the same color and have the same culture. While this may be an interesting idea to discuss over a beer or two, it is so far removed from how the world really works that it's just plain stupid to use it as a argument. Wishful thinking is great and all, but this is never going to happen, and especially with the multiple decades of legacy, disagreements over usability and user experience, non-compatible accessibility systems and API's, the different platforms are very very far from each other.
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.
Desktop OSes are still open platforms and yet we have GTK, Qt, Cocoa, and whatever Windows does these days. You can run a Qt app on macOS, but macOS users are used to Cocoa and prefer the experience of using a native-feeling app. Wouldn’t be any different if you could run Android-native apps on iOS or vice versa.
I'm a self respecting developer who has been using React in production for almost 10 years now, and SiwftUI is significantly better than RN. I wasn't a huge fan of learning to deal with XCode, but yeah it's not fandom it just actually works better with fewer quirks and downstream perf issues.
Swift, the core language, has a FOSS compiler. SwiftUI is a proprietary UI toolkit library and app framework whose only relation to Swift is that it's written in it. It would be like calling GDK "ValaUI" or Bevy "RustEngine".
Swift has no use beyond writing software to target Apple users.
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.
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 is exactly how I felt as a photographer when smart phones took over the world 15 years ago. I try to remind myself that democratization is good, even if it isn’t necessarily pretty.
Art was already democratic. Now the megacorps are inserting themselves in the process and using “democratization” to sell the idea back to people.
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.
Despite not really liking AI-generated content very much myself I think it is quite neat that everyone can now have small apps that precisely cater to their needs.
What they need? More todo apps? Or simple crud apps that they could have hacked together with no code tools for years? If so it speaks long dinstances about the current state of software
At the end of the day, most consumer software boils down to simple CRUD apps with various skins. Sure people have been able to make those for years but it was still time consuming to wrangle the no code tools. Now people can do it in an hour or two with simple English instructions.
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.
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
> 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.
I could have worded this better since running xcodebuild is obviously outside of Xcode. But it's not a stretch.
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.
There might not be end-to-end hand-holding for how to do it, but all of the needed tools are documented, and each one is individually supported. All you are doing is using clang to build a binary -- the same way you would build a binary in any other circumstance -- placing it into a .app container, code-signing it, and zipping the result to get your .ipa file.
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.
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).
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
> 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.
I think there is an implicit assumption that the top 40 apps is reflective of what all app developers should be doing. The top 40 apps are probably also all made my mega corps with enormous budgets and desires to be multi-platform right out of the gate, and also have already vetted necessary issues like "does app performance matter" versus "does developer productivity and app-parity across platforms" matter. Just because a top 40 app is high, maybe it's something like Amazon's shopping app, maybe the trade-offs are heavily towards slow-starting but very feature rich and also equivalent across platforms is necessary. If someone writes a note-taking app that takes 10 seconds to start because it's loading some JavaScript updates and spinning up the non-native code execution hamsters, I already forgot my note. Native is obviously desirable. Or a game is interesting because maybe people are patient for a slow load, but still desire very fast native performance. My main point is there are quite a few trade-offs, and it's unsurprising the leads at Expo are saying look how awesome this stack is. I've used Expo and it was awesome, but it comes with costs too.
Why does Apple allow Expo apps on the App Store when they effectively bypass App Review? Doesn't this go against their own policies?
I say that as someone who uses Expo precisely for this reason.
It's definitely a very gray area within Apple's policy. Shorebird (Flutter OTA updates) describes it best in their FAQ (https://docs.shorebird.dev/faq/#does-shorebird-comply-with-a...).
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.
https://Appgoblin.info/companies/types/development-tools
You can see a ranking of the top non-native apps here.
From a strictly UX perspective, I'm strongly of the opinion that most shopping apps also suck industrial quantities of ass.
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."
Good catch, totally missed that, will update
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?
I find it reasonably useful given these conditions:
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.
Give OpenAI 25 years and they're going to be throwing up plenty of ads in our faces. Source: I remember using Google in 1999.
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.
They will just make it more subtle.
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.
LLMs already can be run on expensive consumer hardware (eg, a higher end Mac Studio), so I expect that to be quite temporary.
I’m really not looking forward to the day when they start serving ads through LLMs. Hopefully local is solid enough by then to do most of the same stuff.
This is a good point and it reminds me of a link to an news article someone had shared some weeks earlier about how AI-generated literature in the form of ebooks is already flooding public libraries that subscribe to certain lending platforms. In a sense, it could be an advantage to have systems where it is so cumbersome to get LLMs to help you with generation so that people have to put at least a little bit of effort.
I recently saw a niche industry specific chatgpt wrapper. I don't think anyone is actually building anything of value with gen AI.
I did. I do.
I don't use it for everything, but it is a 2x-10x multiplier.
This is a pretty big range. Are you saying the overall multiplier for all of your work is somewhere between 2 and 10x, or that some tasks are 2x and others are 10x?
Looking at your profile page, do you use a local model then?
relevant username
It's not.
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.
It saves a lot of time. You don't need it to generate whole app - just do some tedious bits.
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.
> Is gen ai app development really that important?
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.
It seems to me that ai apps are great for prototyping and getting to v0. Maintenance and continuous improvement seem to be more challenging.
Maybe... quantity? Of apps an features. The idea that software is some sort of art form that should be upheld is largely dev/designer centric instead of consumer-centric.
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.
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.
> Xcode does have predictive code completion models and Swift Assist.
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.
Lacking predictive code completion as a beta in Xcode 15 felt like a miss. I realize it would have jumped the gun on Apple Intelligence, but the company has released features prior to the marketing: evidence Spatial Audio.
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’re working on this at https://alexcodes.app!
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.
And the predictive code completion is pretty bare bones awful compared to what you get in VSCode/Cursor or other editors.
I haven't found predictive code completion to be good anywhere for Swift, especially anything to do with Apple frameworks.
I've attributed it to the general lack of open source projects to train off.
"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
No self respecting iOS developer would pick React Native over SwiftUI.
Why would a company hire iOS developers when they can build everything for all platforms in a single language and framework? It's fungible, interchangeable, easy to maintain, and easy to hire for.
Apple is being boneheaded by going their own way. But closed systems lorded over by tyrannical giants typically are.
Using RN doesn’t preclude need for native devs except for the most basic things like local restaurant wrapper apps. As scale increases (codebase complexity, app feature set, number of users, etc), the more you’ll need someone who understands and can work with all the native bits that leaky abstractions like RN wrap.
Because the single language and framework makes worse apps
Only because Apple made a non-open platform.
React Native makes worse apps for Android too
Maybe Apple and Google should open up their devices and agree on a standard UI toolkit.
Maybe all humans should speak 1 language. Maybe there should be no countries. Maybe we all should be the same color and have the same culture. While this may be an interesting idea to discuss over a beer or two, it is so far removed from how the world really works that it's just plain stupid to use it as a argument. Wishful thinking is great and all, but this is never going to happen, and especially with the multiple decades of legacy, disagreements over usability and user experience, non-compatible accessibility systems and API's, the different platforms are very very far from each other.
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.
> Maybe all humans should speak 1 language
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.
Desktop OSes are still open platforms and yet we have GTK, Qt, Cocoa, and whatever Windows does these days. You can run a Qt app on macOS, but macOS users are used to Cocoa and prefer the experience of using a native-feeling app. Wouldn’t be any different if you could run Android-native apps on iOS or vice versa.
There does seem to be a bit of cult-like loyalty to every decision Apple makes.
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?
I'm a self respecting developer who has been using React in production for almost 10 years now, and SiwftUI is significantly better than RN. I wasn't a huge fan of learning to deal with XCode, but yeah it's not fandom it just actually works better with fewer quirks and downstream perf issues.
Swift, the core language, has a FOSS compiler. SwiftUI is a proprietary UI toolkit library and app framework whose only relation to Swift is that it's written in it. It would be like calling GDK "ValaUI" or Bevy "RustEngine".
Swift has no use beyond writing software to target Apple users.
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.
Swift is open source, but SwiftUI and UIKit are both closed-source which is what I meant.
I think they mean SwiftUI.
If you noticed inaccuracies in the article you might be interested to know that the article was written by AI.
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
I mean I could downvote it
https://m.youtube.com/watch?v=thHWvoYfNyo
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 is exactly how I felt as a photographer when smart phones took over the world 15 years ago. I try to remind myself that democratization is good, even if it isn’t necessarily pretty.
Art was already democratic. Now the megacorps are inserting themselves in the process and using “democratization” to sell the idea back to people.
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.
Despite not really liking AI-generated content very much myself I think it is quite neat that everyone can now have small apps that precisely cater to their needs.
What they need? More todo apps? Or simple crud apps that they could have hacked together with no code tools for years? If so it speaks long dinstances about the current state of software
At the end of the day, most consumer software boils down to simple CRUD apps with various skins. Sure people have been able to make those for years but it was still time consuming to wrangle the no code tools. Now people can do it in an hour or two with simple English instructions.
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.
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
We were able to get around it using accessibility! Essentially bringing all of Cursor’s features to Xcode: https://alexcodes.app
They used to have it but XcodeGhost ruins it for everyone.
> 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.
I could have worded this better since running xcodebuild is obviously outside of Xcode. But it's not a stretch.
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.
There might not be end-to-end hand-holding for how to do it, but all of the needed tools are documented, and each one is individually supported. All you are doing is using clang to build a binary -- the same way you would build a binary in any other circumstance -- placing it into a .app container, code-signing it, and zipping the result to get your .ipa file.
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).
> For example, there is an xcodebuild command you can run, but it often doesn't work with table stakes features like incremental builds
I don't think this is true, either.
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
We built a fully fledged AI assistant for Xcode (callex Alex): https://alexcodes.app
Wow this is interesting AF actually.
I also imagine that Linux is going to have quite the edge over microsoft on AI based programs.