地引製作所

ある日、既存のプロジェクトで pod install を行ったところ、以下の警告が表示されました。（CocoaPodsのバージョンは1.11.3）

$ pod install
Analyzing dependencies
Downloading dependencies
Generating Pods project
Integrating client project
Pod installation complete! There are 3 dependencies from the Podfile and 9 total pods installed.

[!] Your project does not explicitly specify the CocoaPods master specs repo. Since CDN is now used as the default, you may safely remove it from your repos directory via `pod repo remove master`. To suppress this warning please add `warn_for_unused_master_specs_repo => false` to your Podfile.
$

あなたのプロジェクトは、CocoaPodsのマスター仕様のレポを明示的に指定していません。CDNは現在デフォルトで使用されているので、pod repo remove masterでreposディレクトリから安全に削除することができます。この警告を抑制するには、Podfileに warn_for_unused_master_specs_repo => false を追加してください。

https://www.deepl.com

CocoaPodsのマスターリポジトリの置き場所がCDN（Content Delivery Network、コンテンツデリバリネットワーク ）上に変わったのかな？そのため自分のリポジトリから今は使用されていないmasterをpod repo remove masterコマンドで消して欲しいということのようです。。

表示されたコマンドを実行してみたのですが、エラーになってしまいました。

$ pod repo remove master
[!] repo master does not exist

Usage:
（以下略）

エラー内容はmasterが存在しないとのことなので、リポジトリの一覧を確認してみます。すると master がなくて、代わりにcocoapodsというリポジトリがありました。

$ pod repo

cocoapods
- Type: git (remotes/origin/master)
- URL:  https://github.com/CocoaPods/Specs.git
- Path: /Users/xxx/.cocoapods/repos/cocoapods

trunk
- Type: CDN
- URL:  https://cdn.cocoapods.org/
- Path: /Users/xxx/.cocoapods/repos/trunk

2 repos
$

なので、cocoapodsを削除してみます。

$ pod repo remove cocoapods
Removing spec repo `cocoapods`
$

そして再び pod install を実行してみると、無事に警告は消えていました。

$ pod install
Analyzing dependencies
Downloading dependencies
Generating Pods project
Integrating client project
Pod installation complete! There are 3 dependencies from the Podfile and 9 total pods installed.
$

iOSアプリの仕事をやっていて、新規で作成するよりも既存のアプリの開発を引き継ぐことが多いのですが、ソースコードを見ていて思わず「嘘だろ・・・」と呟いてしまうようなものを紹介します。

この記事はEngineMaker界隈 Advent Calendar 2022 の3日目の記事です。

画面遷移をpushのみで行なっている

UINavigationControllerの画面遷移を全てpushで行なっていました。詳細画面に遷移する時だけではなく、元の画面に戻る場合もpushしていたのです。popしているところはありませんでした。

そのため画面を行ったり来たりすると次々に新しい画面のインスタンスが生成され、それらは消されでに画面スタックに積み重なっていき、やがてメモリ不足でアプリがクラッシュしてしまう、という状態でした。

一画面あたりのメモリ使用量が少なく（画面内の項目が少なかった）、また画面数も少なかったため、問題が発覚していませんでした。

【iOSアプリに詳しくない人に向けた解説】

特に詳細画面に遷移する場合など、UINavigationControllerクラスが使用されます。これは内部に表示された画面を保持するスタックを実装し、新しい画面に遷移する場合はpushで新しい画面をスタックに積み上げ、前の画面に戻る場合はpopで画面スタックから最後に表示された画面を取り外す、という方法を取ります。

このように今まで表示された画面のインスタンスが保持されていることにより、前の画面に戻る場合に画面インスタンの生成（とてもコストがかかる）をせずに素早く戻ることができます。

リスト表示画面をUIScreenViewで実装している

リスト画面が全てUIScrollViewで実装されていました。UITableViewは使用されていませんでした。

そのアプリにはいくつかのリスト画面があるのですが、ほとんど1ページ分くらいの項目しかなく、特に問題とされていませんでした。しかし、3ページ分くらいの項目があるリスト画面があり、そこのスクロールが異様に遅かったので調べてみたところ、全てUIScrollViewを使っていました。

【iOSアプリに詳しくない人に向けた解説】

リスト画面ではUITableViewを使用します。これは画面に見えている項目（以降セルと呼びます）の分だけインスタンスを生成し、スクロールさせた時に画面から見えなくなったセルのインスタンスを削除せずにストックしておき、新しく見えてきたセルとして再利用する仕組みになっています。

これにより、画面に見えている分のセルの分しかメモリを消費せず、また再利用することによってセルのインスタンスの生成（コストがかかる）を大幅に省くことができ、何万行もあるようなリストでもヌルヌルサクサク動かすことができます。

Webなんかだと何万行もある場合は100行ごとにページを分けたりしますが、iOSでは上記の仕組みによりその必要はないのです。