先月のVelocity Conf London（2013年11月13日から2013年11月15日まで開催）でFacebookのChaitanya Mishra氏が、FacebookのAndroidアプリをWebインタフェースから本格的なネイティブアプリに進化させるための取り組みについて講演した。この移行作業を成功させるために、各プロダクトチームがそれぞれのAndroidの担当機能を主導していた。分散された開発モデルを機能させるため、中心となる統合チームは回帰テストと、各機能からアプリ全体に至る最適化に重点的に取り組んだ。
アプリケーションの新バージョン（とバグフィックス）の配信が、外部機関の承認およびユーザがアップデートを実施するかどうか次第とはいえ、FacebookのWeb開発で用いられていた継続的デリバリー手法（1日2回のアプリケーション配信について）をAndroid開発にも適用して、短いサイクルで開発し続ける必要があった。ビルドが壊れた時は開発者に素早くフィードバックし、リリース対象を自分達で試し（社員への内部リリースは、マーケットへの配信の4週間前に行われる）、そして擬似製品モニタリング（機能面でのエラーやパフォーマンス上の問題について、フィードバックがすぐさま開発者に返ってくる）が、外部に配信される前にリリース内容の信頼性を高める手助けとなっている。その4週間の間、masterブランチ（新機能が継続的に追加され、後のリリースのためにテストされている）と並行して、リリースブランチの安定化が行われる。
機能とパフォーマンスのテスト（Selendroidを使用してUI経由で実施）に加え、アプリケーションの容量（何らかの変更が知らず知らずのうちにアプリケーションの容量を増やす）、メモリ使用量や電力消費量（実際のバッテリ使用量に至るまで）含め、その他Android特有のチェックをビルドプロセスを通じて行っている。Chaitanya氏は、アプリケーションがスリープモードになることを防ぐポーリング機構のマイナーチェンジが原因と判明した、電力使用量が増加した重要かつ説明が難しい例を示した。
外部に配信した後、アプリケーションのパフォーマンスやエラーのモニタリングはAnalytics Loggerで行われる。フィードバックデータは、Scubaと呼ばれる内製ツールを用いて定期的に解析されている。Chaitanya氏は、DBクラッシュの検出数が増加した例を述べた。ユーザの端末に利用可能領域が少ないのではないかと疑い、それを探るために空き領域の計測処理を追加したところ、実は、必要以上に多くの領域を消費しているのはアプリケーションそのものだということが判明した。その原因は、メモリの過剰割り当て、場合によってはデータベースの完全コピー、大規模キャッシュや不必要なファイルの保持などであった。それらを改修した後は、DBがクラッシュする割合が大幅に減少した。
ネイティブアプリケーションへの完全移行の成功にもかかわらず、Chaitanya氏はアプリケーションのネイティブ化に行き過ぎな部分があったことを認めた。特に、あまり使われていない機能については、純粋なWebベースのままでもよかったかもしれないという。それというのも、Chaitanya氏によるとWebに頼ることの難点は、可能な限りWeb APIの後方互換性を維持する必要があることなのである。