The Screen Where You Lose Customers

A buyer unboxes your product, downloads the app, and thirty seconds later sees a system dialog asking for access to their precise location. Nothing in the box mentioned location. The product is a coffee scale, or a door lock, or a blood pressure cuff. A large fraction of users tap Don't Allow, the app cannot find the device, and the support inbox fills with "the app won't connect."

This is the highest-leverage UX problem in hardware companion apps. Setup completion rates of 60 to 75 percent are common when permissions are handled badly, and above 90 percent when they are handled well. The gap is worth more than most feature work, and closing it costs a few days.

Why Bluetooth Scanning Touches Location at All

BLE advertising packets are, in aggregate, a positioning system. Databases of fixed beacon and device addresses let an app infer where a phone is with room-level accuracy, entirely without GPS. Both platforms recognized this and gated raw scanning behind location permission to close the loophole.

Android held that model for years: any app performing an unfiltered BLE scan needed location permission and, on many versions, location services actually switched on. Newer releases added a separate BLUETOOTH_SCAN permission with a neverForLocation flag, which lets an app that genuinely does not derive location skip the location prompt, provided it never uses scan results for positioning. Older devices in your install base still take the old path, so most production apps carry both code paths for a long time.

iOS split the concerns differently. Plain central-role scanning and connection need Bluetooth permission only. Location becomes necessary when you use iBeacon region monitoring, when you want the app woken in the background by a beacon region, or when you combine BLE with actual positioning. Choosing not to use iBeacon ranging is therefore a product decision that removes an entire permission from your onboarding flow. The platform differences interact heavily with your framework choice, which is why they surface in React Native with BLE and factor into BLE app development cost.

What the User Actually Sees

  • Bluetooth. A short system dialog naming your app and asking to use Bluetooth. On iOS the string you wrote in the usage description appears verbatim; a vague string is a rejection risk during review and a trust problem with users.
  • Location, foreground. On Android the user chooses precise or approximate; approximate is often enough for scanning, and asking for precise when you do not need it looks predatory. On iOS the choice is While Using the App or Once.
  • Location, background. A second, separate, much scarier prompt, and on Android it drops the user into system settings rather than a one-tap dialog. Ask for this only if a documented feature genuinely requires it, because it also triggers extra store review scrutiny.
  • Nearby devices. On recent Android the BLUETOOTH_SCAN and BLUETOOTH_CONNECT permissions present as a friendlier "find and connect to nearby devices" prompt, which converts far better than a location request.
  • Notifications and camera. Often needed too, for alerts and for scanning a QR pairing code. They compete for the same user patience, so sequence them.

Five Rules for Asking Well

Prime before you prompt. Show your own full-screen explanation first, in your own words, with a Continue button that triggers the system dialog. You get one system prompt per permission; spend it after the user already understands why.

Ask at the moment of need. Not on app launch. Request Bluetooth on the "Add your device" screen, when the user has the hardware in hand and wants the thing that requires it.

Name the hardware, not the API. "To find your scale, the app needs to scan for nearby Bluetooth devices" beats "This app requires location access." State plainly that you do not track or store location if that is true.

Request the minimum tier. Approximate over precise, foreground over background, scan-and-connect over full location. Every tier you skip is conversion you keep.

Design the denial path. A user who declines must land on a screen that explains the consequence and offers a deep link into system settings, not a dead scan spinner. Also handle the state where permission is granted but the Bluetooth radio is switched off, which is a different failure with a different fix.

Firmware Choices That Shrink the Problem

Permissions look like an app problem and are frequently a firmware problem. On Android, a scan filtered by a service UUID is treated differently from an open scan, so publishing a distinctive 128-bit service UUID in the advertising packet is the single most useful thing firmware can do for onboarding. Keep the advertising interval tight during pairing mode, around 20 to 100 ms, so discovery feels instant, then fall back to a slower interval to protect battery. Include a short local name and a serial identifier in the scan response so the app can show "Your device, ending 4A2C" rather than a list of MAC addresses. These are ordinary decisions in BLE firmware development, but they have to be made before the app team is fighting the platform. If the product also joins a network, the same principle applies to Wi-Fi provisioning, where a badly designed handoff creates a second permission cliff.

Privacy Is More Than a Dialog

Both stores require a privacy label or data safety declaration that matches what the app actually collects, and a mismatch is a takedown risk rather than a warning. If you request location, you must say why in the listing and in the privacy policy. If you never send location off the device, say that explicitly; it converts. Where the product touches personal or usage data, the obligations under state and international regimes are covered in privacy compliance for connected products, and products aimed at children carry a stricter standard entirely, described in COPPA compliance. Get the declarations right the first time; correcting them mid-review costs a release cycle, as anyone who has been through app store publishing will confirm.

Get Onboarding Right Before Launch

Projects House builds companion apps and the firmware they talk to, which means permission flow, advertising design, and store declarations get decided together instead of being patched after the first bad review. Describe your device and its pairing flow through our contact form and we will review where users are likely to drop out.