iOS-Research-Notes.md

+[[_TOC_]]
+
 This report describes the research carried out by the OuiSync and Briar teams to explore the opportunities for peer-to-peer and device-to-device communication on iOS, including communication between iOS and other platforms.
 
 Most of the information is based on Apple's developer documentation, with some input from experienced iOS developers.
@@ -5,11 +7,11 @@ Most of the information is based on Apple's developer documentation, with some i
 On Android we've found that there are often differences between what's possible according to the documentation and what's possible on real devices.
 Apple is a single vendor controlling both hardware and software, so the gap between documentation and reality may be smaller on iOS than on Android, but we don't have enough experience with iOS to confirm this.
 
-## Push Notifications
+# Push Notifications
 
 Communication apps on iOS typically use *push notifications* to wake the app and notify the user when new content is available.
 
-### Architecture
+## Architecture
 
 The iOS push notification architecture includes two centralised components: the Apple Push Notification service (APNs), which is operated by Apple, and the *provider server*, which is operated by the app publisher.
 
@@ -28,7 +30,7 @@ The provider server can authenticate itself to APNs using either a certificate i
 
 https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/establishing_a_token-based_connection_to_apns
 
-### Centralisation
+## Centralisation
 
 The requirement for the provider server to authenticate itself to APNs using credentials issued by Apple means that the provider server must be a logically centralised entity controlled by the app publisher.
 APNs itself is of course a logically centralised entity controlled by Apple.
@@ -38,7 +40,7 @@ See, for example, the notification architecture used by Matrix, in which federat
 
 https://spec.matrix.org/v1.1/push-gateway-api/
 
-### Metadata Exposure
+## Metadata Exposure
 
 If push notifications are used in the typical way to wake the app when a new message is available, then the app publisher (via the provider server) and Apple (via APNs) are both in a position to see which devices are receiving messages at which times, which is a form of metadata exposure.
 
@@ -46,7 +48,7 @@ If the sender authenticates themselves to the provider server (or to another ser
 
 The push notification architecture does not require the sender's identity to be exposed to APNs.
 
-### Mitigations
+## Mitigations
 
 In a federated communication system, it may be possible to mitigate the centralisation of the push notification architecture by allowing the servers of the federated communication system to act as provider servers.
 
@@ -68,7 +70,7 @@ The token server would not handle device tokens, and would not see any metadata
 This approach might not scale to a large and fast-changing population of federated servers, where it would be difficult for the app publisher to prevent a misbehaving server from rejoining the network under a new identity in order to obtain a new authentication token.
 Apple might refuse to publish an app that distributed APNs authentication tokens to servers controlled by third parties.
 
-### Background Notifications
+## Background Notifications
 
 Push notifications are often used to wake the app and notify the user, but it's also possible to send a *background notification* that wakes the app without notifying the user.
 
@@ -86,11 +88,11 @@ Thus background notifications wouldn't be suitable for coordinating the peers in
 When a device receives a background notification, iOS gives the app 30 seconds to do any necessary work in response to the notification.
 Depending on network conditions, this might not be enough time to connect to a federated server or peers in a P2P network, especially if the connections were being made via Tor.
 
-## Background Execution
+# Background Execution
 
 iOS is much stricter than Android about how much work apps are allowed to do while they're running in the background.
 
-### Execution States
+## Execution States
 
 An iOS app can be in one of five execution states:
 
@@ -110,7 +112,7 @@ The amount of time that will be granted isn't documented, but it can be queried
 
 https://developer.apple.com/documentation/uikit/app_and_environment/scenes/preparing_your_ui_to_run_in_the_background/extending_your_app_s_background_execution_time/
 
-### Background Modes
+## Background Modes
 
 iOS defines specific categories of work that apps are allowed to do in the background.
 These are known as *background modes*.
@@ -123,7 +125,7 @@ https://developer.apple.com/documentation/backgroundtasks/choosing_background_st
 The background modes most likely to be relevant for peer-to-peer or device-to-device communication are `bluetooth-central`, `bluetooth-peripheral`, `fetch` and `processing`. Each of these modes is discussed below.
 The `voip` mode is relevant for apps that can receive voice or video calls.
 
-#### Background Modes for Bluetooth
+### Background Modes for Bluetooth
 
 Although the prospects for peer-to-peer communication on iOS aren't encouraging, the prospects for device-to-device communication via Bluetooth Low Energy (BLE) are relatively good.
 
@@ -148,7 +150,7 @@ This means that in most cases, devices can't discover each other if the app is r
 
 http://www.davidgyoungtech.com/2020/05/07/hacking-the-overflow-area
 
-#### Background App Refresh Tasks
+### Background App Refresh Tasks
 
 The `fetch` background mode allows an app to run in the background occasionally to refresh its content.
 
@@ -161,7 +163,7 @@ https://developer.apple.com/forums/thread/685525
 
 https://developer.apple.com/videos/play/wwdc2020/10063/
 
-#### Background Processing Tasks
+### Background Processing Tasks
 
 The `processing` background mode allows an app to run resource-intensive tasks in the background while the device is charging and not being used.
 
@@ -169,7 +171,7 @@ https://developer.apple.com/documentation/backgroundtasks
 
 If this mode allows network access then it could potentially be useful for letting devices in a P2P network take on more resource-intensive "superpeer" roles while they're idle and connected to power and Wi-Fi.
 
-## Bonjour
+# Bonjour
 
 iOS provides an API for Bonjour, Apple's implementation of Multicast DNS (mDNS) and DNS Service Discovery (DNS-SD), which can be used to advertise and discover services on a local area network.
 
@@ -187,7 +189,7 @@ Apps are expected to unregister all Bonjour services when they're suspended, as
 Considering the limited opportunities for background execution described above, it's unlikely to be possible to discover a Bonjour service running on iOS unless the app providing the service is running in the foreground.
 However, opportunistically discovering services running on other platforms during the iOS app's brief periods of background execution may be possible.
 
-## Multicast
+# Multicast
 
 As well as Bonjour, which uses IP multicast for advertising and discovering services, iOS allows low-level access to IP multicast so that apps can implement their own multicast-based protocols.