This Week's Sponsor:

DEVONTHINK

Store, Organize, and Work the Smart Way

Posts tagged with "safari"

Safari View Controller and Automatic Safari Reader Activation

Left: Safari Reader, automatically activated by a Newsify web view.

Left: Safari Reader, automatically activated by a Newsify web view.

In my review of iOS 9, I included a link in a Safari footnote mentioning the possibility for developers to activate Safari Reader programmatically in their apps. Apple has some documentation on this: if available, apps can choose to switch Safari View Controller to Reader mode automatically, without requiring users to tap the Reader button first. I wrote that I hadn’t seen any example of the feature, but I was curious.

Newsify, a powerful (and highly customizable) RSS reader for Feedly, has recently been updated with a watchOS 2 app and support for iOS 9 multitasking. Among the various new options, Newsify lets you pick Safari View Controller (called “in-app Safari” in its Settings) for viewing articles, with an additional Reader view that can also be toggled in Settings. This way, every time you tap on an article’s web view in Newsify, it’ll open Safari View Controller in Reader mode by default, stripping away unnecessary content.

Here’s what you can do to try this out. Open Newsify, go to Settings > Article Browser > Globe Button Action and choose ‘Open in Safari’. In the same screen, under Safari Open Action select ‘Open Safari In-App (Reader view)’.

Now, go back to the list of articles, tap one, and tap the globe icon to open the article’s web view. Safari View Controller will open the webpage, briefly load the main content, and then Reader will activate automatically, with the same appearance settings you used the last time you opened it elsewhere on iOS.

I think this is a great way to provide a “readability” mode in apps by combining the benefits of Safari View Controller with the convenience of Safari Reader. I hope that more apps will consider this option.

Safari View Controller as Onboarding Tool→

Cluster’s Rizwan Sattar has been playing around with Safari View Controller on iOS 9, and he discovered that it can be used as an onboarding tool to make users sign up for web accounts in apps more easily:

In the past I always worried about building a seamless first-time experience for our users. None of the “magic” solutions felt elegant.

Using a hidden Safari View Controller to help identify your user removes user confusion and makes your app feel magical when users use it for the first time.

The videos show how much of a difference using Safari View Controller for authentication in the background makes compared to existing solutions. Even if the background method used by Sattar stopped working, the automatic login and dismissal flow (second video) seems magic compared to shared web credentials with iCloud Keychain, which is already very useful (I love it, for instance, in Junecloud’s Deliveries). Yet another reason why we should keep an eye on Safari View Controller and hope it’ll be widely adopted on iOS 9.

Permalink

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.