Not just chrome on android! Chrome on desktop has the same behavior as well when desktop PWAs are installed (it shows the native experience for in-scope links). I’m not 100% sure whether this behavior is mediated by the operating system or the browser—my guess is that it varies between operating systems. Given that, and the deep links section of the manifest, I think your Goals 1-6 are already handled by the spec, so you might want to rewrite the Introduction and Goals section to focus on use-cases that aren’t already enabled by the existing platform.
This is good context, thank you! I didn’t see anything about this goal or about sw-launch in the explainer, that would be very good context to add—you should probably add both a high-level problem statement that addresses this and concrete example use cases to the explainer. Additionally, it would be great to explain why you think your solution is better suited to address this problem then sw-launch, or at least how you see your two solutions interacting, so developers aren’t confused by having two solutions to solve the same problem.
Yeah, I saw that in the explainer, but I wasn’t sure if it was core to your spec since it wasn’t mentioned in your goals section or your problem statement. I think this behavior adds a lot of complexity to the proposed solution, and I’m not sure how it would interact with the other parts of the spec. While you’re right that the Web App Manifest spec doesn’t forbid it, a close reading does present some complications:
If an application context is created as a result of the user agent being asked to navigate to a deep link, the user agent MUST immediately navigate to the deep link with replacement enabled. Otherwise, when the application context is created, the user agent MUST immediately navigate to the start URL with replacement enabled.
This wouldn’t fall under the first
if statement, since
deep links are defined to be in-scope links, and it would be handled by the
Otherwise, case. So when launching an out of scope link, the user agent would have to immediately navigate to the
start URL, making it impossible for the web app author to tell which out-of-scope link was handled, or do any specific behavior based on the out of scope link.
This section could be amended, of course, but given that the use-cases you provided in the introduction and goals section, the whole thing (adding a well-known route, adding a file format, adding a whole life-cycle of site association renewal) seems like a lot of complication for very little benefit.