Bryan Irace writes about web views in iOS and offers a great idea for the future: a Safari view controller.
But in-app browsers have some pretty massive downsides as well. They can’t access cookies stored by other in-app browsers, nor Safari, requiring the user to repeatedly log in to websites that they should already be authenticated with. iCloud Keychain is great for syncing credentials across devices, but while Safari has access to its data, in-app browsers don’t. This isn’t merely Apple being punitive – it’d be horribly negligent to give third-party applications access to this kind of information.
Essentially, developers would be able to implement a web view based on Safari that offers Safari features to other apps while also isolating code from third-party access. This would be good for security, for example, but also for consistency with extensions and iCloud features.
As I noted earlier this week, implementations of web views can be massively different from app to app. A native Safari view could offer more options than standard web views and secure user data from third-party apps (case in point). It could also provide a solution to this:
You can find Bryan's suggestion on OpenRadar.
Continuing my exploration of iOS 8 technologies with a focus on extensions, a few days ago I came across WhatFont, the new iOS version of a popular desktop tool. As the name suggests, WhatFont lets you identify fonts in Safari easily and without having to go look at source code or style sheets.
I first covered View Source, an action extension to view source code in Safari, soon after the launch of iOS 8:
With iOS 8 extensions, apps like View Source can be possible thanks to direct integration with Safari and access to the DOM. Once enabled in the browser's share sheet, View Source will bring up a full-screen panel with source code you can read and copy. A share button lets you copy all text to the clipboard, send as email, or choose one from eight themes that include dark backgrounds and lighter styles. All these themes support syntax highlighting – a better visualization than my old scripts that didn't support highlighting at all.
If you're a web developer and work with iOS, View Source has turned into a must-have. It's $0.99 on the App Store.
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.
Safari 7.0.3 is available in Software Update.
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.
You can download the macro here.