‘Write once, run everywhere’, sharing code across platforms — Considerations

Ashish Pathak
android-core
Published in
6 min readMar 17, 2021

Lots of people want to share code across platforms. ‘Write once, run everywhere’, they say. For example, write C++ code once and run everywhere; like on Windows, Linux, Android, iOS, IoT devices etc. Or write code with JVM based language like Java or Kotlin and share it across platforms which support JVM. In theory this sounds fascinating. After all, Who wouldn’t want to reuse their code?

In my humble opinion though, this option should be exercised with caution. It may not always be a great choice. This is not to say that it is always a bad choice because there are certain use cases which demand this. What could be parameters affecting this decision though?

I believe, following parameters could act as guideline to decide whether we should be sharing code across platforms? Or not?

Platforms to be supported: This sound obvious, but I have personally worked on projects which started with intention to support only the Windows and Android in the beginning and then decided to support iOS, Linux and IoT devices as well.

People availability for that skill: This is one of the major factors in deciding whether we want to use a given language or framework to share code across platforms. For example, in theory, one could argue that the C++ language can be used to write the common functionality and be shared as shared libraries across platforms. Then, the respective platform and programming language use this shared C++ code to benefit from efforts already spent. However, anyone hiring for C++ programmers would know how hard it is to find good C++ programmers. It is relatively easy though to find Java/Kotlin/Javascript/Dart programmers on the market. So, to rip benefits for code sharing across platforms, one must consider how easily people expert in the given language or the given framework are available.

Popularity of the language or framework: How popular is the language and/or the framework in the market? This also affects how many software developers will be willing to acquire that new skill. For example, people willing to adopt language like Kotlin or framework like Flutter are more than people willing to pick up say C++ or Java. In the long run, this affects how we run the project and find people to maintain the project specially after the core team members have moved elsewhere.

Functionality to be supported across platforms: When we want to write common code which should be shared across platforms, we need to think long and hard what all functionalities do we want to share. Do we want to write common code for only HTTP requests? Do we want to share UI components? Do we want to share persistence layer? Anything else? This vastly affects the language and/or framework choices. Some platforms may not support the HTTP client you are using, or the encryption algorithm you want to support, or the UI framework may not be compatible because rendering depends on the platform specific details, storage is handled in a platform specific way.

Though most languages provide a way to hook into the platform specific code, it is not a trivial task. Also, platform specific nuances may demand different design altogether limiting our ability to write truly common code.

I would like to quote an example where using shared code in my opinion was not a good choice and another example where using shared code really paid off.

I worked on the legacy MDM agent recently. MDM agent is a Mobile Device Management software used by enterprises to make sure that the devices their employees are using are compliant with organisation policy or not. MDM agent also allows the organisation admin to remotely control or wipe the device. It also helps in collecting telemetry data. In that project, they had made a decision to use C++ to abstract out the calls to the server because, “C++ is platform agnostic and device agnostic”, they said. To be fair, they had developed Windows agent first and then the Android agent. Hence, I think using C++ as shared code could be an afterthought. When the project came to us, everyone was finding it hard to find skilled C++ developer who have basic knowledge about Windows and Android. Also, because the HTTP client they had used for windows did not work on Android, they had to use lot of ifdefs and write platform specific code in the shared common code. Then they introduced MQTT adding more complexity of keeping connection alive continuously. Granted one could have used boost libraries or something similar but not many people fully understand how to build that for multiple platforms(Android for example). MDM agent anyway requires many platform specific functionality to perform its task of enforcing policies set by EMM portal. In this case, it would have been better to write separate code for separate platform because, what was there in the shared C++ code is easy enough to implement on any platform. Finding people with C# and say Android native app development skill is certainly easier than finding people who know C++ well and have basic knowledge of Windows and Android. Even picking up C# and/Android native app development is relatively easier and has more future prospect than say learning C++. Also, there is not much to gain by sharing just about 10–20 API calls to the web server. If we compare, only about 10–20% of the code was shared and supposedly common. For such situation, I believe, going with whatever is the platform supported way of doing stuff would have been better approach.

Compare this with say a banking mobile application.Using a cross platform framework which works across platforms would be a better choice here. For this project we had decided to go with Flutter. For most banking applications, it is sufficient to share business logic, API calls and UI rendering. Not much of the platform specific capabilities are needed. People with Flutter skill are not very easy to come by but not too difficult either. Also, there are many people who are willing to pick Flutter. What we also found was that it doesn’t take much time(2–3 weeks) to pick up Flutter for a programmer who understands object oriented programming and is somewhat familiar with mobile apps. Flutter also allowed us to share business logic, API calls, UI rendering etc. With this, we had about 80–90% code in Flutter(Dart programming language) and 10–20% code in native implementation(Kotlin for Android and Swift for iOS). So, team wrote this code once and are running on both iOS and Android and there is a real possibility that it can be ported to other platforms as well without introducing much of platform specific code. For such cases, the clearly makes sense to share code across platforms.

As I said before, it all depends on the use case. As a guideline, it may help to ask following questions before we start sharing code across platforms:

(*) What all functionality do we want to share?

(*) What could be a motivation for people to pick that language or framework on the job?

(*) Why do we want to share that functionality across platform?

(*) How many percent of the total code is shared code?

(*) Approximately how often will we have to rely on the platform specific functionality in the shared code?

(*) What benefit are we getting by sharing that code across platforms? Is there a business problem it solves by doing that?

If you choose to share code across platforms, think long and hard about it, try to answer all above questions in as many details as you can fill in. Performs some spikes to verify your assumptions and then make an informed decision on whether you want to share the code join the ‘Write once, run everywhere’ club.

--

--