Editing Apple App Store

''I started writing this 6 months ago and didn't really finish it. Feel free to use it as a starting point for an article. Hopefully it's not too technical.''

Writing down some anti-consumer standards Apple has, which in my opinion aren't getting the coverage they deserve from lawmakers. Apple is good at obscuring their intentions with technical roadblocks, typically citing security reasons, or just hoping nobody notices or asks in the first place.

== Background info ==
Important terms you'll run into in this article:

* [[wikipedia:Sandbox (computer security)|Sandbox]]: Reduces exposure of the user's device/data to security risks, by reducing what an app is allowed to do.
* [https://theapplewiki.com/wiki/Entitlements Entitlements]: Apple's method of "poking holes" in the sandbox, to give the app more permissions. Some are available to developers, while many are only available to Apple.
* [[wikipedia:Digital Markets Act|Digital Markets Act]]: The European Union's fairly sweeping recent regulations against forcing companies they classify as "gatekeepers" to play nice, giving smaller businesses access to software/hardware features they've historically reserved for their own use.

== Notarization ==
Since 2015, Apple expects all Mac apps to be "notarized". This is a preliminary, automated malware check, which upon passing, provides a notary certificate that gets "stapled" to the app. Apple's explanation:

<blockquote>
Notarization of macOS software is not App Review. The Apple notary service is an automated system that scans your software for malicious content, checks for code-signing issues, and returns the results to you quickly. If there are no issues, the notary service generates a ticket for you to staple to your software; the notary service also publishes that ticket online where Gatekeeper can find it.<ref>https://developer.apple.com/documentation/security/notarizing-macos-software-before-distribution</ref>
</blockquote>

Whether this is actually a better approach than used by Windows antivirus, where they find out about new malware samples only when they end up on a user's computer, is a separate topic.

To comply with the DMA's regulations on app marketplaces, Apple created a new channel of releasing apps outside of the iOS App Store. Apps go through a notarization process. But the process is definitely ''not'' notarization. The name is intentionally being abused, by contrast to notarization on macOS, to make you believe it is something other than the existing App Review system. Despite the pain some developers and users have with it, notarization on macOS has always been considered a net positive. It made sense to take advantage of its reputation for the entirely different "notarization" on iOS.

See for yourself - view the [https://developer.apple.com/app-store/review/guidelines/ App Review Guidelines] and tick "Show Notarization Review Guidelines Only". While most rules are knocked out by this, a good number of them are still in place. These apps are still reviewed and tested by the App Review team, must have a full product listing in App Store Connect, and can be outright rejected - all in the same way as an App Store app.

By contrast, all that is required for notarization on macOS is for your app to not be malware. You submit it to an automated system that approves it within minutes. '''You don't need to convince Apple your app is worthy of existing on their platform.'''

The point of macOS notarization is that Apple has a record of all binaries that are intended for wide distribution on macOS, and can review them both in advance and on a regular basis for known malware/common malware patterns. Say a malware app manages to initially get through, when Apple finds out, they can go back in the notary records and find every sample of that malware to analyze and block. This is purely a technical process, managed by skilled security researchers, while iOS app review and "notarization" is a business process, managed by workers who have been given a checklist of violations to look for.

Apple is retaining complete control over what's allowed to run on iOS. On macOS, you can choose to run apps that have not been notarized (even though the process to bypass the warning is intentionally difficult). On iOS, you never get even that option. What Apple created is the App Store but with more steps. It still goes on the App Store, just hidden so it can only be installed by the third-party store it's tied to.

* [https://twitter.com/mysk_co/status/1806638308455256242 Mysk: iOS should enable alternative marketplaces to add their own links when users share their apps. Links still point to the App Store and if the app is not available there, this happens.]

== JIT ==
Safari is allowed to [[wikipedia:Just-in-time compilation|just-in-time]] compile code worldwide. The super short version of what that means: it can run JavaScript code ''really fast''. All browsers, and other runtimes like Microsoft .NET, Java, Lua use this. Ok, fine, it's the system web browser, it's very carefully written to be secure, and it's important to the platform to be doing well in performance benchmarks and all that.

Apple's [https://apps.apple.com/app/swift-playgrounds/id908519492 Playgrounds] app on iPad is also allowed to JIT. It bundles Apple's [[wikipedia:Swift (programming language)|Swift]] compiler, and shares backend code with the version of Playgrounds found in [[wikipedia:Xcode|Xcode]].

Competing apps like Pythonista (a Python IDE), emulators like Delta and UTM, and terminal environments like iSH, are not allowed to JIT. As such, they need to rely on inferior performance, potentially from an entirely separate implementation of their compiler/interpreter that may be less proven, because the JIT-less implementation doesn't need to exist on any other platform.

Likely the most clear example is UTM SE. UTM is a port of the [[wikipedia:QEMU|QEMU]] emulator to iOS, allowing you to run desktop OSes (Linux, Windows 98, XP, classic Mac OS, etc). iPhone hardware is very capable these days and it runs impressively well, ''if'' you use a hack to enable JIT (which Apple has now patched). "SE" stands for "slow edition" - yes, really. If you compare the true version of UTM to the App Store UTM SE app, you ''will'' feel the loss in performance. It's impressive UTM even got to be on the App Store at all, and the DMA is to thank for it. But Apple is still holding the line on allowing JIT to apps that require that performance.

While UTM SE releasing at all might seem like a pathway to getting Firefox and Chrome "slow editions" on the App Store, browser engines other than the built-in Apple WebKit/JavaScriptCore are [https://developer.apple.com/app-store/review/guidelines/#2.5.6 still outlawed]. In the EU, Apple has blessed web browser JavaScript engines with the option to use JIT. The app must be approved for an entitlement, and then must work within APIs provided by Apple for it. As of January 2025, no browsers have been released using this. We were all anticipating proper competition around web browsers on iOS, but almost a year later, we have nothing. Mozilla has [https://www.theverge.com/2024/1/26/24052067/mozilla-apple-ios-browser-rules-firefox discussed] why.

== Sandbox ==
You might not like app sandboxing, but it's a powerful security feature used on all modern platforms. The reality is very few apps need more than a few basic permissions. [[wikipedia:Flatpak|Flatpak]] on Linux also sandboxes apps, and it seems to work great! Still, it's completely fair that there should be processes for doing things beyond what the sandbox allows. You see some of this with permission prompts - does a flashlight app ''really'' need access to your contacts? (Apple has been burned by [https://www.theverge.com/2012/2/14/2798008/ios-apps-and-the-address-book-what-you-need-to-know apps abusing their kindness] before.)

It can go further than this. As we established in previous sections, an app can be given more access to features of the system using entitlements. These come in a few flavors:

* Completely safe: Entitlements any developer can opt into, with little to no risk.
* Approval required: Entitlements that might be more of a security risk to allow, e.g. giving considerably wider access to the system, or that Apple simply doesn't want to hand out to just ''anyone'' for competitive reasons. The developer must submit a request to Apple with evidence of why they need the entitlement.
* Private: Entitlements that are never allowed for any app developer to use. Many of these are reasonably fenced off because they handle user data that is very risky, or bypasses permission prompts, etc, but can just as well also be guarding features Apple wants to keep to itself.

There have been [https://gizmodo.com/researchers-uber-s-ios-app-had-secret-permissions-that-1819177235 exceptions] where Apple quietly gave a company access to private entitlements anyway, raising eyebrows.

On iOS, you also can't be ''more'' secure than the default sandbox. That might seem crazy, but it's pretty important for security in a variety of situations. On macOS, there are several entitlements you must declare to decide whether you're allowed to access certain types of user data at all. Android echoed this design from the very start - you can't even do fairly fundamental things like access the internet without declaring it in your manifest. It makes it very clear what the app intends to do.

iOS has one sandbox used by all App Store apps. System apps, and App Store apps developed by Apple, are allowed to expand or reduce their sandbox permissions as needed. Third-party apps do not get the right to expand or reduce their sandbox permissions at all. This is clearly less secure. To take the example of Playgrounds again, while it's allowed to run your code from a separate process executing in an ultra locked down sandbox with very few permissions, competing apps such as Pythonista must run your code entirely in the same sandbox and address space as the main app process. The Python interpreter crashing would therefore crash the entire app, possibly losing work. In the worst case, a vulnerability in third-party code could give access to all data stored by/accessible to the app. If that third-party code could run in its own limited sandbox, the risk is significantly reduced.

The only known workaround is to execute the code via JavaScript, as Apple's JavaScriptCore engine runs in a heavily sandboxed process. This requires you to port the code to JS, which may be a lot of work, or just not viable. You wouldn't want to run the Python interpreter inside JavaScript - the performance would be terrible!

== In-app browsers ==
Safari's in-app browser, that is the minimal version you get when tapping a link from social media, uses an entirely separate data store for each app. The in-app browser isn't aware of cookies in the "full" Safari app, or any other app, and doesn't support Safari extensions. Any websites you're logged into. Apple [https://github.com/openid/AppAuth-iOS/issues/120 claimed] this was to protect malicious apps from stealing or setting cookies in Safari without your knowledge, which is a fair argument, but it's hard to not notice that it makes web browsing inconvenient, encouraging users to install native apps, where they can make transactions through Apple.

This also means your browsing in the in-app browser is just forgotten - there's no history menu, and it doesn't get logged to the history in the full Safari app either. Good luck recalling that article you read a few weeks ago.

== See also ==
* [https://theapplewiki.com/wiki/Eligibility Eligibility]
* [https://adamdemasi.com/2024/04/19/app-marketplace-experience.html The iOS 17.4 app marketplace flow is a disaster]
* [https://adamdemasi.com/2024/04/23/ios-eligibility-features.html Features controlled by iOS 17.4’s eligibility system]

== References ==
<references />