Publish to TestFlight and Google Play

Connect a store account to your project and Floot handles the store side of every app build: it signs the build, uploads it, and puts it in front of your testers — TestFlight on iOS, internal testing on Google Play. You need no Mac, no Xcode, and no Android Studio, only the developer accounts.

Start on the Publish screen: open your project on floot.com, click Publish, switch on Publish mobile app, and pick a store under Connect App Stores — or under App stores once the app is live.

Connect Apple

1. 1

   Sign in with your Apple ID

   Enter your Apple ID and password, then the 6-digit code Apple sends to your trusted devices. Floot does not store your password.

   

2. 2

   Let Floot check the account

   Floot checks that the account is in the Apple Developer Program and has the access it needs to create apps and upload builds. If something is missing, it says what.

   If your Apple ID belongs to more than one App Store Connect team, Floot asks you to Choose a team. Pick the team you publish with. You have to be its Account Holder or an Admin; a team marked Needs Admin cannot be picked. What each message at this step means is in Connecting Apple and Google: troubleshooting.

3. 3

   Name your app

   On the first publish, choose the App Store name testers and shoppers will see. It has to be unique across the App Store, and Floot checks that it is free. If your Apple account has never published an app, Apple also needs a company name — the seller name shown on the App Store, which cannot be changed later.

   Choose the name with care. It is also the name under the app's icon until you give the app a home-screen name of its own, which you can do later (see the mobile app ID and the app name). The name on the store listing can still be changed in App Store Connect.

   

   Floot looks in App Store Connect for an app with the project's mobile app ID as its bundle ID, and creates one only if there is none. If your team already has an app with the name you typed but under a different bundle ID, Floot does not tell you to try another name. It explains the mismatch on this step and shows that app's bundle ID next to the project's mobile app ID:

   • That app has no build yet: in App Store Connect, open its App Information, set Bundle ID to the project's mobile app ID, save, and click Validate again.
   • That app already has builds: Apple no longer lets its bundle ID change. To publish to it, set the project's mobile app ID to the bundle ID Floot shows (it is also the Android package name). Otherwise, choose another name.
4. 4

   Confirm

   Floot creates the app in App Store Connect, checks the bundle ID and signing, and connects the account to the project. Connecting does not start a build: the next publish with Publish mobile app on does.

   

After that, each publish builds the iOS app in about 4 minutes. Apple takes another 5 to 30 minutes to process the build before it appears in TestFlight, and emails your testers an invite.

The build shows up in the TestFlight app by itself, with no redemption code. Floot adds the Apple ID you connected as the tester, so open TestFlight signed in with that Apple ID. To let other people test, add them in App Store Connect under TestFlight.

Install it on your iPhone with TestFlight

1. 1

   Open App Store Connect

   When the build finishes, click Open App Store Connect on the Publish screen and open your app's TestFlight tab. Wait for Apple to finish processing the build. To add testers, add them to an internal group there; each one gets an email invite.

   

2. 2

   Install from TestFlight

   On the iPhone, install Apple's TestFlight app from the App Store. Open the invite email and tap View in TestFlight, signed in with the Apple ID that was invited, then tap Install. Later builds appear in TestFlight as updates; there is no need to delete the app first.

   

3. 3

   Check the native features

   Try what the browser could not show: permission prompts and their wording, notifications, the native share sheet, the camera and photo picker, and links that open the app. Note the version and build number in TestFlight so you know which build you are testing.

TestFlight builds expire after 90 days. When testing goes well, submit the same build for review (see Submitting for review).

Connect Google Play

1. 1

   Say whether you have uploaded a build to Google Play before

   Choose No, not yet for a new app, or for one you created in Play Console but never uploaded a build to (Floot creates its upload key). Choose Yes, I've uploaded a build if a build is already on Play: you will need its original upload key.

2. 2

   Pick the Google account that owns your Play Console

   Sign in with Google, or reuse an account you connected before.

3. 3

   For a new app, create it in Play Console

   Click Create app in Play Console and paste the package name Floot shows you — paste it rather than typing it, since it has to match exactly.

4. 4

   Connect Floot to the app

   Open the app in Play Console, copy the URL from your browser's address bar, paste it into Floot, and click Connect. That gives Floot's publishing account access to this one app, so it can upload builds.

5. 5

   For an existing app, upload your signing key

   Google only accepts updates signed with the key you used before, so upload that keystore (.jks, .keystore, or .p12) with its password. If it holds several keys, pick the one your app is signed with.

   That key was made on the computer the app was first uploaded from. Neither Google nor Floot has a copy. If you cannot find it, see the wrong upload key for how to reset it with Google.

After that, each publish builds the Android app in about 2 minutes and puts it on Play Console internal testing.

One connection and one upload key per Google account

Floot keeps one Google Play connection for each Google account you sign in with, and that connection holds one upload key. Every project you connect with the same Google account points to that connection and signs its builds with that same key. Connecting a second project, or signing in with Google again, reuses both: the key stays the same.

• Uploading a keystore replaces the key for the whole connection. It is the key every project on that Google account signs with from then on, so Play refuses the next build of an app that was first uploaded with the old key.
• Removing the Google Play account in Floot deletes its upload key. Floot keeps no copy. If you connect the same Google account again afterwards, Floot creates a new key, and Google Play refuses updates to any app already uploaded with the old one until you reset the upload key with Google. Removing it is not a way to fix a connection: sign in with Google again instead. Floot does not let you remove an account here while a project that has had a build through it still uses it; to disconnect one, contact support.

The mobile app ID and the app name

The mobile app ID is your iOS bundle ID and your Android package name. It is the Mobile App ID field in the Mobile app card of the project's Settings page, which opens when you click the project's name at the top left on floot.com. Unless you change it, it is app.floot.u followed by your project's ID without its dashes.

• Bringing an app that is already in a store? Set its existing ID here before you connect the store. Floot finds your app in App Store Connect and Play Console by this ID; there is no step for picking an app from a list.
• Otherwise, leave it alone. A nicer-looking ID is not a reason to change it, and an invalid ID makes builds fail.
• Changing it later starts a new app. Once builds have been uploaded under one ID, a different ID is a different app to Apple and Google. The app people already installed keeps the old ID, so new builds do not update it. This cannot be undone.
• Changing it disconnects both stores. Connect Apple and Google Play again afterwards. Native push is set up again on the next publish that includes a connected store, and only builds made after that carry push.

The name under the app's icon is, unless you choose one, the App Store name you entered when you connected Apple (up to 30 characters), or your project's name if Apple is not connected. To give it a shorter name, ask the AI you build with to set the app's home-screen name (for example "set the home-screen name to Halfway"), then publish the mobile app again. It works after the first publish and while the app is in TestFlight, on iPhone and Android, and keeps the app's ID and store listings as they are. About 12 characters fit under the icon. People see the new name once they install the new build. The name on a store listing is separate and is changed in App Store Connect or Play Console.

Every publish after that

• Connected stores get a build whenever you publish with Publish mobile app on. Switch a store off under App stores to skip it for one build.
• Set the version in the Version row before a release (1.0.0 until you change it). The build number is automatic, and Floot keeps it above anything already in the store.
• Every build still comes with the Android APK and the project zip, the same as without a store. With Google Play connected, Last build also offers the signed Google Play bundle (.aab), for the rare case where Play Console needs a build uploaded by hand.
• With a store connected, your assistant can build the app itself when it publishes — just ask for an iOS or Android build.
• A test build goes to the same testing tracks but stops working after 4 hours. Never submit one for review.
• Floot builds every iOS app with Xcode 27.1 and the iOS 27.1 SDK, so there is nothing to set up. An app already in TestFlight or the App Store keeps the SDK it was built with until you publish the mobile app again.

Submitting for review

Floot stops at testing. When a build is ready, submit it for review yourself: screenshots, a description, and review notes in App Store Connect, or a store listing and a release in Play Console. Review and approval are between you and Apple or Google, and an app already live in a store keeps its current version until you submit an update.

Floot does not make store screenshots, and there is no .ipa file to download: the iOS build goes straight to App Store Connect. Take your screenshots from the app running on a device. Apple's export-compliance question is answered for you on every build.

Google Play's Data safety form

Google asks every app for a Data safety form, and you fill it in for your own app: what it collects depends on what you built. Security and data describes what Floot stores on your app's behalf. If your app has user accounts, Google also expects a way for people to ask for their account and its data to be deleted, so ask your assistant to build one.

What the Floot app shell adds

Your Android app is your web app inside a native shell. The shell adds no crash reporting, no analytics, no performance monitoring and no ads, so it does not collect crash logs, diagnostics or the advertising ID, and it reads no device identifier of its own. What it adds:

With push notifications, declare Device or other IDs, collected for App functionality. Google's Firebase data disclosure page lists what Cloud Messaging collects. Everything else on the form comes from your app's own features: the accounts, messages, photos, locations or purchases it stores and what it sends to other services.

Floot's visitor analytics (the project's Analytics tab) are for the website only: app builds leave the analytics script out. Builds made before that still download the script, but it sends no events from inside the app. Apple's App Privacy questions for your iOS app get the same answers, except that iOS push may go through Apple's own push service instead of Firebase; either way it uses a push token for the device.

Apple's App Privacy answers

Apple asks the same kind of question in App Store Connect, under App Privacy, and you answer it for your own app. To see what a build actually contains, download the iOS privacy report from Last build on the publish screen. It needs your Apple account connected, because only then does Floot compile the iOS app: it appears a few minutes after that build finishes, and a build made without Apple connected, or with the App Store switched off for that build, has none. It is read from the compiled app on Floot's Mac builder, and lists every privacy manifest (PrivacyInfo.xcprivacy) in the app, its frameworks and its extensions, what each one declares (tracking, collected data types, required-reason APIs), the native SDKs with their versions, and the permission texts. Download it when you submit: it is kept with the build's other files, for 30 days or until your next app build.

The report covers the native side only. It cannot say what your app's own screens and server do with people's data, which is most of what Apple asks about. Apple's own messages about an upload (for example a missing required-reason declaration, ITMS-91053) are emailed to the Apple account that owns the app; Floot does not receive them.

If connecting or uploading fails

The messages the connect flow and the store upload show, and what to do about each, are in Connecting Apple and Google: troubleshooting.