Among heavy users of Safari, by far the most frequent request we’ve heard—and one that’s at the top of our list, as well—is for better memory management. Specifically, if you’ve got multiple tabs open in the browser, there’s a good chance that switching to a background tab will immediately reload its content. What if you were toggling between two tabs to, say, copy text from one tab and then paste it into a blog post on the other? Say goodbye to any unsaved changes.
Of course, there’s only so much you can do with limited physical memory, so the ultimate solution is for Apple to include more RAM in new versions of its iOS devices. But for all of us stuck with current devices, making Safari less enthusiastic about purging pages would be a huge improvement.
Provide a basic plug-in architecture
No, we don’t want Flash on the iPhone. (OK, a few people do. But we don’t.) What we do want is a way to, for example, integrate the excellent 1Password for iOS with Mobile Safari, the way the Mac version of 1Password works with OS X Safari.
Allow printing to PDF
One of our favorite OS X features is how dead-simple it is to save a document or webpage as a PDF: You just click a PDF button in OS X’s Print dialog box, and the OS “prints” the current document directly to a PDF file. We use this feature daily to save receipts from online purchases, to save travel documents, to export presentations to universally readable versions, and much more.
It’s such an elegant and useful feature that we want it on our iPhones and iPads, too. For example, it’s easier than ever to shop online from mobile devices, and it would be great if we could “print” receipts to PDF files, just as we can under OS X. Right now, our only option is to install a utility such as the outstanding Printopia on our Macs, and then “print” to a PDF file via Printopia. But Printopia requires that your iOS device and Mac be on the same local network—and the resulting PDF is stored on your Mac, not your iPhone or iPad.
We’d like to see OS X’s print-to-PDF feature, whole hog, in iOS. When you tap the Print button in any share sheet, you should get the option to save the current document or webpage as a PDF file.
Of course, letting us save to PDF would require someplace to put those PDFs, which leads us to…
Let us download and manage files
In many ways, Mobile Safari is a full-featured browser that compares favorably to its desktop sibling. That is, until you need to download data. If you’re downloading a PDF document, Safari can display it in the browser window, and you can then use iOS’s Open With feature to send the PDF to a more-powerful PDF-handling app such as GoodReader. But for pretty much any other kind of file, tapping a download link leaves you staring at the screen, wondering why nothing is happening.
There are actually two issues at play here. The first is that Safari simply doesn’t attempt to download most types of data. The second is that even if it could download files, there’s no place for Safari to save those files—iOS doesn’t have a Downloads folder like OS X does. We suspect that the latter issue is a big reason for the former. Which means that in order for Safari to support downloads, iOS must provide a place for downloaded data to go and—more important—for users to be able to browse and manage those files. (We’ll have more to say on this topic next week when we cover our wish list for general iOS improvements.)
Tweak full-screen mode on the iPhone and iPod touch
The auto-full-screen mode on Apple’s smaller iOS devices has its advantages—it’s nice to get a bit more screen real estate while viewing a webpage. But it’s also confusing: More than a few less-tech-savvy friends and family have asked us why their search/address field and toolbar have disappeared, and wondered how to get it back. Even among those of us who know Mobile Safari well, the feature feels fiddly, and it can be annoying to have to scroll up a webpage to access toolbar buttons. (We also don’t like that you now have to tap the top of the screen twice, instead of iOS 6’s once, to quickly scroll to the top of a webpage: once to reveal the address field and toolbar, and another to scroll.)
We’re not exactly sure what the best alternative would be. A number of readers, and some Macworld staffers, have suggested simply adding a full-screen-mode toggle button. That would, of course, take screen space away from the webpage-viewing area. But maybe a few buttons isn’t such a bad thing—Apple’s recent penchant for hiding interface elements doesn’t always result in the most usable UI.
Improve saved-password management
Safari’s auto-fill feature, and the capability to sync saved passwords across devices using iCloud Keychain, makes it easier to stay secure online. But managing saved passwords is a different story. If you go to Settings > Safari > Passwords & Autofill > Saved Passwords, you can see a list of sites for which you’ve saved passwords, but it’s just one looong list. And even if you find a particular saved password in the list, you can’t do much with it, other than delete it or (once you’ve provided your device passcode) view the saved data.
We’d like to be able to search the list of saved passwords and, even better, edit an entry if a username or password changes.
Pick a browser. Any browser.
As good as Mobile Safari is, some people just don’t like it. Or they use Chrome on the desktop and want to sync bookmarks with their iOS browser, so they also use Chrome for iOS. You’re free to use a third-party browser on the iPhone and iPad, but doing so requires some extra work and more than a little inconvenience: Browser links always open in Safari, regardless of your personal browser preference.
As we mentioned in our Mail wish list, we’d like to see Apple open up a bit and let users choose their own default browser, with Web links and other browser actions automatically opening in that browser—even if it’s not Safari.
Desktop or mobile? Let us choose
More and more websites are embracing “responsive design,” which means—for the purposes of this item—that a site will serve you a different webpage depending on whether you’re browsing on a desktop computer, a tablet, or a phone. The thing is, sometimes the mobile version of a website stinks, or it’s missing options you get when using your MacBook.
Safari’s Reading List feature is a convenient way to save pages for later reading—for example, when you come across a long article, when browsing on your iPhone, that you’d prefer to read on your iPad’s more-spacious screen. But these days, it seems everything’s about sharing, and we think it would be great to be able to share lists of interesting articles with your friends and family. We’d still want the standard list for our own “read later” articles, but just as you can create shared Photo Streams of photos, it seems the logical next step for Reading List is to able to create shared, publicly (or privately) accessible Reading Lists.
One of our Twitter followers offered a suggestion that we really like: Replace Safari’s Back button with a Close Tab button if there is no “back” in the current tab’s history (i.e., when you’re at the first page in the history). This would alleviate the minor hassle of having to open the tabs view and then close the window.
We’d also like to see Apple bring back the .com button in the Safari keyboard. Under iOS 6 and earlier, tapping this button would immediately type .com in the URL field; tap-holding the button would give you options for .org, .net, .edu, and so on. You can access the same feature in iOS 7 by tap-holding the period (.) button on the Safari keyboard, but relatively few people know this trick—it’s just not obvious.
Finally, Mail, Calendar, and Contacts are pretty good about making addresses “live”—you can usually tap an address to open it in the Maps app, an email address to create a new message in Mail, or a phone number to dial the number in the Phone app. But, inexplicably, Safari presents these bits of data as dead text unless the webpage has specifically coded that text as an HTML link. Apple, let’s make Safari as smart as the rest of iOS when it comes to addresses and numbers.