MMashDiv

Publishing obligations

The seven things that are yours and not ours — the developer accounts, the licences, being the submitter of record, your own keys and URLs, a differentiated build, your data-safety answers, and proof that your server still enforces the rules.

2 min readUpdated 26 September 2026mobile, publishing, compliance, apple, google-play

Seven obligations sit with you. None of them can be met by the package.

  1. Developer accounts — organisation enrolment on both stores, with a D-U-N-S number for the entity.
  2. Licences by country — the named licence for each market you target, recorded in your own attestation console.
  3. Being the submitter — we never submit, and neither may a reseller.
  4. Your own keys and URLs — RPC, market data, privacy policy, account deletion.
  5. Differentiation — Apple 4.2.6, and the release preflight that fails while the project is still ours.
  6. Data safety and privacy — the Play declaration and the iOS privacy answers, traced from what the app actually transmits.
  7. Proving the server half — the rules are enforced by your backend, so there is one command that checks your install still honours them.

Everything here describes obligations the stores place on operators, as they read at the time of writing. It is not legal advice, and neither store treats a vendor's summary as a defence. Check the current policy text for the markets you are entering, and take the questions in Before you buy to your own counsel.

The order to do them in

Two of these cannot be undone later, so do them first:

  • Your bundle identifier. It is fixed after your first release on either store. Choose it before you build anything you intend to keep. Both identifiers — androidApplicationId and iosBundleId — are set in assets/config/app_config.json; see Make it your app.
  • Your app name. Changing it after launch costs you whatever recognition the listing has built.

Then the accounts (enrolment and verification take days to weeks, and Play's organisation verification is the usual delay), then the licence attestations, then the build — Android and iOS.

What the platform does for you

  • GET /api/user/modules is the app's only navigation input, so turning a module off on the server removes it from every build, including ones already installed.
  • The licence attestation console (Admin → System → Compliance → Licence Attestations) records which countries you are licensed to serve, per module. Once you switch on Enforce Licence Attestations (Mobile App) — off by default — it is default-deny for the app: a regulated module reaches nobody until you record a licence for their country. It also emits your Apple storefront list and your Play country targeting list from the same table, so the three cannot drift apart.
  • Native responses are shaped: rates, leverage ceilings and projections are removed from anything the app asks for, so a screen cannot render a figure that reads as an earnings promise.
  • dart run tool/release_preflight.dart fails, and lists the fix, while the project still carries our name, bundle identifier, icon, colours, Apple signing team or demo backend. It checks the project; it does not stop flutter build by itself. Separately, a release build of the app refuses to start against an http:// or ws:// server address.

None of that makes you licensed. It makes the parts we control match what you have told us.