Posts tagged with "safari"

iOS 9 and Safari View Controller: The Future of Web Views

For a long time, iOS apps have been able to open links as web views. When you tap a link in a Twitter client, an RSS reader, or a bookmark utility, it usually opens in a mini browser that doesn't leave the app, providing you with the convenience of not having to switch between Safari and the app. For years, in spite of some security concerns, this worked well and became the de-facto standard among third-party iOS apps.

With iOS 9, Apple wants this to change – and they're bringing the power of Safari to any app that wants to take advantage of it.

Read more


WebKit Blog on Safari Content Blocking Extensions

I've been curious to know more about the reasoning behind content blocking extensions coming to iOS 9 and OS X El Capitan. The general assumption is that Apple wants to enable users to activate ad blockers on the iPhone and iPad, but I wanted to hear Apple's public stance and details on the implementation.

The WebKit blog answers my questions with an in-depth post on content blocking extensions. First off, Apple engineers were unhappy with the current state of content blockers:

The reason we are unhappy about the JavaScript-based content blocking extensions is they have significant performance drawbacks. The current model uses a lot of energy, reducing battery life, and increases page load time by adding latency for each resource. Certain kinds of extensions also reduce the runtime performance of webpages. Sometimes, they can allocate tremendous amounts of memory, which goes against our efforts to reduce WebKit’s memory footprint.

It is an area were we want to do better. We are working on new tools to enable content blocking at a fraction of the cost.

​As for Apple's motivation, they never mention “ads” in the post, but the focus on disabling trackers and making webpages faster by removing external scripts is fairly clear:

We have been building these features with a focus on providing better control over privacy. We wanted to enable better privacy filters, and that is what has been driving the feature set that exists today.

There is a whole universe of features that can take advantage of the content blocker API, around privacy or better user experience. We would love to hear your feedback about what works well, what needs improvement, and what is missing.

​Unsurprisingly, Apple built these new extensions differently than most content blockers for desktop browsers. Content blocking extensions won't see the URLs of pages or resources being blocked:

A major benefit of the declarative content blocking extension model is that the extension does not see the URLs of pages and resources the user browsed to or had a page request.

​And:

WebKit itself does not keep track of what rules have been executed on which URLs; we do not track you by design.

User privacy is at the center of content blocking for both webpages and extensions. It'll be interesting to see how many apps that just focus on blocking ads in Safari will be approved on the App Store (and how much they'll leverage freemium models if so).

Permalink

A Safari View Controller

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.

Permalink


View Source 2.0

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.

View Source has been updated with numerous improvements since its first release, and most notably yesterday with the release of version 2.0. View Source now has two Solarized themes, line wrapping is optional, and you can search and highlight any string of text within the extension. Even better, the extension now has a full DOM browser so you can view and navigate to linked assets without leaving Safari. You can also write custom JavaScript and have it executed in the Safari webpage you're viewing after you dismiss the extension.

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.

Permalink



Safari 7.0.3 Brings New Notifications Preference, Support for Generic Top-Level Domains, Fixes

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.


CloudyTabs Puts iCloud Tabs In Your Mac’s Menu Bar

CloudyTabs

CloudyTabs

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.


Command-C Browser Actions

Command-C

Command-C

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.

Read more