Buying a Template Does Not Get You Rejected. Shipping Forty of Them Does.

Somebody buys a source-code template, spends three weeks making it theirs, opens App Store Connect, and then finds a forum thread claiming Apple rejects apps built from templates. The submission gets postponed, the thread gets read four more times, and the actual guideline goes unread — which is a shame, because it is two sentences long and it answers the question.

Guideline 4.2.6 is about who is submitting, not about what the codebase started as. A developer who buys source, builds their own product on it and ships it under their own account is not the thing the rule is aimed at. An agency shipping the fortieth near-identical restaurant app from one codebase very much is, and the distinction between those two is worth being precise about — including where it becomes uncomfortable.

What 4.2.6 actually says

The text, in full: "Apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content. These services should not submit apps on behalf of their clients and should offer tools that let their clients create customized, innovative apps that provide unique customer experiences."

Read the exception clause rather than the first six words. The rejection applies unless the app is submitted by the provider of its content. If you are a restaurant shipping your own restaurant's app, you are the provider of the content. If you are a startup shipping a delivery marketplace you intend to operate, you are the provider of the content. The codebase's origin is not what the sentence turns on.

The guideline goes on to offer template providers a second route — a single binary hosting all client content in an aggregated or "picker" model, the example given being a restaurant finder with a customised entry per client. That option exists precisely because Apple expects the alternative, forty separate binaries, to be a problem.

The test is whether the content is yours

Everything follows from one question: when a user opens this app, whose business are they interacting with? If the answer is a business you operate, you are inside the exception no matter where the widgets came from. If the answer is "whichever of my clients this build was configured for", you are the service the guideline names, and the account it was submitted from is the fact that gives it away.

This is where being a template vendor requires some honesty. The agency model — buy one codebase, rebrand it per client, ship each under your own developer account — is a common reason people buy source code, and it is the model Apple explicitly does not permit. Nobody selling you the template has an incentive to lead with that. It is still true, and finding out at submission is considerably worse than finding out now.

4.3, and the agency failure mode

Even with the content question settled, volume attracts a different guideline. 4.3(a): "Don't create multiple Bundle IDs of the same app (for example, submitting a separate map app for every city in the world instead of a single worldwide map that allows users to search any city)." Apple's own suggested fix is one app with the variations behind in-app purchase.

And 4.3(b): "Don't submit apps that are indistinguishable from what's already widely available." This is the one that catches a template shipped with its demo content intact — the sample restaurants, the placeholder categories, the theme untouched. The app is not rejected for being built from a template. It is rejected for being indistinguishable, and it is indistinguishable because nobody changed anything.

Guideline 4.3(a) - Design - Spam

We noticed that your app provides the same feature set as other apps
submitted to the App Store; it simply varies in content or language,
which is considered a form of spam.

Next Steps: Review the Design section of the App Store Review Guidelines.

There is no appeal that argues its way out of that message, because it is a judgement about the finished product rather than a checklist item you can satisfy. The work is upstream: different information architecture, different copy, real content, and a visual identity that is not the one forty other buyers also shipped.

Google Play says the same thing about accounts

Play's guidance for white-label developers is more specific than Apple's and worth reading even if you only ship to iOS, because it states the structural answer plainly: each client, or group of clients, should have a separate developer account. The stated reason is containment — a policy problem on one app should not be able to take down every other app you have shipped.

That is the part people get wrong, and it is expensive. Publishing thirty client apps from one account means one repetitive-content strike can suspend the account holding all thirty. Decentralising costs a little administration per client and converts an existential risk into a local one.

Play also requires each listing to stand on its own: distinct description, distinct screenshots, distinct icon and graphics, and a description that matches what the app actually does. Reusing one listing across a family of apps is the violation, independently of how different the binaries are.

The rejections that have nothing to do with templates

Most first-submission rejections are not about provenance at all. The one that catches almost every template-derived app is 5.1.1(v): "If your app supports account creation, you must also offer account deletion within the app." A delivery app has sign-up, so it needs an in-app path that deletes the account — not an email address, not a web form.

Next is permission purpose strings. A template ships with whatever the author wrote, which is frequently a placeholder, and a generic string is a rejection on its own. NSLocationWhenInUseUsageDescription has to say what your app does with the data, in a sentence a customer would understand.

<key>NSLocationWhenInUseUsageDescription</key>
<string>Shows your courier on the map while an order is on its way.</string>

<!-- Not "This app needs access to your location." That is what
     the template shipped, and it is a rejection on its own. -->

Then 4.2.2, which rules out apps that are "primarily marketing materials, advertisements, web clippings, content aggregators, or a collection of links" — relevant if your first release is a shell around a website. And a demo account: reviewers need working credentials, and an expired or rate-limited login is a rejection that costs a full review cycle for no reason at all. If the app has a paywall, there must also be a visible restore control, which the subscriptions post covers under 3.1.1.

Before you submit

[ ] Bundle id, application id and display name are yours, everywhere
[ ] No demo data, sample vendors or placeholder imagery in the build
[ ] Icon, palette and typography differ from the template's defaults
[ ] Every permission purpose string describes your app specifically
[ ] Account deletion reachable from inside the app          (5.1.1(v))
[ ] Restore control visible on the paywall                  (3.1.1)
[ ] Demo credentials tested today, not last month           (2.1)
[ ] Store listing written for this app alone, not reused
[ ] One developer account per client, if you ship for clients

Nine lines, and the first three are where most rejections actually come from. None of them are about having bought a template; all of them are about having finished the job of making it a product.

The rule

Ship your own app under your own account and 4.2.6 does not describe you. Ship other people's apps under your account and it does, whatever the code is. The guideline is not a verdict on where your source came from — it is a question about who is standing behind the thing on the store, and there is only one answer that survives review.