Choose an update mode

Each iOS or Android target has an Update mode. Set it in the release editor before publishing the target. The behavior below applies to VibeUpdate SDK 0.2.0 and newer.

VibeUpdate compares native build numbers, not visible version labels. The highest published build on a platform is the update target. iOS and Android are evaluated separately. Publishing release notes does not upload an app binary or install an update.

OptionalCopy Anchor Link

Use Optional for an update that users can skip. The prompt shows the target release's notes with Update now and Later.

The prompt appears once per target build. VibeUpdate records it as seen when it appears, even if the user chooses Later. A newly published target build can show another Optional prompt. Editing the notes or republishing the same build does not reset its seen state.

PersistentCopy Anchor Link

Use Persistent when you want a reminder on each fresh app launch while a newer build remains available. Users can still select Later and continue using the app.

Dismissing the prompt does not suppress the next launch's reminder. Returning from the background does not by itself show the same reminder every time.

RequiredCopy Anchor Link

Check that users can actually download the new build from the store before publishing Required. VibeUpdate validates the store URL, not the build's availability in the store.

A Required prompt has Update now but no Later action. Users cannot dismiss it to return to the app. The update action opens the configured store URL; it does not install the update itself.

The highest currently published Required build on a platform sets its minimum supported build. Users below that minimum receive a Required prompt, even if the newest published target is Optional or Persistent. The prompt still shows the newest target's notes and version.

For example, suppose iOS build 10 is published as Required and build 12 as Optional:

• A user on build 9 receives a Required prompt for build 12.
• A user on build 10 or 11 receives an Optional prompt for build 12, unless that Optional prompt was already seen.
• A user on build 12 or newer has no pending update.

Publishing a newer Optional target does not cancel the earlier minimum. Unpublishing or changing a Required target can change future update decisions. It does not automatically close a Required prompt that is already on a device's screen.

What appears after installation?Copy Anchor Link

What's new is a release-note screen, not a fourth update mode. When there is no pending update, VibeUpdate can show the installed published build's notes once, with Close instead of an update action.

If those notes already appeared in a prompt before installation, they do not appear again afterward. An automatic store update can produce a What's new screen when the user has not seen that build's notes yet.

A pending update takes priority over installed-build notes. If build 10 is installed and build 11 is available, VibeUpdate does not show build 10 notes ahead of the update. This remains true when an Optional prompt for build 11 was already seen and is therefore suppressed.

New users are not interruptedCopy Anchor Link

From SDK 0.4.0, VibeUpdate leaves new users alone during their first day:

• For 24 hours after the app first runs VibeUpdate on a device, only Required prompts appear. Optional, Persistent and What's new wait.
• What's new never appears for the build that was installed at that first launch.
• After the 24 hours, a pending prompt appears the next time the user opens the app or returns to it from the background.

The 24 hours start when the app is first opened, not when it is downloaded. Users who already used an earlier SDK version are not treated as new. If you add VibeUpdate in a later version of your app, users who update to that version are treated as new once. The integration can change the period with the newUserGracePeriodMs prop.

When checks happenCopy Anchor Link

The initial check starts after the app renders, without a loading screen. By default, VibeUpdate checks again when the app returns to the foreground if at least one hour has passed since the last successful check. SDK versions before 0.4.0 wait six hours. This is not a background polling schedule.

A visible prompt is only replaced by a Required one. While the app keeps running, each prompt appears at most once, but returning from the background can show a different prompt, such as a newly published update. A Required response can replace an earlier prompt or appear after it was dismissed. SDK versions before 0.4.0 show at most one prompt until the app is restarted. The integration can customize the foreground interval.

A failed check does not open a new prompt from an unverified cached response. However, a failure does not close a Required prompt that is already visible. An error opening the store also leaves that prompt on screen.

Seen state stays on the deviceCopy Anchor Link

Seen state is stored locally for the app, platform, and build. It is not synchronized through a VibeUpdate account. Clearing app storage removes that history, and storage failures can affect whether a prompt repeats or appears.

Integrations upgrading from SDK 0.1.x retain recognized Optional seen state. That version did not record Persistent or Required impressions, so those notes may appear once after installation when upgrading the integration.

If the observed behavior differs, use Troubleshoot releases and prompts.