Native app features

Your iOS and Android apps are your web app in a native shell. A few things only make sense in the native app, and there is no settings screen for them: you ask your assistant, and they ship with your next app build.

Push notifications

Floot's built-in push reaches phones as well as browsers. Native push is set up for you when you publish with a store connected: the Apple account for iOS, and Google Play for Android, which needs a paid plan. A build made without the matching store ships without native push. Browser push does not work inside the native app, so the native app needs its own.

1. 1

   Ask your assistant for push notifications

   It adds Floot's built-in push to your project, with the code that asks people for permission and the code that sends.

2. 2

   Connect the store for each platform

   Your Apple account for iOS, Google Play for Android — see Publish to TestFlight and Google Play.

3. 3

   Publish with the mobile app on and that store included

   Switch on Publish mobile app and leave the store switched on under App stores. Floot sets up push for that store during this publish. On iOS it creates a key named Floot Push in your Apple developer account. On Android it sets up Firebase under the Google account you connected. You need no push certificate and no Mac.

4. 4

   Install that build

   Push is in the builds made from this publish on. A build from before it has to be replaced on the phone.

• Keep the Floot Push key. Floot uses the one key for every app on that Apple account, so do not revoke it in the Apple Developer portal.
• Handing out the APK yourself? Android push still needs Google Play connected and included for one build. After that, later builds keep push even when you switch Play off for a build.
• Google may ask for something once. The first publish with push can stop and ask you to sign in to Google again or to accept Google Cloud's or Firebase's terms. The steps are in Connecting Apple and Google: troubleshooting.
• Changing the mobile app ID resets native push. Connect the stores again and publish with them included, and push is set up again for the new ID.

Unread badges and sender photos

Two things make your app's notifications work like a messaging app's. Ask your assistant for them, for example "show the number of unread messages on the app icon, and keep it the same on all of a user's devices" or "show the sender's photo on message notifications, on iOS too".

• An unread count on the app icon. A notification can carry the user's total number of unread items. When they read them on one device, your app tells their other devices, which update the badge without showing a notification. On iOS the number changes silently, whether the app is open or not. Android shows a dot instead of a number (or a number, on phones whose home screen supports one), and clears the dot and the app's notifications once nothing is unread; a count that goes down but not to zero leaves them as they are. On the web the badge shows on an installed web app, and it can only change along with a quiet notice your app writes, because browsers do not allow a push that shows nothing.
• The sender's photo. A notification about a message from a person can show their photo as a round avatar, with their name on top, instead of as a picture attached to it. On the web the photo becomes the notification's icon. On Android the avatar is in builds made since mid-October 2026; older builds show the photo as a large picture.
• On iOS the avatar is something you ask for. It needs Apple's Communication Notifications capability: your assistant adds it to the app's entitlements file, Floot switches the capability on for your App ID at the next publish, and builds from then on show the avatar. Without it, iOS shows the photo as a small picture on the notification.

Permissions

Floot adds the permissions your app needs on its own: camera and photo access when your app has a file upload or uses the camera (on iOS a file upload offers "Take Photo"), location and microphone when your code uses them, and notifications when you use Floot's push. An app with none of these declares none of them. The default iOS wording is generic, and Apple rejects apps for it — ask your assistant to write purpose strings that say why your app needs each one, such as "Scan receipts to add them to your expenses."

One request for the website and the app

Describe a feature once and say it should work on the website and in the installed app. Your assistant adds the web version and the native plugin and permission for the app, and you test the web half in the preview before you build. For example:

• Say when to ask for permission. For example: "Only ask for location when the user taps the button, never when the app opens." People are more likely to allow it, and a refused permission should leave the rest of the app working.
• Write the permission wording in the same request. For example: "On iOS, ask for location only while the app is in use, with the message 'We use your location to find gift shops near you.'" The wording goes into the next build, and Apple rejects generic wording.
• Selling inside the app. If the website takes payments through Stripe, decide what the app shows before you submit to Apple. Apple has rules on buying digital goods inside iOS apps, and the usual options are to hide the purchase buttons in the app or to add in-app purchases with a plugin. See Can my app sell subscriptions or in-app purchases?.

Things to ask for

Share to your app

Let people share photos, videos, audio, PDFs, text, or links from other apps into yours, from the iOS and Android share sheets. Your assistant also writes the code that receives what was shared.

Work in the background

Run a short piece of your app's code while it is not on screen — when your backend sends a silent push, on iOS and Android, or when iOS gives the app background time. Each wake gets about 25 seconds. The phone decides how often background time comes, and on Android a wake only runs while the app is still alive in the background: once the user swipes it away, wakes are missed.

Status bar style

By default the app sits between solid strips under the status bar and above the home indicator. Ask for a different strip color, light or dark status-bar icons, or edge-to-edge — content running under the bars, with the padding your assistant adds to keep controls clear of them. Each can be set differently for iOS and Android, and the app can change the strip color and icons while it runs, for example when someone switches to a dark theme. Like every native setting, it reaches phones with your next app build. Before that, the iPhone, Pixel and iPad previews show it the way each platform's build will: the strip in your color, or the app under the status bar with the space a real phone keeps clear around the notch and the home indicator. A color the app changes while it runs shows only on a phone.

iPhone-only or iPad-only

iOS builds support iPhone and iPad by default. Ask for iPhone-only if the iPad layout is not ready: the app still installs on an iPad, but runs there as an iPhone app. Ask for iPad-only if the app is made for tablets: the App Store does not offer it on iPhone, and App Store Connect stops asking for iPhone screenshots. Either takes effect with your next app build. This is one-way: once a version that supports a device has been released on the App Store, Apple will not accept an update that drops it, so your assistant asks whether the app is already live before it changes this. Adding a device back later is allowed.

Links that open your app

Links on your own domain that open the app instead of the browser: Universal Links on iOS, App Links on Android. Your assistant adds the native settings for both. It takes a new app build. The order that avoids an extra build is under Links that open your app.

A native plugin

Anything the phone can do that a web page cannot, such as in-app purchases, health data, or Bluetooth, comes from a Capacitor plugin. See Native plugins and native settings for which ones work.

Links that open your app

A link such as https://yourapp.floot.app/shared/abc123 can open straight inside the installed app, and still open the website on a phone without it. On iOS these are Universal Links. They need your published domain, a file on that domain, and a setting in the app, so set them up in this order and they ride along with your next build:

1. 1

   Publish the website and connect Apple

   The links use your published address, so publish the website first (with Publish mobile app off, this uses no build), then connect your Apple account. Have your Apple Team ID ready: it is under Membership details in your Apple Developer account. The bundle ID is your mobile app ID.

2. 2

   Ask your assistant to set them up

   Say which links should open the app, for example "Make links under /shared/ open the matching wishlist inside the iPhone app, and the website when the app is not installed. My Team ID is ABCDE12345. Don't publish yet." It adds the Associated Domains entitlement for your domain (see the ios-entitlements guide; Floot turns the capability on for your App ID at the next publish), a static/.well-known/apple-app-site-association file, and the code that opens the right screen when a link arrives.

3. 3

   Publish the website and check the file

   Publish again with Publish mobile app off. Then ask your assistant to check that https://<your domain>/.well-known/apple-app-site-association answers with your Team ID and bundle ID. Floot serves it as JSON with no redirect, which is what Apple asks for.

4. 4

   Build and test

   Publish with Publish mobile app on, install the build, and tap a link in Messages or Notes. Typing the address into Safari opens the website, not the app; that is how iOS treats typed links.

Android App Links work the same way, with an assetlinks.json file on your domain. Ask your assistant for both platforms in the same request.

Handled for you

• Apple's privacy manifest entries for the native plugins your app uses.
• The Android status bar and keyboard insets, so nothing hides behind the system bars.
• AirPlay and cable connections to a TV or display show a mirror of the iPhone screen.
• After your first app build, your project gains static/__dev/native/ios-info.plist and static/__dev/native/android-manifest.xml. Your assistant can edit them for anything else the stores ask for — ask it to read the ios-info-plist or android-manifest guide first. What each file is for is in Native plugins and native settings.

What counts toward your monthly app builds

On a paid plan the count starts over with each month of your plan, counted from the day it began. On Free it starts over on the first of each month (UTC). Unused builds do not carry over. The Publish mobile app switch shows how many you have left. Once they are used up, it shows the count and the date they come back, with See which builds.

To see which builds used them, open Plan & usage and click App builds this month on the Current plan tab. It lists every build in this month's window with its project, date and platforms, and marks one that is still building or that an Action Boost paid for. It shows your own account's builds across all your projects. A project you collaborate on uses its owner's allowance, so its builds count for the owner, not you.

• A build counts once it finishes, and while it is still running.
• A build that fails does not count, and neither does one that every connected store turned away.
• A build that a newer one replaced while it was running still counts.
• A test build counts the same as a live build.
• At most 2 app builds run at the same time.
• Builds started during an Action Boost never count — see Build actions.