#author-padraig

Oisin and Padraig discuss the wrap-up of Castro 3 development and reveal the features that current Castro users can expect in 3.0

Links:

How Ulysses pulled off a controversial pivot to subscription - SaaS Open Mic by ChartMogul

What we need from Apple to make standalone Apple Watch podcast apps – Marco.org

Mark Steadman:

Subscribing to a podcast should be as easy as sending an email, if not easier. In an ideal world, you find a podcast you like, somewhere on the web, click “Subscribe” and are redirected to your podcast app of choice, which shows the artwork, description and list of episodes (just as if you’d tapped a search result within the app). You tap the “Subscribe” button in your app, and you’re done.

The suggested solution is a podto: scheme. The scheme is the http: part of a url; the email scheme is mailto: for example. Tapping scheme links usually makes the OS open whatever app is registered with that scheme and sends the text that comes after the colon to that app.

Adding support for this scheme to Castro (or any other podcast app) is trivial, but there are problems with the concept:

There's already a pcast: scheme but Apple associated it with Apple Podcasts app in 2012, so it always opens to Apple Podcasts. This is a reasonable default, but it can't be changed to third party app, because iOS doesn't give users the ability to change it.

Users could have many podcast apps installed. If they all supported this scheme, podto: will open one of them, but users won't be able to choose which.

If it caught on, Apple would probably add support for it to Apple Podcasts and we'd all be back at square one.

Tapping it on a system that doesn't have a podto: app installed would cause a uselessly vague error for the user along the lines of "Safari cannot open the page because the address is invalid." That's more confusing for the user than the alternatives.

Our solution to this problem is our — https://castro.fm/itunes/1143273587 links. To link to shows in Castro, podcasters only need to know their own iTunes ID, not our internal id for their podcast. Overcast and Pocket Casts also have URLs that can understand iTunes IDs.

The Castro link takes you to a page with buttons to subscribe directly in the major iOS apps. It's not perfect, but it works today and doesn't require the industry to change before it can be useful. Any other podcast app maker can build a version of this too, by taking the iTunes ID and then using the lookup endpoint to get the RSS feed.

Another worthwhile alternative that works today is the Podlove Subscribe button.

Castro is on sale now at US$1.99 as part of the AppSanta holiday sale from now until the 26th of December.

Oisin and I have continued to work hard on Castro in 2017. Some highlights include:

Castro 2.3 in February: Quick access to episode triage in notifications

Castro 2.4 in May: Enhanced Audio.

Castro 2.5 in September: The best Drag and Drop in any iPhone app

Castro 2.6 in December: Backup & Restore

All of the apps on AppSanta, including Castro, are from small indie developers. This year AppSanta is be donating 25% of the profits from affiliate revenue to AppCamp4Girls.

Castro 2.6 is available on the App Store now.

Castro automatically backs up user data to iCloud Drive every 24 hours. This means that user subscriptions, history, starred episodes, inbox and queue state can be recovered even if the app is deleted, because the backup file is stored in iCloud Drive.

This feature is especially useful when a user gets a new iPhone, but don't want to set it up using an iCloud Backup.

Alternatively, if anything goes wrong with Castro for any reason, users can re-install the app, and restore everything back the way it was at the time of the last backup, instead of starting from scratch. We hope that this won't be needed, but we're glad it's now possible.

You can find the feature in Settings→Backup / Restore Castro. Tapping a backup cell will initiate a restore. It requires a signed in iCloud account and is turned on by default. Castro backups are very small, usually a lot less than 1mb. Users can disable the feature if they'd prefer that Castro didn’t make backups.

This version also makes it possible to tap a podcast description in search results to read the whole thing and it allows toggling playback speed on the Watch and CarPlay “Now Playing” screens.

The ability to detect multiple points of contact on a screen, known as multi-touch, has been around since the first days of the iPhone. Before the iPhone we interacted with computers indirectly, using a keyboard or a mouse. The major advance of multi-touch is the illusion of directly manipulating the interface. In practice though, much of the capability of multi-touch is under-utilized. Aside from the occasional pinch-to-zoom on a photo or map, we still perform most actions with a single finger. This is changing with iOS 11’s new drag & drop capabilities. iOS apps have a new way to deliver on the promise of multi-touch.

One limitation of drag & drop on iPhone is that dragging between separate apps isn't supported, while it is on iPad. A lot of attention has focused on drag & drop in the context of sharing data between apps easily. That is a great improvement, but it's is not the full story. Drag & drop is powerful and transformative even within a single app.

Many iOS workflows are tedious, requiring taps, swipes, special edit modes, pushing extra screens on top, and finding a done button at the end. Users have to maintain a mental model of where they are in the app as they step through these tasks. Consider this example: you’ve written an email and wish to attach a photo. You tap a couple of times to get the black popover to appear, tap the right arrow, tap "Insert Photo or Video", browse through your photos, tap it, then tap "Choose", then tap send. With drag & drop, you find the photo and drag it into the email.

In addition to making interactions much more efficient, the direct manipulation that drag & drop affords is easily learned. It’s not just a tool for power-users. It’s intuitive — we move things around in the real world and now we do that in apps too. The basic idea has existed on the desktop for decades. Ordinary users will get it.

Castro 2.5

We worked all summer to add the new drag & drop features to turbo boost triage, the core feature that makes Castro special. Triaging podcast episodes is much more simple and powerful in Castro 2.5.

You no longer need to process episodes one at a time — you can scroll through the inbox with one finger, collecting episodes in a bundle held by another finger, then drop them all in the queue at once. You can re-arrange your queue by picking up a few episodes at once and dropping the bundle in a new position — in a long queue, this is a huge improvement.

Here are some things to try in Castro 2.5 and iOS 11:

Tap and hold to lift an episode, then drag it.

While dragging, tap more episodes with another finger to add them to the bundle.

Drop episodes on the queue, inbox or archive to move them to these locations.

Hold a bundle over any tab icon to switch to that tab, or just tap it with another finger.

Drop episodes in a specific queue location, not just top or bottom.

Drag from the filter bar to pick up a bundle of all the episodes in that filter.

Using drag & drop, you even can now move episodes back out of the queue into the inbox.

Castro is on sale for one week. Get it on the App Store now for 50% off. I'm going to state the obvious here and tell you that $1.99 is good value for a premium podcast app.

We don't have sales often, so if you haven't tried Castro yet, this is your best opportunity. If you already have it, this is a great time to gift it to that person you know who weirdly keeps using some other podcast app.

Oisin and I are hard at work on our iOS 11 update to Castro. We're happy to announce that it will be a free update, so if you buy it now, you get a great podcast app today and an even better one in a few months.

This morning, I saw a tweet in my timeline pointing out an iTunes Connect warning about encryption usage. I decided to spend some time making sure that our app Castro was properly registered.

The last time I payed attention to the encryption export requirements, the US had relaxed the requirements to register usage of encryption and get an “Encryption Registration Number”, so I assumed we didn’t need to do anything else. It now appears that app makers need to annually submit a self-classification report.

This page on iTunes Connect is a detailed FAQ that’s worth reading to make sure you understand what’s going on.

Regarding ERN requirements:

Encryption Registrations (ERN) are no longer required prior to exporting. In lieu of obtaining an ERN prior to export, BIS now requires a year-end Self Classification Report. Consistent with these regulatory changes, Apple has simplified the export compliance review process and will no longer require developers to upload an ERN.

The Self-Classification report:

An annual Self Classification Report is a requirement for exports of certain encryption items. For example, if your app is making use of standard encryption algorithms available in Apple’s iOS or macOS, or simply making calls over HTTPS, you may be required to submit an annual Self Classification Report to two U.S. Government agencies with information about your app every January. For more detailed information, see the following encryption reporting guidance policy.

Unfortunately, the links in this document lead to pages on the bis.doc.gov website that are missing. I was eventually able to find this page though: Annual Self-Classification

After reading through that, I understood that the “report” is simply a CSV file that you create and email to two email address. There’s a sample report linked, and the fields are all pretty straightforward, with the exception of ECCN and Authorization Type:

For Authorization Type, I chose MMKT… which I think means mass-market.

After some searching around various documents on the BIS website and elsewhere, I eventually determined that 5D992.c is the appropriate ECCN for our app. This blog post was helpful when tracking it down.

Once I had those, the other fields were obvious. I emailed it off to the two addresses, one BIS, one NSA (!), in the self-classification document. I haven’t had a reply yet, but I think that’s it. We’re supposed to resubmit this every year or email to say it hasn’t changed.

Last Friday, Apple announced some additional XML tags that it will support in podcast RSS feeds. Here’s the video of the session where the tags were announced and here’s a PDF explaining each tag.

First, lets give Apple some credit — these features could have been built into their Podcast Connect backend, which would have brought podcasting further under its control. Apple instead chose to extend open RSS feeds. This is an encouraging signal for third party podcast app makers and for anyone else who cares about the openness of the podcasting ecosystem.

News Podcasts and Story Podcasts

The majority of podcasts can be categorized as news-type shows. Some clear examples of this are Pod Save America’s political analysis, The Talk Show’s Apple discussions and Football Weekly’s soccer coverage. Listeners of these shows are not expected to know the context provided by previous episodes, and the most recent episode is the most relevant. Apple refers to these as "episodic" which is ambiguous, but I'm going to stick to their terminology for the rest of this post.

There is another type that is less common but still important: story-type shows. Some of the most successful podcasts in the last few years have been story-type shows, which are much more like a TV series than a news show. Serial and S-Town are the obvious examples. Listeners of these shows are expected to listen in order, starting from the first episode. Apple calls these "serial" podcasts.

Every podcast app I’ve tried treats every podcast like an episodic one. When you first subscribe, episodes that are older than the most recent one are marked as played. They’re not actually played, but this shortcut taken by app makers has persisted for years and is now a part of how podcast apps are expected to work. Castro is strict about the meaning of “played”, so older episodes go in the archive instead of being marked as played but the effect here is the same; older episodes are de-emphasized. The one token gesture towards serial shows in Castro is on the subscribe screen, Castro shows the oldest and newest episodes for easy queuing if you do intend to listen from the start. This helps, but it doesn’t add up to solid serial podcast support.

One of the challenges for podcast apps in accommodating serial shows is that there’s no way for podcasters to signal that their show is meant to be listened sequentially. App makers could build a serial workflow but it would require every user to understand what that is and then each user would have to toggle a setting for each relevant subscription. Users rarely change default settings so its unlikely that this feature would be used even where appropriate.

What do the new tags do?

These new tags provide a means for podcasters to indicate directly in the feed that a podcast is an episodic podcast or a serial podcast. This gives podcast app makers all the information they need to handle these shows correctly without user intervention.

Additionally these tags allow podcasters to explicitly assign season numbers and episode numbers, and to distinguish bonus or trailer episodes from full episodes.

With this information, apps will be able to:

pick the correct starting point when a user subscribes to a serial podcast.

provide appropriate auto-queue behaviour for serial podcasts.

highlight and play trailer episodes for users who are browsing to help them decide if they want to subscribe.

The new tags in practice

What about other podcast types?

There’s a third type of podcast that is not well served by either the episodic or the serial approach. A good example is In Our Time which is made up of hundreds of interviews with experts on various historical people and events. The relevant factor for deciding whether to listen is the episode’s topic. An episode from 5 years ago may be more relevant to your interests than one published today. It’s a shame that podcast apps bury these older episodes. Perhaps there is an opportunity to add a third type that identifies these shows separately?

Should bonus episodes get season/episode numbers?

While integrating the parsing of these tags to our server, I picked one serial podcast feed (Serial) and manually added the tags myself. A number of questions arose about how to use the tags:

The Serial podcast feed includes three episodes during season two that don’t progress the season story, but instead provide updates on the events of season one. Of the three possible episode types (full, bonus, trailer). It makes sense to me to consider these to be bonus episodes.

The three bonus episodes have a preferred order for playback, so it also makes sense that they should have episode numbers.

Which season should they belong to? They relate to season one content, but were published during season two. Should they be their own season?

If they’re in season one or two, what are their episode numbers?

Update: I filed rdar://33007101 about this

How should trailers be handled?

The feed also contains a preview and a trailer for a different podcast called S-Town. These should reasonably be classified as trailers, but they’re not trailers for the current show. If a podcast app assumes that a trailer episode provides a preview of the show in question, it’ll be playing the S-Town trailer on the Serial podcast.

Should trailers have season numbers?

How should a podcast app handle multiple trailers in a feed?

There are a range of acceptable answers to these questions but the point is that podcasters will need to think through these decisions carefully because their choices will affect the display of their episodes. If there’s too much ambiguity, it’ll be hard for podcast apps to do the right thing in all cases. Over the next few years I expect that some best-practises will evolve.

Update: I filed rdar://33006962 about this

Conclusion

It became clear to me even when considering Serial, which is perhaps, the canonical example of a serial podcast feed, that there were a number of questions about how best to choose values for these new tags.

Podcasters should start thinking about answering these questions and adding these tags to their feeds right away. Even episodic podcasts will benefit from the episodeTypes and explicit episode numbers. This will allow app makers to start building features that take advantage of them and understanding any unexpected usage.