Our team decided to implement non stop API endpoint pinging in background and after receiving required response, app should display a notification with message from response. I suggested using notifications via third party service, like Firebase or OneSignal, but currently we would like to rather use non stop API endpoint pinging.
I have looked at background work on IOS and found lots of limitation, like duration or type of requests, compared in Android. It is 100 percent possible in Android on any versions (with some adjustments).
This is why I would like to know if this is completely possible on IOS and our background process with possibly 2 hours duration would not be killed at any conditions? Except of course the restart of IOS system, which would not resume background work, I assume.
Also, would welcome any recommendations :) Stay strong!
What you propose is not possible on iOS. Since the beginning, apps have not been able to run in the background with a socket open.
The justification is that doing so keeps the radio interfaces on the device powered on and consumes a significant amount of power. If you can implement this on Android it has precisely the same issues.
It's not clear from the question what problem you are trying to solve: only your chosen means of implementation.
The options available are:
Background App Refresh is intended for apps which need to periodically background-refresh content.
Your app gets woken up for a short period of time (ISTR 15s) at a time when there is sufficient battery life and connectivity to preform whatever action it needs to take.
There are no guarantees that you will get woken up or when. In practice, the most you can expect is every 15m, but there are frequently long gaps, possibly driven by Do-not-disturb and user-behaviour.
URLSession can be handed off to iOS to occur in the background - intended specifically for downloading large content item.
APNS can be used to wake-up your app (or more likely, AppExtension). You would need to send a notification periodically.
Again, there are no guarantees about delivery (intermittent connectivity). Realistically, iOS needs to periodically wake up and power up the radio interface in order to receive them - how and when this happens is a block-box.
Middleware such as Firebase may use a combination of the technologies above and Websockets to achieve synchronisation.