Making an app for Android used to begin with a download: Android Studio, a Java runtime, a build tool, and a fake phone on your screen that took a minute to boot and still lied about how the real thing felt. None of that is the shape of the work now. You describe the app, it gets built, and the build runs in the cloud.
What has not changed is Google Play. You need your own developer account, an app that does something useful on a phone, and honest answers to the questions Google asks about your data. This guide covers the whole path, and it is specific about the gate that catches most first-time developers.
QUICK ANSWER
How do you make an app for Android?
Describe the app in plain language and AI builds it as a real Android app inside your project, with its own backend and database. Preview it on your phone as you go. The build runs in the cloud, so there is no emulator and no local toolchain. You need your own Google Play developer account, and you start the release yourself.
What you need before anything gets built
Only one of these is technical. The other four are decisions and accounts, and the account is the one with somebody else’s queue in it, so start there.
- Your own Google Play developer account: Google’s Play Console registration page said on 2026-08-16 that there is a one-time registration fee of 25 USD, and that you may be asked for a valid government ID and a card in your legal name. Treat the figure as something to re-check, not a fixed price. The account is yours, not your agency’s and not ours.
- A real Android phone, or somebody who owns one: There is no emulator anywhere in this path, by design. You preview the app on an actual phone while you build, and you install a real test build from Play before you go public. Borrow a mid-range phone rather than the newest flagship: it is the one that will show you what your customers actually see.
- A decision about which testing gate you are behind: Google requires personal accounts created after 13 November 2023 to run a closed test with at least 12 testers opted in continuously for 14 days before they can apply for production access. It does not apply to every account. Find out which side of it you are on now, because it is 14 days of calendar time you cannot compress.
- One thing the app does that a browser tab cannot: A store listing is not a marketing channel you get for free. If the job is a form, a booking flow or a dashboard, a web app opens on every phone with no account, no fee and no review. Write down the reason the app has to be installed before you commit to the store path.
- A public address the phone can reach: A phone is a different machine from your laptop. It cannot see localhost and it cannot see a port that only exists on a development server. The app has to talk to a public HTTPS address. On Playcode that is already true, because the project is published on its own link and the app is pointed at it for you.
Credentials and access
| Credential | Minimum access | Storage and rotation |
|---|---|---|
| Play Console account and release permissions Human identity and organisation membership | Give each person the narrowest Play Console permission that lets them do their job. Keep account ownership with the legal owner of the business, not with a contractor or an agency. | Protect the Google Account with two-factor authentication and an address you will still control in three years. Never paste a password or recovery code into a chat message. Remove people when they leave, review permissions before each release, and keep more than one person able to publish so a holiday does not block a fix. |
| App signing and upload key Private key that proves an uploaded bundle is yours | Restrict use to the release job and to named release owners. Play App Signing splits the key Google distributes with from the upload key you keep, and the two are not interchangeable. | Keep the key and its password in project secrets or an approved secrets system, never in source, screenshots, chat or logs. On Playcode the agent stores credentials as project secrets rather than in the conversation. Write down the Play Console recovery path before you need it, along with any certificate fingerprint a third-party API is pinned to. Losing the upload key without a recovery path costs you the ability to update your own app. |
| Play service account for automated upload Service credential used by the build service to submit | One service account, scoped to upload to the tracks you actually use. It removes the need for an interactive login during a release. | Store the key as a project secret. Anything that can upload under your identity should be treated like a password. Revoke and replace on a schedule and after any suspected exposure. Confirm an upload still works after rotation, before you need one urgently. |
Three ways to put something on an Android phone
These are genuinely different trades, not three names for the same thing. Only two end with a Play Store listing, and the cheapest one is what most first products actually need.
| Approach | Best for | Tradeoff |
|---|---|---|
| A web app people open from a link | A form, a booking flow, a dashboard or a portal, where the audience arrives from a link you send them. It opens on every phone and can be added to the home screen. | No Play listing, no store search, and none of the credibility an installed app carries. You trade reach and status for zero accounts, zero fees and zero review queue. |
| An Android app built in the cloud from one description | A product that needs to be in Google Play, and a team that does not want to own an Android toolchain or a second codebase. This is the Playcode path: the phone app, the web app and the backend live in one project and share one set of accounts. | You depend on the build service supporting your libraries, and anything with unusual native code needs checking before you commit. You still own the Play account, the declarations and the release. |
| Native Kotlin and Compose in Android Studio | A product whose core feature is a deep Android capability, or a team already shipping Android continuously with people who know the platform. | A local toolchain per developer, a separate codebase from your website, and the whole release apparatus to run yourself. It is the right answer eventually for a hardware-heavy product and the wrong first investment for a first release. |
Recommended:Start with the web app when the job is a form, a dashboard or a booking flow, because there is nothing to sign and nothing to submit. Move to a store app when you need an icon on the home screen, a listing people can find, or something that only makes sense on a phone. Write native Kotlin when you can name the specific Android capability that forced it.
How to make an app for Android
Open the Play Console account, describe the app, test it on a real phone, complete Google’s declarations, run the cloud build, and release it through the testing tracks to production.
STEP 01
Open the Play Console account and find out which gate applies
The account has a queue and the testing rule has a calendar. Both start now, not the week you want to launch.
Register at Play Console. Google’s get-started page said on 2026-08-16 that there is a one-time 25 USD registration fee and that you may be asked for a government ID and a card under your legal name. Register under the name you want on the listing, because that becomes your public developer name.
Check which testing requirement applies to you. Google requires personal accounts created after 13 November 2023 to run a closed test with at least 12 testers opted in continuously for 14 days before applying for production access. Recruit those testers on day one; the 14 days runs whether or not your app is finished.
Turn on two-factor authentication for the Google Account and use an address you will still control in three years. Whoever holds this account controls your ability to update your own app.
Expected result: A Play Console account you can sign in to, with a clear answer to whether the 12-tester gate applies to you.
Verify it: Create the app record in Play Console. If it saves and the dashboard shows you the setup tasks, the account is genuinely ready rather than half-registered.
STEP 02
Write down the one job the first version does
A first release that does one thing completely is testable. A pile of half-finished screens is not.
Name the person who opens the app, what they do in it, what gets saved, and what they see afterwards. Then write what they see when it is loading, when they are offline, when the input is wrong, and when the server says no. Those four unhappy states are most of the work, and on Android the offline one is not optional.
Keep the rest of the roadmap out of version one. Every extra feature adds review surface and testing surface without adding evidence that anybody wants the app.
This paragraph is also your prompt. You do not need to name a language, a database or a screen layout; you need to describe the job.
One job: a surveyor writes a field note on site and it arrives when the signal does.
Who signs in: a surveyor who belongs to one company.
What gets saved: the note, on the server, against today's survey.
What they see after: the note in the list, marked sent.
Loading: a skeleton, not a blank screen.
Offline: the note is kept on the phone and queued, shown as "waiting to send".
Wrong input: an empty note is refused next to the field, keeping what was typed.
Server says no: a plain message and a retry that does not create two notes.
Not in version one: photos, maps, scheduling, notifications.Expected result: One paragraph describing a single complete task, with its four unhappy states written beside it.
Verify it: Read it to somebody who has not seen the product. If they can repeat the task back and say what happens when it fails, it is specific enough to build.
STEP 03
Describe the app and get a working version
On Playcode you write the brief in ordinary words and get a project that already contains the phone app, the web app and the backend.
Paste the paragraph you wrote and let it get built. Playcode builds the mobile app with React Native and Expo, in the same project as the web app and the backend, so one description covers the phone, the browser and the database behind both.
The phone app and the website share the same accounts, because they call the same backend. Somebody who signs up on your site can sign in on the phone with no extra work. That is what most app builders cannot do, and it is the reason to keep both in one project rather than two.
Ask for changes the same way you asked for the app. The point of this step is a running app, not a finished one.
Expected result: A project containing an Android app alongside the web app and the backend, running without errors.
Verify it: Complete the task once in the preview, reload, and check the record is still there. If it survives a reload it is really in the database rather than held in memory.
STEP 04
Set the identity and the offline behaviour
The package name is permanent, and the offline path is the difference between an Android app and a website in a box.
Set the package name in reverse-domain form, such as com.yourcompany.yourapp, using a domain you control. It is permanent once an app exists in Play Console under it, and creating a second record to fix it splits your app in two.
Add the app name and the icon now. They are required for the release and leaving them until the end is how an upload fails at the last minute.
Make the queued state honest. If a note is saved on the phone but not yet accepted by the server, the app must say so rather than showing it as sent. Give each save one identity that survives a retry, so pressing the button twice on a bad signal makes one record and not two. This is the single most common data bug in a mobile app.
Expected result: An app that starts with your icon and your name, saves offline, and never shows a queued item as confirmed.
Verify it: Turn on airplane mode, save, force-close the app, reopen it, and turn the network back on. Exactly one record should appear on the server, and the phone should have told the truth at every stage.
STEP 05
Test it on a real Android phone, not an emulator
Preview it on your phone by scanning a code. There is no emulator here, and you will not miss it.
Start the mobile preview and open it on an Android phone. Check what a laptop cannot show you: whether the tap targets are reachable with a thumb, whether the keyboard covers the field you are typing in, whether the back gesture does something sensible, and whether the app survives being switched away from and returned to.
Test on a mid-range phone and on a slow connection. Android is not one device, and the phone your customers own is rarely the phone on your desk.
If a screen breaks only on the phone, look first at anything with custom native code. Libraries that ship their own native code cannot load in a quick preview; they need a full build. Prefer a plain JavaScript alternative until you are past your first release.
Expected result: The complete task works on a physical Android phone, including the offline and wrong-input paths.
Verify it: Do the whole task on the phone with the laptop closed. Anything you have to explain away is a defect, not a quirk.
STEP 06
Break it on purpose before a tester does
Your 12 testers are about to use the app badly on networks you did not choose. Go there first.
Deny every permission the app asks for and check the main job still works. A permission is a request, not a guarantee, and an app that dead-ends when notifications are refused is an app people uninstall.
Turn the font size up to the largest accessibility setting and open every screen. Fixed-height rows and text that cannot wrap are the most common way a good-looking app becomes unusable for a real customer.
Sign in as a second account and try to open the first account’s records. The server has to refuse that, regardless of what the app shows. A hidden button is not a permission.
Expected result: The app is usable with permissions denied, at the largest font size, and refuses to show one customer another customer’s data.
Verify it: Write down each phone, font size, permission state and account you tried, and what happened. One unexplained result is a reason to hold the release.
STEP 07
Complete Google’s declarations before you upload
These are questions about your app, not paperwork you can delegate. Getting them wrong is slower to fix than getting them slowly.
Fill in the Data safety form. Google requires every developer to declare how the app collects and handles user data, including data handled by any third-party library in it, and reviews the form as part of app review. Answer from what the app actually does today, not from what you intend it to do.
If people can create an account in your app, Google requires both an in-app way to delete that account and a web link where deletion can be requested. Build both before you submit. It is a small feature that blocks a release when it is missing.
Complete the store listing, the content rating questionnaire, the target audience answers, and the app access instructions. If a reviewer needs to sign in, give them a working account that is not one of your real customers.
Expected result: Every setup task in Play Console is complete, and the declarations describe the app you are actually about to upload.
Verify it: Open the app on your phone with the Data safety answers next to you and check them line by line. Every data type you declare should be one you can point at, and every one you can point at should be declared.
STEP 08
Run the cloud build and release to a testing track
This is the step that used to need a local toolchain, and the step a hosted build service does for you.
The build runs in the cloud. Expo documents that EAS Build produces installable binaries and manages app signing credentials, and that the submit step uploads the app bundle to Play Console and places it in the track you choose. A brand new app defaults to internal testing.
Google moves the minimum Android version an app must target. Its target API level page stated on 2026-08-16 that from 31 August 2026, new apps and updates must target Android 16 (API level 36) or higher, with an extension available to 1 November 2026. You do not set this by hand on Playcode, but it is the sort of rule that turns a working build into a rejected upload.
On Playcode you do not run the build commands yourself. Describe what you want, and the agent drives the build, asks for the credentials it needs, and stores them as project secrets rather than in the conversation. Never paste a signing key or a service-account key into a message.
Expected result: A signed app bundle uploaded to a testing track, installable through a Play link by somebody who is not you.
Verify it: Have a tester install it from the Play link on a phone that has never seen the app, and complete the whole task. An install that works on your phone via a cable proves nothing about the store path.
STEP 09
Publish to production and control when it goes live
Approval and publication are two different events, and you can hold the second one.
Google says on its publishing page that processing can take a few hours or up to seven days, or longer in exceptional cases, because it depends on the review your app is subject to. That is planning guidance, not a promise. Do not tell anybody a launch date you have not already got approval for.
Managed publishing holds approved changes until you decide to publish. Use it when the release has to line up with something else, such as an announcement or a customer meeting. Note that it is not available for an app being published for the first time.
A first production release goes to everyone in the countries you chose; the percentage-based staged rollout is for updates. Choose your countries deliberately rather than selecting everywhere by default on day one.
Expected result: A production release live in the countries you chose, published at a moment you picked rather than one Google picked.
Verify it: Install the public listing on a phone that has never seen the app, with a brand new account, over mobile data. That is the run that catches an app still pointing at a development address.
STEP 10
Stage updates, watch the vitals, and fix forward
You cannot un-ship an update. Everything after the first release is about limiting how many people get a bad one.
Roll updates out to a percentage of users rather than everyone, and watch before you expand. A staged rollout does not increase itself, which is a feature: nothing goes wide while you are asleep.
Halting a rollout stops new people receiving the version. It does not remove it from phones that already have it. The recovery is a higher version number with the fix in it, so keep the backend compatible with the version people are still running.
Keep the phone app and the website moving together. They share a backend, so a change to the data model touches both. When the fault is on the server, fix it there: that reaches every installed copy immediately without any review at all.
Expected result: A repeatable update: staged, watched, and reversible in effect even though the binary itself is not.
Verify it: After each rollout step, compare crash and error rates against the previous version before expanding. Expanding on a schedule instead of on evidence is how a small bug becomes an incident.
What the result can look like
The four tests to run before anybody else sees it
A screen that looks right proves rendering and nothing else. These four cases are the ones that turn into uninstalls, one-star reviews and a blocked release.
| Test | Scenario | Expected result |
|---|---|---|
| happy path | On a real Android phone, sign in, complete the one task the app exists for, close the app, and open it again. | The record is saved on the server. It is still there after reopening, and the same record appears when you sign in to the web version of the same project. |
| invalid input | Submit the main form with a required field empty, with a value far longer than the field expects, with every permission denied, and while signed in as an account that does not own the record. | The app explains what is wrong next to the field and keeps what was typed. The main job still works with permissions denied. The server refuses the unauthorised write regardless of what the app shows. |
| retry | Turn on airplane mode, save, force-close the app, reopen it, press retry several times, then restore the network. | The queued item is still there after the app was killed, it is shown as waiting rather than sent, and the retries produce exactly one record on the server. |
| production smoke | Install the published listing on a phone that has never seen the app, with a brand new account, over mobile data rather than wifi. | A clean install signs up, completes the task, and shows the result. The account-deletion path Google requires is reachable from inside the app and from the web link you declared. |
What breaks, and what to do about it
Every one of these has been somebody’s entire delay. Diagnose from the boundary that owns the symptom rather than asking for rewrites until the error goes away.
| Symptom | Likely cause | Check | Fix |
|---|---|---|---|
| It works in the browser preview and shows nothing on the phone. | The app is calling an address only your development machine can see, usually localhost or an internal port. | Open the same API address in the phone’s browser. If it does not load there, the app was never going to reach it either. | Point the app at the project public HTTPS address through configuration rather than a value typed into the code, then reload it on the phone. |
| A library fails the moment its screen opens in the phone preview. | The library ships its own native code. A quick preview can only run the native code it was built with. | Remove the screen that imports it and see whether the app starts. If it does, that library is the cause. | Swap it for a JavaScript-only alternative, or accept that this feature can only be tested in a full build. Decide before your first release, not during it. |
| Records duplicate or vanish after a spell of bad signal. | Each retry creates a new identity, or the app treats a local save as server confirmation and clears the queue too early. | Trace one save from the tap to the server: does the retry carry the same identity, and is the local copy cleared only after the server actually accepted it? | Give each logical save one identity that survives retries, make the server ignore a repeat of the same identity, and clear the local copy only on a real server response. |
| Play Console will not let you apply for production access. | A personal account created after 13 November 2023 has not completed the closed test with 12 testers continuously opted in for 14 days, or the app setup tasks are unfinished. | Check the account creation date, the closed-track tester count, whether any tester opted out and reset the clock, and the outstanding tasks on the dashboard. | Recruit enough real testers, keep them opted in without a gap, finish the setup tasks, and apply with honest answers. The rule does not apply to every account, so check yours rather than assuming. |
| The upload is rejected for the package name, version or target API. | The package name changed, the version code did not increase, or the build does not meet the current target API requirement. | Compare the rejected upload against the previous release: package name, version code, and signing identity. Then re-read the target API page, because the deadline moves. | Restore the original package name, increase the version code, rebuild against the required target, and upload again. A version code can never be reused. |
| Review flags a mismatch between the app and the Data safety answers. | A declared data type is missing, or a third-party library collects something the form does not mention. | List what leaves the phone, including anything sent by a library rather than by your own code, and compare it line by line with the form. | Remove the collection you do not need, correct the form for what remains, and resubmit. Approval of a previous version is not a defence for the current one. |
| A bad update is still reaching people after the rollout was halted. | Halting stops new installs of that version; it does not remove it from phones that already have it. | Split your crash and error data by app version to see how many people are on the bad one, and check whether your backend still supports them. | Keep the backend compatible with the version they are stuck on, ship a higher version with the fix, and mitigate on the server in the meantime. |
Release, watch, recover
Deploy
Keep the version code and version name in the project rather than in your head. Every upload needs a version code that has never been used, and matching a crash to a version is impossible without the record.
Use the testing tracks in order. Internal for the people in the room, closed for the testers Google counts, production when both have been quiet for a while.
Release one change at a time when you can. When something breaks after a release containing six changes, you have six suspects and a bad afternoon.
Monitor
Watch crashes and app-not-responding rates by app version after each release. A rate that rises the day after a release is the release.
Watch your backend errors at the same time. The phone app and the website share it, so a fault caused by the phone shows up in the same place as one caused by the browser.
Track how many people finish the one task the app exists for, not how many installed it. Installs say the listing works. Completions say the app works.
Recover
There is no rollback for something already installed. Recovery is a higher version code with the fix in it, so keep the previous build and be able to rebuild it.
Keep the backend compatible with the oldest version people are still running. Users update on their own schedule, and some of them never do.
Take a snapshot of the project before a risky change, so you can restore code, files and database together and try again rather than reconstructing from memory.
The parts a generated app must not get wrong
An installed app can be taken apart by anyone who downloads it. Assume that, and keep every decision that matters on the server.
- Never ship a private key, a database credential or an admin token inside the app. Anything in an app bundle can be read. Keys belong on your backend, which is one more reason the app should talk only to your own server.
- Make the server decide what each account may read and write, for every single request. A hidden screen is not a permission. Test it with two accounts before a stranger tests it for you.
- Ask for a permission at the moment it becomes useful, explain why, and keep the main job working when it is refused. Do not collect precise location, contacts or files because they might be handy later.
- Scope everything the app stores on the phone to the signed-in account, and clear it on sign-out. A shared phone is a normal situation, not an edge case.
- The Play Console account must be in your name or your company’s name, never a contractor’s personal account. Whoever holds it controls your ability to update your own app.
- Keep signing keys and service-account keys in project secrets, never in chat messages, code or a committed file. A credential that has appeared in a conversation should be treated as leaked and replaced.
- Answer the Data safety form from what the app collects today. An inaccurate answer is a compliance problem once the app is live, and Google reviews the form as part of app review.
Questions people ask about making an app for Android
Do I need Android Studio or an emulator to make an Android app?
No. The build runs in the cloud on a hosted service, so there is no local Android toolchain to install and no emulator anywhere in the path. You preview the app on your own phone by scanning a code, which is a better test than an emulator ever was.
Do I need to know Kotlin or Java?
No. You describe what the app should do in ordinary language and get a real project back. Playcode builds the phone app with React Native and Expo in the same project as your website and your backend, so there is one thing to maintain rather than two.
What does it cost to publish on Google Play?
Google listed a one-time registration fee of 25 USD on its Play Console get-started page when we checked on 2026-08-16. Apple charged 99 USD per membership year on the same date. Both are their charges, not ours, and both can change, so check the current figures before you budget.
Does every new app really need 12 testers for 14 days?
No, not every account. Google applies that gate to personal developer accounts created after 13 November 2023: a closed test with at least 12 testers opted in continuously for 14 days before you can apply for production access. Check your own account rather than assuming the rule applies or does not.
What Android version does Google Play require an app to target?
Google stated on 2026-08-16 that from 31 August 2026, new apps and updates must target Android 16 (API level 36) or higher, with different rules for Wear OS, Android TV, Automotive and XR, and an extension available to 1 November 2026. You do not set this by hand here, but re-read the page before a major release.
How long does Google Play review take?
There is no fixed time. Google says processing can take a few hours or up to seven days, or longer in exceptional cases, depending on the review your app is subject to. Plan a buffer, and do not announce a launch date before you have approval in hand.
Does Playcode publish the app to Google Play for me?
No. Playcode drives the cloud build and the upload, drafts the listing and captures screenshots. The Play Console account is yours, the declarations are yours to answer, and you start the release yourself. That is also how Apple requires it to work on the other store.
Do I get an iPhone app too?
Yes. The same project builds for both, because the app is written once. Apple has its own account, its own annual fee and its own review, but you are not writing the app twice or keeping two codebases in step.
Should I build an Android app or just a website?
Build the website first when the job is a form, a booking flow, a dashboard or a portal, because there is no account, no fee and no review. Build the app when you need an icon on the home screen, a listing people can find, or something that works when the signal does not.
Do I own the code, or am I locked in?
You own it. Playcode produces real, exportable code, and the project holds the phone app, the web app and the backend together. If you later decide you want Android Studio and a Kotlin team, you take the project with you.
Build it on Playcode
Describe your Android app and see it on your phone today
Write down the one job it does, and get a real app with its own backend, its own database and a link you can share. Preview it on your phone while you build, and take the cloud build to Google Play under your own developer account.
Build My Android AppNo credit card required. The Play Console account and the release are yours.