I wanted to do a quick recap of FlutterCon USA 2024. It was packed with amazing talks, hands-on workshops, and a lot of excitement from the Flutter community. In this post, I’ll share some of my favorite highlights, key takeaways, and a few personal experiences that made this event special.
Flutter at 10 years
It all began with Eric Seidel's keynote, reflecting on the first 10 years of Flutter. The keynote was a journey through Flutter's evolution, broken down into three key sections:
1. Getting Flutter to Work
The first part of the presentation revisited the humble beginnings of Flutter, with Eric recalling one of the early “Sky” demos, which would later evolve into Flutter. You can check out that original demo here: Sky: An Experiment Writing Dart for Mobile (Dart Developer Summit 2015). It was a powerful reminder of the engineering challenges and achievements that led to what we now recognize as Flutter today. Once those initial demos were up and running, the focus shifted toward building something stable and reliable that developers could use in production.
2. Flutter in production
Next, Eric shared how companies began taking a leap of faith with Flutter, with Hamilton being the first commercial app developed using the framework, this set the stage for Flutter’s suitability in large-scale production environments. This started a wave of adoption by businesses—big and small—leading to discussions on how to best leverage the framework: from UI and animations to state management and architecture. This laid the foundation for the stable Flutter we know today.
3. Flutter Everywhere
Today, Flutter has over 1 million published apps, and it has been embraced by countless businesses. However, Eric pointed out that there’s still a barrier preventing some large enterprises and legacy businesses from fully adopting Flutter. The need now is for more organic success stories—companies demonstrating Flutter’s power not because of Google partnerships, but because they’ve achieved real success with the framework.
In conclusion, the keynote made it clear that Flutter is ready. As Eric put it, it has become the "safe choice" for multi-platform development. However, there’s still progress to be made on the business front. We now have a stable and reliable framework, but it’s up to both developers and businesses to drive a large adoption of Flutter. And as a final thought, it’s evident that Flutter is here to stay, leading multi-platform development for at least another 10 years.
Going offline first with Flutter by Gianfranco Papa and Elian Ortega
It was an amazing opportunity to share the stage with Gianfranco Papa at FlutterCon USA for this talk. We wanted to set the foundation for future discussions about offline-first approaches within the Flutter community, a topic we believe is crucial but not widely covered.
The idea behind our talk was to introduce the key concepts of offline-first development, especially in the context of Flutter, where there isn't as much documentation available compared to native Android or iOS. We started by explaining why this approach is essential for modern apps, discussing everything from optimistic UI updates to delta updates and synchronization strategies. We also got into conflict resolution techniques like First Write Wins (FWW), Last Write Wins (LWW), and more advanced strategies like Conflict-Free Replicated Data Types (CRDTs).
Offline-first development isn't trivial. It involves working with local databases, synchronizing data with the server when it's available, and resolving conflicts that arise from multiple devices trying to update the same data. We highlighted how this impacts user experience, making apps feel faster and more responsive while reducing server loads and potentially improving costs. We also stressed that these considerations should be factored into the app's architecture from the start to avoid complications down the line.
We touched on some tools and packages that can help developers implement offline-first functionality in Flutter, including popular local database options like Sqflite, Isar, Hive, and Drift, as well as CRDT solutions for handling more complex synchronization challenges.
Our goal was to set the groundwork for more in-depth talks in the future and encourage developers to consider offline-first strategies early in their projects for a smoother, more efficient development process.
I was particularly interested in this talk, as background processing plays a crucial role in creating offline-first applications.
Dominik kicked off the session by highlighting a common Google search: “How to do background processing in Flutter?” The top result typically suggests, “In Flutter, you can just use isolates.” But, as he explained, this is merely the tip of the iceberg.
He then discussed some key considerations when using isolates, such as the fact that they require the Flutter engine and can be invoked either from the main engine or a new engine created in the native code. Dominik also presented a demo showing how to create a new engine and perform background processing using Kotlin for Android.
This led to a bold takeaway: “Maybe write your code natively?” He emphasized that background processing behaviors and APIs vary significantly between iOS and Android. His demo focused on Kotlin and Android, where the environment is more controlled, making it easier to ensure consistent behavior.
Some existing background processing plugins were highlighted, including:
It was an excellent talk, and I highly recommend watching it if you’re planning to work on any background processing tasks. You can catch the talk recorded during FlutterCon Europe here.
Stop centralizing! A humble approach to Flutter app architecture by Matt Carroll
I’m a big fan of architecture, and I always find it valuable to explore new approaches.
Matt kicked off by discussing the pros and cons of centralizing app components and features—things like UI themes and internationalization. But the real focus came when he addressed navigation through the example of a multistep form for buying movie tickets.
In this example, Matt demonstrated how a centralized navigation approach could introduce unnecessary complexity for a relatively simple feature. Instead, he proposed disconnecting the multistep form from centralized navigation and managing the flow using a StatefulWidget and a switch statement to display different widgets based on the current step which was handled with an enum. Naturally, this raised concerns like, “What if I need to go back?” and “What about navigation transitions?” The solution was simple: add an onBackRequested callback to each view for handling back navigation, and use a custom widget (I believe it was called StackNavigation) to preserve state and animate between steps.
While this approach might be controversial for some developers, the key takeaway was clear: in many cases, opting for a simpler architecture can lead to the same results, but with faster development and less complexity.
The power of Macros in Dart by Gianfranco Papa
Macros are one of the most anticipated features in Dart, offering the potential to introduce powerful metaprogramming into the language. Gianfranco's talk was all about breaking down what macros are, how they can be used in day-to-day coding, and how developers can create their own macros to make life easier.
He also went into the technical side of things, talking about the different stages of a macro’s lifecycle and explaining how the order of execution works behind the scenes. This gave everyone a better understanding of how macros will function in practice.
Gianfranco wrapped up by highlighting how macros could change the way we write Dart code—especially by reducing the need for code generation tools, like those used for JSON serialization. This shift could lead to cleaner, more efficient codebases with fewer workarounds. It’s clear that macros are going to make a big impact when they officially land in Dart.
From frontend to backend with Serverpod by Viktor Lidholt
I was particularly interested in this talk because I’ve been working with Dart on the server almost daily for the past few months. Naturally, I’d heard of Serverpod but hadn’t taken the time to dive deeper into it.
With my current Dart-on-the-server setup, I’ve faced several challenges. For instance, logging has been tricky to implement, especially when trying to make the logs look good in GCP. I’ve also had issues with health checks to ensure the API is running smoothly, and I ended up handling authentication in the mobile app using Firebase for simplicity. Since I’m keen to explore more of the backend world (I’ve worked with NestJS for some projects), I had this feeling that my current setup was missing a lot.
That’s why, when I saw the second slide of the talk listing features Serverpod has built-in, I was immediately intrigued. The list included:
Logging (with a companion app to view logs)
File uploads
Authentication with major providers (Email, Google, Apple, Firebase)
Data streaming
Task scheduling
Health checks
Easy deployment
Data migrations
Knowing that Serverpod is so feature-rich and backed by a team of 8 developers dedicated to its growth gave me a lot of confidence in its potential for long-term support and new features.
Viktor then went on to demo how to create models, run migrations, and build an endpoint. The process felt very similar to my current workflow, but with a lot more built-in functionality and benefits.
I’m genuinely excited to try Serverpod myself and might even write a blog post about my experience. If you're curious to learn more, check out their excellent documentation at serverpod.dev.
Building a package with assets by Moritz Sümmermann and Daco Harkes
This talk grabbed my attention because it featured two Googlers from the Dart compiler team. In my view, the more Dart advances as a language, the more Flutter will benefit as a framework for cross-platform development.
The session began with a disclaimer: some of the demos shown were only available on the Flutter master channel behind experimental flags, and a few only worked on their laptops (which was very funny 😂). Moritz and Daco then showcased an add and subtract function written in C, which was built and bundled as part of a Dart package asset. They also demonstrated how tree-shaking applies to native code—if the subtract function wasn’t used in the Dart code, it was excluded from the final native build. This technique worked for other assets too, such as JSON files.
As they walked through the process, they explained the hooks involved in building and linking these native code assets. They emphasized that their implementation followed protocols that would allow support for other programming languages, such as Rust, Kotlin, and Swift, in the future.
The end goal of the "Asset" feature in Dart and Flutter is to facilitate the use of pre-existing code from other languages, allowing developers to integrate it seamlessly within their Dart projects.
Future of Dart Panel
This panel was one of my favorite events at FlutterCon, offering valuable insights while engaging with questions directly from the community. The open format allowed attendees to hear the thoughts and opinions of the Dart team, and there were some particularly interesting discussions.
One recurring question, reflecting concerns within the developer community, was: “Is Google going to kill Dart and Flutter?” Michael Thomsen’s response was clear—this question has been asked repeatedly since the begining of the language, and Dart is still going strong. His response gave a sense of confidence for the future of both Dart and Flutter. They also mentioned appreciation for community contributions to the Dart ecosystem.
Other questions ranged from thoughts on WebAssembly (WASM) for Flutter Web to things the team might have done differently. For example, there was once an intention to remove semicolons from the language, but this was ultimately scrapped due to the enormous impact it would have had on the framework's core—simply too disruptive to consider.
The main takeaway for me was the reiterated message that Dart and Flutter are here to stay, with the team’s main focus now on highly anticipated features like WASM and macros—features that the community has been asking for quite a bit.
Flutter and Dart Package Ecosystem Summit
The "Flutter and Dart Package Ecosystem Summit" was another great session I attended, focusing on the current state and future of the package ecosystem in Flutter and Dart. This session aimed to address some of the key issues and challenges developers face, such as abandoned packages and finding ways to encourage ongoing maintenance through potential compensation models for package maintainers.
The discussion was led by Ander Dobo and Rody Davis, with members of the Dart team, package creators, and community members actively participating. It was great to see that everyone involved is committed to avoiding the pitfalls that have impacted other open-source ecosystems in the past.
Some of the key takeaways for me were:
Support for Package Maintainers: There’s clear interest from the community in finding ways to support package maintainers, possibly through a compensation model. While nothing has been stablished, starting this conversation is a step in the right direction to ensure long-term package maintenance.
Flutter Community GitHub: If you can no longer maintain your package and want to prevent it from becoming obsolete, you can transfer it to the FlutterCommunity GitHub, where it will continue to be maintained by the community. You will still lead the package development but it will be backed up by the Flutter Community team.
Pub.dev Package Name Recovery: In cases where a package has been abandoned for a significant period, developers can reach out to pub.dev to request that the package name be made available again.
Namespace Discussions: There’s growing interest in introducing namespaces for packages to avoid conflicts where two packages share the same name. This could be an important change to ensure smoother package management as the ecosystem continues to grow.
This session highlighted how much thought is being put into ensuring that the Flutter and Dart package ecosystem remains sustainable and avoids common issues seen in other communities.
Final Thoughts
There were so many other amazing talks and sessions I couldn’t attend live, but I’m definitely looking forward to watching the recordings once they’re available. If possible, I might even write another post to highlight some of my favorite sessions that I couldn't catch.
All in all, FlutterCon USA was an incredible experience! It was amazing to meet so many talented people from the Flutter community in person, share knowledge, and be part of such a supportive network. Huge thanks to my team at Somnio Software, especially Mauricio Pastorini and Gianfranco Papa, for all their support and collaboration. I'm already excited for the next FlutterCon and to continue being part of this fantastic community.
What a great experience! See you all at the next one!
