Do you need a developer to make an app, or just someone willing to sign for it?
No. You do not need a developer to make an app any more. A builder writes the project, runs it on a simulator and produces a real installable build, and the typing stopped being the thing that blocks people a while ago. What you do need is narrower and harder to delegate: a store account in a real legal name, someone who answers App Review in their own words, and a truthful answer about what the app does with personal data. That is why building without coding solves less than it sounds like it should. It removes the work, not the accountability.
The answer then splits by who is asking. Testing an idea, building an internal tool, shipping something small: you can reach a live app alone. Taking money from strangers, keeping their data on a server, working in health, finance or anything aimed at children: you want a developer before the launch, not after the rejection. This page draws that line job by job, and marks the parts that are now genuinely automatic.
See which half your app is inThe short version
You do not need a developer to build it. You need one when being wrong gets expensive.
Building got cheap. A first version of a straightforward app, the kind that keeps its data on the phone and talks to nothing, is a description and an afternoon. Signing and uploading are close to automatic too, which surprises anyone who last tried this in 2020.
Judgement about consequences did not get cheap. Money, personal data, health claims, other people's content, anything with a regulator or a signed contract behind it. There a wrong decision is not a bug, it is a refund, a removal or a letter. Buy a developer for the review rather than the typing, and buy them before the launch.
What the developer was for, and what is left of it
Strip the job down. A mobile developer used to turn an idea into screens, write the logic, wire up the data, get the build signed and uploaded, and keep the thing alive afterwards. A builder now does the first three well enough for an app you would actually use, and the fourth almost entirely. The fifth is where people still earn their money.
That split is the useful way to look at no code app development. The question was never whether a tool can produce an app, because it can. The question is which of those five jobs it quietly hands back to you, and whether you can do them. Most tools are loud about the first three and silent about the last two.
Signing deserves its own mention, because it used to be the wall. Certificates, provisioning profiles, bundle identifiers, capabilities: a confusing afternoon even for people who write code for a living. Tooling that holds an App Store Connect key now creates the app record, registers the bundle ID, switches on the capabilities the project declares and reuses one distribution certificate across your apps. That part genuinely does not need a developer.
Stores sign contracts with people, not with software
Here is the wall that replaced signing. Every app is published by an account, and every account belongs to an identifiable legal person who agreed to the terms. Apple is blunt about it. An individual signs up under their personal legal name, and that name is shown as the seller of the app. An organization needs a D-U-N-S number, a work email on its own domain, a public working website, and someone with the authority to bind the company to Apple's agreements. Membership is 99 USD per membership year, with a waiver some nonprofits, schools and government entities can request. Google Play charges 25 USD once, and says you may be asked for a valid government ID and a credit card, both in your legal name.
No builder does that for you, and no contractor can either. A contractor can publish under their own account, which happens constantly, and then the app is theirs: their seller name, their agreements, their leverage the day you fall out. If the app matters, the account is in your name and you hold the credentials, whoever writes the code.
Then comes a requirement with no code in it at all. Google Play makes personal developer accounts created after 13 November 2023 run a closed test with at least 12 testers, opted in continuously for 14 days, before it allows a production release. Twelve real people, two weeks, and organization accounts skip it. That is a recruiting problem rather than an engineering one, and it keeps finished Android apps off the store for weeks.
Uploading is also not submitting. Newly uploads your build to App Store Connect and TestFlight, and only an owner or admin can authorize it, but it does not submit the app for review. You press that button, answer the export compliance question, set the age rating and fill in the App Privacy details yourself, because those are claims about your app that only you can make.
Google Play Console Help, testing requirements before a production release
Two readers, two honest answers
Most writing about non technical app building stops at the build, which is why so many finished apps never reach a store. Reader one has an idea, a small budget and no code: a booking sheet for a studio, a checklist for a team of nine, a tracker for their own phone. Build it yourself. Paying for that first version costs more than it teaches, and the version you build tells you what you actually wanted.
Reader two is shipping something with a blast radius: payments, other people's data on a server, a regulated category, a date somebody signed for, or a codebase another person has to maintain next year. Build the first version yourself anyway, then pay a developer for a few hours to read it before real users arrive. That is a different purchase from hiring someone to build the whole thing, and it is the one most of this group should make, which is the argument in build an app or hire a developer.
The trap sits in between. An app starts in the first group and moves quietly into the second. The day you add sign-in you are storing personal data. The day you charge you are inside the store's payment rules. Neither is a big change in the code, and both change who needs to look at it.
Try it
Which half is your app in
Tick what is true of the app you have in mind. None of these are code problems, which is the point.
Build it yourself. Nothing here needs a developer.
Score 0 of 9. Every box you ticked is a consequence somebody has to own: a refund, a data request, a regulator, a handover. The code underneath is the same size either way.
Money, data and the review notes are not your call
Three jobs stay with you whoever writes the code, and all three are writing rather than programming: what you charge for, what you collect, and what you tell App Review you changed.
On iOS, if you unlock anything inside the app, a subscription, premium content, a game currency or a full version, Apple's guidelines say you must use in-app purchase, and may not use your own mechanism such as a license key, a QR code or a cryptocurrency wallet. Writing a purchase flow is a small job. Deciding what sits behind the paywall, and whether the commission still leaves a business, is not something a builder or a contractor takes off your desk.
Privacy is stricter than people expect, and most of it is declaration rather than engineering. Apple requires every app to link to a privacy policy, in App Store Connect and inside the app, saying what data is collected, how, every use of it, how long it is kept, and how someone withdraws consent or has it deleted. Collecting user or usage data needs consent. An app that supports account creation must also offer account deletion inside the app, and one without significant account features should let people in with no login at all. Those are statements about your business, so nobody else can write them.
Review replies are the same shape. New features have to be described with specificity in the Notes for Review field, and Apple says generic descriptions will be rejected. Anything behind a login needs a working demo account or a full demo mode. If you are rejected, the reply goes back through App Store Connect in your words. An agent can explain a rejection and change the code that caused it, which helps a lot. The sentence you send Apple is still yours.
Apple, App Store Review Guidelines: in-app purchase, privacy and review notes
Which jobs need code, and which need you
| The job | Is it code? | A tool can finish it | Needs your legal name | Cost of getting it wrong |
|---|---|---|---|---|
| Turning a description into working screens | Yes | Yes | No | You describe it again |
| Signing the build and uploading it | No | Yes | Yes | Nothing ships at all |
| Charging for something inside the app | Yes | the flow, not the pricing | Yes | Rejected under guideline 3.1.1 |
| Declaring what you do with personal data | No | No | Yes | Removal, and worse than removal |
| Answering App Review in your own words | No | No | Yes | A stalled release, then an appeal |
What building it yourself actually looks like
The loop is: describe the app, watch it run, say what is wrong, repeat. Screens arrive faster than your opinions about them, which is why this works at all. Save your patience for the last ten percent instead: the icon, the empty states, the words on the buttons, the store listing. That is where an app stops looking generated.
Newly is an AI app builder. You describe an app in plain English and it writes a real React Native and TypeScript project you own, runs it on cloud iOS and Android simulators while it builds, uploads to TestFlight and publishes to Google Play internal testing, plus a standalone APK. It is $25 a month and there is no free plan. Two limits are worth knowing before you plan around it. There is no payments product built in, so anything you charge for is a thing you ask for and then own, store paperwork included. And a new app is local first: data stays on the phone with no accounts and no server, and the agent adds a backend, with sign-in, an API service, a Postgres database per environment and file storage, only once the app needs accounts, shared data, syncing or payments.
The code is yours either way: a ZIP from project Settings, a two way GitHub sync in the Deploy tab, or the command line. That matters less on day one than it does in month eight, when somebody who is not you opens the project. What that handover involves, and what owning the code does and does not buy you, is a question of who can pick it up later.
Questions people ask before they hire anyone
Not to build one. A builder writes the project, runs it on a simulator and produces a real signed build, and none of that needs someone who codes. You do need a store account in your legal name, someone to press submit and answer App Review, and honest answers about payments and personal data. Hire a developer when being wrong is expensive.
Describe the app before you brief anybody
Write the app down in plain English, build the first version yourself, and find out what you actually wanted before you pay anyone to guess at it. Then you will know which jobs to hand over, and to whom.
Start building