One of the biggest advantages of working at icapps is that you get to play with just about everything. Everything in the field of digital development, that is. But that’s plenty of fun already. Lately, for instance, I’ve had the opportunity to compare three cross-platform technologies that we have used for various projects. A very useful exercise, and I gladly share the main findings with you.
First and foremost: each technology has its advantages and drawbacks, and most importantly, each technology will be the best solution for a high-quality result in specific circumstances. The following overview will provide you with some insights on each technology’s characteristics:
Click the image for a larger view.
This usually takes the form of C (or Kotlin) libraries containing functionality and business logic, and being plugged into (native) iOS & Android codebases as a dependency.
It allows the applications (and therefore also the development performance & functionality) to remain completely native. All tools and technologies being used in this scenario are often "battle-proven" and have been in use since the emergence of both mobile platforms. That’s why this approach is very interesting when a tight Operating System (or native SDK) integration is required for an app.
However, you should take the following into consideration with native code-sharing:
- Sharing User-Interface code between iOS and Android is not possible with this technology.
- The responsibility for the architecture (and what is being structured where) lies entirely with the developers. This means that bigger projects require a great deal of attention and discipline in order to reach an adequate level of maintainability.
- This can significantly complicate the codebases and test and build processes when developing an app.
- Depending on the team size, you will need more documentation, versioning, integration testing ... than ‘usual’
These considerations have led some companies to try and avoid native code-sharing. Recently, Dropbox has devoted a blogpost to this topic: 'The not so hidden cost of sharing code between iOS and Android'.
Builds upon the innovative concepts that have been introduced by React:
- Component-driven architecture with a "declarative" user interface
Unidirectional dataflows in the application generated by the "Flux" design pattern
Even further React Native makes use of OEM widgets in the Operating System to render the UI. This is why React Native is specifically suited for apps that benefit from using these UI elements as a basis to build screens.
This technology gathers a large and active community; big names such as Microsoft and Samsung have openly stated their full support.
Flutter has been built following the concepts introduced by React.
Does not make use of OEM widgets, apart from the canvas element. A Flutter app renders everything itself (on that canvas). The components available for a developer to build screens, are consequently not the ones provided by Apple and Google through the OS, but implemented by the Flutter team. The drawback being that, in a way, you are "dependent" on what components are already available (or have been created by the community) and on the quality of the components. On the benefit side, we can add that the connection between app logic and UI layer is ultra fast, and that customization and animation are very easily supported by this rendering approach. Flutter is thus ideally suited for apps that need a unique UI or that aim for extraordinary, rich user experiences.
The community is expanding steadily, but is still considerably smaller than e.g. React Native’s.
As you can see, we have a lot of options to offer our clients. According to the client’s needs and preferences, we are always happy to help them choose the best fitting solution for their projects. That’s why we are very excited about the next evolutions of these technologies.
I look forward to hearing your experiences with these technologies and to share some extra tips!