プロパティについてのまとめ ・プロパティ　: 型に紐づいた値のこと ・プロパティの分類 ①var,let ②ストアドプロパティ,コンピューテッドプロパティ ③インスタンスプロパティ,スタティックプロパティ,クラスプロパティ ①var,let var :　再代入可 let :　再代入不可 ②ストアドプロパティ,コンピューテッドプロパティ ・ストアドプロパティ（値を保持するプロパティ。プロパティオブザーバをもつ。） struct Bird { var status = "卵" { willSet { print("私は\(status)です。次は\(newValue)になります。") } didSet { print("私は\(status)になりました。前は\(oldValue)です。") } } func greet() { print("私は\(status)です。") } } var bird = Bird() bird.greet() //私は卵です。 bird.status = "鳥" bird.greet()　// 私は卵です。次は鳥になります。私は鳥になりました。前は卵です。私は鳥です。 ・コンピューテッドプロパティ（値を保持せずに算出するプロパティ） struct Human { var gender = "男" var name : String { get { if gender == "男" { return "太郎" } else { return "花子" } } set { if newValue == "太郎" { gender = "男" } else { gender = "女" } } } func person() { print("私は\(name)です。性別は\(gender)です。") } } var human = Human() human.person()　// 私は太郎です。性別は男です。 human.gender = "女" human.person() //　私は花子です。性別は女です。 ③インスタンスプロパティ,スタティックプロパティ,クラスプロパティ ①インスタンスプロパティ（型のインスタンスに紐づくプロパティ） struct Human { var gender = "男" } var human = Human() print(human.name)　//山田太郎 ②スタティックプロパティ・クラスプロパティ（型そのものに紐づく） ・スタティックプロパティについて struct Animal1 { //スタティックプロパティはストアドプロパティ・コンピューテッドプロパティとして利用できる。オーバーライドはできない。 static var weight : Int { return 40 } static var height: Int = 180 } print(Animal1.weight) // 40 print(Animal1.height) // 180 ・クラスプロパティについて //クラスプロパティはコンピューテッドプロパティとして利用しなければならない。オーバーライド可能。 class Animal2 { class var name : String { return "Dog" } } class Animal3: Animal2 { override class var name: String { return "Cat" } } print(Animal2.name) //Dog print(Animal3.name) //Cat

要約 DeviceCheckを使ってリセマラを防ぎます 概要 リセマラ（リセットマラソン）を防ぐために、DeviceCheckを使って端末チェックを行います。 ここでいうリセマラとは、アプリをアンインストール/インストールを繰り返して、初回限定の利益を何度も受ける行為を指します。 端末チェックの結果、「この端末ではまだ初回限定の利益を受けていない」と判断できた場合、初回限定の特典を与えます。 DeviceCheckを使った端末チェックはiOSアプリ単体で完結するわけではなく、さまざまな手順が必要になります。 また、仕組み上、中古端末や譲渡を受けた端末では初回限定の判断はできないかと思われます。 アプリの流れ iOSアプリがDeviceCheckを利用して、トークンを発行する iOSアプリは、サーバーに対してトークンを送信する サーバーは、JWTを生成して、トークンとともにApple APIへリクエストを送る サーバーは、Apple APIの結果を受け取り、iOSアプリへ返す サーバーのレスポンスを元に、初回限定の利益を与える/与えない 端末チェックの手順 p8編 iOS Developer centerで、Keysを作成することができる権限のアカウントが必要です。 iOS Developer centerでDeviceCheck用のP8ファイルを作成する必要があります。 下記は手順の一例です。iOS Developer centerに変更が行われている場合は適宜読み替えてください。 Certificates, Identifiers & Profiles の Keysを選択 Create Keyを押下 Register a New Keyで、Key Nameを任意、DeviceCheckをチェック Downloadで、p8ファイルをダウンロードする。これはサーバーサイドで利用します。 サーバ編 先ほどダウンロードしたp8ファイルが必要です。 サーバーサイドでは、p8ファイル、iOS Developer centerで生成したKeyのKey ID、iOS Developer centerのチームIDが必要になり、組み合わせてJWTを生成し、iOSアプリからデバイストークン受信時、Authorizationヘッダーに Bearer <GeneratedJWT> を付与して、bodyにPayloadを付与してAppleのAPIへリクエストを行います。 APIには query_two_bits と update_two_bits があり、まず query_two_bits を確認して、200 Bit State Not Foundであれば初回限定とみなせます。 必要であればこの時点でupdate_two_bitsで初回特典を付与済みとすればよいでしょう。 AppleのDevice check用APIについての公式はこちらです。 JWTを生成するライブラリは各種環境で選定してください。 以下はJWT生成時のHEADERとPAYLOADの例です。 HEADER例 { "alg": "ES256", "kid": "(iOS Developer centerで生成したKeyのKey ID)" } PAYLOAD例 { "iss": "(iOS Developer centerのチームID)", "iat": 1573712797, "exp": 1573716397 } bodyの例 { "device_token": "Base 64エンコードされた、iOSから送られてきたデバイストークン", "transaction_id": "C94E26BD-714B-4D3F-8733-E86A790C0F8D", "timestamp": 1573707063000 } iOSアプリ編 DeviceCheckは実機じゃないと動作しません。プロビジョニングもDeviceCheckのp8ファイルを作ったチームIDと等しい必要があります。 iOSアプリでは DCDevice.current.generateToken を実行し、生成したトークンをサーバーへ送信し、その結果を受け取って初回限定の特典を与えることになります。 import DeviceCheck DCDevice.current.generateToken { (deviceToken, error) in // TODO: サーバーにdeviceTokenを送信して、レスポンスを受け取って処理をする } iOS単体での実機デバッグ DeviceCheckは、サーバーと連携して使うことが前提のものですが、iOSアプリ単体でテストとして使いたい場合、CupertinoJWT を使ってApple APIとの通信が可能です。 下記はquery_two_bitsの例です。 あくまでテストとしてお使いください。 import DeviceCheck import CupertinoJWT DCDevice.current.generateToken { (deviceToken, error) in //p8ファイルの中身 let p8 = """ -----BEGIN PRIVATE KEY----- ... -----END PRIVATE KEY----- """ let keyID = "iOS Developer centerで生成したKeyのKey ID" let teamID = "iOS Developer centerのチームID" let jwt = JWT(keyID: keyID, teamID: teamID, issueDate: Date(), expireDuration: 60 * 60) do { let generatedJWT = try jwt.sign(with: p8) let url = URL(string: "https://api.development.devicecheck.apple.com/v1/query_two_bits")! var request = URLRequest(url: url) request.httpMethod = "POST" let deviceTokenString = deviceToken!.base64EncodedString(options: Data.Base64EncodingOptions.init()) let timestamp:Int = Int(Date().timeIntervalSince1970) let transaction = UUID().uuidString let requestBody = """ { "device_token" : "\(deviceTokenString)", "transaction_id" : "\(transaction)", "timestamp" : \(timestamp)000 } """ let data = requestBody.data(using: .utf8) request.addValue("Bearer \(generatedJWT)", forHTTPHeaderField: "Authorization") request.httpBody = data let task = URLSession.shared.dataTask(with: request) { (data, response, error) in // NOTE:Apple Device Check APIの結果を判断して初回限定の付与などを判定 } task.resume() } catch { // Handle error } }

Android　エミュレータの command + M　に該当するショートカット 数ヶ月毎にWebとMobileいったりきたりして、いつも忘れてしまう ググってもすぐでてこず、時間浪費・・・　　検索能力が低いだけか？ デバッグメニュー表示のショートカット command + control + Z Toggle Inspectorだけならコレ cmd＋ i

iOS アプリの申請を行ったら以前にもまして厳しかった １．位置情報取得許可とメディアへのアクセス許可の文言が気に入らないと言われた 　・ちゃんと理由を述べよと 　　　なんでこの機能を使用しないといけないのか　っていわれてもね 　　　　「XXXで音楽を演奏する楽曲を選択する為、むにゃむにゃ」 　　　でOKになった 　　　しかし。。。。。言語を英語も使用できる事にしたため切り替えにゃあかんといわれた 　　　ので、[InfoPlist.strings]の日本語、英語を作成しOKとなった 2.プロモビデオが小さい 　・実機でのレコード及び撮影を求められる為、画面レコーダで録画し⇒Mac取り込み iMove 　　縦長を横長のアスペクト比で編集した為、画面の両端に黒が、、、、、 　　結果解像度を変更しアップしたら小さいと。。 　　そもそもいiMoveで縦長扱えるのか⇒無理であることが判明 　　★ところが90°回転すれば良いことがわかり90°回転 　　　あれ、字幕が回転してないそれはそうか 　　　なので、テロップ画像をブルースクリーンで作りオーバーレイさせて対応（もちろんこちらも90°回転） 3.ここにきてICONにAppleのMaoの画像が使用されている？ 　　・この画像前のアプリでも使用していたのに、しかもだいぶ前のMapアプリ画像 　　　（しょうがないので、しょぼい自作画像を作成） 4.ようやく、通過 　レスポンスは早い、以前に比べると雲泥の差⇒ここは評価したい ってなわけで 　アプリ [LocationMusic2](LocationMusicは以前objective-Cでリリースしたが更新がなく削除されてしまった　⇒のあとだれか使用している？らしいので[2]をつけてしまいました） 随時アップデート予定　 　　

やりたいこと アプリ名とかのローカライズの設定を毎回xcodeで設定が面倒なのでunity内で完結したい アプリ名や、ios固有のATT表示の赤枠のメッセージなどが対象 ATTの中のテキスト アプリ名 検証環境 unity 2019.3.0f6 / Xcode 12.4 手順 1,プロジェクトにローカライズのデータを設置 何処に設置してもよいが下記2点は守ること 　・ファイル名はInfoList.strings 　（末尾のsを忘れないこと） 　・格納するフォルダは対応言語に合わせること　日本語ならja (jpと間違えないこと) 　　　言語コードはコチラ参照https://qiita.com/hirobe/items/cb906cca486675d02a87 Base.lproj は用意されてない言語が端末で選択されているときに参照されるデフォルト用 (デフォルト用のつもりでしたが参照されて無い感じがしたのでbaseは見なかったことにしてください) 2, InfoList.stringsの編集 例としてfr.lproj/InfoList.stringsの中を記載 CFBundleDisplayName = "フランス";　 // アプリ名 ATTのメッセージを変えるなら NSUserTrackingUsageDescriptionを指定 このあたりの設定のkey 的なものの一覧がどこかにあるのだろうけどパッと見つからなかったので割愛 3、PostProcessBuildで1で作成したデータを紐づける PostProcessBuildとは、という説明は割愛 public class PostProcessBuild : IPostprocessBuildWithReport { const string IOSPbxProjectPath = "/Unity-iPhone.xcodeproj/project.pbxproj"; int IOrderedCallback.callbackOrder => default; void IPostprocessBuildWithReport.OnPostprocessBuild(BuildReport report) { var summary = report.summary; if (summary.platformGroup != BuildTargetGroup.iOS) { return; } string pbxPath = summary.outputPath + IOSPbxProjectPath; var project = new PBXProject(); project.ReadFromFile(pbxPath); string targetGuid = project.GetUnityMainTargetGuid(); // 指定パス以下にあるローカライズデータを紐づける string[] languageArray = new string[] { "Base", "ja", "fr" }; // 紐づけたい言語を記載 foreach (string lang in languageArray) { string dirPath = Application.dataPath + $"/Editor/Localisations/{lang}.lproj"; // project内に設置したパスを指定 var lGuid = project.AddFolderReference(dirPath, $"{lang}.lproj"); project.AddFileToBuild(targetGuid, lGuid); } project.WriteToFile(pbxPath); } } 間違えやすいこと（やってて間違えてたこと) // 似たような関数があるので注意　project.GetUnityFrameworkTargetGuidではない string targetGuid = project.GetUnityMainTargetGuid(); ビルドして完了 いつものようにビルドをして書き出されたxcodeプロジェクトを開くと 指定したフォルダを見つけることができるはず あとは端末の言語を切り替えながら動作チェックしてみてください まとめ androidはコチラでできるみたい https://qiita.com/ptkyoku/items/3f25872ae0f356966c88 デフォルトの設定は後ほど探しておきます その他まちがってたらおしえてください

Xcodeで開発する際に知っておくと便利かつ「こんな機能あったんだ！」と、思うようなショートカットもまとめました。 使いこなしていければ、「へー、そんな機能あったんですか！」等言われたり、開発効率も上がりオススメです。 ナビゲータエリア ショートカット 機能 cmd + 0 ナビゲーターエリア表示/非表示 cmd + 1 ナビゲーターエリアのプロジェクト表示 cmd + 2 ナビゲーターエリアのリポジトリ表示 cmd + 3 ナビゲーターエリアのシンボル表示 cmd + 4 ナビゲーターエリアの検索表示 cmd + 5 ナビゲーターエリアの問題ナビゲータの表示 cmd + 6 ナビゲーターエリアのデバックの表示 cmd + 7 ナビゲーターエリアのデバッグナビゲータの表示 cmd + 8 ナビゲーターエリアのブレークポイントの表示 cmd + 9 ナビゲーターエリアのレポートナビゲータの表示 option + cmd + N ナビゲーターエリアの新規グループ作成 エディターエリア ショートカット 機能 cmd + L Line Numberの表示 cmd + Shift + Y console表示/非表示 cmd + Shift + L UIパーツ選択画面 cmd + Shift + [ or ] ミニタブの移動 cmd + control + ← or → 前に開いていたファイルに移動する cmd + ¥ ブレークポイントを貼る cmd + option + [ or ] ラインを１行上or下に移動する control + I フォーマット整形 shift + option + ドラッグ 部分的に複数行選択 shift + control + クリック 部分的に複数選択 control + command + クリック Jump to Definition shift + cmd + 1 プロジェクト選択画面を開く shift + cmd + 2 デバイス,simulatorsウィンドウの表示 shift + cmd + 8 画面上にTouch Barの表示 shift + cmd + 0 documentationの表示 shift + cmd + (-) コード画面縮小 shift + cmd + (+) コード画面拡大 control + option + cmd + return 選択したstoryboardのアシスタントエディタを開く Simulator ショートカット 機能 cmd + Shift + A simulator起動時ライト/ダーク切り替え

InstrumentsのMetal System TraceのMetalを使ったアプリの処理時間を詳細に分析することができます。 この記事ではそのやり方を説明します。 今回計測するアプリ GitHubにTokyYoshida/MetalExamplesというMetalのサンプルコードを集めたリポジトリを作りました。今回はこの中のParticleというサンプルを使用します。 パーティクルが上から下に流れるだけの処理です。 なお、このアプリはステータスバーにFPSが表示されているので、いまどのぐらいのFPSがでているのかすぐに確認できるようになっています。 (実行イメージ) 実はパーティクルはハートマークでしかも回転しているのですが、小さすぎて分かりません? 計測の手順 それでは計測してみます。 1. XcodeからMetal System Traceを起動する Xcode > Open Developer Tool > InstrumentsでInstrumentsを起動し、さらにMetal System Traceを選択します。 2. パーティクルの数を決めてアプリを実行する パーティクルの数を決めてアプリを実行します。 パーティクルはこの部分のinstanceCountに指定する値で決まります。 まずは100万を指定してみましょう。私のiPhone 11だと45FPSが出ていました。 ParticleMetalView.swift renderEncoder.drawPrimitives(type: .triangleStrip, vertexStart: 0, vertexCount: 4, instanceCount: 100000) ビルドして、アプリを実行します。 3. Metal System Traceで計測を開始する アプリを実行してパーティクルを表示した状態でMetal System Traceに戻り、左上のボタンを押して計測を開始します。 4. 計測結果をみる 適当なところで■ボタンを押すと計測が止まります。 結果を見てみましょう。 ＜図１＞ アプリケーション（CPU)の処理、GPUの処理、ディスプレイのインスタンスの処理間隔が表示されます。今回なぜかvsyncが表示されなかったので、手書きで入れてみました。 vsyncは16.67ms間隔になっているので、60FPSを出すためにはこの範囲内でCPUとGPUの処理を終わらせている必要があります。 下のペインにはBuilt-in Displayの1つ1つの処理がリスト化されています。みると16.67msで終わっているものもあれば、33msかかっているものもあります。このように処理時間がかかるとフレームがスキップされて16.67のn倍の時間がかかってしまいます。 5. 処理の内訳を確認する 原因を分析するためには、遅くなっている処理の内訳を確認していきます。 上の図１をみるとCPUの処理は間に合っていますが、GPUの処理が大幅に遅くなっています。 ということで、GPUの処理の内訳を見ていきます。 使用しているiPhoneのチップの名前(この記事の場合はA13)の▶をクリックすると処理の内訳をみることができます。 処理は、フレームごとに色分けされていて次の順番で処理していることがわかります。 MetalExamples　・・・ CPUの処理 => Driver Processing ・・・ GPUドライバの処理 => Vertex ・・・　頂点の変換や頂点シェーダーの実行 => Fragment　・・・　ラスタライズ、フラグメント シェーダーの実行 => Direct to Display ・・・　描画 図中にコメントを書きましたが、Direct to Displayより前の処理がvsyncに間に合わないと、現在の画面を表示し続けることになるためFPSのレートが落ちます。緑色で示されたフレームの場合、特にVertexとFragmentの処理に時間がかかりすぎており、描画がvsyncに間に合っていないことがわかります。 6. パーティクルの数を減らして処理を観測する パーティクルの数を10万にしてさきほどのグラフを出してみましょう。 この場合、私のiPhoneでも60FPSが出ていました。 すべての処理がvsyncに収まっていることがわかります。 最後に iOSを使ったARやML、音声処理などの作品やサンプル、技術情報を発信しています。 作品ができたらTwitterで発信していきますのでフォローをお願いします? Twitterは作品や記事のリンクを貼っています。 https://twitter.com/jugemjugemjugem Qiitaは、iOS開発、とくにARや機械学習、グラフィックス処理、音声処理について発信しています。 https://qiita.com/TokyoYoshida Noteでは、連載記事を書いています。 https://note.com/tokyoyoshida Zennは機械学習が多めです。 https://zenn.dev/tokyoyoshida

[WWDC 2021] Platforms State of the Union のメモを残しておきますので、皆様の参考になれば幸いです。 Platforms State of the Union (ASL) - WWDC 2021 - Videos - Apple Developer 夏ぐらいまで日本語訳はないかと思っていたが、これには日本語訳があったので助かった。 Xcode Cloud 開発の全ての工程をXcodeに統合 CIと配信サービスがXcode自体に組み込まれ、クラウドでホストされる。 Appleのクラウドインフラストラクチャを利用して、ビルドやテストさらに配信用のコード署名を省きます。 TestFlightやAppStoreConnectなどのAppleのサービスやあらゆる主要なGitベースのソースコントロールプロバイダと連携。 REST API を備え、開発プロセスの他の段階とも連携する。 そして高度なセキュリティを備え皆さんとプロジェクトを守ります。 Xcode Cloudがビルドを終えると、Xcodeに結果が表示される。 Xcode Cloud で開発を始めるのに必要なステップは４つだけ 製品の選択 ワークフローの確認 ソースコードへのアクセス許可 AppStoreConnectとの連携 SwiftUIサンプルアプリのFrutaでデモ セットアップ Xcode Cloud は自動的にプロジェクトの製品とプラットフォームを検知 Nextを選択したら、提案されたワークフローを検討 デフォルトのアクションは変更の全てを構築（ビルド？）する 最後にCompleteをクリックして、クラウド上で初めてのビルドを始める ビルドが終わったら、ReportNavigatorで結果を見ることができる このようにCIとアプリケーションの配信を1分でセットアップでき、全て Xcode の中で完結します。 ビルド結果の確認 Report Navigator の中の Cloud タブの下で、各ワークフローで進行中のビルドがブランチか PulRequest でグループ化されます。 個々のビルドを選択するとその概要が表示される。 どのXcodeとMacOSのバージョンが使われたかも確認可能。 ソースの確認やリビルドの実行も可能。 ワークフローのカスタマイズ iOSのテストを全ての新たな PullRequest で実行するワークフローをセットアップするデモ。 XcodeCloudのプロダクトメニューに戻り、Manage WorkFlows を選択 Plus をクリックして、新たなものを追加 ワークフローに”PullRequest"と名前をつける メインブランチを対象とするすべてのPullRequestで実行されるように、開始条件を編集 テストアクションを追加し、プロジェクトから既存のiOSテストプランを選択 XcodeCloudが使うシミュレータを提案してくれるので、クリック二つだけでワークフロー用にiPhone, iPadの組み合わせが選ばれる さらにビルドが成功か失敗かの通知を受け取れるように、通知のポストアクションにSlackチャンネルを追加。 できることはもっとあります カスタムビルドのスクリプトを実行したり、Xcode Cloud の Webhook やAPIを利用して他のシステムと連携できます。 Xcodeのワークフロー管理やビルドレポートはWeb上の AppStoreConnect でも利用可能。 各開発サイクルにどう役立つか Test Xcode Cloud があればコードのテストが、さらに徹底的により一貫して、もっと効率的に行えます。 複数のテストプラン、プラットフォーム、デバイス、OSバージョンですべて並行して実行可能。 Frutaでのデモ Fruta はライトモードとダークモードや縦横に対応。さらに２言語にローカライズ。 テストコードの中でXCテストAPIを採用。 自動的に各テストを各バリエーションで実行します。 Xcode Cloud のテストカバレッジでは、iOS15が動作する推奨iPadシミュレータで各構成につき１回ずつスクリーンショットが撮れている。 編集オプションメニューから新たなGallery Viewを有効にすると、テストのスクリーンショットが全バリエーションで表示される。 信頼性が低いテストケース ソースコードから Test Gem をクリックして、”Run Test Repeatedly”を選択。 テストを１００回実行。以前は自分で何度もテストを行う必要があった。 Xcodeはこのテストが非常に信頼性が低いと示しています。 他のメンバーが見られるように Xcode で信頼性に関するメッセージを含めます。 ソース修正をしたら、プロダクトメニューから選べる”Test Again”を活用する。 まだ信頼性が低いので、今後修正するべくリマインダー機能が使える。 Integrate PullRequest のフィードバックをXcodeで確認できる。 Xcode から PullRequest を作成可能。 新しいソースコントロールの変更タブから、ローカルで修正したすべてのファイルと PullRequest と組み込まれている変更が表示される。 PullRequest を選ぶと、すべてのアクティビティと進行中の会話の全体を外観することができる。 ソースコード上で PullRequest のコメントがエディタに表示される。 Xcode から PullRequest のコメントに返信できる。 ローカルのDiffの確認にインライン表示ができるようになる。 履歴内のブランチとローカルの変更を比較することができる。 Deliver Xcode Cloud なら簡単にアプリをチームとベータ版テスタに渡すことができる。 Code Signing in the Cloud を使えば、証明書やプロファイルを最新の状態にしておく必要がなくなる。 Xcode Cloud のワークフローにポストアクションを加えることで、TestFlightを通してすべてのAppleプラットフォームへベータ版が自動的に配信される。 新しい TestFlight For Mac を搭載したMacOSも含む。 Refine Xcode上から AppStoreConnect と同じ診断とフィードバックにアクセスできる。 TestFlightアプリで起きたクラッシュログとフィードバックは数分で Organizer へ届けられる。 Organizer からシンボリケートされたクラッシュログが確認可能。 テスターに詳しい症状を聞くため、Organizer から直接テスターに連絡することもできる。 Xcode 上でクリックひとつでクラッシュ箇所を開け、PullRequest も確認可能。 Xcode Cloud はプライバシーとセキュリティに配慮して作られました。 データはソースやアクセストークンサインインキーやビルドアーティファクトを含めて安全に管理される。 アップルはサービスを運用するにあたって最小限のデータだけ使用する。（何を使うのかはよくわからない） 料金 Xcode Cloud は当初無料の限定ベータ版として入手可能。 価格や発売日の詳細はこの秋にお知らせします。（おっと、無料ではないのか！） 登録のステータスを確認するには、Xcode13 か AppStoreConnect の Xcode Cloud タブから確認できます。 Swift async/await 新しい非同期処理の記述方法 async と await が使えるようになった。 Structured Concurrency async/await を使って構造化された並列コードの記載ができるようになる。 これまでの完了ハンドラを使わないので、ソースを読みやすくなる。 Actor 相互排他的なアクセスのみを提供することで自身の状態をを守れるようになる。 DispatchQueue はActorから着想を得ている。 Actorの同期は自動で管理される。 @MainActor これまではメインスレッドで実行する処理は DispatchQueue.main.async を使っていたが、 今後は自動でメインスレッドで実行させるには、メソッドに @MainActor を宣言することになる。 呼び出し元では await をつけるだけ。 Apple的には completionHandler の時代は終わったようだ。 SwiftUI いくつかのアップル純正アプリではSwiftUIで全面的に作り直した。 Fruta を改良するデモ いつもの Fruta アプリを使って、色々新機能を追加するデモ 新しいマテリアルのサポート コンテンツの背後に新しいマテリアルスタイルを適用することで、読みやすさを自動で維持する。 コンテンツは背景のマテリアルにあわせて、テキストの色などを動的に変更する。 Swift Playground 4 SwiftUIにも対応。 AppStoreに直接提出することも可能。 今年後半に利用可能。 AR RealityKit 2 Object Capture Object Capture を使うことにより、3Dモデルを数分で作れるようになった。 iPhoneで対象物の２D画像を撮影して、MacのObject Capture API で3Dモデルにする。 AR Quick Look用のUSDZファイルも生成できて、メッセージ、メール、Safariなどで閲覧可能。 Metal Selectice Shager Debugger Texture Converter Tool Metal Debugger Timeline View Focus これらのツールはユーザの気が散るのを防ぎ、没頭できるよう手助けします。 まずは通知への全く新しいアプローチ。 Interruption Level API 通知の緊急度を４つの中断レベルから選べるようになった。 * Passive * Active * Time Sensitive * Critical 通知にアバター コミュニケーションアプリでは通知にアバターがアイコンに重なるようになる。 通知要約 ユーザが選んだ時に通知がまとめて提供される。 選択したアプリのPassive, Active通知をまとめる。 各ユーザーに合わせて自動でパーソナライズされる。 おやすみモード 通知を受け取るアプリと人物を選べる。 Focus Status API 集中モードではステータスを共有できる。 アプリが集中モードのステータスを求めることも可能。 コミュニケーションアプリでは新しい UserNotificationAPI を使う。 新しい Focus Status API でユーザの集中モードもアプリに反映する。 （ビデオでは詳細が分からなかったが、サーバにも影響があるのかな？） スクリーンタイムAPI 新たなペアレンタルコントロール機能が追加。 Widget iPad対応 iPadのホーム画面にも対応して、iPad用に特大サイズが追加。 ウィジェットを取り入れたデフォルトのホーム画面レイアウトを用意。 スマートスタック TimelineEntryRelevance API を元にした、最もよく使うアプリを集めたスマートスタック Widget Suggestion スタックにないウィジェットでもおすすめ表示する。 Intents API を使ったドネートも可能。 Share Play Group Activities フレームを使い、体験をシェアする。 FaceTimeを使った体験の共有。 FaceTimeはグループを作成して、アプリはアクティビティを提供する。 グループ内でユーザがアクティビティを始めると Share Play がグループをアプリに導く。 Apple TV アプリのデモ Apple TVアプリ内の再生ボタンを押すと Shared Playback かローカル再生か選べる。 FaceTimeアプリではアプリのビデオ体験に合った再生を始められる。 ホワイトボードアプリのデモ 共有キャンバスを開き、全員で同じキャンバスに描いたものがリアルタイムで共有される。 以上。 ここには App Store 周りの情報がなかったので、別途調べないとな。