We expect most developers will implement Local Push Connectivity in addition to using APNs within their apps when users are not on a private network. A good pattern to follow within your app is to think of the NEAppPushProvider as your private network replacement for APNs and to limit the functionality that you implement within the extension to delivering local notifications and CallKit calls to your users.
Your backend server can determine when a user’s device is connected using the connection managed by your NEAppPushProvider. If your server determines that the connection is connected, then your server can send the “notification” on the connection managed by NEAppPushProvider. Your NEAppPushProvider implementation can respond to your server with an acknowledgement, letting the server know that it received the “notification” successfully to ensure that the user did not drop off of the private network as the notification was being sent. If your server does not have an active connection from the user’s NEAppPushProvider or the client does not acknowledge the “notification” within an acceptable amount of time the server can fall back to APNs to send the notification.
The SimplePushServer has the concept of a message router implemented in Router.swift. The sample project does not include an APNs fallback, however, you can review Router.swift to see how messages are routed and determine whether a client is still connected. If we had implemented an APNs fallback this class could redirect messages over APNs if a client had disconnected from the private network.
