Previously: Why I’m Building My Next App in Public (Part 1)
In my last post, where I explained that I would be building my next app in public, I concluded by saying that it would be an RSS reader. So, I figured that if I am going to build an app in public, and explain all the decisions I am making, I should start with: why an RSS reader?
This app, for me, has been a long time coming. I bought my first Mac in 2006, where I used an RSS reader for the first time. I believe my app of choice was NewsFire by David Watanabe. As I learned Cocoa development, I dabbled with building an RSS reader. I then transitioned to iPhone development, once it was introduced several years later, and over the years since, have built several RSS readers in my spare time. I think I always imagined launching them on the App Store, but never dedicated the time or effort to complete them.
So, I’m not starting this project from scratch. I am code-wise, and concept-wise, but I’ve amassed a great deal of knowledge and experience building RSS readers over almost twenty years. I thought it was important to be honest about this.
A Brief Interlude
RSS was created in 1999. Google Reader launched in 2005, which had an official/unofficial API that allowed many client apps to be created that synced with the service. In 2013, Google sunset Reader. Google stated that there was a dedicated but declining user base. I can imagine that that was true — even if it wasn’t the real reason — as many people had started to get more and more of their news from social media. Specifically Twitter, in the case of the kind of people who used RSS readers.
It’s now 2025, and our relationships with Google, X/Twitter, and other major technology companies, including Apple, are very different. Especially since the 20th of January.
There is a growing sentiment towards being less reliant on centralized, commercial service providers, and building more for the open web. As well as a growing exhaustion toward the sensationalized content / presentation of social media.
And We’re Back
It feels like RSS is now more popular than ever. Or perhaps, the enthusiasm towards RSS is greater than ever. And there are many RSS readers available, on all platforms. So, why build another one?
Over my two decades in the industry, I’ve often seen a prevailing belief that there is one correct way to do any given thing. And this, typically, translates into very opinionated software. This is not good. Nor is it bad. It just is. The result, though, is that for any given category of software there will often be a plethora of choices, all quite different. To the extent that they can be within a particular problem domain.
And yet, as an industry we rarely acknowledge or accept this disconnect. How can there be one way of doing something and a plethora of different, successful apps for that something?
When Steve Jobs introduced the iPhone, he explained Apple’s thinking about the smart phone market, and Apple’s different approach. He said that the problem with most smartphones was the bottom half, which contained the hardware buttons. You can’t change them for each app’s particular needs.
Any yet, most software, including Apple’s, is very rigid in its user interface or user experience. And I don’t believe that’s how things have to be, it’s just how they are. I want to explore to what extent a piece of software can be everything to everyone, within a particular problem domain. Not in the abstract. Not as a generalized theory. But actually.
Can I, or one, build an RSS reader whose UI and UX can effortlessly scale with the user’s preferences and needs? It seems that it’s difficult, if not impossible, to make hardware that is modular and elegant. But, is that true of software, where through code, we can dynamically change anything and everything?
I’m open to the possibility that this idea could fail spectacularly. But I don’t care. My curiosity to try and to learn, outweighs any fear I may have about failing. In public.
And even if the idea fails, I still could create an excellent piece of software in the process.
Or not…
What’s Next?
So, what exactly is my vision for the feature-set and design/architectural ideology? I’ll write more about that next time.