Launching a mobile app: get found, advertise and stay secure (the complete guide)

An app that works is only half a launch. The other half decides whether anyone finds it, installs it and trusts it with their data: developer accounts and privacy forms, a store listing written for search, a website, perhaps some ads, and the security checks that keep one user’s data away from the next.

This guide shows how to launch a mobile app in four stages, in the order I would tackle them. It is written for small teams, whether the code came from a developer, an agency or an AI builder, and every section points to the detailed article on that step.

I build apps end to end for clients, and software for my own use, so I know what it feels like to need a tool and build it. Putting an app in front of strangers is a different job, and that job is what this guide covers. Prices and rules below are as of 19 October 2026.

How to launch a mobile app: the four stages at a glance

The order matters more than any single tactic. Ads sent to a weak listing waste money, a data leak found after launch costs far more than one found before, and Google’s testing rule can add weeks to an Android launch if you discover it late.

Before launch: developer accounts and testing

Apple: the Apple Developer Program

To publish on the App Store, you join the Apple Developer Program. Apple prices it at 99 US dollars per membership year (about £75) and shows the price in pounds when you enrol; check it on Apple’s enrolment page before you budget (October 2026).

You can enrol as an individual or as an organisation. An organisation must be a legal entity with a D-U-N-S Number, a work email address on its own domain and a public, working website on that domain. Apple turns down social media pages, near-empty sites and registrar holding pages, so if your app has no website yet, build one now: you will need it for the stores and for Google anyway.

Google Play: the Play Console

Google Play charges a one-time registration fee of 25 US dollars (under £20), paid by card (Play Console Help, October 2026). Registration can take up to 48 hours, and Google may ask for an ID in the account holder’s legal name.

The step that catches people out: a personal account created after 13 November 2023, which includes any new one, must run a closed test with at least 12 testers, opted in for 14 days in a row, before it can apply for production access (Google’s rule for new personal accounts). Line up your testers (clients, staff, friends with Android phones) before you need them, and allow at least three weeks between the start of the test and your Android launch.

iPhone or Android first?

If you cannot launch both at once, start where your customers are. Statcounter’s web traffic estimates put iPhones at about half of mobile traffic in the UK in August 2026, against about a third in France, where Android leads. Your own figures, from your website analytics or your customer list, beat any national average.

Built with AI, by an agency, or for your team only

How the app was built changes the risks, not the launch steps. If you are building it yourself, my guide to what is realistic when you build an app with AI draws the line: AI builders suit a small tool for you or your team, and a developer becomes necessary once the app stores clients’ personal data, has customer logins or takes payments. AI has shortened my own delivery times a lot; it has not shortened this list.

If the app is only for your team, like the internal CRM I built for a client whose leads piled up, the marketing half of this guide does not apply: nobody needs to find it in a store or click an ad. The privacy and security half still does.

Privacy: what the stores ask and what the law asks

Two jobs get mixed up here. The stores want a description of the data your app collects; the law, in the EU and the UK, wants your users’ consent before some of that collection starts.

• Apple’s privacy labels: since 8 December 2020, every new app and update needs privacy answers in App Store Connect, shown on your product page. They cover the SDKs you add as well as your own code.
• Google Play’s Data safety form: required since 20 July 2022 for every app, including apps that collect nothing, and answered in Play Console under App content.
• Account deletion: if people can create an account, Apple has required since 30 June 2022 that they can start deleting it inside the app, and Google Play asks for an in-app option plus a web link.
• Tracking on iOS: since iOS 14.5 (26 April 2021), App Tracking Transparency means you show Apple’s prompt and get permission before tracking people across other companies’ apps and websites or reading the advertising identifier.

My tutorial on privacy labels, the Data safety section and GDPR consent walks through both store forms and the consent your SDKs need.

Consent is where the EU and the UK now differ. In the EU, analytics and advertising SDKs that read or store data on the phone generally need consent before they run, and the CNIL’s recommendations on mobile apps (September 2024) add that an operating-system permission should not be confused with GDPR consent. In the UK, since 5 February 2026, analytics used only for statistics can run without consent as long as you inform users and let them object; advertising SDKs still need consent. For the rest of the subject, see my GDPR guide for small teams, inside and outside the EU.

This guide explains the rules and the official guidance; it is not legal advice. If your app handles health or financial data, or data about children, paying a lawyer or a DPO to review it before launch is money well spent.

Security: the checks to do before you ship

Store review checks the app you submit, not the server behind it, so an app can pass review and still hand one user’s data to another. Four articles cover the work, in this order:

1. The mobile app security checklist turns OWASP MASVS, the reference standard for mobile app security, into checks you can run before launch: no secret keys in the app, permissions checked by your server on every request, tokens kept in the iOS Keychain or the Android Keystore, encrypted traffic, audited SDKs and a published way to report vulnerabilities.
2. API keys in a mobile app explains why anyone can pull a key out of your app, and where secret keys for services such as OpenAI, Claude or Stripe belong instead: on a server, behind a small function that checks the user first.
3. Is your AI-built app leaking data? is for apps whose AI builder connected them straight to Supabase or Firebase. There, row level security or Firebase’s Security Rules are the only lock on your data, and the tutorial shows how to test them the way a stranger would.
4. The EU Cyber Resilience Act and your app covers the law that now sits on top of all this.

The Cyber Resilience Act (Regulation (EU) 2024/2847, full text on EUR-Lex) makes security a legal duty as well as a practical one. As of 19 October 2026, its reporting duties have applied since 11 September 2026: if a vulnerability in your app is actively exploited, or a severe incident hits it, you send an early warning within 24 hours through ENISA’s Single Reporting Platform (Article 14). Most other requirements, including security updates for the app’s support period and the CE marking, apply from 11 December 2027, to new apps and to apps already on the market that change substantially after that date (Article 69). Micro and small enterprises cannot be fined for missing the 24-hour early warning (Article 64(10)), but the 72-hour notification and the final report still apply to them.

In the UK, the government’s voluntary code of practice for app store operators and app developers already asks for something similar: a vulnerability disclosure process that people can reach from your store listing. For the rest of your business (a password manager and two-factor authentication, backups, a check before paying new bank details, a plan for the first hour of an incident), see my cybersecurity guide for small teams.

Get found: app store optimisation

ASO is SEO for the App Store and Google Play: choosing the words each store matches against searches, then making your listing convincing enough that people install. The two stores read different fields, which is why one copy pasted into both rarely works.

Start with my beginner’s guide to ASO, which explains how each store ranks apps and which parts you control. Then ASO keyword research shows how to find the words people really type in the store search bars, from your users’ own phrases to store suggestions, rival listings and the search popularity score in Apple Ads, and why a new app should go after specific phrases before broad ones. The store listing tutorial turns those words into a name, subtitle, keyword field and description that respect each field’s limit.

Write the first line of your description as a plain sentence that says what the app does and for whom, and make your first screenshots show the app doing exactly that. Once you have steady traffic, both stores let you test alternatives: Apple’s product page optimisation runs up to three variants against your original page, and Google Play’s store listing experiments do the same.

Your app’s website: the half Google can see

The stores rank your listing; Google ranks your website. They answer different searches, so your site needs web keywords of its own: the words people type into Google before they know your app exists.

SEO for your app’s website covers the landing page (the problem it solves, real screenshots, the official store badges, an FAQ), the privacy and support pages your listings link to, and the connections between site and app. Universal Links on iOS and Android App Links open your web addresses in the app when it is installed, and Apple’s Smart App Banner invites iPhone visitors to install the app without hiding the page. If older links of yours relied on Firebase Dynamic Links, replace them: Google shut the service down on 25 August 2025.

A small site is enough to start: a landing page, a privacy page and a support page. It is also part of what Apple asks of organisations at enrolment, so it belongs at the top of the to-do list. Websites are a large part of my work, and a simple one can go live well before the app does.

Advertise: Apple Ads, Google App campaigns or Meta

Paid installs only pay off when the page they land on converts. Before you spend, make sure your listing turns visitors into installs, you have a handful of genuine reviews and your installs are measured. Then choose one platform:

• Apple Ads (called Apple Search Ads until April 2025) shows your app at the top of App Store search results, and also in the Today tab, the Search tab and on other apps’ product pages. The Apple Ads tutorial sets up a first campaign step by step: exact match keywords for your brand and category, a daily budget, a maximum cost-per-tap bid and a discovery campaign that finds new searches.
• Google App campaigns turn the text, images and videos you supply into ads on Google Search, YouTube, Discover, the Display Network and, for Android apps, Google Play, all from one campaign. How Google App campaigns work explains the budget rule that surprises people: Google advises a daily budget of at least 50 times your target cost per install, so a £1 target means £50 a day, about £1,520 a month.
• Meta (Facebook and Instagram) reaches people who are not searching yet, which suits an app that explains itself in a short video.

To choose, read where to spend your app’s first £1,000. Its advice is one platform, not three: Apple Ads if people search the App Store for what your app does and many of your users have iPhones, Google if they are mostly on Android, Meta if the app sells itself on screen.

My own view of these platforms comes from ads in general, not from app installs. Google Ads is not that tricky, but it rewards the research you do on what people search before you spend; my guide to Google Ads basics covers that research. Facebook and Instagram ads work for awareness and for conversion, but you will burn some budget on A/B tests before you know what works, and skipping those tests is one of the mistakes I warn founders about.

Measurement is the hard part on iOS. Since App Tracking Transparency, people who decline the prompt cannot be followed across apps, so ad platforms fall back on Apple’s privacy-preserving attribution frameworks (SKAdNetwork and AdAttributionKit) and on modelling. Expect delayed, grouped figures rather than a record of every install, judge a campaign on its cost per install after two weeks rather than after two days, and make sure your analytics SDK receives each user’s consent choice (Google’s consent mode for apps does this for Firebase).

After launch: reviews, updates and the numbers that matter

Ratings and reviews

Apple says ratings and reviews can influence how your app ranks in App Store search, and they sit at the top of your listing for every visitor to see. Getting more five-star reviews without breaking store rules explains how to ask: only through the official prompts (Apple’s, which the system shows at most three times a year to each person, and Google Play’s In-App Review API), right after a moment of success, never in exchange for a reward and never only from people who say they are happy. Fake reviews break UK and EU consumer law as well as store rules.

Reply to reviews, and fix what they report. Google Play weights its public rating towards recent ratings, so an update that fixes a common complaint shows up in your score.

Updates and stability

Crashes cost you twice: in reviews, and on Google Play in visibility. Google says an app’s core vitals affect its visibility, and above its bad behaviour thresholds (a user-perceived crash rate of 1.09% overall, or 0.47% for “app not responding” freezes) Play may reduce the app’s visibility and show a warning on its listing. Check Android vitals in Play Console and your crash reports every week during the first month.

Plan updates as part of the launch, not as an afterthought: for an app released or substantially changed from 11 December 2027, the Cyber Resilience Act will require security updates throughout its support period, usually at least five years.

The numbers that matter

Downloads alone tell you little. Four numbers tell you where the problem is:

1. Impressions and product page views: whether the stores show your app at all. Low numbers point to keywords.
2. Conversion rate: App Store Connect divides downloads by unique impressions, and Play Console compares listing visitors with installs. A low rate points to the listing: screenshots, first line, ratings.
3. Installs by source: search, browsing, other apps, websites, ads. App Store Connect shows how many people came from search, not what they typed; Play Console can show the search terms that led to your listing.
4. Retention: the share of new users who still open the app a day, a week and a month after installing. Ads cannot fix weak retention; changes to the app can.

Your launch checklist, and when to hand it over

1. Developer accounts open; for a new personal Google Play account, 12 testers lined up for a 14-day closed test.
2. A website live with a landing page, a privacy page and a support page.
3. Privacy labels and the Data safety form answered for your app and its SDKs; consent in place before analytics and advertising SDKs run; account deletion inside the app.
4. Security checklist done: no secret keys in the app, database rules tested, a published way to report vulnerabilities.
5. Store listing written from keyword research, with screenshots that show the app’s main job.
6. Review prompt placed after a moment of success.
7. Installs measured, then one ad platform with one budget.
8. A named person and a process for reporting an actively exploited vulnerability within 24 hours.

You do not need anyone for the listing, the keyword research or replying to reviews: those are writing jobs, and nobody knows your users better than you do. Bring in a developer for the parts where a mistake leaks data: the server, the database rules, the keys and the sign-in. Pay for an independent security test once the app handles health, financial or children’s data.

When I build an app for a client, I build all of it, with 30% or 50% paid upfront and the rest at delivery. Whoever builds yours, ask before you sign who will handle the store accounts, the privacy forms and the security updates after launch: they are part of launching a mobile app, not extras.