契約したばかりのスポーツクラブで月額払ってすぐ破産しました。
同じようなことが起こった方のためにメモ
契約を店舗で行い、クレジットカードで数ヶ月分の月謝とユニフォームなどを支払い。 合計 41,600円。安くはない支払い。
趣味で倒産のニュースなどは日々チェックしているので、Twitterで契約したばかりのスポーツクラブが破産していることを知る。
電話などをかけても繋がらず。 ちょっと焦る。
クレジットカード会社に連絡。（なかなか電話が繋がらない）
クレジットカードから送付してもらった。 支払い異議申し立て書を提出。
クレジットカード会社からスポーツクラブからの支払いは保留になっているので引き落とされないとの連絡。 ちなみにここからは直接担当部署に連絡できるのですぐに電話は繋がる。
クレジットカード会社から支払いのキャンセルが完了したとの連絡。 これですべて完了。
・事前支払いはクレジットカードでやるように
・とりあえず、クレジットカード会社に連絡をして支払い異議申し立て書をすぐに提出を行う。
少しでも家事を楽にするために毎月家事代行を頼むようにしました。
使っているのはCasyです。
だいたい一回6000円です。
以前も一回使ったことあるのですが、やっぱりきれいになりますね。
風呂以外の水回り（風呂掃除は時間がかかるので自分でやっています)
廊下から部屋、玄関までの掃除機、水拭きをお願いしています。
また、自動掃除機や空気清浄機のフィルター掃除など定期的にやる必要があるけど、忘れそうなタスクもこの時にやってもらっています。
毎月定期にやるにしても、あの日は大丈夫だっけ？みたいな感じで微妙に調整しないといけないのがめんどくさいですね。
What's new in WKWebView
の日本語要約。内容はすべて以下の内容になります。
アプリの中でシンプルなブラウザーの場合はSFSafariViewControllerを使いたいと思います。
もしアプリがまだ非推奨のUIWebViewを使っているなら、今こそより高速で応答性の高いWKWebViewに移行する時です。
UIWebView は将来のリリースで削除される予定です。
WKWebView はウェブコンテンツとインタラクションするアプリケーションを書くために使う API です。
CSSベースのUIに使用したり、JavaScriptでアプリの一部を書いたりすることができます。
アプリバウンドドメインを使用して、あなた自身のWebコンテンツと対話することができます。
また、独自のブラウザを開発している場合もあるでしょう。
どのような用途であっても、私たちは常に新しい機能を追加し、よりリッチなWebアプリケーションを作ることができるようにします。
今年の WKWebView の新機能は以下４つ
・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 に最大および最小のエッジインセットを通知し、アプリでこのウェブコンテンツを正しくレイアウトできるようにします。
多くの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」 セッションをチェックすべきです。
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上のサードパーティブラウザで自分で検査とデバッグを行えるようになりました。
次世代認証技術であるpasskeysについて
IDを入力して → パスワードを入力 → SNS認証
1タップ(+ faceID)で完了
新しいパスワードを考えたり、複雑な条件を満たそうとしたりする必要はありません。
それぞれのパスキーはシステムによって生成され、強度が保証されており、1つのアカウントにのみ使用されます。
しかも、正しいアプリやウェブサイトでだけ使わせるように配慮され、強力なフィッシング耐性が内蔵されています。
このアカウントにパスキーを追加してみます。 「アカウント管理」→「パスキーの追加」。ここで、パスキーを作成するためのシステムシートが表示されました。 数回タップするだけで、私のデバイスは私のアカウント用にユニークで暗号的に強力なキーペアを生成し、私のiCloudキーチェーンに保存しました。
パスキーはウェブ上でも使えます。
ここでは、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オプションがあります。
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 プラットフォームも、AutoFill アシストとモーダルパスキーの両方のリクエストをサポートしています。
Web では、セキュリティ キーにも使用される標準の WebAuthn API を介してパスキーが使用されます。アプリと同様に、AutoFill アシスト リクエストを採用すると、Touch ID だけですばやくサインインしたり、利用可能なすべてのパスキーとパスワードを取得したり、近くのデバイスからパスキーを使用したりすることができ、これらはすべて非常に少ないコードで実現できます。
詳細はこちら
AutoFillによるサインインに加え、ASAuthorization APIはさらに多くの便利な機能を提供しています。
ここでは、APIの3つの追加機能と、それらをどのような場合に使用したいかを説明します。
デフォルトでは、利用可能なすべてのパスキーがシートに表示されます。
パスキーの許可リストを使用して、シートに表示されるパスキーを制限し、一致するアカウントのみが提供されるようにすることができます。モーダルリクエストに許可リストを追加するには、まず、ユーザー名が必要です。
そのユーザー名を使って、一致するクレデンシャル ID のリストを取得し、それを許可リストにすることができます。
クレデンシャル ID とは、パスキーの一意な識別子です。Webauthn サーバーは、与えられたユーザー名のクレデンシャル ID を検索する方法を持つべきです。
ここからは、先ほどと同じようにリクエストを進めるだけです。
さて、パスキーを使用して3つのShinyアカウントを持つ私のデバイスでは、シートは私が使用しようとしている1つのアカウントのみを提供します。
モーダル リクエストを作成する場合、ユーザーがどのアカウントでサインインしようとしているか、例えばユーザー名をすでに入力しているかなどの追加情報があるときは、許可リストを使用する必要があります。
許可リストを使用していて、保存されているパスキーのどれもがそのリストに一致しない場合にも当てはまります。
デフォルトでは、モーダルパスキーリクエストを行う際、一致するパスキーがない場合は、モーダルシートが表示され、近くのデバイスからパスキーでサインインするための QR コードがすぐに表示されます。
これはサインイン時に最も柔軟性があり、パスキーが使用されていることが分かっている場合には最適なオプションです。
しかし、APIには新しいオプションがあり、すぐに利用できる認証情報を優先し、ない場合はデリゲートコールバックで静かにフォールバックするようになっています。
これは、従来のサインインフォームを表示する前に、可能であれば既存のクレデンシャルを迅速に提供するために使用できます。
デバイス上に少なくとも 1 つの一致するクレデンシャルがある場合、使用するオプションに関係なく、フル モーダル シートが表示されます。
現在のデバイスにパスキーがない場合でも、近くのデバイスでサインインするオプションに到達できるように、アプリ内のどこかで AutoFill アシスト リクエストまたはデフォルト フォールバックでのモーダルリクエストを使用していることも確認してください。
この例では、アプリがパスキー、パスワード、Sign in with Appleのリクエストを行いました。
私のデバイスにはたまたま3つの異なるアカウントの認証情報が保存されていたので、ここにすべて表示されています。
しかし、より可能性の高いシナリオは、誰かが1つのアカウントしか持っていない場合です。
その場合、シートで1つのアカウントのみを提供します。
既存のASAuthorizationリクエストに追加のクレデンシャルタイプを追加するのは、本当に簡単です。
追加のリクエストタイプのためのプロバイダとリクエストを作成し、それらの新しいリクエストをコントローラに渡すだけです。
これで、モーダルシートは、これらのクレデンシャルタイプのいずれかから利用可能なクレデンシャルを提供することになります。
パスワードからパスキーへとユーザーを誘導することで、信じられないほど迅速で便利なサインインを体験してもらうと同時に、全員のセキュリティレベルを向上させることができるのです。
今回のWWDC22でのプライバシー周りのアップデートの概要は以下の通り
・データの最小化
機能を構築するために必要なデータのみを使用します。
・オンデバイス処理
その機能が機密データを必要とする場合、デバイスのパワーを使ってサーバーとの共有を避けます。
・透明性と制御
機密データが端末外に送信される場合は、送信内容やその使用方法を理解させ、コントロールできるようにする。
・セキュリティ保護
転送中および保存中の機密データを、デバイスの内外を問わず保護します。
iOS 16 と macOS Ventura には、
デバイス名へのアクセスを制限する新しいデバイス名エンタイトルメント
位置情報利用時のアトリビューションに関するアップデート
公証アプリの整合性をより多くの場所で検証する Gatekeeper の改善
ログイン時に Mac アプリを起動すると通知が出る
Pasteboard アクセスには権限が必要になった
という重要な変更があります。
デバイスの識別を容易にするため、iOSではApple IDアカウントからのユーザー名がデバイス名の一部としてデフォルトで含まれるようになりました。
iOS 16以前は、UIDevice APIによって、アプリはユーザが割り当てたデバイス名にアクセスすることができました。
この値へのアプリのアクセスをユーザーの期待とより一致させるために、UIDevice.name API は、ユーザーがどのようにカスタマイズしても、ユーザーが割り当てた名前ではなく、デバイスのモデルを返します。
アプリがマルチデバイス機能を使用し、アプリのUIでこれを可視化する場合、デバイス名にアクセスするための権限を要求することができます。
このエンタイトルメントがあっても、クラウドホスティングサービスプロバイダー以外の第三者とのデバイス名の共有は許可されていません。
アプリが位置情報を使用すると、iOSはステータスバーに以下のように矢印を表示します。
iOS 16では、コントロールセンターから下にスワイプすると、どのアプリが位置情報を使用しているかが表示されます。
アプリが位置情報を使用するのは、予想される場合に限るようにしましょう。
Gatekeeperは、新しくダウンロードされたアプリの整合性をチェックします。 macOS Venturaでは、Gatekeeperは隔離されたアプリだけでなく、公証されたすべてのアプリの整合性をチェックするようにしました。
まず、アプリが適切に署名されている必要があります。 macOS Venturaでは、公証済みアプリの署名が有効でなくなった場合、初回起動時にGatekeeperによってブロックされます。 すべての実行ファイルとバンドルに署名し、アプリに変更を加えたときにその署名が有効であることを確認する必要があります。完全性チェックに加えて、Gatekeeper はアプリが特定の方法で変更されるのを防ぐことができる。
別の開発チームによるアプリの更新を許可したり、更新者を自分の更新者だけに制限したりするには 許可したい NSUpdateSecurityPolicy をInfo.plistに追加する。
macOS Monterey以前では、誰かがMacにログインすると、起動エージェントやデーモンを使ってログイン時にアプリを実行することができます。
ただ、ユーザーがMacにログインすると、関係のないアプリが開いてしまい、邪魔になることがあります。 さらに、アプリや他のソフトウェアがセンサーや位置情報などのデータにアクセスすることもあります。
実行されているものが目に見えないこともあるため、必ずしも人にはわからないのです。
また、開発者にとっても、ログイン時に起動する機構は、デーモン、エージェント、サービス管理...と、どれを使えばいいのか、必ずしも明確ではありません。
そこで、macOS Ventura では、新しい単一の API を使って、ログイン時にアプリ、ローンチエージェント、またはデーモンを起動することができます。
アプリは、デフォルトでログイン時の起動が許可され、ユーザーにも通知されます。
アプリが昇格した権限を持つデーモンを必要とする場合は、有効にするために管理者の承認が必要です。
通知をクリックすると、システム設定にログイン項目ペインが表示され、システム上で起動するアプリを管理することができます。
上部はログイン時に実行されるアプリを管理し、下部はログイン時に実行されるその他の項目を管理します。 このペインでは、エージェント、デーモン、SMLoginItems、およびログイン時に開くように自身を追加するアプリなど、アプリがログイン時に実行できるさまざまな方法を制御できるようになりました。
サービス管理フレームワークを利用すると、ログイン時にリソースを簡単に起動することができます。
すべてのエージェントとデーモンはアプリバンドル内に住んでいるので、もうインストーラを使って起動エージェントを書いたり、クリーンアップスクリプトを作成する必要はありませんし、これは Mac App Store アプリでも機能します。
SMAppService APIをアプリから呼び出すことで、通知を受け取るタイミングや、設定でのアプリアイコンの表示を制御することができます。
編集オプションでペーストを押していないのに、アプリがペーストボードにアクセスすると、透明度の高い通知が表示されました。
iOS 16では、他のアプリが書き込んだペーストボード項目へのすべてのアクセスについて、システムが意図を確認するようになっています。
UIKitのペーストコントロールをアプリのエクスペリエンスに追加すると、ボタンを押すことで直感的にペーストボードにアクセスできるようになります。
CAPTCHAに邪魔されることなく不正を防止する強力なツールです。
プライベートアクセストークンは、CAPTCHAの代わりに、ウェブサイトやAPIの開発者がそれらのデバイスを追跡することなく正規のデバイスを認識できるようにするブラインドトークンを使用して構築されています。
詳しくは、ビデオ「Replace CAPTCHAs with Private Access Tokens」をご覧ください。
Passkeysは、より堅牢な認証ソリューションを可能にし、パスワード自動入力と同じように、すぐに親しみのあるUIスタイルと生体認証を使用します。
パスキーは公開鍵暗号方式で構築されているため、サーバーが保存する値は弱くなることはなく、もし明らかにされても、それは本当に公開されているので問題にはなりません。
パスキーは本来、対応するウェブサイトとリンクしているため、フィッシングされることはない。
パスキーの実装については、"Meet Passkeys "というセッションがあります。
「Safety Check」はiOS 16の新しいプライバシーツールです。
セーフティチェックは、家庭内暴力や親密なパートナーからの暴力を受けている人が、以前に他人に許可した可能性のあるアクセスを見直し、リセットするのに役立つように設計されています。
FindMyの位置情報共有をオフにし、写真、メモ、カレンダーの共有を停止することで、人々とのデータ共有を停止します。
すべてのサードパーティアプリのシステムプライバシー許可をリセットすることで、アプリとのデータ共有を停止します。
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 が同梱されています。
これを使えば、すでに接続している一つのデバイスで Developer Mode を有効にするか、ストリーミングモードで、 パスコードを設定していない接続した全てのデバイスの Developer Mode を自動的にオンにすることができます。
Create parametric 3D room scans with RoomPlan
RoomPlanは、LiDARを搭載したiPhoneやiPadを使って、部屋をスキャンすることができます。
このフレームワークは、部屋のパラメトリックな3Dモデルとその部屋を定義するオブジェクトを生成し、あなたのアプリケーションで使用することができます。 RoomPlan は、ARKit を利用した高度な機械学習アルゴリズムを使用して、壁、窓、開口部、ドア、および暖炉、ソファ、テーブル、キャビネットなどの部屋を定義するオブジェクトを検出します。
RealityKit を使用してスキャンの進捗状況をリアルタイムでレンダリングする RoomCaptureView API を使用すると、スキャン体験をアプリに簡単に統合できます。
使用方法は２つ
1 つ目は、すぐに使えるスキャン機能で、RoomPlan をお客様のアプリにシームレスに統合できます。
2 つ目は、データ 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分以上の長時間のスキャンはバッテリーを消耗し、熱問題を発生させ、アプリのユーザー体験に影響を与える可能性があります。
