No Screen, No Keyboard, No Obvious Way In
The device was a small handheld controller with 4 to 8 physical buttons, depending on the model. Battery powered. No display. The buttons would send commands to wireless speakers on the home network, letting users control music without pulling out a phone. Simple in concept, fiddly in practice.
The snag was onboarding. A screenless device cannot prompt for a Wi-Fi password. It cannot show a list of available networks. It cannot display error messages when something goes wrong. Every configuration step that a phone handles through its touchscreen has to be rethought for a device that has no screen at all.
The client had the hardware design locked. Sequoia's job was to build the firmware that would run on the controller and the iOS companion app that would serve as its proxy interface. The app needed to get the device onto the home network, discover it there, let the user pick which speaker to control, and then get out of the way. After setup, the controller would talk directly to the speaker system without the phone in the loop.
Firmware and App, Both Sides of the Handshake
Sequoia Applied Technologies is a Santa Clara software engineering firm that builds embedded systems, mobile apps, and IoT platforms for consumer electronics, life sciences, and enterprise software companies. This engagement covered both the firmware running on the controller and the iOS companion app.
The firmware side involved the provisioning state machine, TCP command handling, credential storage, speaker protocol integration, battery monitoring, and a chirp feature for locating a misplaced device. The controller had to start in access point mode, accept credentials from the app, reboot onto the home network, and then advertise itself for discovery. All of this had to work reliably on a resource constrained microcontroller with battery life constraints.
The iOS side was its own tangle. Apple does not let apps scan for Wi-Fi networks or join them programmatically. The published APIs simply do not expose that functionality. Every onboarding flow that involves network switching has to bounce the user out to the iOS Settings screen and back. That creates friction, but using private APIs would have gotten the app rejected from the App Store. Sequoia designed the flow to minimize confusion while staying within Apple's guardrails.
SoftAP Provisioning and Local Discovery
The setup flow started with the controller in SoftAP mode. On first power up, or after a factory reset, the device would broadcast a temporary Wi-Fi network with a unique SSID. The user would open the companion app, which would prompt them to connect to this temporary network through iOS Settings. Once connected, the app established a TCP connection to the controller and collected the home network credentials from the user.
The app sent the SSID and password to the controller, which stored them in flash and rebooted. On restart the controller joined the home network as a regular client on the 2.4 GHz band, chosen for range and compatibility with older routers. The user meanwhile reconnected their phone to the home network, either manually or by following the app's prompts.
With both devices on the same network, the app used local discovery protocols to find the controller without requiring a cloud account or internet access. The controller advertised itself on the LAN, the app picked up the advertisement, and communication resumed over a fresh TCP connection. From there the user could select a speaker room from a list of discovered devices and bind the controller to it. The controller stored the speaker's network address and began communicating directly with the speaker system's local API.
The protocol between app and controller covered credential transfer, device ID queries, speaker binding, battery level polling, connection status checks, and a chirp command that made the controller emit an audible tone for finding it under a couch cushion. Firmware updates could be pushed over the air when new versions became available, with the app notifying the user and managing the download and install sequence.
Setup in Minutes, No Cloud Account Required
The finished system let users complete first time setup in a few minutes. The flow was not as slick as it would have been on Android, where apps have more latitude with Wi-Fi APIs, but it stayed within Apple's rules and guided users clearly through the necessary Settings detours. Support calls dropped because the app surfaced errors and status at each step instead of leaving users to guess.
Local discovery meant no mandatory cloud sign-in, no account creation friction, no reliance on external servers for basic functionality. The controller and speaker talked directly over the LAN. The app remained useful for reconfiguration, battery alerts, firmware updates, and the find-my-device chirp, but it did not have to be running for the controller to work.
For companies building headless consumer devices, the broader point is that the setup experience is the product experience for most users. They will only see the app once, during onboarding, and if that goes badly they will return the hardware. Investing in a polished provisioning flow, even when the platform makes it awkward, pays back in lower support load and better reviews.
Common Questions About Headless Device Setup
What is a headless device and why does it need a companion app?
A headless device has no screen or keyboard for direct user interaction. Without a display, there is no way for users to enter Wi-Fi credentials, select settings, or see status feedback. A companion app on a phone fills that gap by providing the interface the device itself lacks. The app handles discovery, credential transfer, configuration, and ongoing status display while the device does the actual work.
How does a headless device get onto a home Wi-Fi network without a screen?
The device starts in SoftAP mode, broadcasting its own temporary Wi-Fi network. The companion app connects to that network, collects the home Wi-Fi credentials from the user, and sends them to the device over a local TCP connection. The device stores the credentials, reboots, and joins the home network as a regular client. The app then reconnects to the home network and rediscovers the device there.
Why does the setup flow require switching Wi-Fi networks multiple times?
iOS does not allow apps to programmatically scan for Wi-Fi networks or join them directly. Apple restricts these APIs for security reasons. The workaround is to send the user to the iOS Settings screen to select networks manually, then return to the app. This creates extra steps but is the only sanctioned path on iOS without using private APIs that would get the app rejected from the App Store.
How does the app discover the device on the local network?
Once both the phone and the device are on the same home network, the app uses local discovery protocols to find the device by its advertised service name. No cloud account or internet connection is required for this step. The device announces itself on the LAN, the app picks up the announcement, and communication proceeds over a direct TCP connection between them.
What happens after the device is on the home network?
The app queries the device for its capabilities and presents a list of compatible speaker systems. The user selects a speaker or room, and the app sends the speaker's network address to the device. From that point the device communicates directly with the speaker system over the local network. The app remains useful for status monitoring, battery alerts, firmware updates, and reconfiguration if the user moves to a new home or changes speakers.
What embedded and mobile work did Sequoia deliver for this project?
Sequoia Applied Technologies built the embedded firmware running on the controller and the iOS companion app. The firmware handles SoftAP provisioning, credential storage, network join, speaker communication, battery monitoring, and a chirp command for locating a misplaced device. The app handles the setup flow with its iOS constraints, device discovery, speaker selection, status display, low battery notifications, and over the air firmware updates.