Mobile Platform Convergence

Our last post about Mobile Oriented Architecture talked about Android, iOS, and the web beginning to look similar at an architectural level. That is a future which is a little far out, and if I’m being honest, for the web end, certainly speculative. Several things will have to come together, and regardless of how well they do, mobile and web are going to have some differences. Knowledgeable practitioners will be able to deal with these differences, but mobile and web will always be more like cousins than siblings.

However, if we think a lot closer to current reality, it’s not all bad news. The MOA diagram I posted looked like this.

Everything’s the same!

Most projects don’t really look like that, though. What the web is doing and what mobile is doing tend to differ somewhat (or significantly). What iOS and Android are doing, however, tend to be the same. The diagram should really look like this.

Mobile is usually pretty different.

Why your product’s feature set should be the same on Android and iOS should be obvious. They’re essentially the same thing. A mobile device. Unfortunately how apps are built for each is quite different. Different languages, libraries, ecosystems, etc.

The funny story here, though, is how not different they actually are. Again, architecturally speaking. They’re both unix-y systems, with files, threads, networking. Both ship with sqlite (and you can link to it). The raw components you need to actually construct the logic of your apps exists in both places, and is basically the same.

Doppl?

That is the general idea behind Doppl. Take some AOSP code, the architectural bits that you’re likely to use in an app, and implement them on iOS using J2objc. You construct your UI the same way you had previously, but both Android and iOS can call into a shared, tested architecture.

There’s a lot to unpack behind it. The longer blog post discussing concepts can be found here, as well as a much updated video from Droidcon SF.

That work is ongoing. We recently pulled the gradle plugin out of the Doppl project because it builds against stock J2objc now (if you tried the original j2objc gradle plugin, they’re similar but different).

Awesome! Nailed it, right?!

It is an interesting time to be pushing a Java thing in the Android community. After Google announced Kotlin support, pretty much nobody wanted to hear about Java. I very much understand this position, but the reality is, although not as sexy, J2objc is quite stable and being used by some very interesting products in production.

On the other hand, some folks are also sorta/kinda using it, but in a much more limited capacity, for a number of reasons. If you’re talking about product development in large teams, Ray’s talk is very interesting. Some shops are simply not going to try to do this kind of stuff. They have the resources to build everything separate, and have the testing and architectural discipline to do so effectively.

There’s also going to be a political issue with existing teams. Using J2objc/Doppl, your development efforts start to look like this.

It’s an Android world

The iOS team is not going to be happy about this situation. There’s no real way to spin it otherwise. Dev becomes Android focused.

This is not bad if you aren’t dealing with an established internal iOS team. In fact, it becomes a lot easier to outsource the 2nd platform, assuming you want to build Android-first. That’s another blog post in the making, but replicating something that exists is a lot easier than making a new thing.

Kotlin Multiplatform

The other tech we’re really excited about is Kotlin Multiplatform. Rather than having all the tech Android focused, there’s a real opportunity for the Android and iOS communities to come together and have a shared ecosystem. As Ray says (see the sorta/kinda video again), when using code sharing, somebody is inevitably working in a foreign environment. Kotlin is obviously Android friendly, but it is also very similar to Swift. The libraries that will need to be built are going to need solid iOS and llvm understanding. There is a real opportunity for collaboration.

There’s still a lot of work ahead of us, though. I am sure there are going to be a number of groups adding different libraries. Sometime in the near future I think we’re going to co-opt the Doppl AOSP sqlite code and see if we can make a Kotlin/Native sqlite access layer that is still source compatible with Android’s sqlite stack (support library sqlite stack, anyway).

If everything goes right, though, the diagram can look like this.

Mobile teams working together!

Technically it could look like this, but meh.

iOS first, still using Kotlin for logic and architecture

But why not ___?!

I’ll get around to the various “Why not ___?” posts at some point. The short version is, it’s not that I think those things are bad. There will be people that use them, and they will be successful. We just think that for the type of work we do, and the types of orgs we work with, these types of tech are your best bet. All of our reasoning will come down the development efficiency and risk. Again, Droidcon SF video explains it best.