Solfreaks IoT Connect builds the mobile app that pairs with your hardware: Bluetooth Low Energy pairing, Wi-Fi setup, live data, cloud dashboards and firmware updates over the air. We write the app and the cloud side. The firmware is usually yours or your hardware vendor's, and we work closely with whoever owns it.
Connected products tend to go wrong at the boundary between phone and device: a connection that drops when the screen locks, a permission prompt nobody planned for, an update that fails halfway. Most of our effort goes there.
The awkward parts nobody warns you about
Bluetooth permissions changed with Android 12, which split them into separate scan and connect permissions, while older versions still tie scanning to location access. iOS shows its own Bluetooth prompt and hides device MAC addresses, so identifying a device needs a design decision early. Both platforms also limit background work. iOS needs specific background modes and state restoration to wake an app for a Bluetooth event, and Android wants a foreground service for long connections, while some phone makers close background apps more aggressively than Google's own rules suggest.
Then there is reconnection. Real devices go out of range, run flat and reboot, and phones handle that more messily than simulators suggest. We test against your actual hardware with the phone in a pocket, the screen locked, and the device wandering out of range and back, because that is where the bugs live.
What's in the delivery
- BLE pairing and bonding. Scan, connect, pair and re-pair flows, with clear messages when the device is off, out of range or already paired with someone else.
- Wi-Fi provisioning. Sending the home network details to the device over BLE or its temporary access point, which each operating system treats differently.
- Cloud connection. MQTT or HTTPS ingestion through a broker such as Mosquitto, EMQX or AWS IoT Core, with per-device credentials over TLS, built on the principles in our backend and API development.
- Live and historical data. Charts in the app, plus a web dashboard for you or your support team, similar to our admin panels and dashboards.
- Over-the-air firmware updates. Nordic's DFU or an ESP32 update flow, with progress, resume and a clear recovery path if the transfer fails.
- Secure pairing and storage. Encrypted links, no shared keys baked into the app and tokens kept in the platform keystore.
- A written test protocol. A checklist run on real devices before each release, covering reconnects, denied permissions and background behaviour, in line with our mobile app QA approach.
How a project goes
- Hardware and protocol review. We read the datasheet and the GATT profile or MQTT topics and send questions to your firmware author. If the protocol isn't written down yet, we write it with them.
- Hardware in hand. We ask for a couple of units or a development board that behaves like yours. Courier and customs time to Pakistan can take a week or two, so we plan around it.
- Pairing spike. A rough app that connects, reads and writes, built to prove the radio side before anyone polishes screens.
- App and cloud build. Screens, background behaviour, the cloud pipeline and dashboards in two-week cycles, each ending with a build you can install.
- Field testing. Real homes or sites, phones from several makers, bad Wi-Fi and low batteries.
- Release and monitoring. Store release, crash and connection-failure monitoring, and a plan for the firmware versions already in customers' hands. Allow a few days for store review.
When to hold off
This suits hardware start-ups with a working prototype and no mobile team, product companies adding an app to existing devices, and agencies whose client's device needs an app.
A companion app is probably not for you if the hardware isn't designed yet. Firmware, power budget and radio choice decide what the app can do, and it's cheaper to settle those before anyone builds screens. We don't build or certify hardware either, and we won't choose your board or antenna for you, though we'll gladly explain what a choice means for the app. If all you need is a sensor reading shown in a browser, a small web dashboard may be enough.
What affects the cost of a connected product
Expect the price to depend on the number of device types and firmware versions, whether the connection is BLE only or includes Wi-Fi and cloud, how much must run in the background, the data and dashboard features, and the amount of real-device testing. We quote a fixed scope for a pairing spike and a first release, and offer a monthly arrangement afterwards for firmware compatibility and operating system updates. A proof of connection typically takes two to three weeks once we have hardware, and a first store release usually takes two to four months. The quote follows a short discovery call.
Who you'd talk to
Calls with us are with the developers who will write your app, from Rawalpindi on Pakistan time. Android's Bluetooth rules are not theory to us, since we release apps on Google Play. You own the code, the cloud account and the store accounts. If your device is ready for a phone to talk to it, book a short call and send us the datasheet.
Open-source tools and references
A few public projects that come up a lot in this kind of work. They belong to other people and teams. We link to them because they are worth a look, not because anyone pays us to.
- espressif/esp-idfOfficial development framework for ESP32 chips.
- eclipse-mosquitto/mosquittoWidely used open-source MQTT broker.
- nordicsemi/Android-BLE-LibraryBluetooth Low Energy library for Android.
Frequently asked questions
Do you write the firmware as well?
Our work is the app and the cloud side. Firmware normally belongs to you, your hardware vendor or a contractor, and we work with them on the protocol between device and phone. If you have no firmware engineer, say so on the first call. We will tell you honestly what we can take on and where you need a specialist.
Which boards and chips do you work with?
ESP32 and Nordic-style boards are the usual ones, and anything that speaks standard BLE GATT or MQTT can talk to the app. Classic Bluetooth is a different matter: Android supports it, but iOS limits it to accessories in Apple's MFi programme, so a device meant for iPhones should use BLE. If your board is unusual, send the datasheet and we'll tell you what to expect.
Can you build it without our hardware in front of you?
We can start the screens and the cloud side, and a BLE peripheral simulator helps with early logic. But reconnects, signal strength, pairing quirks and power behaviour only show up on the real device, so we ask for a couple of units before the pairing spike. Skipping this usually means finding the problems after launch, when they cost more.
Will the app stay connected when the phone is locked?
Sometimes, but nobody can guarantee it. iOS and Android both limit background work, and some Android makers are stricter still. We use the permitted mechanisms, such as background modes on iOS and a foreground service on Android, and design the product to recover: the device buffers data and the app syncs as soon as it reconnects.
How do firmware updates reach customers safely?
The app fetches a signed firmware image from your server, checks the version, sends it to the device over BLE or Wi-Fi and shows progress. The device should verify the signature before switching over and keep the old image if anything fails. We build the app and server side, but the device side must support it, so we recommend designing updates into the first hardware revision.
Talk it through with us
Tell us what you are building and where it hurts. You get a straight answer, a plan and a price, and if we are not the right people we will say so.
