Image generation runs on a server you control, and the key never ships with the app.

Where does the image generation actually run?

On a server you control. There are three pieces, and the middle one is the part people try to skip. The app collects the prompt. Your endpoint checks who is asking, checks how many images they have had today, adds the provider key, calls the image API and waits. The provider returns the image in the response, as data rather than as a permanent link, so the bytes land on your machine first. You write them to storage, keep a record of which account asked for what, and hand the app a URL.

That middle piece pays for itself the week after launch. It is where you cap spend per user, throttle the one account that is hammering it, log what was asked so you can answer a report, and retry a failed call. It is also the only way to change provider or model without shipping a new app version, which matters more than it sounds: image models get replaced often, and a model name compiled into a binary cannot change without a release.

Two variants change the shape. If the feature edits a picture the person already has, you need photo upload first, and now a photo leaves the phone. Apple is direct about that case: you must clearly disclose where personal data will be shared with third parties, including with third-party AI, and obtain explicit permission before doing so. One prompt, in your own words, before the first upload. If instead you want the model on the device so nothing leaves it, read on-device AI before you commit. The model has to be bundled or downloaded, the app gets bigger, and the picture costs battery instead of cash.

One more thing the architecture buys you: a place to put the filter. Both stores expect something to sit between the model and the screen. If the generation happens inside your endpoint, that something is one function in one file. If it happens on the phone against the provider directly, there is nowhere to put it.

Apple, App Review Guidelines, guideline 5.1.2(i), read 10 October 2026

Why can the API key never sit in the app bundle?

Because a shipped app is a readable file, and the people who read it are not your users. Expo's documentation says it plainly. Its Metro config inlines environment variables into the client JavaScript bundle, so any variable prefixed with EXPO_PUBLIC_ will be visible in plain text in your compiled application. The same page puts the general case in one sentence: when an end user runs your app, they have access to all of the code and embedded environment variables in it. Dropping the prefix does not save you either. Anything the app needs at runtime to authenticate a call is in the app, by definition.

Image keys are worse than most, for one reason: they are metered per image. A leaked analytics key is embarrassing. A leaked image key is an invoice that grows while you sleep, and the requests carry no user, so you cannot tell whose traffic to cut off. You see a spend graph, not a culprit.

Then the part people discover too late. Rotating a key that lives in the app means a new build, a review, and a wait while installs update. Until then the old key is the only one the app has, so you are choosing between a growing bill and breaking the feature for everyone who has not updated. Nobody plans for that trade, and the day it happens is not the day to think about it.

The arrangement that avoids all of it is boring. The provider key exists in one place, your server's environment. The app holds a session token for your own API, scoped to one person and revocable in a second without a release. Quotas and spend caps live next to the key. If the token leaks, you kill that token. If the provider key ever leaks, it leaked from your server, which means you have logs and a much shorter list of suspects.

Expo, environment variables in Expo, read 10 October 2026

What do the stores require for AI-generated images?

Google Play has a policy named for this feature, AI-Generated Content, and it is short. Apps that generate content using AI must comply with the rest of the developer policies, including by prohibiting and preventing the generation of Restricted Content, and they must contain in-app user reporting or flagging features that allow users to report or flag offensive content to developers without needing to exit the app. Google adds that developers should use those reports to inform content filtering and moderation in their apps. Read the second requirement twice. It is mechanical. A support email address on your website does not satisfy it, because satisfying it means never leaving the app.

Apple is the opposite shape. Its App Review Guidelines, read on 10 October 2026, contain no rule written for generated images, and the only guideline that mentions AI at all is 5.1.2(i), about sharing personal data with third parties. That absence is not permission. The guidelines describe themselves as a living document in which new questions can produce new rules at any time, and the rule a reviewer reaches for is 1.2, user-generated content. Your user typed a prompt, your app produced a picture, and the picture now sits in your app. That is content a reviewer will treat as posted.

Guideline 1.2 asks for four things, and they are easy to build if you know about them in week one. A method for filtering objectionable material from being posted to the app. A mechanism to report offensive content, with timely responses to concerns. The ability to block abusive users from the service. Published contact information so users can easily reach you. Apple then says removing content that breaks the guideline, your terms of service or your community standards is your responsibility, and that egregious or repeated behaviour is grounds for immediate removal of your app from the App Store and from the Apple Developer Program.

So the honest reading is: build to Google's written rule and to Apple's unwritten one, because they ask for nearly the same four controls. A filter before the image appears. A report control on every generated image, inside the app. A way to stop one account from generating. Contact details a person can find without leaving the app. Four small pieces of work, and they cost an afternoon now or a rejection later.

Apple, App Review Guidelines, guidelines 1.2 and 1.1.4, read 10 October 2026

What actually gets an image feature rejected?

Missing report path, first. It is the only requirement in this whole area that a reviewer can check in ten seconds without typing a prompt, and Google's wording leaves no room: in-app, without needing to exit the app. A link that opens a browser fails it. Put a report control on the image itself, and make the report go somewhere a human reads.

Second, real people. Google names AI-generated non-consensual deepfake sexual material, and voice or video recordings of real individuals used to facilitate scams, as examples of what the policy prohibits. A prompt box that happily accepts a public figure's name is the fastest way into that territory. Keep it out at the input stage, because once the image exists you are arguing about moderation rather than prevention.

Third, drift. Apple's 1.2 is blunt that apps which end up being used primarily for pornographic content do not belong on the App Store and may be removed without notice, and 1.1.4 defines the material it means. You can pass review on launch day and fail later because of what your users discovered the prompt box will do. That is why filtering and blocking matter more than the launch screenshots.

Fourth, the age rating. Guideline 2.3.6 says to answer the age rating questions in App Store Connect honestly so the app lines up with parental controls, and warns that a mis-rated app can surprise customers or trigger a regulator. Answer for what your prompt box can produce when someone is trying, not for your demo. Fifth, the quiet one: consent. If a user photo goes to a third-party model and you never said so, you are on the wrong side of 5.1.2(i) and of your own privacy declarations at the same time.

One fear worth retiring. Guideline 2.5.2, the self-contained rule, is about code: an app may not download, install or execute code that introduces or changes features. A generated picture is content your app displays, like any other image it fetches. What does get people is the waiting. Generation takes seconds, a cold start takes longer, and a screen that freezes while it waits reads as a broken app rather than a slow model, which is a good reason to read app performance before you wire the first call.

Apple, App Review Guidelines, guidelines 2.3.6 and 2.5.2, read 10 October 2026