iOS Background App Kludge
iOS 4 includes seven multitasking services, but none of them are conducive to running a utility service in the background. An application can run in the background to get updates from the GPS, but Apple won’t allow it to run in the background to get updates from IM, Twitter, or a mail server. (Apple’s own Mail app is exempt from this rule, of course.)
The developers of Pastebot wanted to run their app in the background to listen for updates from their companion Mac utility. Their solution is to use the multitasking service that lets apps play music in the background (via John Gruber). They thoughtfully included a silent audio clip so that this kludge would be invisible to the user and not drain the battery. Apple rejected the app, saying that the music must be audible.
So, instead, you must create or buy a silent audio clip, put it in iTunes, sync it to your iPhone, and select it in Pastebot’s settings, all to work around Apple’s decision to forbid normal background processing. This makes the app more difficult to use and wastes the time of both the developers and the users.
13 Comments RSS · Twitter
It's like shooting fish in a barrel. Since I'm not getting paid, it's only a top 5 list instead of a top 10. Sync and select your own (silent) drum rolls at the appropriate moments:
"So, instead, you must create or buy a silent audio clip, put it in iTunes, sync it to your iPhone, and select it in Pastebot’s settings, all to work around Apple’s decision to forbid normal background processing."
Response #5: The quicker workaround is to load a malicious PDF file.
Response #4: Only trucks require normal background processing.
Response #3: Steve Jobs can make a Finder. But only John Sculley can make a MultiFinder.
Response #2: It's still a helluva game console.
Response #1: Just don't hold it that way.
It also wastes battery, presumably kills your ability to launch the iPod app from the audio shortcut menu, and probably means that only one app can run in the background at any given time. This is not a solution, it's a symbol of how absurd a development platform the iPhone has become.
I'll note the really wacky thing here is that the AppStoreReviewMonster approved the app.
They seem to have actually stuck to the letter of the stated rules, rather than using the standard ad hoc decision making process to kill the app knowing that letting it past the velvet rope it would lead to negative coverage that doesn't advance the platform. Methinks someone is going to get fired from the AppStoreReviewMonster for not knowing the real ad hoc rules...
They should have supplied multiple songs you could pick from, one of which was silent. I bet that would have gotten around the restriction.
My bet it with all the publicity, the app will be rejected anyway. Or will soon be when more apps start to do the same. That would frankly be best for everybody. Then in iOS 5, some official way to do it will be added.
@charles That is my bet as well. They are clearly violating the spirit of the rule, and this kind of kludge reflects poorly on the platform. I think Apple will eventually add better support for multitasking and reject apps that abuse it (i.e. use the more general API when the GPS-specific service should have been used).
"They are clearly violating the spirit of the rule, and this kind of kludge reflects poorly on the platform."
The problem, of course, is that if you have to worry about violating "the spirit of the rules" rather than "the letter of the rules", then you no longer have rules. The entire reason the AppStoreReviewMonster exists is precisely because the company has made a policy decision not to have written rules.
(There are written rules, of course. They just don't happen to have much to do with the real and unwritten rules that govern the AppStoreReviewMonster's normal decision making process.)
And, even more obviously, if a developer has to worry about whether or not their app Advances the Platform™, then all bets truly are off. I mean, I can wrap my mind around the internal logic of why Playboy Advances the Platform™, while a Project Gutenberg reader that can access the text of the Kama Sutra doesn't, but that puts us well into game console logic...
-----
"My bet it with all the publicity, the app will be rejected anyway. Or will soon be when more apps start to do the same. That would frankly be best for everybody."
Depends on what you mean by "everybody".
If you define "everybody" as the upper management of Apple and the short-term shareholders of Apple, I'd tend to agree with you.
On the other hand, if you define "everybody" as Apple's customers, Apple's developers, and the long-term interests of Apple itself, I think you are 100% dead wrong.
Kludges are the worst thing in the world with the single exception of banning kludges. Kludges let a minority of users do something with their gear beyond what it was originally intended to do. Kludges end up increasing innovation, and over the long run, actually do genuinely advance the platform.
Just because Apple doesn't want me to hold it that way doesn't mean it should stop me from applying a piece of tape and holding it the way I want. I like holding my gear the way I want. I think "everybody" benefits if they are permitted to hold their gear the way they want.
LKM: I don't know exactly how Tapbots are doing this, but with the beta version I'm using, Pastebot does not show up in the audio shortcut menu. Running another audio app — Pandora, iPod, whatever — does prevent Pastebot from listening for new clipboard items, but when Pastebot is listening, it doesn't show up as an audio source in the switcher.
Presumably, with the changes they're making to get App Store approval, it will, though.
@ Chucky I don't agree and I do think that in the grand scheme of things, it would be best for the other devs and for the consumers that this kind of kludge does not become common practice (of course, it would not be best for Tapbots, and I should add I do not **wish** them this kind of pain).
You are right however that this might unfortunately be the only for devs like Tapbots to get the message to Apple. It worked in the past with some private APIs like access to the video from the camera.
What they could do right now without iOS 5 is agree to consider background services as an option for multitasking, on a per-app basis, with increased scrutiny. As they get better at streamlining the review process, maybe they'll consider it. I would not bet much on it, of course :-)
"I don't agree and I do think that in the grand scheme of things, it would be best for the other devs and for the consumers that this kind of kludge does not become common practice (of course, it would not be best for Tapbots, and I should add I do not **wish** them this kind of pain)."
We do indeed disagree. By my math:
Not wanting the kludge to become common practice ≠ Stopping apps that employ such a kludge from being publicly distributed.
But I do understand that I am living in a parallel universe where iOS would really be something cool if it weren't being yoked to a game console model.
(And FWIW, I do understand that there are tradeoffs to be made. I do understand that dealing with the limitations of cell networks and the limitations of an immature OS on slender hardware mean that there are explicable reasons to put Apple temporarily in a gatekeeper position on app distribution. But that gatekeeper position entails great responsibility, and consistent rules that thus allow developers to kludge around within those consistent rules are part of that great responsibility. But, again, I'm living in a parallel universe where Apple wants iOS to be something more than just a game console, and I suspect that is the real source of our disagreement.)
[...] 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 [...]
