Apple App Store: Difference between revisions
→Epic Games: Typo |
added summary for less technical users |
||
| (8 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
{{ToneWarning}} | |||
[[File:App Store (iOS).svg|thumb|150px]] | [[File:App Store (iOS).svg|thumb|150px]] | ||
| Line 40: | Line 41: | ||
{{hatnote|See also: [[wikipedia:Epic Games v. Apple|Epic Games v. Apple]] and [[wikipedia:Epic Games v. Google|Epic Games v. Google]]}} | {{hatnote|See also: [[wikipedia:Epic Games v. Apple|Epic Games v. Apple]] and [[wikipedia:Epic Games v. Google|Epic Games v. Google]]}} | ||
[[Epic Games]] is a video game developer and publisher, known for games such as [[Fortnite]] and [[Unreal Tournament]], the [[Unreal Engine]], and the [[Epic Games Store]]. | [[Epic Games, Inc.]] is a video game developer and publisher, known for games such as [[Fortnite]] and [[Unreal Tournament]], the [[Unreal Engine]], and the [[Epic Games Store]]. | ||
In 2018, Epic Games launched Fortnite on the iOS and Android platforms. The company made the unusual decision to not release the app on the [[Google Play Store]] - rather, it was made available as a standalone [[wikipedia:apk (file format)|Android app package]] file (.apk), which must be installed by following a series of manual steps.<ref>{{Cite web |last=Statt |first=Nick |date=3 Aug 2018 |title=Fortnite for Android will ditch Google Play Store for Epic’s website |url=https://www.theverge.com/2018/8/3/17645982/epic-games-fortnite-android-version-bypass-google-play-store |url-status=live |access-date=1 May 2025 |website=[[The Verge]]}}</ref> The app was also released on the [[Samsung]] [[Samsung Galaxy Store|Galaxy Store]]. Google offered a $147 million deal for Epic Games to release Fortnite on the Play Store, which the company declined.<ref>{{Cite web |last=Robertson |first=Adi |date=9 Nov 2023 |title=Google offered Epic $147 million to launch Fortnite on the Play Store |url=https://www.theverge.com/2023/11/8/23953262/google-epic-fortnite-play-store-investment-antitrust-trial |url-status=live |access-date=1 May 2025 |website=[[The Verge]]}}</ref> | In 2018, Epic Games launched Fortnite on the iOS and Android platforms. The company made the unusual decision to not release the app on the [[Google Play Store]] - rather, it was made available as a standalone [[wikipedia:apk (file format)|Android app package]] file (.apk), which must be installed by following a series of manual steps.<ref>{{Cite web |last=Statt |first=Nick |date=3 Aug 2018 |title=Fortnite for Android will ditch Google Play Store for Epic’s website |url=https://www.theverge.com/2018/8/3/17645982/epic-games-fortnite-android-version-bypass-google-play-store |url-status=live |access-date=1 May 2025 |website=[[The Verge]]}}</ref> The app was also released on the [[Samsung]] [[Samsung Galaxy Store|Galaxy Store]]. Google offered a $147 million deal for Epic Games to release Fortnite on the Play Store, which the company declined.<ref>{{Cite web |last=Robertson |first=Adi |date=9 Nov 2023 |title=Google offered Epic $147 million to launch Fortnite on the Play Store |url=https://www.theverge.com/2023/11/8/23953262/google-epic-fortnite-play-store-investment-antitrust-trial |url-status=live |access-date=1 May 2025 |website=[[The Verge]]}}</ref> | ||
| Line 82: | Line 83: | ||
</gallery> | </gallery> | ||
A similar case occurred with the app Fanhouse in 2021.<ref>{{Cite web |last=@jasminericegirl |date=9 Jun 2021 |title=#fuckapple, a thread | A similar case occurred with the app Fanhouse in 2021.<ref>{{Cite web |last=@jasminericegirl |date=9 Jun 2021 |title=#fuckapple, a thread I cofounded @fanhouseapp 8 months ago to empower creators to monetize their content. We pay creators 90% of earnings. Now, Apple is threatening to remove Fanhouse from the app store unless we give them 30% of creator earnings. This is theft and exploitation. |url=https://x.com/jasminericegirl/status/1402691047940100100 |access-date=16 Mar 2025 |website=[[X]]}}</ref> | ||
I cofounded @fanhouseapp | |||
===Twitter=== | ===Twitter=== | ||
| Line 111: | Line 110: | ||
==JIT== | ==JIT== | ||
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. | |||
[[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. | |||
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]]. | |||
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. | |||
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== | ||
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. | |||
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 | *'''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 | 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. | ||