This is also happening for me. I noticed that in the Console, the following error appeared from com.apple.weatherkit.authservice: Failed to retrieve application-identifier from SecTask. This typically indicates that the process is missing the application-identifier entitlement. It must match the process' bundle identifier. This is a client-issue. Check the crash report for the Coalition process. PID: 34670 I've double-checked that my provisioning profile does include the application-identifier entitlement (which is the only place this particular entitlement appears, as far as I can tell). Interestingly if I download the FlightPlanner sample app from the developer documentation, I get an entirely different error: 2022-09-13 19:06:54.349898-0400 FlightPlanner[34598:380317] [WeatherService] Encountered an error when fetching weather data subset; location=<+42.56030000,+18.26220000> +/- 0.00m (speed -1.00 mps / course -1.00) @ 9/13/22, 7:06:54 PM Eastern Daylight Time,  error=Error Domain=AMSErrorDomain Code=12 "Mescal Failed" UserInfo={NSLocalizedDescription=Mescal Failed, NSLocalizedFailureReason=SAPInit failed: -42049} I made sure to carefully follow the directions listed in the developer documentation, and waited well more than 30 minutes between creating the App ID and running the app. The Console has a bunch of different messages & errors: Retrieved application-identifier from SecTask: applicationID=***...XXXXXX.FlightPlanner Processed teamID from application-identifier: teamIDIsValid=YES bundleID=XXXXXX.FlightPlanner AMSMescalFairPlay: [AA41C52C] Init failed: { Error domain=AMSErrorDomain, code=12 Error while creating local signature. requestIdentifier=3E73E504-550D-44F5-8940-BD272B02B10E, error=Error Domain=AMSErrorDomain Code=12 "Mescal Failed" UserInfo={NSLocalizedDescription=Mescal Failed, NSLocalizedFailureReason=SAPInit failed: -42049}

I've found the answer to my own question. Re-watching the WWDC'19 video "What's new in Universal Links", there was a tidbit mentioned: Query items with no value and absent query items are treated by the operating system as if they have a value equal to the empty string. I haven't seen this documented anywhere else, but to assert the presence of the app parameter correctly you must use: { &#9;&#9;"/": "/login/magic/*", &#9;&#9;"?": { "app": "?*" }, } By requiring it to match at least one character forces the parameter to actually be a part of the URL. It's not clear how you would positively match a parameter that had no value. Luckily that doesn't apply in my case!

I think you're probably out of luck because those "query parameters" are really parsed as part of the URL's fragment: let components = URLComponents(string: "https://example/#/user?id=ABC123") dump(components) ▿ https://example/#/user?id=ABC123   - scheme: "https"   - host: "example"   - path: "/"   - fragment: "/user?id=ABC123"