In the wake of Google Reader’s demise, we now have many feed-sync services with public APIs, all of which are accumulating users and customers, including Feedly, Feedbin, FeedHQ, Feed Wrangler, Fever, NewsBlur, The Old Reader, BazQux, and probably one or two more that launched while I was writing this sentence and somehow already got added to Mr. Reader.


Mr. Reader v2.0 is available on the App Store.

Backup Your Google Reader Data

As you already now, Google is powering down Google Reader on July 1st, 2013. Please don’t forget to backup your data like mentioned on the Google Reader website. Direct Link to Google Takeout to create the backup. Please do it!

Supported Google Reader Alternatives (June 26, 2013)

Adding Additional Accounts

You don’t have to delete Mr. Reader to add additional accounts:

  1. Tap on your username at top to open the accounts management dialog
  2. Press the “+” button
  3. Select the alternative
  4. Enter your credentials and login

Please have a look at the FAQ too. Thanks!

As I mentioned in my previous blog post it has taken a great deal of work to prepare my code to support multiple Google Reader alternatives. The process involved finding out how to use the APIs in an efficient way, communicating with the developers to improve, complete and fix their APIs, and of course implementing support for the APIs within Mr. Reader.

Free update for Existing Users

I decided against creating single Apps for each alternative service and also against using In-App purchases to enable support for each alternative service. Instead Mr. Reader v2.0 will include support for all of the alternative services added so far (see ‘Supported Alternative Services’ below) and will be free for all existing users. I have taken this approach because it means I will have less work to do in upcoming updates and you can try some or all of the alternatives until you find the one that is right for you.

How to migrate

At a minimum all of the alternative reader services can import your existing RSS subscriptions from an OPML file. You can export your Google Reader data from the Google Reader settings website by using Google Takeout (direct link). Inside the ZIP file that is generated by Google Takeout you will find a file called subscriptions.xml. This is the OPML file that contains your subscription data. There are already a lot of step-by-step tutorials like this one describing how to export your data.

Supported Alternative Services

The following are the alternative services that will be supported in Mr. Reader v2.0. The services are listed in alphabetical order and not in order of preference. Please refer to each of the services respective websites for more information.

BazQux Reader

Website Type Developer Service Vladimir Shabanov

Google Reader compatible API which makes it quick and easy for other Apps to implement support for this service. Hopefully we can expect support across a wide range of platforms in the near future.


Website Type Developer Service Ben Ubois


Website Type Developer Service Bruno Renié

Google Reader compatible API which makes it quick and easy for other Apps to implement support for this service. Hopefully we can expect support across a wide range of platforms in the near future.


Website Type Developer Service DevHD

Feed Wrangler

Website Type Developer Service David Smith


Website Type Developer Selfhosted Shaun Inman

The Fever API does not currently allow you to manage feeds and folders (adding new feeds, renaming folders, moving feeds into folders, etc.). Unfortunately I was unable to make contact with the developer (he’s working on other projects). If you want feed and folder management support please contact the developer and ask him to update the Fever API. I will add this functionality to Mr. Reader as soon as it is available in the API.

Google Reader API Endpoints

The Google Reader API endpoints in Mr. Reader are now editable. This change allowed FeedHQ (Bruno) and BazQux (Vladimir) to test their Google Reader compatible APIs against Mr. Reader. I also added service-specific support to ensure that certain unique aspects of these two services are handled correctly within Mr. Reader. For example:

  • subscribing to feeds
  • whether or not article tagging is supported
  • handling of unread articles that are older than 30 days
  • feeds can only be assigned to a single folder

Supporting alternatives with a Google Reader compatible API is fun and can usually be completed quickly and easily.

Will you support my preferred alternative?

Mr. Reader v2.0 is now code complete. I will consider adding additional alternatives in future updates, but only if the services in question have a Google Reader compatible API (preferred) or an API that is useable (see my previous blog post).

When will Mr. Reader v2.0 be available on the App Store?

It should be available on the App Store, at the latest, one week before Google shuts-down Reader on July 1st, 2013. Apple usually take 7-10 days to review the app (without rejection).

Sorry that there haven’t been any signs of life or App updates from me since my last posts in March. I have been very busy preparing my code to support multiple Google Reader alternatives and, of course, integrating some of those alternatives in to Mr. Reader. I will publish another blog post with more details soon.

This blog post is an introduction to explain some of the problems I have encountered.

All APIs are not equal

Just a few words about the APIs of some Google Reader alternatives and why they cannot be used with Mr. Reader.

This covers - at the time of writing - the APIs of Tiny Tiny RSS, CommaFeed, NewsBlur and others.

Mr. Reader synchronizes data with the chosen RSS service. This means that Mr. Reader keeps the data - depending on your sync settings - in a local database on your iPad. During a sync Mr. Reader downloads only the articles that are not already in the local database and marks items as read and starred, etc. This works with IDs (= numbers) and not with megabytes of data that must be downloaded again and again.

The above APIs are not ready to support the local synchronization approach used by Mr. Reader. They are designed for websites or Apps that behave like websites. Every user interaction results in, just as on a website, a separate server call to fetch the requested data. For example you select a feed and the first 10-20 articles must be downloaded from the server. You scroll down and the next batch of articles must be downloaded. You select a different feed and another download must be done and so on. With APIs like these Mr. Reader is unable to mark an article as read in its local database when the article has already been marked as read on the website. There is just no way to get this information from the API.

Mr. Reader utilises the local synchronisation approach because some functionality requires the data to exist in the local database. For example, once a sync has completed, it’s far more efficient (no more server calls to get the data) and RSS articles can be read without an internet connection.

How to identify an API that is incompatible with Mr. Reader?

  • The API has a call to get the unread count values of folders and feeds
  • The API does NOT have a call to get the IDs of unread, starred, tagged articles only
  • The API does NOT have a call to download articles by ID

Local/Standalone Sync

A quick refresher on running apps in the background in iOS: Once you quit an App it cannot run in the background for longer than ~10 seconds. This can be extended to max. 10 minutes to finalize some cleanup or to finish a long running download. After this time the App cannot do anything. It is suspended until you open it again. This is to save battery life, minimise memory use and to maximise the overall performance of iOS.

Due to these restrictions Mr. Reader is unable to refresh feeds and download new articles when it is not running. Therefore a Local/Standalone Sync approach could be extremely problematic.

I will try to illustrate the problem using an example feed - The Verge (note: this issue is not unique to The Verge; many other feeds work in a similar manner):

  • The ‘The Verge’ feed (RSS = XML file) contains only the last 10 published articles
  • You last synchronised in Mr. Reader one day ago
  • 'The Verge' publishes, for example, 26 new articles since your last synchronization
  • When you synchronize, Mr. Reader will only be able to get the last 10 articles from the feed; the other 16 articles are lost! There is really no way to get them :-(

Server based RSS services like Google Reader, etc. frequently poll feeds for new articles, downloading them and keeping them in their local database. When Mr. Reader is connected to a reader service it is able to fetch all of the articles since its last synchronization, regardless of the frequency of updates or the number of articles published by the feed. No articles are lost.

In my opinion a Local/Standalone Sync approach will not work reliably for most users. The exception is those users who are able to launch the App every one or two hours to download the latest articles, or users who are not subscribed to feeds that regularly publish many articles, or those users who don’t care about missing-out on articles.

Local/Standalone Sync + iCloud

There are still a lot of problems with iCloud and many developers have given up (1, 2, 3) using it. It is just a service to store and synchronise data and not to perform operations like downloading RSS articles.

Apple recommends that only a small amount of data should be synced with iCloud and only data that cannot be recreated. It would be a funny discussion with Apple (e.g. they reject my App) trying to explain why Mr. Reader saves tens or hundreds of MB of article data in iCloud that could easily be downloaded again from the internet. ;-) Also see problems of the Standalone Sync above.

Therefore iCloud would only be useful to sync your subscriptions and settings. But this can only be done between Apps from the same developer and is restricted to iOS and Mac devices.

In January 2013 I received support mails informing me that some articles of The Verge will crash Mr. Reader when using the web view and that Safari works just fine. I wasted hours trying to identify the problem. It seems that the UIWebView (iOS browser component and the only way to display websites) is responsible for the crashes and that Apple’s Safari does not use this black box component in the way 3rd party developers must use it. Very annoying!

Why do I think so? After work I was sitting on the couch reading my news, still thinking about what could be causing the crashes. Then I tried to open the ‘The Verge’ articles in some competitor Apps and those Apps crashed too. Next I opened them in some 3rd party browsers like Google Chrome, iCab Mobile, Grazing, etc. and they all crashed when opening the articles.

I immediately created a bug report for Apple and some weeks later they closed it as a duplicate without any further information.

What happens for you when you open this 'The Verge' article on your iPad in a 3rd party browser like Google Chrome (NOT SAFARI)? If it does not crash immediately, then reload the website and it will crash.

It’s not only ‘The Verge’ articles that are able to crash iOS Apps/Browsers. I’ve found a 'Boing Boing' article that will also crash Safari. Open it in any browser (iPad & iOS 6) and wait until it finishes loading.

Kevin O’Keefe informed me yesterday via Twitter that articles from ‘The Business Journals Digital Network’ also cause the crash. And he is right: Example 1 and Example 2. You can also open the first example article from my Twitter Timeline in Tweetbot or any other Twitter client you are using on your iPad to see it crashing. Of course I’ve already created another bug report for Apple.

I really hope that Apple fixes these annoying crashes as soon as possible.

6 days after Google’s announcement to shutdown Google Reader on July 1, 2013, the support mail wave has subsided back to normal levels. It’s a good time to write down my thoughts and to get a better overview of the current situation and my future options.

Google Reader does nothing?

In the past few days I’ve received some mails from people thinking that Google Reader is just a simple storage of an OPML file (your subscriptions). It is not:

  • Yes, it stores all of your folders and feeds
  • It fetches articles from all of your subscriptions and stores them in a big, big database (for millions of users)
  • It keeps those downloaded articles “forever”. This is also necessary to provide a Google worthily search
  • It records and maintains the unread/read and starred status of every single article in your Reader account. The same when you tag articles
  • It provides an API so that you can use it not only from its web page
  • For API users like me, it handles the different Atom and RSS versions, so that I only need to support a single format
  • It allows me to get articles from a specific date without looking for new articles feed by feed
  • … 

Does anybody have more details about the Google Reader infrastructure?

What makes Google Reader so popular?

  • Everyone with a Google account is able to use it immediately
  • It can be used for free and it has a monopoly without real competition
  • It has a clean and easy to use web page
  • It is fast and reliable. Ok, there were some outages over the last years but what service runs 24*7?
  • There are a lot of Google Reader clients available on all platforms and this without an officially documented API
  • There are web automation services like IFTTT to further process for example your starred and tagged articles

For many people RSS is a synonym for Google Reader. ;-)

What are my possibilities?

  1. I could hope that Google revokes their decision to retire Google Reader on July 1, 2013. There are some petitions like Google: Keep Google Reader Running and Keep Google Reader. But I’m sure that this will not happen. They know that they have a lot of users (very loyal fans) and did it anyway. :-(
  2. Google could open source the Google Reader code and someone else could provide it as an service. I’m not sure if this will be useful, happen or possible, because no one has the infrastructure of Google.
  3. I could provide a standalone solution where everything is stored and processed in Mr. Reader. Fetching new articles will be much slower, because I must look for new articles feed by feed. I must add an OPML import/export. I must do the RSS feed parsing inside the application (multiple RSS and Atom versions). You will lose the possibility to use web based or native clients on other platforms / devices. I must add a sync solution when, for example, I release an iPhone version in future.
  4. Supporting solutions that must be self hosted like Fever or Tiny Tiny RSS. The advantage of these solutions is that they are independent of a provider (except your hosting service). But there are also disadvantages: You must have a web server and install it on your own. Both use their own API, which is not compatible with the Google Reader API. I’ve got both solutions running on my web server. This option is definitely not for everyone, but it is a possibility.
  5. I could implement/provide my own Google Reader alternative (sync solution). Maybe some of my competitors will do this, but I’m not sure if creating another proprietary solution is a good idea. It’s not my business and I’ve got a lot to do until July.
  6. Supporting solutions that provide or will provide a Google Reader compatible API. Some services like Feedly and Digg already announced that their API will be Google Reader compatible. Some guys like Devon Govett already work on compatible backends. This could be hosted by yourself or maybe it gets provided by someone as a service.
  7. Supporting services like NewsBlur, Feedbin, Feed Wrangler, The Old Reader, etc. (there are more than 50 already) that provide or will provide their own API which is not Google Reader compatible. This is cool and easy for them, but it’s not so easy for all the client developers who must support all of these different APIs. This will lead to a big fragmentation problem.

Google Reader has a monopoly in the area of RSS feed aggregators and has virtually created a standard API. Yes, Google did not publish the API or make it an official standard, but hundreds of clients and services use it.

In my opinion all of those Google Reader alternatives should support this API, instead of going the easy way and creating their own. This would be a big win for millions of Google Reader users. Those services will have native clients within a short time-frame across many different platforms and devices. It’s not a big deal for the client developers to adjust the API endpoint. I’ve already changed my code (not uploaded yet) so that the API endpoint can be edited like suggested by Marco (Instapaper developer). Yes, I already hear your feedback that some alternatives provide many additional and awesome features. But do we really need features like ‘folders in folders in folders’ like those implemented in, for example, Tiny Tiny RSS?

Are you the creator of an RSS feed aggregator? There is no reason to fear competition if you support the Google Reader API. People will choose your service because of you, your extras, your modern web page, your great community, your awesome support, your reliable and fast servers.

In short there must be a standard protocol and this should be the Google Reader API. I and for sure all the other Google Reader client developers don’t want to implement hundreds of different APIs to support all RSS feed aggregators available now and in future. Creating a new standard protocol (API) that could be used by all services and clients would be desirable. But who should do that?

There are a lot of Google Reader alternatives that could be supported and I’m sure that we will see the “winners” over the next few weeks and some completely new will appear on the market.

Please keep in mind that you still have 3.5 months time to switch. Of course I must decide a “little bit” earlier to implement it. ;-)

I already contacted Feedly by mail because of their announcement to create a Google Reader compatible API.

The Fever developer works on a game instead of using this advantage. It has a incomplete API (no feed and folder management etc.), looks outdated and IMO the sync is a little bit slow. His statement.

The Old Reader has no API yet, but they are working hard to provide it ASAP. Hopefully as a Google Reader compatible API.

Marco (Mr. Instapaper) has a good idea that I will support, so that services can test their Google Reader compatible API by using Mr. Reader.

There are a lot more infos … It just needs some time and a decision should not be done a day after Googles bad info.

Google: ‘Don’t be evil’ … I still can’t believe what Google did. :-(

Please sign this online petition: Google: Keep Google Reader Running.

I’m sceptical about the success of this petition, but it’s worth a try.

I’m an inbox zero freak, just checked my inbox and wondered what’s going on. It was immediately clear to me that Google retires my beloved Google Reader on July 1, 2013. :-(

Sure, there were rumors since years that it will be the next service that gets killed by Google, but I never thought (hoped) that this will happen so soon. I’m shocked!

The official links to this WTF announcement:

P.S. I’ve just created this blog and this info was published on March 14, 2013 on Twitter and Facebook.