A NT$600,000 Flutter ordering app finished coding on 20 May, with a launch event booked for 1 June. The iOS build cleared review in two days. The Android build took 23 days: the account was newly created and personal, and Google Play requires a closed test with 12 testers opted in for 14 straight days before production access. The event went ahead and half the room could not install the app. Those 23 days were not a technical failure — nobody treated publishing as a scheduled phase at quoting time.
When an app makes sense, and when it does not
Good fit for the stores:
- You need push, Bluetooth or barcode scanning — things browsers do badly or not at all
- Users come back at least twice a week (ordering, work orders, attendance)
- You need offline operation: field inspections, warehouse counts
Poor fit — build a website or PWA instead:
- Pure information display — collides with guideline 4.2 on minimum functionality
- Wrapping an existing website in a WebView shell with no native capability
- A two-platform budget under NT$300,000, or no annual maintenance line item
- Nobody inside the company owns the yearly SDK upgrade
Four routes compared
| Approach | Upfront cost | Publishing risk | Who it suits |
|---|---|---|---|
| Flutter, both stores | From NT$350,000 + NT$25,000 submission management | Medium: must satisfy two rulebooks | Push, retention, long-term product |
| PWA | NT$80,000–200,000 | None: no review | Tight budget, simple feature set |
| Website-to-app wrapper services | NT$30,000–80,000 + monthly fee | High: frequently rejected under 4.2 / 4.3 | Rarely advisable for public release |
| Internal enterprise distribution | From NT$200,000 | Low: bypasses public review | Employee-only internal tools |
The PWA saving is real and so is the trade-off: on iOS the user must add the app to the home screen before push works, which drops opt-in by an order of magnitude. Wrapper services fail worst — the rejection lands in month three, and you do not have the access to fix it.
The full pipeline, stage by stage
- Stage 0 — Accounts and identity verification (1–3 weeks, parallel to development)
Apple organisation account, Google Play Console account, D-U-N-S number. Apple charges 99 USD per year; Google Play charges a one-time 25 USD fee. - Stage 1 — Store assets and compliance pages (3–5 days)
1024px icon, screenshots, store copy, a live privacy policy page, privacy labels and Data Safety forms. Figma, fastlane. - Stage 2 — Beta testing (2–3 weeks; 14 days mandatory on Android)
A TestFlight build (up to 100 internal and 10,000 external testers), a Play closed testing track with 12 named testers, a triaged defect list. Firebase Crashlytics or Sentry. - Stage 3 — Submission and appeal (3–7 days)
Review notes with a permanent test account, password, an SMS-verification workaround and a 30-second screen recording. Apple states 90% of submissions are reviewed in under 24 hours. - Stage 4 — Staged rollout (1–2 weeks)
A Play staged rollout at 5% → 20% → 100%, Apple's 7-day phased release, rollback and hotfix. Put the official flutter build ipa flow into GitHub Actions or Codemagic.
What it actually costs (first release, both platforms)
- Apple Developer Program: 99 USD/year, roughly NT$3,200/year — miss the renewal and your app is removed
- Google Play registration: 25 USD one-time, roughly NT$800
- Store asset design (icon plus screenshots): NT$12,000–30,000
- Submission management, two rejection responses: from NT$25,000
- CI/CD build pipeline setup: NT$20,000–45,000 one-time
- Annual SDK / target API upgrade work: NT$15,000–40,000 per year
The hidden costs: digital goods sold through in-app purchase carry a 15%–30% commission on both stores (under 1 million USD in annual proceeds you can apply for Apple's 15% Small Business Program); a tax-ID change forces re-verification. The most expensive line is losing your Android signing key, which permanently ends your ability to update that app.
What clients expect versus what happens
| Client expectation | Reality |
|---|---|
| Code is done, so we publish in two or three days | A new Play personal account must complete 12 testers × 14 days first |
| A rejection is a small code fix | 4.2 (minimum functionality) and 4.3 (duplicates) are positioning problems — you change the product, not the code |
| Both platforms go live together | Apple is usually fast; Google policy review can drag for days. Set the date by the slower platform |
| Once live there are no more costs | Since 28 April 2026 iOS apps must be built with the iOS 26 SDK, and existing apps must target API level 35 by 31 August 2026, extendable to 1 November |
| Users update themselves | Without a forced-update gate, 20–30% of devices still hit the old API six months later |
Seven traps and how to avoid each
- WebView shell judged as insufficient functionality. Ship at least three capabilities a web page cannot offer — push, scanning, offline cache — and note them in the review notes.
- No in-app account deletion. Users must be able to delete their account inside the app; Apple disallows forcing a phone call or email. The backend must actually delete the data.
- No working test account. A reviewer who cannot log in rejects immediately. Supply a permanent account, password and a short recording.
- Privacy labels that do not match your SDKs. An SDK quietly collecting device identifiers is takedown-grade. Keep an SDK-to-disclosure mapping table.
- Accounts registered under the agency's name. Bundle ID and signing keys travel with the account. Write ownership into the contract on day one.
- The Android keystore lives on one laptop. Enable Play App Signing and store the keystore in a password manager.
- No version gate. Call a /version endpoint on launch and block anything below the minimum supported build. Without it the backend can never retire an old API.
Success metrics and a 90-day roadmap
- Days 1–30: crash-free users at or above 99.5%; first submission approved with at most one rejection; a baseline for store view-to-install conversion; install-to-registration at 40% or better.
- Days 31–60: a D7 retention baseline and a quarterly target; push opt-in at 50% or above; new-version adoption at 60% within seven days; no Android vitals metric sitting in the bad-behaviour threshold.
- Days 61–90: a six-week release cadence running; staged rollout and rollback documented as an SOP; ratings above 4.0 with a reply process; next year's SDK upgrade budget approved.
Decision checklist: are you ready to submit?
- ☐ Developer accounts are registered under the client's own legal entity
- ☐ D-U-N-S number obtained and matches company registration
- ☐ A clear in-app account deletion path exists and the backend truly deletes
- ☐ Privacy policy page is live at a URL you can paste into the store listing
- ☐ Privacy labels / Data Safety cross-checked against the actual SDK list
- ☐ A reviewer test account exists that will not expire
- ☐ Review notes include a screen recording or annotated screenshots
- ☐ At least three genuine native capabilities, not just a web shell
- ☐ Play App Signing enabled and the key backed up by a second holder
- ☐ If the Play account is new and personal, 12 testers × 14 days is complete
- ☐ The app performs a minimum-version check on launch
- ☐ Crash reporting is connected and receiving data
- ☐ Staged rollout percentages and rollback triggers are agreed
- ☐ Next year's SDK / target API upgrade budget is allocated
FAQ
How long should we budget for a first submission?
Five working days for iOS, including one rejection cycle. For Android on a new personal account, budget at least four weeks from account creation to production access, because the 12-tester, 14-day closed test is a hard gate. Organisation accounts usually skip it, but identity verification can take one to two weeks.
Does a rejection hurt future reviews?
There is no penalty score, but repeating the same mistake lengthens each round trip. What genuinely causes damage is trying to game review — toggling features remotely during the review window is a serious violation and can trigger account-level action.
Can we ship iOS first and do Android later?
Yes, and on a constrained budget that is often correct. Use the operating-system split in your website analytics as a proxy, concentrate budget on the majority platform and cover the other with a responsive site or PWA.
What is the minimum annual cost after launch?
The hard floor is about NT$3,200 for the Apple membership. A realistic maintenance budget is NT$15,000–40,000 per year to absorb SDK upgrades, certificate renewals and store policy changes. Budgeting zero means accepting that one year your app simply disappears from the store.
Next step
ScriptWalker offers App Submission Management from NT$25,000, covering both platform accounts, store assets, privacy labels, submission and rejection response; Flutter two-platform development starts at NT$350,000. We also take one-off submission diagnostics. To get a checklist you can hand straight to your engineers, get in touch:
- Email: [email protected]
- Phone: 0916-224-047
- LINE: @ufv9089p