AllTrails：書き直しを伴わずに開発を加速させる方法

皆さん、こんにちは。 あなたに質問があります。 もしかしたら、共感できるかもしれません。 これまで、既存のUIKitコードベースを 見直したことはありますか？ 4年前に書かれた巨大なビューコントローラーを 見て、 「うわっ」と思ったのかもしれない。 これは大幅なリファクタリングが必要だ。 いったんこの件は保留にして、 SwiftUIで全体を再構築しましょう。 手を挙げてみてください。 あなたにもこんな経験はありますか？ わあ。すごい。たくさんの人が 手を挙げているのが見える。 オンラインで視聴している 人はもっと多いはずです。 魅力的な考えだが、 我々が運営する規模では書き換えは、 エンジニアの努力によるものか、 AIネイティブのワークフローによるものかに 関わらず、 それは大きなリスクをもたらす。 こんにちは、私の名前は ジェームズ・グラハムです。 私は AlltrailsのCTOです。 そして今日は、書き直しをせずに 現代的なスピードを実現した 方法についてお話しします。 SwiftUIに強制するのではなく、 SwiftUIに私たちを採用してもらう 方法をお見せしたいと思います。 トップダウン方式での導入。 本題に入る前に、まずは 物語の概要を説明しましょう。 まず、alltrailsとは何か、 私たちの規模、そして 制約についてお話しします。 次に、コードベースを書き 換えることなくSwiftUIがどのように 導入されたかについてお話しします。 あるいは、委任状のようなものだ。 その後、転換点をお見せしよう。 SwiftUIが実験段階を終えたとき そして、デフォルトの選択肢になり始めた。

最後に、今日の状況について お話しして締めくくりたいと思います。 そして、私たちがハイブリッドアーキテクチャをどのように 捉えているかについても。 当社の技術的な意思決定を理解するには、 当社の規模を理解する必要があります。 今日、 Alltrailsは世界で最も人気のある そして、アウトドア探検のための 信頼できるプラットフォームです。 私たちの使命はシンプルです。 世界中の人々が外の世界へ出る 道を見つける手助けをすることです。 私たちは人々がトレイルを 発見するのを手伝います。 自信を持って道を切り開き、 トレイルでの体験を向上させる。 トレイルの最新情​​報や フォトツアーなどの機能も掲載されています。 道中の写真を強調表示し、 近所の公園を散歩するにしても、 数日間のハイキングをするにしても。 ご安心ください。 Alltrailsには9000万人以上の コミュニティメンバーがいます。 世界中に50万のトレイルがあります。 そして、会員の皆様の走行距離は 累計19億マイルを超えています。

私たちは14の言語で対応しています。 つまり、私たちが下す 技術的な決定はすべて、何百万人もの人々に 影響を与えるということです。異なるデバイス、 異なる地域、そして重要なことに、 接続レベルが異なる。

私たちは、さまざまな興味や嗜好を持つ 幅広い層の会員にサービスを提供しています。 一方、手軽さを求める カジュアルメンバーもいます。 そして、地元の湖の素敵な景色を眺めながら、 比較的平坦な午後の散歩を楽しめます。 そしてその一方で、全行程に 挑戦する熱心なハイカーがいます 携帯電話の電波が届かない場所で、 オフラインナビゲーションを使って ハーフドームハイキングを行った。

その多様性は信頼性、バッテリー寿命、 そしてUIのパフォーマンスも重要です。 不具合のあるコードを出荷することはできません が、 私たちのアプリは静的なものではありません。 新しい表面や新しい機能の深度によって、 常に進化し続けています。

SwiftUIが登場した頃には、 Alltrailsはすでに 非常に大規模で成熟した プラットフォームであると約束しました。 UIKitアプリが正常に動作しました。 その進化の一例として、長年にわたる 当社のホームページの変遷をご紹介します。

私たちは毎週リリースサイクルで 出荷していました。 そして私たちは、無料サービスと有料サービスの 両方を支えていました。

そして、レガシーコードについて私が 言いたい最も重要なことはこれです。 UIKitは修正すべき問題ではなかった。 それは、私たちの規模拡大を 可能にした基盤でした。 そのため、遊歩道を閉鎖して 変更を加えることはできませんでした。 私たちはそれを維持しなければならなかったし、 ハイキングの途中で アップグレードする必要もあった。 SwiftUIが登場したとき、 それは私たちが切望していたものを 実現すると約束していた。 データが変更されると自動的に 更新されるクリーンな状態管理ビュー、 UIが同期しなくなるようなバグを全て排除する モデルレスコードを使用。 UIKitの同等機能と比較すると、 40% の削減になります。 つまり、保守、更新、 ライブプレビューの閲覧に必要なコード量が 40% 削減されるということです。 デザイン変更を即座に反復できる能力。 しかし、既に成熟したアプリを書き 直すことは選択肢になかった。 技術的、あるいは組織的な面で。 私たちには別のアプローチが必要だった。 こうしてSwiftUIは静かに 私たちのコードベースに組み込まれた。 それは義務付けられた事項でも、 ロードマップ上の項目でもなかった。 私たちはサンドボックスを作成しました。 そして、プロトタイプの低リスク実験に 利用しました。 そして、孤立したサービス。 これにより、リリース候補版を危険にさらすことなく フレームワークを学ぶ機会が得られました。 それについて。

最初の本当の決断は、UIKitかSwiftUIかという ことではなかった。 彼らはどのようにすれば共に成功できるのか？ 私たちは早期から 相互運用性に投資してきました。 こちらのコードスニペットをご覧ください。

ああ、これが私たちの橋だ。私たちは、 トレイルコーディネーターのようなSwiftUIの 機能を採用しています。 それをホスティングビューでラップします。 そして、それを標準のUIKitスタックビューに 直接配置します。

そしてそれをスクロールビューに追加します。

このページを下にスクロールすると、 ホスティングビューの一部のセクションには、 SwiftUIのサブビュー。 私たちは早い段階でこの パターンを確立しました。

これはプロセス上の決定でした。 境界線が明確であることを確認する そして、二つの世界は時を経て同じ 言語を話すようになるかもしれない。 2本の平行な線路が自然に形成される。 UIKit は依然としてアプリのライフサイクルナビゲーションの 面倒な作業を処理してくれます。 そして、トレイルページのような 複雑または深く統合された表面 または、コミュニティ活動ビューを ご覧ください。 成熟したアプリでは、 安定版を書き直すのは意味がありません。 戦闘で鍛えられたスクリーンをフレームワークを 変更するためだけに、 そのため、私たちはハイキングの途中でよく整備された 道のルート変更を避けることができました。 そして、明確なユーザー成果をもたら す分野に新たな投資を集中させた。 そして、SwiftUI側での 開発速度の向上も実現しました。 私たちは意図的に、孤立した人々にとって 最も適した場所でそれを使用しています。 境界が明確な表面、 重厚な景観の描写、そして新たな試み。

ここにその例を2つ示します。 トレイルレビューフローは、動的な状態を持つ 自己完結型の表面です。 そしてUIの更新は、SwiftUIの 宣言型モデルによく合致しています。

Apple Intelligenceを ベースに 構築された Ask the trail Anything エクスペリエンスは、 比較的新しいものです。より実験的なサービス。 SwiftUIを使えば、 ここで素早く反復作業ができます。 そして、それを密接に 結びつけることなく、体験を進化させる。 アプリの中核となるアーキテクチャへ。

SwiftUIがデザインシステムとして 非常に優れているもう一つの分野。 アプリを見てみましょう デバッグモードでは、Denaliと呼ばれる デザインシステムを視覚化します。 デナリは日々大きくなっており、 デザイン、システム、設計、 エンジニアリングチームすべての 新機能がこのシステムを 活用するようにするため。

当社のコアコンポーネント、 ボタン、セグメント、コントロール、 ここに表示されているバッジは、 当社のデザインシステムの一部です。 デバッグモードでアプリ内で表示可能で、 現在はSwiftUIで構築されています。

かつては何百行もの定型文が必要だった。 では、そのごく一部を取り出そう。 そして、新しいバリアントを追加したり、 間隔を調整したりする必要がある場合、 それは、あらゆる場所に波及する単純な変化だ。 SwiftUIを使うことで、 コードベースを肥大化させることなく、 デザインシステムを拡張できます。

SwiftUIを採用した際に、 予期せぬ事態が発生したことにも気づきました。 それは私たちの建築に影響を与え始めた。

ビューモデルは小型化され、 多くの場合3分の1に縮小されました。 なぜなら、UIと状態を同期させるためだけに、 グルーコードを書くのをやめたからです。

また、配管に関する明示的な記述を大幅に 減らし、出版社や運営者も減らしました。 ライフサイクル管理ははるかに少ない なぜなら、SwiftUIが 状態伝播を処理してくれたからです。

UI、 状態、動作が一体化していたため、 変更の影響を受ける行数が少なくて済んだ。 UIのプルリクエストは 30 ～ 40% 小さくなりました。 そして、コードレビューのスピードが 目に見えて速くなった。

その時、SwiftUIはUI実験のように 感じられなくなった。 そして、それがシステム構築の 正しい方法だと感じ始めた。 私たちはエンジニアにSwiftUIの 使用を強制したことは一度もありません。 彼らがそれを新しい仕事に選んだのは、 摩擦が少なかったからだ。 それは認知負荷を軽減した。

適切な選択をすれば、 コード導入率を 40% 削減しても、 それが自己持続的な効果をもたらす。

これが私たちにとっての教訓です。

SwiftUIが普及したのは、 私たちが人々に使うように 勧めたからではありません。 それが広まったのは、 それが最も速い前進方法だったからだ。 フレームワークが認知負荷を軽減し、 複雑さを取り除くと、 エンジニアは説得される必要はない。 私たちはただ、それに手を伸ばすだけだ。 しかし、コードベースは 一夜にして変わったわけではない。 それは傾いた。UIKitは 依然として深く組み込まれている。 SwiftUIはそれを中心に発展してきた。 機能ごとのコード行数の削減などの 成功指標を測定します。

より速い反復サイクル、 そして、それらの個別のSwiftUI機能における 不具合も減少しました。

相互運用性はインフラであると 私たちは認識しました。 私たちはホスティングラッパー、 共有アニメーションに投資しました。 橋梁、そして統一されたテーマ設定。 橋がしっかりしているときは、 SwiftUIは目新しさを感じさせなくなり、 基礎的なものへと変化していく。

その完璧な例が、当社の Apple Watchアプリです。 当社のコンパスとマップのサーフェスはどちらも SwiftUIで構築されています。 また、当社の地図は Mapkitを使用しています。 これは、重要なパフォーマンスをどのように 提供できるかを示しています 現代的な建築技術を用いた、繊細な機能性。

ここでSwiftUIを選んだのは、 それがクールだからではなく、 しかし、それはより速い 反復を可能にしたからです 複雑なサーフェス上で、 従来のナビゲーションロジックに 手を加えることなく動作する。

さて、私たちは今日、どこにいるのでしょうか？ AllTrailsはSwiftUIに 移行されていません。 メリットを得るために、 アプリ全体を書き直す必要はありません。 私たちは方向性を持った ハイブリッドシステムです。

UIKitは安定性を提供します。 複雑なコレクションビューなど、高度なUIカスタマイズには 依然として最適です。 あるいは複雑なナビゲーションバー。

SwiftUIは私たちの 成長を象徴するものです。 急速に追いついてきて、 そして、ここに表示されている植物識別機能は、 100% SwiftUIで構築されています。

つまり、私がこれまで 説明してきたことはすべて、 私たちの規模のすべてのトレイルに 特有のものです。 私たちのメンバー、私たちの制約。 そしてそれは意図的なものだ。 チームがよく犯す間違いは、導入を二者択一の 選択肢として捉えてしまうことだ。 SwiftUIを採用すべきでしょうか？ より良いフレーミングは。 どのような条件下で、 導入はリスクではなく勢いを生み出すのか？

実際に効果があったのは、 バグの減少、配送の迅速化、 チーム間の連携をより円滑に。 それは単一の技術的な選択ではなかった。 それは意図的に下された一連の決定だった。

よく聞かれる質問の一つに、 UI KitとSwiftUIは 安全に共存できるのか、というものがあります。 そして、私が今日お見せした内容から 判断すると、答えは間違いなくイエスです。 だから、何を採用すべきかを 指示するのではなく、 最後に、採用を評価する際に 使える3つの質問をご紹介します。 それぞれの文脈において。 一つは、相互運用性をインフラストラクチャとして 扱うことです。 相互運用性があったとしても、 それは脆弱であったり、 場当たり的なものであったりする。 製品の普及は、実際の製品に対するプレッシャーが 2に達した瞬間に停滞するだろう。 新しいツールは認知負荷を軽減するのか？ ツールが本当に精神的な負担を軽減する場合、 養子縁組には強制は必要ない。 エンジニアはそれを自発的に選択するだろう。

そして３つ目。あなたはコンバージョンではなく、 勢いを測定していませんか？ 勢いは、より小さなペア、 より迅速なレビュー、 そしてより少ない後退という形で現れる。 コードベースのどれだけの部分を変換したか、 ということではありません。

だから、ここから何か教訓を得るとすれば、 つまり、進歩するために書き 直しは必要ないということだ。 あなたには方向性が必要です。 今日は貴重なお時間をいただき、 本当にありがとうございました。 そして、AllTrailsのストーリーを 共有させてくれたことに感謝します。 トレイルでお会いしましょう。