Apple App Store: Difference between revisions

Line 124:

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 |archive-url=https://archive.ph/D9fQQ |archive-date=7 Jan 2026 |access-date=16 Mar 2025 |website=[[Apple Developer]]}}</ref>

==In-app browsers==

Safari~~'s in-app~~ browser, ~~which 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~~. ~~Apple claimed this was to protect users from malicious apps stealing or setting cookies in Safari without their knowledge~~, ~~which is a fair argument~~. However, ~~it's hard not~~ to notice that it makes web browsing inconvenient, encouraging users to install native apps where they can make transactions through Apple.<ref>{{Cite web |last=@whitehatguy |date=12 Jun 2017 |title=Impact of iOS 11 no longer providing shared cookies between Safari, Safari View Controller instances |url=https://~~github~~.com/~~openid/AppAuth-iOS~~/~~issues~~/~~120 |url~~-~~status=live |archive~~-~~url=https://archive~~.~~ph/1ehTJ |archive-date=7 Jan 2026 |access-date=16 Mar 2025 |~~website~~=[[GitHub]]}}</ref>~~

When apps want to display web content without opening the standalone Safari browser, app developers can use Apple’s [https://developer.apple.com/documentation/webkit/ WebKit] APIs, such as WKWebView. However, due to Apple’s [https://developer.apple.com/documentation/security/app-sandbox application sandboxing] and WebKit’s data-isolation model, web content loaded inside one app does not have access to Safari’s cookies, browsing history, saved sessions, or extensions, nor to data from other apps’ embedded web views. Each app’s embedded browser operates with its own isolated website data store.

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

As a result, web pages opened inside embedded browsers, such as those used in apps like Facebook, do not appear in Safari’s browsing history, and there is typically no persistent, user-accessible history within the app itself. Users may also be asked to sign in to the same services (for example, during OAuth login flows like Google) because cookies and session data are not shared with Safari. Additionally, Safari extensions, including content blockers, dark-mode tools, and other privacy or accessibility extensions, do not function inside embedded web views.

Apple states App Sandboxing "provides protection to system resources and user data by limiting your app’s access to resources requested through entitlements."<ref>{{Cite web |date=2025-01-12 |title=App Sandbox {{!}} Apple Developer Documentation |url=https://developer.apple.com/documentation/security/app-sandbox |url-status=live |access-date=2025-01-12 |website=Apple Developer}}</ref> However, developers have voiced frustration with how WebKit is sandboxed which can result in degraded user experiences, such as with repeated OAuth login flows between apps.<ref>{{Cite web |date=2025-01-12 |title=Impact of iOS 11 no longer providing shared cookies between Safari, Safari View Controller instances |url=https://github.com/openid/AppAuth-iOS/issues/120 |url-status=live |access-date=2025-01-12 |website=GitHub}}</ref> Some developers have found workarounds for sharing information with the native Safari app, but it is unknown whether these methods still function in modern versions Apple's various operating systems.<ref>{{Cite web |last=Storey |first=Leon |date=2025-01-12 |title=Does WKWebView uses cookies from Safari? |url=https://stackoverflow.com/a/41486576 |access-date=2025-01-12 |website=StackOverflow}}</ref>

==See also==

@@ Line 124: / Line 124: @@
 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 |archive-url=https://archive.ph/D9fQQ |archive-date=7 Jan 2026 |access-date=16 Mar 2025 |website=[[Apple Developer]]}}</ref>
 ==In-app browsers==
-Safari's in-app browser, which 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. Apple claimed this was to protect users from malicious apps stealing or setting cookies in Safari without their knowledge, which is a fair argument. However, it's hard not to notice that it makes web browsing inconvenient, encouraging users to install native apps where they can make transactions through Apple.<ref>{{Cite web |last=@whitehatguy |date=12 Jun 2017 |title=Impact of iOS 11 no longer providing shared cookies between Safari, Safari View Controller instances |url=https://github.com/openid/AppAuth-iOS/issues/120 |url-status=live |archive-url=https://archive.ph/1ehTJ |archive-date=7 Jan 2026 |access-date=16 Mar 2025 |website=[[GitHub]]}}</ref>
+When apps want to display web content without opening the standalone Safari browser, app developers can use Apple’s [https://developer.apple.com/documentation/webkit/ WebKit] APIs, such as WKWebView. However, due to Apple’s [https://developer.apple.com/documentation/security/app-sandbox application sandboxing] and WebKit’s data-isolation model, web content loaded inside one app does not have access to Safari’s cookies, browsing history, saved sessions, or extensions, nor to data from other apps’ embedded web views. Each app’s embedded browser operates with its own isolated website data store.
-This also means that your browsing history in the in-app browser is lost; there's no history menu, and it is not logged to the history in the full Safari app either. Good luck recalling that article you read a few weeks ago.
+As a result, web pages opened inside embedded browsers, such as those used in apps like Facebook, do not appear in Safari’s browsing history, and there is typically no persistent, user-accessible history within the app itself. Users may also be asked to sign in to the same services (for example, during OAuth login flows like Google) because cookies and session data are not shared with Safari. Additionally, Safari extensions, including content blockers, dark-mode tools, and other privacy or accessibility extensions, do not function inside embedded web views.
+Apple states App Sandboxing "provides protection to system resources and user data by limiting your app’s access to resources requested through entitlements."<ref>{{Cite web |date=2025-01-12 |title=App Sandbox {{!}} Apple Developer Documentation |url=https://developer.apple.com/documentation/security/app-sandbox |url-status=live |access-date=2025-01-12 |website=Apple Developer}}</ref> However, developers have voiced frustration with how WebKit is sandboxed which can result in degraded user experiences, such as with repeated OAuth login flows between apps.<ref>{{Cite web |date=2025-01-12 |title=Impact of iOS 11 no longer providing shared cookies between Safari, Safari View Controller instances |url=https://github.com/openid/AppAuth-iOS/issues/120 |url-status=live |access-date=2025-01-12 |website=GitHub}}</ref> Some developers have found workarounds for sharing information with the native Safari app, but it is unknown whether these methods still function in modern versions Apple's various operating systems.<ref>{{Cite web |last=Storey |first=Leon |date=2025-01-12 |title=Does WKWebView uses cookies from Safari? |url=https://stackoverflow.com/a/41486576 |access-date=2025-01-12 |website=StackOverflow}}</ref>
 ==See also==