iOSとAndroid間でコードを共有するコスト
(blogs.dropbox.com)Dropbox は2013年の開始時、両プラットフォーム間で共有するためにC++を使用。
当時はチームが小さく、急速に成長するモバイルロードマップを支えるためだった。
現在は Swift と Kotlin を使う形に切り替えており、これはコード共有に伴う以下のような隠れたコストがあるため（実際にはそれほど隠れてもいない）
-
カスタムフレームワークとライブラリによるオーバーヘッド
-
カスタム開発環境のオーバーヘッド
-
プラットフォーム間の違いに対応するためのオーバーヘッド
-
開発者の教育、採用、維持にかかるオーバーヘッド
結論として、1つのコードで書くのは良さそうに見えるが、オーバーヘッドは大きいということ。
この記事の最後の段落が「Android / iOS開発者を募集中！」である点が重要
4件のコメント
結局のところ、組織が負担できるオーバーヘッドかどうかではないでしょうか
何を選んでもその負担に耐えられるなら、いちばん得意なものに集中するのがよいと思います
どうせプラットフォームごとの違いは避けられない気がします。ハイブリッドで作っても、違いがなくなるわけではありませんでした
クロスプラットフォームという、もう一つのプラットフォームにすぎない。
しかも、より複雑で中途半端なものだ。
最近のReact Nativeはかなり完成度が高いようですね…。
もちろん、Dropboxのようにデバイス依存のアプリになると、従来のハイブリッドアプリの苦しさは依然として残るでしょうが…。
文章は長いのですが、実際のところ Dropbox は特殊で C++ を使っているからであり、
小さな組織では単一のコードでマルチプラットフォームをサポートするのが、正直なところ初期には魅力的なのも事実です。
10年前は HTML5 と Phonegap を使った Hybrid 開発がそうでしたし、
最近では React Native や Flutter のようなものが登場して、一度に複数のプラットフォームをサポートできるということで皆を惹きつけています。
私の考えでは、小さな組織では上のような方法でコード共有をすることには、確かに利点があります。
ただしプロダクトが成長するにつれて、これは再び技術的負債になっていきます。
ユーザーが増え、組織が大きくなり、開発者がさらに増えれば、Web/iOS/Android はそれぞれに合った技術で発展していくのが最終的な姿になるのだと思います。
https://ja.news.hada.io/topic?id=309 にある技術的負債についての良い記事にあるように、
意図を持って技術的負債を作ることが重要です。利子が膨らむ前に借金を返しましょう。