Connecting a Device to a Mobile App: Bluetooth, Wi-Fi and the Cloud

Three ways an app talks to a device

• Directly over Bluetooth Low Energy (BLE). The phone and the device talk when they are near each other. This suits wearables and other devices used close to the phone.
• Over the local network. The device joins the home or office Wi-Fi, and the app finds and talks to it on that network.
• Through the cloud. The device sends data to a server, and the app talks to the server. This works from anywhere and allows history and notifications.

Many products combine them: Bluetooth for setup, then Wi-Fi and the cloud for everyday use.

How Bluetooth Low Energy works

Android's BLE overview explains the model most devices use. BLE is designed for much lower power use than classic Bluetooth. One side, usually the device, advertises; the other, usually the phone, scans for those adverts and connects. Data is then organised with the Generic Attribute Profile (GATT): a device offers services, each a group of characteristics, and each characteristic holds one value, such as a temperature reading or an on/off setting. The app reads, writes or subscribes to those values.

So the device's GATT layout is effectively the contract between the firmware and the app. Agree it before either side is built.

Two points from the documentation are worth knowing early. Android warns that once a phone pairs with a BLE device, the data exchanged is accessible to all apps on that phone, so sensitive data needs its own protection at the application level. And the Bluetooth SIG states that all Bluetooth products must be qualified on or before the date you start selling them, under your own company's SIG membership, with a fee for each new design.

First-time setup: getting the device online

Setup, often called onboarding or provisioning, is the step users see first and the one that most often goes wrong. A Wi-Fi device has to learn the network name and password. The common patterns:

• Bluetooth handoff: the app connects to the device over BLE and sends it the Wi-Fi details. After that, the device uses Wi-Fi.
• Temporary access point: the device creates its own Wi-Fi network, the phone joins it briefly, and the app sends the details. On Android 10 and later, the Wi-Fi network request API is built for this; the user approves the connection, and Google notes that it does not give the phone internet access while connected. On iPhone, NEHotspotConfigurationManager lets an app join a network after the user approves it.
• The platform's own setup screens: Android's companion device pairing (Android 8.0 and later) scans for nearby Bluetooth or Wi-Fi devices on the app's behalf, without the app needing the precise location permission. Apple's AccessorySetupKit (iOS 18 and later) lets an app discover and set up Bluetooth or Wi-Fi accessories in a system sheet showing the product's name and image, with Apple describing it as privacy-preserving consent for Bluetooth, Wi-Fi and local network access.

Whichever you use, test setup on many phone models and OS versions, with weak signal, wrong passwords and a device that was set up before.

What iPhone and Android ask of your app

Both platforms treat nearby-device access as private, so the app must ask for it and explain why.

• iPhone: an app that uses Bluetooth must include the NSBluetoothAlwaysUsageDescription key, a message telling people why it needs Bluetooth. Apple's Core Bluetooth documentation says an app without the required usage description will crash when it tries to use those APIs. An app that talks to devices on the local network should include NSLocalNetworkUsageDescription, and the user is asked for local network access.
• Android 12 and later: the Bluetooth permissions are split into BLUETOOTH_SCAN (finding devices), BLUETOOTH_CONNECT (talking to paired devices) and BLUETOOTH_ADVERTISE. If the app never uses scan results to work out location, it can declare that with the neverForLocation flag.
• Android 11 and earlier: Bluetooth scanning requires the fine location permission, requested at runtime.

Ask at the point the user starts setup, with a one-line reason, rather than on first launch.

Where Matter fits

If you make a smart-home product, consider Matter, the standard from the Connectivity Standards Alliance. The CSA says Matter runs on Wi-Fi and Thread networks, uses Bluetooth Low Energy for setup, and lets devices from different brands work together, including with Amazon Alexa, Apple's Siri and Google's Assistant.

Matter covers smart-home device types. If your product does something outside them, or you want features such as detailed history, user accounts or a dashboard for your team, you will still need your own app and cloud alongside it. Matter certification goes through the CSA, so plan for it in the timeline if you go this route.

Software updates and security rules

Firmware will need fixes after launch, so plan over-the-air (OTA) updates from the start. The European standard ETSI EN 303 645 (V3.1.3, 2024) sets the baseline for consumer IoT security. Among its provisions:

• no universal default passwords: each device's password must be unique or set by the user;
• a published way to report security vulnerabilities;
• software kept updatable, with the device checking that each update delivered over a network is authentic before installing it;
• a published support period, so buyers know how long updates will come;
• secure communication, protected personal data and an easy way for users to delete their data.

In the UK, these ideas are now law for many consumer connected products. The government's product security regime (PSTI), in force since 29 April 2024, requires passwords that are unique per product or set by the user, published information on how to report security issues, and published minimum security update periods.

Planning the app and the device together

1. Pick the connection paths (Bluetooth, local Wi-Fi, cloud) from how and where people will use the product.
2. Write down the interface between firmware and app: the GATT services and characteristics or the network API, and how versions change.
3. Design setup first, including failures and factory reset, and test it on real phones.
4. List the permissions each platform needs and where in the app you will ask.
5. Plan updates and security against ETSI EN 303 645 and, for the UK market, the PSTI rules.
6. Budget the app properly. Our guide to app development costs covers what drives the price, and scoping an MVP helps you decide what the first release needs.

Frequently asked questions

Should my device use Bluetooth or Wi-Fi?

Bluetooth Low Energy suits devices used near the phone and running on batteries. Wi-Fi suits devices that need to be reached from anywhere or send data all the time. Many products use Bluetooth for setup and Wi-Fi with a cloud service afterwards.

Why does my Android app ask for location to find a Bluetooth device?

On Android 11 and earlier, Bluetooth scanning requires the location permission. On Android 12 and later, apps use the BLUETOOTH_SCAN permission instead and can declare that they never use scan results for location.

If my product supports Matter, do I still need my own app?

Not necessarily for basic control, since users can set up and control certified devices from the smart-home apps they already use. You still need your own app for features Matter does not cover, such as accounts, history or product-specific settings.

Which security rules apply to a connected product in the UK?

Since 29 April 2024 the UK product security regime requires many consumer connected products to have unique or user-set passwords, a published way to report security issues and a published minimum security update period. ETSI EN 303 645 sets a wider baseline.

Building a connected product? We design the device connectivity, the cloud and the apps as one system. See our IoT product development and mobile app development services, or email info@creahive.com.