Heads up: Our Ideas Factory has been refreshed, levelled up, and grown-up into Alphero Intelligence. Some of our old posts are pretty cool tho'. Check this one out.
- The panacea of a single codebase has taunted app makers for years, but always fell short on delivering the benefits and performance when compared to native code.
- Google's Flutter is a promising framework that matches much of the performance of native development while keeping development and maintenance costs down.
- The technology is still under development and support for third-party libraries and some more advanced device functions can be limited.
Developing apps for iOS and Android devices is a well understood affair, with great practices and tools. Both Apple and Google provide tools and guidelines that make the best out of their systems capabilities and that can access device functions (i.e. camera, bluetooth) without the need to jump through any hoops. The tools and support for third-party functions are mature and stable, which means developing and maintaining apps bring no surprises to our beloved developers. It also means new features and functions are available immediately to developers, and user experience patterns can be tailored to each platform without the need for fiddly customisation.
Through the years different frameworks have come to market where the idea is to develop something once and have it work on both platforms. They get double points if they are based on household languages such as Javascript and C#, which is attractive to some businesses as they don’t require specialist upskilling, and theoretically developers they have around could just get on with building mobile apps.
This approach has had limited success. Because these frameworks act as a “translator” in the middle, when more specialised functionality is needed, native developers may need to come to the rescue to create custom code to target different systems. Creating smooth design features can be troublesome at times as performance is hit or miss, and support for specialist SDKs and new device features take time to catch up. All of these build up and creating apps that match native experience become just as costly (if not more) as it would to develop using native technology to start with.
Tell me more about single codebase frameworks.
Single codebase frameworks have their own development paradigm and under the hood are equipped with witchcraft that allows developers to deploy their application to different platforms of choice.
Until a couple of years ago, most attempts were commendable but really didn’t deliver. Frameworks like PhoneGap and Xamarin promised the world, tooted their own horn but largely created cumbersome slow apps that required large amounts of Paracetamol to work. More recently, some platforms have made some inroads and, while some tools like Cordova and React Native look promising on the surface, they have some performance considerations that didn’t live up to the hype. Some of these frameworks have led our team to say that “they are great for bringing all the Native and Web devs together against a common enemy”.
A shiny and exciting light at the end of the tunnel has arrived: Flutter. This Google development kit has been around for a while and promises deployment for iOS, Android, Web, Desktop (Mac, Windows and Linux), blazing performance and ease of development. Mind you that the promises are not new, so our development team approached it with the caution of someone that has had their heart broken far too many times. They found someone mature, that lives up to their promises and gives you a foot massage at the end of a hard day.
Our developers Kallan and Amarjot have been deep in Flutterland and have granted us an exclusive interview about their journey.
Single code frameworks caused some angst in the past - what are your general feelings about Flutter?
Overall from a developer perspective it provides a good solid experience. The documentation and support from Google regarding Flutter is great, and it seems to be growing really quickly in terms of popularity and adoption. Some technical aspects like being a typed language means it’s easy to know what can be passed to all prebuilt Flutter widgets directly from the developer interface.
What do you think it does better than the Native tools?
It’s got hot reloading, so as soon as an update is made on the code it is reflected instantaneously on the build. Compared to iOS interface builder and Android XML files, the approach for building the user interface means we can build up our components and screens from a variety of widgets out of the box, which saves a lot of time.
Flutter has the advantage of coming into the market after years of iOS and Android development, so it’s doing a good job of taking the best part of both platforms out of the box. Usually there’s pre build widgets that are common on most development flows, which we can pick up and start easily customising.
And where do you think it falls short?
Being new means some well established libraries in other platforms are still not available. This can be a problem for some clients like media who are really reliant on third party SDKs for things like players or ad serving. We can still get around that by writing native Swift or Kotlin code to target a particular platform.
Does it really deliver on the whole performance topic?
Unlike a lot of other (not native) frameworks we’ve seen, it really feels like a native app - the animations and interactions are smooth.
It can use some work on the error messages that are still abstract, which can take some time for debugging. Customising the experience to match iOS and Android specificity will still need work and, although accessing device functions is in a better place, some use cases will still require custom native code.
How much do you have to worry about specificities for iOS and Android?
When writing UI, routing, or network layer code there’s no need to specify whether it’s iOS or Android. Some more specific services like push notifications, location, battery, all require a bit of code so Flutter can communicate with the native iOS and Android code.
Analytics and advertisements normally require different keys based on iOS or Android so with a simple built in flag you can tell whether or not you’re running on iOS or Android.
Does it introduce any issues for deploying to the Apple and Google stores?
Nope.
What does it do for the Web? And Desktop?
Deploying for different platforms is core in the system, and the Web and Desktop deployment process is simple. Deploying for different devices will consider good design considerations, much like a responsive website would need to make sure the experience is good for all screens.
Does it support Unit Testing?
Yes, and also have a suite of integration test widgets out of the box.
How do you think it impacts development cost for an app we would develop for iOS and Android?
It will depend on a few factors. Level of customisation between the platforms, requirement for third-party apps and design execution all will play a part. Flutter will be a better fit for simpler apps that don’t require much frills. We can really reduce dev costs here.
Testing is an area that will need consideration - although costs testing business logic will be cut dramatically, more detailed cross-device testing might be required to make sure no obscure devices or screen sizes misbehave.