Android Only · Engineering Constraints

Why Radar Cannot
Run on iOS

A technical explanation of the Apple platform restrictions that make a full-featured iOS port impossible — not a business decision, but an engineering one.

⚠️ The short answer

Radar's core capabilities — offline mesh networking, proximity-based peer discovery, background radio communication, and SMS integration — rely on a set of Android APIs that Apple has deliberately locked away from third-party developers on iOS.

This is not a matter of effort or investment. The underlying operating system APIs simply do not exist on iOS, or are so severely restricted that the feature cannot function at all. What follows is a precise breakdown of each restriction.

📶

Wi-Fi Aware (Neighbor Awareness Networking)

Peer discovery & data transfer without internet Completely absent on iOS
  • Wi-Fi Aware (NAN) is an 802.11 standard that Apple has never implemented on any iPhone or iPad. The hardware Wi-Fi chip in iOS devices is technically capable of NAN operation, but Apple exposes no API for it and there is no announced intention to add one.
  • On Android, the Wi-Fi Aware API (available since Android 8.0 / API 26) lets Radar discover nearby peers, publish and subscribe to service names, and open encrypted peer-to-peer data sockets — all completely offline, without any Wi-Fi router, hotspot, or internet. Android API 26+
  • This single capability underpins the Radar live radar view, sub-second peer discovery, high-bandwidth offline file transfers, and the proximity doorbell feature. There is no iOS substitute.
  • Apple's Multipeer Connectivity framework is sometimes cited as an alternative, but it cannot advertise or discover arbitrary service names, requires mutual user consent pop-ups for each new peer, and cannot interoperate with Android devices.
📱 Android Full Wi-Fi Aware NAN publish/subscribe/connect API. Background operation supported via foreground service. Works with any Wi-Fi Aware-capable device.
🚫 iOS No Wi-Fi Aware equivalent. No NAN API. No third-party access to NAN radio mode. Multipeer Connectivity is iOS-only and cannot discover Android peers.
📳

Bluetooth Low Energy — Background Operation

Always-on mesh relay & presence beaconing Fatally restricted on iOS
  • iOS suspends all BLE activity when the app is in the background. A Radar mesh node must continuously advertise its presence and scan for other nodes to relay messages and maintain the mesh. On Android this runs permanently via a foreground service; on iOS the app is silently paused within seconds of leaving the foreground.
  • Background BLE advertising is stripped to a single service UUID. iOS permits a backgrounded app to advertise only the primary service UUID — all manufacturer-specific data, the device name, and custom payload fields are removed. Radar embeds routing metadata, relay counters, and message fragments inside the BLE advertisement payload; this mechanism is impossible on iOS.
  • Background BLE scanning is unreliable and rate-limited. Even when Core Bluetooth background scanning is declared in the entitlements, iOS delivers scan results infrequently (often minutes apart), de-duplicates advertisements aggressively, and provides no guarantee of delivery. Radar requires continuous real-time scan results to update the peer map and accept inbound relayed messages.
  • No foreground service equivalent. Android's foreground service keeps a process running at full CPU and radio priority indefinitely with a visible notification. iOS has no equivalent; all background modes are time-limited (typically 30 seconds) and battery-managed by the OS without developer override.
📱 Android Bluetooth LE scanner and advertiser inside a foreground service: full payload control, continuous operation, manufacturer-specific data, extended advertising (BT 5), background scan callbacks with low latency.
🚫 iOS Background advertising loses all payload except primary UUID. Background scanning delivers results infrequently, minutes apart. App suspended <30 s after leaving foreground. No foreground service API.
🔗

Wi-Fi Direct (Peer-to-Peer Wi-Fi)

High-bandwidth offline file & message transfer Not exposed on iOS
  • iOS has no public Wi-Fi Direct API. The Wi-Fi Direct (IEEE 802.11p2p) standard allows two devices to form a direct Wi-Fi link at full wireless LAN speeds without a router. Apple implements Wi-Fi Direct internally for AirDrop, AirPlay, and CarPlay, but the API is entirely private and unavailable to third-party apps.
  • On Android, the Wi-Fi Direct API lets Radar form direct device-to-device Wi-Fi groups, achieve multi-megabit throughput for file and binary transfers, and build a local IP network between peers — all offline. Android API 14+
  • AirDrop is a closed Apple system and cannot be used by third-party applications to establish connections or transfer arbitrary data.
📱 Android Full group owner/client role management, service discovery, connection negotiation, and IP-level socket access. Supports multi-device groups and offline data transfer at Wi-Fi speeds.
🚫 iOS No public Wi-Fi Direct API. Multipeer Connectivity may use Wi-Fi internally but provides no IP socket access, no control over the connection, and no interoperability with Android.
💬

SMS & MMS Integration

Unified SMS inbox alongside Radar messages Completely locked on iOS
  • iOS provides no API for third-party apps to read, send, or receive SMS or MMS messages. Apple reserves all SMS/MMS access exclusively for the built-in Messages app. There is no SMS API, no content observer on an SMS store, and no broadcast receiver for incoming SMS events available to third-party apps.
  • On Android, Radar can be set as the default SMS application, giving it full read/write access to the SMS content provider, the ability to send and receive SMS and MMS natively, and the ability to surface them alongside Radar network messages in a unified inbox. Android API 19+
  • iMessage is closed and proprietary. Apple does not publish any API for third-party access to iMessage or its delivery receipts. There is no way for Radar (or any other app) to interoperate with iMessage on iOS.
⏱️

Persistent Background Execution

Continuous mesh relay, notification delivery, sync Fundamentally unavailable
  • iOS suspends apps within seconds of them leaving the foreground. Radar must run continuously in the background to maintain mesh relay, deliver incoming messages, track nearby peers, and broadcast its own presence. None of this is possible when the process is suspended.
  • Background App Refresh is the iOS mechanism for periodic background work, but it fires infrequently (at OS discretion, often 15–30 minutes apart), cannot perform network or radio operations reliably, and is disabled entirely by the user or OS in low-battery or Low Power Mode conditions.
  • iOS background modes do not cover mesh networking. The declared background modes (audio, location, fetch, voip, bluetooth-central, etc.) each carry severe restrictions and cannot be combined to reproduce the always-on radio scanning and transmitting that Radar performs on Android.
  • Android foreground services are an explicit design commitment — a persistent, battery-aware, user-visible background process that Android guarantees will not be killed. iOS has no equivalent and actively prevents this usage pattern. Android API 9+
📡

Ultra-Wideband (UWB) Ranging

Centimetre-accurate proximity ranging Locked to Apple's own framework
  • The U1/UWB chip in iPhones (iPhone 11 and later) is accessible only through Apple's Nearby Interaction framework, which requires a paired Apple device and explicit mutual session setup. There is no general-purpose ranging API that would allow Radar to perform ranging against arbitrary Android peers.
  • On Android 12+, a public UWB ranging API with IEEE 802.15.4z compliance, enabling Radar to range against any UWB-capable Android device without Apple involvement. Android API 31+
  • Apple's Nearby Interaction does not interoperate with Android's UWB stack, so even if partial access existed it would not bridge the two platforms.
📲

NFC — Background & Peer-to-Peer

Tap-to-connect contact exchange Read-only tags only on iOS
  • iOS NFC is restricted to NDEF tag reading only. There is no peer-to-peer NFC mode (NFC-P2P / SNEP), no ability to emulate an NFC card in the background (Host Card Emulation), and no ability to write NFC tags from a third-party app without launching a dedicated sheet.
  • On Android, Radar uses NFC tap-to-connect to instantly exchange contact details and initiate an encrypted pairing session. Android supports both reading and writing NDEF tags, HCE, and P2P NFC out of the box. Android API 14+
  • Apple has opened NFC progressively since iOS 13 but has not exposed peer-to-peer or background-read capabilities to third-party developers as of iOS 17.
💡 What about MultipeerConnectivity? Apple's Multipeer Connectivity framework is sometimes suggested as an iOS replacement for Android's mesh stack. In practice it cannot substitute: it is iOS-only (no Android interop), requires user-consent pop-ups for every new peer, cannot run in the background, does not expose the underlying transport (BLE or Wi-Fi), is limited to roughly 8 simultaneous peers, and provides no control over advertising payloads. Radar's mesh architecture requires all of these capabilities.
This is not a criticism of iOS as a platform — it is an engineering constraint. Apple's design philosophy prioritises battery life, privacy, and a consistent user experience by tightly controlling background radio activity and cross-app system access. Those are reasonable choices, but they are fundamentally incompatible with what Radar needs to do.

Radar will remain Android-only for the foreseeable future. The features that make it unique — offline mesh, live proximity radar, Wi-Fi Aware peer discovery, and native SMS integration — are only possible on a platform that grants applications the low-level radio access Apple deliberately withholds.

→ View the full feature comparison  ·  → Free vs Premium