preface

I happened to read a good article, with translation, the author is jielse published in androidHub.

With the invention of the smartphone, many developers are asking the same question: How do you build and publish applications for multiple mobile platforms? Including the original iPhone and BlackBerries, Android, as well as Windows Phone and the Web. It is expensive to distribute applications separately for each platform. Our initial thought: There must be a solution to reduce the cost of developing multiple applications. But is it true?

At Pixplicity, we’ve been developing applications for over six years to try and solve this problem. The end result is no different: we started building Android exclusively with native developers before providing a full-service solution. Over the years, we have tried and tested many cross-platform solutions, such as PhoneGap, Xamarin and React. In the end, we decided on a native solution for Android and iOS. The reasons are explained below.

So what is cross-platform?

IOS apps have traditionally been written in Objective-C or Swift; Android applications use Java or Kotlin. These are native languages. This means that if you want to make applications for both platforms, you need to know at least two programming languages. To add the Web to the mix, you’ll need HTML + CSS + JavaScript for the UI, and PHP or Ruby classes for the business logic. That will be a lot of work.

Cross-platform solutions aim to simplify (part of) this problem by using a single programming language for multiple platforms.

These solutions fall into two categories:

1. Using Web technologies supported by all platforms. These solutions basically load the mobile browser in the application and perform all the logic in that browser, while providing additional features that traditional web technologies don’t have, such as push notifications or access to file storage. This category includes PhoneGap (or Cordova), Sencha, and Ionic (a framework built on top of PhoneGap), and uses JavaScript as the main programming language.

2. The other category is often called “native cross-platform,” because programmers write code that is automatically converted by the program to native code. This has the advantage that the resulting application can achieve near-native performance, while a Web-based solution has the overhead of running uncompiled code in a browser. This category includes React Native and one of the (probably) most popular: Xamarin.

These native cross-platform solutions can be further broken down

Two categories:

1. Share UI code (the visual part of the application) and subcategories that do not have these subcategories. For example, regular old Xamarin shares business logic code across platforms, but UI code (and other platform-specific code) is written specifically for each platform. Even if, as a developer, you’re using a single language (C# in this case), you’re still writing separate code for the UI on iOS and Android.

2.Xamarin also provides an API called Xamarin.Forms for sharing UI code. Instead of writing a separate UI code, you write it using Xamarin.form’s own markup format and then convert it to a native control. React also falls into this category; Instead of writing a native view, it will write the React view.

advantages

All of this technology is pretty beautiful. Sharing code means less work and less learning, so let’s look at the benefits of using one of the above options:

1. Shared service logic – Write the service logic once and run it on any platform. Google reuse 70% of its code in Android, iOS, and Web applications by using its own Java-to-Objective-C converter, J2ObjC. This significantly reduces the amount of work required to build the application, reduces the cost, and reduces the time to release. Maintenance-shared code will not only reduce costs during the initial build period, but will also benefit over the lifetime of your application. 3. Learn one Language – If you’re a developer looking for multiple platforms, it’s easier to learn a single language (or set of languages (usually a programming language, the markup language that builds scripting and user interfaces) than two. 4. Same team working on both applications – that’s a lot of work. A team is cheaper, making project management easier and more efficient. Knowledge is more easily shared across teams. Members of the Android team can help the iOS team, and vice versa, because there is no Android team, there is no iOS team. Only one team shares unit tests – if you have unit tests, cross-platform code bases can also share unit tests. This means less time is spent writing tests. 5. Use with the Network – All of the above rules apply to the Web platform as well when using a Web-based solution (or a native solution that supports the network). Where Xamarin can only share code on iOS and Android, the web-based tool offers all the benefits before the web version of your application.

Obviously, whether you’re a single developer, a multinational company spanning multiple development teams, or a student learning to build your first application, you can benefit a lot from these advantages. “Write once, everywhere.” It’s often quoted, and while I wouldn’t argue that it’s sometimes the perfect solution for a project, it sounds too good.

— By Chet Haase, Senior software engineer, Google

The Pixplicity team and I have used several platforms (with varying degrees of success) over the years, and we probably won’t stop trying new ones. Along the way, we ran into some major pitfalls that I think should be carefully considered before committing cross-platform tools.

disadvantages

Are all big companies cross-platform? Google created and uses (a lot) J2ObjC. Facebook created and actively maintains React. Microsoft bought And very aggressively maintained Xamarin.

1. Different platforms are different

You can’t build an application for one platform and expect to get a good score when you copy and paste it onto another. I know you want to, and technically you can, but you shouldn’t. Android and iOS are different, Android and iOS users are different, they should be close to different. Each platform has its own design guidelines and rules to develop, and users will know when you break them.

As Google says:

J2ObjC does not provide any kind of platform-independent UI toolkit, and there are no plans to do so in the future. We think iOS UI code needs to be written in Objective-C, Objective-C ++ or Swift using Apple’s iOS SDK (Android user interface using Android API, Web application UI using GWT, etc.).

Facebook, on the React website, wrote:

It is worth noting that we do not pursue “one writing, run anywhere”. Different platforms have different looks, feels, and functions, so we should still develop discrete applications for each platform, but the same engineer should be able to build applications for any chosen platform without having to learn a different set of technologies for each. We call it “Learn once, write anywhere.”

So this means that when you want to optimize the UI for each platform, the shared UI platform (such as Xamarin.Forms) is already out of the window. This in turn means that close to 100% code sharing is an unattainable goal. Depending on the nature of your application, assume that 60% of your code is shared on the platform.

The web is again very different from mobile, at least when used on a laptop or desktop. Screen size is important, so is the presence of a keyboard, and so is the interaction with the touch screen when using the mouse. Once you understand the performance, you’ll see that the benefits of a Web-based solution are limited, and unless you’re experienced in Web technology, you definitely don’t want to learn a new language. Note that the platform differences are not limited to the visual aspects of your application. It includes all features that are present, missing, or different on each operating system. Android developers have access to a number of features that are not possible on iOS. Think of Android’s rich notifications, open Bluetooth access, NFC and USB communication, alway views, instant apps, launch screen widgets, and maybe more. And vice versa for iOS: smart app banners, dedicated encryption hardware, 3D touch. Other differences are that the cross-platform wrappings are unified: picture-in-picture, ARKit vs. ARCore, the mechanism for playing music, and when and how the application performs tasks in the background, when and how to request permissions, access external storage…

Thanks to Romain Guy, senior software engineer at Google, for addressing some of our concerns.

2. The performance

It is not possible to be faster than a native program. Native cross-platform code is translated into bytecode or native machine code, so it is theoretically possible to achieve native performance, but there are often various limitations. For example, Xamarin sends a library of features to each application that causes some overhead, which may not be important for the smoothness of the animations or the responsiveness to user interactions, but it is important in terms of startup time, memory usage, and application size. A simple “Hello World” App built into Xamarin can take up a whopping 16Mb (four times the maximum size of the Instant App).

Load and save images in milliseconds; The lower the better. Statistics from August 2017

The performance of the network-based approach didn’t even degrade much. Websites that traditionally run in a mobile browser or network view are not good for performance, but there have been significant improvements over the years, and the difference in responsiveness is not only measurable, but also significant. A simple and well-crafted Web-based application might trick users into thinking it’s native, but either way, animations are as smooth as their UI components, and screen transitions or device rotations will disappoint you. That’s the main reason Facebook invented React.

“Unfortunately, since all the rendering was done using Web technology, we were unable to generate a true local user experience.” -by Facebook

3. Easy to scale

For me, this is a personal ambition because I had a lot of trouble building the Xamarin application. These tools have always been a hassle, and the development process has been a hassle, so I’ve had to do my best not to hurt Xamarin.

4. Error

Android and iOS are solid platforms, but even with some bugs. Errors or unexpected or unrecorded behavior in the operating system, development tools, and libraries used. Add another layer of software to the development process and you add more bugs. In The case of Xamarin, the list is quite long. We have a shared file in our office called “The Big List of Xamarin Sh * t”. Not only does it deal with more problems, but it also increases the complexity of the tool chain, leading to more complex debugging.

5. Immature tools

The fact that cross-platform toolchains are less mature than native platforms doesn’t just result in more errors. It also means they are incomplete. Think of the automated code checks performed by XCode and Android Lint, which warn of errors and security issues during development. Think IDE help and speed up coding, help track bugs, track performance issues (memory, CPU, GPU, battery usage, etc.). While other platforms will of course release similar tools of their own, native platforms have been around for years.

6. Slow integration of new platform features

XCode and Android Studio (based on IntelliJ) have been tested and are always the first to release new features, with guaranteed access to 100% of the platform features available to developers. By their very nature, cross-platform tools will always be behind the curve with each update. To be sure, Xamarin has been quick to adopt, and they even boldly claim to take hours to include new OS features, but the problems are numerous. Sometimes, the Appstore forces applications to be built for 64-bit cpus, and Xamarin is not yet stable.

7. Programming languages

Which programming languages are considered “good” and which are “bad.” Each language has its own advantages and disadvantages. But, for all that, personal opinion plays an important role in this discussion, but some languages are inherently safer than others. No matter how good your codestyle-check or IDE is, using only one language instead of the other can avoid certain errors. Javascript (used by React) allows you to use misspellings that the interpreter cannot print, resulting in run-time errors instead of similar warnings from the spell checker.

8. Availability of the library

Popular cross-platform solutions often have a good package manager and can provide a wide variety of plug-ins or libraries. For example, Xamarin’s NuGet repository has a surprisingly large number of plug-ins and includes many popular native libraries. None of these repositories compares to the number of libraries available for the native platform. You can often port existing hangars, the bad thing is that you often need to do so. For some cross-platform technologies, this means that you will need to know the native programming language, which is something you should avoid when choosing a cross-platform language.

9. Slow coding and running cycles

Admittedly, there are two sides to this argument. There are web-based and native cross-platform options to quickly display code changes, and there are platforms where every time you make a small improvement, you need to deploy the changes to the device or emulator.

10. White label

This is important when you deploy different brands of applications for different clients. “Build” on Android or “target” on iOS – these platforms have simple systems to support this. The cross-platform approach I know of doesn’t support this, so you end up writing your own solution during the build process and making each deployment more complex.

11. Expertise

Individual excellence is a subjective matter. If you have a lot of Ruby experience, you might like to create mobile applications in Rhomobile. If you’ve been programming in Basic for the last 30 years, you can stick with what you know and use B4X. Pixplicity’s developers have years of local technical experience, and we have been programming at a high level for a long time and often teach our knowledge at our Android Academy and at conferences around the world. This will affect your choice of technology development applications, but how?

12. Learn a new language

But is it easy? If you want to write a high-quality application, you need to know what platform you’re targeting. You need to know what the platform can and can’t do, what their SDK offers, and even what bugs or features you need to consider. For each platform and often even for each version of each platform. It’s easy to estimate how much you still need to learn, far more than you already know. If you are an experienced C# developer, then about. All knowledge of Net and GDI is useless. In fact, learning the programming language is the easy part of application development. This is a small step from C# to Java or from Swift to Kotlin. If you understand the concept, grammar is trivial.

13. Years of experience

Sure, cross-platform languages like Ruby, C# or JavaScript already exist, but those platforms don’t. React Native was released in March 2015. At the time of this writing, it was impossible to find React Native developers with more than 2.5 years of experience.

14. The document

Any decent cross-platform solution has a good track record. Local development has a better record. They have a much larger online community. They have more meetings and more local meetings. On Stack Overflow, there are 191,918 positive questions on Android + Java, 103,641 on iOS + Swift, 59,355 on React, 54,126 on Cordova, and 25,976 on Xamarin. Of course this is a sign of community size and engagement, not that native programming is difficult to use.

15. Business dependency

So now that you know I don’t really like cross-platform development, I wish I could do it now. But so far, I’ve covered even the practical aspects of application development. Let’s look into the future and see how it might affect your business. Apple and Google have huge teams building their platforms, and as long as those platforms exist, there will be a side to them. This is the best guarantee you can have of long-term support for the tools they offer and their positive continued growth. The popularity of native platforms also provides greater support for the community around the community and a more stable supply of experienced programmers. However, cross-platform tools are entirely dependent on the agenda of the companies they fund. None of them offered any guarantees of support or future plans. There’s no guarantee they’ll be compatible with the next Android or iOS update, no guarantee they’ll even exist next month. If that happens, you can only hope that the technology will be handed over to the community and will continue to be open source, no doubt at a much slower pace. “The company does not provide any assurance that it will not pull into the insert project.”

Ariel Elkon’s comment on React Native. If the past is any indication of the future, today’s popular cross-platform solutions will be replaced in about two years. Titanium, PhoneGap and Adobe AIR are all seen as the next big thing in cross-platform development. React and Xamarin instead; Advanced Web applications may succeed them in the future.

Pay attention to

So when should you use a cross-platform toolkit? There are two big exceptions:

Game –

Games usually do not rely on native components. They are using custom UI components that are designed to fit the look and style of the game without having to write native layouts. Whether 2D or 3D, games are usually built on Top of OpenGL, where performance is very good, and visual logic forms a large part of the application and can be shared across platforms. If you’re making a game, then yes, you should use something like Unity or Unreal.

Rapid prototyping

If you soon want to test an idea and deploy it to a group of testers, you’re probably more interested in how the application interacts than whether it performs well. Depending on your expertise, cross-platform toolsets can be great for prototyping in a quick and easy way.

TL; DR

You’re promising 60-90% shared code for faster development and less maintenance. But the development process has slowed down due to a lack of tools, developers are unhappy, and every software update starts cracking due to a lack of libraries, handcrafting more components. Deployment time is longer. There are not enough tests, so there are more errors. Now you’ve cut your development costs by 20% instead of the expected 60-90%, and on top of that, your users will leave you with bad ratings. We’ve seen it happen, and we’ll continue to see it happen. No one is saying this will happen to you, but consider this article when choosing a platform. The customer came to us with a cross-platform application and asked to rebuild it using local technology. Not once was it the other way around.

About the author

Mathijs Lagerberg co-founded Pixplicity in early 2012 after building several Android applications. The Android OS was young in these times and had a small market share. After years of programming in countless languages, it makes sense to sneak this new technology into your head and join a startup focused on building mobile apps. Over time, Pixplicity has evolved into a creative technology agency that has had the pleasure of playing with all the interesting double letters: A.R., V.R. And Anderson,.. Applications are still being built, but not cross-platform.