◇ App Dev/2026-06-27Intermediate

Show the In-App 'What's New' Once, Without Nagging — Version Gating and Seen State

An in-app 'What's New' screen that fires on fresh installs or shows every launch gets users annoyed. Here is a version-gated, seen-state design that delivers it exactly once to people who updated — in real Rork (Expo) code, plus a shape you reuse across multiple apps.

Rork⁵³⁹ Expo¹⁷⁵ Onboarding⁸ Retention design² Release ops

✦ Premium Article

I have hit the wall of "nobody notices the new feature" many times. The store listing's "What's New in this version" goes mostly unread, and push notifications never reach people who declined them. The one reliable touchpoint left is the screen a user sees the moment they first open the app after updating.

But this "What's New" screen turns sour fast if you build it wrong. Showing a "new feature" announcement to someone who just installed, or showing the same notice every launch, only damages the experience. This is how to draw the boundaries so that "to people who updated, exactly once" actually holds.

How to decide "only people who updated"

The decision needs two values: the "current version" running now, and "which version this user last had." Persist the latter every time and compare it on launch.

No stored value → fresh install. Do not show.
Stored < current → updated. A candidate to show.
Stored = current → just relaunched on the same version. Do not show.

Read the current version from expo-application rather than threading app.json's version around by hand.

// lib/appVersion.ts
import * as Application from "expo-application";
 
// Display version like "1.4.0". It can be null, so keep a fallback.
export const CURRENT_VERSION = Application.nativeApplicationVersion ?? "0.0.0";
 
// A plain semver-ish compare of dotted version strings.
export function isNewer(a: string, b: string): boolean {
  const pa = a.split(".").map((n) => parseInt(n, 10) || 0);
  const pb = b.split(".").map((n) => parseInt(n, 10) || 0);
  for (let i = 0; i < Math.max(pa.length, pb.length); i++) {
    const x = pa[i] ?? 0;
    const y = pb[i] ?? 0;
    if (x !== y) return x > y;
  }
  return false;
}

Put the record and the decision in one place

Keep the decision in one small function. The important move is to separate "should we show What's New" from "should we update the last version." Persisting the last version happens unconditionally, whether or not anything was shown. Otherwise an update that has no What's New data yet will later batch two versions of notes into the next real update.

// lib/whatsNew.ts
import AsyncStorage from "@react-native-async-storage/async-storage";
import { CURRENT_VERSION, isNewer } from "./appVersion";
 
const LAST_VERSION_KEY = "whatsNew.lastVersion";
 
export type WhatsNewDecision =
  | { show: false }
  | { show: true; fromVersion: string; toVersion: string };
 
export async function evaluateWhatsNew(): Promise<WhatsNewDecision> {
  const last = await AsyncStorage.getItem(LAST_VERSION_KEY);
 
  // Always advance the last version (settle the bookkeeping first).
  const persist = () =>
    AsyncStorage.setItem(LAST_VERSION_KEY, CURRENT_VERSION);
 
  // Fresh install: record only, show nothing.
  if (!last) {
    await persist();
    return { show: false };
  }
 
  // Same, or current somehow older: do not show.
  if (!isNewer(CURRENT_VERSION, last)) {
    await persist();
    return { show: false };
  }
 
  // Updated: a candidate. Hand fromVersion to the caller.
  const decision: WhatsNewDecision = {
    show: true,
    fromVersion: last,
    toVersion: CURRENT_VERSION,
  };
  await persist();
  return decision;
}

The crux is calling persist() and returning show: false on a fresh install. The first run quietly records only, and from the next update onward you show correctly, exactly once.

✦

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN

✦A 'last version seen' record and decision logic that never shows on a fresh install, only once to users who updated

✦Reading the current version via expo-application and keying seen-state per version so nothing slips through

✦Running six wallpaper apps in parallel, a shared design that keeps the logic common and only the copy per app

Secure payment via Stripe · Cancel anytime

✦

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

Unlock all articles with Membership →

Tie the content to the version

Keep the What's New copy as data keyed by version, held inside the app. By not depending on the network, it always renders right after an update, even offline. Listing only entries newer than fromVersion lets someone who skipped a version still see the changes in between, batched together.

// data/whatsNew.ts
export type WhatsNewEntry = {
  version: string;
  items: string[]; // 2 to 4 things that changed in this update
};
 
// Order does not matter; we sort at display time.
export const WHATS_NEW: WhatsNewEntry[] = [
  { version: "1.4.0", items: ["You can now reorder favorites", "Widget refresh is faster"] },
  { version: "1.3.0", items: ["Tuned the dark mode palette"] },
];
 
export function entriesSince(from: string, isNewer: (a: string, b: string) => boolean) {
  return WHATS_NEW
    .filter((e) => isNewer(e.version, from)) // only newer than from
    .sort((a, b) => (isNewer(a.version, b.version) ? -1 : 1));
}

When the entries are empty, do not show the screen even if the version rose. Showing "What's New" for an internal-bugfix-only update gives users nothing to read and breeds distrust instead. Keep items to two to four, and write only what visibly changed for the user, in plain language without overselling.

Where to slot it in the launch flow

What's New competes with onboarding and consent prompts. Make the priority explicit so multiple modals never stack on one launch.

Situation	What to show
First run after fresh install	Onboarding only (no What's New)
First launch after update	What's New (only if it has content)
Consent/permission still pending	Prioritize consent, defer What's New
Relaunch on same version	Show nothing

// Example startup assembly
import { evaluateWhatsNew } from "./lib/whatsNew";
import { entriesSince } from "./data/whatsNew";
import { isNewer } from "./lib/appVersion";
 
async function decideStartupModal() {
  if (await hasPendingConsent()) return { type: "consent" }; // consent first
  const d = await evaluateWhatsNew();
  if (d.show) {
    const items = entriesSince(d.fromVersion, isNewer);
    if (items.length > 0) return { type: "whatsNew", items }; // only with content
  }
  return { type: "none" };
}

Pass consent first, and show What's New only when it has content. Just these two gates avoid the "I updated and got hit with a permission dialog and a feature tour back to back" accident.

Reuse it across multiple apps

I run about six wallpaper apps in parallel, so touching each app's code just for What's New is not realistic. The decision logic (whatsNew.ts and appVersion.ts) is a shared module across all apps, and the only thing that varies is the copy in data/whatsNew.ts.

The copy is a separate file per app, but keeping the format identical (the shape of version and items) means a release only has to pour "what changed this time" into each app's data. Generate both the store's "What's New in this version" and the in-app notice from the same source text, and the wording drift disappears too. Once the mechanism is shared, every feature addition carries less of that "they might not notice" worry, and you can actually deliver what you built.

Put "was it seen" to use later

Take it one step further and also record the fact that you actually displayed What's New, so it can inform the next design decision. For instance, "show a quiet one-line banner only to people who updated but never opened the new-feature tab" is something you can build as an extension of the same whatsNew.lastVersion mechanism. Once the mechanism is shared, every feature addition carries less of that "they might not notice" worry, and you can deliver what you built.

Roll it out in this order:

Read the current version in appVersion.ts and stand up one evaluateWhatsNew.
Verify the fresh-install and first-update behavior on a real device.
Put one version's copy in data/whatsNew.ts and wire it into the launch flow.

Start with the single evaluateWhatsNew function and one version's worth of copy. On the next update, the new feature reaches the people who updated — quietly, and exactly once.

Thank You for Reading

Rork Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.