Consumer Rights Wiki

Apple App Store: Difference between revisions

← Older edit
VisualWikitext
Rain (talk | contribs)
confirmed
73 edits
m Removed line breaks.
Emayeah (talk | contribs)
confirmed
16 edits
added summary for less technical users
 
(6 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{ToneWarning}}
[[File:App Store (iOS).svg|thumb|150px]]
[[File:App Store (iOS).svg|thumb|150px]]


Line 109: Line 110:


==JIT==
==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.
The following paragraph is highly technical, if it's too technical for you to understand all you need to know is that: JIT allows for extremely fast programs/apps and due to its fast nature it's used almost everywhere, and is a massive improvement over older code interpreters.


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]].
[[wikipedia:Just-in-time compilation|JIT]], which stands for Just-In-Time, is a method of code execution where code, instead of being compiled before being distributed (like an EXE), gets compiled into machine code in real time right before being executed. This method of code execution allows for much faster website loading times, faster emulation, faster program execution (with programs written in JavaScript, Python, Lua...) compared to interpreters, which instead translates code into machine code line by line, which is much, much slower; JIT also employs many more optimization techniques meant to improve performance.


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.
Safari is allowed to use JIT to compile code from any site, same with Apple's [https://apps.apple.com/app/swift-playgrounds/id908519492 Playgrounds] app on iPad. Playgrounds bundles Apple's [[wikipedia:Swift (programming language)|Swift]] compiler, and shares backend code with the version of Playgrounds found in [[wikipedia:Xcode|Xcode]].


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.
Third-party apps like Pythonista (a Python IDE), emulators like Delta and UTM and terminal environments like iSH are not allowed to use JIT, instead having to interpret code, which comes with serious performance degradation and is more computationally expensive, potentially draining more battery.


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 still outlawed.<ref>{{Cite web |title=App Review Guidelines |url=https://developer.apple.com/app-store/review/guidelines/#2.5.6 |url-status=live |access-date=16 Mar 2025 |website=[[Apple Developer]]}}</ref> 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.<ref>{{Cite web |title=Mozilla says Apple’s new browser rules are ‘as painful as possible’ for Firefox |url=https://www.theverge.com/2024/1/26/24052067/mozilla-apple-ios-browser-rules-firefox |url-status=live |access-date=16 Mar 2025 |website=[[The Verge]]}}</ref>
An example of apps being heavily affected by this restriction is UTM. UTM is a port of [[wikipedia:QEMU|QEMU]] for iOS, iPadOS and MacOS, allowing users to create [[wikipedia:Virtual_machine|VMs]] that can run various OSes, for example Microsoft Windows. The iPhone's hardware capable enough to emulate various modern OSes at full speed, but due to Apple's JIT limitation, the team behind UTM had to create UTM SE (slow edition) that doesn't require JIT, but is nowhere near as fast as UTM with JIT, only being capable of running MS-DOS and derivatives at acceptable speeds. While methods that enable JIT for apps other than Safari and Playgrounds exist (some currently working on iOS 18.5, like [https://apps.apple.com/us/app/stikdebug/id6744045754 StikDebug]), Apple does not allow the use of JIT in notarized apps, meaning that apps that support JIT will have to be sideloaded, which comes with its own set of restrictions.
 
In the EU, Apple gave web browsers permission to use rendering and JavaScript engines other than the built-in with Apple WebKit/JavaScriptCore, with the option for JS engines to use JIT. The browser still has to be approved by Apple for an entitlement, and then must work within APIs provided by Apple for it. But, as of January 2025, no browsers that use different engines than the built-in ones have been released, mainly due to arbitrarily imposed restrictions, meant to discourage the usage and development of third-party engines.<ref>{{Cite web |title=Mozilla says Apple’s new browser rules are ‘as painful as possible’ for Firefox |url=https://www.theverge.com/2024/1/26/24052067/mozilla-apple-ios-browser-rules-firefox |url-status=live |access-date=16 Mar 2025 |website=[[The Verge]]}}</ref>
 
However, Apple still does not allow different engines outside of the EU, with or without JIT support.<ref>{{Cite web |title=App Review Guidelines |url=https://developer.apple.com/app-store/review/guidelines/#2.5.6 |url-status=live |access-date=16 Mar 2025 |website=[[Apple Developer]]}}</ref>  


==Sandbox==
==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 apps abusing user data before the current permission system was built out.<ref>{{Cite web |last=Bohn |first=Dleter |date=15 Feb 2012 |title=iOS apps and the address book: who has your data, and how they’re getting it |url=https://www.theverge.com/2012/2/14/2798008/ios-apps-and-the-address-book-what-you-need-to-know |url-status=live |access-date=16 Mar 2025 |website=[[The Verge]]}}</ref>)
Sandboxing is a powerful security feature used on all modern platforms, from Windows to iOS, and it's used because most programs need only a few basic permissions. While sandboxing is a great security measure, sometimes users may want to develop or create programs that run outside of the sandbox, with less restrictions. When a program needs extra permissions outside of what the sandbox normally allows, the user is prompted with a permission prompt, useful when some very basic programs (like a flashlight app) need access to sensitive information like contacts.


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:
As established in previous sections, a program can be given more access to features of the system using entitlements. These come in different types:


*'''Completely safe''': Entitlements any developer can opt into, with little to no risk.
*'''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.
*'''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.
*'''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 and so on, 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.
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 if you're not a developer, 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 used this design from the very start - you can't even do fundamental things like access the internet without declaring it in your manifest. It makes it very explicit what the app's intentions are.
On iOS, you also can't be ''more'' secure than the default, strictest sandbox. 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 used this design from the very start - you can't even do fundamental things like access the internet without declaring it in your manifest. It makes it very explicit what the app's intentions are.


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 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. For example, it would be a nightmare if you can tap the wrong link in Safari and have a hacker easily steal your cookies from other websites. If that third-party code could run in its own limited sandbox, the risk is significantly reduced.
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 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. For example, it would be a nightmare if you can tap the wrong link in Safari and have a hacker easily steal your cookies from other websites. If that third-party code could run in its own limited sandbox, the risk is significantly reduced.
Retrieved from "https://consumerrights.wiki/w/Apple_App_Store"