App store distribution: signing, builds, and the review process

Both platforms require every distributed build to be cryptographically signed — Cryptography Fundamentals' own domain covered the underlying digital-signature mechanism directly — proving the build genuinely came from the registered developer account and hasn't been altered since signing. An unsigned or incorrectly-signed build simply can't be installed on a real device outside of development mode at all; this isn't an optional hardening step, it's a hard platform requirement with no way around it.

Every web platform this curriculum's own Deployment Platforms subcategory covered deploys the moment a build succeeds — there's no external party reviewing a Vercel or Railway deploy before it goes live. App store submission is genuinely different: both Apple and Google run review processes (automated scanning plus, for Apple specifically, real human review for most submissions) that check for policy violations, crashes, misleading functionality, and privacy-declaration accuracy — taking anywhere from a few hours to several days, and capable of rejecting a submission outright, sending it back with specific required changes before resubmission.

Lesson 10's own permission-justification requirement has a submission-time analog: both stores now require an upfront, accurate declaration of what data categories an app actually collects and why, cross-checked (at least partially) against the app's real behavior during review — a mismatch between declared and actual data collection is a real, increasingly common rejection reason, reflecting both platforms' genuine push toward privacy-by-design (Application Security's own domain covers the underlying principle directly) being enforced at the distribution gate, not left purely to developer discretion.

Both platforms provide a pre-review distribution path — Apple's TestFlight, Google Play's internal/closed testing tracks — letting a real build reach actual testers' devices before ever going through full public review, the mobile equivalent of the preview/staging environments this curriculum's own deployment-platform domains covered for web apps. This is genuinely useful for catching real device-specific or platform-specific bugs (lesson 7's own territory) before they reach full public review, where a rejection costs real calendar time to resubmit and wait again.

A web app can ship a critical bug fix within minutes of detecting the issue — a mobile app's fix still has to go through the same review gate as any other release, meaning a genuinely urgent fix can realistically take hours to days to actually reach users, not minutes. This is a real, structural constraint worth designing around deliberately — feature flags and remote-config mechanisms (conceptually similar to CI/CD's own feature-flags lesson) let a team disable a broken feature remotely without waiting for a full new app-store release, specifically because the release pipeline itself can't move as fast as a web deploy can.