Prompt
Use the Linking API to open a URL "https://example.com" in the device browser. Check if the URL can be opened first, and if not, log an error.
Solution
Linking is the outbound half of deep linking: it hands a URL to the operating system, which routes it to whatever app claims the scheme — browser for https, Mail for mailto:, the phone app for tel:, another app entirely for custom schemes like spotify:. The check-before-open pattern exists because that routing can fail: no handler for the scheme means openURL rejects, and canOpenURL lets you degrade gracefully — hide the button, show a fallback — instead of throwing at tap time.
The trap that makes this an interview question rather than a docs recital: canOpenURL lies for custom schemes unless you declare them. Since iOS 9, querying another app's scheme requires listing it under LSApplicationQueriesSchemes in Info.plist (Android 11 added similar package-visibility rules); undeclared, canOpenURL returns false even when the app is installed. Plain https is always queryable, which is why this example works unconditioned — but "why does canOpenURL return false for whatsapp://" is the production bug behind the question. Both calls are async and can reject, so real code wraps them in try/catch; and the companion API worth naming is Linking.openSettings(), the sanctioned deep link into your app's own settings page for permission-blocked flows.
Red flag: treating a canOpenURL false as "app not installed" without mentioning the Info.plist declaration — that's the exact misdiagnosis the platform docs warn about.
Say it: "Linking delegates URL handling to the OS — I check canOpenURL first for graceful fallback, and I know custom schemes must be declared in LSApplicationQueriesSchemes or the check returns false even when the app exists."