Following the rollout of updates to iWork for iOS, OS X, and iCloud.com, Apple released version 7.0.3 of its Safari browser today. The update, available in Software Update through the Mac App Store, brings a new preference in the app’s Notifications settings that allows users to turn off prompts for website notifications (Note: MacStories uses Safari push notifications). In previous versions of Safari, users could only allow or deny notifications after interacting with a prompt that asked for permissions to display push notifications; now, Safari can skip that prompt entirely if the preference is turned off.
Version 7.0.3 also adds support for new generic top-level domains (which include new entries such as .ceo, .sexy, and .shop) that are loaded as websites by Safari; previously, Safari couldn’t recognize the recently launched generic top-level domains, and redirected them to standard web searches.
In terms of bug fixes, Safari 7.0.3 improves credit card autofill, fixes a bug that could stop website notifications from being displayed, and resolves an address bar bug that loaded webpages or web searches before pressing the Return key.
Since I switched to Safari as my primary browser, I’ve been enjoying the convenience of iCloud Tabs, which allow me to easily find webpages that I have open on my devices and re-open them anywhere, at any time. iCloud Tabs have been reliable and fast in my experience, and I cannot imagine going back to a browser that doesn’t have this sort of functionality.
The problem with iCloud Tabs is that they’re limited to Safari, so if you’re using Chrome or Firefox on OS X, you can’t access the tabs that you have open on your iPhone or iPad. For this reason, Josh Parnham has devised a simple and clever solution: CloudyTabs is a menu bar app that lists iCloud Tabs open on all your devices. CloudyTabs reads data from the .plist file that stores iCloud Tabs data on OS X, which is why the app isn’t available on the App Store and has been released on GitHub.
Once installed, CloudyTabs will need a few seconds to find open tabs and after that it’ll present a dropdown menu listing devices and webpages open on each one of them. You can CMD-click tabs to open them in the background in your default browser, and there’s a handy shortcut to open all tabs from a specific device at once. You can also type the first few letters of a tab’s title to select it.
If you don’t use Safari on OS X and wish there was a way to open iCloud Tabs without copying and pasting URLs, CloudyTabs gets the job done quite elegantly, and it’s free. You can download it here.
When I'm writing on my iPad at home, there's a chance I have my MacBook on my desk with either iTunes open (to check for app updates or playing music from iTunes Match/Radio) or MailMate running (because I've been having issues with Mail on the beta of iOS 7.1). It's not uncommon for me to use a dual-monitor setup when writing, relying on my MacBook for Google searches and other reference material – effectively, I use it as a secondary display to my iPad when I'm working on articles that require a fair amount of research.
Since the release of Command-C, I've been using Danilo Torrisi's utility to quickly beam text and URLs across all my devices, using Launch Center Pro actions to speed up the process. Command-C has excellent support for URL schemes – a boon to iPad users who fiddle with automation tricks to save time when working on iOS. I recently realized, however, that most of the content I share with Command-C is made of URLs from Safari, therefore I asked myself whether I could put together a solution to send URLs with one click from Safari without using an external app or keyboard shortcut. It was pretty clear from the beginning that I would end up with a bookmarklet, but I have to thank Danilo for providing the necessary guidance I needed to achieve the kind of workflow I wanted.
The bookmarklet is part made for myself, part proof of concept (as always) for others to iterate upon. It doesn't only send URLs from Safari on another device with Command-C – it sends the webpage you're currently viewing in Safari to another app on another device with Command-C.
Joseph Schmitt, writing in response to Greg Pierce's hack to simulate x-callback-url support in Chrome:
However, Greg's technique depends on loading a full-screen iframe on the page and overlaying a back button on top to trigger the x-success url. That gets the job done, but I really prefer how Chrome handles this: make the last page jump to the previous app. I brainstormed for a bit and figured I could probably replicate Chrome's behavior's using Greg's idea, and I was right: xsuc.es was born.
To build actions with xsuc.es, see the URL parameters in Joseph's blog post. The format is easy to understand if you're already familiar with URL schemes; here's a demo action to launch a Google search in Safari based on xsuc.es from Launch Center Pro.
My problem: I haven’t installed Flash on my Mac and I sometimes need to watch YouTube videos that require Flash Player in Google Chrome. Google’s browser is my Flash shelter: Safari is my main browser and I only keep Chrome around for Flash videos. I was getting annoyed by the process of copying a URL -> launching Chrome -> pasting the URL, so I made a simple Keyboard Maestro macro to automate everything with a hotkey. I don’t know what took me so long.
The macro checks if Safari is the front window, and, if not, it displays a notification with an error message. I do this to prevent accidental hotkey presses for URLs that I don’t want to open in Google Chrome. If Safari is the front window, however, what required a bunch of steps in AppleScript to open the current Safari URL in Chrome is a single action in Keyboard Maestro: Set Google Chrome URL, using %SafariURL% as a variable.
The two additional steps — Open Chrome and Wait For Chrome To Finish Loading — were necessary because I discovered that, when launched with a Set URL action, Chrome wouldn’t intercept the URL sent by Keyboard Maestro and would simply display a blank tab. In this way, Chrome is launched, paused for a second as it reloads open tabs or the start tab, and then the Safari URL is opened in the current tab. If you want to open the URL in a new tab, change the Set Chrome URL action to New Google Chrome Tab.
Before switching to Chrome last year, I didn’t have a “favorite” browser or “browser of choice”: I just kept jumping between Safari, Chrome, and Firefox, trying out all the features that the three major players had to offer on OS X. I’m pretty sure that, at one point, I even tried to go a full week with using Opera. My browser requirements have always been fairly standard (several open tabs; a lot of reading; sync with mobile devices), so I could afford to change browsers without having to worry about setting up a complex environment from scratch.
As I started using my iPad as my primary computer last year, I was growing increasingly annoyed with the state of iCloud sync in Safari and lack of major overhaul to a design that originally shipped with iPhone OS 1. I don’t frequently abandon systems that work for me due to stagnation, but iOS 6’s Safari exhibited a certain staleness on top of issues with bookmark and tab sync that, for me, were becoming an annoying problem. I liked Safari’s speed and native integrations with iOS, but it was prone to errors and boring.
On the other hand, Google Chrome for iOS was promising, familiar, and power user-friendly. I fell in love with Google’s support for x-callback-url, which I integrated in several workflows of mine as it allowed me to save time when switching between apps on my iPad; sync was nearly perfect; I praised Google’s superior implementation of voice dictation and feedback, although I noted how their Voice Search couldn’t exactly compete with Siri. Google kept pushing updates to Chrome for iOS, making it a capable browser for average and power users alike.
A few weeks after publishing my review of iOS 7, I decided to uninstall Chrome from all my devices and move back to Safari as my main and only browser on my iPhone, iPad, and two Macs.
I’m not looking back. I’m happy with the new Safari – so much, in fact, that I’m even considering Reading List as my “read later” service going forward.
Bake in Clearly, integrate Skitch, toss in the clipper from Evernote’s helper, then add sharing, and you end up with Evernote’s new Web Clipper for Safari. Once a pop-up that simply copied the full page or URL, the new Web Clipper condenses page grabs and annotation tools into a simple sidebar, adding almost all of the base features you’d find in Skitch, a standalone screenshot, image, and PDF markup and sharing application for desktops and mobile devices.
The new Web Clipper is activated by clicking on the toolbar button, which slides out a sidebar that’s reminiscent of the formatting bar found in iWork’s updated apps for OS X Mavericks. All of the actions are organized neatly into various sections for cropping the web page, drawing shapes, and sharing the results. Arrows, squares, and text can be dragged around, rotated, and resized using onscreen handles for annotating webpages. Clip tools give you a wide variety of options, including the ability to format the page into a readable article view as Clearly would before taking the final screen grab. Sharing gives you a URL that you can paste into a chat app or your favorite website, while also presenting options to share via Facebook, Twitter, or publicly via Evernote itself. There’s a couple kinks with the extension, mainly that it doesn’t like to be used with swipe back gestures or the back button while the sidebar is open, but otherwise the tools work just as Skitch lets you on a Mac.
Saving web pages into Evernote is a great way to remember a cool design, highlight an important note, or refer back to a piece of content for later reading, homework, and marketing research in an instantly searchable database. The extension is a complete revamp over the previous one, putting all of the tools that used to require two or three apps into a streamlined list of actions that doesn’t get in the way. Chrome received the new look a while ago, and hopefully the Firefox extension is next.
In moving back to Safari as my main browser on every Apple device I own, I thought I should mention a hidden feature of Safari for iOS that I discovered a few months ago and that I remembered today thanks to a Twitter exchange between readers Jordan and Jerry.
On iOS, you can launch Safari directly in a web search page using this URL scheme:
Where [query] is the text of your search query. Essentially, instead of having to launch Safari, tap the address bar, type your search query, and then tap Go, you can use an app like Drafts or Launch Center Pro to quickly type out your search query and send it to Safari, which will open a new tab for your search.
In Drafts (or any other app that lets you create custom URL scheme-based services like Launch Center Pro, Editorial, or Mr. Reader), simply create an action that sends the text you’ve typed to Safari’s web search. Here’s my action if you want to install it in your Drafts app.
The benefit of this search URL scheme is that it doesn’t care about the web search you prefer: it’ll continue to work based on the search provider that you pick in Settings > Safari, and, overall, it’s just a nice shortcut that lets you save a couple of taps every day.
As usual, make sure to percent-encode your query. If you use Drafts, the action above will do it for you.