Apple App Store: Difference between revisions

Line 131:

==In-app browsers==

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.

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 [[Web cookie|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.

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.

@@ Line 131: / Line 131: @@
 ==In-app browsers==
-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.
+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 [[Web cookie|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.
 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.