canOpenURL returned an incorrect result in iOS 15 run in Xcode13

I don't know whether it is a system bug or a new rule.

Honestly, that doesn’t matter. If something is causing you grief in a beta OS release you should file a bug about that. If it’s a new rule the bug will come back as ‘behaves correctly’, hopefully with an explanation of that rule. You can then file a new bug against the documentation (-:

Please post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

The canOpenURL is still broken even built the app with Xcode 13 RC on iOS 15 RC.

@eskimo  I also have the same problem on iOS 15 RC and Xcode 13 RC. I filed a bug report for FB9447186.

I filed a bug report for FB9447186.

Thanks.

Reading your bug report it seems that you’ve determined that there’s a threshold of 50 URL schemes. Is that right?

Honestly, I don’t know what’s up with that. My suggestion is that you open a DTS tech support incident and talk to DTS’s expert in this field. At a minimum, we should be able to find out whether this 50 URL scheme limit is deliberate or not.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks for your reply.

Reading your bug report it seems that you’ve determined that there’s a threshold of 50 URL schemes. Is that right?

Yes, that’s correct. I tested with a small sample project attached on the FB.
The problem is that the behavior is different among iOS versions (iOS 15 and others) and I cannot find any documentations related to this. So I suspect this should be a bug on iOS 15.

Same problem here, glad to see I am not the only one running into this issue, but it also completely ruins the primary function of our application.

Our application indexes content on streaming services and deeplinks into their respective applications. With the industry's shift to universal links we very frequently only have a web url for the content.

• If we just simply open the web url we get rejected for circumventing the In App Purchases ToS
• If we filter out universal links and just pray that the other deeplinks work we get rejected for an incomplete app. "Use StoreKit if the application is not installed."
• And now we can not check the installed status of any of these applications either since we have too many registered query schemes

So there is legit not a single route we can take that conforms to all the rules and guidelines. Sounds an awful lot like our application is just not allowed to exist.

Time to request technical assistance and hope for the best I guess.

Hi all,

I’ve got another message on my FB, saying
‘This is an intentional change for privacy to reduce the ability of apps to determine what other apps are installed.’

And I also realized that the API documentation has been also updated related to this topic in Important note.
’Apps linked on or after iOS 15 are limited to a maximum of 50 entries in the LSApplicationQueriesSchemes key. ‘

This causes big trouble for our "Where To?" app. Our POI finder app links to more than 80 different apps to get directions. The app's core functionality is POI search. To offer turn-by-turn directions or directions including ticket purchase for public transport, we link to third party apps. Currently, we support more than 80 apps. Some apps have country-based URL schemes, so we have a total of 230 entries in LSApplicationQueriesSchemes.

We need the canOpenUrl API to determine if we can offer a 3rd party directions app as "installed" or whether we should link to the App Store instead (using SKStoreProductViewController).

While I understand your goal to limit fingerprinting, in our case, a totally valid use case is destroyed by this policy. We feel that linking to 3rd party apps creates a vibrant ecosystem of apps working together and focusing on their respective core competencies. Such a business model should not be punished just because there might be some apps abusing the API for finger printing purposes.

We suggest to solve the problem in App Review instead. You could install a new rule that entries in LSApplicationQueriesSchemes must not be used for fingerprinting purposes and each entry must be linked somewhere from the app. Then it would be possible to reliably link to 3rd party apps and prevent abuse at the same time. An additional entitlement permitting a larger limit would also be possible though not needed in our view.

Logged as FB9660602.

I second the comment of ortwin. I use the same mechanism to find available directions apps which I can offer to the user requesting directions.