Can no-code apps go on the App Store? Yes, and the rule that decides it is about what your app does, not how you built it.
Yes. Apps built without hand-written code reach the App Store every week, and the App Store Review Guidelines contain no clause about build tools. We searched the live text on 1 October 2026 for no-code, low-code and drag and drop, and got zero matches for all three. Review reads your binary, your metadata and your account, so what Apple asks for is the same list for you as for a team writing Swift by hand. The caveat is real though. Two clauses in section 4.2 reject a large share of what comes out of no-code tools, and which side of them you land on is mostly decided by the tool you picked.
So the useful question is not whether no-code apps are allowed on iOS. It is whether you are shipping an app or a wrapper, and whose developer account presses submit. This page takes those two in order, then the thing that stops more submissions than either of them.
Check what would block yoursThe short version
The store does not ask how you built it it asks what you built and who submitted it.
Two people ask this question and they deserve different answers. The first has a tool that hands over a real iOS project or a signed build, plus an Apple Developer Program membership of their own. For that person the answer is a plain yes, with nothing to worry about beyond the review checklist everyone gets.
The second has a service that turns a website or a spreadsheet into an app and offers to put it on the store on their behalf. For that person the answer is usually no, and the reason is written down. Guideline 4.2.6 rejects apps created from a commercialized template or app generation service unless the provider of the app's content submits them directly. That is a rule about the arrangement, not about code.
The guidelines have no clause about how an app was built
There is no approved builder list, no penalty for generated code, and no field in App Store Connect where you declare your toolchain. Apple checks a build that behaves, metadata that matches the app, and an account that belongs to whoever is selling it. A Swift app, a Flutter app and a React Native app all arrive as the same kind of upload.
The closest thing to a rule about building is guideline 2.5.2. Apps should be self-contained in their bundles, and may not download, install or execute code that introduces or changes features. That clause matters for one family of tools. If your app pulls its screens and its logic from a vendor's server at runtime, it is sitting near a line a compiled build never goes near. Ask any builder you are considering whether the app keeps working with the vendor switched off.
Guideline 4.7 is the one people misread in the other direction. It does allow certain software that is not embedded in the binary, including HTML5 and JavaScript mini apps, with conditions attached and the developer responsible for all of it. That is a narrow permission for a specific kind of app, not general cover for a shell that loads a website. If you are still choosing an approach, the ceiling each one puts on you is the subject of no code app development, and that ceiling is set long before review sees anything.
Apple, App Store Review Guidelines, sections 2.5.2, 4.2 and 4.7
Guideline 4.2 is the wall most rejected no-code apps hit
Section 4.2 is called Minimum Functionality and it asks for an app that goes beyond a repackaged website. Apple's wording is blunt: an app that is not particularly useful, unique or app-like does not belong on the store. 4.2.2 adds that apps should not mainly be marketing material, web clippings, content aggregators or a collection of links, with catalogs as the stated exception. Those two sentences predict most of the rejection emails in this category.
Notice what the test is not. It does not measure how much code you wrote. A no-code app that tracks someone's medication and fires a local notification at the right hour clears 4.2 without trying. A hand-coded app that shows your blog in a webview does not. The wrapper decision is a design choice with review consequences, and the tradeoffs are set out in native code vs webview.
The practical check before you submit: name one thing the app does that needs a phone. Camera, location, notifications, offline data, a sensor, the share sheet. If the best answer is that it is convenient to have an icon on the home screen, you have built a bookmark, and review will treat it as one. A second real feature is worth more than ten more screens.
Check yours
Which of these describes your app
Not one of these lines is about the tool you used. Tick every one that is true today.
Clear so far, now name the reason it needs a phone
Camera, notifications, location, offline data, a sensor. Pick one, or guideline 4.2 becomes the argument you have to win.
Whose account presses submit, and why 4.2.6 exists
4.2.6 is the clause that catches the app-in-a-box arrangement. Apps created from a commercialized template or app generation service are rejected unless the provider of the app's content submits them directly. Apple also tells those services not to submit for their clients, and to give clients tools that produce customized apps instead. The clause offers them one documented alternative: a single binary that hosts all client content in an aggregated or picker model, like one restaurant finder with an entry for each restaurant.
So ask a builder one question before you pay. Does the app go up under my Apple Developer Program membership, or under yours? If the answer is theirs, you are inside the arrangement 4.2.6 describes, and you are renting your own listing. Your own membership costs money and a little paperwork. Apple's enrollment page puts the Apple Developer Program at 99 USD per membership year, and an organization also needs a D-U-N-S Number, because the organization name becomes the seller name on the listing.
Owning the account has a second effect that matters more day to day than the rule does. When review comes back with a question, you can answer it, change the build and resubmit the same afternoon. When the tool owns the account, you file a support ticket and wait in a queue you cannot see.
What actually gets apps rejected, no-code or not
Here is the part that surprises people who arrive worried about their build tool. Apple publishes where submissions get stuck, and the biggest bucket is not 4.2. On average, over 40 percent of unresolved issues relate to guideline 2.1, App Completeness: crashes, placeholder content, broken links and incomplete review information.
Every item on that list is boring and fixable in an afternoon. Finish the copy. Replace the grey boxes with real images. Make every link work, including the support link and the privacy policy link, both of which are required. If anything sits behind a login, put a working demo account in the review notes, or get advance approval for a built-in demo mode. Apple's own list of common issues also names inaccurate screenshots, substandard interfaces, and apps that promise more than they deliver.
Review time is a smaller problem than forum stories suggest. Apple says that on average 90 percent of submissions are reviewed in less than 24 hours. Plan for longer on a first submission, because account and metadata problems surface on the way in, and expect at least one round trip. The mechanics after that, the certificates, the build upload, the TestFlight pass and the submission form, are getting it submitted, which is a walkthrough rather than a decision.
What your tool hands you, and what review does with it
| What the tool produces | Who presses submit | Where it stands under 4.2 | Reaches camera and notifications | You can fix a rejection yourself |
|---|---|---|---|---|
| Your website inside a webview shell | you | the classic 4.2 rejection | only through the shell bridge | No |
| A visual builder with its own runtime | you | depends what the app does | whatever the runtime wraps | only inside the builder |
| A builder that outputs a React Native project | you | judged like any hand-built app | Yes | Yes |
| A template service that submits for you | the service | 4.2.6 rejects the arrangement | varies by service | No |
| Hand-written Swift or Kotlin | you | judged like any hand-built app | Yes | Yes |
Building something that passes on its own merits
Clearing 4.2 is unglamorous work. Pick one job the app does for one person. Make that job work with no network where it can. Use one or two device features because they help, not to tick a box. Delete the screens that are only links back to your site. One real feature beats twelve pages of your website, at review and for a year afterwards.
Newly is an AI app builder. You describe the 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, then uploads to App Store Connect and TestFlight. It does not press submit for review, you do, and only an owner or admin can run the upload. It is $25 a month and there is no free plan. New apps start local-first, with data on the phone and no server, and the agent adds sign-in, a database and file storage only when the app needs accounts, shared data or syncing. Android publishes to Google Play internal testing from the same chat, and a standalone production APK comes out of it too.
The ownership part is what 4.2.6 cares about. The code comes out as a ZIP from project Settings, or through the two-way GitHub sync in the Deploy tab, and the TestFlight upload lands in your own App Store Connect account, under your name as seller. You are the provider of the content, submitting directly. That settles the arrangement question. It does not settle 4.2, because nothing except the app itself can.
Questions people ask before they publish
Yes. There is no rule against apps built with visual builders, AI builders or generated code, and the App Store Review Guidelines do not use the term at all. Apple reviews the uploaded build, the metadata and the account behind it. Two clauses do catch a lot of no-code work: guideline 4.2 on minimum functionality, and 4.2.6, which rejects apps that a template or app generation service submits on a client's behalf.
Describe the app, then hold it against 4.2
Write one sentence about what the app does for one person, and one about why it needs a phone rather than a browser tab. If both sentences hold up, build it as a real project you submit from your own account, and the way you built it is not the part review will argue with.
Start building