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.
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.
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.
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.
Touchlab is an enterprise-grade innovation advisory firm helping application development leaders identify and eliminate inefficiency to free-up resources for reinvestment into innovation sprints.
What’s the difference between Touchlab and bigger enterprise mobile development firms like Accenture, IBM? Smaller players like WillowTree or LiquidHub?
IBM and Accenture aren’t known for building successful startup products. They specialize in selling big contracts to big companies. The output? Big applications we’ve all seen before. Not true mobile innovation. Furthermore, they don’t specialize in code-sharing, which is the only true path to accelerating mobile innovation. Touchlab has built disruptive products for enterprises and startups and is a pioneer in code-sharing for enterprise environments.
Smaller players like WillowTree and LiquidHub are capable of building great startup products, but they build product for 2010, not 2020. Our expertise in code-sharing and our D.R.Y. philosophy is a strategic advantage.
How are code-sharing and cross-platform development different?
Cross Platform is a “Capital B BIG Decision.” You have to live with that decision and it’s not an easy separation. Code-Sharing is lower risk because you can start small and there is no lock-in.
One day, will every enterprise mobile development team be using code-sharing?
Yes! Backend architecture and logic doesn’t need to be developed natively. We believe the trend towards enterprise code-sharing will start there and spread to other areas with potential for standardization.
I don’t want to lead you on too much about the status of coding Kotlin on iOS. I’m very excited about where that’s going, but it’ll be a little while.
The Kotlin team is making tons of progress, though. It’s coming and it’ll be pretty great.
One of the things that will be needed are Kotlin libraries that don’t need access to the JRE. A lot of stuff is in the JRE, so many libraries will have some issues.
I’m not sure running Doppl/J2objc under Kotlin native will be how a lot of apps are built, but I was curious to see if it would work. After all, J2objc is basically a JRE running on iOS. With some smoothing, I think the two will go together quite well.
The Doppl Droidcon app runs RxJava 2, Retrofit 2, Dagger, Android Architecture components (RC1), with room, all on iOS, with Swift as a front end.
Here’s a Kotlin native version, calling into the same Doppl code underneath (RxJava 2, etc). It’s only the main schedule page. There are technical hurdles on the Kotlin side that I won’t go into, and I think they’re a mix of things the Kotlin team is fixing and/or me not fully understanding how to interact with the framework (and not wanting to spend more than a few hours on a proof of concept).
There are a few important points related to that project. It’s constructed with a reactive architecture using RxJava 2 and Android Architecture components, running on iOS. Yesterday, we updated the Android Architecture components to RC1, which was recently released.
The Xcode side of Doppl’s build system has been greatly simplified. Your code and dependencies are all wrapped in an Xcode Framework that Swift can call. No bridging header or manual management.
Obviously, the Android community has been talking quite a bit about Kotlin. I won’t get into that. It’s cool, but let’s call it well handled by others. I’m going to talk about what’s showing up in the Kotlin/Native samples folder!
My particular career focus has shifted dramatically in the past 1–2 years and is pretty much on code sharing and how we’ll be pushing pixels for the next decade (ish). I don’t know exactly how things will shake out, but we’re talking to a lot of people who are trying different ways to not build the same thing over and over again.
We have built Doppl. It’s a mobile code sharing tool. It is interesting now because it’s available now, and will fit well into a lot of contexts. It’ll be a bit, but you will be able to code Android, JS, iOS, and apparently sooner than I thought, webassembly, with Kotlin code. If we had a current “focus”, those two would be it.
We’ll save the “yeah, but what about ____?!” discussions for later. Assume there will be multiple “things”, and not everybody is going to agree with you. That’s how people work.
I’m speaking at a Swift conference in November, and my talk is basically saying the web and Android communities are working on their answer for other screens. The Swift community should do the same.
This sample is not what I’d call “practical”. You can’t use this today. However, it’s the first Webassembly thing I’ve ever built (I just built the sample, and did a little Kotlin tweaking to make sure it actually worked).
It takes a while to load. Like I said. Not practical today, but assuming you’re on Chrome, this works (haven’t tried other browsers).
Kotlin Native can “mount” Objective-C headers for interop. The sample compiles and runs on iOS, which is cool, but hopefully, for you can build a separate library that can be referenced from Swift, etc. I keep advocating this because I think it’ll be very important for adoption.
This is all very neat stuff! It’ll be a while before the tooling allows you to be productive, but it’s coming.
We’re going through and updating Doppl libs and sample apps. J2ojbc updated to 2.0.4, which caused some minor incompatibilities with existing Objective-C code. That required a redeploy of a number of libraries.
Future versions will package the java directly in the dependencies rather than the translated code, but for the next few months, we’ll be working with 2.0.4 and locking down the libraries and versions.
I updated a bunch of the architecture code to actually use reactive features of Room DB. The tests aren’t updated yet, though. Just fyi.
Droidcon app update coming soon. Before end of week (ish).
We’ve had a lot of feedback on the technical preview. Next up on the todo list:
Finishing RxJava 2. It works, but needs some tweaks.
A little more work on Retrofit 2. Some error states don’t do the same thing as they do on Android.
After that, Xcode help. It’s difficult to manage for Android devs.
Gradle plugin needs some fixes. It does not do well with project dependencies. Also needs to handle Android library projects better. Can only deal with plain Java and Android Application modules. Compile failures can be difficult to find root cause.
In the middle, whenever Architecture Components get to v1 we’ll need to create an “official” version.
In the longer term, evaluating Kotlin as a potential alternate platform. They’ve been making a lot of progress, and many folks are working on Kotlin-only libraries, so should be viable in 1–2 years.