Shipping to the app stores alone
The build is not the hard part. The two weeks between “it works” and “it is live” are where first-time solo developers lose a month, almost always to the same short list of things.
The short version
- Open the accounts first. Verification and Google Play's testing requirement for new personal accounts are measured in weeks, and they run in parallel with development if you start early.
- Budget roughly $99 a year plus $25 once for the two developer accounts, before commission.
- Most first rejections are not bugs. They are payments, privacy, account deletion and thin functionality.
- The listing is an ad, and the first two lines and the first screenshot are nearly all of it.
- The store is a channel, not a strategy. Nobody finds a new app by browsing; the launch still has to happen somewhere else.
Is a store worth it at all?
If the product is genuinely mobile (used standing up, needing notifications, the camera or offline access), yes. If it is a web app you are wrapping so it can say it has an app, the stores will cost you weeks and give you a slower version of a site you already had.
What the stores actually give a solo developer is trust and billing. Being listed is a credential, in-app purchase handles tax and refunds worldwide, and updates reach everyone without you running anything. What they do not give you is discovery: search results for anything valuable are dominated by companies with budgets, and browsing is not how people find apps.
So treat a listing as the place a launch lands rather than the launch itself. The people who install in week one will come from the same places as any other product, which is the same argument as launching a SaaS, and it does not change because there is an icon involved.
What it costs
| Apple | ||
|---|---|---|
| Developer account | $99 per year | $25, once |
| Standard commission on digital sales | 30% | 30% |
| Reduced commission | 15% under the Small Business Program | 15% on the first $1M per year |
| Subscriptions after year one | 15% | 15% |
| Free apps with no digital sales | No commission | No commission |
Both reduced rates apply to roughly the first million dollars a year, which is to say: to you. Apple's requires enrolling in the Small Business Program: it is not automatic, and forgetting to enrol is money handed over for nothing. These programmes and thresholds change; check the current terms before you build a spreadsheet on them.
The costs that are not on the list are the ones that hurt: an Apple device to build and test on, and the time. Two weeks of assets, policies, metadata and review is a reasonable estimate for a first submission, and it is roughly the same amount of work whether the app took two months or two years.
How long it takes
| Stage | Realistic time |
|---|---|
| Apple account verification | 1–5 days, longer for a company entity |
| Google Play account verification | 1–7 days |
| Google Play closed testing (new personal accounts) | Weeks: a required testing period before production access |
| Apple review, per submission | Usually under 48 hours |
| Google review, first submission | Days rather than hours; faster afterwards |
| A rejection and a resubmission | Add 1–3 days each time |
The row that ruins launch dates. New personal Google Play accounts have to run a closed test with a group of testers for a set period before they can publish to production. It is weeks, it cannot be shortened, and it is invisible until you go looking. Start the account the day you decide to ship.
Plan for two rejections. Not because your app is bad, but because the first submission is where you find out which of the rules you misread, and the round trip is short if you have not announced a date to anyone.
What to have ready before you submit
- A reachable privacy policy at a stable URL, describing what you actually collect. Both stores check that the link loads.
- Accurate data disclosures: Apple's privacy nutrition labels, Google's Data safety form. Wrong answers here are treated as misrepresentation, not as a mistake.
- Account deletion, reachable from inside the app, if users can create an account at all.
- Store-native purchases for digital goods. Your own checkout for digital content inside the app is the classic rejection.
- Screenshots at the required sizes, for every device class you claim to support.
- A demo account with working credentials if anything is behind a login. A reviewer who cannot get in rejects the build.
- Support contact and a URL that resolves. A dead support link is an easy rejection to avoid and a common one to receive.
- Age rating answered honestly, including any user-generated content and any external links.
The rejections that catch first-timers
| What happened | Why it was rejected |
|---|---|
| Selling a subscription through your own checkout in the app | Digital goods must use the store's purchase system |
| Accounts can be created but not deleted | Both stores require in-app account deletion |
| Data disclosures do not match what the app does | Treated as an inaccurate declaration |
| The app is a wrapper around a website | Minimum functionality: it has to be more than the site |
| Login required with no demo credentials | The reviewer could not see the app |
| Third-party sign-in only, on iOS | An equivalent private option may be required alongside it |
| Placeholder text, lorem ipsum, or a broken link in the listing | Incomplete submission |
Read the rejection message rather than guessing at it. Both stores tell you the specific guideline, and both let you reply: a short, factual response explaining what the app does resolves a surprising number of borderline cases without any code change. Arguing does not.
The listing is an ad
Almost nobody reads past the first two lines of the description or swipes past the first screenshot. Those two things are the listing; everything below is for the small number of people already deciding to install.
- The title carries the search term, not a slogan. A name plus three words of what it does beats a clever name alone.
- The first screenshot states the benefit in text over the UI. A bare screenshot of your empty home screen sells nothing.
- The first two lines answer “what is this and who is it for” in plain words, before any feature list.
- Keywords go where the store looks for them, which on iOS is a dedicated field and on Android is the description itself.
- Ask for reviews after a success in the app, never on launch, and never twice.
Desktop and web, for comparison
The mobile stores are not the only distribution, and for a lot of small software they are not the best. Shipping a desktop app or a web app from your own site means no commission, no review, no waiting, and a direct relationship with the customer, at the cost of doing your own billing, your own tax, your own updates, and your own credibility.
| Channel | Commission | Review | Who owns the customer |
|---|---|---|---|
| App Store / Google Play | 15–30% | Yes, every update | The store |
| Mac App Store / Microsoft Store | 12–30% | Yes | The store |
| Direct download, own checkout | Payment fees only | No | You |
| Web app, own checkout | Payment fees only | No | You |
The pragmatic order for a solo founder is usually: ship on the web first because it has no gatekeeper, then add a store listing once there is something to point people at. Which channel you can afford also depends on how you charge, since a store takes its cut of every model: that is the other half of the subscription-or-one-time decision.
The system behind this, written down
Everything above is the map. The Income Loop is the work inside it: modules 0–6 from the problem you solve to the offer that pays for it, plus ten traffic paths: the deeper post banks, the content sales systems and the full software build sequence, in one place.
Get The Income LoopNot ready to pay for anything? The Basic Income Loop is free and includes a complete seven-day starter for Threads, Instagram or software, enough to find out which one suits you before spending anything.