能登 要

札幌在住のiOSアプリ開発者。SwiftUI により分割されたデバイス間を縦横にやりとりできる考え方に転換しています。

iOSアプリ開発者。2009年のiPhoneアプリ開発開始時期から活動。開発言語のアップデートの中でSwiftUIおよび周辺技術に着目中。

サードパーティ通信ライブラリ考古学 - iPhoneアプリ開発

通信周りが不変であればサードパーティ整ライブラリ(Alamofire + Moya)は有意であろう。しかしアプリ開発の根底から覆すAppleと我々アプリ開発者は対峙しているのである。

1) Alamofireについて

Swiftベースの通信ライブラリ。エレガントな通信処理が記述できるというのが触れ込みである。

GitHub - Alamofire/Alamofire: Elegant HTTP Networking in Swift

Swift言語の生まれたときとほぼ同時に当時し以降ベストセラーライブラリだった。

Alamofireは登場した時から成功が約束された通信ライブラリだった。前身のObjective-Cベースの通信ライブラリAFNetworkingの作者がSwift用に立ち上げたライブラリがAlamofireだった。

AFNetworking/AFNetworking: A delightful networking framework for iOS, macOS, watchOS, and tvOS.

Mattt - NSHipster 開発者のBlog。こちらの開発者が関わったライリブラリを個人的にはMattパワー と呼んでいる。

公開当時Swiftで頼るべきものがObjective-Cのライブラリが大半でObjective-C - Swift間でのブリッジ(Objective-Cの処理をSwiftで呼び出す)が不完全な中、通信処理をAlamofire に任せることはAFNetworkingに慣れていたアプリ開発者にとってはメリットだった。

Alamofireは、煩雑で混乱気味だったAppleの通信処理をうまく黙らせていた。非同期の通信処理はC/C++呼び出し前提のCFNetworkを使う方法からNSURLSession に移行する段階だったがAFNetworking/Alamofireは利用者に困らない形で移行を成功させている。

2) Moyaについて

Swiftが静的型付けを試行する言語として注目されたあたりから、静的型付けをもっと活用しようという動きがApple以外の開発者から立ち上がった。Moyaはその一つでAlamofire門前でリクエストする型を厳密に定義し、通信処理のストリームを他の静的型付けを使ったライブラリに渡すためのボイラープレートなコードを生成する。

GitHub - Moya/Moya: Network abstraction layer written in Swift.

Moyaを覚えれば効率的にアプリが構築できるという触れ込みでAlamofireの普及率に乗ってMoyaもアプリ開発のツールとして効率化するためのライブラリとして認知されていた。

当時としてはMoya+AFNetworkingは開発の効率化の一つの到達点だったはずだ(私は積極的に使っていないのでわからない)。

3) AFNetworking の地位低下

AFNetworking の通信ライブラリとしての優位性はそのままだが、AFNetworkingを立ち上げた開発者(Matt)自体はAFNetworking メイン開発者から離脱して久しい。AFNetworking のテーマが開発者に見つかったのかもしれないが実際はわからない。

サードパーティ通信ライブラリ

4) 謹製ライブラリの充実

メイン開発者が通信ライブラリの離脱とは別に、Appleの非同期通信機能であるNSURLSession がやっと安定し普通に使える様になっていた。iOS7から登場しどの時期から使える様になったかは曖昧だが2019年にはApple謹製の非同期フレームワークCombine framework が登場し非同期処理をサードパーティ製のライブラリを使用せずに各選択肢が提供されてから採用のハードルは下がったことを個人的には認識している。

Combine | Apple Developer Documentation

謹製ライブラリのみで記述する場合のメリットは、ライブラリの本体がOSに組み込まれているので(iOS,iPadOS,macOS)、その分のアプリ要領を節約できる。ビルドの際のトラブルもサードパティ製に比べると少ない。

Appleが提供したライブラリで済ますことができても、Webの記事としてはAFNetworkingないし、Moya+AFNetworkingで効率化という話題が多いので結果としてApple謹製フレームワークを使った例はそれほど脚光を浴びなかった。

5) サードパーティ製通信ライブラリの信頼が崩れる時

WWDC2002で暗号化DNSの有効化なるセッションが公開されている。Appleが己のアイデンティティであるプライバシー保護の観点からDNSの挙動に手を加える事もいとわない姿勢が見て取れるセッションであった。

Alamofireもこれに追随すると思うが、AFNetworkingを立ち上げた開発者(Matt) が不在状況でサポートが遅れる可能性もある(2020年8月現在iOS14 SDK対応で手一杯といったissueは見て取れる)。

Alamofireは通信ライブラリとして人気だが、iOS14 SDKへの対応、Appleが提供するプライバシー対応は後手になっている。気軽に採用して不具合のフィックスが遅れると言った自体も考えられる。

サポートが不安定となったサードパーティ通信ライブラリと、その通信ライブラリを使ったライブラリを使うMoya+AFNetworkingのパターンはプラグイン内プラグインみたいな状態は開発環境の変化に追随できないタイミングが生まれる。

またプラグイン内プラグインは使い方を知りたい場合や不具合時にWeb検索での解を得にくい点もある。Appleのライブラリであれば、かろうじてiOSアプリ開発のボキャブラリーとして通用しWeb検索でも対応策が見つかる(そもそもiPhoeアプリ開発コミュニティーの規模が小さい)。

経験上、途中から参加したアプリプロジェクトのメンテナンスにおいて期待を通り(?)に化石化した便利ライブラリが見つかる。Moya+AFNetworking の組み合わせは手をつけると脆く状態を保持しつつ(Apple謹製コードに)置き換えが難しいデカイ恐竜の化石といったところである。

恐竜の化石のメンテナンスで金銭を得ることは可能であるが開発者として誠実かというとまあ違うだろう。