This is the long awaited sequel to the tale of Audiobus’ development. I’m completing this article now, on the day we say an emotional farewell to our motorhome Nettle, who has today been sold to a new family in the UK. It seems like a fitting time to tie off some loose ends as we start the next chapter of our lives in our new home in Australia.

In [Part 1](http://atastypixel.com/thirteen-months-of-audiobus/) of this article, I wrote about the early stages of the technology which was to become [Audiobus](http://audiob.us), our inter-app audio platform, now supported by over 500 great music apps. Part 1 ended just as Sebastian had one of his genius moments, which I obnoxiously left as a cliffhanger. So, onwards:

It was winter in the south of France, and I was buried in the best kind of work: A new project, and one that brought together a bunch of different interests into a challenging, exciting heap.

But first, it was time to move on and find a more satisfying place to spend the rest of the winter.

I’d spent a little time researching places we could stay which were open all year, and I found one that looked promising: A little caravan park, wedged between the Aude river and the ruins of a 12th century cathedral, in the foothills of the Pyrenees, which sprawl across the French/Spanish border, in an old Roman spa village called Alet-les-Bains. So we packed up and took off across the countryside, taking a couple of days about it.

When we finally arrived, following the snaking, cyan-coloured Aude up a valley in the foothills, we were thrilled: Alet-les-Bains was the kind of French village that we would fantasise about before we left Australia, all delightfully wonky half-timber buildings and narrow winding lanes, and right out our door, too.

It even snowed for us a couple times, which really was rather sporting. Snow in a medieval French village! Hard to beat that.

Anyway, it was a tremendous spot to spend a few months programming.

So far, I’d put together an interface for my inter-app audio system that was built into each app. Users would bring up the interface (somehow, depending on the app), then select sources/destinations from there.

I’d been conversing with my friend Sebastian more and more frequently, sometimes spending hours each day talking. I was struggling with two things: Usability, and a way to turn this idea into a viable product. And then, Sebastian solved both: We make a separate app which does all of the configuration.

That solves the usability problem, as it means there’s one, very accessible and simple way to connect stuff together. The problem with the traditional technique for connecting apps via Virtual MIDI is that every app has a different interface, accessed in a unique way for each app, and with app-specific behaviour. There’s no consistency at all, and it’s never clear what one should expect. Having it all done in a centralised location makes everything absolutely clear, and gives users a nice top-down overview to boot.

But even more elegantly, having a centralised app solves the product problem. My original thought was finding a way for developers to fund the development. That’s not a great idea, firstly because there are a very limited number of developers, and secondly because it actually disincentivises adoption! By having an actual app we can sell, our users can help fund development, which is a vastly more sustainable model.

So, Sebastian’s proposal turned what would be a mainly self-funded, unsustainable project into something that we can truly throw our weight behind. That’s when we became a partnership for real, and dived into designing the workflows.

“iOS Audio Pipeline”, the in-progress name for the project, soon became “Audio Bus”, then “AudioBus”, and finally (with Sebastian’s German influence!), “Audiobus”. It felt right.

We went through a number of iterations of icon concepts, some more lewd than others:

…until we settled on the final version:

We spent months and months carefully going over details, talking for hours each day about how to best represent the connection screen, how to handle multi-app workflows, tearing through ideas until we found something that worked. It was out of these discussions that the concept of the three-group “Input-Filter-Output” pipeline came into being.

This three-way division between types of apps let us (and our community of developers and users) communicate more easily about what apps could do and how they interacted. It also led to a very simple and easy to operate connection mechanism that required just a short sequence of taps.

Another thing that fell out of these discussions was the Audiobus connection panel, a vital ingredient for a multi-app workflow, where you might want to control an app in the background from a different app in the foreground. Crucially, this give us the ability to trigger recording and playback in a timely fashion, without needing to switch between apps to do it. It also gave us a way to navigate between the currently-active apps of a session, pulling them together.

A concept we struggled with was how to initiate an Audiobus session: due to the limitations of the platform at the start, Audiobus could only detect apps once they were running and active, after they’d logged into our registration system. That felt wrong, and we needed a way to avoid that awkward additional step.

The solution came in the form of a separate registration system that allowed developers to register apps with our database which was then downloaded by the Audiobus app and used to identify which apps were installed, without those apps needing to be launched in advance. The same mechanism that allowed us to determine if an app was installed — the use of a custom URL — we could also use to kick-start those apps, so that give us both an easy-to-use app launcher as well as an on-device registration system.

That meant diving into some web development, which resulted in the Audiobus Developer Center we have today.

This registry gave us something more valuable, though: a fully automated (from our point of view, anyway!) dynamic list of apps that work with Audiobus, categorised by their capabilities. That meant we could make this list available on our website, allowing people to discover new apps. Tied together with Apple’s affiliate marketing system that gave us, aside from an additional revenue stream, some fantastic tracking abilities.

It’s that tracking that let us see just what implementing Audiobus has done for those compatible apps: just in the first few months of 2014, we sold almost a third of a million dollars worth of third-party apps through our compatible apps directory, which is staggering.

In the meantime, Sebastian and I met for the first time in Barcelona! He flew down to join us, while we drove over the Pyrenees down into Spain, passing through snow and down to the 35°C coastal climate.

After nearly a year of working together, despite having never met face-to-face before it seemed quite natural to hang out in person, although our productivity admittedly dropped somewhat during the week in food, beer, and vermouth-induced merriment.

We made contact with a number of developers we’re close to, and began the process of trying out Audiobus in other environments than our own apps. It was a pleasure working with the likes of Rolf Wöhrmann, Jaroslaw Jacek, Hamilton Feltman; Kalle Paulsson and the Propellerhead team, the Positive Grid team and a number of other talented folks, and together we discovered and ironed out the remaining issues.

It was a thrill seeing these great apps passing live audio between themselves, and we were excited to see public interest growing as we got closer to having a launch-ready product.

Meanwhile, we’d taken some time to head northwards through the beautiful region of Provence, France, where we spent some time hiking over glorious Mediterranean fjords and rowing and swimming in turquoise water near Cassis, cycling through fields of purple lavender, and driving through beautiful fairytale landscapes.

We ended up back in the UK, in the beautiful, quiet village of Wootton, where we continued to refine Audiobus and get it ready for launch, amidst the rolling green fields, bluebells, cooing pigeons and bleating sheep.

We’d taken Audiobus to the point where it was ready for a test submission to Apple App Review. We were very nervous about this, as Apple don’t have a pre-approval facility. That means that there can be a staggering amount of risk involved in developing a groundbreaking new product, especially one that treads dangerously close to “system” functionality. This was the one point of failure for us, and we uploaded a build to Apple with great trepidation.

The wait was excruciating. If Apple said no at this point, we would have no recourse: the last year of work would be wasted.

Then, the news arrived: we had the green light! We breathed a massive sigh of relief and continued with our refinements, building the website, writing the developer documentation, addressing bugs.

Winter began its approach, and we moved closer to London as frosty mornings became ever more common.

Finally, launch time arrived: we had our initial group of apps, we’d done our due diligence, everything was tested and ready to go. We uploaded the final public build to Apple, along with Audiobus-compatible builds of our other apps Loopy and SoundPrism, and sat back to wait for approval.

Then, disaster struck as we were contacted by a representative of App Review who told us they had a problem with our app and were taking some time to consider whether it would be rejected. It’s hard to express our feelings at this point, after having come all this way. We were terrified.

And then: SoundPrism was approved. Then Loopy. And then, to our enormous relief, we received notice that Audiobus had been approved. It was time for a drink.

Our work was done, and with great excitement in the frosty dawn of an early winter’s day we watched as the biggest, most complex project we’d ever worked on went out into the world.