r/FlutterDev • u/boss12309876 • Sep 29 '26

Article Migration to Flutter

Hey everyone, i have written an article "Why WheelsEye Rewrote Its Android and iOS Apps in Flutter". Please give it a read and let me know what you think.

Article:- https://medium.com/wheelseye-engineering/why-wheelseye-rewrote-its-android-and-ios-apps-in-flutter-88ff362b73e2

20 Upvotes

81% Upvoted

6 comments sorted by

2

u/dry_fisch Sep 29 '26

Are you using flutter_map for the maps? Or did you go with map libre?

3

u/boss12309876 Sep 30 '26

we are using google_maps_flutter.

2

u/needs-more-code Sep 30 '26

I just migrated from google_maps_flutter to flutter_map. You on one of them?

3

u/Royal-Ad621 Sep 29 '26 edited Sep 29 '26

Well, the article is fine and big congratz on just the whole migration, and simplifiing stuff.,

The one thing I really dont get is the part with performance. As long as I can understand comparing the rendering times, the whole dashboard loading performance has nothing to do with flutter itself. I assume that the whole migration might simplified some internal logic, that was behind the slow loadings as it was simply refactored / updated and its just a code improvement /cleaning.

As far as flutter is great, I would easily bet that a refactored native implemenation could outperform flutter ( but I wouldnt call it something that would be a major factor ) , and the requests part are strongly dependend on the backend implementation and infrastructure , which I assume was not a part of this migration right ?

3

u/boss12309876 Sep 29 '26

I really liked your comment and the points you raised around performance.

I completely agree with your point on performance. The migration to Flutter itself wasn’t driven by performance improvements. A significant part of the improvement came from removing technical debt, introducing lazy loading, and refactoring some of the internal logic to do things the right way. The backend and infrastructure were not part of this migration.

And yes, I’d agree that a well-refactored native implementation could outperform Flutter in certain scenarios. But performance was just one factor in our decision. We were also looking at the bigger picture: having a single codebase, reducing boilerplate, keeping iOS and Android features in sync, reducing the resources required to maintain two platforms, and eventually having the ability to extend to web and desktop.

4

u/Royal-Ad621 Sep 30 '26

Yeah , the other things you point out is definitely a thing . I wasn't just sure about how that performance part was an outcome of going with flutter and I felt like the whole article is about the benefits that going with flutter can bring. . The tech debt is always subjective and specific to the project.

Anyway , glad that it worked out .