Amazon's 'Story so far' Recap Feature Reaches US Kindles and the iPhone App First

Amazon has started rolling out its upgraded "Story So Far" recap feature to US customers on Kindle e-readers and the iPhone Kindle app. The classic version of this feature has existed for years, working like the "Previously on..." segments that open a TV episode. It reminds you where a book left off when you return to it after a long break. The new version, announced last year, generates far more detailed summaries, and it is finally shipping.

For anyone building or maintaining reading apps across platforms, the more interesting story is not the feature itself but how Amazon chose to ship it: iOS first, Android later, with no committed date for the second platform.

What actually changed

The old recap was a relatively simple feature. The new Story So Far produces longer, more context-aware summaries of a book's plot and characters up to the point you have read. According to Engadget, the catalog of supported titles currently numbers in the thousands rather than the millions, covering English-language books that customers have either purchased or borrowed.

Access shows up in two places. On a book you have not opened, press and hold the cover and look for a Read Recap button. If a book is already open, tap the three-dot menu in the top right corner to pull up the Story So Far view. Amazon includes a spoiler warning when a recap might reveal something you have not reached yet, which matters because a naive summary of "the story so far" can easily leak plot points from later chapters if the system misjudges your reading position.

You may also need a device or app update before the option appears, which is worth checking if the button is missing.

The platform split developers will recognize

Story So Far is currently exclusive to iPhone on the app side. There is no word on when it reaches Android. This is the part that should feel familiar to any mobile developer maintaining the same product on both stores.

Staggered platform rollouts happen for predictable reasons. A team often has deeper bench strength on one platform, or the iOS codebase reaches feature parity first because of a smaller device matrix to test against. Apple's hardware lineup is narrow and the OS version distribution skews recent, so an iOS feature can ship to most of the active install base quickly. Android's fragmentation across OEM skins, screen sizes, and OS versions stretching back several releases makes the same feature a longer QA effort. When a feature also leans on newer system APIs or on-device compute, the gap widens further.

For cross-platform teams watching this, the lesson is the one that keeps repeating: shared business logic is cheap to port, but the integration surface, the UI affordances like a long-press context action or a three-dot menu item, and the platform-specific testing burden are where timelines diverge. A summarization feature that calls the same backend looks identical on paper across iOS and Android, yet the client work to wire it into each platform's interaction model is what gets scheduled separately.

Where the summaries likely run

Amazon has not detailed the architecture, but the shape of the rollout offers hints. The catalog is limited to thousands of titles rather than every book, which strongly suggests the recaps are generated server-side and cached per title and reading position rather than produced live on the device. That design choice has clear trade-offs.

Server-side generation keeps the heavy model off the e-reader, which is sensible given that Kindle hardware runs modest processors and prioritizes battery life over compute. It also lets Amazon curate quality, apply the spoiler-detection logic centrally, and expand the catalog by reprocessing books rather than pushing model updates to millions of devices. The cost is that coverage is gated: a book has a recap only if Amazon has processed it, which explains the "thousands not millions" figure.

An on-device approach would flip those trade-offs, offering universal coverage for any book you own but demanding far more local processing than a Kindle can reasonably provide. The middle path, doing this work on a phone's neural engine, is technically feasible on modern iPhones but would fragment the experience between hardware Kindles and the app. A consistent server-backed feature across both surfaces is the more maintainable engineering decision, and it matches what shipped.

What to do if you build something similar

If you are shipping an AI summarization feature into an existing reading or content app, the Kindle rollout maps to a few practical considerations. Decide early whether generation is server-side or on-device, because that choice cascades into catalog coverage, offline behavior, and per-platform parity. Treat spoiler or context boundaries as a first-class correctness problem rather than a polish item, since a summary that reveals too much is worse than no summary at all. And plan the cross-platform rollout honestly: if iOS ships first, communicate the Android timeline internally so the second platform does not become an open-ended backlog item.

For now, US Kindle and iPhone owners can start using Story So Far today, assuming their device is updated. Android users, as is often the case, are left checking the changelog and waiting for a date that has not been set.