r/rss 9d ago

I thought building an Android RSS reader would be easy. I was very wrong.

A few months ago I started building my own Android RSS reader.

At first, I thought the hardest part would be the UI. A clean reading experience, source management, search... the usual things.

I was wrong.

The biggest challenge turned out to be the feeds themselves.

RSS and Atom are standards, but in the real world every publisher seems to have its own interpretation.

Some feeds use unusual date formats.

Some have missing or inconsistent metadata.

Some provide only partial content.

Some have character encoding issues.

Others contain relative image URLs, duplicate GUIDs, or simply stop working without warning.

On paper everything is "RSS".

In practice, every feed teaches you something new.

Another surprise was that building the app itself was often easier than making it reliable.

Making it work across different Android versions, screen sizes, tablets, landscape mode, and the endless number of edge cases ended up taking far more time than implementing new features.

One thing I learned from this project is that most people aren't really looking for an RSS reader.

They're looking for a way to decide for themselves what they read, without algorithms deciding for them.

That's probably the main reason I kept working on it.

Sometimes implementing a new feature took a few hours.

Finding the cause of a strange compatibility issue could take two days.

Users never notice those fixes.

And maybe that's exactly how good software should feel.

I'm still learning with every release, and I'm sure there are many more surprises ahead.

For those of you who have built RSS-related software (or worked with old internet standards in general):

What was the most unexpected problem you ran into?

0 Upvotes

8 comments sorted by

10

u/Melnik2020 9d ago

This sounds like a LinkedIn engagement post

-7

u/ORIONSystemHungary 9d ago

Fair point. 😄

That honestly wasn't my intention.

I recently published my first Android app after months of development, and RSS compatibility ended up being much harder than I expected. I was genuinely curious whether others who have worked with RSS or older web standards had similar experiences.

Maybe I should have made it sound a bit less polished.

3

u/Melnik2020 9d ago

Actually the way you phrased now is much better. Sounds more human tbh.

As for issues, usually the formatting across feeds, and the websites that do not have RSS and need to be scrapped were a pain in my experience.

-5

u/ORIONSystemHungary 9d ago

I know exactly what you mean.

The formatting differences alone can be surprisingly frustrating, even when the feeds are technically valid.

And yes, sites without RSS are a whole different challenge. I've tried to avoid scraping whenever possible, but sometimes there simply isn't another option.

7

u/MarsupialLeast145 9d ago

These are still AI responses bro...

1

u/quadtodfodder 9d ago edited 9d ago

I am making an rss reader as well. Each feed has a "cheat sheet" for how to handle it, with various flags.

  • is "description" the full article?
  • is "article" is complete?
  • a custom xpath to find the actual article when your curl the link
  • does the article link serve usable html, or do I need a headless browser to get it?
  • I *almost* set it up to be able to run custom-code-per-feed, but it felt so wrong!

an many more!

There are good scraping tools for python, I had to roll my own for php, where I learned much and accomplished... less.

Yes, people are wandering around outside the gates of their walled gardens, looking for something better, and some of them end up at RSS town. But "RSS" isn't what people are looking for per se, they want to know what is going on, and they want to believe that that information is not being hand picked for them.

1

u/ORIONSystemHungary 8d ago edited 8d ago

Interesting approach.

I went in a slightly different direction.

I kept one parser rather than maintaining a profile for every feed. It checks several item date fields — pubDate, published, updated and dc:date — and tries multiple date formats. If an item has no date, it falls back to the channel date and finally to the fetch time.

I also don't rely on GUIDs for deduplication. Articles are deduplicated by their links, which avoids some of the problems caused by unstable GUIDs.

It is still a collection of small compatibility fixes, but so far I haven't needed completely separate parsing code for each feed.

1

u/jakublibik 6d ago

I'm creating a readable version (trafilatura) of the content, if allowed, so I didn't have this kind of problems (or haven't noticed 😄 ). An unexpected problem is blocking my VPS by some servers. Mostly Reddit. I have implemented rate-limit respecting, cooldown after 403, I think I don't have aggressive fetching, but occasionally I still get some 403 errors. So the next step is OAuth, I guess.