Mobile development has a cost structure the web doesn't: a bad ship isn't a quick hotfix deploy, it's a review cycle, sometimes days long, sometimes with a rejection you have to diagnose and resubmit against. That changes how much a pre-ship discipline is actually worth.
Why the tier decision matters more here
A platform-level change — a new push-notification provider, a background-sync architecture, an in-app-purchase integration — is exactly full-tier territory: real architectural risk, the kind of thing that's expensive to get wrong after it's already shipped to users' devices. Catching that distinction before implementation starts, rather than after a rejected build, is where the tier decision pays for itself fastest on mobile.
Design-First is the common case, not the exception
Mobile work is disproportionately Design-First: a Figma file from a designer, an existing native app being rebuilt in a new framework, a design system that already exists in a style guide nobody's translated into working screens yet. design-analysis extracting screen-level flows and component specs from what already exists — rather than a fresh requirements doc drafted from a vague description of "make it look like the mockups" — is usually the actual starting point for mobile specs, not an edge case.
Investigation matters more when repro is harder
Mobile bugs are frequently device-specific, OS-version-specific, or timing-dependent in ways a desktop web bug usually isn't. The Investigate skill's insistence on verifying actual behavior — querying real state or running the flow, not just reasoning from source — matters more here, not less. "Probably a race condition in the sync logic" is an especially expensive guess to be wrong about when confirming it means a multi-day round trip through TestFlight or a Play Store internal track.
Approval gates and app-store accountability
Once a spec is approved for a release-bound feature, the discipline against silent mid-implementation changes has a very literal payoff: what gets built matches what you reviewed, which matters when what you reviewed is also what's about to go in front of an app-store reviewer or a company's release-approval process.
Mobile doesn't need a different workflow than web — it needs the same one, applied somewhere the cost of skipping it shows up faster and less forgivingly.