Modern mobile application development is often hampered by the options available for the platforms available. Will your application be intended for iOS, or Android? Both, plus desktop web browsers? What versions? What specific devices? How long do you intend to support the application, and what does this mean for the limitations and maintenance of your desired application? These questions and their answers have a serious effect on the potential for any application’s success in the marketplace, and the amount of effort that development teams have to put into creating and maintaining a successful application in the wild.
Let’s start with the basics. Essentially, if your application is intended for Apple’s iOS platform, the code could be written in Apple’s Swift language. On the other hand, if your application will be offered to the world’s Android user base, then Java or Kotlin are the native languages usually targeted. You can see where this will cause major overheads and barriers to market uptake. Another way to think of it is like wanting to build a brick building, but having to build your own bricks first. Assuming that bricks are a standard item and that you know you can always get the right kind of bricks in sufficient quantities for your building project is usually a given. So, this is where development frameworks like Flutter and React Native come in. Depending upon which platform is chosen, quickly creating high-quality applications on virtually all popular platforms becomes a matter of staffing and education. Software development kits (SDKs) provide the virtual tool benches that application developers use to build the artifacts they hope will solve the problems their audiences need to solve.
Let’s break this down:
Applications can be assessed by a few categories, related to their intended uses, audiences, and general applicability.
Uses could include universally available, which might mean portable, real-time access to the current state, and perhaps efficient use of platform characteristics (size and ease of use).
Platform might be an important factor if an application has a limited audience, predominantly use a specific platform (this happens a lot around Windows, MacOS and Linux), and stakeholders with limited resources (people, time and/or money).
Expertise in the underlying tools is certainly a factor. Do you develop in the latest and greatest tools available, for future-proof benefits of having longer-lived application life-spans, at the risk of being unable to find sufficient developers who are competent and practiced with these new tools, and if so, can you afford to do it, based on the fiscal model that justifies the application’s creation? Or do you choose mature, well-adopted practices and tools, because it’s been a strong player for long enough to have spread the experience broadly?
Finding the appropriate strategy will be every creator’s initial challenge, because the future success or failure is first, the idea itself, and then, how you decide to turn it into reality. Will it work with the target platforms’ road-maps? For how long? How big is the audience? Will it make sense to build scalability early, or will it be re-imagined during its growth?
The first thing to note is that the choice involves belonging to either the Facebook camp (React Native) or the Google camp (Flutter). This probably doesn’t involve extreme risks, as neither organization is likely to dramatically shift direction on the core mission behind both frameworks. Delivering extremely robust, easily maintainable cross-platform applications, while keeping development costs, time-to-market, and application maintenance as low as possible. Let’s break down what that means for each stage of a project.
Choosing a Framework
Times are changing and companies are directing their focus to making the mobile app the main access point to their product. The vast majority of users always carry a smartphone on them, allowing them to open any app with a single tap.
Access to all the native phone functionalities—accelerometer, push notifications, or running in the background—is a huge advantage of mobile apps.
But there is no rose without a thorn. While you only need one development team with web technologies expertise to create a web app, the world of mobile apps is divided into 2 main operating systems: iOS and Android.
Each of these systems has a completely unique tech stack. Creating 2 separate apps that serve the same purpose, only on different platforms, may prove too costly—especially for startups or companies with a limited budget.”
Implementation and Learning
Development and Operations
There are some specific issues around the certification process for the two predominant application stores, Apple’s App Store and Google Play. Before any application can be posted to either store platform, the appropriate developer signature must be approved by the store, and embedded in the application before it will be publicly available to users.
Testing and Rollouts
There are differences in how developers work with each framework. Flutter is a more reactive platform, meaning that there is more freedom to respond to changes while in development. This means that changes to the end application are easier to adapt to with the Flutter framework, because the changes can be reloaded or re-rendered immediately, instead of having to rethink the overall structure. This usually means that a level of planning can move down to the practical level, allowing the people actually making the plan work can interact with details of the plan, reducing the to-and-fro of Context being translated into Conceptual, Logical and Physical design. When iterative improvements can be done with less effort, better designs are an inevitable end result.
Dart substitutes a whole zoo of languages and frameworks developers ought to know today.”
When it comes to performance, Flutter’s approach is quite different than that of React Native, or even NativeScript. Flutter’s application is compiled using arm C/C++ library so that it’s closer to machine language and gives better native performance. Not just the UI components are compiled, but the whole thing.
Dart is quite a performant language on its own, and many people believe that in terms of performance, Flutter has got the upper hand, although it’s hard to definitely judge as there are many factors involved in the performance.”
Youssef Nader, Computer Engineering Student, Cairo University. Published in hacker.io
Depending on how long an app is expected to be deployed, it might be worth the initial overhead of building a Flutter-created app. Doing so would be betting on the Google-founded framework. If, on the other hand, people feel that the 3 year lead effort from Facebook’s funded React Native, it’s extensive ecosystem, and greater quantity of experienced developers gives a faster time to market, there will be use cases that make that a better option. There are conceptual, architectural differences to the two contenders that are worth thinking about, but the two main choices appear to be exerting effort now or extending that effort over the lifetime of the application.
At Pieoneers we’re always thinking about the future. Making sure that our products stand the test of time, with low maintenance costs and high usability, is at the forefront of our planning, design and development processes.