Google Inboxのエンジニアリングディレクタを務めるGarrick Toubassi氏は先日，氏のチームが３つのプラットフォーム - iOS, Android, そしてWebの"クライアントコードの，およそ３分の２の共有化"を達成したと公表した。そのキーとなっているのは，UIコードのUI依存とロジックを明確に分離したこと，そして，Googleが長年に渡って開発を続けてきた一連のツールの存在だ。
Googleのアプローチが目標とするのは，"私たちがターゲットとするプラットフォームそれぞれにシームレスに適合する，独立したネイティブアプリ"を効率よい方法で開発することだ，と氏は言う。確かに，Inboxのようなアプリは，ネットワーク通信管理やキャッシング，データ永続化のためのローカルストレージなど，数多くのコンポーネントを持っている。３つのプラットフォームすべて別々に実装してメンテナンスしなければならない，というのは合理的なやり方ではない。
Googleが採用したのは，データモデルとアプリケーションロジックをJavaで1回だけ実装して，その上に各プラットフォーム用のネイティブUI層を置く方法だ。データ層とアプリケーションロジックは，２重の責務を持っている。
-
会話やリマインダ，連絡先，ラベルといった，Inbox固有のモデリング概念。
-
ユーザインターフェース(UI)層にバインド可能な，完全にオブザーバブルなデータモデル。
これら基本部分が，Google独自のツールをいくつか使用して，各プラットフォーム用のネイティブコードに"トランスパイル"されるのだ。
- Google Web Toolkit (GWT) - Javaで記述されたデータモデルを，Webプラットフォーム用のJavaScriptに変換する。
- J2ObjC - Javaで記述されたデータモデルを，iOSプラットフォーム用のObjective-Cに変換する。
GWTは長く使用されているオープンソースのツールセットで，AjaxアプリケーションをJavaで開発し，デバッグすることができる。 アプリケーションのデプロイ時には，GWTクロスコンパイラを使って，JavaコードをスタンドアロンのJavaScriptに変換する。Javaのコメントを使用して，JavaコードにJavaScriptコードを埋め込むことも可能だ。
J2ObjCはそれよりも若いツールで，Googleの説明によれば"品質的にはアルファ版とベータ版の中間"にある。クロスプラットフォームのUIツールキットは含まれていない。Toubassi氏の言葉によると，JavaをObjective-Cに変換する場合には，ガベージコレクションから参照カウンタへの移行にトリッキーな部分がある。J2ObjCではこの部分を，オートリリースプールを使って処理する。ガベージコレクションと同じように，Javaのオブジェクトセットは，Objective-Cでアロケートされたプールの内容を使用するのだ。ここでひとつ，具体的な問題としてToubassi氏が挙げるのは，循環参照の発生する可能性に関するものだ。これについては，weakなObjective-Cプロパティにマッピングされた特定のJavaアノテーションを通じて，効率よく処理されている。
Ars TechnicaのRon Amadeo氏との対話でToubassi氏は，このアプローチによる目立ったパフォーマンスへの影響はなく，J2ObjCが生成するコードは，手作業で記述したバージョンのObjective-Cコードと比較して，"オブジェクトの数，オブジェクトグラフの複雑さの面ではほぼ同程度"である，と述べている。