{"id":988435,"date":"2026-09-16T14:00:00","date_gmt":"2026-09-16T14:00:00","guid":{"rendered":"https:\/\/croncodestudio.com\/en\/?post_type=croncode_post&p=988435"},"modified":"2026-09-08T22:58:41","modified_gmt":"2026-09-08T22:58:41","slug":"first-app-store-release-fixed-scope-vs-agile","status":"publish","type":"croncode_post","link":"https:\/\/croncodestudio.com\/en\/journal\/first-app-store-release-fixed-scope-vs-agile\/","title":{"rendered":"First App Store Release: Fixed Scope vs Agile"},"content":{"rendered":"
\n

A first App Store release is a legal and operational event. You pick a bundle ID, a privacy label, and a version that strangers can install. The process question is not \u201care we agile.\u201d The question is whether version one is a contract or a learning loop. This article is about that choice. It is not a guide to going faster. For bottlenecks and calendar pressure, read time to market and roadblocks<\/a> and from idea to market<\/a>.<\/p>\n

\n

Use fixed scope when version one must pass review with a known job. Use agile when you are still discovering that job. Do not mix the two without writing the rule.<\/p>\n<\/blockquote>\n

What does fixed scope mean for version one?<\/h2>\n

Fixed scope means the first store binary has a written list of screens and a written not-now list. Change goes to version 1.1. The team can still work in weekly slices. The store gate is not a moving target.<\/p>\n

This fits products where review will ask hard questions: payments, health-adjacent copy, or a detective fiction that must not look like real surveillance. Spylie<\/a> is a narrative game. The store listing has to say that clearly. A weekly rewrite of the promise would be a review risk, not a virtue.<\/p>\n

When is agile the better contract?<\/h2>\n

Agile is better when the first job is still unknown and you can ship to TestFlight without pretending the public listing is stable. You still need a kill rule. \u201cWe will not add a second tab until ten testers finish the first job\u201d is a rule. \u201cWe will see\u201d is not.<\/p>\n

    \n
  1. Write the first job in one sentence.<\/li>\n
  2. Write the smallest UI that finishes it.<\/li>\n
  3. Write the change that would force a new store version versus a silent TestFlight.<\/li>\n<\/ol>\n

    Consumer apps we ship, such as YourStyle<\/a>, still needed a store-shaped version one. Discovery happened around outfit logic, not around inventing a new category every sprint. Category positioning is a different essay: the ASO playbook on positioning<\/a>.<\/p>\n

    How do you write the hybrid without lying?<\/h2>\n\n\n\n\n\n\n\n\n
    Layer<\/th>\nFixed<\/th>\nFlexible<\/th>\n<\/tr>\n<\/thead>\n
    Store promise<\/td>\nYes<\/td>\nNo, until a version bump<\/td>\n<\/tr>\n
    Internal copy<\/td>\nNo<\/td>\nYes, in TestFlight<\/td>\n<\/tr>\n
    Third-party SDK<\/td>\nYes, for privacy labels<\/td>\nNo last-week surprises<\/td>\n<\/tr>\n
    Visual polish<\/td>\nA floor<\/td>\nAbove the floor<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    If a client wants agile language and a fixed date, pick one as the contract. The other becomes a wish. Selecting a studio that will say this out loud is covered in how to choose an iOS studio<\/a>.<\/p>\n

    What belongs in the version-one cut?<\/h2>\n

    The first job, empty and error states, and the privacy text. Not a second product. Feature creep is how first releases miss review windows. See feature creep<\/a> and the step list in from idea to App Store<\/a>.<\/p>\n

    What mistakes look like process?<\/h2>\n