Choosing the right platform to build on is hard.
Choosing a platform for mobile is even harder.
At Craftworkz, we try to find the right tool for the right job. Therefore, we attend webinars and investigate the newest technologies. Our developers have the option to pick one day a month to investigate a framework or a new tool. During this day, they come up with a prototype, or even a blogpost.
Wednesday we listened to Mike Harington, Developer advocate at Ionic. During his webinar, he explains how we can choose the right cross-platform solution.
He starts by creating a list of points to compare against.
- Technology stack and tooling
- The ability to reach multiple platforms
- Access to Native device features
Technology stack and tooling
Firstly, an important option is Native, meaning that we have to build a native mobile application for every platform. That means that we have two codebases, one for Android and one for iOS. Writing native code requires the developers to learn specific programming languages. Moreover, every codebase has a different programming language. For instance, on the one hand, the programming language for Android is Java or Kotlin. On the other hand, for iOS, it’s Objective C or Swift.
The second option is Compile to Native. This platform offers the ability to have one codebase for Android and iOS. For instance, you can use React Native or Flutter to build your apps. All code, written in React for React Native or Dart for Flutter, will compile to native code. With Compile to Native, only one programming language is used to cover both iOS and Android.
The third option is Web Native. Web native uses the web to its advantage. This means that every platform that can run a browser, can run this app. Sometimes you might want to build apps for web and mobile in the same language. Ionic uses Javascript frameworks like Angular, React and Vue to create applications.
This immediately concludes that Web Native will be able to cover more platforms with the same codebase. However, it’s important to understand that Compile to Native could fit your needs. Remember that more platform coverage is not necessarily better. It’s a comparison that you should make based on the needs of the project or company.
Access to Native device features
Native device features are very vague. Let me explain to you what a native device feature actually is. Let’s say, for instance, you have an iPhone which unlocks by Face ID. Face ID is built in iOS by Apple. This means that it’s a native functionality of your device. Some apps use Face ID to authenticate or create a payment. These apps rely on the native device features.
It’s impossible to develop a new Face ID for iOS without investing countless hours. By building it yourself, you will not differentiate yourself from other applications.
The Native platform allows all possible features. This means that every API that the Android or iOS development kit exposes, can be used. This approach requires knowledge of both development kits in order to develop a working feature.
Compile to Native takes on a different approach. Flutter or React Native create plugins or libraries for all these native features. The advantage of this approach is that you have both functionalities in one plugin. However, the downside of this approach is that the development kit of Android differs from the iOS development kit. Although most of the plugins are open-source, you depend on external parties to maintain them.
Web Native will use a cross-platform native runtime named Capacitor or Cordova. Using Capacitor exposes these native features for both Android and iOS. Most of the libraries are written by the community, however, they will be supported by Ionic. The advantages and disadvantages for Compile to Native and Web Native are the same here. Both platforms allow native functionality to be added, but this requires knowledge of native programming languages.
The right platform for the job
One of my grandfather’s sayings was: “Use the right tool for the job”.
Every mobile developer will stumble upon Native, Compile to Native and Web Native. With mobile applications, it’s difficult to pick a winner. Sometimes performance is a big part of the discussion. But then again, budgets are also a big part in the equation. Native could improve the performance of your application, which is awesome. However, you also need two teams of developers, meaning that your costs are twice as high.
The point that we are trying to make, is that it’s important to visualize the needs of the application. For example, if you’re building a POC to showcase an idea, you should pick as many platforms as possible. This reduces the costs by a lot and ultimately allows you to AB test all the platforms. For instance, you could use something like Web Native.
If you’re looking for a mobile application for both iOS and Android, Compile to Native as well as Web Native could be your platform to build on. When Google services are the main requirement for your application, pick Flutter! If you have a team of web developers who know React, you should probably pick React Native or Ionic/React.
At Craftworkz, we focus on the needs of the project. We pick our platforms by failing fast and analyzing all requirements. This helps us to create MVP’s with the latest technologies. In conclusion, we always try to find the right tool for the job! Don’t know which platform to pick? Contact us to guide you through the process.
Top comments (2)
You should consider exploring Kotlin Multiplatform Mobile, which I would put in its own category where you still have separated platform-specific apps that all share common compiled business logic code. Leaving most UI and native features up to the platform teams, while business logic and core services are written once and can be shared by all clients.
Thanks for your answer! I'll look into that!