FDA recalls defective iOS app that injured over 200 insulin pump users

App store policies & platform responsibility

• Some argue Apple has no real restrictions specific to medical apps and defers to FDA regulation; others point to Apple’s “physical harm / medical apps” guidelines as at least a formal category.
• Several comments say Apple lags Android in approving or enabling diabetes-device apps (e.g., bolus delivery, Omnipod iOS app), though long review times are described as common across categories.
• Debate over whether Apple should reject buggy medical apps or help fix them:
  • One side says that’s what the “app store tax” should fund and that Apple wants to market health as a platform feature.
  • Others argue Apple shouldn’t become a “shadow FDA” and should focus on privacy/security, leaving safety/efficacy to regulators.

Software quality of diabetes device apps

• Multiple users describe CGM and pump apps (Dexcom, Libre, Tandem, Omnipod, Roche DBLG1) as unreliable, slow, notification-buggy, and generally “trash,” especially compared with small indie apps.
• Specific issues: alert stacking and delays, watch readings lagging or missing, Bluetooth instability, battery-drain bugs, poor Do Not Disturb integration, crash-induced reconnection loops.
• Some suspect cross‑platform frameworks and cost-cutting (outsourcing, minimal QA) as contributors.

Regulation, FDA, and 510(k)

• Several commenters note the recalled app and devices are FDA‑regulated; some expected this to catch such failures and are disappointed.
• Discussion of 510(k) “substantial equivalence”:
  • Critics call it a form of regulatory capture and a shortcut around full re‑testing.
  • Defenders respond that clinical trials may be skipped, but extensive testing, validation, and IEC 60601 compliance are still required; no liability shield, and “product drift” is intentional.
• One contributor visualized the predicate “ancestry” graph for this device and found ~40 upstream devices, raising questions about tracking lineage-wide risk, which others say is not how devices are actually regulated.

Smartphones as safety‑critical controllers

• Some see using general-purpose phones to control insulin pumps as inherently unsafe complexity; others, especially users, emphasize huge quality‑of‑life benefits and limited direct control (mainly bolus).
• Suggestions include dedicated “sacrificial” intermediary devices and clearer reliability requirements for “alternative control enabled” pumps.

Developer incentives & organizational issues

• Comments link poor quality to low pay for embedded/medical developers, heavy bureaucracy, and big‑company culture.
• Debate over whether “enthusiastic” fast‑iterating devs or methodical “paperwork”‑oriented engineers are better suited for safety‑critical software.
• Formal verification is mentioned; consensus is that it appears little used here.