iOS allows any app to present Safari Views and Mail Compose Views. These views are fantastic because they provide the functionality of Safari and Apple Mail without forcing the user to leave the app presenting them.

Safari Views incorporate the user’s content blockers. Bookmarking a webpage from a Safari View adds that webpage to the user’s Safari bookmarks. Safari’s reader mode is available, and the app presenting the Safari View can indicate that the Safari View should be opened in reader mode by default.

Mail Compose Views let the user send a message from any email account setup in Apple Mail. The app can specify an initial subject, list of recipients, and message content. The initial message content can either be plain text or HTML. The user then edits the message and sends it.

iOS 14 added a Default Browser App setting and a Default Mail App setting. The system honors the settings when opening webpage URLs and mailto: URLs, but does not when presenting Safari Views and Mail Compose Views. Those views just incorporate functionality from Apple’s apps. When an app presents a Safari View or a Mail Compose View to a user with an alternative default app setting, it looks like a bug that prevented the default app setting from being honored.

When presenting webpages, the result is that bookmarking a webpage adds the bookmark to Safari instead of the user’s browser of choice. Mechanisms to prevent tracking and to block obnoxious content that might be available in the user’s preferred browser are not available in the Safari view.

For email the situation is worse. A user might not have Apple Mail setup with their accounts, or they might have it setup with their iCloud account but not their preferred email account. They might use a service like HEY that does not work with Apple Mail.

An app can check MFMailComposeViewController.canSendMail() to determine whether the user is able to send a message from Apple Mail, but my customer interactions have led me to conclude that this is a weak indication of the user having their preferred account setup in Apple Mail. There is no way for an app to determine whether the Default Mail App setting on a device is set to Apple Mail or something else.

This leaves app developers with these options:

  • Use mailto: links and accept their limitations: that you cannot specify default HTML content, that many email apps do not handle default plain text content with more than one line in mailto: URLs, and that the user gets bounced out of the app.
  • Use a Mail Compose View when MFMailComposeViewController.canSendMail() returns true, accepting that this will not let all customers send from their preferred account.
  • Add a setting.

I tried to avoid adding a setting to Unread, but I ended up creating a Send Mail In setting. When set to Unread, it presents a Mail Compose View. When set to Default App, it tells iOS to open a mailto: URL.

When using Unread’s mechanisms for contacting customer support while this setting is Default App, I cannot automatically incorporate information like the Unread version identifier into the outgoing message because multiline plain text content often does not work with mailto: URLs. I cannot honor this setting for Unread’s Mail Article functionality because there is no way to specify HTML content in a mailto: URL.

Apps need the ability to create Mail Compose Views that honor the default email app setting. A third party email app should be able — perhaps required — to provide an extension with its implementation of Mail Compose View functionality. Similarly iOS needs a Browser View that honors the Default Browser App setting.

Relevant Feedback Assistance reports:

  • FB10005791: Safari View Controller should honor default browser
  • FB9093370: MFMailComposeViewController and Default Email Apps

Update: I removed FB9093357 from the list of relevant Feedback Assistant reports. It reported that mailto: URLs with multiline message bodies do not work in Apple Mail. That appears to be fixed in the current iOS 15.5 beta release.