To ship your first mobile app as a side project, pick one small job the app does better on a phone than in a browser, build only that loop, and skip accounts if you can. Then budget for the store gates before you write much code: Apple charges 99 USD a year and puts your legal name on the listing if you enroll as an individual, and a new personal Google Play account has to run a closed test with at least 12 testers for 14 days in a row before it can publish. Plan those weeks, pass the common review checks the first time, and keep one evening a year for the platform updates that keep the app listed.
This guide is for developers and makers with a day job and a few hours a week. Store rules and fees below were read on Apple's and Google's own pages in October 2026, so treat them as "as of Oct 2026" and check again before you pay for anything. The example builder near the end is made up, and so are his numbers.
Should your side project be a mobile app at all?
Be honest about this first. A store app costs more than a website: an annual fee on iOS, a review on every release, and platform updates you can't skip. A web app you can ship tonight.
A phone app earns that cost when it needs something a browser does badly: the camera many times a day, background location, working with no signal, or a habit people open ten times a day. If your idea is mostly forms and lists, start with a mobile-friendly web app and add a store app once people use it.
Option | What it costs you | Store review | Fits when |
|---|---|---|---|
Mobile-friendly web app | Hosting only | None | The job is forms, lists or reading, and people open it on a laptop too |
Android only (Google Play) | 25 USD once, plus a 14-day closed test on a new personal account | Yes | Your users are mostly on Android, or you want to learn on one store first |
iOS only (App Store) | 99 USD every year | Yes, every release | Your users are mostly on iPhone |
Both stores | All of the above, twice the listing work | Yes, on both | Version 1 already has people asking for it on both platforms |
My rough judgement: for a first app, pick one store. Choose the one your likely users carry, not the one you own.
What does it cost to get into the app stores?
Here is what each store asks of a solo builder as of Oct 2026.
Apple App Store | Google Play | |
|---|---|---|
Fee | 99 USD per membership year (local prices vary) | 25 USD one-time registration fee |
Account types | Individual, or organization (needs a D-U-N-S Number and a real company) | Personal, or organization |
Identity checks | Legal name, address (no P.O. boxes), two-factor authentication | Legal name and address from your payments profile; you may be asked for a government ID; new personal accounts verify an Android device with the Play Console app |
Before your first public release | App Review, plus Beta App Review for your first external TestFlight build | New personal accounts: closed test with 12+ testers opted in for 14 days in a row, then apply for production access |
Review time | Apple says at least 50% of submissions in under 24 hours and 90% in under 48 hours | Production access review "usually takes seven days or less" |
If you stop paying or updating | Expired membership: apps no longer available to download | Apps that fall behind the target API level stop showing to new users on newer Android versions |
Sources: Apple's Apple Developer Program enrollment requirements, Apple's App Review overview with typical review times and Google's testing requirements for new personal Play Console accounts.
Whose name goes on the store listing?
People with a day job often find this out too late: both stores show real identity details.
Apple, individual account: your personal legal name is shown as the seller name on the App Store. An organization account shows the company name instead, but Apple doesn't accept trade names or DBAs, so you need an actual legal entity and a D-U-N-S Number.
Apple, EU storefronts: if you distribute in the EU and you count as a trader under the Digital Services Act, Apple publishes an address, phone number and email on your product page. Apple says a hobbyist with no plan to make money "may not be considered a trader", but the call is yours. Read Apple's Digital Services Act trader guidance in App Store Connect Help before you tick a box.
Google, personal account: Google shows your legal name, your country and your developer email. If you monetize, it shows your full address. Google's own wording is in its page on what a Play Console developer account needs and what Google displays.
So assume your employer and anyone who searches your name can see that you publish apps. If your contract has a moonlighting or invention clause, read it before you enroll. And use a separate email as the developer contact so support mail stays out of your personal inbox.
What should version 1 of a mobile app include?
One loop, done well on a phone. Write it down as a sentence: "Open the app, do X, see Y." Everything that isn't in that sentence waits.
The core loop and nothing else. One main screen, one action, one result.
No login if you can avoid it. Apple's guidelines say that if your app doesn't have significant account-based features, people should be able to use it without logging in. Local storage on the device is enough for many first apps.
If you do have accounts, deletion inside the app. Apple requires in-app account deletion for any app that supports account creation. Google requires an in-app deletion path and a web link where people can request deletion, per its app account deletion requirements.
A privacy policy URL and a support URL. Both stores ask for a privacy policy link, and Apple asks for a support link with working contact details. Keep the policy short and true to what the app collects. (Not legal advice; if you collect anything sensitive, get proper help.)
A sane offline state. Even a clear "you're offline" screen beats an endless spinner.
Leave out push notifications, sharing, themes, widgets and tablet layouts for now. Each adds review questions and test time.

Native or cross-platform for a side project?
For one store, use whatever you already know that targets it. Cross-platform makes sense when you really will ship both stores and already write JavaScript or Dart; native makes sense when you need deep platform features or know Swift or Kotlin. What matters more is whether you can still update it in a year with two free evenings, which is the point of choosing a side project tech stack you can still maintain.
How do you get 12 testers for Google Play's closed test?
If your personal Play Console account was created after November 13, 2023, Google won't let you publish to production until you run a closed test with at least 12 testers who stayed opted in for at least 14 days in a row. Testers who join and drop out before 14 days don't count, and someone who leaves and rejoins starts their 14 days again. After that you apply for production access, answer questions about the test, and wait for a review that Google says usually takes seven days or less.
So a new Android developer needs at least three weeks from "it works on my phone" to "it's on the store". Plan for it:
Recruit 15 to 20, not 12. Someone always forgets, switches phones or opts out. Google suggests friends, family, coworkers and communities where your future users already are.
Pick testers who match the app. If it's for runners, ask runners. You'll summarise their feedback in the production access form.
Send one clear message. What it does, the one thing to try, how to send feedback, and "please stay opted in for at least 14 days".
Ship at least one update during the test. Fix the first two complaints and push a new build to the closed track. You'll be asked what you changed.
Keep a simple log. Date, tester, what they said, what you changed.
Don't buy testers from a service that promises to tick the box. Google asks whether testers used the features and behaved like real users, and the test is the best free feedback you'll get.

How does beta testing work on iOS?
Apple has no fixed tester count, but it has its own gate. With TestFlight beta testing you can add up to 100 internal testers from your own team and invite up to 10,000 external testers by email or a public link. Your first build for external testers has to be approved by App Review before they can install it. Testers can send screenshots with notes, and crash reports come back to you. For a side project, a public link shared with 10 to 20 well-matched people is plenty.
What gets a first app rejected, and how do you avoid it?
Apple says that on average over 40% of unresolved review issues relate to guideline 2.1, App Completeness: crashes, placeholder content and missing information. Those are the easiest to fix before you submit. Here are the guidelines a small first app most often hits, from Apple's App Review Guidelines as of Oct 2026.
Guideline | What it says, in short | Fix before you submit |
|---|---|---|
2.1 App Completeness | Final versions only; no placeholder text, broken URLs or crashes; demo account info if there's a login | Test on a real device, click every link, put a working demo login in the review notes, keep your backend running during review |
4.2 Minimum Functionality | Apps should be more than a repackaged website | Don't submit a web view of your site; use at least one thing the phone does well |
4.3 Spam | Some crowded app types (flashlight, simple timers, wallpaper and others) need a meaningfully different experience | Pick a narrow use and say what's different in the review notes |
5.1.1(i) Privacy policy | A privacy policy link in App Store Connect and inside the app | Add the link to your settings screen |
5.1.1(v) Account sign-in | No forced login without account features; account deletion in the app if accounts exist | Drop the login, or add a delete-account button |
4.8 Login services | If you use a third-party social login for the main account, also offer an equivalent privacy-focused login option | Use your own email sign-in or no login for version 1 |
2.3.3 Screenshots | Screenshots should show the app in use, not just a title screen or login page | Capture the core loop in action |
Google Play has its own checks. Every app, including ones in closed testing, needs a completed Data safety form and a privacy policy link, even if the app collects nothing. Fill it in from what your code and every SDK actually do.
If you're rejected anyway, fix exactly what the message names and reply in App Store Connect. It's normal on a first app.
What goes on the store listing?
Keep it short and accurate. Apple limits app names to 30 characters and wants screenshots that show the app in use, not a title screen. For the images themselves, the habits in making product screenshots that get clicks carry over well: show the moment the app is useful, with realistic but made-up data, never a real person's details.
Should you charge inside the app?
For version 1, probably not. If you do: on the App Store, selling access to features or content inside the app generally has to use Apple's in-app purchase, and Google Play requires its billing system for in-app purchases with some exceptions. Both stores run a reduced 15% commission for small developers (Apple's Small Business Program and Google's 15% tier on the first 1 million USD of earnings each year), and you usually have to enroll to get it. Google says its fees are changing in some markets, so check your country.
What does it take to keep a mobile app alive?
A website can sit untouched for two years. A store app can't.
Apple membership renewal. If your membership expires, Apple says your apps are no longer available for download and you can't submit updates. Existing installs keep working. Put the renewal date in your calendar.
Google's target API level. Starting August 31, 2026, new apps and updates must target Android 16 (API level 36) to be submitted, and existing apps must target at least Android 15 (API level 35) to stay available to new users on newer devices. Google offers an extension to November 1, 2026 if you request it. Details are on the Android Developers page on Google Play's target API level requirement.
Apple's "still works" rule. Apps that no longer function as intended, or that you no longer support, get removed. Check yearly on the newest iOS.
Your own dependencies. Budget one or two evenings a year to update, rebuild and resubmit.
If you know you won't do that yearly evening, ship a web app instead.
A made-up example: Rangi and Puddlemark
Everything here is made up: the person, the app and every number.
Rangi is a backend developer who shares a dog with two flatmates. Tired of "has she been out yet?" in the group chat, he built Puddlemark, an Android app with one button: log a walk, see the last three. No accounts. Data stays on the phone, and a share button sends the log to the flat chat as text.
He picked Android only because the flatmates and most dog owners he knows from the park use Android. He paid the 25 USD, verified his ID and device, and had a build in two weekends. Then the part he hadn't planned: 12 testers for 14 days. He asked 18 people from the park and his climbing gym; 15 opted in and 13 were still in on day 14. Two testers said the button was too small to hit with a lead in the other hand, so he made it fill half the screen and pushed an update in week two.
In this story, production access came back in five days. One more evening on the listing and the Data safety form (no data collected), then he shipped and put two dates in his calendar: the next target API deadline and a "does it still build?" check.
A 7-day plan to get your first build into testers' hands
Timings are suggestions. It ends with testers using a real build, because the store gates take longer than a week.
Day | Do this | Done when |
|---|---|---|
1 | Write the one-sentence loop and decide: web app, Android, iOS or both | One sentence and one platform choice written down |
2 | Read your employment contract's side-work clauses; set up a separate developer email | You know what your contract says; new inbox ready |
3 | Enroll in the developer program for your store and start identity checks | Fee paid, verification under way |
4 | Build the core loop end to end on a real phone, no login | You can do the loop on your own device |
5 | Write a short privacy policy page and a support page with a contact email | Both URLs live and linked from the app's settings screen |
6 | Message 15 to 20 likely testers with the one thing to try and the 14-day note | At least 12 yeses |
7 | Upload a build to a closed test track or TestFlight and send the invites | First testers have the app installed |
Common traps
Ignoring the 14-day test. Planning an Android launch date before the closed test even starts.
Adding a login "for later". It brings account deletion, password resets and extra review questions. Add accounts when someone needs to sync.
Submitting a website in a wrapper. Apple's 4.2 exists for this. Give the app at least one job a phone does better.
Not checking what's public. Your legal name, maybe your address, and your developer email all appear on the listing.
Letting the membership lapse. On iOS the app quietly disappears from the store when the year runs out.
FAQ
How much does it cost to publish a mobile app?
As of Oct 2026, Google Play charges a one-time 25 USD registration fee and Apple charges 99 USD per membership year, with local prices varying.
Can I publish an app without my real name showing?
Not as an individual. Both stores show your legal name. An organization account shows the company name instead, but needs a real legal entity.
Can I skip Google Play and just share the APK?
For a few friends, for now. Google's Android developer verification program started protections on September 30, 2026 in Brazil, Indonesia, Singapore and Thailand and plans to expand globally in 2027. Google also offers limited distribution accounts so students and hobbyists can share an app with up to 20 devices without a government ID or registration fee.
Is a browser extension or a mobile app the easier first side project?
An extension usually has lighter gates and no yearly fee, and the steps for shipping a browser extension as a side project are shorter. Pick the mobile app when the job really belongs on a phone.
Ship the small app
A first mobile app doesn't need to be clever. It needs one loop that works on a phone, a store account you planned for, a handful of real testers and a reminder for next year's updates. Start the identity checks this week; that clock runs while you build.
And once it's out, list it on SideHunt so other builders and early users can find it.