Posts tagged with "safari"

Browsecurely Brings Safari View Controller Anywhere with an Action Extension

Typically, you wouldn't be able to do this in the Twitter app for iOS.

Typically, you wouldn’t be able to do this in the Twitter app for iOS.

One of the best details of Peace, Marco Arment’s original Ghostery-based Content Blocker for iOS 9, was the ability to summon Safari View Controller anywhere with an extension. As I wrote in my review:

Open Unrestricted and Open in Peace are interesting, as they leverage Safari View Controller to temporarily disable (Unrestricted) or use Peace for a link passed to the extension. This means that, besides Safari and apps that support Safari View Controller, you can enjoy the benefits of Peace from the system share sheet. Even if an app doesn’t integrate with Safari View Controller – such as Twitter, but there will be many others – as long as they can share a URL with native extensions, you’ll be able to use Peace’s Content Blocker and Safari View Controller. This is a genius way to circumvent apps that don’t support the superior Safari View Controller experience in iOS 9, and I bet that other developers will be “inspired” by it once they see it.

Developed by Martin Gordon, Browsecurely is a new app for iPhone and iPad that lets you open Safari-based web views in every app that supports the iOS share sheet.

The idea is extremely simple: in spite of the many advantages of Safari View Controller (which include privacy features, performance gains, Content Blockers, and an experience consistent with the system browser), there are still some apps –like Twitter’s official client – that prefer not to implement it, using their own web views independent from Safari. Browsecurely offers a way out from those web views: as long as you can share a webpage’s URL with native extensions, you’ll be able to open the selected webpage with Safari View Controller using the Browsecurely action extension. By doing this, you’ll simply be opening a URL in Safari View Controller without leaving the app you’re using; current Content Blocker, Reader, and other Safari settings will carry over from the browser automatically.

I was waiting for someone to replicate Peace’s Safari View Controller extension in a dedicated app, and it doesn’t surprise me that this basic functionality is available for free with an optional In-App Purchase to support the developer. Browsecurely has no additional features – it’s just a way to open links in Safari View Controller with an extension.

I have to wonder if, eventually, Apple will make a Safari extension themselves, allowing users to always open links with Safari View Controller as a system-level option available in every app. In the meantime, Browsecurely comes in handy to quickly view webpages in Safari View Controller from the share sheet, and it’s available for free on the App Store.

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