iOS開発におけるライブラリの選定戦略について考えてみた
Table of Contents
ライブラリ選定に悩んでますか？私も悩みます。便利なら何でも入れてますか？それなら怖いですね。
ネットでは執筆当時のトレンドに合わせたライブラリセットを紹介してる記事もありますね。
慣れない人は鵜呑みに取り入れて目の前の問題を解決し自信を持っていますが、 事業成長に合わせたライブラリを使うメリット・デメリットを考慮していますか？
去年年末にこんなツイートを呟きました。
AFNetworkingは潮時
— もちゅる｜リモートパパエンジニア (@mothule) November 27, 2019
UIWebViewが非推奨になってからWKWebViewに差し替えるPRが牛歩過ぎて業務スピードに全く追いついけていない。
ObjCはSwiftのバージョンによる破壊変更に依存しないため安定性維持メリットがあったが、今回のAPI依存だと安定性が災いして更新速度が牛歩。https://t.co/uclNZQ8WC3
ちょっとこのこともあるし、ライブラリ最高文化な風潮がiOSにはあるので、それって他プラットフォームのメリットを鵜呑みにしてない？って思うこともあり考えてみました。
近年のアプリ開発においてOSSの利用は必要不可欠です。
でもリスク分かって取り入れてるのかな？って疑問に抱く記事を見かけるときもあります。
ライブラリを使う上でどう付き合っていくべきなのか？ってのを少し考えてみました。
私個人の経験のもと判断した物なので、これが全ての答えとは思わないでください。
大事なのはリスクコントロールです。
Swift製とObjective-C製のライブラリどっちが良いか？
さきのAFNetwrokingの件も踏まえて私は次のような判断です。
- Objective-Cは普段は安定しているが変更時の リスクが大きい
- Swiftは新しいライブラリやSwiftyだが変更の リスクが多い
Objective-Cは普段は安定しているが変更時のリスクが大きい
言語として落ち着いており今後目新しい追加や変更はないものと見てます。
言語としてどうなのか？疑問はありますが、良い意味で変わらないので、その上で作られたプログラムは言語都合で変更を余儀なくされるリスクは低いです。
しかし、悪い意味で言語として衰退しており、その上で作られたプログラムをメンテナンスする人も減ることで、API仕様変更で対応が必要になっても、対応する人がいないリスクもあります。
Swiftは新しいライブラリやSwiftyだが変更のリスクが多い
SwiftのライブラリはSwiftで書かれているためSwiftyな使い方が出来るので、使う側からしたら使い心地は良いものです。
しかし言語としてまだ未熟で、言語仕様の変更に影響を受けやすいのでバージョンの更新は多くなります。
またそのライブラリ自体がライバルのライブラリと負けて衰退してメンテナンスする人が少ないと、ライブラリの撤退が早まります。
独断と偏見で領域別ライブラリの見方
- UI系のライブラリは変更リスクが一番大きい
- 通信系はセキュリティと新プロトコル以外は安定
- 永続化系は今後は大きな変更なく落ち着いていく
- テスト系は改善傾向
- アーキテクチャ系はハイリスクハイリターン
UI系のライブラリは変更リスクが一番大きい
iPhoneの強みはデザインです。
新しいデザインを取り込みます。
そんなコンセプト方針に一番影響受けるのはUIです。
一昔前に流行ったデザインも1年後には廃れてるのが日常茶飯事です。
独立性の高いUIライブラリの場合は寿命が長いですが、ひとまとまりのUIライブラリはそのデザイン自体が廃れたら終わりなので寿命は短命です。ただ入れるだけで簡単に画面が出来上がるのでスタートダッシュには向いてます。
通信系はセキュリティと新プロトコル以外は安定
通信は新しい通信方式が出たときにライブラリが旧式しか対応していないとリジェクトリスクが出るので変更は必要となります。
またAppleは個人情報大事マンになったのでセキュリティに力を入れるのは明白です。
永続化系は今後は大きな変更なく落ち着いていく
近年はデータはクラウド上やサーバー管理が主流なので、少し前に流行ったRealmあたりから落ち着いてます。
大きな変更は少ないとは思いますが、そもそもニーズがなさそうな気もします。
テスト系は改善傾向
Objective-CではSwizzlingでモックをラクラク作れてたのに、
Swiftはマニュアルモッキングというprintデバッグ並の最悪スタートだったのもあり、これ以上不便になることはないかなと思ってます。
少し前あたりからプロダクトコードを分析してテスト用モッキングコードを自動生成するライブラリも出てますし、
後はiOSがテスト環境ならprivateにもアクセス可能とかモック可能とかfinalでも継承可能とか自由度が効く改善をしてくれた場合の便利に向かう変更がありそうですね。
アーキテクチャ系はハイリスクハイリターン
もともとはMVCでしたが、MVPのあとにMVVMが出てきました。
それに加えてClean ArchitectureやVIPERアーキテクチャも出てきました。
より上位な概念としてDDDのプラクティスも介入してきました。
これらアーキテクチャの共通してるのは関心事の分離による依存排除です。
しかしSwiftではそれを実現するにはクラスやファイルを分けるしか方法がないため、
自然とファイルやクラス数は増えて、単純な変更にもまどろっこしい手続きとも呼べる変更作業が発生します。
これらを補足するライブラリや外部ツールが登場しています。
これらは全部根幹または根幹をサポートするライブラリなので、もしそのアーキテクチャが廃れてしまうと差し替えコストは甚大となります。選定には慎重に。
脱線: 決済会社や広告会社などのSDKにObjective-Cが多い理由
決済会社や広告会社などが提供しているSDKの場合は、iOSはObjective-Cが多いです。
明確な理由は会社それぞれですが、理由のいくつかとしては事業としてより多くの会社で使ってもらうには、両言語で使えるObjCが適しているからです。
またSwiftのように言語自体がまだ未成熟だと言語仕様が変更されるとSDKの更新も必要になります。
ライブラリと事業規模の関係性
「iOS開発はこのライブラリセットで最強」は危険な思想です。
前述したようにリスクを理解し、リスクに対する対策や選定をしないと痛い目を見ます。
ここらへんはロングメンテナンスを経験すると痛感します。
特に悪質な業務委託者などで時間給ではなく単価給でスピード重視で突発的に作られたりすると、負債が未来に後回しされます。
導入時はiOSチーム人数がネックとなる
ライブラリを導入する場合、導入障壁は影響範囲 x 人数に比例します。
人数が多いとそのライブラリへの理解や利用方法の把握が必要になります。
またチームによっては、対象ライブラリへの反対が一人でもいると、やはりその人へ説明する必要が出てくるでしょう。
対応や退却時はiOSチーム人数がキーとなる
反対にライブラリの更新や別ライブラリへの差し替えや退却は、人数が多いほうが作業を分散できるので、楽になります。
ライブラリは機材のレンタルだと捉える
事業スタート時期は負債をして利益を得ることを優先します。
利益が獲得し安定し始めた頃に負債を少しずつ返すことでフットワークを軽くし次を事業を拡大します。
企業みたいな話ですが、ライブラリの話です。
ライブラリは時限爆弾式ブースター
iOSのライブラリは宝くじのようにAPIや言語仕様の変更にぶつかります。
ライブラリを使うことで実装をショートカットしたり実装速度をあげたりできますが、仕様変更が起きることでライブラリの対応をしないといけません。自分らで対応可能な規模や難易度であれば自分らでfork&pull requestsで直すこともできますが、全てのエンジニアがそれを出来るとは限りません。
いつコストが炎上するか分からない時限爆弾のような存在です。
乗るタイミングより下りるタイミングが重要
ライブラリはずっと使い続けるものもあれば、一時的に加速するためのライブラリもあります。
何でもかんでもライブラリで解決すると、一度に炎上したときに手を付けれなくなります。
自前で簡易に用意していれば、簡単に解決できることでもライブラリとなると汎用性が高いことで構造が複雑になっていたり
Pull requests を投げてもなかなか承認されないという問題リスクもあります。
ライブラリはスターよりもアクティビティを見る
ライブラリを選ぶ場合はスターを基準にすると時として痛い目をみます。
スターは多くてもそれは過去のスター蓄積であって、今のスターとは限りません。
- コミットの時間
- コントリビューターの数
- Open Issueの数
- Closed Issueの更新日
- Pull requestsの数と提案日
これらを見て活発度合いを確認しましょう。
まとめ
- ライブラリ選定は事業規模を考慮する
- ライブラリ選定は領域毎に変更リスクを理解する
- ライブラリ選定はスターではなくアクティビティを見る
