The honest answer for a companion app that pairs to a physical product, controls it, and shows data is four to seven months from kickoff to a version in both stores. Teams quoting six weeks are describing a screen mockup with a fake data source. The reason a companion app takes longer than a standalone app has almost nothing to do with the app: it cannot be finished before the hardware it talks to behaves consistently, and hardware behaves inconsistently for a long time.
Here is how the calendar actually fills, so you can plan a launch date that survives a beta program.
Timeline by Scope
Tier one: a controller, six to ten weeks
Connect over BLE, send commands, read a few characteristics, show status. No accounts, no cloud, no history. One platform, two or three screens. This is genuinely a two-month job, and it is the right first release far more often than founders accept — the argument for staying here is made in does your product really need a companion app.
Tier two: connected product with accounts, three to five months
User registration, device provisioning, cloud sync, history charts, push notifications, firmware update delivery, settings, both platforms. This is where most consumer hardware lands. The backend is now on the critical path alongside the app, and both teams must agree on an API contract early or each builds to a different assumption.
Tier three: platform-grade, six to twelve months
Multiple device types, roles and permissions, offline-capable data, third-party integrations, and a web dashboard. Products in this tier usually need two applications — an end-user app and a separate installer or service build — which doubles the QA surface.
Where the Weeks Actually Go
For a tier-two project on a fourteen to eighteen week schedule, a representative allocation:
- Definition and UX, 2 to 3 weeks. Screen flows, pairing sequence, error states, data model. Underspecified error states are the largest source of later rework.
- Backend and API, 3 to 5 weeks. Device registry, authentication, telemetry ingest.
- Core app build, 6 to 8 weeks. Screens, state management, local storage.
- BLE integration, 3 to 6 weeks, overlapping but rarely compressible.
- Integration and field testing, 3 to 4 weeks. Real devices, real phones, real interference.
- Store submission and fixes, 1 to 3 weeks.
Those add to more than the calendar length because they overlap. What does not overlap is the dependency chain from firmware to app.
The BLE Tax
Bluetooth Low Energy is the largest single schedule risk in a hardware app, and it is underestimated because a demo connecting to a dev board works on day three. The hard part starts after that.
- Android fragmentation. Handsets implement the BLE stack with different quirks in connection intervals, MTU negotiation, and bonding. A pairing flow that is flawless on a Pixel can fail on an older Galaxy. Budget a test matrix of eight to twelve physical Android devices.
- Background execution. Both platforms aggressively suspend apps. Reconnecting reliably after the phone sleeps is a specific engineering problem, not a setting.
- Permission flows. Recent iOS and Android versions require location and nearby-device permissions with prompts that confuse users and change between OS releases; the current state is described in Bluetooth and location permissions.
- Reconnection and state recovery. Users walk away, the link drops, the device reboots. Handling this gracefully is where several weeks disappear.
The firmware side of the same interface is a parallel workstream covered in BLE firmware development, and its schedule couples directly to the app's.
Hardware Dependency: The Real Reason Apps Slip
An app team cannot finish against a moving target. Three patterns cause most delays:
- Firmware is not ready. The app team gets a partial GATT implementation, builds against a simulator, and discovers on integration that characteristics changed. Mitigation: freeze the interface specification — service UUIDs, characteristic formats, byte order, units — before app coding starts, and version it.
- Not enough prototype units. Two hand-built prototypes shared among four developers and a QA tester is a bottleneck that costs weeks. Ten units at the start of integration is a cheap purchase against developer idle time.
- Hardware revisions. A board spin that changes the sensor or the radio module forces app rework. Aligning the app plan with the EVT, DVT, and PVT build stages prevents the app from being built against hardware that no longer exists.
A practical rule: start app definition and UX early, but do not start heavy BLE integration until firmware reaches a stable EVT build. Starting sooner does not finish sooner.
App Store and Play Review
Review time is short but the calendar risk is real. Apple's App Store review currently turns most submissions in 24 to 48 hours, with occasional multi-day holds. Google Play is often faster for updates but a first submission from a new developer account can take up to seven days, and new accounts face additional testing requirements before production release. Neither should be the thing you discover two weeks before a launch event.
Rejections that hit hardware apps specifically: a Bluetooth permission string that does not explain why the app needs it, an app that appears non-functional to a reviewer who has no device, and account deletion requirements. Ship a demo mode and a reviewer note. Submission mechanics are in how to publish an app to the App Store and Google Play, and if hardware is scarce, launching one platform first is a legitimate schedule lever discussed in iOS and Android at launch.
Compressing the Schedule Without Breaking It
- Cut scope, not testing. Accounts and analytics dashboards can wait; a reliable pairing flow cannot.
- Use a cross-platform framework where it fits — it can save 25 to 35 percent on a two-platform build, with the caveats in native versus cross-platform development.
- Freeze the BLE interface spec in writing before coding.
- Run the beta with real users on their own phones for at least three weeks; lab testing does not surface the Android device that fails to bond.
- Submit a TestFlight and internal-testing build early so store accounts, certificates, and provisioning are done long before launch.
Budget planning belongs alongside the schedule; the cost drivers are broken down in how much a BLE app costs to develop.
Plan the App and the Hardware as One Project
Projects House develops firmware, app, and cloud together, so the interface between them is specified once rather than renegotiated at integration. Send your product concept, target launch window, and current hardware stage through our contact form for a schedule that accounts for the dependencies.