WiFi provisioning is one of the most important moments in an IoT product. It is the bridge between a physical device and the operational system behind it. It is also where many products lose user confidence: the device cannot find the network, the phone refuses to switch connections, the SSID is unavailable, a captive portal blocks access, or a permission prompt appears with language the user does not understand.
For Xari, provisioning is not a small setup screen. It is a product workflow that touches mobile development, firmware behavior, cloud integration, security, support, and the customer’s first impression.
The real provisioning problem
An IoT device usually needs WiFi credentials, but it does not have a keyboard, browser, or display. The mobile app must help the user transfer network information securely while the device, phone, and operating system each impose constraints.
A reliable flow has to cover credential transfer, network discovery, wrong passwords, weak signal, hidden networks, special characters, device resets, mobile permissions, captive portals, hotspots, and support diagnostics.
Provisioning architectures have tradeoffs
SoftAP mode is common because the device creates a temporary WiFi network and the app communicates with it locally. It is broadly compatible, but the user experience can be rough: the phone changes networks, the operating system warns about no internet, and modern mobile platforms require user approval.
BLE provisioning avoids WiFi network switching and can provide a smoother setup path, but it requires BLE hardware and introduces Bluetooth permissions, pairing behavior, and BLE reliability concerns. Device-side scanning can give a better cross-platform experience because the device reports the networks it can actually see, but it requires more firmware work.
There is no universal best architecture. The right choice depends on device hardware, enterprise deployment model, security requirements, support expectations, and whether the product needs to work in homes, warehouses, vehicles, clinics, hotels, factories, or managed corporate networks.
Modern mobile operating systems limit what apps can do
Android and iOS have tightened WiFi access for privacy and security. Apps cannot assume they can silently scan all networks, read the current SSID, switch WiFi networks, or route local traffic without user approval. Android versions differ significantly, and iOS is even more restrictive around scanning and network information.
For an enterprise product, this means the provisioning UX must prepare the user for system dialogs, explain permissions before requesting them, and provide manual fallback when automatic detection fails.
Current network detection is a convenience, not a dependency
Getting the phone’s current WiFi network name sounds simple, but in production it can fail for many legitimate reasons: location services are disabled, the app is in the wrong state, the OS blocks access, a VPN interferes, the device is managed by MDM, or the manufacturer has added additional restrictions.
The safer product design is to attempt detection briefly, pre-fill the field if it works, and always let the user type or edit the SSID manually. A provisioning flow should never block because SSID detection failed.
Edge cases are normal in the field
Captive portals are common in hotels, airports, coffee shops, and shared facilities. IoT devices usually cannot complete a browser-based login. Mobile hotspots may work temporarily, but they can disconnect automatically and are not appropriate for permanent installations. Hidden SSIDs and special characters in network names or passwords need deliberate handling.
Many IoT devices support only 2.4 GHz networks. If the user selects a 5 GHz network, setup can fail even when the password is correct. The product should detect or explain these constraints where possible instead of leaving the user with a generic failure.
Security is central to provisioning
Provisioning handles credentials. That makes it a security-sensitive workflow. Credentials should be protected in transit, stored securely on the device, and cleared during factory reset or ownership transfer. The app should verify that it is communicating with the expected device before sending sensitive information.
Enterprise deployments may also need device identity, certificates, cloud registration, fleet assignment, auditability, and policy-driven network behavior. Security has to be part of the architecture, not a final checklist.
Designing for supportability
When provisioning fails, the app should know which step failed. Was the phone unable to connect to the setup network? Did the device reject the credentials? Did the device connect to WiFi but fail to reach the cloud? Did the user cancel a system dialog? Did the product hit a captive portal or unsupported band?
Clear state and telemetry help support teams guide users without guessing. They also help engineering teams see patterns across device firmware versions, routers, mobile OS versions, and deployment environments.
What Xari looks for in enterprise provisioning
- A provisioning state machine with clear progress and recovery paths.
- Platform-specific handling for Android and iOS permissions and dialogs.
- Manual SSID entry as a first-class fallback.
- Support for hidden networks, special characters, and 2.4 GHz constraints.
- Security controls for credential transfer, device identity, and credential storage.
- Diagnostics that distinguish app, firmware, network, and cloud failures.
- Provisioning flows that can connect to Azure IoT Hub, AWS IoT Core, or custom cloud services after onboarding.
Where this fits in Xari projects
Provisioning sits at the intersection of mobile development, firmware, IoT cloud architecture, and security. A reliable setup experience requires all of those pieces to agree on device identity, network behavior, errors, telemetry, and recovery.
That is why Xari designs provisioning as part of the product lifecycle: onboarding, diagnostics, updates, support, and fleet operations.
Adapted from engineering notes originally published at xafmarin.com.
