Subscriptions, one-time purchases or ads? Choosing an app business model
The way an app makes money shapes its design, its roadmap and its relationship with users. A practical comparison of the main models and when each one fits.
Read article
All articles
From idea to App Store: the publishing checklist nobody shows you
Writing the code is only half the launch. Here is everything that happens between "it works on my phone" and "available on the App Store and Google Play".
Most teams plan an app around its features. The ones that ship on time also plan everything around the features: the accounts, the listings, the reviews and the paperwork that the stores need before anyone can press "Get". This is the checklist we run for every app we publish.
1. Accounts and legal identity
Both stores publish an app under a developer account, and the name on that account is the name customers see. If the app is a business, enrol as an organisation, not as an individual:
- Apple Developer Program: an organisation enrolment needs a legal entity and a D-U-N-S number. Allow time for the verification.
- Google Play Console: organisation accounts go through identity and business verification too. Personal accounts created recently must also run a closed test with real testers before they can go to production.
- Agreements, tax and banking: paid apps and in-app purchases stay switched off until the paid agreement, tax forms and payout account are complete.
2. The store listing is a product of its own
The listing is often the first and only screen a potential user reads, so treat it like a landing page:
- A name and subtitle that say what the app does, not just what it is called.
- Screenshots that tell a story in the first two frames. Most people never swipe past the third.
- A description that leads with the benefit and keeps the feature list for later.
- Keywords (App Store) and the short description (Google Play) chosen from real search terms, not from guesses.
- A preview video only if it is better than the screenshots. A weak video hurts.
3. Privacy disclosures
Apple's App Privacy details and Google Play's Data safety section ask exactly what data the app and every SDK inside it collect, why, and whether it is linked to the user. Make an inventory of your SDKs early: analytics, crash reporting and ad libraries often collect more than the team expects. On iOS, the commonly used third-party SDKs on Apple's list must also ship privacy manifests and signatures.
Rule of thumb: if you cannot explain in one sentence why the app needs a piece of data, stop collecting it.
4. The review-ready build
- Test it on real devices with TestFlight on iOS and internal or closed testing tracks on Android.
- Give the reviewer a demo account and clear notes for any feature behind a login or a paywall.
- If users can create an account inside the app, they must also be able to delete it inside the app.
- Subscriptions need clear pricing, renewal terms and links to the terms of use and the privacy policy on the purchase screen.
- Use the platform's own in-app purchase system for digital goods unless a documented exception applies to you.
5. Launch is a process, not a moment
We almost never push an update to 100% of users on day one. For updates, phased releases on iOS (automatic updates spread over seven days) and staged rollouts on Google Play let you watch crash rates and reviews on a share of users before everyone gets the new version. Prepare the support inbox, the FAQ and the first two updates before launch day. The first week of reviews always teaches you something.
The short version
- Set up the organisation accounts, agreements and payouts first.
- Build the listing like a landing page.
- Inventory every piece of data and every SDK.
- Hand the reviewer everything they need.
- Roll out gradually and listen.
Done properly, publishing becomes a repeatable routine instead of a stressful event. That routine is what we do every day.