My mobile smoke test before every release

The mistake I see most is running the web smoke test in a phone-sized browser and calling it a mobile pass. That checks the layout and nothing else mobile actually breaks on. A real mobile smoke test exercises the things that only exist on a device — the lifecycle, the network, the interruptions, the permissions. It takes fifteen minutes on a real device and catches the class of bug that escapes web-first teams. Here's the pass.

Do it on a real device

Emulators are fine for layout and quick loops, but the smoke test before release wants a real device, because the bugs that matter most — real network behaviour, real permission dialogs, real backgrounding by the OS, real notification delivery — are exactly the things emulators fake or skip. One mid-range Android and one iPhone covers most of it; the cheap old Android is where the ugly stuff surfaces.

1. Lifecycle: background, resume, kill

The single most valuable mobile check, because web has no equivalent. Start a task — half-fill a form, open a detail screen — then:

• Background the app (home button), wait, and resume. Is your state intact, or did it reset?
• Background it, open a few other heavy apps to push it out of memory, then resume. Does it restore the screen, or crash trying?
• Force-kill it from the app switcher and relaunch. Clean start, or broken state?

2. Network: offline, slow, switching

• Turn on airplane mode mid-session. Do you get a clear "you're offline" state, or an infinite spinner and a cryptic failure?
• Do an action offline (if the app supports it), then reconnect. Does it sync once, or double-submit?
• Switch wifi → cellular during a request. Does the in-flight request survive or silently die?

3. Interruptions

Trigger the things that interrupt a real phone, mid-flow:

• A phone call or alarm while on a screen — does the app recover?
• The keyboard sliding up — does it cover the field or the submit button?
• Rotate the device mid-form — is your input still there?

4. Permissions

The denied/revoked paths are where apps dead-end:

• Hit a feature that needs a permission (camera, location, photos, notifications) and deny it. Graceful message, or crash/blank screen?
• Grant it, use the feature, then revoke it in system settings while the app is backgrounded. Does the app handle coming back to a revoked permission?

5. Notifications

• Send/trigger a push and tap it. Does it deep-link to the right screen — when the app is foreground, background, and killed (all three behave differently)?
• Check one with the app in each state; the killed-app case is the one that's usually broken.

6. The upgrade path

The check teams forget entirely: install the current production version, use it enough to write some local data, then upgrade to the new build in place (not a clean install). Does it migrate cleanly, or corrupt/lose data? If there's a forced-update flow, does it actually work? Users upgrade over old versions; that's the real path.

Where this fits

Fifteen minutes, real device, before every release. For why these specific things matter, see why mobile bugs escape web-first QA teams; for the automation tool choice, Appium vs Detox vs Maestro; and the common bugs library catalogues the notification, data, and time/date defects this pass tends to surface.

Mobile release smoke test (real device)

• Background → resume, and background → memory-pressure → resume: state intact
• Force-kill and relaunch: clean, correct restore
• Offline state is clear; reconnect doesn't double-submit; wifi↔cellular survives
• Call / keyboard / rotation interruptions recover without losing input
• Denied and revoked-mid-session permissions handled gracefully
• Push notifications deep-link correctly in foreground, background, AND killed states
• Upgrade in place over the production version migrates data cleanly