How to choose the right technology for cross-platform development?
The last few years have been marked by the rise of multi-platform mobile development solutions, each claiming to be “THE solution” to reduce costs, shorten development times, facilitate testability or increase consistency between the different target platforms.
In short, they all promise to do more with less and, taking them at their word, one might wonder why some still persist in using so-called “native” solutions.
Of course, the reality is more complex.
All these solutions require you to make compromises. They certainly have advantages but also disadvantages. Using them means understanding and accepting these compromises and running certain risks that must be balanced against the potential gains.
How can we find our way around and objectively evaluate these solutions?
We propose here a set of criteria to evaluate their strengths and weaknesses. Depending on your objectives and the compromises you are willing to make, these criteria will allow you to choose a multi-platform solution for your project.
Performances
All users appreciate a high-performance application: the application starts and is ready to use in an instant, interactions are rich, fluid and reactive.
The end user doesn’t care how or with what technology you built your application. On the other hand, a slow or unresponsive application will be immediately sanctioned with a bad grade, uninstall or disinterest.
Unfortunately, this is one of the recurring pain points of multi-platform solutions, especially those based on Web technologies.
A few questions to ask yourself:
Is the startup time before application interaction increased?
Are the applications produced by the solution fluid and reactive?
Are slowdowns or latencies noticeable?
Are complex animations possible in an efficient way?
Are screen orientation changes and resizing efficient or does it show latency?
In order to assess this, consider testing several devices, different platforms and ranges. For example, some solutions behave relatively well on the latest iPhone but offer an unacceptable experience on a low-end Android phone.
Possible compromises
Revise graphic ambitions downwards to keep performance acceptable.
Be prepared to change or simplify the rendering / animations based on feedback from the development team.
Consumption
Battery consumption is an often overlooked but very important point for users.
An unloaded phone is useless and the most power-hungry applications are pointed at by the system, prompting users to uninstall them before posting a killer comment.
A few questions to ask yourself:
Is the battery consumption similar to an equivalent native application?
Compromise possible
Revise its graphic, processing or refresh ambitions downwards.
Size
The size of an application also has an impact on users.
It is not uncommon to run out of space on a device and to have to remove applications, among others, the largest ones being naturally the first potential victims.
Some features such as Instant Apps (which allows to install parts of applications from Chrome on an Android phone in a transparent way) limit, for example, the size of the features to 4 megabytes.
A few questions to ask yourself:
Does the solution have a significant impact on the size of the applications generated?
Will users have to download the application in a context of low connectivity (emerging countries, roaming, high costs…)?
Would the project benefit from Instant Apps compatibility?
Remote update
One of the difficulties related to the maintenance of a mobile application is the management of its updates and different versions.
Unlike a website that is updated (almost) in real time for all users, updating a mobile application goes through a set of steps:
validation by application stores
propagation of new versions on the Application Store servers before they are actually visible to users
the user’s willingness to perform a manual update or the good conditions (typically device charging and wifi) for triggering an automatic update (if enabled)
Some cross-platform solutions allow remote applications to be updated almost instantaneously (e.g. the next time the application is started). This can be very useful if you need to distribute a patch urgently or if the application is not distributed via an application store and therefore does not have an existing update mechanism.
However, it is also appropriate to temper and expose the limitations:
Only the cross-platform part can be updated. If an update of a native component is necessary, the application will have to be updated classically.
Application stores that require validation of applications and their updates (typically Apple), could view these systems in a negative light and as a way of bending the rules, exposing the application and its publisher to sanctions.
The possibility of remote code modification is an additional security risk to be taken into account.
The management of updates is more complex and the risk of error is greater. In case of a partial update, a complete update will still have to be published on the classic update channel. It is also necessary to check that the partial update is compatible with the targeted versions (for example, that the native embedded components are compatible with the update).
A few questions to ask yourself:
Is my application published to an application store that does not offer an automatic update mechanism or is it not published to an application store? Some application stores offer solutions to encourage the user to update your application or even update from the application (for example [in-app updates from Google](https://developer.android.com/guide/app-bundle/in-app-updates)). In this case, the support of a third-party and partial solution (not allowing to update the native part) is of little interest.
Does my project need to have an automatic remote update mechanism? The validation time of applications by application stores has been reduced from several weeks to a few days. It is important to keep in mind that support for partial remote updates is not totally free and will have an operating and maintenance cost in terms of the development team’s working time.
Platform-specific features
Cross-platform solutions unify rather well what all platforms have in common: downloading data, displaying graphical components such as lists, images, buttons, etc.
However, features that have a large differentiating factor or that are absent from some platforms are much more complex to unify.
For example: background processing, notifications, widgets, APIs specific to application stores (in-app purchases, etc.), support for specific devices (connected watches, televisions, etc.), low-level APIs, etc.
A few questions to ask yourself:
Does my application need features not ready to use in the solution I’m considering?
Are these functionalities feasible within the framework of the studied solution and at what cost?
Are there third party libraries that meet the needs of the functionality? Are they maintained and of high quality?
Is a workaround possible?
Support and community
The health of a multi-platform solution is directly related to the efforts and support of its sponsor and main contributor.
The risk is to choose a solution that will later be abandoned or neglected, leaving your project with little hope of being able to continue to evolve without a complete rewrite.
Another important factor is the responsiveness and speed with which the solution adopts the new features of the native platforms and fixes its known bugs. What happens if the solution maintainer decides that it is not appropriate for them to support certain features or fix certain bugs that your application depends on within a timeframe that is acceptable to you? Will you be able to address these shortcomings yourself?
Other major contributors, sponsors or users are also an indicator to be taken into account. Nevertheless, recent history has shown that some large companies that invest very actively in multi-platform solutions can make a 180-degree turn a few months later by abandoning them completely. Popularity is an indicator, but be careful not to fall into an argumentum ad populum.
Finally, the health and dynamism of the ecosystem is a factor to be taken into account.
Are there quality third-party libraries available to meet the needs of users not supported by the solution? Unfortunately this is one of the pain points of multi-platform solutions, especially when compared to the quality and diversity of third-party libraries available for native platforms. The reasons are simple: first of all, these solutions are less popular than native platforms. Therefore, there are fewer developers willing to contribute. Secondly, building a cross-platform library requires knowledge of the cross-platform solution concerned but also of the native platforms it targets. To unify native behaviors or features requires a very deep knowledge of the underlying platforms. It is therefore not uncommon to see so-called “cross-platform” libraries that really only support a single platform.
A few questions to ask yourself:
Is the solution open source?
Does the solution have any known unresolved bugs that could impact your project?
Is the solution actively supported by its creator or main contributor?
Is the community around this solution dynamic and active?
Is the solution popular or declining?
Are there quality libraries that my project needs that are actively supported?
Does the creator listen to the problems its users may encounter?
Is the solution well documented?
Homogeneity between platforms and OS versions
The current native mobile ecosystem has been in existence for about ten years.
The design, features and behaviors have evolved through different versions of operating systems. Fortunately, the active fleet is not as old, but may still include devices and operating system versions that are five years old.
The challenge is to ensure that an application will react the same way on all versions of a given platform.
This is a common problem in native development that is addressed differently depending on the manufacturer. For example, since Android suffers from a slower adoption of the latest versions on the majority of mobiles (often called Android fragmentation), Google invests a lot in so-called compatibility libraries in order to bring new features to older versions of the system or to simplify graceful degradation. Apple, on the other hand, not having this fragmentation problem, tends to more or less force the adoption of the latest version of its operating system by users and developers, leaving the latter to manage the differences if they want to maintain some backwards compatibility.
Multi-platform solutions multiply this problem.
It is no longer a question of guaranteeing homogeneity across a single platform but across all supported platforms.
It should be noted that all do not have the same strategy at this level. Some choose to do nothing. For example, a single button may have a different rendering between different native platforms and between different versions of the same native platform. Others choose to invest a lot of effort to guarantee a certain homogeneity and simplify the work of developers.
Keep in mind that the visual aspect is only the tip of the iceberg.
It is the subtle differences in behavior, present in borderline cases and difficult to identify upstream that can seriously impact your project.
A few questions to ask yourself:
Is user interface consistency important for my project?
Does the studied multi-platform solution guarantee a homogeneity of the user interface and behaviors across different platforms and operating system versions?
Loyalty and integration within target platforms
While it is important that your application has its own visual identity, it is equally important that it respects the philosophy and codes of the target platforms.
Navigation, the physics and dynamics of interactions, the use of certain icons, typography and the alignment of certain elements are all biases of the designers of the native platforms that serve as reference points for users.
It is not a question of making a value judgment on the choices made.
One may prefer the bias of one platform or another but it is in the interest of your application to respect them as much as possible. Otherwise, it will give the user a feeling of dissonance, lower quality, lack of professionalism, or lack of consideration for the target platform and therefore its users.
In short, users don’t care about the technology you choose to develop your application as long as they don’t realize it.
A few questions to ask yourself:
Do the applications produced by the cross-platform solution respect the code and integrate easily into the target native ecosystem?
Are the applications produced by the cross-platform solution easily distinguishable from native applications?
Does the solution allow differentiation by simple or complicated platform?
Tooling
Native development tools are today not only free of charge but of very high quality. Google and Apple are constantly improving these tools to increase the productivity of their developers.
This is an extremely broad subject. We can mention for example: auto-completion, debugging, static code analysis, test management, profiling, …
Even if in theory a simple text editor is enough to write an application, the support of professional tools increases the comfort and productivity of your development team. It is therefore a crucial point to take into account.
A few questions to ask yourself:
Does the studied solution offer stable and high quality development and debugging tools?
Does the solution studied fit easily into a continuous integration process?
What impact will the solution have on the organization of your source code and version management software?
Does the studied solution facilitate or complicate unit and integration tests?
Ease of bridging with the native part
It is likely that sooner or later, cross-platform code will have to interact with native code.
For example, a native functionality not supported by the cross-platform solution will have to be developed or a third party library (advertisements, statistics tools, etc.) that does not support the chosen solution will have to be driven from the cross-platform code.
To address this issue, most cross-platform solutions provide “bridges” between the native and cross-platform parts.
Two types of bridges can be identified.
Those that allow the use of native graphical components in the cross-platform solution and those that only exchange data.
The former are generally more complicated and may pose more problems for some multi-platform solutions than the latter. Nevertheless, using a bridge can have a certain cost in terms of performance depending on the solution chosen.
A few questions to ask yourself:
Is it easy to develop a bridge between the cross-platform solution and native platforms?
Do bridges and especially graphic bridges have any particular limitations?
Does the use of bridges have an impact on performance?
Speed of development
One of the promises of multi-platform solutions is the ability to develop an application that targets multiple platforms at the same time faster.
But what about the time it takes to develop an application on a platform?
In other words, does the studied solution allow to develop and iterate faster or slower than with a native approach?
Tooling plays an essential role here, but the choice of language, architectural models or certain functionalities such as hot reloading can really influence development time.
A few questions to ask yourself:
Does the solution studied facilitate or complicate development?
Does the solution studied offer reliable hot reloading?
Reuse of skills or technologies
Some solutions emphasize the use of a language or technology known in other contexts.
The promise is to be able to reuse hard-won knowledge and have to learn little or nothing.
Although using a language or a known technology is comfortable, basing one’s choice of cross-platform solution primarily on this criterion would be a mistake. Performance, power consumption, size and fidelity are far more important to end users than the technology used.
Architectural languages or models are only the tip of the iceberg. A language can be learned in a few days (or even less) and this is nothing compared to the cost of a bad technical choice in the medium and long term.
All multi-platform solutions, even those based on web development methods, have non-trivial specificities that need to be understood.
Developing a multi-platform application requires a good knowledge of the target platforms. Any project that is a bit complex will require, sooner or later, the development of a native bridge. Some technical choices will be much more enlightened if the development team is aware of the strengths and weaknesses of the underlying platforms. Multi-platform development teams must, therefore, have even more of that curiosity that characterizes good developers.
Unfortunately, some fall into the trap of apparent ease and praise technologies (good or bad) for the wrong reasons.
In summary, the possibility of reusing previously acquired skills is a plus but should not overshadow the more important factors related to the quality of the applications produced by the solutions studied.
A few questions to ask yourself:
Does the studied solution allow the reuse of available skills of the development team?
Does this represent an appreciable and quantifiable gain?
Does the solution studied involve a training cost for the development team?
Is it easy or difficult to recruit experts in the studied solution?
Sharing business logic and user interfaces
Some cross-platform solutions allow to share only the business logic, others allow to share both the business logic and the graphical interfaces, some still allow to share the business logic but require to write graphical interfaces specific to each target platform in a common language.
Each approach has its advantages:
Sharing only business logic is appropriate if your application has complex business rules. Indeed, this sharing will have a cost in terms of reflection (you have to think about several platforms in parallel), integration (how to reflect a change in the business logic in the platform-specific part) and organization. Nevertheless, it is the solution that also offers the most flexibility.
Sharing the business logic and graphical interfaces is the solution that allows the best economy of scale provided, of course, that this solution does it well (performance, fidelity, …) and that the chosen compromises suit you.
Finally, sharing business logic and writing platform-specific GUIs in a common language is of little interest in itself. It has both the disadvantage of having to write the GUI code as many times as the desired platforms and of being dependent on the chosen solution to use native functionalities. The only advantage is to be able to use a single language but, as already explained, the gain is not obvious.
A few questions to ask yourself:
Is the business logic of my application complex?
Does my application have specific rules according to platforms?
Do I only want to share the business logic or also the user interfaces?
Does the solution slow down the development and iteration cycle?
