Saltar al contenido principal

Getting FlowPOS onto App Store, Play, and Sunmi

Written for the person who will file the first store records. Accounts for the Fixx team's other apps already exist; what remains is app-specific. Nothing here is urgent before hardware tasks pass, but two items have lead time and cost nothing to start.

The bundle identifier is com.rpapos.flowpos on both iOS and Android (apps/mobile/app.json). It is permanent: App Store Connect, Play, and any future Epson MFi PPID application all key off it.

Do not register tech.flowandgrow.pos or reuse tech.flowandgrow.flowpos. The latter was silently registered to a free Personal Team during a Program License Agreement block and cannot be released from that team (research D15). The paid team's portfolio is com.rpapos.* / com.rpasolution.*; this app follows that.

Standing rule: the Apple team hosts other production apps. Never create a distribution certificate, revoke anything in the portal, or pass -allowProvisioningDeviceRegistration without asking first. See apps/mobile/CLAUDE.md.

How daily web work reaches devices without a store release: Printing topology and Releases. Debug install (simulator, emulator, or USB device): Run locally.

What to do now​

  1. Confirm with the Play account holder whether the Google Play developer account is organization-verified (D-U-N-S). If it is still a personal account, verification takes a couple of weeks, and new personal-account apps must run a closed test with a minimum number of testers for two weeks before production. Organization accounts are exempt.
  2. Register an explicit App ID for com.rpapos.flowpos on team Fixx Sociedad Anonima (4LL4BEN647) and create the App Store Connect record, so TestFlight is ready the day the first pilot build exists. Local debug builds used the team's XC Wildcard * App ID; a store build needs the explicit one. Additive — it must not touch the RPA apps.

Apple App Store​

Accounts: done. The Fixx team is a paid Developer Program membership; you are Admin. The Paid Applications Agreement is cleared.

The review risk to prepare for​

Apple's guideline 4.2, "minimum functionality," rejects apps that are just a website in a wrapper. This app isn't, but the reviewer has to see that in the first minutes. What makes it pass:

  • native printer discovery over Bluetooth and the network
  • offline cold start
  • the device-lock session gate
  • the hardware permissions

Write the review notes to lead with printing, and provide a demo account whose location has a network printer configured so the reviewer can reach the setup screen and see a discovery scan. Do not submit with a demo account that lands on an empty till.

Per-app items​

  • An App ID for com.rpapos.flowpos on the team, plus an App Store Connect record. Additive, nothing touches the RPA apps.
  • Usage-description strings in Info.plist for Bluetooth and local network. The review team checks that each one explains why in plain language — "FlowPOS uses Bluetooth to find and print to your receipt printer" passes; "Bluetooth access required" gets flagged. The strings already in app.json follow that pattern; keep them that way when adding more.
  • App Privacy labels in App Store Connect, matching what telemetry actually sends (hashed identifiers, no names). See Installed-base view.
  • Export compliance: the app uses HTTPS, which is the standard exemption — one checkbox.
  • A privacy policy URL, updated to mention StarIO10's telemetry once a later feature ships Star (design phase 4).

MFi — only when a protocol string is declared​

Epson's PPID goes into the review notes; Star's app authentication is done through Star's portal. Submitting with a protocol string declared and no matching approval is a rejection, which is why the design says declare each one only when its SDK is integrated. Generic printing (feature 052) declares none.

Distribution path​

TestFlight first. Internal testing needs no review; external testing needs a light "Beta App Review." Pilot merchants go through TestFlight before the first App Store release, which also lets you run the store-update-detection logic from feature 051 against a real channel.

Google Play​

Accounts: done, under Fixx. Confirm whether it is a personal or organization developer account — see "What to do now" above.

Per-app items​

  • Play App Signing. Google holds the release key; you upload with an upload key. EAS or the release pipeline generates it once.
  • Target API level. Google requires new apps to target a recent API level, and it moves yearly. Check the current requirement at the time you submit. The shell's minSdkVersion 28 is fine (usesCleartextTraffic for the pinned loopback origin); targetSdkVersion must be current.
  • Foreground service declaration. Specific to this app. The connectedDevice foreground service type requires a justification in the Play Console and, for some types, a short video showing the feature. Prepare a thirty-second clip of a ticket printing over Bluetooth while another app is in the foreground. This becomes more important once Android agent mode exists.
  • Data safety form, mirroring the Apple privacy labels (hashed identifiers, no names).
  • Bluetooth permissions are runtime prompts, not review items, but the permission rationale strings should exist (they do, in app.json).

Distribution path​

Internal testing → closed testing with pilot merchants → production. New personal-account apps must run a closed test with a minimum number of testers for two weeks before production; organization accounts are exempt.

Sunmi — later, and separate​

Sunmi devices without Play Services cannot install from Google Play. Sunmi has its own app store and an MDM path. That is a third submission, when the first Sunmi prospect signs — not part of the first shippable release.