FWIW when web team implement T403073: Reading List Phase 2 - API endpoint to get all list items the apps can be updated to use this API to address this issue.

Most important change for Apps is that articles added to the general list on Web are represented in the general list on Apps. We need to make sure this is happening before reading lists is released on Web

@HFan-WMF Hi Hsuanwei, when is the estimated release for reading lists on Web?

Hi @HNordeenWMF! The initial experiment launch will be week of Nov 10 on 5 smaller wikis (fr/ar/zh/id/vi) and week of Nov 17 for English. However, the initial experiment excludes logged in readers who already have saved articles from apps because we have not implemented syncing from Apps to Desktop just yet. You can see the full criteria for experiment eligibility in the task description here: https://phabricator.wikimedia.org/T405259

Before we launch to a wider audience, we will be working on syncing the saved lists from users on the apps to be visible on the desktop, though. (That's phase 2 for us; phase 1 is just this initial experiment to gauge usefulness/interest on desktop)

Ok thanks @HFan-WMF ! Sounds great, so this task is only required for phase 2.

The API is now live on the beta cluster and ready for you to use in iOS! It will ride next week's train deployment so should be in production wikis from 16th December:

https://en.wikipedia.beta.wmcloud.org/w/index.php?title=Special:ApiSandbox#action=query&format=json&list=readinglistentries&formatversion=2

To clarify the current situation:

• Currently we do not show reading list feature on web to users that have created reading lists on apps. On web, we only save to the default list.
• In future web will support the ability to save to lists other than default list. It will also expand to include app users.
• When this happens, as users use the reading list feature on web, if they also use iOS their lists on iOS will become outdated and out of sync e.g. this bug will become more common.
• On web there will be no disruption. Reading lists updated on apps will instantly appear in web. For a smoother roll out ideally we'd address this bug prior to the web launch. If we don't you will be getting more bug reports.

@HFan-WMF will reach out to you @HNordeenWMF to discuss!

Thanks! Next steps: Apps team pick this up in January/February, and fix the bug using the new API.

• Best case scenario: we get this fixed before the Beta release of saved reading lists to all users, planned for February 2026.
• If we don't fix this before the beta release, iOS app users with Syncing turned on will have a slightly more buggy experience. We already have this problem from Android, we're just adding Web as another platform to contribute to the bug.
• The amount of iOS users affected depends on how wide the Beta release is, and how many logged-in users opt-in to beta and syncing.

I'm thinking 5 or 8 points for this one.

My approach is to refactor SavedArticlesCollectionViewController away from NSFetchedResultsController and towards using UICollectionViewDiffableDataSource. This gives us an opportunity to dedupe the data before it is displayed on screen. This is essential because "All articles" is set up to display ReadingListEntry objects, of which multiple can be assigned per article (if it is assigned to multiple lists). When I update SavedArticlesCollectionViewController to display ALL articles from multiple lists, I start seeing duplicates articles (if they belong to multiple lists). Deduping unfortunately is impossible without moving away from NSFetchedResultsController. UICollectionViewDiffableDataSource allows us to preserve animations and keep inserts / deletes / updates fairly stable. Unfortunately diffable data source doesn't work well with our indexPath-based APIs, which the rest of our reusable editing logic for swipe to delete and edit modes relies on. So this is turning into a Large effort to work around those index path dependencies.

If we decide this refactor is not worth it and we should instead move to SwiftUI, that would be an XL effort, as it is essentially rewriting the entire UI layer of the Saved tab.

Progress is in reading-list-fix-tinkering branch.

Re-checked the steps on enwiki wmf.7 and iOS app (when testing T403073: Reading List Phase 2 - API endpoint to get all list items) - the issue is still present as described.