Google Play Preparation

Cheaper to enter, slower to launch. The rule that catches everyone is a testing requirement that adds two weeks to your first release, so if Android is anywhere in your plan, start the clock now, even with a throwaway build.

The concept

Google Play parallels the App Store with different economics and one rule that reshapes your timeline.

⭐ The rule that catches everyone

New personal developer accounts must run a closed test with ~12 testers for 14 continuous days before production access is unlocked. (Organisation accounts are usually exempt; verify current requirements, Google changes them.)

That means: from zero to a public Android app is a minimum of ~3 weeks, most of it waiting.

📐 If Android is anywhere in your plan, even "maybe next quarter", do this now: pay the $25, create the account, upload any build, recruit 12 testers (friends, a Discord, a subreddit, your email list), and start the 14-day clock. By the time your app is genuinely ready, the gate is already open. This is the single highest-leverage thing in the chapter.

The signing key is business-critical

Losing your signing key means you can never update your app. Ever.

Opt into Play App Signing (Google holds the app-signing key; you hold a resettable upload key), and back up your keystore to a password manager and an encrypted offline copy, with passwords stored separately. Treat it exactly like a private key for money, because it is.

Listing differences from Apple

Differences that bite

• The Data Safety form is stricter than Apple's label. It asks specifically about encryption in transit, deletion mechanisms, and third-party sharing. Answer it against your real behaviour, including SDKs, mismatches get apps removed, not just rejected.
• Target API level is enforced with a deadline. Google requires apps to target a recent Android API within ~a year of its release. Miss it and your app is hidden from new users, a maintenance obligation Apple doesn't impose.
• Fragmentation is a real testing cost. Thousands of device/OS/skin combinations. For webview-based apps especially, the system WebView version varies by device, test the oldest WebView you support, because CSS and JS that work on a modern phone may not on a four-year-old one.
• Review can be slower and more opaque than Apple's, fewer rejections in practice, less dialogue when they happen.

Payments: the same layer

Use the same subscription layer as iOS (Chapter 27) with a matching product configuration and the Android public key. Same product IDs, same entitlement, same code path, which is exactly why a subscription layer is worth it: Android becomes a config change, not a second payments implementation.

Apply for the small-business fee tier (15% under $1M/year) here too.

📐 Best practice

Start the 12-tester clock immediately if Android is remotely planned.

Opt into Play App Signing; back up the keystore in two places.

Reuse your subscription layer, matching product IDs.

Answer the Data Safety form against real behaviour, including SDKs.

Test on a low-end device with an old WebView (for hybrid apps).

Set a calendar reminder for the target-API deadline.

Apply for the 15% fee tier.

Ship where your customer pays, often iOS first for US consumer subscription.

💀 Common mistakes

⭐ Discovering the 12-tester rule at launch. A 2-3 week delay you could have absorbed earlier.

Losing the keystore. You can never update the app. Play App Signing + backups.

Data Safety mismatch. App removed, not just rejected.

Missing the target-API deadline. Hidden from new users.

Testing only on a flagship. Old WebViews and cheap devices break the UI.

Two payment implementations, double the bugs. Use one layer.

Following stale build docs that reproduce a fixed bug.

Waitlist promises made ("iOS and Android") that become launch obligations.

The professional workflow

 1. CREATE THE ACCOUNT ($25) — even if Android is later

 2. START THE 12-TESTER CLOSED TEST with any build

 3. TOOLCHAIN — SDK + JDK; add the Android platform

 4. SIGNING
    generate keystore · opt into Play App Signing · back up twice

 5. PAYMENTS — subscription layer, matching product IDs, Android key

 6. LISTING
    title · 80-char short description · full description ·
    feature graphic 1024×500 · 2-8 screenshots

 7. COMPLIANCE
    Privacy Policy URL · Data Safety form (real behaviour) ·
    content rating · target a recent API

 8. TEST on a low-end device with an old WebView

 9. CLOSED TEST 14 days → apply for production → submit

10. CALENDAR: target-API deadline; small-business fee tier

Tools, websites & costs

$25 total to enter, a quarter of Apple's, and one-time rather than annual.

Alternatives & trade-offs

iOS first vs Android first. For US/UK consumer subscription, iOS usually monetizes far better, ship it first. For markets where Android dominates (much of Asia, Africa, LatAm), invert this.

Google Play vs alternative stores. Play is the default. Alternatives (Samsung Galaxy Store, Amazon Appstore, direct APK, F-Droid) reach specific audiences and add distribution/QA surface. Add them only with a reason.

Managed cross-platform vs native. Cross-platform makes the second store a config change; native means a second codebase. For most first products, cross-platform.

Personal vs organisation account. Organisation avoids the 12-tester rule and needs business verification. If Android is core and you have an entity, the organisation account can save the three weeks.

Checklist

• Play Console account created ($25), even if Android is later
• 12-tester closed test started, the long pole
• SDK + JDK installed; Android platform added
• Keystore created, Play App Signing enabled, backed up twice
• Subscription layer + matching product IDs + Android key
• Listing: title, 80-char short description, full description
• Feature graphic 1024×500
• 2-8 screenshots
• Privacy Policy URL live
• Data Safety form matching real behaviour
• Content rating done
• Target API level current; deadline in the calendar
• Tested on a low-end device / old WebView
• Applied for the 15% fee tier
• Build docs current (no stale integration instructions)

📓 Case Study: the rule documented on day one and never acted on

Project: SOLIS. This case study is mostly about a deviation, because Android was never shipped, the platform was prepared for but never built out.

The decision to defer was defensible. The target market was US young men, where iOS both dominates the demographic and monetizes substantially better. Supporting two stores would double the build, QA, store-listing, IAP configuration and support surface, for a launch whose demand was still unvalidated. Validate on one platform, expand on evidence. For a US consumer subscription product, iOS-first is nearly always correct.

⚠️ Deviation: the 12-tester clock was documented on day one and never started.

The build guide, written at the very start, recorded the rule explicitly:

New personal accounts must run a closed test with ~12 testers for 14 days before production is unlocked. Start this early, it's the slowest gate.

That advice was correct and self-authored, and nothing was done with it. The Play Console account was never created; the SDK was never even downloaded. So whenever Android happens, it now begins with a three-week wait that $25 and a form on day one would have removed.

📐 The lesson isn't "SOLIS should have built Android." It's that a known, cheap, front-loadable gate was identified and deferred anyway, because starting a clock produces no visible progress. The highest-leverage move (pay $25, upload anything, recruit 12 people, start the clock) feels like nothing is happening, so it loses to work that feels productive. Front-load everything that has a queue.

⚠️ A second deviation: a promise made to the waitlist. The confirmation email was updated to mention "iOS and Android", a commitment made before the Android work was scoped or started. Easy to write; real work owed at launch. Every promise made to a waitlist becomes a launch obligation.

⚠️ A third, quieter one: the build docs contained a stale integration. The Android track in the build guide still documented the wrong payments integration pattern, the exact one that had silently granted every user free access on iOS before it was fixed (Chapter 27). Anyone following that doc for Android would have reproduced the bug. Stale documentation is worse than none; it confidently teaches a fixed bug.

One thing done right: the payments architecture used a subscription layer, so Android support was genuinely a config change plus one API key rather than a second implementation. That's the design decision that makes "iOS first, Android on evidence" cheap to execute later.

Lessons

1. The 12-tester/14-day rule is the real Android launch cost. $25 and three weeks of waiting.
2. ⭐ Start the clock before you need it. Any build, 12 people, day one. It feels like nothing; it saves weeks.
3. Ship where your customer pays, not where the devices are.
4. Your keystore is a business-critical secret. Play App Signing plus two backups.
5. A subscription layer makes the second platform a config change, not a second implementation.
6. The Data Safety form is stricter than Apple's label. Answer it against reality.
7. Android imposes ongoing maintenance (target API) that iOS doesn't.
8. Test old devices and old WebViews.
9. Stale docs reproduce fixed bugs. Date and update them.
10. Waitlist promises become launch obligations. "iOS and Android" is real work.

Next: Chapter 38: Analytics, Crash Reporting and Observability →