Tech Racho エンジニアの「?」を「!」に。
  • Ruby / Rails以外の開発一般

iOS 13における必須対応について(更新版)

更新情報

  • 2019/08/28: 初版公開
  • 2020/11/25: 各項目について現在の状況を追記

はじめに

こんにちは、主にiOSアプリの開発を担当している川島と申します。

iOS 13のリリースが間近に迫りつつあり、またWWDC2019ではSwiftUIを始めとした新しいツール等の発表、ARKit2やCombineフレームワークなどの発表などにより、昨今のiOS界隈が盛り上がりを見せています。

そうした新しいツールや技術が登場する反面、Appleはバッサリとした互換切りや新技術への対応を短期間で強いる傾向にあり、既存プロジェクトの保守などをしているiOSアプリエンジニアはこの時期に頭を悩ませる人が多いのではないでしょうか。
2年前のSafeArea対応なんかは記憶に新しいですね。

今年もそうした「〇〇対応が必須」のような情報はチラホラと聞きますが、断片的な情報が多い印象です。

この記事では今後iOS 13(及びiPadOS)にて対応が必須となる、もしくはなりそうな件について、なるべく公式の情報を交えつつまとめて紹介します。

注意

あくまでも執筆時点(2019/08/20)の情報を元にした記事となります。
現在はiOS 13のbeta版が出ている状態であり、今後公式ドキュメントなどを含めて変更・更新される可能性は大いにありえます。
そのため、必要な情報については適宜ご自身でご確認ください。

1.「Sign In with Apple」の対応の必須化について

追記(2020/11/25)

他社のログインサービスやソーシャルログインサービスを使用するAppでは 2020年6月末より必須になりました。

Apple Watch Appは、watchOS 6 SDKかそれ以降のバージョンでビルドする必要があります。 ユーザーアカウントの認証や設定を行うAppは、App Store Reviewガイドラインのガイドライン4.8での要求に該当する場合、「Appleでサインイン」をサポートする必要があります。
developer.apple.comより

「Sign In with Apple」はセキュリティ及びプライバシー面を強化したAppleのサインインシステムになります。
また、端末でログイン済み状態であれば認証が簡略化できます。

6月のApp Storeレビューガイドラインのアップデート情報に以下の記載があります。(2019/08/20時点)

Sign In with Apple will be available for beta testing this summer. It will be required as an option for users in apps that support third-party sign-in when it is commercially available later this year.
Updates to the App Store Review Guidelines - News - Apple Developerより

ソーシャルログインなど、サードパーティ製のサインインシステムを利用しているアプリには、今年の後半以降にログインオプションの選択肢の一つとしてこのシステムを導入することが求められるようです。
こちらの対応必須化は、ほぼ確定かと思われます。

対応にあたっては、ガイドラインが指定されており、サインインのボタンを目立つように配置する必要があります。

Button Size and Position
Prominently display a Sign In with Apple button.
Make a Sign In with Apple button the same size as other sign-in buttons,
and avoid making people scroll to see the button.
Sign In with Apple - Sign In with Apple - Human Interface Guidelines - Apple Developerより

ログインシステムに関しては、アプリ開発と担当が分かれている場合も多いため、サードパーティ製のサインインシステムを用いているプロジェクトに関しては、適宜情報共有を行ったほうがよいでしょう。

2. Launch Storyboard、全ての画面サイズ、画面分割機能対応の必須化について

追記(2020/11/25)

iPhoneやiPad向けAppはiOS 13 SDKかそれ以降のバージョンを使ってビルドし、Xcodeの StoryboardでAppのLaunch Screenを使用する必要があります。
iPhone AppはすべてのiPhoneスクリーンをサポートし、iPad AppはすべてのiPadスクリーンをサポートする必要があります。
developer.apple.comより

Launch Storyboard、全ての画面サイズの対応については、2020年6月30日以降対応が必須となっています
画面分割機能対応については、今の所、Apple からの告知は特に無いようです 。

WWDC2019にてAppleが、2020年4月までに全アプリがLaunch Storyboard、全ての画面サイズのサポート、iPadにおける画面分割機能の対応を行う必要がある旨を宣言しています。(2019/08/20時点)

以下の二点の対応を行う必要があります。

  • Launch Imagesを廃止し、Launch Storyboardに移行する
  • iPadに対応している場合、画面分割機能を有効にし、フルスクリーン以外の画面対応

Launch Storyboardに対応すれば、全画面サイズの対応は行なえます。
公式が大まかな日付まで明示しているため、来年の4月にはほぼ確実に対応必須となるでしょう。

3. ダークモード対応の必須化について

追記(2020/11/25)

今の所、状況は変わっておらず、強く推奨のままとなっています。

iOS 13 SDKでは、デフォルトでダークモードに対応している状態とみなされます。
標準のUIでは、ユーザがダークモードを選択すると外観が勝手に変更されてしまいます。

大抵のアプリでは標準のUIとカスタマイズしているUIを併用しているものと思います。
ダークモード未対応のアプリをそのまま出した場合には、ユーザの端末の設定によっては、奇天烈な見た目になってしまうでしょう。

これについては、Info.plistUIUserInterfaceStyleキーにlightを指定することで、アプリ内では常にライトモード扱いとなり回避可能なようです。

しかし、公式のドキュメントに以下の記述があります。(2019/08/20時点)

Supporting Dark Mode is strongly encouraged. Use the UIUserInterfaceStyle key to opt out only temporarily while you work on improvements to your app's Dark Mode support.
Choosing a Specific Interface Style for Your iOS App | Apple Developer Documentationより

UIUserInterfaceStyleキーによる回避は、あくまでダークモードへの対応作業が完了するまでの一時しのぎに限られる」という内容になっています。

今期中に必須として対応を求められるかについては不明ですが、かなり強めの言い回しとなっているため、いずれは対応が必要になるかと思われます。

大きいアプリになってくると、ダークモードの対応にはかなりの工数を割かれる可能性が高く、また対応自体はアプリのアクセシビリティの向上にもつながるため、今のうちに検討をした方が良いでしょう。

4. UIWebView の廃止

追記(2020/11/25)

App Storeは、2020年4月からUIWebViewを使った新しいAppの受付を終了し、2020年12月からUIWebViewを使ったAppのアップデートの受付を終了します。
developer.apple.comより

新規アプリについては、4月からUIWebViewを使ったアプリはリジェクトされるようになりました

Appのアップデートの期限を2020年末以降に延長します。正式な期限が決まり次第お知らせします。
developer.apple.comより

既存のアプリについては、2020年12月でアップデートの承認を終了する予定でしたが、おそらく、コロナの影響で期限が延期となるようで、現在の期限は未定となっています

昨年、Deprecatedになって記憶に新しいUIWebViewですが、iOS 13 SDKで廃止になるのでは?との噂が弊社内で流れました。
というのも、公式のドキュメントでは、

SDK iOS 2.0 - 12.0

との記載になっており(2019/08/20時点)、iOS 13 SDKでサポートする雰囲気が無いからです。

とりあえず、Xcode 13 beta6(執筆時点での最新バージョン)で実行してみたところ普通にUIWebViewを使えました。
ドキュメントの更新漏れか?と考えていましたが、調べてみたところそうでもなさそうです。

以下に、AppleのWebKitのアーキテクチャを担当しているBrady Eidsonさんの、6月5日にTwitterのつぶやきを転載します。

まだ、UIWebViewはiOS 13で存在しているが、将来のリリースで消えますとのこと。

少し古めのアプリであれば、UIWebViewを利用しているアプリは多いのではないでしょうか。
流石に今からXcode 11のbeta版の更新でUIWebViewがいきなり消えるのは考えにくそうですが、次のマイナーバージョンアップでばっさり削除などはありえるかもしれません。

まだ未対応のアプリについては、WKWebViewなどへの移行を検討する時期かもしれません。

5. その他

presentViewControllerのデフォルト表示が変更

presentViewControllerで画面遷移した場合のデフォルトの表示が変わり、下のViewが見えるような状態になります。

UIModalPresentationStyleにautoが追加され、デフォルトのモードがautoとなっています。
確認したところ、

  • iPhoneの場合: pageSheet、fromSheet、popoverなど(複数のモードが同一表示)
  • iPadの場合: pageSheet

と同じ表示になっているようです。

ドキュメント: UIModalPresentationStyle - UIKit | Apple Developer Documentation

全画面表示をする場合はfullScreenに変えましょう。

viewController.modalPresentationStyle = .fullScreen

iPadOSのユーザエージェント

アプリエンジニアにはあまり縁がなさそうな話ですが、
beta版の現状ではiPadOSではmacOS Safariと同一のユーザエージェントを返してしまうようです。

ユーサエージェントでiPadかどうか判定しているケースなどでは、気をつけた方が良いかもしれません。
少し調べてみたところ、解像度からiPadかどうか判断する方法があるようです。

(詳しくは参考文献の「Quiita: ユーザエージェントでの iPad 判定関数 iOS/iPadOS 対応版(2019/08/20時点)」をご確認ください)

おわりに

昨年はiOSのバージョンアップによる既存プロジェクトに影響がありそうな問題というのはあまり多くなく、だいぶ落ち着いている印象でした。

今年はリリース直後は平穏な感じがしますが、年明け頃から既存プロジェクトへの影響がそこそこありそうな制約が公式から告知されそうですね。

参考文献


CONTACT

TechRachoでは、パートナーシップをご検討いただける方からの
ご連絡をお待ちしております。ぜひお気軽にご意見・ご相談ください。