App Spotlight + Interview: Pocket Casts

My first smartphone was a twice-handed-down iPhone 3GS. It was a scuffed, scarred, plastic little thing, and for the 15 year-old nerd that held it, it was nothing short of mesmerizing. What followed shortly was my very first all-nighter, spent in utter juvenile excitement over the gadget, in an attempt to figure its ins and outs, and most importantly, to stuff it senseless with every application a boy that age would want to keep in the massive sixteen-gigabyte storage, a la Temple Run and the original Angry Birds, with its fifteen free-to-play levels before the IAPs kicked in.

I was better than my friends, embroiled in their daily struggles with their finicky Android Gingerbread-powered handsets, while I could lord my high-end Apple device over them as they did so.

Developing the itch to mess with phone software over time, I moved on to the Nexus 5 (the irony isn't lost on me), which, till today, remains my favorite smartphone. After its buttons gave out, I got my hands on a Nextbit Robin, and after that one gave up the ghost, I sit now, seven years after the iPhone failed to boot one last time, with my Xiaomi Mi A1.

Across these preposterous pubescent platitudes and the multiple smartphones that succumbed to my horrifying "experiments", one of my very first paid apps on the iPhone - Shifty Jelly's Pocket Casts - has stuck with me through and through, so I understandably have some attachment to it.

I discovered the appeal of podcasts, enjoying the often soft-spoken voices feeding me stories and tidbits of knowledge that somehow sat comfortably in the back of my head despite being, more often than not, a background activity.

In 2014, Shifty Jelly debuted a web player for Pocket Casts that synced with the mobile apps, while also functioning independent of them. Being fresh out of school, I still had the solid, full-featured smartphone app to work with, rendering the web app unnecessary for me at the time.

As a college student, the need for a podcatcher on my laptop for when my phone wasn't readily available became pressing. Having to switch between devices just to change volumes or skip ahead a bit in a track kicked me out of my workflow quite easily, so I caved and purchased access to the web player shortly after.

The web app worked as expected - it kept the same list of podcasts I'd subscribed to on my phone, kept tabs on the ones I'd already listened to and had the same sections for 'starred' and 'in progress' podcasts among others. Its UI was a little different, straightforward nonetheless. Work then began on a revamp of the web player in the form of an open beta, giving the interface a greater degree of familiarity to anyone used to the interface in the mobile apps.

This isn't to say it's a blown up version of an app made for small screens - the web player is not a Progressive Web App, and has been designed primarily for use on large screens, and won't play nice with your handset. It scales well with high-DPI displays, and barring the necessary padding, lacks the absurd, unused white space that one might find on certain other scaled-up software. I enjoyed using it a bit more, despite its lack of unique playback features currently present in its mobile counterparts, such as a sleep timer and automatic clipping of extended silence in a podcast.

One noticeably absent feature is offline listening. There's no way to download episodes to consume later while off the grid, unfortunately.

You might be wondering, at this point, why my focus so far has been on the beta web player and not the Windows app that was released recently. It's simple - the two are one and the same. The interface, and the feature-set are nearly indistinguishable.

There are, however, a few goodies Shifty Jelly has included in the Windows app, including native audio controls, alongside the system being furnished with basic playback information so you could tell which podcast was playing at a glance.

Pocket Casts for Windows is no Twitter PWA. It ticks nearly every box for me in terms of functionality, and from a visual standpoint, the typefaces and UI elements look fantastic. While I can live with not being able to download podcasts for later use, the lack of appealing transitions and animations are sorely missed, and make its existence as a web app a bit too obvious. It just feels a bit too static, especially compared to its exceptional sister apps on mobile.

That might be an unfair comparison. Perhaps I expect too much from apps devoted to media consumption. Pocket Casts goes almost all the way to being the perfect cross-platform experience, so I suspect it's a testament to my faith in Shifty Jelly's ability to shell out a quality experience that the "almost" bothers me so much.

Interview

I had the chance to have a one-to-one chat with Russell Ivanovic, a co-founder of Shifty Jelly, the little Australian company that made Pocket Casts (and something called Pocket Weather, available only for people living in Australia, unfortunately, so no App Spotlight on that one anytime soon).

Russell and I cover a good deal of material, including the future of web-based apps, and go on to talk about Twitter's recent foray into this field.

Having debuted Pocket Casts for Windows recently, what sort of a future do you foresee for web apps that leverage local API?

I think our desktop app might be a little different than most. Since launching our web app we have had non-stop customer requests for a friendlier desktop experience. Now, that means a lot of things to a lot of people, but the common thread seemed to be that a lot of people don't want to just open another tab in their browser to listen to podcasts. So when we redesigned the web app as part of our work on v2 of it - currently in beta - we made sure we made it as flexible as possible, so we could do more interesting things with it on the desktop.

As part of that experiment and to test the waters, we built a Mac app as a companion to the web app. The idea was not just to have the same interface, but also to do some things natively on a desktop to make the experience even better, like supporting media controls and publishing now playing info to the operating system so it can give you shortcuts and other niceties to use. It also led to a few other things like reading chapter information and displaying that, something that's not even possible in a web app for security reasons.

The experiment went really well. We found that re-using the web UI meant we could deploy rapid changes to it, and adding these little native touches meant that people felt like they were getting more than they could from a web app. Considering how well that went, and given that I use Windows 10 a lot in my personal life, I found myself wanting a Windows version too. So did our customers, seeing as how over 50% of our web users are running Windows.

So in my spare time, I worked on a Windows 10 UWP app just to see what we could do on the platform. It ended up being something I used a lot, so we decided to ship that. Just like the Mac app before it, the goals were the same - use a core web UI, and provide native touches to enhance it. It's early days yet, but people seem to have responded well to that approach.

On that note, do you believe relatively lightweight apps (unlike Photoshop and Premiere, for instance) have a future being coded with a strongly platform-specific approach?

I honestly don't think I'm qualified to answer that. I think in cases like ours, it was the right approach. We have a fully featured mobile app built around the idea of being in your pocket and traveling with you everywhere, and that doesn't make a huge amount of sense to run on a desktop, given you'd spend most of your time not fiddling with its UI. You'd have your headphones on you, or a car stereo, with your phone tucked away elsewhere.

So in our case, it made a lot of sense to build a different desktop experience. Should every app do that in the way we did? I know it sounds like a cop-out, but it really depends. I suspect apps like Photoshop are better served with native UI that gives you the absolute best performance and power possible. Podcast listening apps like ours can be built faster - and often better - if you mix in a bit of web technology.

I see. For a small team such as Shifty Jelly, it makes sense to have a web-based desktop interface, given the far lesser effort I'd imagine it'd take to maintain, when compared to individual, completely native apps. Plus, given the effort that's gone into making the design paradigm platform-agnostic in a way, this, in my view, would click with users better.

True. Our mobile apps are 100% native because that's how we get the best experience possible. On the desktop it feels slightly different. If we make one core web app and the build custom experiences around it you get great results with less overlap/effort.

Do you see this as a more compromise-heavy approach? Both as a developer and as a user of your own service.

There's compromises inherent to all development, and with any approach. On mobile, we trade much higher development effort for getting the exact results we want with pixel precision. On the desktop side, we compromise some native features, like downloading podcasts, for much faster development times, and a more agile approach to testing and adding new features.

Got it. On a somewhat less pleasant note, I'd done a piece on Twitter's PWA approach for Windows last week, and the general response to the app was, put kindly, mixed. While there were a number of people who liked that Twitter for Windows wasn't abandonware anymore, there were just as many who did not appreciate having Android UI elements like the FAB, among others, in a Windows app, and were very vocal about Twitter's lack of effort towards catering to individual platforms.

Do you think this is something that will eventually blow over, or do you think teams with far greater resources at their disposal are in some ways 'obliged' to make fully native apps?

I think Twitter is extremely lucky to still be as popular as it is. It rose to prominence with third-party apps and then killed them all, and didn't have the budget to pay a single Mac or windows developer? Makes no sense when the iOS team is 40+ people. Also - this is just my opinion - but their website is an abomination, which when wrapped in a PWA doesn't change that one bit. The way that company is run absolutely baffles me on so many levels.

So that's a long way of saying "no". I don't think the Twitter thing will blow over, and no, I don't think that just because we share technological similarities that there are product similarities.

That's certainly something you'll find vast numbers on the internet, myself included, agreeing with you on. The very last question I've got for you before signing off is something I'm sure you get very often:

How does it feel to be the worldwide industry leader, and possibly the only developer to provide both changelogs that are great fun to read and completely functional, with every update, no matter how minor?

Oh, you! I bet you say that to all the developers. I actually wanted to be a writer, so I feel totally vindicated when even one person appreciates our changelogs. It lets me know I totally would have made it as a writer and been bigger than JK Rowling, et all. See, I know Latin too!

JK who?

Where you can get it

Pocket Casts' web app costs a one-time fee of $9 to use. V2 of the web app, which is currently in an open beta, will require no additional fee, either, and given the Windows and Mac apps are companion apps for it, the above fee will let you use these apps at no extra cost.

The app is available on the Microsoft Store and its Mac counterpart is downloadable from within the Pocket Casts v2.0 web app. Given this is still a beta, it's currently unlisted on the Microsoft Store - which means searching for it there won't help you - but using the link here will take you straight to the download page.

It's also available on Android ($4, but the price varies by location. In India, it's priced at ₹99, which is a bit under $2) and iOS devices ($4, worldwide). There's also a Windows 10 Mobile app, but it hasn't been updated in a while, and doesn't look like it's supported anymore.