0

I have been investigating iOS background fetch for our enterprise applications. According to articles like this, there are limitations like having 30 seconds to download before the app is terminated and the may be (unconfirmed) a penalty where after 3 timeouts, an app gets banned from background sync. Also if the user kills the app, fetches stop happening -noted here.

The goal is to be able to retrieve data from our servers periodically when app is suspended/not running but sometimes the transfers can take minutes due to long running SQL. I don't want to implement sending periodic notifications to all users.

Before I go down the path of developing for the iOS background sync, I needed to do some due diligence and research alternatives to iOS's background sync and didn't find anything.

Has anyone seen or developed an alternative to iOS's background sync or dealt with this issue for their enterprise apps?

Community
  • 1
  • 1
Barrett
  • 460
  • 3
  • 11
  • 2
    Maybe cache the updates so the update does not block because of slow SQL? Maybe break it into smaller parts? The fact that the call "takes minutes" is not a good thing. – picciano Mar 02 '17 at 22:30
  • Can you elaborate: "retrieve data from our servers periodically when app is suspended"! – nikdange_me Mar 02 '17 at 22:36
  • @nikdange_me, After the user presses home and the app goes to the background or gets suspended, I need to make a call to my API, say, every 30 minutes or so, to keep the user's local data up-to-date while the app is not in use (can be for days or months). All for a better user experience. – Barrett Mar 03 '17 at 00:35
  • @picciano Agreed. The key is having the data ready at the time of the API call. As a kind of caching, it will likely be more in the form of a preprocessed result table for each user as the data changes often. It may be a combination of this, breaking up the work, and background sync. – Barrett Mar 03 '17 at 15:44

2 Answers2

0

The goal is to be able to retrieve data from our servers periodically when app is suspended/not running

  • The only reliable way to achieve such a behaviour is implementing a User-facing Remote (Push) Notifications framework on backend & apps.
    You can append 4kB (or 5 for VOIP) worth of data in the push JSON payload, eliminating need for a network fetch request if implemented in a handshake mechanism.
  • You can evaluate usage on Silent Remote Notifications to augment content updation & fetch small amounts of content opportunistically, though it has the same as Background App Refresh.
  • You can definitely improve the API that can take minutes due to long running SQL
  • And remember you need to have the app updated only when the user actually fires it up. Evaluate implementing a catchy & smooth fetching content screen that transitions into the actual screens once all data is fetched.
ystack
  • 1,736
  • 11
  • 22
0

As an enterprise app there's nothing extra you can do except that you can use whatever background modes you want (audio, location, voip etc,) without needing to have a legitimate reason to do so.

Where this might assist is:

  • you could make use of a significant location change (as opposed to a regular location change) notification to run your app in the background. The problem with this is it of course depends on the user of your app to move around. However, assuming everybody in your workforce commutes to/from work with their iPhone then you would have two opportunities each day for the app to run in the background. A app run due to a location change can be made to execute in the background for more than 30 seconds.

  • voip pushes: Unlike a regular push notification, a voip push will launch the app even if the user has force terminated it. To make use of this functionality is only a tiny bit more effort than using regular push, you don't have to do anything regarding making or receiving an actual voip call, you just need the voip capability and voip certificates instead of normal push certificates.

The comment in that link is not correct regarding force quitting and background fetch - a user force quitting an app does not make it ineligible to run for a background fetch, I have force quit my own app that uses background fetch but it will still be started by the OS, however what will happen is that the frequency when the app is run will decrease lots, and if the user never runs the app again then the OS will stop launching it. A user force quitting an app will prevent other things from happening, such as it running in the background in response to a silent push notification for example (unless its a voip push).

Also the 30 seconds in not related to download times, NSURLConnection would stop after 30 seconds, NSURLSession is designed to continue to download on your app's behalf. But if you are downloading and then applying lengthy SQL processing it would be an issue. But minutes of processing time seems excessive, are you sure its all optimized?

Gruntcakes
  • 36,166
  • 41
  • 170
  • 346
  • The slow SQL was fixed but the remaining calls still come close to 30 seconds limit for background fetch (in worst case). I ended up creating a test app that relatedly hits my API with a series of requests. I did see the decreasing calls to launch my app. Guessing that the interval is affected by the load on the CPU and time taken to complete downloads. The interval got close to 12 hours. If you interact with the app, it resumes shorter intervals for a while. [See this too](http://stackoverflow.com/questions/39197933/how-to-troubleshoot-ios-background-app-fetch-not-working) – Barrett Mar 10 '17 at 21:32
  • Also, I may implement weekly or semi-weekly silent push notification if I experience the mentioned case where OS eventually stops launching the app. – Barrett Mar 10 '17 at 21:40