EEG Mobile App Development: A Technical Guide for Biosignal Hardware Teams

An EEG companion app is a data-acquisition system that happens to run on a phone. Its job is not merely to connect and draw a waveform. It must preserve sample order and timing, survive mobile lifecycle changes, expose gaps honestly, and produce a recording whose limitations can be assessed.

The engineering experience represented here includes mobile work involving EEG, EDA, and HR/HRV devices, including the Nucleus-Kit platform from RE-AK Technologies and a CLEIO product team. The article separates measured product behavior from transport assumptions.

Why Biosignal Apps Fail Differently

The acceptable gap, latency, and alignment error depend on the study protocol, algorithm, intended use, and claims. Define those limits with the scientific and product owners before choosing transport or buffering behavior.

The constraints that define this domain:

• High-frequency continuous streaming. EEG at 250 Hz across 8 channels is 2,000 samples per second. At 24-bit resolution, that is roughly 48 kbps of payload, before BLE overhead. Higher channel counts and higher sampling rates push this well past 100 kbps sustained.
• Defined timing accuracy. Capture and alignment requirements come from the analysis, not from a generic "millisecond accurate" claim.
• Visible data loss. Lost data must be detected and represented explicitly. Recovery is useful only when the peripheral protocol and buffer support it.
• Long sessions. The design must either maintain the link through required screen and background states or recover with explicit gaps and session state when interruption occurs.
• Hardware variation. The same app may need to talk to a custom headset, an off-the-shelf wearable, and a research-grade device with completely different firmware behavior.

BLE on Android vs iOS: Two Different Worlds

Core Bluetooth and Android BluetoothGatt expose different lifecycle and operation models. Neither platform removes the need for interruption testing, background-state handling, or a real device matrix.

The biggest differences that affect biosignal apps:

• iOS and Android have different background execution rules. A declared mode or foreground service is necessary in some flows, but it is not a survival guarantee.
• Android exposes connection-priority and PHY preferences; the accepted link still needs to be measured.
• On Android, serialize GATT operations and correlate each callback with the active request.
• Generic failures such as Android status 133 require trace evidence; they do not encode one root cause.

For an Android-specific treatment, see our BLE engineering notes.

The BLE Bandwidth Math

Before choosing a streaming architecture, calculate the complete framed data rate. Then measure sustained payload, burst recovery, loss, and energy on the exact peripheral and supported phones. A PHY rate or rule-of-thumb efficiency is not a product capacity.

For an 8-channel EEG at 250 Hz with 24-bit samples, the raw payload is:

• 8 channels × 250 Hz × 3 bytes = 6,000 bytes/second = 48 kbps
• Add the actual protocol's timestamps, sequence numbers, checksums, framing, and auxiliary channels.
• Prove that the weakest supported configuration sustains this rate with the required headroom.

The fixes that matter:

• Use the negotiated ATT payload, not the requested MTU.
• Request high connection priority during the stream and treat the result as a platform preference.
• Compare LE 1M and LE 2M on the complete link, including body-worn range.
• Pack enough samples per notification to reduce overhead without creating unacceptable latency or loss exposure.

At higher channel counts and rates, BLE may or may not provide enough margin. Compare it with Wi-Fi or wired transport using the complete framed rate, required range, energy budget, supported hosts, reconnect behavior, and measured worst-case throughput before fixing the product architecture.

Multi-Sensor Synchronization

Many neurotechnology platforms record multiple modalities simultaneously: EEG plus EMG, EDA, HR/HRV, GPS, and sometimes video. Nucleus-Kit, represented in the DEVSFLOW portfolio, combines all of these. Synchronizing them accurately is one of the hardest problems in this space.

The naive approach is to timestamp every sample with the phone's system clock as it arrives. This fails for two reasons. First, BLE notification delivery is bursty. Samples can arrive in batches of 5 to 10 with the same wall-clock time. Second, different sensors connect over different channels (some BLE, some via the phone's internal sensors), each with its own latency.

The patterns that work:

• Each sensor should expose a sample counter or device timestamp with documented units, width, wrap, and reset behavior. The phone retains arrival time as transport evidence but reconstructs sample timing from the device clock.
• Estimate clock offset with repeated timestamp exchanges or a shared event, account for round-trip uncertainty, and update the mapping during the session when drift matters. A one-way wall-clock assignment is not a synchronization handshake.
• When the protocol requires sub-millisecond alignment, use a shared hardware trigger or clock and validate the result at the signal path. BLE arrival times alone cannot establish that accuracy.
• Record clock-fit residuals and uncertainty for each session. Use a shared hardware event at defined validation intervals when the product requires empirical cross-stream accuracy.

For a deeper technical breakdown, see our piece on multi-sensor BLE synchronization.

Background BLE on iOS

If your use case requires recording data while the phone is in the user's pocket and the screen is off, iOS makes this difficult on purpose. Apple does not want apps to drain battery silently. The protections they have built make sense for most apps but create real engineering challenges for biosignal recording.

The key behaviors to plan for:

• Declare bluetooth-central in UIBackgroundModes when the product needs the central role in the background, and justify the behavior in the product workflow.
• Use Core Bluetooth state restoration when long-lived connection or scan requests require it. Restoration is conditional; user force-quit and other states can prevent relaunch.
• Keep background callbacks bounded. The system controls suspension and termination, so persist enough session state to explain interruption and recover only where the protocol permits.
• Background discovery is slower and scan results can be coalesced. Measure reconnection on the supported iOS versions and devices instead of promising a fixed latency.
• Test screen-off, background, suspension, system termination, Bluetooth changes, peripheral range loss, and user force-quit as distinct lifecycle states.

Data integrity and explicit loss

Do not promise zero loss from a best-effort radio path. Promise observable integrity: the recording can distinguish complete data, recovered data, known gaps, and corruption.

The architecture that delivers this:

• Include a sequence number or equivalent continuity field in the protocol. The phone tracks expected progression and records detectable gaps.
• If the peripheral protocol includes a bounded replay buffer, the phone may request missing ranges. Buffer duration and overwrite behavior must be explicit.
• If the gap cannot be filled, it is logged with start time, end time, and reason. Downstream analysis can mark this segment as invalid rather than silently using bad data.
• Append-only chunks, length framing, and checksums can bound corruption and support recovery after a crash. Test truncation at every write boundary rather than assuming the whole session remains valid.
• At session end, the file is sealed with a session summary including duration, sample counts per channel, and gap log.

For specific implementation patterns, see our breakdown of EEG data streaming over BLE.

Battery and Thermal Management

Continuous radio, storage, processing, and rendering consume energy on both the wearable and phone. Measure each subsystem on the target hardware before choosing an optimization.

On the phone side:

• Avoid keeping the screen on solely to sustain a session. On Android, use a correctly declared foreground service when the work qualifies; iOS uses its own Core Bluetooth lifecycle rules.
• Pause non-essential UI updates. If the user is not looking at the screen, do not run live waveform rendering.
• Batch disk writes within a bound derived from memory pressure, storage cost, and the maximum acceptable data exposure if the process terminates.
• Defer processing that is not required during the session; schedule heavier post-processing according to latency, power, and charging requirements.

On the wearable side, this is mostly firmware territory, but the app should help:

• Measure connection parameters that meet throughput and latency requirements across the target phones; neither the request nor nominal interval proves energy use.
• Subscribe only to characteristics required by the active workflow and let firmware expose an explicit acquisition mode where sensor or radio features can be disabled safely.
• Surface battery level to the user in the app, with low-battery warnings before recording starts.

Product-specific regulatory analysis

Regulatory status depends on each software function's intended use, claims, and jurisdiction. Start with the FDA's device software functions guidance and Health Canada's SaMD definition and classification guidance, then obtain qualified regulatory advice for the actual product.

This is not a regulatory tutorial, but the engineering implications matter from day one:

• Define intended use, software functions, hazards, requirements, architecture, and verification evidence under the product's quality process.
• Inventory third-party software, its role, version, known vulnerabilities, and maintenance plan.
• Verification testing must cover the requirements you specified. Vague requirements lead to expensive test cycles. Be precise.
• Cybersecurity controls are now scrutinized. Authentication, encryption, and update mechanisms need to be designed in, not bolted on.
• Regulatory status is function-specific and depends on intended use, claims, risk, and jurisdiction. Get qualified regulatory advice early.

Engineering lessons from RE-AK and CLEIO

The neurotechnology work represented by DEVSFLOW reinforces a few patterns that generalize across this space:

• Estimate from the protocol, lifecycle states, data path, supported devices, verification burden, and release scope. "Receive BLE data and show it" is not a useful work breakdown.
• Treat the protocol as a versioned interface. Integration may reveal differences between documented and observed firmware behavior; capture them as tests and negotiate changes deliberately.
• Test on the actual phones your customers will use. A research-grade headset that works perfectly on a Pixel 9 may be unusable on a 4-year-old Android device that a clinical site already owns.
• Protect data integrity before adding polish. A clean interface cannot compensate for silent sample loss, ambiguous session state, or files that cannot be audited.
• Make ownership across firmware and mobile explicit. Shared traces, fixtures, protocol tests, and error semantics reduce ambiguity at team boundaries.

Frequently Asked Questions

How long does it take to build a mobile companion app for an EEG device?

There is no credible duration without a defined protocol, firmware readiness, platforms, lifecycle requirements, data-validation plan, device matrix, cloud scope, and regulatory evidence. A short technical audit should produce the state model and risk register before anyone commits to a schedule.

Should we build native or cross-platform?

Choose native or cross-platform from ownership and testability. A shared UI can be reasonable if the team keeps a well-defined native BLE and background layer. Fully native may be simpler when the product depends heavily on platform lifecycle, diagnostics, DSP, or new Bluetooth APIs. Prototype the hardest path before standardizing.

Can we use Web Bluetooth instead of a native app?

Web Bluetooth support and background behavior vary by browser and platform. Evaluate it against the required devices, session duration, reconnection, file handling, security model, and offline behavior. It can suit a controlled desktop workflow or prototype, but it should not be assumed to replace a native companion app.

How do we handle firmware updates from the app?

BLE firmware updates (sometimes called Device Firmware Update or DFU) are a separate protocol on top of the standard GATT connection. Nordic devices use the Nordic DFU protocol. Other vendors have their own. Implement DFU as a separate module from the data streaming code. Most teams underestimate the testing burden: you need to handle interrupted updates, downgrade scenarios, and recovery from corrupted firmware.

How do we validate that our recorded data is scientifically usable?

Define validation with the scientific and quality owners. Depending on intended use, evidence may include calibrated signal injection, a hardware simulator, synchronized comparison with a reference acquisition path, file-format verification, and protocol-specific signal metrics. Preserve raw data, configuration, firmware, timing uncertainty, and analysis code so the result is reproducible.