# Design a Mobile Read-It-Later App

Source: https://www.techinterview.org/post/3233475181/design-mobile-read-it-later-app/
Updated: 2026-07-26 · techinterview.org

Read-it-later apps (Pocket, Instapaper, Matter, Readwise Reader) save articles for later consumption — stripped of ads, formatted for reading, available offline. The interview tests whether you understand article extraction, offline-first sync, and the polish that distinguishes serviceable from delightful.

## Functional requirements

- Save an article via share sheet, email, or browser extension

- Strip ads, navigation, sidebars

- Format for reading (typography, dark mode, spacing)

- Read offline

- Tag and search

- Sync across devices

- Optional: text-to-speech reading

## Article extraction

The hardest technical challenge. Strategies:

- **Mercury Parser / Readability:** heuristic algorithms that detect article body. They score DOM nodes by text density and link ratio, run fast and cheap, and handle most blog and news layouts — but they break on unusual markup, so treat them as the default path, not a guarantee.

- **Server-side rendering:** fetch the page, run extraction, return clean HTML. Centralizing extraction lets you cache one clean copy for every user and fix parsing bugs without shipping an app update; the trade-off interviewers probe is that your servers now fetch on users' behalf, which raises rate-limiting, IP-reputation, and cost questions.

- **LLM-based:** modern approach; passes the page to an LLM that extracts the article. It handles messy or novel layouts that heuristics miss, but it's slow and costly per article, so reserve it as a fallback for pages where Readability returns garbage rather than the primary path.

Most apps use server-side extraction. On-device is too costly per article.

## Storage

Per article:

- URL, title, author, publish date

- Extracted body (HTML)

- Hero image (cached)

- Tags (user-applied)

- Read status

- Highlights and annotations

Stored in local SQLite for instant access; synced to server.

## Offline reading

On save:

- Server extracts article

- Client downloads extracted body + hero image

- Stored locally for offline access

Saved articles accumulate (~50KB each typical). Cap library size; offer manual cleanup.

## Reading UI

Best practices:

- Generous typography (16–18pt body)

- Adjustable font size, family, theme (light/sepia/dark)

- Single-column layout

- Progress bar showing time remaining

- Tap to scroll to next page (some apps)

## Highlights and annotations

Like a Kindle:

- Long-press to select text → highlight

- Add a note

- Color-coded highlights for category

- Sync to server; available across devices

- Export highlights to Notion, Obsidian, Readwise

## Tag and search

- User-applied tags

- Auto-tags via ML (topic detection)

- [Full-text search](/post/3233461821/database-indexing-interview-guide/) via local FTS5

- Filter by source, date, read status

## Text-to-speech

Modern apps offer TTS for articles:

- iOS: AVSpeechSynthesizer or third-party (ElevenLabs)

- Android: TextToSpeech

- Background playback works like a podcast

High-quality TTS makes articles audio-consumable. Hot feature in 2026.

## Sync

Per-device library + cloud master:

- Device adds article → uploads to cloud

- Cloud [notifies other devices via push](/post/3233474168/system-design-twitter-news-feed-timeline-fanout-on-write-fanout-on-read-celebrity-problem-ranking-caching/)

- Other devices download

- Read state and progress sync (similar to Kindle position sync)

## Browser extension

The primary save mechanism. Extension hits a save endpoint on the server. Server fetches and extracts; client gets it on next sync.

## Email-to-save

User forwards a newsletter to a unique email address. Server parses the article and adds to library. Common feature for newsletter consumers.

## Common gotchas

- Paywalled articles — strip behind paywall fails. Extraction only sees what the fetch returns, so a gated article yields the teaser, not the body. Interviewers want you to say you won't bypass the paywall — instead save the URL and preview, and extract from the client's already-authenticated session when the user is a subscriber.

- JavaScript-heavy pages — server extraction misses content. Single-page apps render the body client-side, so a plain server fetch gets an empty shell. The fix is a headless browser (Puppeteer or Playwright) that runs the page's JS before extraction, at the cost of far higher latency and memory per save.

- Multi-page articles — only first page extracted. Detect "next page" pagination and stitch the pieces together, or prefer the site's print/reader-view URL, which usually serves the whole article on one page.

- Image-heavy articles — local storage explodes. Downscale and re-encode images to WebP on the server, lazy-download anything below the fold, and enforce per-article and per-library caps with eviction so one photo essay doesn't fill the device.

## Frequently Asked Questions

### Why did Pocket lose ground?

Mozilla acquired Pocket; product slowed; competitors (Readwise Reader, Matter, Omnivore) shipped faster. Sometimes the sale is the death.

### How do I handle a user with 1000+ saved articles?

Pagination, filters, search. Auto-archive after 6 months unread.

### What about audio articles?

Some apps generate TTS audio on save; let user listen during commute. Storage hit but valuable feature.