iOS

1.2.0 — September 8, 2026

The iOS privacy manifest now declares Device ID. The SDK stores a session identifier on the device and sends it with later requests, and that identifier was not declared before. Nothing changed about what the SDK collects — only what it tells Apple. If you ship this SDK, re-check the App Privacy answers on your App Store listing, because you inherit our manifest into your own disclosure and Device ID may be new for you.
The SDK no longer keeps cookies. Stay22's responses set a session22 cookie carrying the same session id the SDK already sends as a parameter, and the default URLSession configuration persisted it into HTTPCookieStorage.shared — your app's process-wide cookie jar, readable by anything else running in your app. The SDK never read it, so nothing changes about how notifications are decided or attributed. If you have disclosed a Stay22 cookie in your own privacy documentation, you can drop it.

Event handling now documents, and the sample now demonstrates, that a switch over Stay22Event needs a default case. The framework is built with library evolution, so the enum is non-frozen and an exhaustive switch is a warning today and an error under the Swift 6 language mode. No API change: the enum stays non-frozen on purpose, so new events can be added without a breaking release.
The willPresent forwarding snippet in this README, and the Flutter wrapper's own copy of it (README, example app, plugin doc comment), still said [.banner, .sound] after the .list fix below landed in the SDK itself — an app copying any of them would reintroduce the bug it fixes for apps that own the notification delegate.

A notification delivered while the host app is still alive now stays in Notification Centre instead of vanishing with its banner. The foreground presentation options were [.banner, .sound], and without .list iOS shows the banner and never adds the notification to the list, so a user who does not catch the banner within a few seconds has no way back to the offer. Only apps that were awake at delivery time were affected — a suspended app never gets the callback and iOS lists the notification itself — which is why it looked intermittent.
Partner config is now fetched from /ext/partner/settings instead of /ext/partner. The old path is blocked by an unrestricted rule on AdGuard's spyware filter list, so on a device running a system-wide URL filter the SDK never received its config, never scheduled a notification, and retried on every foreground forever. /ext/partner/settings was added for exactly this reason and the web moved to it in April; both paths are registered to the same handler and return the same payload.

Integration self-check via Stay22.diagnostics, reporting each prerequisite as pass/warn/fail with the remedy for anything that fails.
Stay22.handleNotificationResponse(_:), Stay22.handleWillPresentNotification(_:) and Stay22.ownsNotificationDelegate, for apps that manage UNUserNotificationCenter themselves.
Stay22.advanced.scheduleNotification(force:) for verifying an integration without waiting out the normal delay. Defaults to false and never bypasses partner settings.

The SDK no longer stops receiving notification taps when another notification library is set up after it, and no longer interferes with the host app's own notification handling.
Notification-settings deep links are passed through to the host app.
A transient failure no longer loses that trip's notification permanently.
Repeated travel-context updates no longer defer a notification indefinitely.
The SDK can no longer crash the host app on an invalid partner ID or unexpected internal errors.

Privacy section now states which data the SDK transmits and the App Store privacy answers a host app needs.

SDK activity reporting now includes the installed SDK version for release-level diagnostics.

Improved binary compatibility for notification interruption-level configuration.
Skip scheduling when the host app has already filled iOS's pending local notification queue, instead of failing silently.
Hold the background task for the full scheduling flow, so a notification scheduled while the app is backgrounding is recorded reliably.

The locally built fallback notification link now applies device-context provider exclusions, matching the link the server builds.

Device context captured during early app launch or a background/prewarmed launch could be inaccurate for the rest of the session. It is now refreshed when the app becomes active, and the last known-good snapshot is used as a fallback for launches that never reach the foreground.

Reapply the short local cooldown after the server declines an offer, reducing redundant decision checks.

Retry loading partner configuration when the app returns to the foreground, so a failed or interrupted initial fetch no longer blocks notifications for the rest of the session.

Stay22 iOS SDK 1.0.8 — prebuilt Stay22SDK.xcframework for Swift Package Manager (binaryTarget) and manual integration.

Full release notes and downloads: iOS releases