This article covers the following topics:
This document describes the product lifecycle and support terms of the following ForgeRock SDKs:
In total, ForgeRock has more than 250 libraries under its official GitHub page but it is out of scope for this document to address any of those libraries that are not listed above. For the rest of this document, ForgeRock SDKs refer to the four libraries called out above.
The ForgeRock SDKs are distributed via dependency managers with the intent to follow industry best practices and to provide the best possible developer experience to our customers. Instructions about how to obtain the SDK via this method is part of our documentation.
The SDKs are available in the following dependency managers:
Support for other dependency managers (for example, Swift Package Manager) are under consideration for the future with no committed timelines yet.
As an alternative to the dependency managers, customers can access the SDKs’ source code via GitHub:
The SDKs are released an estimated two to six times a year. Releases are triggered when:
- New SDK features and fixes are available that warrant a release.
- Defects causing production problems require an immediate fix and there is no known workaround that we can offer to our customers.
Example: ForgeRock iOS SDK 2.1.3, where:
- iOS - platform
- 2 - major version: major feature release, fixes, possible breaking changes.
- 1 - minor version: feature release, fixes, no breaking changes.
- 3 - patch: defect fixes that can’t wait for the next release and we don’t have a workaround that we can offer to our customers.
Alpha / Beta Releases
We use alpha and beta releases from time to time to encourage evaluation and early feedback.
Alpha and beta releases are not supported or otherwise subject to any warranty or other guarantee and are provided “as-is”. Alpha and beta releases should not be used in production. ForgeRock shall have no liability arising out of or related to any such use of alpha and beta releases.
Compatibility and Support
Earlier versions of the SDK
Our strategy is to encourage our customers to use the latest version of the SDK and make SDK upgrades extremely simple.
To achieve that, we do not introduce breaking changes in minor releases. If a breaking change is introduced in a major release, we document it in the Change Log together with the required upgrade steps.
This means, in most cases, the SDK can be upgraded to a minor version by replacing the old SDK library with the new one, without any additional effort.
Earlier versions of the Platform
We understand that our customers will upgrade their apps more often than their IAM infrastructure. Therefore, our goal is to enable customers to use the latest version of the SDK even if they run an older version of the ForgeRock platform.
For instance, the latest version of the SDK (2.1) was tested on:
- The ForgeRock Identity Cloud
- ForgeRock 7.0
- ForgeRock 6.5.2
Supported SDK Versions
The last two major versions of the SDK are supported.
|Example: If the latest version is 2.x, we will support 2.latest and 1.latest.|
Defects identified in any version of the SDK will be fixed only in our next release, if they are prioritized for that release.
We do not backport defect fixes or features to older versions of the SDK.
The ForgeRock iOS and Android SDKs are tested and supported in native iOS and Android applications on the following operating systems:
|Support matrix for SDK 2.1|
|Tested / Supported||OS Coverage|
|iOS||10, 11, 12, 13, 14||95% +|
|Android||5, 6, 7, 8, 9, 10, 11||~ 94.1%|
This support matrix is reevaluated at the time of every major release and operating system versions might be dropped if their adoption is no longer significant. Our guiding principle is that our goal is to support at least 95% of the devices globally.
Support of Major Platform Releases
A major iOS and Android release is the most anticipated event of the year for those in mobile app development. It is a critical time for application owners as oftentimes these new releases ship with breaking changes that can render apps unusable.
We understand the criticality of supporting these new operating system releases when they become available to end-users therefore our goal is to support them (with the SDKs), as soon as possible, preferably on the day of the release.
We take the following actions to avoid last minute surprises:
- We test the SDKs with iOS/Android beta releases.
- If we identify that the new iOS/Android release will break the SDKs:
- We notify our customers ahead of time.
- We prepare a new SDK release that addresses the incompatibility.
With all that said, we have seen examples of Apple and Google introducing breaking changes in their final releases without any warning or indication for the change in preceding beta releases. In such (rare) cases, we will issue a compatible SDK version as soon as possible.
The SDKs should work in apps developed with hybrid technologies (for example, Cordova, Xamarin, React Native, and so on.) but ForgeRock does not provide the wrapper / bridging code / documentation that is necessary for the integration (with these apps) and does not test or support these development stacks.
ForgeRock is continuously assessing the demand and feasibility of supporting these technologies in the future; therefore they are in the “Under Consideration” section of our roadmap.
The SDKs can behave unexpectedly and are not supported on devices that are rooted, jailbroken, or run a custom ROM (a “Tampered Device”). We discourage our customers to support such devices as their security posture might be compromised. ForgeRock shall have no liability arising out of or related to any such use of SDKs on a Tampered Device.
The ForgeRock SDKs will not function in Internet Explorer 11 and Legacy Edge. You can use polyfills as described here to achieve compatibility with these legacy browsers.
The ForgeRock SDKs allow a great degree of customization and have many extension points. ForgeRock will use reasonable efforts to support a customized / extended version of the SDK and investigate these issues until we have reasons to believe that the defect is caused by the introduced customization.
Changing the SDK Source
The ForgeRock SDKs are licensed under open source and accordingly the source code may be modified. ForgeRock only supports unmodified, released versions of the SDK, as downloadable from the dependency managers or GitHub Releases.
In this document, only the most significant SDK limitations are called out:
- The SDKs are designed to work with trees and are not tested or supported with chains.
- The SDK is not tested or supported with any ForgeRock version that is earlier than 6.5.2.
- FRUI is a demonstration UI that is not intended for production use. ForgeRock shall use reasonable efforts to support the FRUI, however ForgeRock shall have no liability arising out of or related to any use of the FRUI in a production environment.
- The Authenticator Module of the Android SDK and displaying CAPTCHAs in your application requires the presence of the Google Play Services.
Though the SDKs are open source projects, customers that hold valid ForgeRock software licenses should raise SDK issues via Backstage, the same way as they would open tickets for AM or any other platform component. To avoid confusion, the Issues tab has been removed from the SDK repositories in GitHub.
Instructions about how to raise issues are documented in the README file of all repositories and in our documentation.
SDK defects are always fixed in the latest version of the product. Fixes are not backported. In order to receive a fix, customers have to upgrade to the latest version of the SDK.
|Example: A customer uses SDK version 1.0 and they identify a defect in the SDK. The latest released version of the SDK at the time of the discovery is 2.0. The fix will not be backported to 1.x or 2.0. They will be rolled out in our next release: 2.0.1 or 2.1. The customer will have to upgrade the 1.0 version of the SDK in their app to the latest version.|
The SDK documentation is at https://sdks.forgerock.com/
The SDK knowledge base articles are on Backstage.
We are working on an SDK hands-on University course that is targeted for early 2021.