Let’s entertain a simple scenario for a second:

You’re a solo developer. You have an idea. You tell the idea to your friends. They like the idea. You design a prototype. You spend months on design, code, art, marketing, and then the time comes for you to release it.

You push it out to the world and share it with everyone you know. Then, you get the all too familiar question…

When is this coming to Android?

So you stop for a minute and think, “hmm… it seems people want this on Android too. What would this actually take to implement”? And so you look it up and discover that:

• You’ll need to learn a new set of steps for deployment
• You’ll need to learn a new UI toolkit
• You’ll need to follow a new set of human interface guidelines
• You’ll need to learn a new programming language!!!
• You’ll need to learn how to sync two separate deployments every time you want to add a new feature.
• You’ll need to master the new payment API, and push notification API, and page routing API, and… you get the point.
• In the end: You’ll need to completely rewrite every single line of code from day 0 to today

But, what if there was a solution to this? Well, there is, and it’s called cross-plaform app development

What Is Cross-Platform App Development?

Cross-Platform development is the idea that you can use 1 codebase and deploy it to multiple platforms at once. Usually, this is done by programming your project 1 time in a language like JavaScript, then using a WebView to embed that javascript code into your mobile and desktop apps.

The WebView can basically be thought of as basically a web browser with the borders removed that just shows the content of the page. It will end up looking something like this:

By designing an application like this means you only have to write code once, so the productivity gains can be massive. Think about it like this:

If n is the number of platforms you support, when you write native code for each of these platforms you’re basically developing at O(n) speed. When you develop using cross-platform technologies, you’re now developing at an O(1) speed since you don’t have to do much more work to make the app for more platform. Now wouldn’t that optimization look impressive in a coding interview?

Okay, so if there’s so much to gain by developing cross-platform apps, why doesn’t everybody do it?

Well, it’s because cross-platform development, just like any technology, doesn’t come without it’s downsides.

The Downsides of Cross-Platform Apps

When you opt for a cross-platform solution, there’s almost always going to be a tradeoffs in terms of speed, support, and stability versus building a native app for each platform. I think these downsides can be easily overlooked, so here I’m going to list some issues you might come across along the way:

Cross-Platform Apps are slower

Building a cross-platform app means there’s an added layer of abstraction that your code has to run through. I’d say for most apps this difference is negligible, but it still might come into play.

Deployment Can Be More Complicated

It’s easier to deploy new features when the codebase for different plaforms is silo’d off from one another. Each platform can have their own launch schedule, testing procedures, and pipelines, but when everything is tied together you have to find a good solution for managing everything.

Limited Functionality

Most cross-platform solutions have a good repository of libraries for doing native operations. Examples include push notifications, popups, UI-matching etc. This is amazing, but I’ve yet to find a solution that fully encompasses all the possible native functionalities.

This might limit certain apps, but won’t be a problem for most use-cases. If you’re not sure if this will effect you or not, it probably won’t. I’d say 98% of use-cases can be done perfectly well through cross-platform.

So now that you know the drawbacks of cross-plaform apps, lets get into my preferred way of building cross-platform apps.

Which Cross-Platform Framework Should I Use?

There’s a lot of different solutions for building cross-platform apps. You have quite a few popular solutions such as React-Native, Cordova, Ionic, Capacitor, Flutter, so the decision isn’t an easy one. I’m not going to discuss the tradeoffs between these in this article, but here’s some good articles that compare the differences between these alternatives:

• Cross-Platfrm App Frameworks in 2019 by Amit Manchanda
• 7 Popular Cross-Platform App Development Tools That Will Rule in 2020 by Sophia Martin

Instead, today I’m going to talk through the framework that I believe is the best, and why it’s been a pretty amazing stack to work in.

The Cross-Platform Tech Stack I recommend

At Pwego, I consistently work with companies to optimize their cross-platform deployments. When asked what tech stack to use, my recommendation is usually the same. This is the reasoning I usually give.

A lot of React developers would opt for something like React-Native. I decided against this because I didn’t want to write any native code at all. I also didn’t want to deal with compatibility issues with other React libraries that I might want to include, so I went with Ionic

Ionic released its version that officially supported React back in October 2019. I was an early adopter to this release, and started using it a month after it’s released. I’ve now been on the technology for 9 months and although it’s had some issues, I think the technology has come a long way. Here’s some of the things I love about Ionic + React:

• It’s deployable to everything. iOS. Android. Electron (desktop). Web. Etc.
• I’ve never had to write any native code.
• I can test my code and develop it in the browser, then when I’m ready to test how it works on mobile, I can build the code and test it directly in XCode/Android Studio
• Ionic is now framework agnostic
• There’s a repository of ionic react-hooks that give you an easy interface for a lot of native capabilities

Here’s a rundown of the other pieces in my cross-platform tech stack.

Ionic

Ionic is basically a UI kit of different generic components that you can use in your web code to have native-looking features in your app. It offers generic components like an <IonButton> that might look like this on iOS:

and this on Android:

The difference between these may look small, but it’s meant to make your application look and feel native no matter which device you’re on. I think this has it’s tradeoffs because your UI won’t always be consistent across platforms. For example, on iOS those buttons are slightly bigger which means your UI will look different on both platforms.

This is annoying at first, but over time you’ll learn the oddities of each component and what they look like on each platform, and then it’s much easier to work with them.

I’ll also note that these Ionic components are generic, so they can be used paired with React, Angular, Vue, or even no framework at all. This is very powerful because it means you won’t be locked in to a frontend framework as-well if you choose this technology. In my opinion, this is a large benefit over something like React-Native, because it future-proofs the technology much better.

React

React is the most popular web framework, pulling ahead of angular by a greater margin every single day. I first started pairing Ionic + React in 2019 within a month of Ionic being supported on React. Through this process things have become far more stable, so now I feel comfortable recommending the two technologies together.

Capacitor

The React code is what will get displayed in the “WebView”, and it will use Ionic components to mimic native the look and feel of native components. Then, Capacitor comes in and acts as the “build step” that will take that web code, bundle it into an app and then toss it into Android Studio or XCode for you to configure further.

Firebase Cloud Messager

On the backend, I like to use FCM because it gives you the same cross-platform capabilities, except this time it’s with your push notifications. If you didn’t know, android and apple both have their own push notification services. If you want to send out a notification to all your users, you’d have to write the API calls twice to upload that notification for both services.

Using something like FCM, you can have 1 single API to upload push notifications to, and then they’ll get forwarded to all the different notification services for the platforms your users are on.

Ionic Appflow for CI/CD

I’ll admit, I haven’t use Ionic Appflow yet, but I must say the technology looks attractive. One of the really interesting features to me is their idea of “live deployments”.

Basically the idea here is to let you push new web code to your mobile apps without having to push a new release to the stores. This means you can use their CI/CD platform to just push new frontend code once and have it automatically be update the website and every single user’s app. That’s insanely powerful if you think about it! Not only do you only have to write code once, but you only have to deploy it once too.

If AppFlow was free, I’d give it a try right now because that’s a super attractive service for small development teams.

Conclusion

In the end, there can be quite a few tradeoffs you’ll have to make with a cross-platform solution, however the downsides can be minimized by choosing a proper tech stack. Using something like capacitor is going to give you a really solid way to embed your web apps into native code. But combine that with a cross-platform CI/CD platform like AppFlow and a nice UI-kit like Ionic and you can end up with a solid app. Enjoy!

Want to bring in expertise to guide your the cross-platform solutions at your company? I run Pwego, a SaaS & cross-platform consultancy that specializes in exactly that. Let’s get in touch and discuss your use-case!