Many iOS music makers want to route audio between apps – just as you would in a studio. But news came this week that Apple would drop support for its own IAA (Inter-App Audio), used by apps like KORG Gadget, Animoog, and Reason Compact. What will that mean? I spoke with Audiobus’ creator to find out.
Michael Tyson created popular music apps Audiobus and Loopy. And he’s made frameworks for other developers, too, not only supporting countless developers working with Audiobus, but also creating the framework The Amazing Audio Engine, now part of Audiokit. So he’s familiar with both what users and developers want here.
Audiobus is key. At first, iOS music apps were each an island. Audiobus changed all that, by suggesting users might want to combine apps the way they do on an stompbox pedalboard or wiring gear together in a studio. Take an interesting synth, add a delay that sounds nice with it, patch that into a recording app – you get the idea. That expectation was also familiar from plug-in formats on desktop and inter-app tools like the open source JACK and Soundflower. And Tyson’s team developed this before Apple followed with their own IAA or the plug-in format AUv3.
So now, having pushed their own format, Apple is abandoning it. iOS and the new iPadOS will deprecate IAA, according to the iOS 13 beta release notes.
This won’t mean you lose access to your IAA apps right away. “Deprecated” in Apple speak generally means that something remains available in this OS release but will disappear in some major release that follows. Apple often deprecates tech quickly – as in one major release later (iOS 14?) – but that’s anyone’s guess, and can take longer.
That is still a worry for many users, as many iOS developers do abandon apps without updates. It’s tough enough to make money on an initial release, tougher still to squeeze any money out of upgrades – and iOS developers are often as small as one-person operations. Sometimes they just go get another job. That may mean for backwards compatibility it even makes sense to hold on to one old iPad and keep it from updating – not only because of this development, but to retain consistent support for a selection of instruments and effects.
But if you’re worried about Audiobus dying in iOS 13 – don’t. Michael explains to CDM what’s going on.
Can you comment on the deprecation of Audiobus and IAA for iOS? It’s safe to say this should mean compatibility at least for the forseeable future, but not much future in OS updates after that, given Apple’s past record?
To be specific, this is a depreciation of IAA rather than Audiobus – Audiobus is a combination of a host app, and a communication technology built into supporting third party apps. The latter is presently based on IAA, but doesn’t have to be.
As for the IAA deprecation, I consider this a very positive move by Apple. The technology that replaces it, Audio Unit v3, is a big step forward in terms of usability and robustness, and focusing their own attention and that of the developer community on AUv3 is a good thing. I doubt IAA is going anywhere any time soon though; deprecations can last many years.
Does this mean the Audiobus app will reach its end of life? Do you have plans for further development in other areas?
Not at all. I’ve got lots of plans for Audiobus, to increase its value as an audio unit host, and possibly to fill the gap left by IAA if it’s ever switched off.
Do we lose anything by shifting to AUv3 versus IAA? (I have to admit I have a slightly tough time wrapping my head round this myself, in that there’s a workflow paradigm shift here, so it’s not so fair to compare the enabling technologies alone…)
AUv3 is actually quite impressive lately, and continues to grow. As you say, they’re pretty different workflows, so it can be tricky to compare. The shortcomings we see I largely put down to developers not fully exploiting the opportunities of the platform – myself included! This will only improve going forward, I suspect.
There is one pretty big downside, which is that implementing AUv3 support in an app is a lot harder than implementing IAA, which itself is harder than implementing Audiobus support. It’s the difference between just a few lines of code, and a whole restructure of an app. Minutes vs days or weeks; worse if there’s file management involved. For apps that want to host audio units (on the receiving end), it’s a lot more work too, as they would need to implement all of the audio unit selection and routing themselves, rather than letting Audiobus do all the work and just receiving the audio at the end.
This is the reason there are still plenty of apps that only do Audiobus or IAA – my own apps Loopy and Samplebot included! If those apps that don’t have AUv3 yet don’t update in time and Apple ever pull the plug on IAA, those will just stop working. And it’s possible we’ll see less adoption of AUv3 for new apps.
But if things do go that way, I’m completely open to the possibility of stepping in to fill the gap left by IAA; there’s no reason Audiobus couldn’t continue to function as it does right now without IAA, as this is how it worked in the beginning. But we’ll wait and see what happens.
Is there some way to re-imagine Audiobus using AUv3?
Audiobus actually already has great AUv3 support built in, and lots of users are already on exclusively AUv3 setups. I’m continuing to add stuff to make the workflow even better, like MIDI learn and MIDI sync – and 2-up split screen coming soon.
Have you heard reaction from other developers?
Not as yet, no.
So you see a justification to Apple going this direction?
Sure, I’d say it’s so we can all focus on the new hotness that is AUv3. IAA was never enormously stable, and felt like a bridging technology until something like AUv3 came along. The resources of the audio team at Apple are just better put towards working on AUv3.
Thanks, Michael. We’ll keep an eye on this one, and if there’s anything CDM can do to pass on useful information to developers interested in adding AUv3 support, I imagine we can do that, too.