It’s a problem Google decided to tackle when it was developing the recently launched reimagining of Gmail, called Google Inbox. With Inbox, Google adopted a set of tools that allowed it to tame the three-headed platform hydra. The app shares roughly two-thirds of its code across Android, iOS, and the Web.
J2ObjC is a open source project which Google went public with last year. The project waspreviously used in Google Sheets (the spreadsheet part of Google Docs), but Inbox is Google’s biggest use of the project to date.
A lot of the shared code defines things like conversations, reminders, and contacts. It also deals with the difficult task of network management and offline synchronization, where the app is used offline, reminders are made, and e-mails are sent. It’s up to the app to store all that and fire it off to the Internet when the time comes. Sharing the code for this stuff is a big time saver, since it only has to be written and debugged once. It also makes the app more consistent across platforms: reminders will work the way you expect them to, because the same code powers it across devices.
When designing Inbox, Google broke down its code into abstract concepts for each of these shared functions. So the code for a reminder logic lived in something like “reminder.java” and could just be wired up to the Android UI. When it came time to make an iOS version of Inbox, J2ObjC took the “reminder.java” brick and spit out Objective C code, which can then be wired up to a UI for iOS.
The tool does not convert UI pieces from Android to iOS, because that would be an awful user experience. Google wants developers to write the logic once in Java, transpile it to other platforms, and then make the UI natively using the SDK for each platform. That way the apps look and feel native to the platform they’re on, and the UI should run a lot more smoothly. This is the same approach—cross-platform core, platform-specific UI—that Xamarin promotes for its development environment.
Performance for something like this is naturally a concern. Ars spoke with Garrick Toubassi, an Engineering Director at Google and a member of the Google Inbox team, about any performance impacts. “If there’s anything, it’s negligible—we’ve done a ton of benchmarks,” he said. “You don’t have a new layer of cruft that’s getting added to make it compatible.” Toubassi said the code J2ObjC spits out has “roughly the same number of objects and the same object graph complexity” as a hand-built Objective-C version.
The tool is interesting. It solves a big problem that most app developers have today while simultaneously promoting an Android-first development cycle. The company obviously feels J2ObjC is ready for prime time, as Google Inbox is a massive, public facing use for it. It seems to work well, too—just try out the iOS version. The app feels as fast and smooth as something that was hand-built for the platform. You’d never know most of it was spit out by a machine.