※本記事は主に BizDev 向けの記事です
iPhone X への対応に追われていた時期もありましたが、落ち着いた時期だからこそ次の “嵐” に備えておくのも良いかもしれません。
「iPad のマルチタスクに対応していないアプリは 2020 年 4 月から App Store の審査に通らなくなる」というニュースは特に話題を集めていますが、2020 年は 4 月と 11〜12 月に iOS アプリの審査基準がアップデートされるようです（10 月には OS アップデートもあることも要注意）。
まずまとめると、2020 年の前期で見直しておくべきは
- iOS 13 の挙動（Launch Screen、Apple ID サインイン、ダークモードなど）
- WebView アプリの場合 → UIWebView に依存しているライブラリなどがないか
- APNs まわり（該当するアプリは少なそうですが）
- iPad 対応（Universal）アプリの場合 → Split View 対応
です。
iOS 13 対応に関する補足・注意点
- 位置情報と同様、Bluetooth 利用にもパーミッションが必須に
- ログイン処理を実装する場合は Apple ID でのサインインも必須
- UISerchBar の value(forKey:) メソッドが廃止
などがありますが、タフな作業になりそうなのは WebView まわりと iPad OS 対応でしょうか。
UIWebView の廃止 → WKWebView への切り替えが必須に
すでに運用中の iOS アプリがある場合、大きな影響を受けるケースもあります。
既に iOS8 以降で “非推奨” 扱いにはなっていましたが、2020 年 4 月以降に新規で申請するアプリでは UIWebView が使えなくなります。同年 12 月からは完全に NG となり、既存アプリのアップデート審査でも WKWebView への移行が必須になります。
特に「ライブラリが UIWebView に依存している」ことに気づいていないケースが最も危険なので、運用中の WebView アプリがある際はどこかのタイミングでの見直しを計画しておくと良さそうです。
WKWebView への移行でハマりがちなポイント
特に Cookie まわりでは iOS 8〜11 それぞれ固有でのハマりポイントがあったことで、これまで Web 上に多くの情報が挙げられています。
ただ、iOS 13 の公開により iOS 11 以下のシェアが 10% 以下に落ち込んだので、2020 年 12 月という嵐（完全に NG 化）への備えは iOS 12〜13 での挙動を理解しておくことになります。
また、基本的な仕様としても
- target="_ blank"が使えない
- POST パラメータが消える（ネイティブ側でのリクエストが必要）
- UserAgent の設定が変わる（「applicationNameForUserAgent」というプロパティで編集）
などの違いがあるので、移行作業には余裕を持って対応することが求められそうです。
参考：
iOS 13 以降でさらなる変化が？
iOS 13 では、これまでの WKPreferences クラスに加え、ページ単位での設定ができる WKWebpagePreferences クラスが実装されました。現状はいじれるパラメータが少ないですが、管理方法のアップデートとしては頭の片隅に入れておいたほうがいいかもしれません。
念のため、APNs（プッシュ通知）まわりの確認も
影響を受けるアプリは少なそうですが、
という二点が iOS13 対応の対象になります。
また、iOS アプリの運用を始めたばかりの企業は APNs を更新する（※一年ごとに必要です）という作業も習慣づけておきたいところです。APNs の更新を怠るとユーザーにプッシュ通知が届かなくなるため、事業に大きなマイナス影響を与えてしまいます。
参考：期限切れの前に！iOSのプッシュ通知用証明書（APNs）の更新方法
「マルチタスク対応必須」になる iPad 対応の補足
今回は Split View 対応必須化が注目されていますが、iPad が独自の OS として進化を続けることで、開発〜保守運用のコストがかかるようになっていきます。
もとよりネイティブアプリは iOS/Android という両 OS の対応でそれぞれの専門家・開発チームが求められているので、経営目線で考えると費用対効果のようなことを考え始める時期かもしれません。
ただ、注意すべきは、一度 Universal としてリリースした iOS アプリは、iPad 対応を省くために iPhone Only アプリにすることができません。
参考：iOSアプリ開発におけるデバイス選択 / Appropriate choise of supporting devices on iOS app development
ですので、今後開発する iOS アプリが iPad での利用をあまり想定していない場合、リリース時には Universal ではなく "iPhone Only" アプリとして出すほうが安全です。
開発者・事業者もまた「iOS は高コスト・高パフォーマンス」というブランドを背負っている
Apple 社からすると、ユーザーが「iPhone/iPad のアプリは（Android に比べて）使いやすい」という状態を維持することがブランドを守ることにつながります。端末価格も Android に比べて高価であるにも関わらず、特に日本では他国よりも高いシェアを誇っており、依然としてそのブランド力は衰えていません。
2018 年夏には App Store のアフィリエイトも停止し、事業者の PR 施策も ASO や動画広告に移行しました。事業者のコストは上がったものの、ユーザーとしては「絶対に使うべきアプリ 108 選」のような怪しげなサイトからではなく、動画やバナーなど公式の目が届いたコンテンツからアプリを認知できるようになりました。
とはいえ、開発も PR も、事業者に求められるコストは増加する一方なので、アプリ事業を展開する企業および開発者・運用担当者には今後もより体力が求められそうです。
iOS アプリの開発・運用を始めたい、あるいは内製化を検討している企業からはよく「iOS エンジニアがなかなか見つからない」という声を聞きます。
特にエンジニアにとっては、毎年アップデートされる開発環境をキャッチアップしながら開発 “チーム” として実務をスムーズに行えることが理想なので、個人や立ち上げ時点での組織よりは既に出来上がった組織（リモート含む）のほうが魅力的に見えることが多いのです。
企業としては「1 つのアプリを開発・運用するだけだから、ミニマムの開発チームでいい」と考えても、そのミニマムなチームで働くエンジニアは情報格差というハンデを背負うことになるのです。 “内製化” は机上ではメリットのほうが多いのですが、アプリ事業でスモールスタートを考えている企業にとってはクリアすべき課題もあるということを頭に入れておくべきでしょう。
Backapp では受託/自社プロダクトともにアプリ開発を手掛けるディレクター、PM、デザイナーを募集しています。
- 「折衝・調整や進行管理能力を生かして新たな分野の仕事にチャレンジしたい」
- 「アプリ開発のスペシャリストとしてもっと幅広い・大きな案件をこなして成長したい」
といった方はぜひ一度カジュアル面談でお話しましょう！