Google Podcasts App within Google Play

Today Google released the much-rumoured official/Google branded podcast app. This is something that has been rumoured on and off for quite some time, and we’ve even talked about it regularly on Better Podcasting. While the idea of a dedicated podcast app by Google is new for them, this isn’t the first time that Google has worked to bring podcasting to Android. A couple years ago, Google integrated podcasts into Google Play Music, and last year, Google added podcast-support to their Google Search app, allowing podcasts to be played through Google Search App 6.5 or higher. You can get the app from Google Play by searching for Google Podcasts and download the app titled “Google Podcasts” by the publisher “Google LLC”.

Although I have only had a very brief time to play with the app, I wanted to post my first reaction – sadly, so far my experience as both a podcast consumer and a podcaster is underwhelming; I’ll start off with my critiques as a podcast consumer. Compared to other podcast apps available, the app feels very bare-bones and offers little reason for me to consider switching over. Many features that I’ve grown to love that are available on many other podcast apps, are unavailable in Google Podcasts. An example of this is that the settings only consists of only two options: How quickly to remove completed episodes, and how often to remove unfinished episodes.

The settings screen withing the Google Podcasts app.

There are no options such as refresh time, how many episodes I want to keep showing up, or even options on whether or not to auto-download episodes. As well, the user interface is fairly simplified, meaning those who are looking for third party features such as playlists, will likely be disappointed.

As a podcast creator, there are some additional concerns that I have. It appears that Google continues to make it’s own path when it comes to podcasting. Please excuse me while I get a little technical, but it’s necessary for my first example. Within podcast RSS feeds, there are usually two places that podcasters will place episode descriptions. The first is within the standard <description> tag, however, the other, more commonly placed, is the <itunes:summary> tag. For whatever reason, the latter has widely been accepted as being the main tag, with the <description> as a fallback. From my understanding, this is the logic that Apple follows for its Podcasts directory, and in turn, others have followed suit.  As an fyi, my existing podcast app (Pocket Casts) follows this logic. On the other hand, with Google, it appears they are prioritizing the description tag, meaning those Podcasters which have followed the aforementioned logic, may have issues with their episode information not displaying correctly. A great example of this is that some users use a condensed version in the <itunes:summary> with a full version in the <description>. Another concern that I have is the directory of podcasts, and how podcasts are listed, and the control I may or may not have if Google lists something that shouldn’t be listed. I’ll get more to that later.

The biggest question mark / concern I have, is the way that the app interacts with individual podcasts consumption. Those who have experimented with both the Google Play Music Podcast integration, and the Google Search Podcast integration, are probably very familiar with the difference in the way these operate from a backend perspective. While the Google Play Music app works more like a traditional app where the episodes are downloaded to your device, the Google Search app operates more like a streaming interface. When you press play on an episode, the episode starts buffering to your phone, on-demand. As the episode plays through, more of the episode is download. The Google Podcasts app operates as the latter – streaming.  I confirmed this operation by playing a few episodes and skipping through them – as the episodes played, I watched my data use increase throughout the episode playback. The trouble with this method is that the app will use data by default, and as it stands, it appears that there is no way to prevent data consumption (as mentioned, there are only two settings within the app). For those who are thinking that w work-around is to block it on an app level within Android, I have some bad news to report on that. The app seems to be an overlay for the Google services: as the app played episodes, the general “Google” App itself was the one that would increase in data consumption rather than the “Google Podcasts” app. This means to block data consumption, you likely will have to block the entire Google Service App, which I’m guessing (but have not confirmed) would affect your user experience. You can download episodes individually by clicking on an episode, and then clicking the download button. This will download the episode to your phone so that it can be listened to offline.

An example of the Google Podcasts App Notification Control Screen

With that said, it’s not all bad. The interface was extremely easy to use, and it was very fast to navigate. Searching for a podcast turned up results quickly, and after hitting subscribe, it was easy to navigate individual podcast episodes. When an episode is playing, the notification interface is clean offering a visually appealing play/pause button, as well as the option to skip ahead 30 seconds or back 10 seconds. There is also a very easy to use slider bar for playback offering the speed to be adjusted from 0.5x to 2x speed. The speed nature of the app, combined with the bare-bones nature, offered a really intuitive design. Subscribing was as simple as pressing subscribe and then the podcast showed on the main screen.

The Google Podcasts app displayed a result for our network-wide RSS feed not submitted to any directories.

From a search perspective, my initial search results seemed to find the podcasts I was searching for, and compared to the search results that were found within the Google Search app itself, they seemed slightly cleaner. With that said, it does appear that Google is using their web search integration, as it does seem to be displaying podcast results that are not found it the Google Play Music directory, but can be found within the Google Search app.

This operation has the potential to be really good, as this might mean one less step in a podcast creation process (bypassing manual submission). On the flip side, as a webmaster, I have questions on what I need to do to prevent / remove listings that may accidentally be discovered. In my previous experiments with the Google Search integration (as discussed on Better Podcast Episode 132), I found that a non-listed, non-advertised and non-linked section of GonnaGeek was discovered by Google. This was a “channel” that I had to setup within PowerPress when I converted data from the plugin that was previously used. I’d like to have an easier way to remove this listing, rather than having to modify details on the website-side of things.

With all of that said, for those of you who have been using the podcast function of the Google Search app, you’ll likely find there is little (if any) new here for you to discover. In fact, those of us who had added the “Podcasts” icon to our home screen through the Google Search app, will find that after installing the new Google Podcasts app from Google Play, the two of these (the Google Podcasts app, and the Google Search Podcast icon) will actually launch to the same location. Go ahead, give it a try (at least that’s how it operated for me).

Overall, even though I have significant concerns over the app based on my initial experience, I think that there is real potential benefit to Android having a packaged Podcast app. For potential consumers who have heard of podcasts, but weren’t sure how to get it, this might be the gateway that they need to discover it. Further, leveraging Google’s reach both from the perspective of content indexing, as well as its assistant, offers a massive of potential for discoverability and new use-cases. With that said, I just can’t help but shake my concern of the app centering more around a streaming model, with Download having to be manually done per episode – this is very different than traditional podcast consumption.