TidBITS News App 1.4 Allows Background Audio

We’ve just released a new version (1.4) of the TidBITS News iOS app, containing two bug fixes you probably won’t notice and one new capability which, while subtle, has been requested by users and should make a lot of people happy. We’ll start by describing the new capability, which has to do with audio and TidBITS News’s interaction with other apps.

As you may know, the TidBITS News app enables you to play the recorded audio versions of our articles. (These are the same audio versions to which you can subscribe in iTunes as a podcast.) Because it has the capability to play its own audio, the TidBITS News app has to declare an “audio session policy” so the system knows what to do in case there is any background audio. This was necessary even under iOS 3.x, before multitasking, because the iPod app (or, on some devices, the Music app) could play background music.

Since TidBITS News could play its own audio, and since it was originally written for iOS 3.x, it declared its audio session policy in a simple-minded way. When the app launched, it halted the playback of any background audio. Admittedly, that wasn’t ideal, since if you were happily listening to your favorite tunes via the iPod app, the music would stop when you launched our app, even if you weren’t planning on listening to any of our recorded articles. Clearly, it would have been better for our audio session policy to declare itself only if you actually did start listening to one of our recorded articles. We were aware of this (especially because several users of our app pointed it out to us), but it wasn’t a high enough priority
to tackle immediately.

However, iOS 4 introduced both some new ways of specifying an audio session policy and a new capability for other apps (such as Pandora) to play background audio; so the time had clearly come to straighten out this situation. After some experimentation, it turned out that we could actually change our audio session policy as you start listening to an article recording, and change it back when you finish. There were, in fact, two different ways we could do this:

• TidBITS News could “duck” the current background audio (play it more quietly) when a user started playing one of our recorded articles, and restore the background audio’s loudness when our recorded article stopped playing. This worked perfectly, but some people might have had difficulty hearing Adam’s dulcet tones quietly reading an article while their favorite heavy metal band was wailing away in the background.

• TidBITS News could halt the current background audio altogether when a user starts playing one of our recorded articles. This worked fine too, but unfortunately our app could not reliably resume playing the halted background audio. In theory, such resumption is possible, and TidBITS News attempts to do all the right things, but actual resumption only takes place about five percent of the time. This is probably due to a bug in iOS itself.

So our choice was between an option that worked perfectly but might strain the user’s ability to listen to two things at once, and an option that only half worked. We chose the latter. Ducking is not really suitable for a lengthy, important sound like the reading of an article, as opposed to, for instance, a brief audio notification of an upcoming turn from a navigation app. And the fact that background audio couldn’t reliably be resumed after pausing wasn’t terribly important, because in a multitasking world it isn’t hard for the user to fix this manually.

So that’s the one obvious new feature in TidBITS News 1.4. When you enter the app, any audio that’s playing continues to play. If you start to listen to the audio version of one of our articles, your previous background audio will pause, and, if you’re incredibly lucky, will resume again once you’re done listening to our article. But if it doesn’t resume, then just use iOS 4’s multitasking capabilities to resume it yourself. The simple way to do this is:

1. Double-press the Home button to show the app switcher interface.

2. Swipe the app switcher to the right. This will bring in the stuff from the left, which includes sound control buttons.

3. Tap the play/pause button to resume background audio.

4. Tap in the TidBITS News interface to dismiss the app switcher interface.

On the user side, that’s probably all you’ll notice about this new feature. On the developer side, however, this change was remarkably difficult to accomplish. It turns out that our previous audio session policy wasn’t just annoying; it was actually broken, thanks to the advent of multitasking. Not only were we turning off sound on launch, but also we were failing to turn off sound when the user switched away from our app and returned. So it was actually possible for the user to subvert our annoying audio session policy. This goes back to a point I made months ago, when iOS 4 and multitasking first appeared (see “What is Fast App Switching?,” 23 June 2010): merely
making your app participate in multitasking is trivial—just recompile the app under a current version of Xcode—but making it behave properly under multitasking is hard.

The trouble is that as soon as your app starts to do multitasking, things that worked just fine before can come crashing down about your ears. The reason is that multitasking introduces lots of new ways in which the user can leave and return to your app. Before multitasking, there was only one way to arrive at the TidBITS News app, namely by launching it, and only one way to leave it, namely by quitting it. So, while it was annoying that our app turned off background sound on launch, at least in a non-multitasking world this was clear and definitive. But under multitasking, the user can do lots of strange things: switch to another app and return to our app, summon the app switching interface and return to our app, and so forth. And it
turns out that your app must actively defend against all these possibilities by reasserting its audio session policy in every case. TidBITS News, however, was failing to do this.

And that, in fact, is why we changed our audio session policy. We didn’t really do it just to be nice to users who were listening to music in the background. (After all, when you’re reading one of our articles, you should be giving it your undivided attention!) We did it because we discovered that our audio session policy wasn’t working as it stood. Changing our audio session policy and its behavior was, in fact, just something we did in the course of the much more urgent change of unifying the app’s behavior against the multitasking hydra.

There isn’t an Apple document that says, “Hey, if your app switches to using multitasking, watch out! Here’s a list of things that can go wrong, and sound is one of them.” But there should be. In our case, multitasking broke our audio session policy and we didn’t even notice initially. Nor did Apple’s vaunted approval process alert us to this fact. This is probably true up and down the line of apps. Lots of apps think they have adopted multitasking just by linking against the iOS 4 SDK and recompiling, maybe with a few simple obvious additions like saving state on backgrounding instead of saving it on termination. But multitasking is much, much more complicated than that, and Apple has not made it easy either to
become a safe multitasking citizen or to discover how to become one.

Oh, and what about the other two things we fixed in this release? One was just a good old-fashioned mistake. Images in our articles that had been acceptable on iPhone were appearing at the wrong size on the large iPad screen; this was merely an unnoticed consequence of converting the app so that it ran natively on iPad (see “TidBITS News App Updated for iPad”, 4 January 2011). We also tried to work around a mysterious cosmetic glitch that can appear in low-memory situations; with luck, you won’t encounter the situation that causes this glitch (none of us had, which is why we didn’t know about it), but the truth is that this problem is not really fixed, and likely won’t be until
we tear the app’s code completely apart and rewrite the whole thing from scratch.