The context
A press group publishes a TV listings magazine and extends it with a mobile application: the channel grid, programme details, and articles from the newsroom.
The application already existed. It had been built with Cordova and Angular — a website wrapped in a native shell, a very common approach in the mid-2010s. It worked, it was in production, and it had reached its limits.
The challenge
This is a situation many companies find themselves in without knowing how to get out of it: a hybrid app that has aged well functionally and badly technically.
The symptoms are always the same. Scrolling a dense programme grid lacks the smoothness of a native application. Every iOS or Android release becomes a risk, because the wrapper layer depends on components that are no longer truly maintained. And the ecosystem’s libraries are drying up.
Two bad answers are common here:
- Do nothing, until the day an OS update breaks the app and it has to be rebuilt in a hurry, with no budget set aside.
- Start from scratch, with a new application, a new store identifier, and the loss of all history — reviews, ranking, existing installs. Users have to download it again. Many never do.
So the real objective was not “rewrite the application”. It was to rewrite the application without the user noticing.
What we did
A complete rewrite in Flutter, with a layered architecture — a technical core (networking, storage, theming), features isolated from one another (TV grid, news, search, programme details, settings), and a shared layer. Nothing exotic: a structure another developer can pick up without a manual.
Version continuity. The last hybrid release was numbered 3.1.8; the first Flutter release shipped as 3.2.0. From the store’s point of view and the user’s, it is one more update — not a new application. History, reviews and the installed base are preserved. That detail is what separates a successful migration from one that costs you your user base.
Reading comfort, which was the whole point of the project:
- Local caching of schedules, so the app opens on content rather than a spinner
- Network request caching, so nothing unchanged is fetched twice
- Progressive loading placeholders instead of blank screens
A content back-end, built in Java, made of separate services:
- A TV schedule enricher, completing raw channel data with additional information — including recommendations sourced from streaming platforms
- An article aggregator, pulling the newsroom’s output into the application
The application is published on both the App Store and Google Play.
The outcome
A native application, maintainable with today’s tooling, delivered in continuity with the one it replaces.
If there is one thing to take from this project, it is this: the hard part of a technical migration is almost never technical. Rewriting code is a solved problem. What takes method is doing it without making users pay for the transition — keep the identifier, keep the numbering, keep the habits, and make visible only what improves.