Apple's own Swift Playground app does the exact thing that supposedly violates the rules, abusing an inconsistently-applied exception for "educational" apps [1].
Recent regulation doesn't help here, by the way. iOS apps submitted for "notarization" to be distributed in alternative app stores in the EU, Japan, etc. still must comply with a subset of the guidelines, including 2.5.2. EU is probably not interested in strengthening the DMA so that Apple doesn't have to approve everything because then it makes other EU regulations easier to bypass (e.g. Chat Control).
The "educational" exception is definitely a convenient loophole, but it raises questions about consistency and fairness in how these rules are enforced across the board
It’ll be interesting to see if Apple comes around on customization of apps in general, because hopefully that’ll soon be what users expect.
In the world where users expect to be able to customize software more and more, apps start to look quite rigid and open platforms like the web that offer flexibility start to look more appealing.
Imagine a Lovable-style PWA that morphs into the app you vibecoded by storing the generated code in localStorage, for example - with cloud fallbacks to re-download the code if the storage is wiped.
Linux and Windows have always been a lot more customisable, Apple always was the more "we know better than you what you want" company... And they weren't wrong enough
I haven't been in the App Store ecosystem in a while, but the restriction is generally on running new Machine Code, all machine code needs to be signed on iOS. Interpreters get around this limitation, only the interpreter code that is compiled AoT and signed is actually running.
This tracks as the reasoning behind a lack of other browser engines, nobody can get comparable performance without a JIT, which would be compiling net new machine code that wasn't shipped with the binary.
The best way to handle this I would imagine within the current bounds of Apple's restrictions would be WASM.
Apps don't get removed for breaking that rule, though, because they can't break it in the first place. The system won't allow you to mark a freshly written page as executable.
Years ago I watched a bunch of people stop an apartment building from being built. They did this by employing a legal concern that they didn't actually care about, but that they knew would stop the development in its tracks. It worked.
That was the day I realized that for a lot of people, rules aren't actually rules. They're tools that they can use to stop something they don't like, no matter what the rule is really about.
I think this is a disgusting attitude, but it's unfortunately the way a lot of people operate.
So it might be that Apple has this "no external code" rule to stop things they don't like, and the category of "things Apple doesn't like" doesn't actually include every app that runs external code. It includes a lot of them, but for whatever reason Apple chose not to codify the details. Crummy if true, but I wouldn't be surprised. Every regulator I've ever dealt with leaves themselves an "I know it when I see it" escape hatch that lets them ban whatever they want.
If you read the actual rule the exceptions are relatively well defined. Stuff like pythonista falls into their educational/coding app exception as they define it
Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the app completely viewable and editable by the user.
There are not "exceptions"; there is one exception, and that's educational apps. But it's unclear why Pythonista is educational while the apps mentioned in the article are not. In fact, Pythonista is even listed in the "Productivity" section in the App Store.
Those are terminal emulators, not actual terminals. You can't fork or exec on iOS/iPadOS, so they're not actually running e.g. a python process, they're just running python interpreter.
As I understand it, ish implements x86 instructions and Linux syscalls as functions and translates running programs into arrays of calls to these functions, so all the machine code that will ever run is included in the app bundle, which at least satisfies the rules iOS enforces at runtime.
As for the rules as written, I suppose you could make reasonable arguments either way.
And it's always been a stupid rule. If I ship an app with a browser view, I can run any custom code I want in it. The rule is just a bandaid on Apple's lack of true sandboxing for apps.
> The rule is just a bandaid on Apple's lack of true sandboxing for apps.
That's not it at all. If an app can run arbitrary code then it can run other apps and that can by-pass the app store. They are specifically trying to prevent something like Wechat on the iPhone. It's not about security, it's about money and control.
Wechat is large enough to be able to negotiate requirements with Apple. They are the gateway to an entire continent and close to 2 Billion users. And since they are a 'everything app' the frequency of use and reliance is likely compounded.
Apple's not picking up the phone for 50 million users. So we shouldn't expect anything different here.
Luckily there are other phones and mobile os's to develop for.
Apple's huge problem here is - even though the get 50% more native app submissions this year - that these apps-in-apps (no matter how buggy they are) do not get them their predatory 30% Apple cut.
That being said, it is rumoured that Apple will make deal with the big one like Replit as long as these apps do not run on ios - they are going to keep profiting off that walled garden until it collapses.
This get brought up often, and it’s such a lazy example. Apple forces you to give them their cut (you have to pay for developer license even just to keep your own personal apps on your phone).
Valve's most anticompetitive rule is that steam keys you distribute outside steam shouldn't be sold for less than the price on steam. Would that Apple were the same.
I cannot get apps on my iPhone from anywhere else but the App Store. While they are dominant, Valve isn't locking anyone in even on their own hardware.
What does vibe coding add here? How is this any different than just arbitrary code execution on device, which is exactly what this gatekeeper rule covers?
(Not commenting on the rule, just want to see what’s new here)
Interesting that they’re not ok with that, but are completely fine with plenty of React Native and Flutter apps using OTA to update themselves without going through AppStore review like GM’s apps, Crypto.com and countless others
IANAL, but I think it means creating apps that stand alone outside their creator. I have a couple of linux VM's a-shell and iSH, but nothing runs outside of them.
At the end of the day, Apple is justifying this move as rule enforcement, but it's clear that the guidelines seem outdated in the context of rapidly advancing AI tools
The real problem for Apple here: in the fairly near future, the model of pre-defined functionality of software will be obsolete. All apps will be vibe coded and customized. Individual apps will basically be silos that protect proprietary data sources that are difficult to collect. But they will be infinitely more configurable than they are today.
I suspect any minute the first software with integrated AI customization will launch. Geeks will hate it, but regular folks will love trading all those god damn endless settings and menus for a simple prompt bar.
In an almost ironic twist, GUI will revert back to a "CLI".
Yeah but not everyone has the same priorities within those sliders. For example strength is something that has many different types. Tensile strength, compression strength, shearing etc.
You use different infills to optimise for each type. This differs per model. An AI can surely help optimise it but it won't always know which one to prioritize, it requires knowing exactly what the printed model will be used for.
The same with aesthetics, usually you care about one specific side. And for ease of remove, are you willing to use support interface material? That makes a lot of difference.
I think this comment actually makes the case for highly custom LLM modifications to software. If you have priorities, you express them to the model and let it figure out how to maximize the UI for your needs.
The article basically said it did launch and then Apple blocked it.
I’m really curious why I’m getting downvoted here. I fundamentally think that software is about to become 1000x more customizable and it’s a problem for the existing app model.
If I’m wrong, I want to know why. The thread seems to have a bias against AI slop (totally understandable), but in my experience it can one shot simple and functional apps today, and the technology will likely be able to make much better apps in the near future.
Is there an actual use-case for this fan-fiction-esque prediction of software that rewrites itself, or is this just promoting AI for the sake of promoting it only?
I get annoyed enough when software I use changes arbitrarily in ways that don't benefit me, I can't see LLM vibed software that changes itself based on what it thinks I need being an improvement at all. It just feels like it would be even more annoying.
My ideal software: buggy in ways you can't diagnose, for reasons you can't intuit, reproducible by literally no one in the world, and with no one to file a bug report to
Simply put, yes, there are many use cases. Concrete example: Various timers with a better interface for the specific task I want to do (meditate, pomodoro, workout, etc) and no ads.
There’s no reason I really need those four different apps on my phone with a login and ads and tracking and 100 page terms of service.
Claude can write them for me today. It’s be even better if I just ask my phone for them and they pop up in a couple minutes.
Apple's own Swift Playground app does the exact thing that supposedly violates the rules, abusing an inconsistently-applied exception for "educational" apps [1].
Recent regulation doesn't help here, by the way. iOS apps submitted for "notarization" to be distributed in alternative app stores in the EU, Japan, etc. still must comply with a subset of the guidelines, including 2.5.2. EU is probably not interested in strengthening the DMA so that Apple doesn't have to approve everything because then it makes other EU regulations easier to bypass (e.g. Chat Control).
Looks like YC wasted their money on this one, unless it's exempt because one of the founders used to work at Apple or something: https://news.ycombinator.com/item?id=45041185
[1] https://developer.apple.com/swift-playground/
The "educational" exception is definitely a convenient loophole, but it raises questions about consistency and fairness in how these rules are enforced across the board
It's refreshing that projects like https://grapheneos.org/ exist that let you take control of your device again at least to some degree.
It’ll be interesting to see if Apple comes around on customization of apps in general, because hopefully that’ll soon be what users expect.
In the world where users expect to be able to customize software more and more, apps start to look quite rigid and open platforms like the web that offer flexibility start to look more appealing.
Imagine a Lovable-style PWA that morphs into the app you vibecoded by storing the generated code in localStorage, for example - with cloud fallbacks to re-download the code if the storage is wiped.
That's funny to read this today morning because that's exactly what i've been working on.
We helped a Series B YC company with a whitelabel Lovable app so all of their customers can build exactly what they need on top of their SaaS!
It really works -- 1200 customers are now vibe coding daily and using their SaaS a LOT more.
Linux and Windows have always been a lot more customisable, Apple always was the more "we know better than you what you want" company... And they weren't wrong enough
> open platforms like the web
I winced. The threats to the open web at the moment are depressing.
It could probably store the code in the Cache API and serve it from a service worker so that it works offline and doesn't require evaling JavaScript
[dead]
[dead]
As I understand it, these apps allowed running custom code from the app, and that has always been disallowed.
Other than exceptions like Roblox
Maybe disallowed but definitely not enforced. There’s an app called Pythonista that has allowed you to run arbitrary python code for years.
I haven't been in the App Store ecosystem in a while, but the restriction is generally on running new Machine Code, all machine code needs to be signed on iOS. Interpreters get around this limitation, only the interpreter code that is compiled AoT and signed is actually running.
This tracks as the reasoning behind a lack of other browser engines, nobody can get comparable performance without a JIT, which would be compiling net new machine code that wasn't shipped with the binary.
The best way to handle this I would imagine within the current bounds of Apple's restrictions would be WASM.
Apps don't get removed for breaking that rule, though, because they can't break it in the first place. The system won't allow you to mark a freshly written page as executable.
Years ago I watched a bunch of people stop an apartment building from being built. They did this by employing a legal concern that they didn't actually care about, but that they knew would stop the development in its tracks. It worked.
That was the day I realized that for a lot of people, rules aren't actually rules. They're tools that they can use to stop something they don't like, no matter what the rule is really about.
I think this is a disgusting attitude, but it's unfortunately the way a lot of people operate.
So it might be that Apple has this "no external code" rule to stop things they don't like, and the category of "things Apple doesn't like" doesn't actually include every app that runs external code. It includes a lot of them, but for whatever reason Apple chose not to codify the details. Crummy if true, but I wouldn't be surprised. Every regulator I've ever dealt with leaves themselves an "I know it when I see it" escape hatch that lets them ban whatever they want.
If you read the actual rule the exceptions are relatively well defined. Stuff like pythonista falls into their educational/coding app exception as they define it
The entire rule is as follows:
Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the app completely viewable and editable by the user.
There are not "exceptions"; there is one exception, and that's educational apps. But it's unclear why Pythonista is educational while the apps mentioned in the article are not. In fact, Pythonista is even listed in the "Productivity" section in the App Store.
there are terminal type apps in the app store though?
Not sure why this is downvoted, it's true:
https://apps.apple.com/us/app/ish-shell/id1436902243
https://apps.apple.com/us/app/a-shell/id1473805438
Those are terminal emulators, not actual terminals. You can't fork or exec on iOS/iPadOS, so they're not actually running e.g. a python process, they're just running python interpreter.
ish runs a full blown x86 alpine linux distro.
As I understand it, ish implements x86 instructions and Linux syscalls as functions and translates running programs into arrays of calls to these functions, so all the machine code that will ever run is included in the app bundle, which at least satisfies the rules iOS enforces at runtime.
As for the rules as written, I suppose you could make reasonable arguments either way.
Not entirely. There is scriptable which allows you to run custom JS
>"and that has always been disallowed".
And it's always been a stupid rule. If I ship an app with a browser view, I can run any custom code I want in it. The rule is just a bandaid on Apple's lack of true sandboxing for apps.
> The rule is just a bandaid on Apple's lack of true sandboxing for apps.
That's not it at all. If an app can run arbitrary code then it can run other apps and that can by-pass the app store. They are specifically trying to prevent something like Wechat on the iPhone. It's not about security, it's about money and control.
Wechat works on iPhone
Wechat is large enough to be able to negotiate requirements with Apple. They are the gateway to an entire continent and close to 2 Billion users. And since they are a 'everything app' the frequency of use and reliance is likely compounded.
Apple's not picking up the phone for 50 million users. So we shouldn't expect anything different here.
Luckily there are other phones and mobile os's to develop for.
If we had to live with this rule during the "classic" Mac era, it would have disallowed HyperCard.
That's because browsers are the most battle tested sandbox out there. It's not worth developing another sandbox if they already have Safari webview.
> browsers are the most battle tested sandbox out there
The most battle tested sandbox... after operating system. After all, browsers rely on the OS to provide the primitives for their sandboxes.
And curiously those primitives are not exposed by iOS.
What's lacking in the sandboxing?
[dead]
Apple's huge problem here is - even though the get 50% more native app submissions this year - that these apps-in-apps (no matter how buggy they are) do not get them their predatory 30% Apple cut.
That being said, it is rumoured that Apple will make deal with the big one like Replit as long as these apps do not run on ios - they are going to keep profiting off that walled garden until it collapses.
Know the workplace rules!
Steam: We take a 30% cut of profits on our store. Devs: Aww you're so sweet.
Apple: We take a 30% cut of profits on our store. Devs: Hello? Human resources?
This get brought up often, and it’s such a lazy example. Apple forces you to give them their cut (you have to pay for developer license even just to keep your own personal apps on your phone).
Valve isn’t forcing you to use Steam.
Valve's most anticompetitive rule is that steam keys you distribute outside steam shouldn't be sold for less than the price on steam. Would that Apple were the same.
Which does not actually seem anticompetitive at all.
I cannot get apps on my iPhone from anywhere else but the App Store. While they are dominant, Valve isn't locking anyone in even on their own hardware.
Steam doesn't prevent me from running other games on my pc.
[dead]
Apple's primary concern is control over the revenue stream
What does vibe coding add here? How is this any different than just arbitrary code execution on device, which is exactly what this gatekeeper rule covers?
(Not commenting on the rule, just want to see what’s new here)
The only thing it changes is the audience. Developers are an insanely small subset of iPhone users but these applications are targeting everyone else.
Interesting that they’re not ok with that, but are completely fine with plenty of React Native and Flutter apps using OTA to update themselves without going through AppStore review like GM’s apps, Crypto.com and countless others
IANAL, but I think it means creating apps that stand alone outside their creator. I have a couple of linux VM's a-shell and iSH, but nothing runs outside of them.
At the end of the day, Apple is justifying this move as rule enforcement, but it's clear that the guidelines seem outdated in the context of rapidly advancing AI tools
iOS developers everywhere: "good"
"One more day where I get to use llm to code but still avoid being replaced myself"
The real problem for Apple here: in the fairly near future, the model of pre-defined functionality of software will be obsolete. All apps will be vibe coded and customized. Individual apps will basically be silos that protect proprietary data sources that are difficult to collect. But they will be infinitely more configurable than they are today.
I suspect any minute the first software with integrated AI customization will launch. Geeks will hate it, but regular folks will love trading all those god damn endless settings and menus for a simple prompt bar.
In an almost ironic twist, GUI will revert back to a "CLI".
Yeah, I've been wondering what this might look like for a 3D printer slicer --- heck, I'd be glad to just have a series of sliders:
- aesthetic print quality
- dimensional accuracy
- strength
- ease of removing supports
- reliability of printing
which resolve to two values which estimate:
- print time
- volume of material used/consumed in supports
Yeah but not everyone has the same priorities within those sliders. For example strength is something that has many different types. Tensile strength, compression strength, shearing etc.
You use different infills to optimise for each type. This differs per model. An AI can surely help optimise it but it won't always know which one to prioritize, it requires knowing exactly what the printed model will be used for.
The same with aesthetics, usually you care about one specific side. And for ease of remove, are you willing to use support interface material? That makes a lot of difference.
I think this comment actually makes the case for highly custom LLM modifications to software. If you have priorities, you express them to the model and let it figure out how to maximize the UI for your needs.
Yes indeed but not as sliders IMO, that was my point
The article basically said it did launch and then Apple blocked it.
I’m really curious why I’m getting downvoted here. I fundamentally think that software is about to become 1000x more customizable and it’s a problem for the existing app model.
If I’m wrong, I want to know why. The thread seems to have a bias against AI slop (totally understandable), but in my experience it can one shot simple and functional apps today, and the technology will likely be able to make much better apps in the near future.
Is there an actual use-case for this fan-fiction-esque prediction of software that rewrites itself, or is this just promoting AI for the sake of promoting it only?
I get annoyed enough when software I use changes arbitrarily in ways that don't benefit me, I can't see LLM vibed software that changes itself based on what it thinks I need being an improvement at all. It just feels like it would be even more annoying.
My ideal software: buggy in ways you can't diagnose, for reasons you can't intuit, reproducible by literally no one in the world, and with no one to file a bug report to
I love the idea of all software everywhere involving a die roll. Sounds like it'll be even more infuriating than most computing is right now.
The BOFH is grinning in his cave.
Simply put, yes, there are many use cases. Concrete example: Various timers with a better interface for the specific task I want to do (meditate, pomodoro, workout, etc) and no ads.
There’s no reason I really need those four different apps on my phone with a login and ads and tracking and 100 page terms of service.
Claude can write them for me today. It’s be even better if I just ask my phone for them and they pop up in a couple minutes.
I feel like I could write this in an afternoon with basic HTML. React if you want your phone to also act as a heating pad.