Differentiation
Apple 4.2.6 as a shipping requirement rather than a theme — what must differ, the build step that refuses a template build, and the parts no build step can check.
Apple 4.2.6 does not ban template-built apps. It requires the template provider to give you customisation tools, and requires you to use them. An app that differs from every other build of the same template only by its logo is the case the rule names, and 4.3(b) allows removal of one that is already live.
So differentiation is a shipping requirement here, not a preference.
The build step
From the project root, before every release build:
dart run tool/release_preflight.dart --explainIt exits non-zero, with the fix for each item, while any of these is still ours:
| Checked | Why |
|---|---|
App name in app_config.json, AndroidManifest.xml and Info.plist |
Three places set three different names — inside the app, the Android home screen, the iOS home screen. Three different names read as an unfinished build, so it checks they agree as well. |
| Bundle identifier, iOS and Android | Fixed after your first release on either store. |
assets/icons/app_icon.png |
The file we ship is 281 bytes of text, not an image. It also refuses a source under 1024×1024, because flutter_launcher_icons upscales silently and the result is your store listing. |
The three brand colours in lib/core/theme/app_themes.dart |
This detects that nobody opened the theme file. It cannot grade a palette and does not try. |
baseUrl |
A build submitted against a vendor demo has the reviewer looking at somebody else's data. |
The installer runs it at the end and reports; that run is advisory, because you may not have chosen an icon yet. The run before a release build is the one that matters.
What no build step can check
These are the parts that decide a borderline review:
- Your store listing. Screenshots taken from the template, in the template's colours, are the most recognisable signal that a reviewer is looking at the same app for the fifth time this month. Take your own, on your own deployment, with your own data.
- Your listing copy. Your positioning, your markets, your differentiators — not a description of the platform's features.
- Your feature set. Every module is gated by
GET /api/user/moduleson your own server. Turning off what you do not offer is accurate, and it makes your app materially different from the next operator's. - Your own screens. You have the full Flutter source. A screen that exists only in your build is the strongest 4.2.6 answer there is.
The failure case, stated plainly
A default-skinned build with a swapped logo, submitted alongside a dozen others that look the same. If that describes your plan, the differentiation work is cheaper than the rejection.