Deep Linking in the Bandcamp iOS app

I love Bandcamp. They are truly the premiere independent music platform. They treat their users and artists well, and still manage to stay afloat.

I also like their iOS app. It works well for previewing new music, or listening to music I’ve already purchased on the platform.

I do have one complaint about their app though: There’s no way to open the app when viewing an album or artist’s page in the web browser. Many apps have this functionality. To name a few:

(All of those links should open in their respective iOS apps if you have them installed)

So why not Bandcamp? I don’t know why they’ve avoided deep linking, but for a while now, I’ve just accepted it as a fact. Until recently.

The other day, I bought an album on Bandcamp — Vaporlane’s Hieretic Teen.

After the purchase, I received an email receipt as usual. For whatever reason, I opened that email on my iPhone, and noticed a link saying “listen now in the Bandcamp app”. I don’t know if this is new or not, but this is the first time I noticed it.

Intrigued, I tapped the link. It first opened a web page in Safari, and then opened the Bandcamp app directly to the album, and started playing it! I was surprised and immediately started digging further. I had thought the Bandcamp app didn’t support deep linking, but it was now obvious that it does indeed.

So first, let’s look at the link in that email (personal/purchase information replaced with @@@):


The URL is constructed in a way that it first tries to open the Bandcamp iOS app, but then falls back to the web page if it’s not successful.

So what are all those % symbols? This URL uses Percent Encoding to encode information not normally allowed in URLs/URIs. Here’s a list of the codes used, and their translations:

Percent code Translation
%3A :
%2F /
%3F ?
%3D =
%26 &

So, if we use this to fix the parts after the fallback_url= in the original URL1, we get:


The last bit of that URL is the key. Here it is isolated:


iOS’s deep linking syntax uses URIs to open applications rather than web pages. This description from the deep linking Wikipedia page is good:

Unlike the Web, where the underlying technology of HTTP and URLs allow for deep linking by default, enabling deep linking on mobile apps requires these apps be configured to properly handle a uniform resource identifier (URI). Just like a URL is an address for a website, a URI is the address for an app on a mobile device.

twitter:// and YouTube:// are the iOS URIs used to launch their respective apps, so in this instance, it’s the bandcamp:// part of the URL that tipped me off.

Looking at the URI, there is an album_id= field. I was hoping an album’s ID was used in the actual URL for the album, but it’s not the case. If we dig into the HTML source code though, we find the goods. Here are the last few lines of the source code for Hieretic Teen’s Bandcamp page:

<!-- bender01-6 Sun Oct 09 20:06:39 UTC 2016 -->
<!-- album id 531538254 -->

There it is! Buried at the bottom of the page is this album’s ID. Each album’s page has an album ID commented out at the very bottom of the page.

Next, I built a couple workflows using the excellent Workflow iOS app to test this out. Here they are:

Here’s where we hit a problem that I can’t fix on my own. These workflows work beautifully and without error (in my testing), but only on albums that the user logged into the Bandcamp app already owns. If used on albums not already in the user’s library, the Bandcamp app throws up an error saying:

The album could not be loaded. You may need to add your payment email address or sign in as a different user.

So this is where my journey ends. It seems that Bandcamp and its developers want to keep the deep linking to themselves, and use it only for opening the app from purchase receipts. I’m definitely curious to know why, and I’d like to request that the app’s behavior be changed. Preferably, I’d like it to act like the Twitter and YouTube apps: When any link to a Bandcamp web page is opened, open the Bandcamp app instead. The app’s audio player is much preferable to the web player.

  1. 1.I used ascii.cl’s URL Decoding page to convert this. It’s a handy resource.

Have a comment or notice a typo? Send me an email, or fork this post on GitHub.