Medical device companion app development in 2026: FDA, BLE, cost

TL;DR

Medical device companion app development in 2026 runs on two budgets that behave differently. The app is priced by vendors, from about $15,000 for a single-platform Bluetooth Low Energy MVP to about $180,000 for a connected-device build before any regulatory work. The regulatory layer is priced by FDA and published to the dollar.

• From October 1, 2026, a 510(k) costs $28,653, or $7,163 at the small business rate.
• What sets your burden is the app's intended use, not the clearance your hardware already holds.
• The QMSR took effect on February 2, 2026 and makes ISO 13485:2016 the quality baseline.
• FDA reissued its cybersecurity guidance on February 3, 2026. An SBOM is statutory for cyber devices.
• Around 20% of our published case studies run over a Bluetooth link, and the hard part sat on the phone.

What a medical device companion app costs in 2026

Two vendors publish real numbers for this work, and they sit a factor of twelve apart.

AppMatic Tech prices a BLE companion MVP from $15,000 for one platform in 4 to 6 weeks, a dual-platform app with read and write commands at $30,000 to $60,000 over 8 to 12 weeks, and a connected-device platform with backend and telemetry at $60,000 to $100,000 over 12 to 20 weeks. Across six shipped BLE integrations its delivery times ran from one month to eight, set by firmware readiness rather than app complexity.

Topflight Apps opens at about $180,000 over 8 to 14 months for a connected-device app before any regulatory work, then stacks a HIPAA overlay of $5,000 to $25,000 at pilot stage and $40,000 to $100,000 for compliance an enterprise buyer accepts.

Both can be true. The first describes a Bluetooth app built against a documented protocol. The second describes a regulated product carrying design documentation, verification evidence and a submission. The distance between them is not screens. It is whether the GATT profile is frozen and written down, and what FDA decides your app is for.

One number here is exact and beyond negotiation: the fee FDA charges you.

FDA user fees go up on October 1, 2026

FDA published the FY 2027 medical device user fee rates on July 30, 2026, and they apply from October 1, 2026 through September 30, 2027. A 510(k) goes to $28,653, or $7,163 for a qualified small business. A De Novo classification request goes to $191,020, or $47,755. A 513(g), which buys FDA's written answer on how your software is classified, costs $8,596, or $4,298. Annual establishment registration is $13,785, with no small business rate on it.

Three mechanics decide what you pay. Small business status covers firms with $100 million or less in gross receipts and cuts most submission fees to a quarter, but the request has to reach FDA at least 60 days before the fee is due, and FY 2026 status expires on September 30, 2026. A 510(k) routed through an FDA-accredited third-party reviewer carries no FDA user fee. And read the submission counts in the notice before anyone tells you your app needs a De Novo: FDA averaged about 3,960 fee-paying 510(k)s a year across FY 2023 to FY 2025, against about 77 De Novo requests.

How we built this guide

Four rules, applied to every statement below.

• Regulatory facts come from FDA, the Federal Register and CMS, not from vendor summaries of them.
• Platform behaviour comes from Apple and Android developer documentation, because that is where the rules that break background sync are written.
• Published prices are quoted from the vendor guides ranking for this query and labelled as vendor estimates.
• Our own figures are counted from our published case studies, shares rounded, no client named who is not already named on our site. Any group with fewer than three data points is not published.

One disclosure. Mercury Development sells healthcare and connected-device software development, so the section on our own record is a supplier's record, not a market survey.

Medical device companion app development at a glance

Your app carries its own FDA classification

Your hardware clearance does not cover the phone. FDA regulates software by function and intended use, and its oversight focuses on software that connects to a device to control it or analyze its data, or that turns a phone into a device through sensors or attachments. Lower-risk functions sit under enforcement discretion, and functions that only transfer, store or display device data stopped meeting the device definition after section 3060 of the 21st Century Cures Act, unless they interpret what they carry.

An app is therefore not an accessory because it reads from your device. It becomes one when what it does with the reading changes what the device is for. A trend line, an alarm threshold, a dosing suggestion, a parameter written back to the hardware: each moves the boundary, and each is a week-three product decision that returns as a month-nine regulatory answer.

Two pieces of vocabulary changed recently, and reviewers notice the old ones. Since the June 2023 software guidance, a submission carries a Documentation Level, Basic or Enhanced, and the three old levels of concern are gone. On January 6, 2026, FDA reissued its Clinical Decision Support Software guidance alongside the general wellness policy, which matters for any patient-facing screen that recommends rather than displays.

Want it settled in writing rather than in an opinion? That is what a 513(g) buys. A pre-submission meeting costs nothing in user fees.

What the QMSR and the February 2026 cybersecurity guidance changed

Two dates, one working day apart, reset what a submission has to contain.

On February 2, 2026, the Quality Management System Regulation took effect. Part 820 now incorporates ISO 13485:2016 by reference, FDA retired the Quality System Inspection Technique, and inspections run under compliance program 7382.850. Conformity to ISO 13485 stopped being a commercial nicety you show device partners. It is the rule your development process is measured against.

On February 3, 2026, FDA reissued Cybersecurity in Medical Devices, superseding the June 27, 2025 edition and retitling it to match the QMSR. The substance is statutory. Section 524B, added to the FD&C Act by the December 2022 omnibus and effective March 29, 2023, requires a premarket submission for a cyber device to carry a postmarket vulnerability monitoring and disclosure plan, processes that keep the device patched, and a software bill of materials covering commercial, open-source and off-the-shelf components. FDA has been able to refuse to accept submissions missing that information since October 1, 2023.

Now read your dependency list against that. The cross-platform framework, the BLE plugin, the crash reporter, the analytics SDK: each has a version, a maintainer and a vulnerability history, and each belongs in an SBOM you keep updating after launch.

What CMS changed for remote monitoring apps in January 2026

If your device earns through remote monitoring, a billing rule just became a software requirement. Traditional Medicare spending on remote physiologic monitoring went from $6.8 million in 2019 to $194.5 million in 2023, per the Peterson Center on Healthcare.

From January 1, 2026, the Medicare Physician Fee Schedule pays for device supply and data transmission when data is collected across 2 to 15 days in a 30-day period, where the older codes needed at least 16, and pays for 10 minutes of treatment management where the older codes needed 20.

That is not a billing team's problem. Your app now has to count qualifying transmission days per patient per 30-day window, separate a day with a real reading from a day with a failed sync, and timestamp interactive communication. A dropped BLE connection stopped being a missing data point. It is a day nobody gets paid for.

BLE is where companion apps actually break

Nothing in a companion app fails as often, or as quietly, as the link. Almost none of it is the radio's fault. It is the operating system deciding your app has had enough.

On iOS, background Bluetooth work needs the background mode plus Core Bluetooth state preservation and restoration. Apple's technote TN3115 sets out when the system actually relaunches you: after the app is removed from memory or crashes, yes; after a user force quit, no; after Bluetooth power is toggled in Settings, no. Since iOS 26 and iPadOS 26, the cases that still relaunch after user action are limited to apps using AccessorySetupKit. Restoration fires only where the app was waiting on a specific event.

On Android, scanning and connecting have been runtime permissions since Android 12, granted by the user under Nearby devices. Holding a link with the app in the background means a foreground service of type connectedDevice, the companion device presence API, or a scan registered with a PendingIntent so the system wakes your process when the peripheral appears.

The rest is old news to anyone who has shipped this. Fire two GATT writes at once and the stack drops packets, which on Android surfaces as status 133, so every operation goes through a queue that waits for acknowledgement. Negotiate MTU once per connection. Subscribe to notifications instead of polling. Treat a disconnect as an expected state with backoff, because patients walk out of range.

What BLE testing has to cover before a submission

FDA's guidance on radio frequency wireless technology in medical devices has asked the same questions since 2013: why this wireless technology, what quality of service the function needs, how the device coexists with other radios, how the link is secured, and how electromagnetic compatibility was handled. FDA recognizes ANSI C63.27 for evaluating wireless coexistence and AAMI TIR69 for managing its risk, so a declaration of conformity answers the coexistence question with evidence instead of prose.

A bench test on a clean desk answers none of it. A test plan that survives review covers the OS versions and phone models your patients own, walking out of range and back, airplane mode, a user force quit, a Bluetooth toggle in system settings, battery saver and doze, a second app holding the same device, every shipped firmware revision, and a crowded 2.4 GHz room. Then it covers what the app does with a partial write and a stale reading.

Orthogonal, the most serious competitor publishing here, sizes edge-case testing across cloud device farms, simulators and real phones, and narrows the pairing window with out-of-band pairing over NFC. Both practices are worth copying.

What teams underestimate is traceability. Every case above maps to a requirement and a hazard in the risk file, and your Documentation Level decides how much of that evidence travels with the submission.

Which build fits your device program

Three bands, split by what FDA is being asked to accept.

Under $50,000 buys one platform against a documented, frozen protocol, with intended use kept to display. Spend the first money on a protocol review that produces a written characteristic map, because a vendor quoting a fixed price without one is quoting a guess.

Between $60,000 and $150,000 buys both platforms, read and write, offline buffering, a backend, and the monitoring counters reimbursement depends on. This is accessory territory, so design history, verification evidence and software documentation get produced alongside the code rather than reconstructed afterwards.

Above $150,000 buys a submission-grade product: human factors work, coexistence testing, an SBOM with a maintenance process, penetration testing, and postmarket surveillance somebody owns after launch. If your budget sits here and your scope is a pairing screen and a chart, you are funding someone else's risk.

What our own Bluetooth engagements show

Around 20% of our published case studies run over a Bluetooth or BLE link, and around half of those began in code somebody else had already shipped. The pattern is consistent: the protocol was rarely the problem, and the platform always was.

On ORIGOSafeDriver, a fleet safety product, the work our page records is low-level Bluetooth LE debugging to stop disconnections, a replacement driver for an unstable modem, and power work after the hardware turned out to flatten a vehicle battery in three days. Data traffic came down to 8 MB per device per month.

On Fitbit, early Android had no Bluetooth 4.0 at all, and our team spent two months deciphering Samsung's proprietary technology to sync a tracker. A legacy Windows 8 app that could not sync wirelessly was later rebuilt with Bluetooth 4.0 support, worked out with the Windows team on the Microsoft campus.

On Kensington Proximo, a range of BLE fobs and tags, Android again had no built-in BLE support, so the app shipped against a pre-release Samsung SDK covering a single handset, with a power-efficient algorithm combining signal levels and location. On Tonal, the connected gym, the complexity our page names is session logic keeping machine, phone and watch agreed about one workout.

None of those is a protocol story. Each is a story about what one OS version, one SDK and one power budget do to a link that looked fine in the lab.

Where companion app schedules actually break

Opinion, stated plainly: these projects break because two documents get written in different rooms.

One is the intended use statement, owned by regulatory. The other is the GATT profile, owned by firmware. The first decides whether the app is a display, an accessory or a device in its own right. The second decides what the app is physically able to do. A control characteristic that writes therapy parameters is the regulatory boundary expressed in bytes, and if nobody notices in design, the finding arrives in verification, where it costs far more to move.

The second failure is sequencing. Teams buy the app first and postpone classification, because classification feels like paperwork and the app feels like progress. FDA publishes a price for removing that doubt in writing, and it is smaller than one sprint. Buy the answer before the architecture.

Written by Alexey Rodionov, Lead Front-end Developer at Mercury Development since 2020. Alexey is a Google Developer Expert in Web Technologies and a Chromium contributor whose code ships in Chrome DevTools, Google's Bubblewrap and Microsoft PWABuilder. The platform constraints and integration reviews behind this article's connectivity and testing sections come from the engineering practice he leads.

Have a device and no companion app yet? Start with the boundary

You know which questions decide the budget. What you probably lack is the protocol and the intended use written down side by side. Tell us what your device measures, what you want the app to say about it, and which platforms your patients use. We come back with a scope and a test plan.