Skip to content
Start free

What App Review says about screens from a server

Shipping without a releaseOpinion4 min readMiniwall team

Part of the series: Ways to change a live app without shipping a release

Apple's published rules don't mention screens that come from a server. They talk about downloaded code, apps that change their purpose, and hidden features. A screen described as data is not code, which is our reading and not Apple's statement. Even so, those rules limit what you can change after review, and a reviewer decides how they apply to your app. We're not lawyers, and this isn't legal advice.

Here is what the text says, what we'd tell reviewers, and the one thing we wouldn't do.

What the text says

All four quotes below are from pages we opened on 2 November 2026. Wording changes, so read the current pages before you rely on them.

  • Guideline 2.5.2. An app "may not download, install, or execute code which introduces or changes features or functionality of the app"[1]. It's about code.
  • Developer Program License Agreement, 3.3.1(B). Executable code can't be downloaded, but "interpreted code may be downloaded to an Application but only so long as" it doesn't change the app's primary purpose, doesn't bypass signing or security features, and doesn't create a store for other apps[2].
  • Guideline 2.5.19. "Don't include any hidden, dormant, or undocumented features in your app"[1].
  • Guideline 2.3.1(a). New features and product changes must be described in the Notes for Review and be accessible for review[1].

None of these says "screens from a server are fine" or "are not". What they share is a test: what the reviewer saw has to be what the app is.

Data isn't code, but purpose is the test

A screen that a server describes as JSON, and an SDK draws from components it already has, doesn't download anything that runs. That's why we read the executable-code rules as being about something else.

The rule that does apply is purpose. If the app was reviewed as a note-taking app, a screen that turns it into something else is the thing the license agreement says not to do. A new price, a new headline and a different order of plan cards don't change what the app is. A screen that unlocks a feature reviewers never saw is a different matter.

What we'd do

  1. Say it in the review notes. One sentence: some screens in the app are described by a server and drawn by an SDK. Say where a reviewer can see them. This follows the spirit of 2.3.1(a).
  2. Publish what reviewers should see before you submit. A screen left as a draft isn't on the device[3]. Reviewers can't judge a screen that isn't there.
  3. Keep the price and what it buys clear. Guideline 3.1.2(c) asks you to describe "what the user will get for the price" before asking someone to subscribe[1]. That holds for a screen from a server as much as for one in the build.
  4. Keep a way back. Every version that went live can be made live again[3]. If a change turns out to be a problem, you want to undo it in a minute, not in a release.
  5. Decide who can publish. A change that reaches every user without a release deserves the review step you'd give a release. How to govern remote UI changes covers who approves what.

What we wouldn't do

We wouldn't use a remote change to put back something a reviewer asked you to take out. If a screen was rejected, treat the rejection as feedback and fix it the way the reviewer expects. Changing it after approval to restore the rejected version is the case the rules were written for, and it's the case those rules were written for.

Remote screens are good for the changes that were never in doubt: copy, order of options, a sale, a survey. Ways to change a live app without shipping a release lists the others and what each can't do.

What we haven't checked

We didn't read Google Play's policies for this post, because we couldn't open that page from where we work. We read only the published text, not how reviewers apply it in practice, and we can't tell you how your reviewer will read your app.

When this matters less

If your product is a website with no store review, none of this applies. If every screen in your app is in the build, it doesn't either. It matters once a server can change what a reviewed app shows.

Next step

Read the four clauses above on Apple's own pages. Then write the sentence for your review notes, and keep it with your release checklist.

Sources

Go further

Keep reading