I think the even bigger point is it's never ok to organize data in a way that removal of the UI leaves you with no access to the data at all, even though you could use another tool to do UI if only the vendor gave you proper access to the data. E.g. if Apple stored their RSS feeds, say, in OPML - migration would be easy. If they exported the feed to OPML on upgrade - migration would be not very hard too. Since Apple did everything the wrong way there, the user had to use 3 tools and spend hours of manual work to get her data back.

This is especially bad coming from the company that is known for their neglect to BC and overhauling UIs in most radical way. Their developers must have known the possibility of UI change exists - and still stored the data in a format that turns this possibility into a major problem for the user.

Compare, for example, to Firefox that stores bookmarks in HTML(-like) file. If ever something happens to Firefox project or their bookmark functionality, I can always take the HTML and get the info out with the simplest of tools, and probably I won't have to, since these tools would already exist - since the format is easy to use.

I don't think Firefox has stored bookmarks in HTML since the bookmark and history systems were unified in Firefox 3. Now they're stored in a single SQLite database. The schema is sensible, so it's easy enough for a programmer to work with, but it doesn't have the automatic portability/transparency of a text-based format like HTML.

The article goes on to say that the data wasn't removed - only the feature. Regardless, Apple should've provided a simple migration path for those that DID use the RSS feature rather than just assume they had the knowledge to find and export the data manually.