admin管理员组

文章数量:1392098

I'm implementing an App Clip experience that should trigger when a user receives a link like base_url/msg/* in iMessage. The expected behavior is that the App Clip shows a preview card in iMessage and, upon clicking, invokes the advanced App Clip experience.

My main app is hosted on Firebase via a Flutter app (with a domain like app-name.firebaseapp), while my Next.js app handles the /.well-known/apple-site-association file needed for Universal Links and App Clips. App Clip is coded in SwiftUI and verified to work and run on a physical device -- also tested it runs when launched with base_url/msg/45.

What I've Tried

• Serving the AASA File: I'm hosting the apple-site-association file in my Next.js app using an API route. The file is accessible at base_url/.well-known/apple-site-association.

Example code snippet:

// api/apple-app-site-association/route.js
import { NextResponse } from 'next/server';

export async function GET() {
  const aasaContent = {
    applinks: {
      details: [
        {
          appIDs: ["TEAM_ID.example.appname"],
          components: [
            { "/": "/msg/*", "comment": "Matches any URL starting with /msg/" },
            { "/": "/msg*?*", "comment": "Matches URLs with query parameters" }
          ]
        }
      ]
    },
    appclips: {
      apps: ["TEAM_ID.example.appname.Clip"]
    },
    webcredentials: {
      apps: ["TEAM_ID.example.appname"]
    }
  };

  return NextResponse.json(aasaContent, {
    headers: { 'Content-Type': 'application/json' },
  });
}

Next.js Rewrites and API Routing:

• In next.config.js, I've set up rewrites so that requests to /.well-known/apple-site-association route correctly to the API route, and /msg/:path* routes to an API that fetches content from Firebase and injects the required meta tag.

Relevant excerpt from next.config.js:

async rewrites() {
  return [
    {
      source: '/.well-known/apple-site-association',
      destination: '/api/apple-app-site-association',
    },
    {
      source: '/msg/:path*',
      destination: '/api/msg/:path*',
    },
    {
      source: '/:path*',
      destination: '/:path*',
    },
  ];
},

Branch.io Validation: When validating via Branch.io, I receive no result, while checking the Apple CDN URL (like /...) shows the expected JSON response.

{
  "applinks": {
    "details": [
      {
        "appIDs": [
          "TEAM_ID.example.appname"
        ],
        "components": [
          {
            "/": "/msg/*",
            "comment": "Matches any URL with a path that starts with /msg/"
          },
          {
            "/": "/msg*?*",
            "comment": "Matches URLs with query parameters"
          }
        ]
      }
    ]
  },
  "appclips": {
    "apps": [
      "TEAM_ID.example.appname.Clip"
    ]
  },
  "webcredentials": {
    "apps": [
      "TEAM_ID.example.appname"
    ]
  }
}

Expected vs. Actual Outcome

Expected: The AASA file is correctly served from my Next.js app, allowing the App Clip to be triggered from URLs under /msg/\*, with the preview card showing in iMessage.

Actual: Branch.io validation doesn't return the expected content, which may indicate that something is misconfigured in how the AASA file is served or routed.

When sending the link in Messages (e.g., https://base_url/msg/45), nothing happens—no preview is shown and the app clip does not launch.

The Advanced App Clip experience is configured with the URL https://base_url/msg (with TestFlight configured for https://base_url/msg/*). Advanced App Clip experience doesn't let me configure for https://base_url/msg/ or wildcard.

Local experiences in phone's developer settings for a specific invocation (https://base_url/msg/45) are also not triggering the expected preview or app clip launch.

The AASA file has passed validation using yURL’s Universal Links / AASA File Validator tool.

Questions

• What could be causing the AASA file to be undetectable via Branch.io validation, despite being accessible via the Apple CDN URL?
• Are there specific considerations when serving the AASA file via Next.js API routes and rewrites that might affect its delivery to Apple's services?
• How can I troubleshoot or verify that the URL rewrites and content delivery are configured correctly?

本文标签：