Table of Content
- IOS Local and Remote Push Notification Services
- IOS Local Push Connectivity Solution
- MQTT Protocol for iOS Push Notifications
- IOS Local Push Connectivity Components
Many businesses operate in environments where receiving messages from the application server is critical for its functionality. They must continue to work without internet connectivity as well as in circumstances such as internet congestion, system failures, catastrophes, or other cases requiring a high degree of fault tolerance. Some examples of industries that must have this technology in place are hospitals, mining operations, transportation, drones, oil, and gas, to name just a few. IOS apps rely on Apple’s push notification service—which is only available where there is an internet connection—to deliver messages to devices. This limitation represents a problem that requires the development of custom notification services for critical iOS apps.
Build a special iOS mobile app—or enhance an existing one—by implementing local push connectivity and notification services to ensure continuous use, even without an internet connection.
IOS Local and Remote Push Notification Services
Communication between devices and apps is achieved through notification services. Notifications are messages delivered in the app to alert the user of new data. These notifications are scheduled and handled by local and remote services; they may appear similar to consumers and may show up as alerts, banners, badges, or sounds. It’s worth differentiating between local and remote notifications.
- Local push notifications are generated from the app (locally) that configures and creates the notification content and specifications that trigger their delivery.
- Remote push notifications are generated from a server (remotely) and deliver messages to the app from the backend (servers) via Apple’s Push Notification Service (APNs) using PushKit or UserNotifications framework as the preferred method when an internet connection is present.
IOS Local Push Connectivity Solution
Specific use cases require mobile apps that can support operations in a local network with restricted internet access and eliminate the need for the APN’s cloud messaging system. This problem can be solved by developing an app extension (mini-app) that communicates via WI-FI directly with your local server to run a push notification service for specific functionality.
The app extension is a mini-app attached to your app that runs while devices are connected to the network, maintains an active connection with the local server for receiving notifications, and wakes up the app to answer the call or message. The extension allows users to send messages from the local server (app server) to the device (app client). You must set up your own notification protocol between the local server (provider server) and the app extension. A solution for creating your local notification service is to define a standardized protocol such as MQ Telemetry Transport MQTT or Extensible Messaging and Presence Protocol (XMPP) and implement it in the app extension.
This standardized methodology allows bi-directional communication with devices (phones), running the MQTT or XMPP services in the extension and sending direct messages from the server to these devices. This capability allows you to pass text messages and Voice-over-IP (VoIP) calls such as notifications displayed in the user phone without a remote push. This capability is self-contained and can work inside your facilities, giving you a faster and more reliable service under all circumstances and without the need to use APNs.
MQTT Protocol for iOS Push Notifications
MQTT is commonly used for IoT device messaging, and data exchange is event-driven and connects following a publish/subscribe pattern. The MQTT server (broker) handles incoming messages from the sender (publisher) and distributes them to receivers (subscribers). The MQTT protocol is a lightweight messaging transport protocol easy to implement for push-based communication via TCP/IP connections and can be used via WebSockets. It is suited for situations with low bandwidth and constraint environments.
The MQTT client can send or receive messages with connections handled by a broker, communicating over TCP/IP, running an MQTT library, and connecting to a broker over a wireless network. MQTT client libraries are available for Objective C and Swift programming languages. The broker acts as a central hub that filters, receives, and sends messages to clients—a hub that can handle millions of concurrently connected devices and is responsible for authentication and authorization of devices (clients).
Messages are encrypted using Transport Layer Security (TLS) and authenticated using OAuth. The messaging protocol is responsible for defining the rules, forms, and functions to send messages between devices or machines. Apple does not allow users to implement polling mechanisms or generic capabilities to randomly pull in the background, which is why we develop a solution by creating your own messaging protocol. On the other hand, Android gives users more control over the operating system, so it’s possible to design a different solution for Android apps.
IOS Local Push Connectivity Components
Selecting the correct API for your iOS app development is essential and requires configuration and understanding of the methods used to create the appropriate instances.
For specific cases, devices operating on local restricted networks can use Apple’s Local Push Connectivity API, configuring the local push connectivity extension to create instances where the extension runs and defining how incoming calls interact with the framework. Connectivity apps use NEAppPushManager instances when client apps start and configure WI-FI networks, push providers, and then set their delegates after the app launches to handle incoming calls. App extensions implement a subclass of the NEAppPushProvider to define methods called by the system and network connections.
App push providers (local push providers) run as extensions and provide functionality in environments without connectivity, similar to Apple’s Push Notification Service (APNs). This type of app uses Local Push Connectivity and maintains connections with a messaging server to route messages and calls with TCP connections and network functionality through the class object NEAppPushProvider. Configure a NEAppPushProvider to provide a persistent connection to your local push server, and extend the NEAppPushProvider to receive notifications.
Create an app extension that launches automatically when the device joins the network and disconnects from the server when a device sends a disconnect command and leaves the network. An app using local push connectivity requires customization of networking features. This can be accomplished by enabling the app push provider entitlement and network extension capabilities (network extensions entitlement API).
APIs are available for networking features to proxy DNS queries as well as TCP and UDP connections, filter APIs to allow or deny connections, tunnel IP packets, system-wide DNS configuration, share web credentials, custom VPN configuration, etc.
