@dave @adam
Re: QR code
Use a standard http with user agent detection. This will allow the QR code to always function, safari users get a landing page with ways to subscribe and maybe links to apps.

If the user agent is a podcast app (should probably have some standardized UA for this), then you can just return the RSS in a 301 redirect.

This is how firebase app deeplinks work.

@dave @dwood @adam @agates

Ideally, opening a link for another podcast from an episode's show notes would have access to document.referrer. With that, you could redirect the user back into their app of choice.

Unfortunately, document.referrer doesn't seem to work from app-to-web, just web-to-web. User-agent is similarly unhelpful.

My best solution is to give the user a page with all the relevant links, and then let them save their preference with a cookie.

@dave @dwood @adam @agates

Overcast has a nifty solution to the problem I outlined. Marco parses the show notes with a regex that rewrites Apple Podcasts and Overcast URLs to never open the browser and just directs the user to the native UI.

@dave @dwood @adam @agates

so if you want to make a QR code that works for everyone, maybe you could use Apple’s feed-based URL scheme and build a QR scanner into each podcast app that intercepts it. So iOS users that just use their a generic QR scanner get Apple Podcasts, and people scanning from their podcast app get a better experience.

@dwood @dave @adam These work, but the issue with this is that it centralises the QR codes to point to one domain. So the QR code you see on any Podnews page is a QR code that does a redirect depending on useragent to either Apple Podcasts or Google Podcasts (the players for which are preinstalled on all iOS/Android phones). The reason you can see a redirect happening here is I want to catch the edge-case that you've uninstalled Apple Podcasts - and show something on the page to help.

@dwood @dave @adam With a URL-based QR code, "someone" is in charge, so it isn't decentralised. But a bespoke protocol might never be supported by anything on-device, whereas a URL will *always* work - even if it just takes you to a web-based player. So both approaches are suboptimal here.

@adam @dave @jamescridland we're talking about reimplementing firebase deeplinks here, right? So it's only centralization so much as app developers use the same deeplink service.

I can see an appeal from an app developer to host their own, so that QR code scans drive installs of their app.

The important thing here is when an AppA user scans a AppB QR code linking to an ep/timestamp, AppB should receive the needed info to subscribe/play and certainly not be kicked over to another App/Safari.

@dwood @adam @dave Surely, when an AppA user scans an AppB QR code linking to an ep/timestamp, AppA (not AppB) gets the data? Otherwise we'll end up with 400 different QR codes to scan. One QR code for all...

(...which we've abjectly failed to do for a subscribe button after fifteen years)

@dave @adam @jamescridland yes.

So the idea is we standardize the client implementation as well as app UA responses, we leave safari UA response up to the server implementer, with the suggestion that it be an embedded player, links to pc2.0 apps, etc.

Share links become, for example,

If you can that QR code in Overcast, the PC20 UA means that podnews returns a 301 to the RSS feed for that show. Your client already knows what ep/ts to play.

@jamescridland @dave @adam you can dumb it down and have a metatag in the listen page with the rss link that overcast will then parse and do it's thing.

If you scan the aforementioned link from the camera, you get a nice splash page with the player, and podnews gets to nudge you to install their preferred player with the top banner

@jamescridland @dave @adam if you standardize the client implementation of these share links with QR codes, you bypass Apple/Google restrictions and do not have to worry about the fact that podcast:// is registered to Apple podcasts.

Would it be ideal for QR code links to open from the main camera whatever pc2.0 app was last used? Yes. Is there a way of accomplishing that? No.

It is easy for the pc2.0 apps to add the QR scanner and NOT launch safari if the URL is formatted in a specific way.

@dwood @dave @adam OK - so you could have a link that works in PC2.0 apps, but also works in the camera with a fallback URL. That's nice, so it always works. Good idea. The URL still needs to be centralised somewhere, but I don't think we can escape that.

On Android, you could absolutely set it to open your favourite pc2.0 app from the camera - if the app sets the intent for that URL then it'll appear as an option to set. Don't know how Apple works.

@adam @dave @jamescridland no need to centralize as part of the spec. Just define behaviors for client and server along with url schemes. There could be many domains hosting redirects, make the spec host agnostic.

As for iOS, unfortunately not. Each app can register a Handler (com.overcast://), but you can't over overlapping handlers. That is the legacy method.

The current method is applinks.
You define a FQDN that is authorized to launch your app, then you setup a AASA.

@adam @dave @jamescridland if a developer trusted a FQDN, you could have:

If overcast had in its manifest, the AASA could direct* to launch overcast if its installed.

This would allow multiple podcast player buttons on the fallback page that would launch the appropriate player, if installed. That said, you have to trust the domain somewhat and add it, so this would be terrible without centralization of the link hosters.

@dwood @adam @dave

I don't understand why it makes any sense for Marco to have someone else's domain opening his app. Sorry, you've lost me.

@dwood @jamescridland @adam App Tracking Transparency. I thought it might have been part of that change. 10-4

@jamescridland @dave @adam it doesn't make sense and it sucks on iOS, that was my point. There is no good way to accomplish it on iOS.

@dwood @adam @dave The other way it could work is that the QR code opens the "right" app based on both useragent *and* user preferences. So in the Podnews case, a visit to would check a) what device is this user on, but also b) has this user given a preference on which app to open?

(A protocol-based link isn't possible to catch gracefully if nothing is installed to deal with the protocol, as I understand it.)

@dwood @dave @jamescridland It is my understanding that using a guid offers more implementation options.

@adam @dwood @jamescridland The GUID just ensures that if the podcast referenced by the QR code ever changes, the QR code will still work. It allows is to be a one-time generated thing even if the podcast changes hosts in the future.

Sign in to participate in the conversation
PodcastIndex Social

Intended for all stake holders of podcasting who are interested in improving the eco system