12

I am registering an application to handle being opened via URL and am confused with

application:openURL:sourceApplication:annotation

According to the documentation you should return YES if you can support the URL and NO if not. What good does this do though? I am returning NO in the event that the URL is malformed or unsupported but the app still opens as if nothing went wrong. Who listens for that BOOL return and what do they do with it? Is there anyway to prevent the app from opening if the URL is is malformed or not supported?

Cœur
  • 37,241
  • 25
  • 195
  • 267
Chris Wagner
  • 20,773
  • 8
  • 74
  • 95

1 Answers1

6

The documentation says that you return YES if you successfully opened the URI and NO if you didn't. Note that "did succeed or did fail to open" is semantically different from "can or cannot open". Unfortunately, there's no way to prevent the app from launching - if it registers a schema then it will be launched regardless of whether the rest of the URI is correctly formatted.

UIApplication has two methods: canOpenURL: and openURL:. First one ONLY checks whether the schema is supported (not the full URL), where's the latter launches the app and returns the result of the application delegate.

So to answer your question: the other app who calls [[UIApplication sharedApplication] openURL:url] is the one who listens to your delegate's result

Nick
  • 2,626
  • 1
  • 26
  • 29
  • Interesting, so when/how should the other app respond to the response? At that point the user is in the app that does not know how to handle the passed URL – Chris Wagner Aug 09 '12 at 23:53
  • That's correct. At that point the user is in the other app and won't get back into yours unless the other app specifically launches yours or the user switches back manually. I'm not sure what their intentions were creating this API, but I assume it was created primarily for communication between apps of the same developer who "play nicely" with each other. This is a guess, I don't think you can find documentation on why Apple has this approach. It could also be just outdated API that was "the best they could do" on top of legacy versions of iOS. – Nick Aug 13 '12 at 19:15
  • 1
    That's a fair assumption. Thanks for the input, I'll mark this as answered with the belief that it's mostly a useless return value. – Chris Wagner Aug 13 '12 at 21:54
  • 4
    Just tested: app A launches app B. B returns `NO` from `application:openURL:options:`. In `openURL:options:completionHandler:`, app A still receives a `success=YES`. So the return value of the launched app is not sent back to the calling app. – Ortwin Gentz Oct 22 '20 at 09:01