iOS timed background processing

Question

I'd like my app to be able to - say, every 12 hours - even if the app isn't curently running or is in the background, send an HTTP request to a server, get a small file with a version number and if the version on the server is higher than the version on the client, then download some more files to disk so that next time the app starts it will find new content on disk.

What design patterns are best suited for such task in ios?

A few come to my mind but I'm not as experienced.

1. Perhaps push notifications, the server needs to push a message to all clients when there's a new version available.
2. Or, Is there something similar to Android's Service that can help?
3. Or, maybe every time the app starts (or goes to the foreground) just ping the server and see if there's anything new.
4. Or, every time the app starts ping the server plus add a timer for the next 12h in case this app will still be in the foreground.
5. Or, every time the app starts, check a preference value and if the last time the server was pinged was more than 12h ago, then ping it now. And then save this ping time.

Option 1 may be more heavy on the server and could be more complicated to implement (consider an ios newbe) but may be the only option for real background update. But even so, I still don't want the user to have to react to some low-level data update b/w a client and a server (and that's what it is), so unless push notifications can go directly to the app and execute something without the user's intervention then this option doesn't fly.
Options 3-5 are all possible and don't sound too hard but they would only work while the app is in the foreground.

From what I know, background apps can only either play music, get location updates or voip updates. There's even this hack with the silent sound that was trying to escape this limitation. (and was not approved to the store).

Perhaps the limitations in place are of good cause, so how do I play by the rules and be able to achieve a periodic server ping (or more generally, solve the problem of periodic sync b/w clients and servers even when apps are in bg)?

Thanks

Answer 1

I don't have a definite answer for your question, just a rambling set of comments that may help you decide what will work best for your situation. Sorry, this is the best I can offer.

One thing to keep in mind is that an app shouldn't use any of the phone's data-plan quota without letting the user know it's downloading something. Some apps are all about downloading stuff such as Twitter clients, so the nature of the app tells the user the app is using the data plan. Other apps, like a drawing program, have little explicit need for downloading, so should notify the user of a need for a download.

Because Apple doesn't allow developers the option of downloading in the background, people using iOS are trained to wait for their apps to download updated data. The typical way to improve the user experience while waiting for a download is to at a minimum show a spinner, letting the user know the app is working. To improve the interface even more, send the download to another thread, and allow the people to continue to use the rest of the app. They can interact with the old data, or use the parts of the app that are not in need of an update.

Apple doesn't give programmers a mechanism to download new content in the background for most app types. According to Apple's announcements, iOS 5's Newsstand feature will allow subscriptions to be updated in the background. Maybe in the future we developers will have more options for background downloading.

I have one app on the app store that uses method 5, and another in the works that uses method 3.

I'd use push notifications (method 1) if the people would want to know as soon as possible that new data is available. It would depend upon the topic.

iOS doesn't have anything like Android's service (method 2)

I have an app that checks an RSS feed for news each time the app is launched (method 3). This app mostly does other things, but shows the feed on the starting view. Since the app is a simple utility that helps people find a specific solution, the RSS feed is ancillary.

I like the timer idea in method 4. If you want to give the person a chance to approve the download, the timer could pop up an alert view, and then wait. That way the app doesn't actually download something if the device was just left sitting with your app in the foreground.

My implementation of method 5 in my currently available app has a little variation. It downloads the data for just one of many views. Each time this view is visited it checks against the stored time to see if it should download fresh data. Then it asks for permission.