技術と本について書くブログ

技術と本について書くblog。技術メモなど雑記を書いているblog。

What's new in WKWebView2022

What's new in WKWebView

の日本語要約。内容はすべて以下の内容になります。

developer.apple.com

webViewの種類

アプリの中でシンプルなブラウザーの場合はSFSafariViewControllerを使いたいと思います。

もしアプリがまだ非推奨のUIWebViewを使っているなら、今こそより高速で応答性の高いWKWebViewに移行する時です。

UIWebView は将来のリリースで削除される予定です。

WKWebView はウェブコンテンツとインタラクションするアプリケーションを書くために使う API です。

CSSベースのUIに使用したり、JavaScriptでアプリの一部を書いたりすることができます。

アプリバウンドドメインを使用して、あなた自身のWebコンテンツと対話することができます。

また、独自のブラウザを開発している場合もあるでしょう。

どのような用途であっても、私たちは常に新しい機能を追加し、よりリッチなWebアプリケーションを作ることができるようにします。

WKWebViewの新機能

今年の WKWebView の新機能は以下4つ

・Web コンテンツの新しい操作方法

・コンテンツブロッカーの新機能暗号化メディア

・リモート

・Web インスペクタの使用

Web コンテンツの新しい操作方法

iOS 16では、フルスクリーンAPI、新しいCSSビューポートユニット、検索インタラクションの3つの方法で、 アプリケーションがウェブコンテンツとインタラクトすることができます。

まず、フルスクリーンについて説明します。

何年も前から、JavaScript はブラウザでビデオや canvas ゲームなどの HTML 要素をフルスクリーン表示することができました。

簡単な例として、携帯電話では次のように表示されます。JavaScript がフルスクリーンを要求し、ユーザーまたは JavaScript がフルスクリーンを終了することができます。

アプリで必要なことは、WKPreferences .isElementFullscreenEnabled を true に設定し、webkitRequestFullscreen などのフルスクリーン API を使用する Web コンテンツを読み込むことだけです。

しかし、アプリの遷移をカスタマイズしたい場合は、WKWebView.fullscreenState の値を監視することで、Web コンテンツがフルスクリーンになるか、戻るかをアプリに知らせることができます。

また、動的なビューポートのサイズに応じてウェブコンテンツをレイアウトできるようにするための新しい CSS ユニットも用意されています。

これらの新しい CSS ユニットには、svh、lvh、dvh などのユニットが含まれます。

これらのユニットにより、ウェブ開発者は最小、最大、および動的なビューポートサイズに基づいてレイアウトを変更することができます。

例えば、Safariで最初にページを開くと、ウェブページのホストと下部にいくつかのボタンが表示されます。

スクロールすると、ボタンが邪魔にならないようにスライドして、ビューポートのサイズが大きくなります。

Svh、lvh、dvhは、これらの異なるサイズのビューポートを測定するのに便利な単位です。

アプリケーションが WKWebView のビューポートを変更する場合、ビューポートのサイズの範囲が何であるかを前もって WebKit に通知する必要があります。

Swift では、1 つの関数呼び出しで WebKit に最大および最小のエッジインセットを通知し、アプリでこのウェブコンテンツを正しくレイアウトできるようにします。

iOS 16ではWKWebView内の検索のサポートを導入

多くのWKWebViewアプリケーションは、多くのテキストを読み込み、ユーザーはこのテキストを検索したいと思います。

WKWebView .findInteractionEnabled を true に設定すると、ユーザーは使い慣れた UI と Command-F のようなショートカットを使って、開いているページのテキストを検索できるようになります。

この1行のコードだけで機能をオンにできますが、 WKWebView .findInteraction を通じて UIFindInteraction オブジェクトにアクセスし、検索パネルの表示と非表示、または次や前の結果への移動をプログラムで行うこともできます。

コンテンツブロック

コンテンツ・ブロックについては、Safari でコンテンツ・ブロッカーを実装するために使用される API である WKContentRuleList に新しい機能が追加されました。

ここでは、サンプルサイトの iframe に Wikipedia を埋め込んでいます。

以前は、リクエストされた URL とトップフレームの URL に対して正規表現を実行し、読み込みをブロックするか、その他のアクションを実行するかを決定することができました。

しかし、時には、あるルールを特定のiframe内のロードにのみ適用したい場合があります。

このように、現在のフレームのURLに対して正規表現を実行することができます。

ここでは、Wikipediaを含むフレームからの画像のみをブロックするルールを書こうと思います。

これを行うには、次のようにJSONにif-frame-urlを追加します。

そして、先程と同じようにJSONをコンパイルして、WKWebViewConfigurationに適用します。

そして、リクエストを行うフレームのURLに対して、正規表現を実行します。

このブロックルールは、if-frame-url の正規表現にマッチするフレームからのリクエストにのみ適用されるようになります。

ここでは、Wikipediaのiframe内の画像のロードをブロックしていることがわかります。

もしあなたがコンテンツブロッカーの実装を真剣に考えているなら、 「What’s new in Safari Web Extensions」 セッションをチェックすべきです。

developer.apple.com

iPadOS 16のWKWebViewのもう一つの新機能は、暗号化されたメディアです。

Encrypted Media ExtensionsとMedia Source Extensions APIを使用するコンテンツがあれば、iPadOS上のアプリでそれを使用することができるようになりました。

つまり、AppleTV+のようなプレミアムコンテンツがあれば、iPadOSでもmacOSの時と同じように使えるようになるのです。

アプリがWebブラウザのエンタイトルメントを持っている場合、リモートWebインスペクタは、iOSのSafariでそうであったように、あなたのプロダクションアプリで動作するだけです;コードを追加または変更する必要はありません。

サードパーティーブラウザで Web Inspector を有効にするには、Safari の場合と同じ手順で行います。

まず、iOS デバイスの Safari の設定で Web Inspector をオンにし、Mac の Safari の「詳細設定」で「開発」メニューを有効にする必要があります。

携帯電話をMacに取り付け、macOSのSafariの「開発」メニューでデバイスを探します。

Webインスペクタには、Webコンテンツをデバッグするためのツールが多数用意されています。

DOMの探索、JavaScriptの実行とデバッグ、ページロードのタイムラインの表示などを行えます。

ウェブサイトを持っている場合、リモートWebインスペクタを使って、iOS上のサードパーティブラウザで自分で検査とデバッグを行えるようになりました。

Appleが新しく発表したパスキーについて Meet Passkeys

次世代認証技術であるpasskeysについて

developer.apple.com

パスキーの使い方

通常のフロー

IDを入力して → パスワードを入力 → SNS認証

これをパスキーに対応すると

1タップ(+ faceID)で完了

新しいパスワードを考えたり、複雑な条件を満たそうとしたりする必要はありません。

それぞれのパスキーはシステムによって生成され、強度が保証されており、1つのアカウントにのみ使用されます。

しかも、正しいアプリやウェブサイトでだけ使わせるように配慮され、強力なフィッシング耐性が内蔵されています。

追加方法

このアカウントにパスキーを追加してみます。 「アカウント管理」→「パスキーの追加」。ここで、パスキーを作成するためのシステムシートが表示されました。 数回タップするだけで、私のデバイスは私のアカウント用にユニークで暗号的に強力なキーペアを生成し、私のiCloudキーチェーンに保存しました。

webでも使える

パスキーはウェブ上でも使えます。

ここでは、Safariでシャイニーのウェブサイトを見ています。

携帯電話と同じように、ユーザー名フィールドにフォーカスすると、iCloud Keychainのおかげで私のパスキーがすでにそこにあり、すぐに使える状態になっています。

あとはTouch IDでサインインするだけです。

パスキーはオープンスタンダード

Appleのパスキーの実装は、オープンスタンダードに基づいて構築されています。

私たちは、FIDOアライアンス内の他のプラットフォームベンダーと協力して、パスキーの実装がクロスプラットフォームで互換性を持ち、できるだけ多くのデバイスで動作するようにしました。

私のアカウントをパスキーを使うようにアップグレードした後も、友人のPCからサインインすることができます。

もちろん、友人のPCにはローカルにパスキーは保存されていないが、ここでユーザー名を入力することはできる。

サインインを押すと、携帯電話を使わせてくれるというシートが表示されます。すると、QRコードが表示されます。これをスキャンします。

このQRコードはパスキーを使ってサインインするためのものだと認識されます。このオプションを選択すると、私の携帯電話とブラウザが安全に接続されます。

あとは「続ける」だけで、サインインが完了します。このクロスプラットフォームでのサインイン体験は、パスキーの背後にある標準の一部であり、第一級のシステム機能です。一見、とてもシンプルに見えますが、これは単なるQRコードではありません。

裏側では、デバイスがローカルな鍵の合意を行い、近接性を証明し、エンドツーエンドの暗号化通信路を確立しています。すべては、簡単な方法でサインインできるようにするためですが、passkeysの強力なフィッシング耐性を維持するためです。

どのようなデバイスからでも自分のアカウントに安全にサインインできるようにするために、とても役立っています。

パスワードの共有も可能

パスキーをAirDropを使って共有ができます。

私の携帯電話では、私はアカウントの詳細を開いて

AirDriopで共有が可能

これで私のパートナーもパスキーを持つことができます。

このように、どこでも簡単にパスキーを使うことができるのです。

パスキーのデザイン

パスキーについて語るとき、何よりもまず、パスキーはパスワードの代用品です。

パスキーはより速くサインインでき、より簡単に使用でき、より安全です。

以下は、アプリやウェブサイトでパスキーをどのように呼ぶかのガイドラインです。

Passkey は、一般的な、ユーザが目にすることのできる用語です。

"Passkey "はまた、"password "のような普通名詞です。英語では小文字で、"password "のように複数形になることを意味します。私は自分のアカウントにパスキーを持っていて、「設定」でパスキー付きのアカウントをすべて見ることができます。

SFシンボルのperson.key.badgeと.fillも用意されています。

アプリやウェブサイトでパスキーを提供する場合、まったく新しいインターフェースを設計する必要はありません。

そして今、ユーザー名フィールドに、もうひとつの大きな特徴が加わりました。

パスキーはサインインの仕組みに新しいパラダイムをもたらしますが、パスワードからの移行もスムーズで簡単である必要があります。

AutoFillを使用したパスキーは、ファーストクラスの機能として、既存のサインインフローにそのまま組み込むことができます。

AutoFillを使用したパスキーの提示は、パスキーの主要な使用方法です。

しかし、より高度な使い方として、Appleのプラットフォームには、パスキーを使ったサインイン用の幅広い追加UIオプションがあります。

パスキーの使用方法とAutoFillを使用したパスキーの表示方法について

Passkeys は WebAuthentication または WebAuthn 標準をベースに構築されており、公開鍵暗号方式を使用します。

入力可能な単語や文字列ではなく、一意の暗号キー ペアがアカウントごとに生成されます。

パスキーによるサインインを行うには、サーバーのバックエンドに WebAuthn を採用する必要があります。

パスキーは AuthenticationServices フレームワークの ASAuthorization API ファミリーに含まれます。

また、AutoFillのサポートなど、使用できる新しいメソッドもいくつか追加され、このAPIをさらに柔軟にして、既存のサインインフローにシームレスに適合させることができるようになりました。

アプリでパスキーを使い始めるには、まず、webcredentials サービスを使用して、関連するドメインを設定する必要があります。

詳細は、ビデオ「Introducing Password AutoFill for Apps」と「What's new in Universal Links」でご覧いただけます。

アプリのインターフェイスで、ユーザー名フィールドがユーザー名textContentTypeを使用していることを確認します。

これにより、パスキーの候補を提供する場所がシステムに通知されます。

この設定が完了したら、AutoFillによるパスキーリクエストを開始するために必要なコードを以下に示します。

他の WebAuthn リクエストと同様に、まずサーバーからチャレンジを取得する必要があります。

次に、プロバイダとリクエストを作成します。

ASAuthorizationPlatformPublicKey CredentialProvider は、パスキー リクエストを扱うための ASAuthorizationProvider です。

WebAuthn の用語では、サインイン時にアサーションを使用するため、ここでは既存のパスキーでサインインするためのアサーションリクエストを作成しています。

実際にリクエストを処理するのは ASAuthorizationController です。

パスキーリクエストでインスタンスを作成し、そのデリゲートとpresentationContextProviderを設定します。

そして最後に、performAutoFillAssistedRequests を呼び出して、リクエストを開始します。

このリクエストがアプリで実行されている間、ユーザー名フィールドがフォーカスされるたびに、システムは QuickType バーに利用可能なパスキーを提供します。

キーボードが表示されたときにパスキーの準備ができるように、ユーザー名フィールドがフォーカスされる前に、ビューライフタイム内の早い段階でこのリクエストを開始するようにしてください。

QuickType バーの項目が選択されると Face ID が呼び出され、ASAuthorizationController Delegate コールバックを受け取ってサインインを完了します。テキストフィールドには、実際には何も入力されません。

どの種類のクレデンシャルでも認証に成功すると、didCompleteWithAuthorizationコールバックを受け取ります。

最初にすべきことは、取得したクレデンシャルの種類を確認することです。

パスキーによるサインインの場合、それは ASAuthorizationPlatformPublicKey CredentialAssertion となる。アサーション・オブジェクトには、バックエンドでサインインを検証するために必要なフィールドが含まれる。

値を読み込んでサーバで検証し、サインインを完了させる必要がある。

AutoFill によるパスキーリクエストは強力です。

先ほど紹介したコードでは、追加の変更なしに近くのデバイスからパスキーサインインすることも可能です。

鍵のアイコンをタップして、利用可能なすべてのパスキーとパスワードを一覧表示するビューを表示し、近くのデバイスでサインインするオプションにたどり着くことができます。

その後、クロスデバイスのパスキーサインインを実行できます。

どちらの場合も、パスキーが使われると、同じASAuthorizationController Delegateコールバックを受け取ります。

これをサポートするために必要な特別なことは何もありません。

もしユーザーがまだパスキーを持っていない場合は、ログインフォームをそのまま使用することができます。QuickTypeバーにパスワードの候補が表示されますし、フィールドに入力することもできます。

パスワードの項目が選択された場合でも、クレデンシャルはテキストフィールドに入力され、実行中のリクエストをキャンセルすることができます。

このAPIは、既存のサインインフローにそのまま追加できるように設計されており、ユーザーにとって非常に使いやすいものとなっています。

既にパスキーの使用にアップグレードした人が、AutoFill の提案を使う代わりに、とにかくユーザ名を入力しようと決めた場合、AutoFill のリクエストをキャンセルして、ASAuthorizationController を使ってモーダルパスキーサインインシートを表示させる必要があります。

ここからはシングルタップで、同じ ASAuthorizationController Delegate のコールバックを受け取ることができます。

以下は、以前のコードです。AutoFill リクエストからモーダルリクエストに切り替えるには、この performAutoFillAssistedRequests メソッドの呼び出しを performRequests() の呼び出しに置き換えるだけです。

Web

Web プラットフォームも、AutoFill アシストとモーダルパスキーの両方のリクエストをサポートしています。

Web では、セキュリティ キーにも使用される標準の WebAuthn API を介してパスキーが使用されます。アプリと同様に、AutoFill アシスト リクエストを採用すると、Touch ID だけですばやくサインインしたり、利用可能なすべてのパスキーとパスワードを取得したり、近くのデバイスからパスキーを使用したりすることができ、これらはすべて非常に少ないコードで実現できます。

詳細はこちら

Apple Developer Documentation

プラットフォームの追加機能

AutoFillによるサインインに加え、ASAuthorization APIはさらに多くの便利な機能を提供しています。

ここでは、APIの3つの追加機能と、それらをどのような場合に使用したいかを説明します。

パスキー許可リスト

デフォルトでは、利用可能なすべてのパスキーがシートに表示されます。

パスキーの許可リストを使用して、シートに表示されるパスキーを制限し、一致するアカウントのみが提供されるようにすることができます。モーダルリクエストに許可リストを追加するには、まず、ユーザー名が必要です。

そのユーザー名を使って、一致するクレデンシャル ID のリストを取得し、それを許可リストにすることができます。

クレデンシャル ID とは、パスキーの一意な識別子です。Webauthn サーバーは、与えられたユーザー名のクレデンシャル ID を検索する方法を持つべきです。

ここからは、先ほどと同じようにリクエストを進めるだけです。

さて、パスキーを使用して3つのShinyアカウントを持つ私のデバイスでは、シートは私が使用しようとしている1つのアカウントのみを提供します。

モーダル リクエストを作成する場合、ユーザーがどのアカウントでサインインしようとしているか、例えばユーザー名をすでに入力しているかなどの追加情報があるときは、許可リストを使用する必要があります。

パスキーが保存されていない場合、モーダルパスキーのリクエストを行うとどうなるか

許可リストを使用していて、保存されているパスキーのどれもがそのリストに一致しない場合にも当てはまります。

デフォルトでは、モーダルパスキーリクエストを行う際、一致するパスキーがない場合は、モーダルシートが表示され、近くのデバイスからパスキーでサインインするための QR コードがすぐに表示されます。

これはサインイン時に最も柔軟性があり、パスキーが使用されていることが分かっている場合には最適なオプションです。

しかし、APIには新しいオプションがあり、すぐに利用できる認証情報を優先し、ない場合はデリゲートコールバックで静かにフォールバックするようになっています。

これは、従来のサインインフォームを表示する前に、可能であれば既存のクレデンシャルを迅速に提供するために使用できます。

デバイス上に少なくとも 1 つの一致するクレデンシャルがある場合、使用するオプションに関係なく、フル モーダル シートが表示されます。

現在のデバイスにパスキーがない場合でも、近くのデバイスでサインインするオプションに到達できるように、アプリ内のどこかで AutoFill アシスト リクエストまたはデフォルト フォールバックでのモーダルリクエストを使用していることも確認してください。

複合クレデンシャルリクエストの作成

この例では、アプリがパスキー、パスワード、Sign in with Appleのリクエストを行いました。

私のデバイスにはたまたま3つの異なるアカウントの認証情報が保存されていたので、ここにすべて表示されています。

しかし、より可能性の高いシナリオは、誰かが1つのアカウントしか持っていない場合です。

その場合、シートで1つのアカウントのみを提供します。

既存のASAuthorizationリクエストに追加のクレデンシャルタイプを追加するのは、本当に簡単です。

追加のリクエストタイプのためのプロバイダとリクエストを作成し、それらの新しいリクエストをコントローラに渡すだけです。

これで、モーダルシートは、これらのクレデンシャルタイプのいずれかから利用可能なクレデンシャルを提供することになります。

まとめ

パスワードからパスキーへとユーザーを誘導することで、信じられないほど迅速で便利なサインインを体験してもらうと同時に、全員のセキュリティレベルを向上させることができるのです。

参考: About the security of passkeys - Apple Support

Appleのプライバシー保護について[What’s new in privacy]

developer.apple.com

Appleのプライバシー保護について

今回のWWDC22でのプライバシー周りのアップデートの概要は以下の通り

・データの最小化

機能を構築するために必要なデータのみを使用します。

・オンデバイス処理

その機能が機密データを必要とする場合、デバイスのパワーを使ってサーバーとの共有を避けます。

・透明性と制御

機密データが端末外に送信される場合は、送信内容やその使用方法を理解させ、コントロールできるようにする。

・セキュリティ保護

転送中および保存中の機密データを、デバイスの内外を問わず保護します。

変更された機能

iOS 16 と macOS Ventura には、

  1. デバイス名へのアクセスを制限する新しいデバイス名エンタイトルメント

  2. 位置情報利用時のアトリビューションに関するアップデート

  3. 公証アプリの整合性をより多くの場所で検証する Gatekeeper の改善

  4. ログイン時に Mac アプリを起動すると通知が出る

  5. Pasteboard アクセスには権限が必要になった

という重要な変更があります。

1. デバイス名へのアクセスを制限する新しいデバイス名エンタイトルメント

デバイスの識別を容易にするため、iOSではApple IDアカウントからのユーザー名がデバイス名の一部としてデフォルトで含まれるようになりました。

iOS 16以前は、UIDevice APIによって、アプリはユーザが割り当てたデバイス名にアクセスすることができました。

この値へのアプリのアクセスをユーザーの期待とより一致させるために、UIDevice.name API は、ユーザーがどのようにカスタマイズしても、ユーザーが割り当てた名前ではなく、デバイスのモデルを返します。

デバイス名を表示する方法

アプリがマルチデバイス機能を使用し、アプリのUIでこれを可視化する場合、デバイス名にアクセスするための権限を要求することができます。

このエンタイトルメントがあっても、クラウドホスティングサービスプロバイダー以外の第三者とのデバイス名の共有は許可されていません。

2. 位置情報利用時のアトリビューションに関するアップデート

アプリが位置情報を使用すると、iOSはステータスバーに以下のように矢印を表示します。

iOS 16では、コントロールセンターから下にスワイプすると、どのアプリが位置情報を使用しているかが表示されます。

アプリが位置情報を使用するのは、予想される場合に限るようにしましょう。

3. 公証アプリの整合性をより多くの場所で検証する Gatekeeper の改善

Gatekeeperは、新しくダウンロードされたアプリの整合性をチェックします。 macOS Venturaでは、Gatekeeperは隔離されたアプリだけでなく、公証されたすべてのアプリの整合性をチェックするようにしました。

まず、アプリが適切に署名されている必要があります。 macOS Venturaでは、公証済みアプリの署名が有効でなくなった場合、初回起動時にGatekeeperによってブロックされます。 すべての実行ファイルとバンドルに署名し、アプリに変更を加えたときにその署名が有効であることを確認する必要があります。完全性チェックに加えて、Gatekeeper はアプリが特定の方法で変更されるのを防ぐことができる。

追加方法

別の開発チームによるアプリの更新を許可したり、更新者を自分の更新者だけに制限したりするには 許可したい NSUpdateSecurityPolicy をInfo.plistに追加する。

4. ログイン時に Mac アプリを起動する通知が追加

macOS Monterey以前では、誰かがMacにログインすると、起動エージェントやデーモンを使ってログイン時にアプリを実行することができます。

ただ、ユーザーがMacにログインすると、関係のないアプリが開いてしまい、邪魔になることがあります。 さらに、アプリや他のソフトウェアがセンサーや位置情報などのデータにアクセスすることもあります。

実行されているものが目に見えないこともあるため、必ずしも人にはわからないのです。

また、開発者にとっても、ログイン時に起動する機構は、デーモン、エージェント、サービス管理...と、どれを使えばいいのか、必ずしも明確ではありません。

そこで、macOS Ventura では、新しい単一の API を使って、ログイン時にアプリ、ローンチエージェント、またはデーモンを起動することができます。

アプリは、デフォルトでログイン時の起動が許可され、ユーザーにも通知されます。

アプリが昇格した権限を持つデーモンを必要とする場合は、有効にするために管理者の承認が必要です。

通知をクリックすると、システム設定にログイン項目ペインが表示され、システム上で起動するアプリを管理することができます。

上部はログイン時に実行されるアプリを管理し、下部はログイン時に実行されるその他の項目を管理します。 このペインでは、エージェント、デーモン、SMLoginItems、およびログイン時に開くように自身を追加するアプリなど、アプリがログイン時に実行できるさまざまな方法を制御できるようになりました。

APIの使い方

サービス管理フレームワークを利用すると、ログイン時にリソースを簡単に起動することができます。

すべてのエージェントとデーモンはアプリバンドル内に住んでいるので、もうインストーラを使って起動エージェントを書いたり、クリーンアップスクリプトを作成する必要はありませんし、これは Mac App Store アプリでも機能します。

SMAppService APIをアプリから呼び出すことで、通知を受け取るタイミングや、設定でのアプリアイコンの表示を制御することができます。

5. Pasteboard アクセスには権限が必要に

編集オプションでペーストを押していないのに、アプリがペーストボードにアクセスすると、透明度の高い通知が表示されました。

iOS 16では、他のアプリが書き込んだペーストボード項目へのすべてのアクセスについて、システムが意図を確認するようになっています。

UIKitのペースト・コントロールについて

UIKitのペーストコントロールをアプリのエクスペリエンスに追加すると、ボタンを押すことで直感的にペーストボードにアクセスできるようになります。

プライベートアクセストークン

CAPTCHAに邪魔されることなく不正を防止する強力なツールです。

プライベートアクセストークンは、CAPTCHAの代わりに、ウェブサイトやAPIの開発者がそれらのデバイスを追跡することなく正規のデバイスを認識できるようにするブラインドトークンを使用して構築されています。

詳しくは、ビデオ「Replace CAPTCHAs with Private Access Tokens」をご覧ください。

Passkeysとは

Passkeysは、より堅牢な認証ソリューションを可能にし、パスワード自動入力と同じように、すぐに親しみのあるUIスタイルと生体認証を使用します。

パスキーは公開鍵暗号方式で構築されているため、サーバーが保存する値は弱くなることはなく、もし明らかにされても、それは本当に公開されているので問題にはなりません。

パスキーは本来、対応するウェブサイトとリンクしているため、フィッシングされることはない。

パスキーの実装については、"Meet Passkeys "というセッションがあります。

developer.apple.com

Safety Check

「Safety Check」はiOS 16の新しいプライバシーツールです。

セーフティチェックは、家庭内暴力や親密なパートナーからの暴力を受けている人が、以前に他人に許可した可能性のあるアクセスを見直し、リセットするのに役立つように設計されています。

FindMyの位置情報共有をオフにし、写真、メモ、カレンダーの共有を停止することで、人々とのデータ共有を停止します。

すべてのサードパーティアプリのシステムプライバシー許可をリセットすることで、アプリとのデータ共有を停止します。

iOS16から登場したDeveloper mode

developer.apple.com

Developer Mode とは

iOS 16とwatchOS 9の新しいモードで、一般的なデベロッパーのワークフローを可能にするものです。 デベロッパーモードはデフォルトでは無効になっており、デバイスをデベロッパーモードに明示的に登録する必要があります。

iOS16からは開発用のAppを実行するにはDeveloper modeをオンにする必要があります。

つまり → 設定からこれをONにして再起動しないと実機転送できんぞ

登録した内容は、再起動やシステムアップデートを経ても持続します。もちろん、デベロッパーモードの設定を自動化するためのツールも用意されています。

デベロッパーモードのオンのやり方

macにiPhoneを繋いで何かしらのAppをXcodeから実行すれば起動がすれば準備完了

「設定」、「プライバシーとセキュリティ」、「開発者モード」に進むことができます。

開発者モードをオンにするには、デバイスを再起動する必要があるので、先にそれを行いましょう。

デバイスの再起動が完了すると、もう一度確認画面が表示されます。Turn Onをタップしたら、もう大丈夫です。これで、XcodeはデバイスがDeveloper Modeを有効にしていることを確認し、アプリケーションを実行できるようになりました。

このフローは、1台のデバイスで作業する場合は有効ですが、複数のデバイスを扱う場合は、このプロセスに時間がかかることがあります。このため、このプロセスを自動化するためのツールが追加!

自動化フローには1つの制限があります。パスコードのないデバイスだけが、自動的にDeveloper Modeを有効にすることができます。これは、iPhoneを再起動する際に、デバイスを操作する前にロックを解除する必要があるためです。

macOS Venturaにdevmodectlが追加

自動化をサポートするために、macOS Ventura には devmodectl が同梱されています。

これを使えば、すでに接続している一つのデバイスで Developer Mode を有効にするか、ストリーミングモードで、 パスコードを設定していない接続した全てのデバイスの Developer Mode を自動的にオンにすることができます。

iPhoneで3Dで部屋をスキャンできる RoomPlanが登場

developer.apple.com

Create parametric 3D room scans with RoomPlan

RoomPlanとは

RoomPlanは、LiDARを搭載したiPhoneやiPadを使って、部屋をスキャンすることができます。

このフレームワークは、部屋のパラメトリックな3Dモデルとその部屋を定義するオブジェクトを生成し、あなたのアプリケーションで使用することができます。 RoomPlan は、ARKit を利用した高度な機械学習アルゴリズムを使用して、壁、窓、開口部、ドア、および暖炉、ソファ、テーブル、キャビネットなどの部屋を定義するオブジェクトを検出します。

RealityKit を使用してスキャンの進捗状況をリアルタイムでレンダリングする RoomCaptureView API を使用すると、スキャン体験をアプリに簡単に統合できます。

RoomPlan を使用する主な方法は

使用方法は2つ

1 つ目は、すぐに使えるスキャン機能で、RoomPlan をお客様のアプリにシームレスに統合できます。

2 つ目は、データ API をつか方法で、お客様のアプリでスキャンからのライブ パラメトリック データを使用できるようにするもので、お客様の用途に最も適した方法で使用できます。

RoomCaptureView API

RoomCaptureView は UIView のサブクラスで、アプリに簡単に配置することができます。

このクラスは、世界空間スキャンのフィードバック、リアルタイムのルームモデル生成、およびコーチングとユーザーガイダンスの表示を処理します。

RoomCaptureViewベースのスキャン中に表示されるデザイン要素について詳しく見ていきましょう。

RoomCaptureViewのセッション中は、検出された壁、窓、開口部、ドア、および部屋を定義するオブジェクトの輪郭が、アニメーション化された線でリアルタイムに表示されます。

対応している部屋、デバイス

RoomPlan APIは、一般的な家庭の建築構造とオブジェクトのほとんどをサポートしています。 最大で30フィート×30フィート(約9メートル×9メートル)の部屋の大きさの住宅用シングルルームに最適です。 照明もまた、APIがクリアなビデオストリームと優れたARトラッキング性能を得るために重要です。

APIを使用する際には、最低でも50ルクス以上を推奨しており、これは夜間の一般的な家庭のリビングルームの明るさに相当します。

ハードウェアについては、RoomPlan APIは、LiDAR対応のiPhoneとiPad Proの全モデルに対応しています。

注意点

フルハイトの鏡やガラスは、LiDARセンサーが期待通りの出力をするためうまくいきません。

高い天井も、LiDARセンサーのスキャン範囲の限界を超えてしまう可能性があります。 また、非常に暗い表面は、デバイスのスキャンが困難な場合があります。 より良いスキャン結果を得るためには、いくつかの考慮事項があります。 まず、高い精度が要求される用途では、スキャン前に部屋を準備することで、スキャンの質を高めることができます。

例えば、カーテンを開けると自然光が入りやすくなり、窓の蔽いを減らすことができるので、日中のスキャンには最適です。

また、ドアを閉めれば、部屋の外側の不要な場所をスキャンする可能性を減らすことができます。

また、APIを使ったスキャンでは、スキャン動作を正しく行うことが重要です。

繰り返しのスキャンや5分以上の長時間のスキャンはバッテリーを消耗し、熱問題を発生させ、アプリのユーザー体験に影響を与える可能性があります。

カルディ ブラジル ダークロースト カルモデミナス地区 コーヒー豆

カルディのコーヒー福袋に入っているブラジル ダークロースト  カルモデミナス地区

写真左

苦めのコーヒー豆ですが、エスプレッソマシンとの相性がとてもよくデロンギのコーヒーマシンととてもよく合います。

これをリピしたいのですが、まったく同じパッケージがないようですね。