2つのネイティブアプリを保守し、iOS と Android の機能をそろえ続ける

修理伝票

• 2つのネイティブアプリはおよそ倍の作業

  Swift の iOS アプリと Kotlin の Android アプリを保守するということは、2つのコードベース、2つのリリース列、2つの QA サイクルを意味します。追加する機能はすべて両側に載せる必要があり、実際にはたいてい一方のプラットフォームがもう一方に遅れます。その差は、ユーザーとサポート受信箱がすぐ気づく挙動の違いを生み、放置するほど埋めるのが高くつきます。

• ピクセル単位で一致させずに機能をそろえる

  機能をそろえることは、一方のアプリをもう一方にコピーすることではありません。iOS と Android には独自のナビゲーションパターン、コンポーネント、ユーザーの期待があります。私は両側で同じ機能、同じ製品を保ちつつ、それぞれのプラットフォームがユーザーにとってネイティブに感じられる要素を尊重します。それが、Android で異質に、iOS で場違いに感じられるのを防ぎます。

• OS のバージョン跳躍は毎年やってくる

  Apple と Google はそれぞれ年に一度のメジャーリリースを出し、非推奨 API、新しいプライバシー要件、ときにはデフォルト挙動の変更を伴います。保守がなければ、アプリはいずれ壊れるか、更新がリジェクトされます。私はこれらの跳躍に早めに対応し、意味があるときはベータに対してテストするので、新 OS がユーザーの端末に届く9月に緊急の修正をする羽目になりません。

• 実際に予算化できる保守費用

  アプリの年間保守は、範囲と製品の進化の速さに応じて、初期構築費用のおよそ15〜20パーセントになることが多いです。固定の日額と単一の窓口により、その予算は読みやすく保たれます。不透明なサポート契約ではなく、特定された作業日数に対して支払い、あるリリースに何がかかるかを始める前に把握できます。