Design a Mobile Read-It-Later App

Updated July 26, 2026 · 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 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
• 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.