Appleファーストは持続不可能

Appleのポリシー変更に振り回されないアプリ開発体制の構築方法

モバイルアプリ開発の理想はクロスプラットフォーム化だが、Appleの要求に準拠しようとすると開発工数が膨れ上がる。Appleに左右されずクロスプラットフォーム開発を実現する方法とは。

公開 2021年10月08日 08時00分

更新 2023年02月08日 12時21分

著者

Cliff Saran

[Computer Weekly]

印刷する連載新着通知を受け取る Googleで優先するソースとして追加

　「Adobe Flash」のサポート終了が迫る2016年、Bet365 Group（通称bet365）はFlashベースのサイトを「HTML5」化した。同社はこれをきっかけにプラットフォームを統合し、新しいWebサイトを基盤とする「iOS」アプリと「Android」アプリの提供に注力するようになった。

　だが、2019年にiOSアプリのエクスペリエンスをより向上させる機能、コンテンツ、UIの強化をAppleから求められた。

　bet365の技術部門子会社であるHillside Technologyのアラン・リード氏（スポーツ開発部門責任者）は、Webサイトの開発計画がAppleの戦略によって方向付けられていったと言う。「AppleはiOSアプリの差別化と均一な製品を希望していた。交渉の余地はなかった」

　開発作業を最小限に抑えるため、bet365アプリはWebサイトのクローンだった。だがAppleは、Apple風のルック＆フィールと操作性を備えた一貫性のあるiOSエクスペリエンスを要求してきた。そのためbet365はiOSアプリ開発のアプローチを完全に変える必要があった。

iStock.com/Daemys

　それまでクライアントアプリは「TypeScript」で開発していたが、Appleのポリシー変更によってiOSアプリはネイティブコードを使わなければならなくなった。だがbet365には「Swift」のスキルを有する開発者がいなかった。

　Appleが2019年に導入した「SwiftUI」はSwift開発を簡素化し、Apple端末用のユーザーインタフェースを構築するためのフレームワークを提供する。「SwiftUIを使えばApp Store用のアプリを迅速に作成できる。だが当社のWebサイトには端末に縛られないさまざまな機能が必須だった」（リード氏）

　高可用性と低遅延をサポートするにはSwiftUIの機能だけでは足りなかったのだ。「さらに、既に実現している非常にリッチなユーザーエクスペリエンスを別のリッチなユーザーエクスペリエンスに移行することが問題になった」とリード氏は話す。SwiftUIからbet365の豊富なデータセットにアクセスする必要もある。

アプリの移植性

　理想は、一つのコードを複数のチャネルにデプロイできるアプリを作成することだ。だが、AppleはApple固有のルック＆フィールを求めている。

　移植可能なアプリの開発とAppleの要件のバランスを取る方法についてチームで話し合った。そして、Appleファーストで開発し、その後他のプラットフォームに移植するのは複雑だということになった。Swiftが独自の仕様を持つためだ。代わりに「コードを変換する方法を構築した」という。

　この方法は「Kotlin」をベースとする。「古いFlashコードの一部をKotlin用にパースする」とリード氏は述べる。

　Kotlinアプリは当初機能しなかったが、このパースによって開発時間は短縮された。「コードを改良する必要があった。だがこのパースによって正しい方向への一歩が見つかった」と同氏は語る。

　リード氏は、Appleファーストでアプリを開発するのは持続可能ではないと考える。だが、Kotlinなら開発作業を減らすことができる。Kotlinならばアプリからバックエンドビジネスロジックが切り離されるため、クロスプラットフォーム開発がシンプルかつ高速になる。「Linux」や「Windows」で実行するサーバサイドコードには「Go」を使うことにした。

　とはいえ、iOSアプリはSwiftでコーディングしなければならない。リード氏の経験によると、KotlinからSwiftに移植する方がその逆よりも簡単だという。

　アプリ開発者が直面する問題は、アプリのパフォーマンスを犠牲にせずにネイティブなユーザーエクスペリエンスを活用し、さまざまなスマートフォンでアプリを最適に操作できる方法だ。