Cross Platform Mobile Approaches

Book covers

I have trouble making decisions, especially if they relate to technology. Today I’m trying to decide what approach to use for mobile development.

If I wanted a single iOS app or Android app I’d prefer using a native approach. By native I mean using the language, APIs and tools the vendor supplies. On iOS this would mean writing in Swift using Xcode, on Android it would mean Java and Android Studio.

There is only a single code base to worry about and there are no other layers between your code and the vendor’s platform. APIs are the latest available and there’s no delay in tools being available. I believe Google and Apple engineers are using the same tools as I am using.

The trouble starts if I want both an iOS app and an Android app. Now I have a more difficult choice to make.

I’ve been thinking about this a lot lately. Android has something like 85% of the world wide market and iOS about 15%. In the US, where I am, supposedly Android is about 55% and iOS 45%.

Since I tend to use iOS personally I could ignore Android for apps I’m using. However when I develop apps for friends they tend to want to be on both platforms. And if I ever switch platforms I’d have to make decisions on every app I’ve made.

The goal for the user side is to have the same functionality on both apps with the user interface to be consistent with the platform. The goal for the developer side is to maximize code sharing and minimize the number of languages and APIs I need to know.

Xamarin

The Xamarin approach allows me to use a single code base for the non-UI portion of the code. It’s also a single language, C#. If I want to have a single code base for the UI portion I could use Xamarin Forms, but I’ve found this is to be too slow for practical use.

The drawbacks to this approach is that Xamarin is adding a layer in between me and the platform. If there’s a bug I now have an additional layer to hunt through. Also, I still have to know all the APIs for each platform, and that’s the hard part. Using different languages is much easier, especially if they are closely related.

Web

The Web approach also gives a single code base and a single language used across platforms. It also frees me from the platform vendors, i.e. I can use my own tools, publish to my own host and I skip the application review/approval process.

The drawbacks are the need for constant connectivity (unless I’m willing to add offline support). I also need to maintain servers with either dollars or time or both. There’s also the problem of accessing hardware if I need to use the GPS, camera, gyro, etc.

Native

This approach gives the maximum native experience. I’d be using the platform tools, language and APIs.

The drawback is that there is a lot of duplicate effort as all code is duplicated. If I find a bug on the iOS side and fix it, I have to make the same fix on the Android side too.

Native with converter

I spent a lot of time on this road for a recent project. I wrote the Java non-UI code for Android and then used a small project specific app I wrote to generate the Swift code from the Java code. It worked pretty well. I also spent some time using C++ for the non-UI code since that works with iOS and Android in a native manner.

The drawback is that the converter is a pain to maintain. This would be a great approach if someone wrote a general purpose converter. Looking around on the web I saw a few different attempts but nothing useable at this point.

Conclusion?

So, what approach is best? I don’t think any of them are great. There are significant drawbacks to all of them.

Today I’m going the native route for smallish apps and the Xamarin route for bigger apps. I’m counting size as the amount of non-UI code. I already know C#, Java and Swift, so switching between the languages isn’t that big of a deal.

Also, this isn’t my day job so I need to minimize the amount of time I spend in the evening writing apps that I’m pretty much the only user of. I do like learning different technologies and I believe it helps me at my day job. One of the best ways for me to learn is to jump in and code something I find useful or fun.