--- title: Compatibility description: Select a platform below to view the supported operating systems and browsers. component: sdks version: latest page_id: sdks:oidc:compatibility canonical_url: https://docs.pingidentity.com/sdks/latest/oidc/compatibility.html revdate: Tue, 20 May 2023 16:11:17 +0100 keywords: ["Compatibility", "Features", "Source Code", "SDK"] section_ids: supported-os: Supported operating systems and browsers compatibility_with_in_app_browsers_and_webviews: Compatibility with in-app browsers and WebViews WebView: WebViews In-App-Browser: In-App Browsers iOS-In-App-Browsers:-Key-Differences: In-app browser implementation on iOS SFSafariViewController: SFSafariViewController ASWebAuthenticationSession: ASWebAuthenticationSession summary_of_ios_in_app_browser_implementations: Summary of iOS in-app browser implementations --- # Compatibility ## Supported operating systems and browsers Select a platform below to view the supported operating systems and browsers. * Android * iOS * JavaScript The Ping (ForgeRock) SDK for Android supports the following versions of the Android operating system: **Supported Android versions and original release dates** | Release | API Levels | Released | | --------------- | ---------- | --------------- | | Android 16 | 36 | August, 2025 | | Android 15 | 35 | September, 2024 | | Android 14 | 34 | October, 2023 | | Android 13 | 33 | March, 2022 | | Android 12 | 31, 32 | October, 2021 | | Android 11 | 30 | September, 2020 | | Android 10 | 29 | September, 2019 | | Android 9 (Pie) | 28 | August, 2018 | | | | | - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | We are updating how we determine which Android versions form our support policy for the Ping (ForgeRock) SDK for Android.From **March 1st, 2025**, the support policy is as follows:- Every public major release of Android within the last 6 years. For example, this would mean support for **Android 9** (API level 28) and later versions. | **Supported browsers on Android** * Chrome - Two most recent major versions. The Ping (ForgeRock) SDK for iOS supports the following versions of the iOS operating system: **Supported iOS versions and original release dates** | Release | Released | | ------- | --------------- | | iOS 18 | September, 2024 | | iOS 17 | September, 2023 | | iOS 16 | September, 2022 | | | | | - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | We are updating how we determine which iOS versions form our support policy for the Ping (ForgeRock) SDK for iOS.From **March 1st, 2025**, the support policy is as follows:- Every public major release of iOS within the last 3 years. For example, this would mean support for **iOS 16** and later versions. | **Supported browsers on iOS** * Safari - Two most recent major versions. The Ping (ForgeRock) SDK for JavaScript supports the [desktop](#js-desktop-browsers) and [mobile](#js-desktop-browsers) browsers listed below. **Minimum supported Desktop browser versions** * Chrome 83 * Firefox 77 * Safari 13 * Microsoft Edge 83 (Chromium) **Supported Mobile browsers** * iOS (Safari) - Two most recent major versions of the operating system. * Android (Chrome) - Two most recent major versions of the operating system. ## Compatibility with in-app browsers and WebViews Native Android and iOS applications use two main methods for opening a website or web app: 1. [WebViews](#WebView) 2. [In-App Browsers](#In-App-Browser) The Ping (ForgeRock) SDKs for Android and iOS use an in-app browser when authenticating using OIDC sign-on, rather than a WebView. Understanding the distinction between WebViews and in-app browsers is critical for security and user experience, and explains why the Ping (ForgeRock) SDKs use an in-app browser by default. ### WebViews A WebView is a component that renders web pages as an integrated part of your native app's UI. | | | | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Control | Your app has extensive control over a WebView. It can inspect traffic, inject JavaScript, and access content.You can set headers, URL parameters, and cookies in the requests. | | Context | WebViews run in the same process as your app, sharing memory and resources.The WebView does **not** share cookies or sessions with the device's default browser. | | Security | As the app can manipulate the WebView, it is considered **less secure** for handling sensitive authentication redirects.An attacker who compromises the app could potentially intercept credentials. | | Compatibility | WebViews don't support the entire web specification.Advanced features like **WebAuthn** and **Passkeys** do **not** work. | ### In-App Browsers In-app browsers appear separated from your native app's user interface, often creating their own window to open the website or web app. In-app browsers are platform-recommended components such as **Chrome Custom Tabs** on Android, and **SFSafariViewController** and **ASWebAuthenticationSession** on iOS. | | | | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Control | Your app has minimal control over an in-app browser window. It can't inspect the content or inject scripts.It essentially hosts a sandboxed, secure browser tab. | | Context | An in-app browser runs as a separate, secure process.Critically, certain components like `ASWebAuthenticationSession` and Chrome Custom Tabs share the cookie jar with the device's default browser, for example `Safari` or `Chrome`.This sharing of cookies is the key mechanism for enabling Web SSO. | | Security | This separation between the app and the in-app browser makes it the most secure and recommended option for user authentication flows.It prevents the host app from interfering with the login process. | | Compatibility | In-App browsers are fully-featured browsers that run on the same engine as Safari and Chrome.Features like **WebAuthn** and **Passkeys** are fully supported. | #### In-app browser implementation on iOS On iOS there are two main implementations of in-app browsers; `SFSafariViewController` and `ASWebAuthenticationSession`. This section outlines some of the differences between the two iOS implementations. ##### SFSafariViewController The `SFSafariViewController` implementation is designed to display general web content within your app while maintaining a secure, sandboxed environment. | | | | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Cookie storage | Since iOS 11, `SFSafariViewController` **does not** share cookies with the native Safari browser.If a user is logged into a website on Safari, they will **not** be logged in when that same site is opened by using `SFSafariViewController`. | | SSO within the same app | Instances of `SFSafariViewController` within the same app **do share** a cookie store.This means if you have multiple `SFSafariViewController` instances in your application, they can maintain a consistent session, but this session is sandboxed to your app only. | | Other storage | Instances of `SFSafariViewController` share their own data store for `localStorage` and `sessionStorage`, which is separate from the native Safari browser. | | Use case | Ideal for displaying external, non-authentication-related web pages. | ##### ASWebAuthenticationSession The `ASWebAuthenticationSession` implementation is a specialized API built for handling authentication flows like OAuth 2.0. It is the recommended and most secure method for logging a user in to a web app. | | | | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Cookie Storage | It shares cookies and website data with the native Safari browser by default.This cookie sharing enables a seamless web SSO experience. | | Ephemeral sessions | You can optionally configure it using the `prefersEphemeralWebBrowserSession` property to start with a clean slate each time.This prevents it from sharing any existing cookies, and it discards any new ones after the session. | | UI and consent | The `ASWebAuthenticationSession` implementation presents a clear, recognizable, non-customizable system dialog to the user, informing them that your app is about to use a specific website to sign them in.This explicit user consent is a critical security feature. | | Use case | The only appropriate choice for handling third-party login flows, such as signing in with through your Ping Identity solutions. | ##### Summary of iOS in-app browser implementations The following table summarizes the key differences between the two iOS implementations of an in-app browser: | Feature | `SFSafariViewController` | `ASWebAuthenticationSession` | | ----------------------------- | ------------------------------------------------------------------ | ---------------------------------- | | Primary Use Case | Displaying general web content | User authentication flows (OAuth) | | Ephemeral Session Option | No | Yes | | Shares Cookies with Safari | No (iOS 11+) | Yes (unless ephemeral) | | Shares Other Data with Safari | No (iOS 11+) | Yes (unless ephemeral) | | Data Returned to App | Nothing (Custom schemes are possible but not recommended for auth) | Callback URL with tokens and codes | | UI Customization | Minimal (tint color) | None (System-provided alert) |