Testing

You cannot publish a new release every time you want to see the prompt. Use a mock instead. A mock is a fake release you set up in code.

Fake a release

Put this at the top of your entry file:

import { setMockVersion } from '@axonpack/in-app-updates';

if (__DEV__) {
  setMockVersion({
    latestVersion: '9.0.0',
    releaseNotes: 'These are fake notes.',
  });
}

Now the prompt thinks version 9.0.0 is out. No request is made while a mock with latestVersion is on. To try a forced update, add minimumVersion: '5.0.0'.

You can also mock one prompt, without touching anything else:

import { UpdatePrompt } from '@axonpack/in-app-updates';

<UpdatePrompt mock={{ latestVersion: '9.0.0', releaseNotes: 'These are fake notes.' }} />;

A mock can set latestVersion, currentVersion, minimumVersion, releaseNotes, releaseDate, storeUrl and buildNumber.

Test your rules without a phone

evaluateUpdate is the decision part of the package, with no request and no phone needed. It is easy to use in unit tests:

import { evaluateUpdate } from '@axonpack/in-app-updates';

const result = evaluateUpdate('1.0.0', { version: '2.0.0' }, { required: 'major' });
// result.isForced === true

The fake Play

Google Play's update flow only runs for an app installed from Play. To test how your app reacts, turn on a fake Play. It plays the part of Play and of the user, so the whole flow runs on a debug build with no store. It uses Google's own FakeAppUpdateManager from Play Core.

import { setNativeUpdateFake, startNativeUpdate } from '@axonpack/in-app-updates';

if (__DEV__) await setNativeUpdateFake('flexibleAccepted');

const outcome = await startNativeUpdate('flexible', (status) => console.log(status));

Pass null to turn the fake off again.

The fake replaces Play's consent dialog and update screen, so it shows how your code reacts. It does not show Google's screens. For those, see the next section.

Test it for real

Google's screens only appear for an app that Google Play knows. The way to test them is internal app sharing. These steps follow Google's guide (Test in-app updates).

1. Use a device or emulator with Google Play, signed in to a Google account.
2. Share an older build internally from the Play Console, and install it from its internal app sharing link. It must already include this package.
3. Share a newer build the same way. It needs a higher version code, and the same application ID and signing key.
4. On the device, open the internal sharing link for the newer build, but do not install it from the Play page that opens.
5. Open the app from the home screen or app drawer. Play now has an update for it, and the real consent dialog or update screen can appear.

Good to know, from the same guide:

• The account must have downloaded the app from Play at least once. Play only offers updates to accounts that own the app.
• Play only updates to a higher version code.
• The update priority field is not supported in internal app sharing, so you cannot test priority this way.

The example app

The repository has an example app, packages/@axonpack/in-app-updates/example. It shows the live store answer, and has buttons for each state of the prompt: live, soft, expanded, forced, dark, brand, minimal, custom, none and native.

bun install
cd packages/@axonpack/in-app-updates/example
APP_ID=com.example.app APP_VERSION=1.0.0 bun run ios

APP_ID and APP_VERSION make the example install as your own published app, so the stores answer for it. Without them, it uses neutral ids and the live check finds no listing.

Next: Troubleshooting