iOS Universal LinksでバンドルIDとAASAアプリIDの不一致を修正する方法

バンドルIDの不一致によってiOS Universal Linksが機能しなくなるのはなぜですか？ アプリケーションの署名済みアプリケーション識別子が、関連ドメインに対応するAASAのappID/appIDsエントリと一致しない場合、関連ドメインの検証が失敗し、Universal Linksが機能しなくなります。

バンドルID（CFBundleIdentifier）は、Appleエコシステム内で個々のiOSアプリケーションを識別する一意の文字列です。Universal Linkのアーキテクチャでは、バンドルIDがアプリケーション識別子プレフィックスと結合されてアプリケーション識別子が形成され、オペレーティングシステムはホストされているapple-app-site-associationファイルに対してこれを検証することで、ネイティブURLの処理を認可します。

用語	定義
バンドルID	XcodeでiOSアプリターゲットに割り当てられる一意の逆DNS識別子（`CFBundleIdentifier`）。
アプリケーション識別子プレフィックス	Apple Developerアカウントの設定で割り当てられるApp IDプレフィックス（常にチームIDと一致するとは限りません）。
Universal Links	WebのHTTPS URLをネイティブアプリのビューに直接ルーティングするためのAppleの標準メカニズム。
関連ドメイン（Associated Domains）	アプリが処理を承認されているWebドメインを宣言するXcodeの機能（Entitlements）（`applinks:`）。
AASAファイル	アプリのURL処理を認可するためにドメイン上でホストされるJSONファイル（`apple-app-site-association`）。

標準診断チェーン

以下の図は、アプリのインストールおよびドメイン検証中に実行される多層検証シーケンスを示しています。

Layer 1: Signed App Binary
       │
       ├── application-identifier (<Prefix>.<BundleID>)
       ├── com.apple.developer.team-identifier
       └── com.apple.developer.associated-domains (applinks:example.com)
                    │
                    ▼
Layer 2: AASA Delivery & CDN Ingestion
       │ (Apple-managed infrastructure retrieves origin AASA)
                    ▼
Layer 3: AASA Schema & Pattern Matching
       │ (Validates appIDs array and components/paths routing rules)
                    ▼
Layer 4: Device Association State
       │ (Operating system registers verified domains in local database)
                    ▼
Layer 5: Application Routing Execution
       │ (System routes matching URLs to application lifecycle handlers)

クイック修正チェックリスト：30秒診断ルーチン

Universal Linksが予期せずWebへのフォールバックを行う場合は、次の項目を順番に確認してください。

署名済み識別子の抽出: コンパイルされたバイナリの埋め込み権利（Entitlements）を調べ、正確なapplication-identifier（<Prefix>.<BundleID>）を取得します。
権利フォーマットの検証: com.apple.developer.associated-domainsに、不要なパス、クエリ文字列、末尾のスラッシュを含まない正確なホスト名（例：applinks:subdomain.domain.com）が含まれていることを確認します。
オリジンAASAの監査: https://subdomain.domain.com/.well-known/apple-app-site-associationを取得し、署名済みのアプリケーション識別子がappIDsにそのままリストされていることを確認します。
パス一致の検証: ターゲットURLが、AASA設定で定義されたcomponentsまたはpathsパターンと一致することを確認します。
ドメインスコープの確認: 関連ドメインの権利（Entitlements）がターゲットホスト名をカバーしており、対応するAASA設定がそのホスト名で利用可能であることを確認します。サブドメインの場合は、必要に応じて明示的なホスト名またはサポートされている*.ワイルドカード形式を使用します。
開発モードの切り離し: 開発用署名ビルドで?mode=developerを使用し、イテレーション中のApple CDNキャッシュをバイパスします。

バンドルIDとアプリケーション識別子の正確性が重要である理由

アプリケーション識別子の構造

Universal Linkの検証では、アプリケーションの表示名、内部URLスキーム、バンドル名は評価されません。applinks.Detailsに関するAppleのドキュメントによると、セキュリティモデルは厳密に完全修飾されたアプリケーション識別子に依存しており、次のように構成されています。

\text{Application Identifier} = \text{ApplicationIdentifierPrefix} \;+\; \text{"."} \;+\; \text{CFBundleIdentifier}

ここで：

ApplicationIdentifierPrefix: Apple Developerアカウントの設定で割り当てられたApp IDプレフィックス（例：9JA723G82S）。多くの近代的な開発者アカウントでは、この値は10桁のチームIDと一致しますが、エンジニアは両者が互換性があると憶測せず、Apple Developerポータルで実際のプレフィックスを確認する必要があります。
CFBundleIdentifier（バンドルID）: ターゲットのビルド設定で定義された、大文字と小文字を区別する逆DNS文字列（例：com.example.mobileapp）。

ホストされているapple-app-site-association（AASA）JSONファイル内では、この複合文字列はappIDs配列またはappID辞書エントリ（例：9JA723G82S.com.example.mobileapp）内に表示されます。コンパイルされたバイナリの埋め込み権利とホストされているAASAエントリの間で、文字の不一致、大文字小文字の違い、または末尾のスペースが存在する場合、ドメインの検証は失敗します。

バンドルIDの不一致は、統合トリアージ中に確認すべき最優先事項の1つですが、Universal LinkがWebにフォールバックする原因はそれだけではありません。

障害の症状：識別子の不一致がWebフォールバックを強制する理由

アプリケーション識別子の不一致が発生した場合、iOSは通常、これを致命的なランタイム例外として表面化させません。代わりに、この障害は、関連ドメインの検証状態、デバイスの診断、または結果として生じるWebフォールバックの動作に反映されます。

システムの処理: ドメインの関連付けが失敗した場合、システムは検証済みのUniversal Linkパスを通じてアプリを呼び出しません。URLがどのように開かれたか、および周囲のブラウザのコンテキストに応じて、URLはネイティブアプリケーションに配信されるのではなく、Web処理に留まるか、そこにフォールバックします。
ユーザーエクスペリエンスへの影響: ユーザーがメッセージ、メール、またはSafariで一致するWebリンクをタップしたとき、システムは認可されたネイティブアプリのマッピングを認識できず、ブラウザでWeb URLを開きます。

AppleのCDNがAASAファイルをフェッチおよびキャッシュする仕組み

インストールのハンドシェイクとApple CDNのメカニズム

com.apple.developer.associated-domainsの権利を含むアプリケーションがインストールまたは更新されると、システムは関連ドメインの relacionamento（関係）を確立または更新します。

CDNを介したスクレーパー: システムが関連ドメインの関係を確立または更新すると、Appleの関連ドメインインフラストラクチャを介してドメインのAASAデータを取得し、そのデータを使用して関連付けを検証します。
独立したキャッシュライフサイクル: Appleが管理するCDNは独自の更新およびキャッシュライフサイクルを制御するため、オリジンの更新がCDNを通じてすぐに表示されるようになると想定してはなりません。変更をテストする際は、必要に応じて、文書化された開発用代替モードを使用し、デバイスの関連付け状態を検査してください。
オリジンサーバーの要件: オリジンWebサーバーは、有効で信頼されたTLS証明書（自己署名証明書は拒否されます）を使用し、application/json MIMEタイプを使用して、HTTPS経由でAASAファイルを配信する必要があります。AASAのホスティングはHTTPリダイレクトに依存してはならず、AASAエンドポイントはHTTP 200 OKとともにファイルを直接返す必要があります。

AASA JSONフォーマットの一貫性

最近のiOSバージョンは、従来のpaths配列との下位互換性を維持しながら、詳細なcomponents辞書構文をサポートしています。

Universal Linksのデバッグに関するApple Developer技術ノートTN3155によると、特定のdetailsエントリ内で、開発者は最新のappIDs + components構造、または従来のappID + paths構造を使用する必要があります。混在設定は予期しない検証動作を引き起こす可能性があるため、同じエントリ内で両方の構造を混在させないでください。

古いAASAの例には、一般的に"apps": []が含まれていました。最新のApple OSリリースをターゲットとするデプロイメントでは、このキーは必須ではありません。特定の期待を持つ古いOSバージョンをサポートする場合にのみ保持してください。

診断プロトコル：ステップバイステップの解決ワークフロー

ステップ1：codesignを使用した署名済みアプリの権利の検査

エクスポートされたIPAまたはデバッグビルドに、期待される正確なアプリケーション識別子と関連ドメインが含まれているかどうかを判断するには、macOSのcodesignコマンドラインユーティリティを使用して、バイナリのコード署名を直接検査します。application-identifier、com.apple.developer.team-identifier、およびcom.apple.developer.associated-domainsを一緒に確認します。

プロビジョニングプロファイルは、プロファイルが許可する機能とドメインを示し、署名済み実行可能ファイル（codesign）は、出荷されるバイナリに実際に含まれているものを示します。

ステップ2：ホストされているAASA JSONスキーマの監査

認証やリダイレクトなしでパブリックにアクセスできる有効なAASAファイルがオリジンサーバーでホストされていることを確認します。古いAASAの例には通常"apps": []が含まれていたのに対し、現代のiOSリリースをターゲットとする最新の設定ではこのキーが省略されていることに注意してください。

以下の標準的なAASA JSONスキーマは、最新のappIDsおよびcomponents構造を使用した適切なパスルーティングを示しています。


```json
{
  "applinks": {
    "details": [
      {
        "appIDs": [
          "9JA723G82S.com.example.mobileapp",
          "9JA723G82S.com.example.mobileapp.staging"
        ],
        "components": [
          {
            "/": "/product/*",
            "comment": "Matches product detail routes"
          },
          {
            "/": "/invite/*",
            "?": { "ref": "?*" },
            "comment": "Matches referral links with custom query parameters"
          },
          {
            "/": "/help/*",
            "exclude": true,
            "comment": "Excludes customer support URLs from native routing"
          }
        ]
      }
    ]
  }
}

ステップ3：診断CLIツールの実行（codesign、swcutil、curl）

swcutil診断を提供するmacOSバージョンでは、このツールを使用して関連ドメインデータを検査または検証します。コマンドオプションはOSやツールチェーンのリリースによって異なる場合があるため、以下の診断ワークフローを実行する前に、swcutil --helpで利用可能なオプションを確認してください。

# 0. 利用可能なオプションの確認（構文はOSやツールチェーンのリリースによって異なる場合があります）
swcutil --help

# 1. エクスポートされたIPAアーカイブの展開
unzip -q YourApp.ipa -d UnpackedApp

# 2. 実行可能バイナリから署名済みの権利を直接抽出して検査
codesign -d --entitlements :- "UnpackedApp/Payload/YourApp.app" > signed-entitlements.plist 2>/dev/null
/usr/libexec/PlistBuddy -c "Print" signed-entitlements.plist

# 3. swcutil（macOS診断ツール）を使用して、ドメインのAASAデータをダウンロードできるかどうかを確認
sudo swcutil dl -d custom.opwakeup.com

# 4. swcutilを使用して、特定のURLに対するAASAパターンマッチングを検証
sudo swcutil verify -d custom.opwakeup.com -j ./apple-app-site-association -u https://custom.opwakeup.com/product/123

# 5. Apple管理の関連ドメインCDN診断エンドポイントを直接クエリ
curl -i https://app-site-association.cdn-apple.com/a/v1/custom.opwakeup.com

エッジ配信されたAASAデータのトラブルシューティングを行う際は、Apple管理の関連ドメインCDNエンドポイントを検査します。このエンドポイントは、公開APIコントラクトとしてではなく、診断インフラストラクチャとして扱ってください。

ステップ4：AASAテストへの関連ドメイン開発モードの使用

関連ドメインの設定に関するAppleのドキュメントによると、Appleは開発用の代替モードを提供しています。developerモード（?mode=developer）により、対象の開発デバイスはApple管理のCDNをバイパスし、HTTPS経由で関連ドメインから直接AASAファイルをフェッチできます。

以下の設定は、個別のXcode権利設定で開発モードを宣言する方法を示しています。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.developer.associated-domains</key>
    <array>
        <string>applinks:custom.opwakeup.com</string>
    </array>
</dict>
</plist>

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.developer.associated-domains</key>
    <array>
        <string>applinks:custom.opwakeup.com?mode=developer</string>
    </array>
</dict>
</plist>

オペレーティングシステムがドメインの関連付けを確立すると、アプリケーションレベルのルーティングは、標準のUIKitまたはSwiftUIライフサイクルデリゲートを使用して着信URLペイロードを処理します。

import UIKit

// ----------------------------------------------------------------------------
// 1. UIKit AppDelegate Implementation
// ----------------------------------------------------------------------------
@main
class AppDelegate: UIResponder, UIApplicationDelegate {

    var window: UIWindow?

    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        return true
    }

    // Standard Apple Universal Link Continuation Callback
    func application(
        _ application: UIApplication,
        continue userActivity: NSUserActivity,
        restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void
    ) -> Bool {
        
        guard userActivity.activityType == NSUserActivityTypeBrowsingWeb,
              let incomingURL = userActivity.webpageURL else {
            return false
        }
        
        print("Handling verified Universal Link: \(incomingURL.absoluteString)")
        
        // Dispatch incomingURL to internal router or SDK layer for parameter extraction
        return handleIncomingRoute(incomingURL)
    }

    private func handleIncomingRoute(_ url: URL) -> Bool {
        // Application-level destination routing logic
        // Note: Returning true indicates the app handled the activity, not that URL parsing succeeded.
        return true
    }
}

// ----------------------------------------------------------------------------
// 2. SceneDelegate Lifecycle Implementation (iOS 13+)
// ----------------------------------------------------------------------------
class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var window: UIWindow?

    func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
        if let userActivity = connectionOptions.userActivities.first(where: { $0.activityType == NSUserActivityTypeBrowsingWeb }),
           let incomingURL = userActivity.webpageURL {
            print("Cold-launch Universal Link: \(incomingURL.absoluteString)")
        }
    }

    func scene(_ scene: UIScene, continue userActivity: NSUserActivity) {
        if userActivity.activityType == NSUserActivityTypeBrowsingWeb,
           let incomingURL = userActivity.webpageURL {
            print("Foreground Universal Link: \(incomingURL.absoluteString)")
        }
    }
}

物理ハードウェアでクライアント側の開発モードを有効にするには：

iOS 16以降で、[設定] > [プライバシーとセキュリティ] > [開発者モード] に移動し、オンに切り替えます（デバイスの再起動が必要です）。
[設定] > [開発者] > [関連ドメインの開発（Associated Domains Development）] に移動し、スイッチをオンにします。
?mode=developerの権利を含む開発用プロビジョニングプロファイルで署名された開発ビルドをインストールします。
本番環境に関する注意: ?mode=developerは開発および内部テストの設定に限定し、デプロイメントでその設定が明示的に必要かつサポートされていない限り、本番環境の関連ドメイン権利に含めないようにしてください。

根本原因の決定木

Universal Link falls back to web handling
        │
        ├── Does signed application-identifier match AASA appIDs?
        │       ├── NO ──> Correct App ID Prefix or Bundle ID in AASA
        │       └── YES
        │
        ├── Does associated-domains entitlement list the exact domain?
        │       ├── NO ──> Add applinks:<domain> to target entitlements
        │       └── YES
        │
        ├── Does sudo swcutil dl -d <domain> succeed?
        │       ├── NO ──> Fix origin HTTPS, TLS certificates, or 301/302 redirects
        │       └── YES
        │
        ├── Does sudo swcutil verify match the target URL path?
        │       ├── NO ──> Correct components or paths syntax in AASA
        │       └── YES
        │
        └── Check device association state and internal application routing handlers

診断マトリックス：Universal Linkの失敗の根本原因

障害モード	根底にある根本原因	観測されるシステムの動作	推奨される修復方法
バンドルIDの入力ミス	AASAの`appIDs`における大文字小文字の区別または文字の不一致	ネイティブアプリの代わりにリンクがブラウザを開く	AASA JSONの文字列を修正し、オリジンに再デプロイする
App IDプレフィックスの不一致	実際のDeveloper App IDプレフィックスの代わりに誤ったプレフィックスを使用している	インストール時にドメインの関連付けが失敗する	Appleメンバーセンターでアプリケーション識別子プレフィックスを確認する
サブドメインの不一致	権利が`www.example.com`を指しているのに対し、AASAは`example.com`にある	アプリがサブドメインからのリンクの取得に失敗する	クレームされた各サブドメインで専用のAASAファイルをホストするか、ワイルドカードを設定する
エンドポイントでのHTTPリダイレクト	オリジンサーバーがAASA URLに対して301または302リダイレクトを返す	Apple CDNスクレーパーがAASAファイルを拒否する	200 OKを直接返すようにWebサーバーを設定する
AASAフォーマットの不整合	レガシーの`appID`/`paths`と最新の`appIDs`/`components`の混在	パスの一致が一貫しない、または部分的なものになる	最新の`appIDs` + `components`構文に標準化する
URLパターンの不一致	AASAは正常にダウンロードされるが、リクエストされたURLがパターンと一致しない	リンクがWebブラウザで開く	`swcutil verify`を使用してパスの構文とコンポーネントを確認する
リリースに開発モードが残っている	配信ビルドが開発用の代替モードを保持している	配信ビルドにおける非標準の権利	リリースビルドの設定から`?mode=developer`を削除する

温かみのあるクリーム色のグリッド背景に、明確なステータスバッジを備えたiOS Universal Linkの障害モード、根本原因、システムの動作、および修復手順を示す、国際的なエンタープライズ向け比較マトリックスチャート。

Xcodeでのデュアル環境設定の実装

複数のビルド設定の管理（Debug、Staging、Production）

エンタープライズ開発パイプラインでは、ビルド環境間で異なるバンドルID（例：com.example.app.debug、com.example.app.staging、com.example.app）を頻繁に管理します。

すべてのビルド設定で機能するUniversal Linksを維持するには：

明示的なAASA宣言: ホストされているAASAファイルは、appIDs配列内で各環境の完全修飾アプリケーション識別子を明示的にリストする必要があります。
```
"appIDs": [
  "9JA723G82S.com.example.app",
  "9JA723G82S.com.example.app.staging",
  "9JA723G82S.com.example.app.debug"
]
```
ターゲット固有の権利（Entitlements）: Xcodeのビルド設定を使用して、ビルド設定ごとに個別の.entitlementsファイルをリンクし、内部のデバッグビルドによって本番ドメインがクエリされないようにします。

ターゲット識別子の管理

Universal Linksのトラブルシューティングでは、ワイルドカード識別子に頼るのではなく、署名済みビルドからの正確なバンドルIDとアプリケーション識別子プレフィックスを使用します。各ホスト名を明示的に扱います。アプリがexample.comおよびwww.example.comをクレームする場合、対応する関連ドメインのエントリを設定し、各ホスト名が適切なAASAデータを確実にサーブするようにします。Universal Linksを実際に処理するターゲットに権利が設定されていることを確認し、該当する場合はアプリ拡張機能やwatchOSのターゲットを個別に検証してください。

CI/CDでの埋め込みプロビジョニングプロファイルと署名済みバイナリの検証

バイナリをTestFlightにアップロードする前に、継続的インテグレーション（CI）ビルドスクリプト内で権利とアプリケーション識別子の検証を自動化します。

# Automated CI validation script
security cms -D -i /path/to/embedded.mobileprovision > provision.plist

# 1. Inspect profile entitlements for allowed Associated Domains
/usr/libexec/PlistBuddy -c "Print :Entitlements:com.apple.developer.associated-domains" provision.plist

# 2. Extract actual signed entitlements from the compiled executable binary
codesign -d --entitlements :- "UnpackedApp/Payload/YourApp.app" > signed-entitlements.plist 2>/dev/null
SIGNED_APP_ID=$(/usr/libexec/PlistBuddy -c "Print :application-identifier" signed-entitlements.plist)
echo "Extracted Signed Application Identifier: $SIGNED_APP_ID"

# 3. Validate that signed Associated Domains match the target domain
/usr/libexec/PlistBuddy -c "Print :com.apple.developer.associated-domains" signed-entitlements.plist

# 4. Verify that the signed App ID exists in the hosted AASA file via Python
python3 -c "
import json, sys
signed_id = sys.argv[1]
data = json.load(open('apple-app-site-association'))
app_ids = [app for detail in data.get('applinks', {}).get('details', []) for app in detail.get('appIDs', [])]
if signed_id not in app_ids:
    print(f'AASA mismatch: {signed_id} not found in AASA appIDs: {app_ids}')
    sys.exit(1)
print(f'AASA consistency check passed: {signed_id} registered')
" "$SIGNED_APP_ID"

検証スクリプトがエラーコードで終了した場合は、ビルドパイプラインを中止して、機能しないディープリンクバイナリの本番環境への出荷を防ぎます。

温かみのあるソフトクリーム色のグリッド背景に、CI/CDビルドパイプラインでのiOS Universal Link App IDおよびAASA検証を自動化するための国際的な4ステップの開発者ワークフローフローチャート。

Universal Linkの一致基準

信頼性の高いルーティングを確保するには、次の条件を同時に満たす必要があります。

Signed App Configuration:
application-identifier = <ApplicationIdentifierPrefix>.<CFBundleIdentifier>
com.apple.developer.associated-domains = applinks:<hostname>

AASA Configuration:
appIDs = [..., "<ApplicationIdentifierPrefix>.<CFBundleIdentifier>", ...]
components / paths = Matching target URL paths and query parameters

System Eligibility:
1. Associated Domains entitlement explicitly contains the target hostname.
2. The signed Application Identifier matches an authorized entry in the domain's AASA appIDs.
3. The incoming URL satisfies the AASA routing patterns.
4. Device association state and user/browser context permit native application delegation.

権利、AASAの関連付け、およびURLパターンがすべて一致している場合でも、観測されるルーティングはデバイスの状態やユーザー/ブラウザのコンテキストによって依然として左右される可能性があります。たとえば、ユーザーがSafariで同じドメインをすでに閲覧しているときにユニバーサルリンクをタップした場合、オペレーティングシステムはSafariにとどまるというユーザーの意図を尊重することがあります。

よくある質問（FAQ）

AASAファイルにおけるアプリケーション識別子の正確なフォーマットは何ですか？

アプリケーション識別子は、厳密に `<ApplicationIdentifierPrefix>.<CFBundleIdentifier>` の形式である必要があります。ここで、`<ApplicationIdentifierPrefix>` はApple Developerアカウントでアプリケーションに関連付けられているApp IDプレフィックス（例：`9JA723G82S`）であり、`<CFBundleIdentifier>` はバンドルID（例：`com.example.app`）であり、結果として `9JA723G82S.com.example.app` になります。プレフィックスが常にチームIDと同一であると仮定しないでください。アプリのプロビジョニングプロファイルから値を確認してください。

Universal Linkが開発モードでは機能するのに、本番環境では失敗するのはなぜですか？

開発モード（`?mode=developer`）を使用すると、対象の開発デバイスはApple管理のCDNをバイパスし、HTTPS経由でオリジンWebサーバーから直接AASAファイルをフェッチできます。本番環境でUniversal Linksが失敗する場合、一般的な原因には、オリジンサーバーでの無効なTLS証明書、AASAエンドポイントでのHTTPリダイレクト、またはAppleのCDNスクレーパーによって拒否されたフォーマットエラーを含む本番用AASAペイロードが含まれます。

AASAのappIDs配列でワイルドカードのアスタリスクを使用できますか？

Universal Linksのトラブルシューティングでは、署名済みアプリからの明示的なアプリケーション識別子（`<App ID Prefix>.<Bundle ID>`）を使用し、その識別子をAASA設定で宣言してください。アプリケーションの実際の識別子の代わりとしてワイルドカードを使用しないでください。

まとめと決定フレームワーク

Universal Linkのルーティングの信頼性は、Apple DeveloperポータルのApp ID設定、Xcodeのcom.apple.developer.associated-domains権利、およびホストされているapple-app-site-association JSONファイルの3つのノードにわたる、文字レベルでの正確な整合性に依存しています。サードパーティのSDKやルーティングフレームワークは、失敗したオペレーティングシステムのドメイン関連付けを修復することはできません。iOSがUniversal Linkをアプリケーションに正常に配信した後にのみ、URLを処理できます。Universal Linksがオペレーティングシステムレベルで正しく関連付けられているにもかかわらずパラメータの抽出に失敗する場合は、ドメインの関連付けレイヤーとは別に、アプリケーションレベルのルーティングレイヤーを検査してください。

アプリケーションがUniversal Linkの関連付け成功後に追加で動的リンクパラメータの復元やオンボーディングルーティングを必要とする場合、OpoInstallはそのアプリケーションレベルのワークフロー向けにオプションのSDKレイヤーを提供しています。

ドメイン設定パターンとディープリンクの統合の詳細については、OpoInstallディープリンクドキュメントをご確認ください。