Setup global mobile settings in your app
Navigate to Settings > Mobile settings, where you’ll find all the settings related to native mobile apps, regardless of where you publish, that you must fill out.
To ensure everything will work, fill these out as follows:
App display name: This is the name of your app as it will appear to users on their device’s home screen. Choose a concise and descriptive name that aligns with your app’s purpose.
App icon: The visual representation of your app on users’ devices. This icon should be high quality and adhere to the design guidelines for the platform you are deploying to (iOS or Android).
Note: For your app icon in mobile settings, we recommend using a PNG or SVG file. Some file formats, such as
.avif, are not supported and may cause your build to fail.
Splash screen background color: The background color displayed during the app’s launch while the app initializes. Choose a color that complements your app’s branding and creates a seamless transition into the main interface.
App scheme (optional): A unique identifier used for deep linking and handling redirections from external services, such as OAuth or payment gateways. See more information below.
Using the app scheme setting
The App Scheme setting is optional and should only be configured if your app specifically requires a custom scheme (for example, when setting up deep linking). In most cases, Bubble will automatically handle this for you, and you don’t need to provide a value.
If you do need to define a custom app scheme:
The format is typically: appname
All characters must be lowercase
Only alphanumeric characters, periods (.), and hyphens (-) are allowed
Make sure to follow these formatting rules carefully to ensure compatibility across platforms.
Universal links
Universal links (called App Links on Android) let a standard https:// link on your app’s domain open your installed mobile app directly, instead of opening a web page. Compared to custom-scheme deep links (myapp://), universal links work reliably in email clients, SMS, and social media, and behave like a normal web link on devices that don’t have your app installed.
Once set up, use the Create a mobile deep/universal link workflow action and choose any Fallback other than None to generate shareable universal links to specific views in your app.
Setting up universal links
Validate your store settings. The universal link fields only appear after your store credentials have been validated — your Apple Team ID and bundle ID in the Apple App Store section (for iOS), and your package name in the Android Play Store section (for Android).
Enable universal linking. In Settings → Mobile → Device permissions, turn on the Universal linking card. This registers your app’s domain with your mobile builds so the operating system knows your app can handle links to it. For iOS, Bubble also enables the Associated Domains capability on your app’s Apple identifier automatically — no changes are needed in the Apple Developer portal.
iOS: enter your iOS App Store ID in the Universal Links section of the Apple App Store settings. This is the numeric Apple ID of your app, which you can find in App Store Connect under App Information → Apple ID (it also appears in your App Store URL, after
id). Bubble uses it to send iOS users to your App Store listing when they open a universal link with the App store fallback without the app installed.Android: enter your Android SHA-256 fingerprint in the Universal Links section of the Play Store settings, as a comma-separated list. Find them in the Google Play Console under Protected with Play → Play Store protection: next to Protect app signing key, click Manage Play app signing, then copy the SHA-256 certificate fingerprint under App signing key certificate.
Create and install a new build. Universal linking is configured at build time, so it only takes effect in builds created after you complete the steps above. Users must update to the new build before universal links will open the app on their device.
How verification works
Apple and Google verify that your app is allowed to handle links for your domain by checking two files that Bubble hosts automatically on your app’s live domain:
https://yourdomain/.well-known/apple-app-site-association— generated from your Apple Team ID and bundle IDhttps://yourdomain/.well-known/assetlinks.json— generated from your Android package name and SHA-256 fingerprints
You don’t need to create or host these files yourself, and no custom domain is required — they are served on your custom domain if you have one, or on your .bubbleapps.io domain otherwise. Each file becomes available as soon as the corresponding identifiers are filled in.
On plans that include root-directory file hosting, you can serve your own versions of these files instead: in Settings → SEO / metatags → Hosting files in the root directory, upload a file with the name .well-known/apple-app-site-association or .well-known/assetlinks.json. Bubble will serve your file in place of the generated one — useful if you need to associate additional apps with your domain.
Notes and limitations
Universal links always point at your app’s live domain. If you later change your domain, create a new build — links generated before the change and builds installed before the change will not match the new domain.
Only links generated by the Create a mobile deep/universal link action (and Bubble’s built-in flows) open the app. Ordinary links to pages of your Bubble web app will continue to open in the browser.
The operating system verifies your domain when the app is installed or updated, so changes to these settings only affect devices after they install a new build. Apple also caches the association file on its CDN, so allow up to 24 hours for changes to propagate to new installs.
Device permissions
Overview
The Device Permissions section in the Native Mobile Settings tab lets you explicitly control which hardware or system features your app will request access to. This ensures that your app only includes the permissions it actually uses — helping avoid app store review issues.
Previously, every permission supported by Bubble was automatically included in the build file, even if your app didn’t use it. This could cause problems during the app review process, especially on Google Play, where unused permissions may lead to rejections or additional scrutiny.
How it works
Permissions are toggled off by default. If your app requires access to a specific device feature, you’ll need to manually toggle that permission on.
The available permissions include:
Camera access
Microphone access (required for Camera access)
Photo library access
Location access
Sign in with Apple
Universal linking
When you enable a permission, Bubble includes it in the app build so that the relevant app store (Apple or Google) is aware.
Using workflows with permissions
If your app includes a workflow that depends on one of these permissions — for example, using the Open camera action — but the corresponding permission is not enabled, Bubble will display an issue in the issue checker. This helps ensure that your permission settings are always in sync with your app’s functionality.
Updating your build
Changes to device permissions require a new build submission. If you toggle a permission on or off after your app has been built, you’ll need to rebuild and resubmit your app for the changes to take effect.
Customizing permission request text
Each permission request must be accompanied by a user-facing short explanation of why your app needs access. You can update this text in the Languages tab. The settings panel includes a link to that section to help guide you there.
Providing clear, accurate language helps improve your chances of passing the app store review and builds trust with your users.