How to Make an App Like Pocket

Building a read-it-later and content-curation app is harder than it looks. The interesting parts are not the bookmarking itself but the parsing pipeline, the offline sync architecture, and the recommendation layer that keeps users coming back.

---

Pocket has roughly 30 million registered users and processes millions of URLs per day. If you're thinking about building something in the same space, here is what the engineering actually looks like.

What Does a "Pocket-like" App Actually Need to Do?

Strip away the UI and the core job is: take a URL from anywhere, extract the readable content, store it reliably, and serve it back on any device, including offline. That sounds simple. The edge cases are not.

Web content is structurally chaotic. A single article URL might return an AMP page, a JavaScript-rendered SPA, a paywalled response depending on the User-Agent, or a redirect chain ending in a PDF. Your parser has to handle all of these. Pocket uses a custom extraction engine. Mozilla's Readability.js (the library behind Firefox Reader View) is the closest open-source equivalent and a reasonable starting point.

Beyond parsing, you need:

• Sync across devices with conflict resolution
• Offline storage on iOS and Android
• Push notifications for digest features
• Tagging and search at scale
• A recommendation engine (optional at v1, expected by v2)

The app is deceptively content-platform shaped. Plan your data model early.

How Does the Content Extraction Pipeline Work?

This is the part most engineers underestimate. The pipeline has at least four stages.

Fetch

You cannot rely on the client to fetch the HTML. Paywalls, CORS restrictions, and JavaScript-heavy pages mean you need a server-side fetch layer. For straightforward pages, a plain HTTP GET with a reasonable User-Agent string works. For JS-rendered pages, you need a headless browser. Puppeteer (Node.js) or Playwright are the standard choices. Playwright's multi-browser support makes it preferable if you are testing fidelity across rendering engines.

Puppeteer/Playwright instances are expensive to run at scale. Pool them. A queue-backed worker pool with 10–20 instances handles moderate traffic without ballooning costs.

Parse and Extract

Once you have the raw HTML, pass it through Readability.js or a comparable extraction library. The output is the article title, body text, a lead image, author, and estimated read time. Readability works well on article-structured pages. It struggles with recipe sites, product pages, and anything with heavy visual layout. You will need custom extractors for high-value domains where Readability fails.

Store the extracted text, the original HTML, and the parsed metadata separately. You will want the original HTML later for re-parsing if your extractor improves.

Normalise and Enrich

Clean the extracted HTML. Strip tracking parameters from embedded links, re-host images through your own CDN so they are available offline, and resolve relative URLs. This step is where you control the offline experience. If an image 404s later on the origin server, your CDN copy survives.

Add metadata: word count, reading time estimate (250 words per minute is the standard baseline), primary language, and canonical URL.

Index for Search

For full-text search, Elasticsearch or OpenSearch are the production-grade options. PostgreSQL's tsvector is adequate up to a few million documents and removes an infrastructure dependency early on. Switch when query latency becomes a real problem, not before.

What Does the Sync Architecture Look Like?

Pocket's sync model is eventually consistent. Users expect offline reads and offline saves to reconcile correctly when connectivity returns.

The standard approach is an event-sourced sync log. Every save, archive, delete, and tag change is an event with a timestamp and a client-generated UUID. The server applies events in order. Clients send their local event queue on reconnect. Conflicts (the same article archived on two devices while offline) are resolved by last-write-wins on the server, which is acceptable for this use case.

On mobile, SQLite is the local store. On iOS, use Core Data or GRDB.swift over raw SQLite. On Android, Room (which wraps SQLite) handles migrations cleanly. Both platforms cache the extracted article HTML locally so the reading experience works fully offline.

Sync frequency matters for battery. Use silent push notifications (APNs on iOS, FCM on Android) to trigger a sync rather than polling on a timer. This reduces background battery usage significantly without sacrificing freshness.

How Do You Build the Recommendation Engine?

At v1, don't. Personalised recommendations require enough user interaction data to be meaningful. Below a few hundred thousand active users, a curated editorial feed and basic "similar articles" based on tag overlap will perform comparably to a trained model, with a fraction of the infrastructure cost.

When you do build it, the architecture is straightforward at this scale:

Signal	Weight
Save rate for a domain	High
Read-to-completion rate	High
Tags the user applies	Medium
Time spent on article	Medium
Share/send actions	Low

A collaborative filtering model (Matrix Factorisation via Implicit or LightFM) trained weekly on interaction data is a reasonable v2 starting point. Run inference offline, cache recommendations per user in Redis, and serve them from cache. Real-time inference is unnecessary and expensive here.

For content discovery (surfacing new articles, not just saved ones), you need an ingestion pipeline separate from the user-save pipeline. RSS feeds, partner APIs, and social sharing signals are the common sources.

Mobile Architecture: Flutter vs. React Native vs. Native

For a content reading app, native is defensible. The reading experience depends on text rendering, scroll performance, and offline storage, all areas where native gives you the most control.

That said, Flutter is a practical choice if your team is cross-platform. Flutter's text rendering is consistent and fast. Its SQLite access via drift (formerly Moor) is mature. The trade-off is a larger binary size and occasional friction with platform-specific APIs like Share Sheet on iOS.

React Native has improved significantly with the New Architecture (JSI-based, available since RN 0.71), but text-heavy scrolling still has edge cases on older Android devices. If your target demographic skews toward mid-range Android, test thoroughly before committing.

If you go native, Swift + SwiftUI on iOS and Kotlin + Jetpack Compose on Android represent the current standard. Sharing the sync logic and extraction client as a Kotlin Multiplatform (KMP) library is worth considering if you want code reuse without a full cross-platform framework.

Conclusion

The core technical bets are the extraction pipeline, the sync model, and the offline storage strategy. Get those three right and the rest is product work. Start with Readability.js, an event-sourced sync log, and SQLite on device. Add headless browser rendering when you confirm the simpler fetch approach fails on enough URLs to matter. Defer recommendations until you have real interaction data.

If you want a technical review of your architecture before you start building, or you need a team that has built content pipelines at this scale, talk to us at Sodio.

FAQ

How long does it take to build a Pocket-like app? A v1 with save, parse, sync, offline reading, and basic search takes 4–6 months for a focused team of 4–5 engineers. That excludes a recommendation engine. The extraction pipeline and sync architecture are the longest poles; shortcuts taken there create disproportionate technical debt later.

What is the biggest technical risk in a read-it-later app? Content extraction reliability. The web changes constantly, and parsers break silently. You need automated regression tests that run against a curated set of known URLs and flag extraction quality drops. Without this, user-facing quality degrades without any obvious server error to catch.

How much does it cost to run the extraction pipeline? Headless browser instances (Puppeteer/Playwright) are the dominant cost. A pool of 15 instances on mid-tier cloud VMs handles roughly 50,000 fetches per day comfortably. At scale, caching extraction results by URL and setting a 24-hour TTL reduces redundant fetches by 40–60% for popular articles shared across many users.

Do you need a separate backend for mobile and web? No. A single REST or GraphQL API with device-aware response shaping (returning different image sizes, for example) is sufficient. GraphQL is useful here because clients can request exactly the fields they need, which matters when you are serving both a bandwidth-constrained mobile client and a web app.

When should you add a paywall-bypass feature? You should not. Bypassing paywalls violates the terms of service of virtually every major publisher and creates legal liability. The correct approach is to store what the user legitimately accessed at the time of saving, which is what Pocket does. If the user could read it, you save it. If they could not, you save the metadata only.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.