Over the last few years, we have been diving more and more into the world of multi-platform Self-Service and Self-Management style Apps for Mobile and Web. Oftentimes, we are working with clients who have done very little in the digital space – aside from a very basic Website (or even a Squarespace or Wix instance) – and they are looking to us to select the best technology and framework for their project.
The thing about Agencies and Software Development shops is – they will ALWAYS push their favourite technology, regardless of what is best for the project or even the future maintenance of their client and their customers.
There’s just no getting around that.
One Mobile Development Studio will insist on native development for each platform (Swift for iOS, Kotlin for Android, and a dedicated JS Framework for Web), another on a simplified cross-platform approach that maps to their team’s existing skillset (say, React Native), or perhaps even a more modern, ‘widget-focused’ single interface solution like Flutter.
The problem is – each of them is correct – and each of them is totally wrong.
These days a solution that combines multiple Mobile Apps, Tablet Apps, a Web site, and even a Management Portal can be developed in a number of languages and methodologies – and none of them are functionality incorrect. But there is a LOT more consider than just the empiric project goal of getting ‘something out the door’.
How will users interact with the Apps? How often will the App offer new features and functions? Will your client eventually bring in an internal team to manage the solution? Will other Developers be involved in future? What is the projected lifespan of the solution? All of these questions have a massive impact on the codebase that is selected, and sadly we see these questions are too often left unanswered when the first lines of code begin to be laid. And that’s just backwards.
At Mission Control we have always advocated for the best experience for each platform – which means more often than not – going for a native language for each platform we target. But in the last few years, when new clients come on board needing a simplified, centralised solution they can pick up and run with – approaches like React and Flutter have just made more sense.
After all, why rebuild the codebase multiple times for essentially the same App experience? The trouble for us has always been the ‘experience’ part of that statement. While Flutter has proven exceptional for helping us optimise one codebase across multiple Mobile and even Web Operating Systems, some of the recent changes to platforms (we’re looking at you, iOS 26 and your ‘liquid glass’!) has meant that a ‘one size fits all model’ will leave the user experience lacking in many cases.
Enter Kotlin Multiplatform (KMP). While the largest percentage of our projects have used Flutter or direct Native approaches the past few years, we are extremely bullish on the prospect of KMP taking the mantle as our chosen development language. KMP has all the benefits of Flutter and React (i..e a common base for business rules, integrations, etc) but allows us the freedom to design dedicated layouts for *each* platform. So that means, we get all the liquid glass goodness from iOS 26, all the new slick animations on Android’s Material 3 Expressive, and even a solid base to extend to Web and other channels.
You can hear the excitement in our voice, I’m sure. But we also need to pump the brakes a bit (even we get carried away with these new toys sometimes!).
Back to the core point of this post – even with Kotlin Multi-platform in the mix – there is still no 100% correct answer when choosing a development methodology/framework for our (or your) clients. The key is recognising all the variables – mapping the future of the solution from both an ongoing management aspect as well as an end user experience – and (to us at least) staying as close to native on each platform as possible.
So perhaps KMP gets us closer to our ideal – but Flutter is still the chose for many of our projects – and we never tire of jumping straight in to each dedicated platform (Swift/Kotlin even Objective C, etc) when that makes the most sense for the project.
So when we’re asked which is ‘the best’ approach – we tend to slow things down and first ask all those annoying questions we mentioned above about the future plans for the solution, our client’s vision of where this is all headed, and what their end users really want to see in an App. Only then can we map out a few solid options, make the best call on what (at least for today!) looks like the correct, most sustainable approach, and start to write code that will work now and well into the future for everyone involved.
