You’re sat at your PC, and a family member or friend sends you an email or an instant message. It includes a link to a photo album containing some fun holiday snaps, or to a listing for some product, or anything else for that matter. A cat video on YouTube. You name it.

You click the link, and it opens up in your favourite web browser. From there, you have complete control of what happens next: you can either go back to your email and leave the page open in the background, you can jump through some more pages and open some more tabs/windows or you can close your email app and keep browsing. Your favourites are there, your tabs are there, your history is there. Hell, the address bar is there.

In iOS, however, it is a very common pattern for developers to try and handle opening URLs within the application themselves. You tap a link, a little web view pops up inside the application, you look at the page or browse around a bit. You decide to go back to the app. You don’t think much more of it.

Then twenty minutes passes by, and you think “hey I could do to look at that page again”. You open up your task switcher, jump to Safari and… nothing. The page isn’t there. The page wasn’t open in Safari to begin with, it was only open within the context of the app you were using.

By this time you have closed the app, and lost your place. Where’d the page go?

Even worse, your application might open a page within a web view that looks like another site, even if it is not genuine. This can be worsened by the “hidden URL” problem, whereby a link is crafted to display one URL but navigate to another. Without visibility of the address bar, the user is not able to see the domain name/URL, or if the HTTPS connection is trustworthy.

It’s common for application developers to implement web views in this fashion mainly for a couple of reasons:

• Application developers want to keep the user captive within the application. The page only really needs to be open for a few seconds before the user wants to continue what they were doing in the app;
• The developer is concerned that in the time that the user is playing with the page in Safari, that the application in the background may be tombstoned/suspended by iOS, and that the application may not fully resume correctly.

There are some limited acceptable uses for forcing a user to use an embedded UIWebView within your app, and these include:

• Web authentication mechanisms such as OAuth or OpenID;
• Account creation or registration;
• Display of terms and conditions or other user agreements;
• Render inline content that is web-native (read: not whole web pages!) and cannot be rendered through other means.

However, if you are presenting a URL to the user and the user chooses to tap on it, the default action should always be to open in Safari. In addition to that, your application should correctly handle being suspended and resumed, so that when the user is done in the browser, they are able to jump back to your application relatively quickly without losing their place.

This provides the following benefits:

• The user is in control of where they go next. If they want to continue browsing from that page into new windows or tabs, they have the ability to;
• The address bar is present, allowing the user to see the domain name, page URL and security/encryption status of the connection (HTTPS, SSL/TLS), allowing them to verify the authenticity of the page;
• If the user wants to add the page to their browser bookmarks or to use the Share feature, then they have the option to do that also, as these are native to the browser;
• The user is able to jump back to the app and continue what they were doing, whilst being in control of whether the tab stays open in the background. Remember, they may wish to come back to it later.

It is also critical that your application correctly implements suspend and resume behaviour, so that the application state is not lost and the user can jump right back to where they were in your app before opening the web page.

If you absolutely insist on allowing the user to browse to pages without leaving your application, then this should be entirely optional. However, the default setting should always be that a single tap on a URL opens the link in the default browser.

This is such a fundamental usability issue, and yet so many high profile apps, even including Medium and Gmail, don’t seem to get this right.

Don’t let your app be one of them.