Ping SDKs

Compatibility

Supported operating systems and browsers

Select a platform below to view the supported operating systems and browsers.

  • Android

  • iOS

  • JavaScript / Login Widget

The Ping 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 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 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 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 SDK for JavaScript, and the Ping (ForgeRock) Login Widget support the desktop and mobile 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

  2. In-App Browsers

The Ping 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 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)