Native plugins and native settings
Which Capacitor plugins work in a Floot app, what a plugin of your own needs, the native config files your project carries, and what the build does not support.
Floot builds your iOS and Android apps with Capacitor 8. Anything the phone can do that a web page cannot comes from a Capacitor plugin, and the native settings live in a few files in your project that the assistant you build with edits for you.
Which plugins work
Capacitor plugins published on the public npm registry work, both the official @capacitor/… ones and community ones. Plugins built for Capacitor 8 are the ones to pick. Ask your assistant for the feature. It adds the plugin as a dependency of your project and writes the code that calls it.
- The plugin has to be used in your code. A build leaves out any dependency that no file in your project imports, so a plugin that is installed but never imported is not in the app.
- It takes a new app build. A plugin is native code, so it reaches phones only in a build made after it was added.
- It does nothing in the preview. The preview and your website run in a browser, where there is no native side to call. Your assistant guards plugin calls so they run only in the native app. Use a test build to try a plugin on a real phone.
- Permissions come with it. A plugin's own Android permissions and services are merged into the app. On iOS, ask your assistant to add the purpose string for anything the plugin makes iOS ask permission for.
Every build includes Capacitor's core, @capacitor/app, @capacitor/browser and @capacitor/status-bar at version 8.0.0, and Floot adds the push plugin itself when your project uses its built-in push.
A plugin of your own
A Floot project holds web code only: it cannot contain Swift, Kotlin or Java files. To ship native code of your own, package it as a Capacitor plugin, publish it to the public npm registry, and have your assistant add it like any other plugin. It needs:
- A public npm package. Private registries, git URLs, tarballs and local paths are not installed.
- An import in your project. As with every plugin, it is left out of the build unless your code imports it.
- CocoaPods on iOS. The iOS project is built with CocoaPods, so the plugin needs a podspec. The app's deployment target is iOS 15.5, so the podspec has to allow iOS 15.5 too. A plugin that uses a newer framework has to link it weakly and check availability in code.
- Android 8.0 on Android. The app's minimum is Android 8.0 (API 26). Permissions, services and other entries the plugin declares in its own manifest are merged into the app, a foreground service included.
- An exact version while you iterate. A build prefers package versions that have been on npm for at least a day, so a version range can resolve to yesterday's release. Pin the exact version you just published to get it.
The native config files in your project
Three files under static/__dev/native/ hold the native settings. They are part of your project, your assistant edits them, and changes ship with the next app build. They never appear on your website.
| File | What it is | When it exists |
|---|---|---|
ios-info.plist | The iOS app's Info.plist: permission wording, and any other key Apple asks for. | After your first iOS build |
android-manifest.xml | The Android app's manifest: extra permissions, App Links, and other entries Google Play asks for. | After your first Android build |
ios-entitlements.plist | The iOS app's entitlements, for capabilities such as HealthKit, Sign in with Apple, Associated Domains or NFC. | Only when your app needs one; your assistant creates it |
Ask your assistant to read the ios-info-plist, android-manifest or ios-entitlements guide before it edits one. A few things in these files stay Floot's:
- The version and build number are written on every build. Set the version in the Version row on the Publish screen.
- The app name, the bundle ID and the app's URL scheme are not edited here. See the mobile app ID and the app name.
- Permissions your app's features need are put back on every build, so removing one of them does not stick.
- The push entitlement and the share target's app group are added by Floot. They do not go in the entitlements file.
- A file that is no longer valid XML fails the build.
Everything else in the ios/ and android/ folders is generated fresh on every build. A change made in Xcode or Android Studio to a downloaded project is not kept, and capacitor.config.json cannot be edited.
iOS capabilities
An entitlement only works if the matching capability is switched on for your app in your Apple developer account. Floot switches these on for you at the next publish: push notifications, HealthKit, HomeKit, Associated Domains, Sign in with Apple, NFC tag reading, Access Wi-Fi Information, Hotspot, Multipath, Personal VPN, SiriKit, Wallet, ClassKit, Wireless Accessory Configuration and Game Center.
Any other capability you switch on yourself in the Apple Developer portal before you publish. That includes iCloud, Apple Pay and Data Protection, and the capabilities Apple has to approve first, such as FinanceKit and CarPlay, which only your team's Account Holder can request. If one is missing, the publish stops before the build and names the entitlement.
What the build does not support
- React Native and Expo packages. The app is your web app in a native shell, so they cannot be installed.
- Native source files in the project. No Swift, Kotlin or Java outside a plugin, and no extra Xcode targets.
- App extensions and widgets of your own. The share sheet and notification extensions are the ones Floot adds itself.
- Your own Android image resources. A project cannot add files to the Android
resfolders, so the notification icon is the app icon. - Secrets for the build. There is nowhere to give the build a token of your own, which is why packages from a private registry cannot be installed.
- An outside build service. Builds run on Floot's own machines. A service such as Ionic Appflow cannot take the build's place, though you can download the project zip and build it yourself — see Installing your iOS app and Installing your Android app.
Background work
A native app is a web page in a shell, and phones stop a page that is not on screen. What you can do depends on how long the work runs:
- A short task now and then
- Ask your assistant for background work: your app's own code runs for about 25 seconds when your backend sends a silent push, or when iOS gives the app background time. See Native app features for the limits.
- Location while the app is in the background
- Use the
@capacitor-community/background-geolocationplugin. The Android build switches on the setting that plugin needs by itself. - Work that must keep running on Android
- Step counting, sensors, or a tablet that has to stay ready for orders need an Android foreground service, which comes from a plugin: a community one such as
@capawesome-team/capacitor-android-foreground-service, or a plugin of your own. Android shows a permanent notification while it runs, and Google Play asks you to declare the foreground service in Play Console. - Work with no need for the phone
- If both the input and the result live on your server, run it there instead: a scheduled job or a background task has none of a phone's limits. See Scheduled jobs and background tasks.
The phone has the last word
iOS runs nothing for an app the user force-quit, in Low Power Mode, or with Background App Refresh off. Android can stop an app in the background at any time unless a foreground service keeps it alive. No plugin changes that.