(2)はこちら https://qiita.com/satoru_pripara/items/3a229b58dba9ddccc51f
App Store Guideline 5.1.1(v): Apps supporting account creation must also offer account deletion
アプリ内でアカウントの作成をできるようなアプリは、アプリ内でアカウントの削除機能も提供する必要がある。
- 適用時期はいつなのか(既に順次適用されていく? あるいは期限がある?)
- どのような機能が必要か(アカウントの非活性化などで足りるのか、アカウントのデータの完全な削除まで必要か)
- どこで削除できなければいけないか(Webサイトに飛ばすだけで足りるのか、アプリ内で削除しないといけないのか)
以上詳しい部分はForumでも定説があるわけではない。
https://developer.apple.com/forums/search/?q=5.1.1&page=1&sortBy=newest
最悪の場合は、「今すぐ」「アカウントのデータを完全削除できる機能を」「アプリ内で」実行できるようにしない限り、新規アプリが拒絶されたり、既存のアプリが順次指摘を受け公開停止になるな可能性がある。WKWebViewを用いてアカウント削除のためのWebページを表示するのであれば問題ないのではないかと個人的には考えている。WKWebViewであればアプリ内の機能でないとは言えないと思うため。Safariで開くとかだと、Safariという別アプリを使っていることになるので、アプリ内で削除機能を提供しているとは言えず、ダメと言われるのではないかと考えている。
Add intelligence to your widgets
ウィジェットの機能の解説
- 時間によってどのアプリのウィジェットを表示するか切り替える
Smart Rotate
- まだ使っていないウィジェットをユーザーに知らせる
Widget Suggestion
Add rich graphics to your SwiftUI app
SwiftUIで、
- safeAreaの扱い方(SafeAreaを無視して描画するなど) 通常のステータスバー・ホームバー用のセーフエリアのほかに、キーボード用のセーフエリアの設定も可能だとは知らなかった。
-
- foregroundStyle: Textなどに適用し、文字の色が背景色からの影響を受けるどうか、四段階で設定できるなどの機能があるとのこと。
- 複数のグラフィックに統一的な操作を施せる.drawingGroupモディファイア、複雑なグラフィック記述を記載できるCanvas、時間経過に従ったグラフィックの変化を記載できるTimeLineViewなどを用いて、SwiftUIで複雑なグラフィックを実現する一例を示している。複雑なエフェクトの描画などを行うのであればチェックしておいた方が良さそう。
Apple’s privacy pillars in focus
Appleが策定したプライバシーを守るための4つの原則を提示した上で、Appleの新しい技術でどのようにそれらの考え方を守り推し進めているかを解説している。
- 取得するデータの最小化 -> 本当にこの個人情報を取得する価値・理由があるか?というのを考え、取得する個人情報は最小にすべき。
- オン・デバイス処理(データをサーバになるべく送らない) -> どうしてもデータをサーバに送る必要があるのか?を考え、可能な限り取得した個人情報はデバイスに持っておくのみにする。
- 透明性・ユーザーによる情報コントロール -> 取得した個人情報をどう扱うのか? という点を明確にし、ユーザーに分かるようにする。またユーザーがその個人情報をコントロール(提供停止・削除など)できるようにする。
- セキュリティ保護 -> データの保護(暗号化など)
- Data Minimization(本当に必要な個人情報のみ取得する)の例として、新しくShare My Current Location ボタンというものを紹介している。これは以前導入された「位置情報の使用を一回のみ許可(Allow Once)」の代替である。このボタンを押した場合はダイアログが表示され、そこで位置情報を許可すると、同一セッション(アプリをキルするまで)は位置情報の使用が許可される。
Allow Onceとあまり変わらない気もするが、ユーザー自身のアクション(ボタンをタップ)で位置情報取得が開始されるものなのでよりユーザー自身のコントロールが効いていると言える。ボタンの外見はカスタマイズできる。
-
Paste Notice(コピペをしたときに表示されるアラート)が、ユーザーがpasteボタンを押した時などユーザー起因のペーストの時は表示しなくなり、アプリがユーザーの知らないうちに勝手にペーストする時だけ表示するようにしたとのこと。
-
Siriが音声データを端末内部でのみ処理するようになり、サーバには送らないようにしたとのこと。
-
Eメールは、目に見えない画像などの要素を勝手にダウンロードして、ユーザーのデータを勝手にトラッキング していることがある。Apple公式のメールアプリでは、これに対する防御の機能 Protect Mail Activityを入れたとのこと。
参考 kaspersky daily - メールのトラッキングとその対策
-
チャット系のアプリなどで、あるユーザーの状態(アクティブ状態・離席状態など)を取得し、これを他のチャットユーザーに見せたい場合があると思う。この場合、NSFocusStatusUsageDescriptionというキーで使用理由を記載する必要があるとのこと。
-
Macで、音声レコードが働いている際は、どのアプリから使われているかを示すラベルがコントロールセンターに表示されるようになるとのこと。
-
iPhoneの設定アプリで、どのアプリがどのような個人情報を使っているかをレポート形式でユーザーに示す、App Privacy Report機能が追加されるとのこと。
Bring accessibility to charts in your app
株価関係のアプリや健康・フィットネス系のアプリでグラフをよく使うと思うが、それらを視覚障がい者にも見やすくする方法を解説している。
- 色のコントラストを高くすること。XcodeのAccessibility Inspector内で使えるColor Contrast Calculatorの使用を推奨している。
- 赤と緑の組み合わせを避けること。次いで、青と黄色の組み合わせを避けること。
- 色だけでなく記号などを用い、色が分からなくても識別できるようにすること。
また、AudioGraphで、グラフのデータを音声読み上げする方法を解説している。
Connect Bluetooth devices to Apple Watch
Bluetooth周辺機器などに接続する場合で、Apple Watch用アプリの作成を行うなら見ておいた方が良い。
Craft search experiences in SwiftUI
SwiftUIに導入された.searchable
モディファイアをNavigationViewなどのViewにつけると、自動で検索窓が表示される。
NavigationViewに付けた場合で、NavigationViewに複数のViewを入れて画面が複数カラムになっている場合、iOS, watchOSであれば左側(leading側)のViewに検索窓が表示される。macOSであれば右側(trailing側)のViewに検索窓が表示される。
検索中か否かで画面の表示を変えたいなどあれば、@Environment(\.isSearching)
という変数で判定できる。
serachableモディファイアにはcompletionHandlerを渡すことができ、検索ワードのサジェスト表示のビューをどう表示するかを設定できる。
.searchCompletion
モディファイアは、サジェストの結果を実際の検索ワードの変数に代入してくれるもの。
ユーザーが検索ワードを決定したときの挙動は、onSubmit
モディファイアで定義できる。
Create 3D models with Object Capture
物体を360からカメラで撮影し、ARアプリなどで使えるモデルを生成するまでの手順やコツなどを消化している。その手の動作を実装するのであれば見ておこう。
Create custom audio experiences with ShazamKit
https://developer.apple.com/videos/play/wwdc2021/10045/
ShazamKitのカスタムカタログの使い方を説明している。
ShazamKitの基本についてまずはExplore ShazamKitの方を参照しておこう。
ベストプラクティスとしては、
- 生成したカスタムカタログは.shazamcatalogファイルによってネットワークを通じて複数の端末に共有できるので、これを利用する
- 音声データのメタデータにはアプリのユースケースに合わせて自由なデータを設定できるので、状況に応じて利用する
- マイクを使用する場合は、
matchStreamingBiffer
を可能な限り利用してほしい
とのこと。
Explore ShazamKit
ShazamKitは入力された音が特定の音声ファイルのライブラリの中のどのファイルと合致するかを検索できます。入力された音や声の内容を分析するような機能ではないことに注意。スピーチの文字起こしとかに使うものではありません。
音声ライブラリは、デフォルトではAppleが管理しているShazam catalogが使われます。Shazam catalogはクラウド上にあり、 最新の各種有名音楽が含まれているライブラリとのこと。これとは別に、自分で用意したカスタムの音声ライブラリも使うことができます。
検索の流れは以下の図のようになっています。元の音楽を変換したSignature
という音声をSessionに渡します。Signature
は元の音声を圧縮したようなもので、これだけ聞いても元の音がなんなのかはよく分からなくなっており、また元の音に変換し直すこともできないため、音声データの流出の恐れがないとのこと。
こちらをShazam Catalogの音声群と付き合わせ、マッチしたものがあれば、session delegateを通じて、Media Itemクラスのインスタンスが返ってきます。返ってきた情報には、音楽の名前、アーティスト名、アルバムアートやApple Musicで開く場合のURLなどが含まれるとのこと。
カスタムカタログではなく、Shazam カタログを使う場合は、Apple Developer > App ID > App Servicesの項で、Shazam Kitにチェックマークを入れる必要があります。
また、各ユーザーにShazam Library
(Shazam Catalog
とは別)が用意されており、検索してきた音楽をそこに追加することができるとのこと。Shazam Library
に今何が追加されているかは、Apple公式のShazamアプリか、端末のコントロールセンターから確認できるらしい。
Tipsとしては、
- マイクからの音声入力などリアルタイムの音声入力を使用する場合は、バッファ(
matchStreamingBuffer
)を利用すると良い - マイクを使う場合は、検索が完了したらすぐマイクの使用を止めて、端末の電力の消耗を抑えること
-
Shazam Library
に保存するか否かは、ユーザーの選択に委ねること
が挙げられています。
Discover built-in sound classification in SoundAnalysis
CreateMLにより音声解析を行う方法が紹介されています。
音声の判定により、どういった音声か(カテゴリ)、判定の信頼度、音声のどこから何秒間続いたかなどの情報が得られます。
カテゴリは、Appleがあらかじめ生成した訳300のカテゴリがあり、それらに自動で分類してくれるとのこと。例えば、各種楽器の音や、人間の声、水や風など自然物の音、各種動物の鳴き声、車など道具が出す音など。
Enhance your app with Metal ray tracing
Metal APIにより、3Dグラフィック描画の際行うレイトレーシングが効率的にできるようになったことを紹介しています。レイトレーシングとは、光源から発される光の反射をシミュレートし、影の見え方などをより現実的に見せる技術を指します。
Explore HLS variants in AVFoundation
HLSで、動画のダウンロードをする際にAVFoundationを用いてSDR/HDR, FPSなど動画の特性をチェックしていくやり方を説明しています。
HLSとは、Appleが2016年に開発した動画ダウンロード用のプロトコルで、動画を10秒ごとに分割しそれらをプレイリスト形式にしてダウンロードしていきます。通信は全てHTTPで行われるため、特別なソフトウェアなどは必要ありません。動画のストリーミング再生でよく使われます。
HTTP Live Streaming
HLS 【HTTP Live Streaming】 HTTPライブストリーミング
SDR/HDRとは、動画の輝度(一度に表現できる明るさの範囲)を指します。
よくわかる、HDR徹底解説! HDRとは
Explore Nearby Interaction with third-party accessories
近距離でデバイス同士の距離をかなり正確に測定できるUWB(超広域帯無線通信)を用いたNearby Interactionを実装する方法を解説する。
iPhone, Apple Watchなどの端末同士のほか、端末とサードパーティ製アクセサリとの距離計測も可能。
Explore Verifiable Health Records
Health Kitを用いて、医療情報をアプリへ安全にダウンロードできるVerifiable Health Recordsについて解説しています。
このレコードのデータとしてはFHRという規格が用いられています。アメリカなど海外を中心に使われている医療情報共有のための共通規格です。日本でも取り入れようという動きはあるようです。
Verifiable Health Recordsは、FHR形式のデータを暗号化したJSONであるJWS形式で表したものになります。暗号化されているので安全性が高くなります。
JWS公式
iOSの実装側としては、JWEはCryptoKitを使って解読する必要があり、その方法も平易に解説されていました。
Verifiable Health Recordsのダウンロード元について、アメリカ・カナダ・イギリスには既存のHealth Recordというデータベースがあり、そこからDLできます。その他の国では、.smart-health-cardsという形式のファイルや、QRコードを使ってアプリにダウンロードする方法があるようです。
ダウンロードしてFHRが得られた後、これをアプリで利用する前に、ユーザーに許諾を得る必要があります。許諾は各データごとに一回一回必要になります。
Faster and simpler notarization for Mac apps
Notarization(公証)とは、MacアプリをAppStoreを介さず自社ウェブサイトなどで公開する場合、アプリ内に悪意あるプログラムなどが含まれていないか事前にAppleがチェックするという制度で、以前からaltool
経由で使うことができました。
今回は新たにNotaryAPIが用意され、また速度も改善され、コマンドラインで申し込むだけで、数十秒で結果が返ってくるほど早くなったとのことです。CI/CDにもかなり簡単に組み込めそうです。
Focus on iPad keyboard navigation
キーボード操作(矢印キー・タブキー・エンターキーなど)でiPadアプリの操作をするにはどう実装したら良いかを解説しています。
例えば、矢印キーを入力するとコレクションビューの各セルへフォーカスが映る、タブキーを押すと画面の各部品にフォーカスが移るなど。
TextField, TextView, SideBarはすでにデフォルトで有効化されていますが、他にCollection View, TableView, その他自分で実装するカスタムViewクラスでも有効化可能とのこと。
UIFocusItemプロトコル(UIViewが準拠), UIFocusEnvironment(UIViewControllerやUIViewが準拠)を用います。
デバッグツールも充実しており、lldbでビューのフォーカスの状態を調べられるほか、画面上にフォーカスの順番などを表示させるデバッグもできるようです。
Get ready for iCloud Private Relay
Appleの新サービスiCloud Private Relay
について解説しています。こちらは、iCloud+に契約しているユーザーが明示的にONにした時のみ有効となるサービスとのことです。
これ無しの場合は今まで通り普通に通信を送る事になり、DNS 名前解決の際や、TCP/TLS handshakeの際にユーザーのIPアドレスやユーザーが要求するサーバーのドメインがネットワークに普通に流れるタイミングがあるため、これを何者かが検知できてしまいます。また、相手サーバー側もユーザー側のIPアドレスが分かってしまう事になり、ユーザーの明示の許可なくユーザーのIPアドレスを用いてユーザーのおおよその位置を把握するなどができてしまっていました。
これに対して、iCloud Private Relayでは、ユーザーのデバイスとサーバーの間に、AppleがIngress Server
とEgress Server
というプロキシを二種もうけています。これにより、ユーザーのIPアドレスは隠蔽されるので、ユーザーのIPアドレスとユーザーの請求先ドメイン両者を知る者は誰も(Appleでさえ)いなくなります。
なお開発時にiCloud Private Relayをテストする際には、Appleが提供するURLSession
またはNWConnection
(NWConnection.establishmentReport)を使えば、開発時に限りiCloud Private Relayを使っていてもトラフィックのチェックができるので、デバッグの際は必ずこれらのApple公式クラスを使って欲しいとのこと。
また、サーバー側の対策としては、ユーザーのIPアドレスから勝手に位置を算出するなどは辞め、位置情報が欲しいのであれば明示的にユーザーに情報提供を求めるようにすべきとのこと。
Meet DooC Documentation in Xcode
Xcode13よりDocC(ドック シー)という機能が追加され、コードコンパイル時にコードの中に書かれている三文字スラッシュ(///
)のコメントをドキュメント化してまとめてコンパイルし、アーカイブとしてエクスポートできる機能が追加されたとのこと。特に、自作フレームワークを作るときなどにドキュメント作成は必須になってくると思うが、この時に役立つ。
![截屏2021-08-07 20.34.44.png](https://q![截屏2021-08-07 20.45.19.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/392332/0c36c18a-7335-0700-e0ca-5929931a5c06.png)
iita-image-store.s3.ap-northeast-1.amazonaws.com/0/392332/e8a71e50-af4b-97bf-7852-f8cac69065be.png)
xcodebuild
コマンドにもxcodebuild docbuild
が追加され、コマンドラインからでもドキュメントのコンパイルが可能。
また、ドキュメントの書き方として、二重の`で囲うことで、他のクラスやメソッドなどへのリンクを貼る機能も追加されている。
またこのDocCはオープンソースとして公開予定であり、ウェブ上にドキュメントを公開する機能も予定しているという。
Host and automate your DocC documentation
DooCでドキュメントを作成し、ウェブサーバで公開し、またXcodeプロジェクトをビルドした際自動でドキュメントを更新しウェブサイトも更新する手法を紹介している。
新規追加されたxcodebuild docbuild
は、プロジェクトをビルドすると同時にドキュメントもビルドして作ってくれる。
ドキュメントは「.doccarchive」という拡張子で作られるため、そのファイルを検索しウェブサイトの資材が入っているフォルダにコピーしている。
Immerse your app in spatial audio
Spatial Audioという新技術で、ユーザーが音楽・映像を見ている最中に違う方向を向くなどして耳の位置を買えたとしても、前後左右など複数チャンネルからの音響が常に一定方向を保たれるようにする。今までは、頭を動かすと(当然)それに音声チャンネルの方向も追随していた。この技術においては、あたかもユーザーが映画館にいるかのように、音声チャンネルの位置が固定されより現実感のある体験を提供できる。
基本的には、
- マルチチャンネルを含む音声・映像であること
- DRCメタデータを提供すること
- iOS, tvOS, iPadOS, macOSのうち最新3リリース以内であること
といった条件を満たせば、特に何もしなくてもこの機能が利用可能だという。
マルチチャンネルとは音響が発生する方向が2方向(左右)を超えるものをいう。例えば5.1チャンネルサラウンドがこれに当たる。
参考 通信用語の基礎知識 - マルチチャンネルオーディオ
DRCメタデータとは、DRC(Dynamic Range Control)の実装に必要なメタデータを言う。各セグメントの音の大小などが記録されており、小さい音となってしまっているセグメントの音量だけ拡大させるなどの用途に使用する。
MPEG - Dynamic Range Control Metadata Makes Itself Heard
Meet Group Activities
Group Activityとは、複数人同士でセッションを確立し、映像・音声などなどのコンテンツを遠隔地にいる複数人で共有して閲覧・作業できるもの。映画や音楽の鑑賞、絵を一緒に書くなどが例としては想定されている。
映像などのコンテンツそのものはこのAPIでユーザーに共有されるわけではなく、あくまで映画の再生・一時停止・スキップなどのイベントが1セッションを共有する全ユーザーに瞬時に共有される。iOS, macOSなどのAppleのOSのほか、Webサイト上でも利用可能とのこと。
Meet MusicKit for Swift
MusicKitとは音楽関係の操作を簡単にできるようにするAPIで、最新機能であるasync awaitやSwiftUIにも最適化されている他、Apple Musicとも連携しています。Apple Musicからの音楽データ取得や再生・購読促進ダイアログの表示まで一通り行うことができます。しかも、async awaitやSwiftUIに対応していることからかなり簡単にできる印象でした。
Meet Safari Web Extensions on iOS
Safari Web Extension(ブラウザの拡張機能)をiOS等で作る手順等について説明しています。もちろん全くのゼロから作ることができる他、すでに存在している他ブラウザの拡張機能をiOS等に適応させたり、すでにあるmacOS Safari用extensionにiOSサポートを追加することもできます。
iOS上ではSafari拡張機能はアプリとして扱われ、App Storeにアップロードしていくことになります。
ゼロから作る場合、テンプレートがありますのでそこから選択します。
すでに存在している他ブラウザの拡張機能をiOS等に適応させる場合は、以下のコマンドを叩くことでプロジェクトが生成されるそうです。
xcrun safari-web-extension-converter [options] <path to extension>
すでにあるmacOS Safari用extensionにiOSサポートを追加する場合は、以下のコマンドを叩きます。
xcrun safari-web-extension-converter [options] --rebuild-project <path to extension>
MacのSafari Web Inspectorでデバッグをする方法も解説しています。MacのSafariの開発者メニューを有効化すると利用できます。
また拡張機能作成の際のベストプラクティスについても多く解説しています。
ブラウザ拡張機能ではバックグラウンドで何かスクリプトを走らせることもあると思います。iOSではバックグラウンドのページを常に走らせっぱなしにすることは禁止とのことです。manifest.json
でpersistent: false
を指定すべきとのことです。
また、いくつかのAPIはiOSでは動かないため注意が必要とのことでした。windows.create()
, windows.remove()
, windows.update()
, browser.contextMenus
, browser.webRequest
等・・・
また、iOSのSafari拡張機能に置いては、ユーザーの何らかの個人情報にアクセスする場合、逐一許諾をとる必要があります。例えば、タブのURLやタイトル、Cookieの取得、scriptのインジェクションを行いたいときなどです。さらに、許諾を永続的に取る必要がない場合(=このブラウザセッションの、このタブでのみ許諾を得ればいいとき)はactiveTab permission
という一時的な許諾にとどめておくべき、とのことでした。ユーザーの個人情報取得を最小限に抑えるべきというAppleの哲学を反映したものといえます。
Meet Shortcuts for macOS
iPhoneで使うことができたShortcuts(さまざまな動作を定義しオートメーション化できるApple公式アプリ)がMac OSでも使えるようになるとのことです。
その開発方法について解説されていました。
-
配布方法
-
intentの作成
どのようなtaskにどのような動作を行うかと言うことを定義したintentを作成していく必要があります。具体的には、Xcodeからintent definition fileと言うファイルを作成し、行う動作を定義していきます。これが完了すると、intentを表すクラスがXcodeにより生成されます。
- intent handlerの作成
Shortcuts で行われた動作がintentとして発出されるので、これをintent handlerで処理していきます。intent handlerは普通にアプリ内で定義することもできるほか、別のextension(intent Extension)としてアプリの外側に定義することもできます。
以下では、Shortcutsでユーザーが入力したタイトルと日時を受け取り、空文字であれば再入力を要求し、そうでなければ先に進むという処理をしています。
- macOS特有の処理
macOSではiOSと違ってファイル・フォルダを扱うことが多いので、ファイル・フォルダパスの指定がやりやすくなるよう、APIが準備されているとのことです。
Meet StoreKit 2
アプリ内での購入・サブスクリプションなどを司るStoreKitの2が登場しました。
Products, Purchases, Transaction info, Transaction History, Subscription status の五要素から成るようです。色々、初代StoreKitよりも簡単な書き方でできるようです。
何箇所かでJWS(JSON Web Signature)が使われているようです。
Meet TestFlight on Mac
2021秋からMacもTestFlightが使えるようになります。Macアプリのほか、Apple Siliconの場合はiOSアプリも試験できます。Apple SiliconによるiPhoneアプリ試験を許すかどうかというようなオプションも追加されます。
Internal Group(テストを行う内部グループ)の設定が細かくできるようになります。複数の内部テスターグループを作成し、それぞれに異なる設定ができます。例えば、開発チーム向けには自動的に全ビルドをテスト用に提供するが、QAチーム向けには安定した特定のバージョンのみを手動で提供するなどです。
またXcode Cloudとも連携しており、シームレスにTestFlightへアップロード可能です。
Meet Xcode Cloud
CI/CDがXcodeおよびApp Store Connectで設定できるようになります。
アーカイブの他、テスト、アーカイブ終了時の動作(eMail, Slackで通知など)一通り色々な動作をさせることができるようです。
Xcodeなどの画面でポチポチ押して設定していくだけでできるので簡単にできるかとは思いました。
Xcode > Product > Create Workflowから新しいワークフローを追加できます。
- 開始条件(特定のブランチでのみ開始 など)
- ビルドの環境(Xcodeいくつで行う など)
- アクション(行いたい動作 例えばアーカイブ化)
- 終了後アクション(通知など)
を設定できます。それらもそれぞれXcodeの画面で選択していくだけで設定できます。
その後、コードへのアクセスを承認します。例えば、Githubであれば、App Store Connectに一旦移動し、Xcode CloudがGithubアカウントへアクセスできるよう許可を与えます。
セキュリティ面ですが、ビルドの行われる環境は一時的に作り出されるものであって、ソースコードは保存されることはないとのこと。データは暗号化され、いつでも消せるようになっています。
Meet declarative device management
MDMプロトコルのアップデートの「Declarative Management」について解説しています。
※ MDM(Mobile Device Management) 学校・企業などで複数の端末の管理をするため、Appleが提供しているプロトコルです。アプリの配布、アプリの設定の配布、遠隔操作や端末の情報収集などが行えます。
Start it up - Mobile device management (MDM) for iOS
エンタープライズiOS研究所 - MDMとは何か 〜今さら聞けないMDMの基礎〜
今までのMDMではサーバー側から聞かない限りデバイスの状態などが分からないという設計でした。Declarative Managementでは、何か重要な変更があった時はデバイス自身が反応してアップデートを行ったり、サーバーに通知をするという、デバイス自身の自律的・積極的な処理が行われます。
Declarations
端末を管理する際の様々な事項を決定します。
Configurations
, Assets
, Activations
, Management
の四種があります。JSONで表されます。
Configurations
Assets
ユーザー情報・eメールアドレス・証明書など、端末がサーバに問い合わせてダウンロードしてくるものに関する設定を指します。
デバイスからMDMサーバへ直接落としにいくこともできますし、別のCDNサーバーにアクセスすることもできます。
Configurations
とAssets
は多対1の関係となっており、複数のConfigurations
が一つのAssets
を参照することがあります。
Assets
の定義の一例は以下のようになります(ユーザー情報)。
Activations
複数のConfigurations
の組み合わせをActivations
と呼びます。
Configurations
とActivations
の関係は多対多となっています。Activations
は複数のConfigurations
を包含することがありますし、他方Configurations
は複数のActivations
から参照されることがあります。
定義する際は、複数のConfigurations
のIDを参照してpayloadに設定します。
Management
会社情報・サーバ情報など、全体に関わる静的なデータを端末に送信するときに使います。
Status channel
デバイスの状態を監視するためにサーバが行う購読をStatus channel
と言います。購読した情報を最初は全部送りますが、その後は変更があった部分だけがデバイスからサーバーに通知されます。
購読した情報が最初にデバイスから送られてくる時のレスポンスの一例です。
何かアップデートがあった際は、以下のように変わった点だけがデバイスから送信されてきます。
Extensibility
拡張性のことです。
Declarative Managementは従前のMDMと影響を与えないので共存することができますし、一部だけ導入して少しずつ増やしていくということも可能です。
構成図
Declarative management を導入するときの図です。サーバがDeclarativeManagement
コマンドを送信することでONになっています。
その後設定の同期が開始されます。デバイスがcheck-inリクエストを送ったのち、サーバ側で設定したDeclarationがデバイスへダウンロードされ、定義した設定がデバイスに適用されていく事になります。
Meet in-app events on the App Store
アプリ内イベント(ゲームアプリのキャンペーン・映画のリリースなど)をApp Storeで設定できるようになりました。
アプリの該当ページにアクセスするとアプリ内イベントの情報が表示されるようになります。ユーザーが通知ボタンをタップすると、イベントの開始時に通知が送られるようになります。
アプリ内イベントはApp Store ConnectのFeatures > In-App Eventsから設定できます。
注意点としてはApp Storeでの公表日(Publish Date)・開始日(Start Date)・終了日(End Date)3つを決める必要がある点です。End Dateがすぎたイベントは終了し、アーカイブ化されます。イベント終了後から30日はリンクが閲覧できるようです。
イベントの目的を設定する欄があります。新規ユーザー向けか、既存ユーザー向けか、一度アプリから離れてしまったユーザー向けかという目的です。これを設定すると、App Storeが自動のアルゴリズムでユーザー一人一人に合わせたイベントの推薦を行う際に考慮されるようです。
イベントは、アプリと同様、公開前にAppleのレビューを受ける必要があります。
審査が通ったが未公開状態のイベントは最大10まで、公開中のイベントは最大5つまでとなっています。
App Analyticsのページで、イベントの効果測定データが見れます。どのくらいのユーザーがイベントページを見たか(impression)、どのくらいのユーザーがイベントページを開いたか(Open)、どのくらいのユーザーがアプリをダウンロードしたか(Download)、どのくらいのユーザーが通知ボタンを押したか(Notifications)が確認できます。
以上の操作は全てApp Store Connect APIでサポートされる予定だそうです(2021年 秋頃)。
Meet the Screen Time API
Screen Time APIはデバイス上でアプリを起動していた時間を計測したり、使用に制限を設けたり、使用状況を家族と連携したり、アプリ内の特定の機能の使用を制限したりといった機能を提供するAPIです。iOS15, iPadOS15より利用可能となります。
当APIは3つの部分より成ります。
-
Managed Settings Framework
- デバイス上でアプリ使用制限を設けたり、Webコンテンツのフィルタリングをしたり、自由にカスタマイズしたシールド画面を表示することで特定のアプリ・Webサイト使用を防いだりすることができます。
-
Family Controls Framework
- 本API使用の際に保護者に許諾を求めたり、計測データが家族外の誰か(Appleを含む)に漏れたりすることを防止するフレームワークです。
-
Device Activity Framework
- 設定したスケジュールの開始と終了時に何らかのコードを実行したり、アプリの使用程度が閾値を超えた場合に何らかの動作を実行したりします。
以下は使用の一例です。
アプリ使用時に、保護者の許可を得るよう促す画面を表示できます。
開始時間・終了時間を選んで、どのアプリを使って良いか・制限するかを選択できます。
Meet the UIKit button system
UIButtonのアップデートがあります。
UIButton.Configurationという構造体が追加されます。こちらでplain
, filled
, gray
, tilted
の4タイプが選べるようになります。
単に見た目だけではなく、Configuration
構造体経由でボタンの様々な設定変更ができるように成ります。例えば画像の配置(top, bottom, trailing, leading)が選べます。
また、状況によってボタンの見た目など様々な設定を動的に変えたいことがよくあると思います。これを、configurationUpdateHandler
経由で行うことができます。例えば以下では、ボタンのisHighlighted
プロパティが変化したら、それに伴ってボタンの画像を変えるようにしています。isHighlighted
プロパティが変化するたびに、自動的にconfigurationUpdateHandler
が呼ばれます。
ここでisHighlighted
はUIKitの定義した変数のため自動的に呼ばれますが、自分で定義した変数が変化したときも、configurationUpdateHandler
が呼ばれるようにできます。自分で定義した変数が変化した際、ボタンのsetNeedsUpdateConfiguration
メソッドを呼ぶようにしましょう。
また、ボタンの中にActivity Indicator(くるくる回るもの)を表示させることができるように成りました。単に、showsActivityIndicator
をtrueにするだけです。
文字列を二種(TitleとSubtitle)を表示できるようになりました。画像との配置の関係図は以下のようになっています。
トグルボタン(押された状態と押されていない状態など二種の状態の入れ替えを行えるボタン)が公式でサポートされるようになりました。今まで、こういったボタンを作る場合は普通にカスタムクラスなどを作っていたかと思いますが、それが必要なくなります。changesSelectionAsPrimaryAction
変数をtrueに設定することで、自動的にトグルボタン化します。isSelected
プロパティにより、トグルが選択された状態か否か決定できるようになります。
メニュボタン(ボタンを押すとメニューがポップアップないしプルダウンで出現する)も公式でサポートされるようになりました。↓こういったものです。
トグルボタンと同じくchangesSelectionAsPrimaryAction
変数をtrueにします。かつ、menu
変数にUIMenuクラスインスタンスを割り当て、showsMenuAsPrimaryAction
変数をtrueにすることで、メニュボタンになります。なお、showsMenuAsPrimaryAction
変数のみfalseにした場合は、トグルボタンのままですが、長押しでトグルの選択肢を選ぶメニュが出てくるような形のトグルボタンとなります。
Simplify sign in for your tvOS apps
tvOSアプリで、サインインをスムーズに行うことができるサインインビューの紹介をしています。
毎回パスワードを入力させるようなデザインは好ましくないため、iPhoneと連携してiPhoneの顔認証などでログインし、その結果をtvOSに伝えスムーズにログインするようなフローが紹介されています。iPhone側に通知が届き、それをタップするとサインイン用の認証ビューが開きますので、認証をします。
技術としてはAssociated Domainsを用いる必要があります。
tvOSの方のアプリのバンドルIDをapple-app-site-associationファイルに記載します。
webcredentials:
という接頭辞をつけて、Xcodeの方でドメインを登録します。その他の手順は通常のAssociated Domainsの手順と同じようです。
コードの方ではASAuthorizationController
を用います。
Sign in with Appleを利用する場合はASAuthorizationAppleIDProviderも利用します。
ASAuthorizationControllerDelegate
も実装します。
追加する場合はコード上でcustomAuthorizationMethodを利用します。
Take your iPad apps to the next level
UIWindowSceneアップデート
iPadで同アプリを同時に複数開けるUIWindowSceneが以前導入されました。こちらのアップデートになります。
-
UIWindowScene.ActivationRequestOption
新しいシーンを生成する際、どのシーンから生成されたのかを明示する場合に利用できます。
automatic
とprominent
とstandard
の三種あります。
prominent
は以下のように単独で目立つような形での画面表示となり、画面の他の部分が薄暗くなります。
その性質上、prominent設定で表示したシーンは、それ単独で役割を遂行できるような画面であることが求められます。また、Closeボタンなどを必ずつけることが求められています。また、特定の役割のみを遂行するものであることが推奨されています。
automatic
はどのようにシーンが開かれたかによって自動でスタイルを決めるそうです。
アプリを新しいシーンで開くためのアクションが追加されています。シーンはiPadのみのサポートなので、iPhoneではできませんが、iPhoneだけ代わりにモーダル表示で表示するというように、動作を分けることも可能です。
UICollectionView、あるいは他のViewをタップしたときに、新たなシーンを開くようにすることも可能です。
その他、シーンのPreviewを表示する、テキストの入力状況を新しいシーンに引き継ぐ、シーンの状態を保存するなどが紹介されています。
キーボードショートカット
Macでは見慣れた画面上のメニューバーがiPadでも使えるようになりました。Macと違って少しスペースに余裕がないことからか、現在選択可能なコマンドのみが表示される用になっています。UIMenuBuilderクラスを使ってメニューをカスタマイズできます。
ショートカットコマンドは被ってしまうこともあります。被ってしまう場合は、メソッド名を変えるのが一番良いとのことでした。info.plistに記載のコマンド名を変えることでも、一応回避できます。
コマンドが衝突している場合、ログに以下のようなエラーが出ます。
ショートカットで入力するキーを自動でローカライズする機能も追加されました。例えば、各国語のキーボードに対応する場合は、自前で処理を書かずApple公式の機能を利用してほしいとのことです。
ポインター機能のアップデート
MacOSでドラッグをし複数の要素を一気に選択するポインター機能をよく使うと思いますが、iPadにもこれが導入されます。
ポインター画面上に表示されるポインターに関して、外見をカスタマイズすることもできますし、ポインターの周囲にアクセサリを追加することもできます。例えば、どの方向にドラッグできるかを表す左右矢印アイコンなどです。
ポインタのドラッグに関して、特定の方向(X軸・Y軸)にのみドラッグできるように設定することもできます。例えば、画像の拡大縮小のためドラッグする時などに使えそうです。
Tap into virtual and physical game controllers
バーチャルゲームコントローラ(デバイスの画面上に表示されるコントローラ)、および実際のコントローラをiOSデバイスで使用する手順を解説しています。
復習
ゲームにおいて、コントローラ、キーボード、マウス、トラックパッドなど、入力方法を気にすることなく、抽象的にコード上で処理することができるようになっています。
それら入力デバイスはGCDeviceクラスで表されます。
- 今ボタンが押されているかどうかの検査(ポーリング)
- 何らかのボタンが押された際の通知
- 各デバイスの接続・解除の通知
コントローラ対応している場合はApp Storeでその旨のバッチがつくほか、コントローラ対応ゲームのセクションにも表示されるようになります。そのための対応は、XcodeのCapabilities > Game Controllers にチェックを入れるだけです。
設定ページにて、アプリごとにユーザーがコントローラのキーコンフィグを行えます。
ゲームのスクリーンショット・動画キャプチャも可能です。
キー割り当てのベストプラクティスですが、ゲーム中でインベントリなどを開く場合は、XBoxコントローラではYボタン、プレイステーションコントローラでは△ボタンにしましょう。あるいは、方向キー上を割り当てるのも良いです。
ゲーム中にボタンのマークを表示したい場合があると思います(「Aボタンを押す」 など)。ただキーコンフィグで割り当てボタンを変更している場合もあるわけです。その場合は、sfSymbolsNameを使うことで正しいキーが取得できます。
バーチャルコントローラ
↓こういったデバイススクリーン上に表示される仮想のコントローラを指します。
ボタンレイアウトは左右で変えることができます。レイアウトは設定によって決定され、動的に変えることはできません。左右の片側につき合計4つのボタン・スティック・タッチパッド・十字キーをおくことができます。
ボタンをABXYなどではなくオリジナルの画像に置き換えて表示することも可能です。
バーチャルコントローラはGCVirtualControllerクラスにより表されます。connect関数により、バーチャルコントローラを画面上に表示します。設定はGCVirtualController.Configurationにより変更できます。最終的にGCControllerクラスインスタンスが得られます。
実物のコントローラー
- Adaptive Triggerへの対応
一部のコントローラでは、ゲーム上の状況に合わせてトリガーが指に跳ね返る力の強さを変えられるアダプティブトリガー機能があります。それへの対応方法が解説されています。GCDualSenseGamePadクラスを利用します。
The practice of inclusive design
包括的デザイン(あらゆる属性の人を排除しないデザインのこと)のベストプラクティス6つについて開設されています。
幅広い表現を行う
アプリのスクリーンショットの一例です。
上の写真は排他的な表現が含まれているので、下はそれを修正しなるべく多くの人に当てはまるような表現にしたものになります。
-
カヤックを漕ぐ人の写真
- カヤックを漕ぐような余暇をするのは社会の中で特定の属性の人だけで、多くの人が日常的にするようなものとは言えない。
- 複数の人種が作業場で働いている人の写真に修正。
-
TODOアプリの文言
- 上の写真では、人名や誕生日イベント・ピアノの練習などの表記がアメリカ合衆国のステレオタイプ的な表現が多いです。それを緩和するための一例として、別の文化圏っぽい人命や行事名などをTODOアプリの内容として記載したのが下の写真となります。
-
料理の内容がハンバーガー・ピザ・パンケーキなど
- 料理の内容がアメリカ合衆国の典型的な食事ばかりになっています。もう少し色々な文化圏の食事の写真を含むように修正したのが下の写真になります。
ステレオタイプを避ける
ステレオタイプを避けるとは、過度に単純化しすぎて現実世界の多様性に上手く対応しきれていないようなデザインを避けるということです。
例えば性別についてですが、たいてい男性・女性の二種のみとされています。現実にはトランスジェンダーや、どちらの性別にも当てはまらない人など多数の特徴がスペクトラム状に分布しているものであって、本来はふたつに分けられるものではありません。
英語の話ですがhe/she, guysなど性別を特定する表現ではなくthey, everyoneを使うようにするなど。
また、人の顔画像のプレースホルダで人のシルエットを表示していますが、男性とわかるようなシルエットではなく、丸い頭の性別を感じさせないシルエットにするなど。
Appleが提供するSFSymbolsでは、人の表現が特定の性別に偏らないようなアイコンが多く提供されています。
また人が特定の能力を持っていることを前提とした表現をしないようにしましょう。 例えばある種の精神障害を持っている方もいるのでinsane と言う言葉を用いるのは、たとえ気が狂うと言う意味そのものでないとしてもあまり良くありません。代わりに ridiculously と言う言葉を用いる例が下になります。
また家族のメンバーが母親父親子供から構成されると言う偏見も良くありません。そういった家族構成でない方に違和感を持たせてしまう可能性があります。 母親父親等ではなく単純に家族のメンバーと言う表現をしまた何人でも家族のメンバーを登録できるようにしたアプリの一例が以下になります。
その他言語や文化は日々変化し続けています。そういった変化に敏感になり表現も変化させるようにしましょう。
アクセシビリティをアプリに適用する
アクセシビリティーとは障害を持った方でもアプリを使いやすくするための考え方です。例えば目が見えにくい事に対してはアップルの技術であるダイナミックタイプを活用して文字の大小を調整できるようにしましょう。 その一例が以下になります。
また文字だけではなくその他のシンボルやアイコンに関しても目が悪い方に対しては大きく表示するなどするとさらに親切になります。
さらにアプリそのものを声だけで操作する技術であるVoiceOverも活用してください。 アプリに表示されている様々なボタンの役割が音で再生されます。そのため理解できるような説明文をつけるようにしてください。
またデフォルトですとアプリの一番左上にあるボタンなどの要素からVoiceOverで読み上げられます。しかしアプリの最も基本的な機能など重要な機能から読み上げられるようにした方が良いでしょう。例えば下の例では投稿をすると言う基本的な機能のボタンが 一番下にあるのですが、設定をすることでこちらのボタンがVoiceOverで一番最初に読み上げられるようにしています。
文化を考慮したローカライズ
単純な翻訳はローカライズにおいて重要ではありますが、単にそれだけでは足りないこともあります。アプリ内でよく使う表現として電話番号、数字、 通貨などの表現は文化によっても異なります。 その他の表現に関しても特定の文化圏の人にしか理解できないような表現は控えましょう。
例えば以下ではAtoZと言う言葉を用いていますがこれは英語を知っている人にしか理解できないので、from beginning to end 言う表現に書き換えています。
また例え話や寓話ことわざなど直接的でない表現は他の文化圏の人には理解しにくいことがあります。複数の文化圏の人に使われることを考えれば直接的な表現を用いるようにしましょう。
また文化によりタブーが違うことがあります。 例えばインドでは牛が神聖な動物とみなされているので牛を食べる事はあり得ません。また多くの人がベジタリアンとなっています。 そのため例えば料理のアプリなどで牛肉を使ったレシピを紹介してしまえばインドの人からは顰蹙を買うことになるでしょう。
また皮肉的な表現もなるべく控えましょう。たとえ侮辱までいかない表現だったとしても不愉快に思う人がいる可能性があります。
色を注意深く使う
色は特定の感情や概念に結びついていることがあります。しかしそれは文化圏によっても異なります。例えば英語圏では赤色は主に警告や危険などの意味を表す場合が多いです。しかし中国では赤は非常に縁起が良い色とされています。そのため下記の株価のアプリでは 英語圏向けには株価が下降した場合赤色を用いています。しかし反対に中国向けには株価が上昇したときに赤色を使用します。
また色の識別に関して全人口の5%ほどが何らかの障害を持っていると考えられています。そのため複数の色の組み合わせなど注意する必要があります。 例えば以下では丸いアイコンを色だけで区別していますがこれだと区別できない方もいるので丸のアイコンと旗のアイコンと言うようにアイコンの形を変えて工夫しています。
また複数の色の組み合わせに関してコントラストが4.5対1より大きいことが推奨されます。
ユーザーの自己表現を幅広くする
ユーザが自分自身のことを表現する際に幅広いやり方でその人に合った表現ができるようにしましょう。例えば以下ではアプリで名前を入力する際にファーストネーム、ラストネームと言う形で強制するのではなく、フルネームを自由に入力できる欄を1つ設けています。それに加えてその人がどのように呼んで欲しいかを入力する欄ももう一つ設けています。
性別に関しても男性女性の2つだけではなく他の性別も指定できるようにすると良いでしょう。
しかし男性女性その他と言う3つだけでは必ずしも完全にいろいろな形の性別を表現できるとは限りません。
マッチングアプリのバンブルでは性別に関して非常に多くの選択ができるようになっており、この点を非常に考慮していると言えるアプリです。
Bumble
またSay No! More と言う ゲームアプリではキャラクターの外見や喋る言葉のオプションが非常に充実しておりこの点に関して見本となるアプリといえます。
Say No! More
The process of inclusive design
開発の各段階においてより多くの人に 受け入れられるようなデザインをするためにはどうすればいいかを説明しています。
- 人の属性の様々な軸
人種民族宗教性別などの様々な属性の軸を下で提示しています。この様々な軸を用いてより包括的なデザインのアプリとするためにはどうすれば良いかを考えていくと良いです。 なお下記のclassとは社会階級Handednesssと言うのは右利きか左利きか、セクシャルオリエンテーションとは性的嗜好と言うことを表します。 またConnectivity、Modern techとあるのはインターネットやハイテク機器にどの程度アクセスできるかと言う属性を表しています。
-
包括的デザインをする上での様々な誤解
-
「包括的なデザインをするのは難しい」
- → 包括的デザインというのは終わりなく改善を繰り返していくって言うことであって短期に一気に実現するようなものではありません。 まずは小さいところから始めるべきといえます。
-
「包括的デザインは創造性を損なう」
- → むしろ包括的デザインを考えていく上で新しい創造性が生まれる刺激になります。 人が持っている複数の属性を考えてより多くの人に受け入れられることを考えていく上で新しいデザインが生まれていくと考えた方が良いでしょう。
-
「 開発チームに様々な属性の人が含まれれば製品も包括的デザインとなる」
- →正しくは開発チームの様々な属性の人がきちんと意見を発信できれば、製品も包括的なデザインとなるかもしれないと言うことです。例えば障害者の方ですとか異なる文化圏から来た方などがチームにいたとしても、必ずしも製品が包括的なデザインとなるわけではありません。そういった人が チームのメンバーにいても意思決定の過程にきちんと組み込まれていないというのがよくあります。
-
「 包括的デザインは開発の過程の1番最後でなされる」
- むしろ包括的デザインは開発の過程の1番最初から考え始められるべきです。
-
-
開発の各過程で考えるべきこと
-
アイディア出しの段階
- なぜこの製品を作っているのか、誰のために作っているのか、と言うことを考える
- こうしようと言うアイディアが出た場合同僚やあるいは外部の専門家などに尋ねてその妥当性を図る
-
設計の段階
- 障害を持っている方や様々な性的嗜好を持っている方など、極端な事例を考える。 世界の約15%の人は何らかの障害を持っていると考えられているので、障害について考慮すること非常に大切です
- そのアプリを使うことによる感情的、社会的、身体的な影響を考える
- アプリが使われる地域場所や使われる文脈を考える
-
開発の段階
- アプリの中での表現が多数の人に受け入れ可能なものになるようにしましょう。 障害など様々な属性を持つ人の意見が取り入れられているとよりそのようなアプリに近づきます。特に障害を持っていてかつ、 トランスジェンダーであるなど複数の属性においてマイノリティーに属するような人は特にユニークな物の見方があったり、ユニークな経験をしていることがあります。そのような人の 意見を聞くことができればより深みのある表現につながります。
- アクセシビリティーやローカライズの技術を積極的に活用しましょう。例えばVoiceOver技術を 使用することで、iPhoneのホーム画面の様々なアイコンを音で読み上げてくれるので、目に障害のある方でも使いやすくなります。
-
またVoiceOver技術では 写真に説明文を加えることで、目の見えない方にも内容がわかるようVoiceOverで説明文を読み上げると言うことができます。さらにAI技術の活用で、人手で書いた説明文ではなく、AIが自動で生成した説明文をも利用できるようになりました。
-
テスト段階
- なるべく様々な属性を持った人を含むテストチームで、テストを行う
- 拡大鏡やVoiceOver機能 などなど様々な補助機能がありますが、それらをテストの時にも用いる
- フィードバックを評価し、優先順位をつける
-
リリース段階
- 必要であれば一定の機能を削るなど、決断力の必要な決断も時に行う
- 包括的表現をするにおいてできなかったことがある場合、なぜできなかったのか、今できないとすればいつできるようになるかを考えておく
アップル公式の写真アプリのメモリー機能と言う機能では、上記のような考え方のもと包括的なデザインを実現するためにいくつかの修正を行いました。例えばフィードバックの1つとして、「娘の空手の練習の様子を メモリーにまとめたい」と言うフィードバックがありました。これを受けてアップルのチームは一体どのようなテーマで写真をまとめてメモリーとして表示するかを考えました。 その際チームが所在する地域またはチームの人の意見や見方だけではなく、様々な外国の文化や、様々な国の人がどのような趣味嗜好を持っているかと言う点を外部の専門家にも聞き、 ブレインストーミングを行ったところです。これにより様々な国の人々の趣味であるとか、様々な国の行事にフォーカスしたメモリを自動的に生成できるよう写真アプリをアップデートしたとのことです。
また「元カレの写真はメモリ見たくない」と言うようなフィードバックもありました。これに基づき、 メモリや写真を選択して、この人物の写真はメモリで表示しないと言うように選択できる機能を追加しました。 このようにフィードバックを受けて、絶え間なく様々な人に受け入れられるアプリを目指していくことが重要です。
Transition media gaplessly with HLS
動画内の複数シーンを入れ替えたり、それらをシームレスにつなげて再生する手法について解説しています。