FB9240072: MFMailComposeViewController should provide an interface to the default email client, not just Mail

I just filed “suggestion” feedback FB9240072 with Apple on the MFMailComposeViewController in UIKit.

I've been running into some issues trying to gracefully degrade from in-app presentation of the MFMailComposeViewController, to opening the user's default email client via a mailto: link, and if that fails, present an alert allowing the user to copy a support email address to the pasteboard. The problem is that in the state of UIKit today, that final fallback is impossible to get to — even if there's no email client installed on the device (i.e., the user deleted Apple's Mail app and didn't install anything else), iOS always assumes that mailto: links can be opened.

Anyways, here's the body of the Feedback:

MFMailComposeViewController presents a wonderful API that developers can use in-app to give users the ability to draft and send email. However, this ability is limited only to users who use (and prefer) Apple’s own Mail app. For users that prefer (or are required) to use a third-party email client, developers must instead register and open mailto links for sending email.

This has the following drawbacks:

  1. The user is unceremoniously dumped out of the app and into their mail client, with no automated way to come back to the app after drafting/sending their email.
  2. No attachments or HTML can be added to an email generated via a mailto link. This is limiting for, say, support requests, where it is convenient for the developer to add a log file that the user can review before sending.
  3. UIApplication.shared.canOpenURL(_:) will always return true, even if there is no email client installed on the device. This is, for all intents and purposes, a silent failure.

Opening the MFMailComposeViewController API to the user’s preferred email client is a net win for Apple’s users.

Thanks to John Brayton for his input on this issue.

#Swift #UIKit #iOSDev #Radar