Cross-platform mobile development refers to the development of mobile apps that can be used on multiple mobile platforms. In the business world, a growing trend called BYOD (Bring Your Own Device) is rising. BYOD refers to employees bringing their own personal mobile device into the workplace to be used in place of traditional desktop computers or company-provided mobile devices for accessing company applications and data. Because of BYOD, it has become necessary for businesses to develop their corporate mobile apps and be able to send them to many different mobile devices that operate on various networks and use different operating systems.

​

     Cross-platform mobile development can either involve a company developing the original app on a native platform (which could be iOS, Android, Windows Mobile, BlackBerry/RIM, etc.) or developing the original app in a singular environment for development that will then allow the app to be sent to many different native platforms. There are both pros and cons to cross-platform mobile app development. These tools are useful because they decrease costs and increase the speed at which apps are developed. In addition, cross-platform mobile development tools are generally quite simple to use as they are based off of the common languages for scripting, including CSS, HTML, and JavaScript.

​

     However, cross-platform mobile development does have a few drawbacks. First, mobile operating systems are frequently updated. Whenever a mobile operating system receives a new update, the applications must also be updated to be compatible with the new system. In addition, rendering times with cross-platform mobile development may be longer as each operating system needs a separate set of code. When deciding between native and cross platform mobile apps, people sometimes base their decision on hyped up blog posts, or simply on the grounds that they want to try something new. It should depend on the type of project you’re about to build, what features the project requires, and what money/time you have. The longer you think your app will “live”, the more you should question your decision. If it’s something short lived, then you can feel free to use whatever you want, and experiment a little (but don’t forget to check whether you’ll be able to deliver all the features you plan to or you’ll have to make a compromise).

​

     The main selling point for cross platform frameworks is that you’ll be able to share a code base between platforms. The amount of shared code depends on the framework of your choosing.The main downside of these frameworks is that, by using an extra framework, you add another layer that can be a source of bugs (no software is bug free). Like any other library, this framework has to keep up with every update from each platform, otherwise you’ll be left behind.

One thing you should keep in mind is that even though you’ll be using a cross platform framework, there is a chance that you’ll have to write some native code (uderstood as Java/Kotlin or ObjC/Swift), or edit some configuration using the native build system on either platform. So you should invest some time into getting familiar with it, or have other developers for it. This mostly depends on the app you decide to build.First, let’s look at what cross platform frameworks are available right now. We’re not going to go through all of them. Rather, we’ll divide them into 3 categories — WebView based, Native Widget based and Custom Widget based.

​

WebView based

​

     Frameworks like PhoneGap, Apache Cordova, Ionic, etc. are all based on WebViews. That allows developers to create mobile applications using web technology such as HTML, CSS, and JavaScript. The biggest issue with these frameworks is performance. Even though WebView’s improved over the years (iOS WKWebView and Android Crosswalk), it won’t match the performance of native widgets.

​

Native Widget based

​

     Using React Native, the developers can use JavaScript and JSX (JavaScript syntax extension) to construct their application from components that are then mapped to the platform specific widgets. The biggest issue this time is that, in order to use native widgets, the JavaScript part of the application has to communicate with the native part through a “bridge”. This is most noticeable when dealing with animations. Luckily AnimatedJS was created to handle most cases — but not all. In order to create a performant React Native application, we must keep passes over the bridge to a minimum.

​

Custom Widget based

​

     Flutter does not use WebView nor does it use native widgets. Rather, Flutter communicates directly with the canvas and renders the whole UI in a very effective way. Flutter provides a rich set of widgets that are easy to use, compose, and customize. The biggest issue with Flutter is that it’s still in beta. Don’t get me wrong, Flutter is pretty stable but it lacks some features, like inline WebViews and inline Maps (there are workarounds, but they are not always an acceptable compromise). We can’t possibly go though everything in this single article. This was only meant as an introduction. Every framework has downsides, otherwise there would be no point in creating a new one. I wanted to point out the major ones. In my opinion, the WebView based frameworks are the things of the past and the main focus should now be on React Native and Flutter. Maybe you’ve tried some of them. What’s your opinion? Feel free to leave a comment about your experiences.