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
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.
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.
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.
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.
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.
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.
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.
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.
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.
I winced. The threats to the open web at the moment are depressing.
(Not commenting on the rule, just want to see what’s new here)
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.
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?
Valve isn’t forcing you to use Steam.
In an almost ironic twist, GUI will revert back to a "CLI".
- 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
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’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.
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.
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.