We have written a Xamarin Forms application and have iOS as well as Android distributions. A request has been made to enhance the app by adding Push Notifications (Apple APNS and Firebase for Android). When a notification arrives the End User can tap it an launch our mobile app. The notifications created will be triggered based on the devices geo location. So, at a battery-friendly interval, a process determine the devices current geo location data and send that to our middle-tier of which will be used to calculate whether to send a push notification request to Azure. I have the push notifications working just fine and the CoreLocation geo data is a breeze to collect.
Here's the kicker: This enhancement requires the app to be running in the foreground, or running in the background, or not running at all. Given this, I am thinking we need to create a headless app that side-loads with the main app on installation and it (as much as possible) is always running in the background kicking off those battery-friendly geo location fetches and making middle tier calls.
I have attempted to persuade the folks making this request to handle all of this within the running app ... and not create long running background services or other apps to handle the telemetry pieces (geo location data). They are dead-set on constantly collecting geo location data and using that to kick off push notifications.
So, I have a few questions:
1) With all of the strict Apple rules on long running processes and the like, how feasible is this?
2) Are mobile headless apps even a thing? My gut tells me this is bad idea and Apple would never go for something like this.
3) How would two apps be packaged for delivery/installation, or would this be a two-step process?
Thanks for taking time to read this )