iOS

1.6.5 — October 30, 2026

Fixed

• An aid passed to initialize with capital letters, such as MyTravelApp, no longer makes the SDK reject its partner configuration with partner_config_aid_mismatch. Before this fix the SDK scheduled no notifications for that app.

1.6.4 — October 13, 2026

Fixed

• Allez links generated by the SDK now put the partner ID first and the destination second when present.

1.6.3 — October 6, 2026

Fixed

• An app whose URL scheme your app does not list in LSApplicationQueriesSchemes is no longer reported as not installed. iOS cannot check such an app, so the SDK now skips it. Before, a missing entry made Stay22 treat the app as absent and could remove that booking option from the user's offer.

1.6.2 — October 2, 2026

No changes to this SDK. This version keeps it in step with the Android SDK.

1.6.1 — October 2, 2026

No changes to this SDK. This version keeps it in step with the Android SDK.

1.6.0 — October 1, 2026

Added

• Support can inspect a recent notification decision and scheduling history from device logs when testing your app, without adding logging code to your integration.

1.5.0 — September 28, 2026

Added

• Stay22.advanced.setErrorListener(_:) and setErrorHandler(_:) report SDK failures to your app as a Stay22Error, so you can forward them into the crash reporter you already use and see at a glance when a problem is Stay22's rather than yours. The SDK bundles no crash reporter of its own, which would fight yours for the same handlers. Callbacks arrive on the main thread. setErrorListener holds your listener weakly, so keep your own reference to it; setErrorHandler keeps the closure until you replace it or pass nil.
• Errors raised before your app registers an error listener are held and delivered as soon as it does, so a partner configuration that fails during initialize still reaches you. A listener you remove on the main thread is not called again, even for an error already on its way.
• A partner configuration that fails to load is now reported to your app, as it already was on Android.
• A travel context the SDK cannot use is now reported, even before the partner configuration has loaded.
• A notification the SDK could not schedule, because iOS refused it, dropped it, or the app is already at the pending-notification limit, is now reported while Stay22.testing.force is on. That flag keeps test runs out of Stay22's telemetry; it no longer hides a real scheduling failure from the developer running the test.

1.4.0 — September 25, 2026

Added

• Built-in notification text now follows the device's French or English language when a notification is scheduled. Custom notification text is unchanged.
• Apps that set Stay22RequiresConsent in Info.plist keep the SDK disabled until they call Stay22.isEnabled = true after consent.
• Stay22.isStay22Notification(_:) identifies Stay22 requests when your app owns the notification delegate, so handleWillPresentNotification(_:) can decide whether to present them.

Fixed

• Disabling the SDK now stops pending notification reconciliation and prevents an in-flight scheduling decision from queuing a notification after opt-out.
• Disabling the SDK before initialization now cancels a Stay22 notification still pending from an earlier launch.
• Disabling the SDK while a notification is being prepared now cancels that request; a later opt-in can schedule a new offer without reviving the old one.

1.3.0 — September 18, 2026

Added

• Stay22.managesNotificationDelegate, for apps built on a framework that takes UNUserNotificationCenter.delegate for itself and will not share it. Set it to false and the SDK stops claiming that slot; forward taps and foreground presentations to Stay22.handleNotificationResponse(_:) and Stay22.handleWillPresentNotification(_:) from wherever your framework delivers them. Defaults to true, so an app that owns the delegate the ordinary way needs no change.

Fixed

• The SDK now clears its stored travel context once a notification has been shown, matching Android. Previously, setting the same destination and dates again for a later trip could be silently ignored.

1.2.0 — September 8, 2026

Changed

• 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.

Documentation

• 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.

Fixed

• 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.

1.1.0 — August 31, 2026

Added

• 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.

Changed

• Android and iOS now share a version number.

Fixed

• 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.

Documentation

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

1.0.12 — August 21, 2026

Added

• Notification impression reporting when a Stay22 notification is displayed.

Changed

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

Fixed

• 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.

1.0.11 — July 16, 2026

Fixed

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

Changed

• Aligned the notification link and failure-event source to direct.

1.0.10 — July 2, 2026

Fixed

• 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.

1.0.9 — July 2, 2026

Changed

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

Fixed

• 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.

1.0.8 — June 30, 2026

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

Full release notes and downloads: iOS releases