bump. Is Apple listening?

Yes. Not sure. Re-downloaded.

I think this is a bug. The link you included states "Upon launch, the App Clip receives a URL, then extracts path components and query parameters", but the example given only includes path components. Additional query parameters shouldn't be a problem. Specifically, I think the bug happens when your invocation URL already includes query parameters. Until when or if it's fixed, I would suggest removing the query parameters from your invocation URL or turn them into path components if possible.

@Elena, If you want your app clip to be invoked via the Messages app, the page at the invocation (sent) URL must contain app clip metadata. This is not a requirement for app clips to be invoked by QR codes, however. Not sure how a gradual release of your app would affect app clips, if at all.

I thought "cpserrordomain error 2" (which I've seen several times recently) was only for NFC tags, not QR codes. And just to check - the meta tag on the web page contains app-clip-bundle-id=appClipBundleID and the app clip bundle ID is not an app ID and typically starts with "com."

This may help: https://github.com/home-assistant/iOS/issues/1194

Not sure what you are asking. When I open an app clip via a QR code, take a few actions in the app clip, close (not quit) the app clip, then re-open the app clip, the app clip's state will be where I left it. Instead, if I quit the app clip (swipe up), then re-open the app clip, it will start over using the original invocation QR code. That's the behavior I would expect. I suppose it could restart using the default invocation URL, but that's not the way it works.

I have no idea what the problem is or what you are asking.

Hi @againwithanaccount, In my experience, this requirement: The webpage being shared must contain the requisite metadata for the Smart App Banner for app clips is not required for QR codes via the Camera app or Control Center QR Scanner, but is required for the Messages app. If your URL works as a QR code but not when sent in Messages, this is likely the problem. In my case, the URL was being redirected to another page the didn't have the required metadata. Note that the Messages web user agent does not contain "iPhone" when it visits the URL to determine if there is an app clip to be shown, which is good in my case since my URL will redirect the user to the app in the app store when the user agent contains "iPhone" -- for iOS 13 and below.

So I looked at the user agent when iMessages queries my invocation url for the smart banner and app clip. The good news is that it is significantly different than when iOS Safari loads the same url. iMessages: Mozilla/5.0 (Macintosh; Intel Mac OS X 10111) AppleWebKit/601.2.4 (KHTML, like Gecko) Version/9.0.1 Safari/601.2.4 facebookexternalhit/1.1 Facebot Twitterbot/1.0 iOS Safari: Mozilla/5.0 (iPhone; CPU iPhone OS 14_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Mobile/15E148 Safari/604.1 Based on this, it's very easy to have an invocation url open the app clip by scanning a QR code or in iMessages for iOS 14+ users, but have the same url redirect iOS 13- users to the app in the App Store. Thanks again for your help, @liazkam.

@liazkam Thanks, that helps, but seems to be an unnecessary requirement at least to me, especially since it's not a requirement for QR codes. Maybe an Apple engineer determined it would eliminate a call to Apple if iMessage could first detect the presence of an app clip while it was already examining other meta-data for the App Banner. I'm going to have to examine the http request to see if there's any difference between when it comes from Safari vs. iMessage to determine if the redirect to the App Store should happen. Otherwise, this iOS 13/14 "trick" will never work.

"The message sharing only works for sharing a link to a website that has Safari Smart App Banner integrated on it. Links to a webpage cannot just be shared in a message." This may explain my problem. In my case, I have an invocation URL (and deep link) such as: https: //mywebsite/thing/<id> The link should display an App Clip card if iOS 14+, but if iOS 13 or lower, using/clicking the link should display the app in the App Store via a website redirect based on the device User-Agent. This is exactly what happens if the invocation URL is a QR code. Are you saying the invocation URL sent to iMessage doesn't display the App Clip card because https: //mywebsite/thing/<id> doesn't have meta data to support a Safari Smart App Banner?

Have you tried adding a corresponding app link? https://developer.apple.com/documentation/safariservices/supporting_associated_domains { "appclips": { "apps": ["Z7Z74TFKB7.com.efrac.tunerios.Clip"] }, "applinks": { "apps": [], "details": [ { "appID": "Z7Z74TFKB7.com.efrac.tunerios.Clip", "paths": ["/path/to/experience/* "] } ] } }

I'm having the same problem. I've have a beta profile installed (though I'm using the GM 14 right now) and cannot figure out how to install the Feedback Assistant app. This link (https://developer.apple.com/bug-reporting/) points to the website to report bugs but there's no link to install the app. When I try to use the website, the header is "Where would you like to start your feedback?" but the text says I can't start my feedback. Can @apple provide the steps? Thanks!

Hi Apple Staff, "These edits will not be immediate as the changes must first be reviewed and then pushed live." I did not realize there is a review process for app clip experiences, but it does make sense and seems to be indicated by the "Received" status in the Advanced App Clip Experiences page. However, my app clip works, but it's still in the "Received" status. I understand from an early video that the status should (after review?) eventually be "Published." Will we see "Published" statuses so we know when new or changed app clip experiences have been approved? Thanks.