Posts tagged with "safari"

Apple Launches Safari Technology Preview for OS X

Safari is joining the growing collection of apps and developer tools that Apple wants to open up for public testing. Earlier today, Apple unveiled Safari Technology Preview, a separate version of Safari for OS X that will allow users and developers to test upcoming WebKit features.

Safari Technology Preview (which, unlike the regular Safari, has a purple icon) is a standalone app that will be updated every two weeks from the Mac App Store.

The browser will be fully compatible with iCloud: contrary to WebKit Nightly previews (the existing way of testing upcoming WebKit changes), Safari Technology Preview supports iCloud Tabs, Reading List, bookmarks, and every other iCloud feature of the stable version of Safari. Integration with iCloud should make it easier for users and developers to test Safari Technology Preview as their daily browser as they won’t lose access to their iCloud account and personal data.

Here’s Apple’s Ricky Mondello:

Safari Technology Preview is a standalone application that can be used side-by-side with Safari or other web browsers, making it easy to compare behaviors between them. Besides having the latest web features and bug fixes from WebKit, Safari Technology Preview includes the latest improvements to Web Inspector, which you can use to develop and debug your websites. Updates for Safari Technology Preview will be available every two weeks through the Updates pane of the Mac App Store.

Features already available for testing include support for the latest iteration of JavaScript (ECMAScript 6), the B3 JavaScript JIT compiler, and a new way to programmatically cut and copy to the clipboard in response to a gesture.

Safari Technology Preview requires a Mac running OS X 10.11.4 and it’s available for download today here.

Sidefari Adds iPhone Support with Updated Safari View Controller Extension

Sidefari's new iPhone extension.

Sidefari’s new iPhone extension.

I first covered Sidefari by Francisco Cantu last month, noting how such a clever idea had arisen from Apple’s limitations in the multitasking framework of iOS 9 for iPad:

Sidefari essentially acts as an on-demand Safari View Controller built into an app that does nothing else, and that’s been made available for Split View. In its simplicity, I find Sidefari to be an ingenious idea for an app that uses a built-in technology to work around a limitation of Apple’s multitasking design in iOS 9. By using Safari View Controller, Sidefari comes with a series of Safari features available by default (such as autofill and Reader); for Safari users, this is a superior alternative to using Safari and a browser like Chrome in Split View, as third-party browsers can’t access user data and settings from Safari.

I’ve been using Sidefari extensively on my iPad: while other third-party browsers exist with support for Split View (notably, both Google Chrome and the Google app can be used to browse webpages alongside Safari), Sidefari brings the convenience of having an instance of Safari that looks and behaves like the system browser. This convenience applies to design and security features, but also to everyday tricks like holding the address bar to open a URL or built-in Reader mode.

Yesterday, Cantu updated Sidefari with iPhone support and other minor improvements on the iPad. On the iPhone, the app now offers an action extension to open any link modally in Safari View Controller from any app. This is reminiscent of Browsecurely in that you can summon Safari views from apps that don’t support them– like Twitter’s official app – and it works well. On the iPad, the app has two new options: the address bar now doubles as a search box for Google search so you can type any query in it, and you can set a Home page to open with an icon in the main view. Both additions are quite handy if you want to save a little bit of time when using Safari and Safari View Controller simultaneously (the latter doesn’t let you tap the address bar to search manually, nor can you access bookmarks with it).

Sidefari has become one of my must-have utilities on the iPad, and I’m glad it’s on the iPhone too. Sidefari is available at $0.99 on the App Store.

Sidefari Lets You Browse Two Webpages at Once with iOS 9 Split View and Safari View Controller

In my review of iOS 9, I noted how new iPad multitasking features lacked an important functionality that had long been available to desktop users: a way to view multiple screens of the same app side by side. Whether it’s documents, conversations, or email threads, there’s a clear utility in being able to split the same app in multiple instances, but that’s currently not possible in iOS 9.

I’d argue that the ability to view multiple webpages at once would be even more useful than the aforementioned examples. And that’s exactly what Sidefari, a $0.99 iPad-only app released today by Francisco Cantu, wants to provide a solution for.

Sidefari uses Safari View Controller to let you open a second webpage in Split View on your iPad. Unlike Browsecurely, Sidefari doesn’t display Safari View Controller on the top of the app you’re currently using – it’s been designed, as the name suggests, as a side companion based on the Safari web views introduced with iOS 9. Whenever you find yourself needing to open two webpages and view them simultaneously, you can invoke Sidefari from the Slide Over app picker and enter Split View. At this point, you have some options: you can use the Sidefari extension to send a webpage from the main app to Sidefari (which needs to be in Split View already to open the URL directly), or you can paste a URL into Sidefari and open the webpage from your clipboard. Sidefari can also hold up to 50 items from your history in the app, but this can be disabled in the Settings.

Sidefari essentially acts as an on-demand Safari View Controller built into an app that does nothing else, and that’s been made available for Split View. In its simplicity, I find Sidefari to be an ingenious idea for an app that uses a built-in technology to work around a limitation of Apple’s multitasking design in iOS 9. By using Safari View Controller, Sidefari comes with a series of Safari features available by default (such as autofill and Reader); for Safari users, this is a superior alternative to using Safari and a browser like Chrome in Split View, as third-party browsers can’t access user data and settings from Safari.1

Sidefari is a clever implementation of Split View and Safari View Controller, and it’s only $0.99 on the App Store.

  1. They can, however, offer tabbed browsing, which Safari View Controller doesn’t have. ↩︎

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