Overview
Cross Platform vs Native development is not always a straightforward consideration. I’ve been involved in my fair share of heated debates over what is best. As a passionate iOS evangelist for over a decade, it was a difficult shift to see if the grass is indeed greener on the other side.
Recently, we here at Mantel Group had an opportunity to work on a fairly high-profile project with expectations of quick delivery. As usual, MVP was mentioned frequently and admittedly, whilst this topic had been brought up a few times in my career, it was adhered to this time. Decisions for feature inclusion were taken on the merit of effort and importance to the user and an evolutionary approach. Give the user a scooter, and slowly with time, upgrade to a luxury car.
The idea was to get an app out to market asap, repurposing as much of the new website as possible.
As tech lead on the project, I was (somewhat) responsible for the technical direction, so when planning the work, it was done abstractly, independent of which mobile technology we would use. Whilst it’s always favourable to use technology that the team is comfortable with, we must factor in the desires of the client. In this case, Flutter was a necessity and mandated.
Big Shock
Excitement to try some new technology to add to my tool belt overtook my native-mobile bias. I could see the appeal.
Write it once; get two apps. I get it.
As I played with the technology via training courses, I put together a number of sample apps using the vast number of Widgets available in the Flutter library. For those unfamiliar, Widgets are UI components, so think of them as a view, button, toggle, spinner, etc. It was relatively easy to get an app looking the part.
However, as I tested on both iOS and Android simulators, my excitement bubble started to deflate.
I came to the realisation that Flutter doesn’t automatically switch out native controls for the platform it’s running on. If I’d defined usage of a Switch, for example, it would look like an Android switch running on iOS.
This is NOT what I’d expected. What I had expected was by using a switch, it would look natural on the device it was running on. This is also not limited to the look but also the feel with some of the scroll physics and inertia. It would look natural on the device it was running on, but if you wanted native platform-looking UI components, then it would involve extra work. This could be done through abstracting a Widget to the call-site, but the component itself would be switched under the covers.
Having said that, I was pleasantly surprised to run into some platform-specific behaviours using common Platform specific widgets. For example, scrolling on Android vs iOS has a distinctly different feel; Android, I’d call stickier, and iOS a bit more fluid. Presenting new views to the user is also visibility different, however, this is taken care of by Flutter itself, which was refreshing.
Should You Use Flutter?
The Pros and Advantages of Flutter
Write once, get 2 apps
By far, the biggest selling point is support for the minority of your app’s audience, whether this be iOS or Android. Rarely is a user base equally split, so the decision to put out an MVP is usually tied to the majority of the platform. Often, a compromise is made and either uses existing development experience or focuses on one side of the fence.
The benefit of Flutter is once you have engineers able to build for it, you’ll have a head start at launching an app for both iOS and Android.
Performance
Dart is said to be the fastest language available for building Android and iOS apps as a cross-platform solution. Tests have been done in terms of rendering components between the likes of Xamarin (now known as .net maui), and PhoneGap. It’s also one of the fastest languages available (assembler is arguably faster) due to it compiling to the device’s native ARM / x86 CPU instructions rather than Just in Time interpreted bytecode eg: Android
Now available for Windows with Flutter 3
In addition to having access to building apps for the ‘big boys’ in iOS and Android, we also get support for Windows with Flutter 3. This is in addition to support for Linux, MacOS, and of course web
Hot reload
Being an old-timer of sorts having to compile and wait for UI things to load, there’s something magical about changing code and instantly seeing the results. SwiftUI has been on this (when it works – it’s a bit fickle at the best of times), and Jetpack Compose has had a lot of love added for support for hot reload.
This alone can rapidly influence the speed of the development of components and elements that the app needs.
Flutter tutorial support
I was blown away by the quality of video content on the FlutterDev YouTube channel. The content concepts are easy to follow along and can get any engineer up and running while binge-watching their moreish videos.
The Cons and limitations of Flutter
Machine taxing environment
Any iOS engineer would quickly agree that running Xcode alone, on top of compilation duties, running simulators etc, can often bring MacBooks to a grinding halt.
Add to that the need to run either Android Studio or Visual Studio Code alongside Xcode at times will test the patience of any zen-engineer.
Few Flutter engineers in the market
Native mobile developers have been growing over the past decade; both iOS and Android have almost a 10-year head start, which makes Flutter relatively immature. It’s understandable that there are so few Flutter engineers in the wild. It’s been reported that of the mobile development community, only 5% can be attributed to Flutter engineers, which is twice that of React native engineers.
The flow-on effect of this is a lack of support in the community for troubleshooting strange issues or examples on Stackoverflow and other similar code-sharing platforms.
Given this project, we had the advantage of an existing team that had flutter experience, and this was the biggest selling point. This in terms negated this Con, so made Flutter a compelling choice.
However, on the other hand, supporting engineers and other peripheral team members weren’t as well-versed in Flutter
Is Flutter Cheaper?
One of the selling points is that you’re writing code once to automagically get it for two (or more if you include Windows, MacOS, Linux and web) platforms.
The problem is that MOST documentation to bring engineers up to speed is centric to using the default Flutter design of material design.
This is a two-fold problem:
- Your app starts looking and feeling like an Android app or a Google website, even if your user base might well be weighted to iOS like most Australian apps.
- The single expected code base quickly becomes an IF THEN ELSE breeding ground.
The team starts celebrating the win that the app is starting to take shape until you realise it’s not quite as ‘native’ looking for iOS. In 2023, 60% of mobile users use iOS in Australia. That might remind you to cater for a suitable experience for your majority of users. iOS users will be confused with a toggle that looks like an Android one. So you have to start shifting tact. Refactoring. That means cost and, more importantly, time! Most projects are governed based on fixed times or looming deadlines.
The team reacts to make conditional component switchouts; show the default Material design and Android-influenced Switch Widget and a CupertinoSwitch Widget for iOS.
Suddenly your single source is now quickly becoming riddled with complicated code.
If you play it smart, you’d build abstract Widgets that themselves house the conditional component switch out, but the call side just knows it as a named Widget.
All this is at a cost and on top of having to potentially upskill existing mobile engineers from one side of the fence to learn how to use flutter.
What and Who Is Flutter Best Suited For?
Android biased user audience
Teams with existing Android developers
It’s a lot easier to turn an Android dev into a Flutter developer than it is to take an iOS dev on a journey to learn Dart and Flutter. I experienced this first hand as there was a reluctance by Apple fanbois to adopt the platform built by their “rivals”. However, since Flutter is Android-y out of the box, it’s no surprise for the better uptake by Android devs and a smoother transition.
Smaller/Startup companies with limited budgets
Startups or small companies with modest development budgets might need to put out an app quickly to validate the need in the market for the product. Since Flutter caters for both iOS and Android, Flutter can be a very cost-effective way of taking a product to market. Based on the uptake, investors of the product might want to invest more money in a more refined product, or simply continue on the development with that Flutter codebase.
Simple apps, with fixed roadmap or functionality
Apps often start with an idea, and quickly spiral into a backlog of features. With an agile mindset, the foundations can be built on to extend the product. However, occasionally you’ll have apps with limited functionality, without the need or desire to build on top of these foundations. Whatever the reason for this, whether it be a ‘basic’ app, or the need to get an initial app to market, Flutter could definitely satisfy this need.
Conclusion
The birth of SwiftUI and Jetpack Compose for Android, bridges the gap of the hot-reload that had been lacking in native development.
Admittedly, there’s something magical about changing code to be rewarded with a changed UI without having to re-compile. That’s a huge selling point of Flutter.
However, combined with the confirmed lack of Flutter development experience out in the market, layered with the desire for every developer wanting to learn the latest and greatest tech from a native perspective, using Flutter can be a hard sell. Having said that, support for Flutter has been invested fairly heavily by Google since its birth in 2017.
If you’re a relatively small, nimble, progressive company with few devs, or a startup wishing to validate whether you have a potentially profitable product and business model, then Flutter would be a great choice. It’ll allow you to iterate over quickly to refine the product before investing more time and money in a more refined, native experience. This, in turn, will speed up the development time using a working app model.
In saying that, I’ve seen Flutter used by bigger companies with great success. If the users love the app, it shouldn’t matter what’s under the hood.
