Skip and Flutter

• Introduction
• Comparison
• Getting a feel for Flutter
• Flutter in the wild
• The Future of Flutter
• Case Study: Realtor.com
  • We Weighed the Pros and Cons…
  • Native Approach Delivers Lightning-Fast Performance
  • Time Savings for Developers
  • Building Better for Everyone’s Benefit

Introduction

Comparison

Getting a feel for Flutter

Flutter UI Templates https://apps.apple.com/my/app/flutter-ui-templates/id1524943343 https://github.com/nohli/flutter_templates

Flutter in the wild

A good litmus test of any technology is to see whether the technology’s creators themselves use it for building their own apps. In this case, Google has indeed built some of their own flagship apps, such as the Stadia and Google Pay. However, the Stadia app – along with the entire Stadia streaming game service – was discontinued in 2022, and the Google Pay Flutter app is in the process of being discontinued and merged into the native Google Wallet app.

The Future of Flutter

Flutter has a large community and ecosystem of support libraries. It is probably going to be around for a long time to come. That being said, Google are themselves very clear on the recommended way to build Android apps:

• “Jetpack Compose is Android’s recommended modern toolkit for building native UI” - https://developer.android.com/develop/ui/compose
• “What are the plans for Jetpack Compose? Are there plans to make it multi-platform like Flutter is today?…” their response “…Jetpack Compose … is the present and future of Android UI…” — #TheAndroidShow https://youtu.be/_gL7XZy_XsY?t=2895
• “Compose is the future of modern UI development in Android” — #TheAndroidShow https://youtu.be/_gL7XZy_XsY?t=3584

Case Study: Realtor.com

https://techblog.realtor.com/from-flutter-to-full-native-how-we-optimized-performance-and-user-experience-for-realtor-coms-mobile-app/

From Flutter to Full Native: How We Optimized Performance and User Experience for Realtor.com’s Mobile App

You may be familiar with Flutter, an open-source UI software development kit from Google that’s useful for developing cross-platform mobile apps from a single codebase for any web browser. It was released in May 2017, and we use it to develop many of the screens on our mobile app. While this solution worked well back then, today’s users expect more—more accessibility, more performance, more features, more animation, and more innovation.

To that end, about two years ago, we decided to invest heavily in a mobile-first approach to increase the growth and adoption of our mobile app. As we started the research and defined the problem to solve, we asked ourselves: What is the right technology that will help us achieve our vision of being mobile-first while providing a high-performance, native experience? How do we ensure the solution can evolve as the OS ecosystem changes and differentiate our offering from other available products?

We Weighed the Pros and Cons…

Flutter is an excellent technology for building cost-effective, multi-platform native solutions:

• You can have a single codebase that runs on both platforms, which saves time and resources. Since it uses the same UI and business logic on both platforms, it helps maintain consistency in the ecosystem.
• Because it’s open source, it’s accessible to a wide range of developers and companies to continue to improve it.

However, supporting both Flutter and native versions in our iOS and Android applications was affecting development, production support, quality, and the state of the codebase:

• Leveraging Flutter works best when the app is built only on Flutter. In our case, because we had to manage Flutter and native in the same code base, it added additional overhead, which we describe next.
• Testing was more challenging and time-consuming because Flutter wasn’t rolled out 100%; we needed to test both variations (Flutter and non-Flutter) with several devices, duplicating much of the work.
• Switching between Flutter and native required about 20% more development time for our engineers. Since our version of Flutter was outdated, debugging Flutter features on iOS was difficult. There’s an absence of IDE tooling, which allows for the deep-dive debugging necessary to ensure a seamless user experience.
• Debugging was more challenging because we lacked robust tools in the IDE for real-time debugging or inspecting code at runtime to analyze and fix root cause issues.
• As new additions to the OS were released each year in the ecosystem, accessing that functionality or capabilities was delayed because we needed to wait for Flutter SDK updates that enabled that functionality.
• We couldn’t take advantage of Xcode 14.3 on iOS and continue to adopt future versions as they are released. (XCode 14.3 provides innovative capabilities such as new emoji, web app notifications, Voice Isolation for cellular calls, improved VoiceOver support, and more.) There were many advantages to switching to a full native approach:

Native development offered superior performance and responsiveness due to optimization for specific OS and hardware.

• The user experience was seamless because developers could adhere to platform-specific design guidelines and leverage native UI elements.
• Developers had direct access to the device’s features for creating feature-rich applications.
• Native apps tend to rank higher in app stores, leading to better visibility and discoverability. They can work offline or with limited connectivity and quickly adopt new OS updates for a seamless user experience.
• Native development benefits from a robust set of development tools, libraries, and community support.

Yet, there were drawbacks to this approach, as well:

• Native development requires separate codebases for different platforms, which would increase development time and cost.
• There’s the potential for disparity in behavior and UI with two code bases and different business logic in place.
• After weighing all the pros and cons, the team decided moving forward with a full native approach was the best way forward.

Native Approach Delivers Lightning-Fast Performance

Switching to a fully native approach was a massive effort that took a year and a half to complete, but we can confidently say that it was the right decision. The native approach provides full access to native capabilities and the native ecosystem, enabling us to deliver exceptional user experiences.

Tightening the codebase for improved readability and easier maintenance. There is now less risk of regression issues sneaking into the codebase and reduced initialization overhead for faster screen transitions.

Going native reduced the app’s launch time by 40%, from 2 seconds to just 1.2 seconds. The app bundle size is nearly 30% smaller (280MB instead of 398MB), and the app’s memory fingerprint shrank about 65% (from 450 to 200MB). Ultimately, these changes enable a superior user experience with our mobile app.

“The removal of Flutter from our codebase and going from a hybrid codebase to fully native has resulted in the engineering team being able to confidently build out features that look and feel better,” says Tomdroid Anderson, Staff Software Engineer – Mobile.

Time Savings for Developers

Users aren’t the only ones who benefit from going native. Our mobile developers enjoy time and cost savings and the ability to leverage the latest, most up-to-date features and capabilities of the Android and iOS platforms to enhance and enrich their projects.

Jing Zhu, a Software Engineer who also worked on the project, says the new design is easier to debug and saves the team a lot of development time since they don’t need to build Flutter frameworks and Flutter-related libraries. The table below shows the time savings realized:

Additionally, development cycles are shorter, thanks to improved Xcode times. The table below shows how switching to native development has accelerated development times:

“Removing Flutter from the codebase helps us focus on what each operating system provides natively,” says Fernando Jinzenji, Senior Software Engineer – Mobile. “Our productivity has increased noticeably without the limitations of Flutter, and it’s easier for our engineers to maintain the codebase.”

Plus, the new design is more modern. “We now have consistent theme colors across screens, which definitely make our app look cleaner and more elegant,” adds Jing. “Since more and more Millennials are buying homes, the new design could attract more users to our mobile app.”

Building Better for Everyone’s Benefit

Converting our mobile app from Flutter to all-native was well worth the time and effort invested. Now, our developers can leverage Apple and Google’s latest features and capabilities to optimize the user experience. They’re also saving significant time, resources, and budget that can be reallocated into creating innovative features that delight our Consumers and make their mobile experience with Realtor.com engaging, useful, and impactful.

“We no longer have to feel a certain level of anxiety over the hybrid approach potentially holding us back,” says Tomdroid. “Now we can focus on modernization efforts and enable our team to build out cool new features.”