Freedom of Choice with Flutter

Any significant investment in digital solutions considers cross-platform technologies at some point. What is the widest footprint of devices I can address without compromising the experience for each user and staying within budget?

A comprehensive discovery study may consider the following:

• Native Mobile: Android / iOS
• Native Tablet: Android / iOS / Surface
• Web: Mobile & Desktop
• Native Desktop: Mac / Windows / Linux

I don’t know an MVP version of an unproven app that targets more than 3 of these without cutting some corners. Native mobile is reused for tablet or a web site targets all desktop needs. Web may also cover mobile via a PWA.

Even with cross-platform technologies, validation cost may become prohibitive.

Cross-Platform Hope…

The cross-platform dream is a single code base produced with the development IDE experience of one’s preferred platform that comes close to native performance. Most fall far short.

Plenty of articles compare the various options — new ones daily. The view on whether one should use Flutter has ranged from ‘It depends’, to ‘Maybe’, to ‘Absolutely, and I will never go back’. Accompanied by the pragmatic ‘meh’ or once bitten ‘will never replace native’.

The single code base is a myth hidden by an abstraction that conceals native integrations. Whether Javascript or Dart, a cross-platform app may have a single code base — but below that lurk per platform variances waiting for an opportune moment to keep you up at night with a complication. They announce their presence when an underlying dependency changes, think iOS13 to iOS14, or AndroidX.

The cross-platform library may have some integration issues, or more likely — selected third party packages must get updated. And now I have an extra delay and cost to my development. Even if I anticipated it — and you should, the timing is rarely convenient.

It’s out of my control. And it makes my head hurt. After two or three bad experiences, I gaze at my old native code bases with nostalgia.

Enter Flutter…

In the past couple of years, Flutter has evolved to address many cons of cross-platform development. Though typical risks remain, it far surpasses other solutions in my experience. Judging by recent articles, many agree. In my opinion, the Flutter advantage comes down to 2 key items: developer experience, and performance.

Historically, native platform developers begrudge the benefits of cross platform solutions due to painful past experiences alluded to above. They remain comfortably anchored to their preferred platform. But with Flutter, because of the tools, documentation, and community, developers find they enjoy the programming experience. It allows them to focus on what they love instead of battle against forced usage of a tool they know in their heart is not the best.

But Flutter actually does what it promises — maximize development reuse with a similar effort as single-platform native. It’s easy to install, has great documentation, a fast learning curve, and great toolsets. Its underlying architecture (it does its own rendering instead of a bridge to native components) keeps the platform integration layer thin and abstracted from the typical migration headaches called out above— though third party packages are not immune.

For these reasons, I have embraced Flutter. I especially like it for B2B, MVPs, or version 1.0s. I also discovered a new degree of freedom I had not been looking for. Flutter allows delayed choice of target platform. What does this mean?

Platform Decision Risk

If the target user or engagement model is not identified or proven, the platform investment risk can seem especially high. Are they primarily Android users? iOS? Will they prefer to interact on their phone or desktop? How likely is it they will have installed the app in advance of need? If web is the primary platform, what browser will they use?

Maybe there is one primary mobile usage scenario, but a critical secondary usage that will always be web. For example — a transaction between a service provider and a walk-up customer.

It may take several iterations to determine the best approach and highest value platform target — unless budget is unlimited and you can support them all. (If this is you, please comment what automated test tools you use to validate all the permutations).

Agile Deployment

The great thing about Flutter is that it supports all of these scenarios. So you can target one platform with low risk and after some iteration, when the picture is clearer, you can pivot to a different platform, without throwing your initial investment away, or starting over.

Maybe mobile was not the right choice because usage is 1-time — perhaps a PWA link sent via message works better.

Consider Flutter and this agile approach to targeted platform deployments — broad and shallow at first, then increasingly focused and deep as you come to know your users and the most convenient and successful platforms for them to engage your solution and extract the value you provide.

Strategically planning the first phase of your app to address all these platforms with an appropriate experience, will pay dividends. But the experience should be carefully designed. What might be the right engagement model and UI for mobile and PWA is probably not ideal for native desktop or responsive web. An agile approach to target selection may save you enough to invest in a single code base that still has the appropriate UI for mobile, tablet, web, and desktop when needed.