The ArcGIS Maps SDK for Flutter team returned to flutterCon USA in Orlando this July with first-hand insights to share. Martino Yovo and Harish Kunchala represented the team at this year’s event to connect with other Flutter developers, hear directly from the Flutter team and community, and learn where the platform is headed. FlutterCon continues to provide these valuable opportunities, which help ensure Flutter Maps SDK continues to meet the needs of Flutter developers.
In this article, we share our key takeaways and tell how we demonstrated the Flutter Maps SDK’s ability to empower Flutter developers with GIS through mission-critical applications.
Flutter in mission-critical GIS apps
Martino was interviewed by Craig Labenz of the Flutter team, co-presenter of this year’s keynote, about GIS and building mission-critical applications with Flutter Maps SDK. The discussion explored what GIS is, how a geospatial platform differs from consumer mapping applications such as Google Maps and Apple Maps, when organizations should consider GIS, and how customers are using the SDK in production. To learn more about some of these success stories, explore the StoryMaps at the bottom of the article!
Takeaway 1: Flutter is everywhere and here to stay – road ahead highlights
Flutter is no longer just an emerging framework. Today, it is used by global brands and organizations around the world, including Universal Studios. Its growing popularity is also evident in its rise to become the second most popular developer SDK for mobile, demonstrating strong adoption across the developer community.
As contributors to the Flutter ecosystem, we’ve also seen growing expertise emerge across the community, making Flutter less dependent on any single organization – such as Google – and strengthening confidence in its long-term future.
A key message from Google’s Fluttercon USA keynote was the increasing role of the broader Flutter community in shaping the framework’s future. To support this, Google is expanding pathways for external contributions while maintaining the quality and stability of the platform. This includes initiatives such as the new Flutter Contributor Ladder, which formalizes recognition and participation for community experts.
For organizations using Flutter, including Esri, this approach provides confidence that the platform’s roadmap will continue to be guided by the needs of developers and the broader ecosystem.
Takeaway 2: Flutter is decoupling Material and Cupertino
Material Design and Cupertino Design Language have long been part of the core Flutter framework. These design libraries for Android and iOS, respectively, often underpin the widgets that the framework produces. Flutter is now moving toward a more decoupled architecture, separating widget functionality from visual design. This change reflects the platform’s continued maturity and gives developers greater flexibility in how they build and manage applications.
A less-opinionated widget baseline makes it easier for developers to create custom design systems without depending on Material or Cupertino. Developers who want to continue using these design systems will benefit from their independent release cycles, allowing them to receive updates without requiring a Flutter upgrade and vice versa.
So what does this mean for your apps? The transition is not expected to be disruptive. Material and Cupertino will remain available as standalone packages. We’re already exploring these changes in our Samples and Toolkit, and plan to share our findings in a future blog post.
Takeaway 3: Dart Hooks configuration improvements
Dart Hooks has been a valuable addition to our Flutter Maps SDK, providing a more streamlined way to download and compile native assets at build time. This approach is particularly important because our GIS capabilities are powered by a native C++ Runtime Core library that is packaged alongside our Flutter package.
We know that project configuration and setup are often the most complex part of using Flutter, especially as a cross-platform framework where you are often handling both iOS and Android platform specifics. Simplifying project setup remains a key focus for us. Continued improvements to Dart Hooks are helping us further reduce configuration requirements, with the long-term goal of eliminating the manual install step currently required when integrating or upgrading Flutter Maps SDK. These enhancements would simplify onboarding and reduce the effort required to get started with app development. Flutter thrives on providing a positive developer experience, and a positive experience continues to be an integral goal for our package too.
Takeaway 4: SPM is now the default
Speaking of project configuration, keeping pace with multiple platforms is an ongoing challenge in any cross-platform framework. At flutterCon, we attended a session by Louise Hsu from Google on how the Flutter team follows and stays ahead of the latest from Apple and the iOS ecosystem.
Dependency management with CocoaPods on iOS has traditionally been a source of configuration complexity. With CocoaPods becoming read-only at the end of 2026, Flutter has moved to Swift Package Manager (SPM) as the default iOS dependency manager in Flutter 3.44. We introduced SPM support in Flutter Maps SDK version 300.1, aligning with Flutter’s broader transition away from CocoaPods. We expect this approach to further simplify the development experience for our Flutter developers targeting iOS.
Learn more about building mission-critical applications with the Flutter Maps SDK
Learn more about some of the success stories featured in our interview at flutterCon by exploring the following StoryMaps:
Until next year, flutterCon!
Article Discussion: