Not having to rewrite applications for Web, iOS and Android fat-clients is one of the holy grails for development organizations. Google have an shared-code approach that worth understanding, and some appropriately sized companies should consider copying it. Google’s Garrick Toubassi, has a perfectly concise blog entry on it, and some of the Inbox-team developers discussed the technologies on a Reddit interview/IAMA thing.

Google’s development toolchain would be (I guess) to write the shared code for the clients in Java (J2SE), with a high-coverage set of tests in JUnit (or TestNG) and Mockito (or equiv) according to their test sizes (roughly analogous to the Test Pyramid). Code is then generated/transpiled/compiled into an Objective-C static linked library or JavaScript importable thing, is not unit-tested a second time. All three native solutions are functionally tested separately, which means that the generated/transpiled/compiled code does get tested again, but only in conjunction with clicking user interfaces and verifying outcomes there, as well as in the backends. That functional testing is automatic of course, and done per-commit.

Thomas Broyer points out to me that that Closure compiler is the crucial piece of the toolchain for the Web client, and that it is compilation not transpilation that the team use for the process in question.

Unshared code

The shared code amounts to 70% of the code for each client. The other 30% (including view logic) would be idiomatically correct (platform-native) for the client technology in question. E.g. for iOS that’d be the products of Interface Builder and XCode. I’m not sure what the web app uses for the rest of the UI logic. While I prefer the AngularJS way of doing things, the Inbox team is already invested in GWT and the Closure compiler for the -transpilation- compilation, and there’s a greater capability with that technology. My memory of GWT though, is that it is harder to test with Selenium (divs without a predictable means to locate them).

All three sets of source, whether shared or unshared are in the same trunk.

The server app

The backend was written once of course, deployed once (horizontally), and shared by all the clients. It could be Java, but that’s not certain, as Google might have also made it in Go (or C++ if they consider this a heavy-lifting service which is unlikely).

Shared code elsewhere at Google

Watch all of Jeremy Manson’s presentation at the JVM Language Summit in July, as there a lots of interesting nuggets in it. Given the context of this blog entry, the detail we’re interested in is that Google is keen to make C++ interoperation with Java much better. In particular it is much more debuggable. You could write shared code in C++ and use it in an iOS, Android or Web application. The trouble is that would have to be a Web 1.0 application, as you can’t invoke C++ code in browsers (at least in a cross-platform way), meaning you’d have to leverage it in the server-side web app. Inbox’s UI is certainly a push-the-bar Web 2.0 app, for the web deployment.

Dropbox on sharing code

Dropbox uses some shared C++ code for it’s Android and iOS clients. Their strategy could allow them to target the “Windows Phone” platform another day too. Unfortunately C++ can’t be used easily in a web browser version of the app. Dropbox is such a specialist app, that they might be able to convince end-users to install a plugin though.