Our Journey towards Cross-Platform Development
Mobile apps are now almost second nature to us. They’ve streamlined our day-to-day activities and made our tasks easier.
We at Freshworks offer a mobile app version of every product in the Freshworks suite. Initially, we developed all the apps on our native platform. However, as we grew rapidly and started adding more products to our suite, it became increasingly difficult to replicate our rich features over different mobile platforms––Windows, iOS, or Android.
The fix for this was cross-platform development that would enable us to maintain a single codebase and apply it across various platforms.
However, this was a road less traveled, and embarking on this would bring about a paradigm shift in the way we built our products. It could mean that we lose out on libraries that have already been tested. It also would change the way we worked on a problem and analyzed it.
But on the other hand, with the right tool, we’d be able to improve our performance and efficiency, and reduce our spend on tools and technologies used to develop mobile apps.
Cross-platform development is still a dream for many companies, but quite a few of them have pulled it off successfully. For instance, Google Inbox shares 70% of its code between their web, Android, and iOS apps.
We decided to look into what these companies had done and find the framework that would work best for us.
Google Inbox uses java2objc, a tool that produces Objective-C code from Java, to share code between their mobile apps. Java2objc would replicate the logic written for Android in the iOS version. Similarly, Dropbox uses Djinni, a tool that can interface C++ with Java and Objective-C; the shared logic is written in C++ and Djinni enables Java and Objective-C to tap into it.
But there seemed to be no clear front-runner. So, we set out to conduct a trade study that would help us find the framework that meets our requirements.
Conducting a trade study
A trade study is a process that allows a team to pick a solution from a list of viable options. Here’s how we did it:
- Shortlisted frameworks
- Identified parameters to grade these frameworks
- Eliminated frameworks based on these parameters until we were left with the one that best worked for us
Frameworks:
We picked frameworks that would help us build native apps and not hybrid or HTML5 applications. We also ensured that the frameworks supported code sharing and could co-exist with our codebase.
These are the ones we considered:
Flutter
Flutter is Google’s cross-platform SDK that uses the Dart programming language to write applications. Flutter allows a single codebase to create applications on multiple platforms. Hot reload works seamlessly and there are also provisions to interop with existing codebases. While we were evaluating the framework, Flutter was in alpha. Despite this, Flutter had a excellent documentation, examples, and support.
React Native
Facebook’s React Native has the same design principles as React (a web framework maintained by Facebook) and uses Javascript (JSX) to build native mobile applications. React Native works smoothly with existing views and components written in Objective-C, Swift, or Java. It also has very good debugging tools and support for hot reload. React Native gained a lot of traction as it opened up a whole new world for web developers in developing mobile applications.
Xamarin
Microsoft-owned Xamarin lets users build native mobile applications in C#. Xamarin IDE allows for native Android, iOS, and Windows app development within Microsoft Visual Studio. The apps have a shared app and view logic that enables developers to still access platform-specific system APIs, and Xamarin also comes with a visual editor for user interface development, something that is missing in other frameworks we evaluated.
In addition, Xamarin has numerous examples that aid learning––Xamarin University facilitates easy learning of C# and building cross-platform mobile applications.
GoMobile
GoMobile is an experimental framework developed by the Golang team at Google. It was built to showcase Go’s ability to build mobile applications. GoMobile can be used to either build a full-fledged application in Go or build an SDK that can work with existing Android and iOS Apps.
Evaluation:
Here’s how we evaluated each of the frameworks:
- List parameters
- Grade each parameter based on a set of requirements, with reason/code (wherever applicable)
- Rank each requirement and assign weights
- Compute final score (Sum [Weight * GradeValue])
Performance
We carried out tests to measure how a cross-platform framework performed compared to a native framework. We did this by building the same application in different frameworks and compared it with a natively-built application. We measured performance based on these sub-parameters:
- Frames per second
- Startup time
- Memory allocation
System APIsIt was clear that cross-platform frameworks had similar performance numbers and didn’t have any serious drawbacks compared to the native applications.
We wanted to evaluate if the framework had a support to access system APIs like camera, VOIP, and file storage. A lot of our business use cases revolve around sharing documents and collaboration, so an easy access to APIs that enable this was critical.
Availability of testing libraries
We checked the availability of testing libraries for generating coverage reports, building a test suite, and working with mock data because a key component of our development workflow involves having the comfort of test cases, and catching bugs and issues early in the development cycle. We also considered compatibility with existing UI testing tools.
Error and crash reporting
We were keen on this feature because a cross-platform solution generally involves jumping between languages, and it is essential that error and language traces are easily accessible to investigate bugs and issues.
Tech maturity
We checked if the framework was in alpha, beta, or production. A battle-tested and production ready framework would rank high in this category.
Code reuse and coexisting with the current codebase
We considered this parameter to see if we could use our existing libraries and utils with the new framework, and also isolate features without the need for rewriting the existing codebase.
Developer community and developer happiness
A strong developer community makes troubleshooting easy. Considering that we would be developing in a new environment, it was important for us to check the support for the framework, and the availability of debugging tools. We also checked if we had access to how-to articles, blogs, and tutorials as we would be onboarding a fairly large team.
Onboarding a new team and prior experience with the language
This parameter was very specific to our team at Freshworks. The team comprises Java and Objective-C developers, and introducing a new language result in a significant change in the way the team worked. Our testing and deployment process would also have to change to accommodate the framework, so it was important for us to consider this aspect as well.
Grading and Ranking Parameters:
The next step in our study was to grade and rank parameters. We gave every parameter a minimum requirement and assigned grades based on how close or far they were from the requirement.
This helped us to give every framework an overall score and also provide a point of reference to understand why a certain framework was selected.
We ranked performance, developer happiness, and the ability to co-exist with our codebase very highly because we felt these parameters had a significant impact on what we wanted to build and how the team functions. This ranking can vary depending on a team’s goals.
We, however, understand that these frameworks are evolving and we plan to revisit these periodically and update our metrics.
Conclusion:
Upon evaluation, we saw that GoMobile was the ideal cross-platform development framework for our needs.
GoMobile allowed us to continue using our UI Libraries with very little change to our workflow, and allowed us to share business logic between iOS and Android. The learning curve was also considerably less compared to learning C++ or understanding the nuances of Javascript.
Conducting the trade study has been beneficial in multiple ways in addition to helping us zero in on the framework we wanted to use.
We spent a lot of time coming up with a decision-making framework because our choice would alter the way the mobile development teams work on a day-to-day basis. It would also have an effect on the way the teams are structured, tasks are prioritised, and roadmaps are laid out.
The process has enabled us to factor in a continuously changing landscape, and if we come across another promising new cross-platform solution, we are now equipped to evaluate that in quick time.
It has also left us with valuable business lessons.
When we initially set out to choose a cross-platform solution, we focused on the technological aspects of the solution, but during the evaluation, we found that we needed to keep our business and organizational aspects also in mind for engineering, product owners, and customers to reap its benefits.
