App clip cards are not being displayed correctly according to the url prefixing documentation which states: "The system then chooses the App Clip experience with the URL that has the most specific matching prefix." This video also outlines the same strategy for invoking different app clip cards with a matching prefix (start video at 12:46).   I have the following two advanced app clip experiences associated with my app:  https://example.com/card1 -> opens correctly https://example.com/card1/subcard1-> opens same card as above Even though the second experience has a more specific url, it's still opening the app clip experience for the shorter url. Both app clips were submitted over a week ago at the same time, so I don't believe it's a propagation issue.

In December 2020, I launched my first app that uses app clips. Since that time, I've had to reluctantly explain over 60 times that the notification-like banner, which appears when an app clip loads, cannot be removed. This banner, to which I'm referring, appears as the app clip fills the screen and persists for about 5 seconds. iPhone users, conditioned to click notifications, often mistake this banner as something that needs to be tapped to proceed. This misstep inadvertently takes them away from the app clip. The fact that this banner appears during the initial in-flight API calls exacerbates the number of users who incorrectly end up on the app store download page. App clips offer a full-screen, engaging native iOS experience without the need for a cumbersome app store download. However, if 5-10% of customers end up on the app store download page, it undermines the benefits for the remaining 90-95%, and brings into question whether a webpage would be a more optimal solution. App clips are designed to address use-cases where downloading an app is an unrealistic expectation. In the scenarios I service, the idea of downloading a full app stops the customer interaction immediately. If a customer ends up at the app store download page, they often won't download the app just to look at a menu, but rather complain to the server and request a paper menu. One of my initial customers was a restaurant in my hometown. At the peak of summer, they were receiving over 500 scans a night. Invariably, a subset of customers would ask the staff why they needed to download an app to see the menu. This daily occurrence led the restaurant to remove my QR menus from their tables. Another downside of the 'Powered by …' popover banner is that it deprives the owner of the advanced app clip experience of their branding. The larger the brand, the more off-putting it is for them to see what looks like us trying to advertise our own brand to their customers. When customers reach a point in their app clip journey where they need to download our full app, we have SKOverlay to prompt them. The default popover is redundant and limits our strategic approach to asking them to transition. It’s similar to asking a user for push notification permissions at app startup, instead of the moment when they understand why they need them. I've been one of the biggest advocates of app clips since their inception and have had hundreds of ground-level conversations about their implementation in the real-world. The popover is detrimental to our efforts. Please consider removing it and let us show the upgrade option when the user understands why they’re doing it. Thanks for your consideration.

Do you have intention to support App Clip Smart App Banners in WKWebView in the future?