Skip to main content
A player who leaves with an uncashed balance is the easiest player to win back. Local reminders let you reach them — “you have earnings waiting”, “you’re 80% of the way to an Amazon card” — without any push infrastructure. Because the OS holds the scheduled notification, there is no server, no device tokens, and no backend work. The SDK schedules reminders when the player leaves and cancels them when they return, so a reminder only ever fires if they genuinely stayed away. You supply the conditions and the copy; the SDK owns the plumbing. It caches the player’s reward state during play, schedules on background, cancels on return, and handles the platform hygiene that makes local notifications fiddly to get right.
Requires Unity SDK v1.1.7 or above.

​
Opting in

Already have a notification system? Use that instead. This feature exists to make reminders easier and quicker to ship for games that don’t have anything built. If your game already schedules its own notifications, we recommend adding reward reminders there — pull the reward data from GetGiftCards or GetBalance — and skipping this feature entirely.
Reminders are off by default and stay off until you do both of the following:
  1. Add Unity’s Mobile Notifications package (com.unity.mobile.notifications, version 2.3.0 or above) to your project. The SDK does not add it for you.
  2. Call ConfigureReminders with your rules.
If you skip either, nothing happens — no notification channel is registered, no permission is requested, nothing is scheduled, and there are no build errors. Without the package, ConfigureReminders logs a hint and does nothing. A game using its own notification manager can ignore this feature completely, even with the package installed.

​
Quick start

Call once, any time after Init:
Then ask for permission at a sensible moment (see Asking for permission):

​
How rules work

When the player backgrounds the app, the SDK evaluates your rules in order against a snapshot of the player’s reward state. The first match wins and its reminders are scheduled; if no rule matches, nothing is scheduled. List the most specific rule first.
Always gate your catch-all rule on s.balance > 0. No-match-means-no-reminder is how a player with nothing to come back to stays unbothered — a player who has already cashed out must never be told they have earnings waiting.
Each rule has:

​
The snapshot

Rules receive a ZBDRewardSnapshot with the player’s withdrawable balance, the giftCardName they’re closest to unlocking, their giftCardPercent progress toward it (0–100, or -1 when unknown), and canWithdraw. The snapshot is as of the player’s last session, not a live read — reminders are scheduled while the app is suspending, which is not a safe place for network calls, so the SDK caches this during play: after Init, after each reward it sends, and after every withdrawal. You never refresh it yourself.

​
What the SDK handles for you

  • Scheduling on background, cancelling on return — using OnApplicationPause, which fires reliably on both platforms (unlike OnApplicationQuit, which Android frequently skips when killing a backgrounded process).
  • Only its own notifications. Cancellation is scoped to reminders the SDK scheduled, tracked by ID and persisted across process kills. Your game’s own scheduled notifications are never touched.
  • The Android notification channel (required on API 26+), configurable via androidChannelId / androidChannelName / androidChannelDescription on the config.
  • Platform hygiene — a 60-second floor (both platforms batch shorter timers), and reminders never show while the player is in the foreground of your game.
  • Stale-state protection — pending reminders are cancelled and rebuilt on every background, and the snapshot is re-cached after withdrawals so copy is never built from pre-cashout state.

​
Asking for permission

Never ask on a cold launch. iOS shows the system permission prompt only once per install — if the player declines, the only way back is the Settings app. The SDK never requests permission itself; you choose the moment.
Call RequestNotificationPermission() when the value is obvious to the player — after their first reward, or once they’re a signed-in rewards user. It only ever prompts once per install. On Android 13 (API 33) and above the POST_NOTIFICATIONS runtime permission is required — without it nothing is shown and nothing errors. The same call handles it.

​
Cancelling programmatically

Cancels the SDK’s own pending reminders — for example if the player turns reminders off in your settings menu. Your game’s notifications are unaffected.

​
Testing

Notifications are device-only — they don’t fire in the Unity Editor. To test without waiting a day, set debugFastReminders = true on the config: reminders fire about a minute after backgrounding instead of hours (interval tunable via debugIntervalSeconds, floored at 60 seconds).
Never ship with debugFastReminders enabled.

​
Reference example

The SDK demo project’s ZBDDemoNotifications.cs is a complete working example of configuring reminders — rules, permission timing, and the debug flag — and is a good starting point to copy from.

​
Pairing with creatives

Local reminders bring the player back; a creative modal tells them what to do next. Showing a “you’re halfway to a gift card” creative on the session that a reminder brought them back to is a natural pairing — both are driven by the same gift-card progress data.