Flutter is no longer being tested only in mobile apps. As teams deploy it across web, TV set-top boxes, fintech products, and consumer fitness platforms, the bigger question is no longer whether it can run across environments, but how far it can scale without breaking performance, architecture, or developer workflows.
That shift changes the conversation around cross-platform development.
It is not just about sharing code between screens. It is about designing systems that can handle constrained hardware, large codebases, migration risk, and very different user interaction models while still moving fast.
Hashem Abounajmi, Senior Flutter Engineer at Sky (Comcast), has worked across that range firsthand. Based in the UK, he has deployed Flutter across mobile, web, TV set-top boxes, fintech, and consumer fitness products. He also speaks at Flutter London and mentors developers through the GDG London Flutter DevCamp. In this conversation, he reflects on pushing Flutter beyond mobile, building architecture that scales, solving hard technical problems, and working as the sole developer on a product used by more than 100,000 people.
1. You’ve deployed Flutter across mobile, web, TV set-top boxes, fintech, and consumer fitness products. How did you first get into Flutter, and what made you go all-in on it?
Hashem Abounajmi:
It was 2018. I came across an article on Medium which introduced a new cross-platform UI framework with native performance called Flutter. I looked at its official page and tried it out. It was promising compared to UIKit and its slow speed of UI development. Initially I had a bias towards iOS, but as I moved on with Flutter, I found that all these frameworks and languages are just tools to build products that solve real users’ problems – and Flutter accelerates that view.
2. You’ve worked across very different sectors. What stays consistent in how you approach products, regardless of industry?
Hashem Abounajmi:
I think of all these product-oriented apps as a compilation of smaller sets of features which can be developed separately and combined together to achieve the bigger shape. That’s what led me to modularity and applying related software development patterns around it.
When working with a large team, by training everyone on those patterns, we could bootstrap the team and enable parallel development of features, which accelerated product readiness. Another practice I always follow: I start each project with an automated continuous delivery setup so stakeholders can see the product evolving every day. Involving them early creates a closed feedback loop and makes sure the product is steering in the right direction.
3. Flutter is still commonly associated with mobile. You’ve pushed it into TV set-top boxes. How does that actually work?
Hashem Abounajmi:
TV set-top boxes are cheap, resource-constrained devices that use RDK – a collection of software components running on a Linux kernel to handle hardware. RDK doesn’t have an official Flutter embedder. Flutter has Linux support, but the official embedder targets desktop Linux, not lower-level RDK.
The thing is, Flutter’s architecture allows it to run on virtually any hardware if you provide a custom platform embedder. The embedder acts like “glue” code that the Flutter engine needs to function – surface management, input handling, event loop. By writing that glue code, we’re able to run the same Flutter app on RDK with customised UI and TV remote as another mechanism of navigation.
4. What do developers usually underestimate when they try to bring Flutter to non-mobile platforms like TV?
Hashem Abounajmi:
The most important thing is that the UI has to follow TV navigation guidelines to ensure it’s accessible, predictable, and remote-friendly. Just because you can run the same code on different platforms doesn’t mean the app is interactable the same way as a mobile app.
The streaming app we were building had a rich scrollable UI with tons of images – it had smooth scrolling on low-end mobile devices, but poor performance on RDK. The frame rate was roughly around 30fps and our goal was 60fps. We had to reduce the load on the raster thread by flattening the widget tree as much as possible, avoiding costly widgets like Clipping and Opacity, using WebP image format for faster rendering and less memory footprint.
We even had an end-to-end test sampling average frame rate across multiple runs on RDK to make sure we weren’t regressing performance with every code change. Basically, we had to squeeze every bit of optimization to retain the desired performance on RDK.
5. You built a custom navigator to solve memory crashes on TV hardware. What was happening, and how did you fix it?
Hashem Abounajmi:
In the streaming app, users can browse content indefinitely – tapping each piece of content, viewing details, then browsing recommended content shown on that page. The user can traverse infinitely.
We observed on TV that because we displayed large amounts of images, there was a rapid memory spike when users navigated a few pages. After roughly 10 nested page navigations, the app was crashing on the set-top box with an out-of-memory exception.
To bypass that, we implemented a custom navigator which tracked the user’s navigation history and always kept two pages in memory: the current one and the previous one. When the user navigated back, the navigator would lazy-load the page before the previous one, inflate it in memory, and make it available for display. That way we retained the browsing experience while bypassing the memory limitation.
6. You’ve worked on Flutter codebases with more than 45 developers and over a million lines of code. What starts to break first at that scale, and why does modularity matter so much?
Hashem Abounajmi:
When working with a large team, the immediate issue is inconsistency of developers’ contributions and ineffective code review bottlenecks, which affects their autonomy and developer experience.
So we ran a series of workshops and agreed on patterns for common scenarios – how to keep UI dumb, data feeding, unidirectional data flows, in-module and cross-module navigation, reusable components. Most of these were known challenges across different projects. The goal was getting everyone on the same page and controlling the level of isolation between teams and modules.
We formalized this using code generation tools to generate templates so components were “wired up correctly” with a single command. The result was remarkable – instead of stepping on each other’s toes, we saw a rapid increase in contribution, autonomy, and fast PR merges because the code was already reviewed during pairing sessions.
Modularity is the key of software. It doesn’t mean having many packages – it means defining boundaries. Boundaries give you isolated change, and isolation means single responsibility. It helps break down a complex problem into smaller parts, and by solving the smaller ones, the bigger problem is solved.
If I map that to Tide, we decomposed the app into multiple smaller parts with a specific purpose. Each functional team took ownership of specific features – user acquisition, payments, support, design system – and started implementing by pairing and following common practices.
7. Can you share examples of the kind of technical problems that forced you beyond the standard Flutter approach?
Hashem Abounajmi:
I came across an animated interactive onboarding challenge from the design team – they wanted to present app features as the user scrolled through pages. Initially there was an attempt to do it purely in Flutter, but it wasn’t easy to get right, especially when it needed to scale and adapt for different screen sizes. At that time I had some experience with the Rive animation engine, so I brought the idea to life using Rive and presented it to the team. Later I shared that challenge in my Flutter London talk. I follow rule number 8: use the right tool for the right job.
I’ve done a few native app migrations to Flutter, and the riskiest part is always preserving user cached data and making it available after installing the new version. The challenge was that Flutter’s shared preferences plugin reads and writes primitive values prefixed with “flutter”, and the native deserialized objects weren’t supported by the plugin. I had to create a custom solution to bypass that limitation and cover it with end-to-end tests to make sure data was accessible in Flutter, then push it to the cloud.
8. You’ve also done DRM integration in Flutter for offline video playback. What makes that kind of work especially sensitive?
Hashem Abounajmi:
Both iOS and Android have content protection systems that encrypt video files and ensure playback only occurs on authorized devices. We had full in-house video player frameworks using FairPlay on iOS and Widevine on Android, capable of playing DRM and non-DRM content like trailers, with download capabilities. We had to write plugins to use those players from Flutter.
There’s a niche challenge here: users may have plenty of downloaded content, and if we fail to migrate the user session correctly, those downloads get automatically removed by the player. So we had to be very careful that user sessions remained valid after the Flutter migration to retain the user experience.
9. You were also the only mobile developer on a product used by more than 100,000 people. What did that teach you, and how does it shape the advice you give others?
Hashem Abounajmi:
The advantage of being solo is you’re in control of decision-making – you can learn and practice different development processes in depth. But every feature, every bug, post-release monitoring is on you. You have to take the full burden. Having a huge user base gives you the impression that your code has an impact on a mass audience. So I have to make sure changes don’t break anything, I have to cover them with tests, and the architecture has to support those tests.
You have a great opportunity to learn by doing the entire cycle of design, development, release, and monitoring by yourself. Build your foundation by applying software design principles: KISS, SOLID, YAGNI, and DRY. Tools and frameworks change rapidly, but principles remain forever. Then try to automate repetitive tasks – initially you think you can test or release manually, but after a while it becomes boring, tricky, and that’s when bugs and flakiness show up. Tests automate your manual validation. Having CI helps chain automated tasks like build, test, release. Automation increases your confidence and peace of mind.
10. You speak at Flutter London, mentor through the GDG London Flutter DevCamp, and publish technical articles. Looking ahead, where do you think Flutter is heading next, and what’s next for you?
Hashem Abounajmi:
For me, the best way to learn is by teaching. It helps you deeply understand a topic because you have to prepare and try to simplify something complex. Community involvement helps showcase your skills, builds a personal brand, and grows your network.
For me it’s a lot when I see that I’ve had a good impact on people’s lives.
Flutter ignites the idea of what cross-platform really means – run everywhere, not just mobile or desktop. We already see big companies like LG using it on TV, Xiaomi for their electric vehicles and smart home devices. Another major focus is supporting agentic UI, which means the UI can adapt based on user intent instead of having rigid, pre-built interfaces.
Continuing to train and prepare junior developers for the job market and helping them land their first role is my main goal. Publishing tutorials and speaking at larger conferences will continue as well.
What This Conversation Shows About Flutter Beyond Mobile
Flutter’s expansion across TV, streaming, fintech, and consumer products is not just a story about code reuse. In Hashem Abounajmi’s account, the deeper issues are performance under constraint, modular architecture, migration risk, automation, and the discipline required to scale across both platforms and teams.
The conversation also shows that cross-platform work becomes more demanding, not less, as products grow. Running in more places is only part of the challenge. Making those products maintainable, resilient, and performant across very different environments is what defines the work.
Hashem Abounajmi is a Senior Flutter Engineer based in the UK. He speaks at Flutter London, mentors through the GDG London Flutter DevCamp, and writes about Flutter and Dart. You can find him on LinkedIn and GitHub.
