3 ms·

This is not the default behavior for a UIWebView. It relies on a practice that is very common among developers of iOS apps with web content. Specifically: ever

This is not the default behavior for a UIWebView. It relies on a practice that is very common among developers of iOS apps with web content. Specifically: every click/interaction that loads content in your custom web view sends the webView:shouldStartLoadWithRequest:navigationType: message to your web view delegate. Without implementing that method, clicking a tel: link will prompt first. However, many apps throw some logic in there to detect any URI schemes that don't match the standard HTTP/HTTPS schemes used in normal websites, and trying to do something "nice" for the user, they handle requests for those URIs by calling: [[UIApplication sharedApplication] openURL:request.URL]; This is a reasonable thing to do (outside the context of tel: links) because it allows the app to spawn an external app for custom URIs. Therein lies the problem: not that UIWebView opens tel: links without prompting (it doesn't), but that many app developers are just trying to improve the inter-app experience, and unknowingly open tel: links directly with that openURL: method. EDIT: Just my opinion, but I think it's actually pretty cool that Apple gives developers the ability to dial phone numbers without an extra prompt. It makes third-party contact/phone apps much more useful (imagine having to confirm every phone number to dial after tapping the contact in the built-in phone app). In a way, this is the kind of trust / freedom that iOS developers rarely enjoy without a fight. It's just unfortunate that in this instance, it also happens to be very easy to overlook this pitfall when implementing web view logic that handles non-http links.

chaitanya 12y ago
While tel:// URLs open the Phone app without any prompt, there's also a telprompt:// scheme which opens the Phone app with a prompt. As an app developer, would you ever want to use the latter scheme instead of the former? Turns out, yes, you would. The advantage that you get with telprompt:// is that, once the call finishes, the user comes right back into the app that initiated the call. With tel:// that is not the case.
- kenrikm 12y ago
  Indeed I almost always use telprompt:// over tel:// for exactly that reason. It's usually better to bring them back into the app when the call finishes.

chaitanya 12y ago

While tel:// URLs open the Phone app without any prompt, there's also a telprompt:// scheme which opens the Phone app with a prompt. As an app developer, would you ever want to use the latter scheme instead of the former? Turns out, yes, you would. The advantage that you get with telprompt:// is that, once the call finishes, the user comes right back into the app that initiated the call. With tel:// that is not the case.

kenrikm 12y ago
Indeed I almost always use telprompt:// over tel:// for exactly that reason. It's usually better to bring them back into the app when the call finishes.