Choosing Cross Platform Development for Your Mobile Project

Erik Wolfe | 06/04/2018

Save time, save money, share code between platforms: this is the goal of a cross platform solution. Many companies have tried to solve this problem to varying degrees of success with widely different approaches. Every couple years there’s a “new kid on the block” that seems to improve on the previous tech, or take a novel approach that pushes the concepts further. The problem is there’s no “one size fits all” solution, so many developers stick with what we commonly call native development. The mere mention of cross platform options makes many native developers feel uneasy. This feeling stems from valid concerns that must be considered before diving in and staking the future of your app on this tech; concerns that are often times overlooked when asked in a meeting “why do we have to write this twice?” If we lay out common considerations that we must address before adopting a cross platform solution, then you: the developer, manager, stakeholder, will be armed with the talking points to make an informed, researched decision.

New Tech

A consideration that should never be taken lightly when considering a cross platform option is new tech the team will need to learn. If you’re a web shop using React, you should probably look at React Native to start, if you’re not using React, does Cordova make more sense? What about a progressive web app? What if you’re coming from a C# background? You’ll probably start looking at Xamarin. Just want to share some business logic between apps and want to keep the UI native? Maybe J2ObjC or Kotlin/Native is the best approach. Or if learning a new language to share 100% of your code sounds fun, check out Flutter. The point is, where you’re coming from could inform where you go next.

Does the team already know the language? How about Platform?

It’s incredibly valuable to consider the skills your team already has before jumping into a cross platform option. There may be an option that will benefit from the team’s current skills, and greatly reduce the learning curve. This can also reduce or remove the need to hire more developers for the apps as you’ll have a the in-house talent already.

What does the support look like? Is there an active developer community?

Many software developers love to solve hard problems, but that doesn’t necessarily translate into solving tedious problems like a tool not working as advertised or a framework bug you’ll have to hack around. Consider the support landscape of whatever language and platform you’re considering, especially if this will be new tech to the team. Will there be community support when you get a cryptic compilation error? Take a look at Stack Overflow questions, blog posts, meetups, GitHub repos, etc. If there seems to be an active, dedicated community, that’s a good sign.

What does the build/release process look like?

Not all build systems are created equally. You’ll want to make sure that there’s good documentation around building, debugging, and releasing for all target platforms. Ultimately the IPA and APK will be created using the native build tools, but you’ll want to make sure you are able to interact with those at some level to make your life easier.

You’ll want to use CI (you are using CI right?) to test and release, so confirm your CI solution supports this platform, or there’s one you’re willing to switch to that supports it. What we don’t want to do is adopt this new tech, and then fight every step of the release process to use it.

Is this tech a core competency of the company, or a competency we wish to grow?

If the tech is already a core competency of the team, then skilling up on the mobile side probably makes sense. If not, does learning this tech support company goals in other ways? Ideally this is a tech investment that will be valuable for years. It’s important to consider where you see the app going. If this is an MVP and the plan is to rewrite in a year, then the path of least resistance may be the right one. On the other hand, if you want to build a product that can grow with the company, then choosing a tech that will be easier to support long-term may be more important.

Long-Term support

Prospecting is always part of the decision when considering a new or different technology to solve a problem. We naturally don’t want to spend time and money on a tech that will be dead soon, or that is already on its way out. It’s important we consider the maintainer’s track record (do they cancel projects often), if the project is open source and would we be comfortable maintaining it if needed, how about documentation? What we want to avoid is building a product on tech that will have little community support or won’t support the products in the coming years. The following questions can be hard, if not impossible, to answer, but are important to discuss to make an informed decision.

Can this tech grow with the featureset?

Hopefully, you have some concept of what you want the apps to do. If the featureset you’re planning uses things like Maps, AR, camera, audio processing, video editing, complex animations, etc. then make sure you understand what that means to the cross platform solution. Some may not support the libraries you want to use, or will require groundwork to be laid by the team. Do you have time to do this? What about targeting latest platform APIs? It may be important to consider what the delay between target platform APIs and the cross platform supporting those APIs is. These kind of issues can quickly reduce the benefits the cross platform option promised.

How difficult is it to add native support?

If updates to the cross platform aren’t covering an area you need to develop in, writing native code may be the answer. The triviality of that endeavor may be a deciding factor for your team. Hopefully, you can write it in the proper IDE and the workflow isn’t greatly impacted. Ideally you can write something that can be easily maintained by the team, or even better something that can be shared with the community. You might even be able to build a portion of the app with a cross platform tech, and the rest in native. This capability makes the cross platform discussion much more complex because it’s not an all-or-nothing discussion now.

What’s our goal for this tech?

Sure, right now the MVP for the project is a list of local restaurants, but maybe the ideal app is far more advanced. Does our choice support that? Some apps get re-written multiple times, but that’s not always an option. Consider the roadmap of the application, and whether or not the potential speed of the MVP outweighs the tech debt you’ll pay on the next feature. If you’re building a proof of concept, then maybe this tech is perfect because it’s easy to move fast, and it checks all the boxes today, and you don’t need to worry about tomorrow.

Is this a desirable platform developers will like working with?

Admittedly a subjective question, but informs how difficult it may be to find developer support in the future. In this business, people move around a lot, and building a product on the tech an old employee swore by could make future developers cringe and avoid the project. Start with the Stackoverflow survey results to get a feel for how developers regard the tech. Read blog posts on both sides of the fence, and remember there are always fanatics and naysayers. If the tech isn’t favorable, then it could be challenging to find talent making maintenance a nightmare. Obviously, the more popular the tech is to developers, then the easier it will be to find talent.

Tooling

Whether it’s development, testing, debugging, or building, the devs will be reliant on robust, predictable tools to get the job done. Even with the most popular tools for native development, you’ll hear legitimate gripes about how minutes or hours can be wasted trying to solve a problem. Part of having a great platform is having great tools to support it.

Is the IDE stable?

You’ll want to make sure the IDE is stable for you and your team’s operating system. If it’s not stable, does dual booting mitigate the problem, and is it an option? Is the UI acceptable, how about customization options? Your team will be spending most of their time in this application, it should help them.

It’s also worth checking out the plugin/extension options for the IDE. There are typically a multitude of plugins a developer can use to customize their developer experience, and these often times will save time, or make the IDE more enjoyable.

Is it testable?

Some cross platform options are incredibly testable, and others are a little more difficult. If testing is important to the team, then make sure you look into this. The more code you can test, the fewer regressions you’ll have. Take some time and confirm there are unit testing and integration testing tools. Again, you don’t want to adopt a tech and then have to write all the tools to use it the way you want to.

Are there OSS libraries that solve common problems?

Open-source software is a huge asset to any tech, so it can be a deal breaker if there’s not an active community. Make sure to take into account the amount of development that will be needed to build out your own solutions to common problems, and of course the time you could save using open-source software. If there’s a thriving community and active support from the maintainer, this is a huge benefit and a good indicator of platform longevity.

Performance

This can be tricky because usually the answer is “it depends on what you’re doing.” If you can find case studies that explore the types of features your app will support, then that’s a great start. If all else fails, the highly unscientific approach of spiking on the feature and comparing how the results “feel” may help. There are a few questions that may help figure this out.

Are animations smooth?

Animations are a common bottleneck with cross platform products, so consider how would like to use animations in your app. Transitions, scrolling quickly, touch feedback, and other effects we may take for granted with native, may not work as well with a cross platform and could end up making the app feel slow and boring.

What about cold start time?

Developers work hard to get the start time to a minimum with apps because it reduces the user bounce rate and is a reflection of code and architecture quality. If a platform is going to add time to a cold start or a resume, then that could be a difficult problem to overcome. You may be able to find average start time comparisons.

Does the performance impact the app?

You can find performance comparisons that may surprise you, but ultimately, does it impact the app and user? There may be negative results around database read/write, but if your app’s not going to use that, or use it rarely, don’t consider it a problem. Performance must be analyzed holistically to determine its impact. Figure out what’s “good enough” for your project.

What now?

None of these questions should be considered in a vacuum, and only you and your team can really weigh the importance of each one. You should spend time exploring and answering each of these questions before investing time and energy into something that’s potentially a bad fit. Some answers may be relatively ambiguous, and that’s OK because this isn’t an exact science, but the general takeaway is that you’ll ask often overlooked questions early to arrive at a more educated decision.

Cross platform solutions exist to decrease development time and cost by sharing code, but those savings are dependent on many variables that may not be apparent to stakeholders. Through your research you may find the answers to these questions surprising, and you’ll probably come away with a better understanding of why many developers choose native over cross platform. The sad truth is that every approach solves some problems, and creates a few of their own. Understanding those problems is where you’ll find the best option for the team. Hopefully now that frustrating question: “why do we have to write this twice?” will really be an invitation to a more productive conversation.