When Apple or Google releases a new major version of iOS or Android, keep running your current Fullstory SDK until we certify support for that OS. We typically certify within days of the public release and commit to doing so within 30 days. This article explains why we validate against the final public build, what we do to certify quickly, and the track record behind that commitment.
To capture your app's UI, Fullstory integrates with the operating system well below the level of its public APIs. Because we work that close to the internals, an OS change we haven't validated can affect capture, stability, or privacy—not just surface a recoverable error. So rather than enable capture on an unverified build, we test against every beta and release candidate throughout the cycle and certify the moment the final release checks out.
Note: If you want an earlier signal on iOS, you can raise the MaxOSVersion setting during your own beta testing. This enables capture so you can validate behavior, including privacy, before Fullstory completes official certification.
How we certify a new OS
Certifying a new OS is a continuous process that starts well before the public release:
- Test throughout the beta cycle: We test each new OS across the beta and release candidate cycle.
- Validate at release: Once the OS is publicly released, we complete final validation and certify support, typically within days.
- Ship an SDK update: We release an SDK update that raises the maximum supported OS version—as a dedicated point release if needed, rather than shipping with our normal monthly cycle.
- Capture stays disabled until you update: Until that SDK update is installed, capture remains disabled on the new OS.
Why we validate against the final release
Final pre-production builds generally indicate that public APIs are stable. For most applications, that's enough confidence to begin supporting a new OS.
Fullstory has different requirements. Our SDK needs to understand how the operating system behaves under the hood, not just the APIs it exposes. Apple or Google can change those implementation details between a late beta or release candidate and the final public build without breaking an API contract.
Those changes can still affect Fullstory. They may alter capture behavior, introduce crashes, or, most importantly, change how privacy protections need to be applied.
iOS 26 is a clear example. In that release, Apple changed parts of the underlying view hierarchy without requiring apps to change their own code—a change that can materially affect how Fullstory interprets and captures an app's UI. Validating against the final build let us adapt before enabling support; see our iOS 26 migration guide for the details.
Our certification turnaround
Our goal is to certify every new OS as soon as possible after its public release. We plan for each release months in advance, testing against betas and release candidates throughout the cycle so support is ready as soon as the final build ships. While thirty days is our upper-bound commitment to account for worst-case scenarios, our target is always to certify within days of release.
For our three most recent certifications, support arrived on iOS 27's release day, nine days after Android 17's release, and four days before iOS 26's public launch.