Browser vs mobile app

FrontendTier 1 · hear it this weekPhase 1 · Put a page on the internet

The same product can live on the web (opened in a browser) or as an app installed from an app store. What changes between them matters.

The same product can reach users two ways, and the two ways impose very different constraints that decide what you can promise and when. On the web there is no gatekeeper, so a change is live for everyone the moment you deploy it; in a mobile app, every change waits on Apple's and Google's store review and then on users choosing to update. This distinction exists because those constraints, plus access to hardware like the camera and reliable notifications, drive real roadmap and timeline decisions, not just a choice of technology.

A website loads fresh each visit and updates instantly for everyone. A mobile app is installed on the phone, can work partly offline, and reaches hardware like the camera and push notifications.

The catch: app changes must be submitted to Apple's and Google's stores and reviewed before users get them, and users must choose to update. The web has no gatekeeper and no waiting.

A junior PM, stuck

My boss pinged me this morning: the Kacchi promo price is correct on the website but her phone app still shows the old number. We shipped the same fix to both. I told her it was fixed an hour ago, and now I look like I do not know how our own product works.

You do know the product. What you are running into is that web and app are two different release paths, and only one of them lets you push a change straight to everyone. The thread from this morning already spells out why, in Rafi's own words. This is the actual Slack thread, nothing paraphrased. Read it top to bottom, then take the steps with me.

#launch thread, Friday 2026-03-06, Kacchi promo price mismatch
Thread
boss 11:20 Web shows Kacchi at the new 699 promo price. My phone app still shows 649. We shipped the fix this morning. Why are they different?
Rafi 11:24 The web fix went live at 11:05, about 20 minutes after merge. Web has no review step, it deploys straight to production and every visitor gets it on the next page load.
Rafi 11:26 The app is the same fix in a new build, but the build is sitting in app store review. Apple and Google have to approve it before anyone can download it, usually 1 to 3 days. Nothing we do speeds that up.
Rafi 11:27 And approval is not the end. Each user still has to update the installed app before they see the new price. Check the adoption numbers below.
Android adoption, checked Friday
New build with the fix: submitted, in review, not downloadable yet
Old build still showing 649: 38% of active users
Everyone else: on recent builds, will get the fix only after review clears and they update

Click a step to see the lines it points at.

Quoting a web timeline for an app change. You say fixed today because the website was fixed today, and the store review plus adoption tail makes you wrong in front of a stakeholder.
Forgetting the adoption curve after review clears. Even an approved build only reaches users who update, and the 38% still on the old build keep hitting the bug for days.
Treating we shipped it as users have it. On the app those are two different events separated by review and by every user's own update, and conflating them sets false expectations.
Promising a hardware feature on web to dodge the wait. If the feature needs the camera or reliable notifications the app path is the only one, and the store timeline comes back whether you like it or not.

Tell your boss: "Web has no gatekeeper, so that fix was live in 20 minutes. The app build is in store review for a few days, and even after it clears, the 38% of users still on the old build only get it when they update." You just answered a can-we-just-change-it question by splitting it across the two release paths, which is the move every time web and app disagree.

"Can we just change it?" has a different answer on web (yes, now) versus app (build it, submit it, wait for review, hope users update).
Features that need the camera, precise location, or reliable notifications push you toward an app.

"On web we ship today; on app we're stuck behind store review until Thursday."

Appears in Phase 1, Put a page on the internet.