Couple interesting posts lately about background fetch resource usage. If you’re not familiar with background fetch, that’s an iOS 7 thing that’s explained quite nicely in objc.io’s Multitasking in iOS 7 article:
Background Fetch is a kind of smart polling mechanism which works best for apps that have frequent content updates, like social networking, news, or weather apps. The system wakes up the app based on a user’s behavior, and aims to trigger background fetches in advance of the user launching the app. For example, if the user always uses an app at 1 p.m., the system learns and adapts, performing fetches ahead of usage periods. Background fetches are coalesced across apps by the device’s radio in order to reduce battery usage, and if you report that new data was not available during a fetch, iOS can adapt, using this information to avoid fetches at quiet times…
But the naîve user may find a surprise in wait:
An Unexpected Botnet
… There is, however, an intrinsic danger in applying this ability without fully thinking through the implications. When enabled within your applications you are essentially building a massively distributed botnet. Each copy of your application will be periodically awoken and sent on a mission to seek and assimilate internet content with only the OS safeguards holding it back. As your app grows in popularity this can lead to some rather significant increases in activity…
Here are the feed request frequencies for various Background Fetch enabled podcast clients … For an RSS feed that changes only once per week just these apps produce 126k web requests each week (out of 160k across all aggregators ). The feed itself is 450KB (49KB gzipped). Where it not for HTTP caching/compression (discussed later) this would be generating 56GB of almost entirely unnecessary downloads each week…
That is, indeed, a lot of almost entirely unnecessary downloads. The developers of Castro chimed in here:
The Value of Background Fetch [Point]
… Our strategy with Castro has been to employ Background Fetch to help us avoid the ongoing cost of a server. Castro polls each subscribed feed from the app regularly and posts local notifications when new episodes are found. There are pros and cons to this approach.
Pros
- We spend no time on web app development or money on server hosting. Xcode is always open.
- We have no scaling concerns.
- The continued functionality of the app is not dependent on future sales.
- There are fewer points of failure.
Cons
- Worse update performance since the app hits every individual feed, rather than one centralised server.
- A central server gives developers flexibility to fix individual feed issues, like poorly formatted dates or duplicate episodes for example…
Well, being big believers ourselves in not doing work we don’t have to, that makes a pretty compelling argument, indeed. But hark! Here’s a counterpoint from coming soon Castro competitor Overcast author Marco Arment:
The Value of Background Fetch [Counterpoint]
… Service-backed apps still have a lot of advantages and exclusive capabilities over iOS 7’s Background Fetch. I think server-side crawling is still the best choice for podcast apps and feed readers, for which users want fast updates to collections of infrequently updated feeds.
Overcast has been crawling tens of thousands of podcast feeds every few minutes for the last 6 months using standard HTTP caching headers. In the last week, 62% of all requests have returned 304 (“Not Modified”). Many of the rest returned the entire “new” feed, but none of the episodes had actually changed, making the server download and process hundreds of kilobytes unnecessarily.
An app using Background Fetch needs to make all of those fruitless requests just to get the handful of occasional changes. All of those requests cost processor time, memory, battery power, and data transfer. And each copy of the app needs to download those hundreds of wasted kilobytes when a server erroneously reports an unchanged feed as new…
A server can simply send a silent push notification to all subscribed apps when there’s new data in a feed, and each app can download just the changes. With infrequently updated feeds, like podcasts, this leads to huge savings in battery life and transferred data over time…
Well, there’s that too. So yeah, if you can’t count on decent 304 support, background fetch is not your resource-optimal choice no.
Lots of good numbers to crunch through, so read the whole posts. Personally, if the choice for your particular application is less than immediately obvious, we’d recommend implementing both methods; that way, if your service goes down, or you stop paying for it, or whatever, the app can remain functional. Safety first and second, that’s us!
Continue Reading →
27
FEB
Share
