Posts tagged with "iOS 9"

iOS 9 Beta 3 Adds Albums for Selfies, Screenshots→

In the third beta of iOS 9 released to developers earlier today, Apple has included two new default albums in the Photos app – Screenshots and Selfies. The albums automatically collect screenshots and pictures taken with the front-facing camera (anything taken with the front-facing camera, as there’s no facial recognition in place yet – maybe it’ll be added later?).

As someone who takes dozens of screenshots on a daily basis – and I’m not alone – this sounds like a welcome change. Since iOS 8, I’ve been using apps like Screeny and Sharkie to delete all my screenshots, but native integration with the Photos app to view all screenshots and organize them should speed up my workflow even more.

Permalink

Reconsidering Apple’s Default Apps→

Seth Clifford’s post on reconsidering Apple’s default apps on iOS and OS X comes at an interesting time, as I’m also in the (now annual) process of reevaluating which apps I use during the developer beta of iOS.

Something’s changed though–well, two things–in the past few years. I’ve lost my taste for fiddling a little bit, and the default apps Apple ships with its devices have gotten, well, better. Better than other things I could use? Not in all cases. But better… enough. I’ve been increasingly focused on reducing friction in my life, and having a simpler computing experience that works together with its component parts–as much as any multi-device connected computing experience can work without hair-pulling these days.

I go through this stage every year: Apple releases a new beta of iOS, and, for review purposes, I need to know what’s changed in their apps. This usually means that, for a few months, I go back to Mail, Podcasts, Reminders, Calendar, and other apps that gradually get replaced by third-party alternatives as developers release updates for their apps in the Fall. Some of Apple’s apps have stuck with me over the years, like Safari (which I believe is Apple’s best app on iOS); others eventually disappear from my Home screen as they don’t offer the kind of powerful features I think I need.

But as I argued on Connected last night, I wonder if this year will be different. Apple is bringing new exclusive functionality to their apps, such as the ability for Siri to create reminders for anything that’s on the screen (with deep links) and start audio playback depending on your habits, or handy links to create calendar events and update contact cards based on information found in Mail. In the past two weeks, I’ve made an effort to use Apple apps as much as possible, and, while minor, these subtle enhancements do add up. I like that iOS 9 can offer shortcuts gathered from conversations in email, and Reminder’s ability to create todos for any app content is convenient and clever.

Apple’s apps have always gotten better with each iOS release, but I wonder if this year’s additions – most of them featured under the Intelligence banner – will make me reconsider third-party apps I thought I’d never change again. It’ll be interesting to check back once iOS 9 ships.

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

iOS 9 Beta Includes New Auto App Delete & Reinstall Feature for OS Updates→

As noted by some users on Twitter today, the just-released second beta of iOS 9 includes an option to delete apps to make room for a software update, with iOS taking care of reinstalling deleted apps once the update is complete.

Here’s Juli Clover, writing for MacRumors:

When attempting to install iOS 9 on a device with insufficient space, there’s a popup that offers to temporarily delete some apps in order to make room for the update. Apps that are deleted are then reinstalled and replaced after the operating system update is completed.

Between this and smaller sizes for apps and updates announced at WWDC, Apple wants to make sure owners of devices with low storage will always have a chance to upgrade to the latest version of iOS. We can only wonder if 16 GB iPhones will ever go away.

Permalink

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

Inside iOS 9 Search: Apple’s Plan for More Connected Apps

At WWDC 2015, Apple announced app search, a new feature of iOS 9 that will help users find content inside apps. Beyond the user-facing aspects of a new search page on iOS and proactive suggestions from Siri, however, lies a commitment to fundamentally rethink iOS’ relationship with apps and the web, with deep implications for the future.

With iOS 9, Apple wants to reimagine how information from apps is exposed to users. For a long time, iOS apps have largely been treated as data silos – utilities that kept gaining design improvements and powerful functionalities as iOS grew, but ultimately unable to bring their data outside the confines of their sandbox. Following in the footsteps of iOS 8’s adoption of extensions, Apple’s plan to further open up iOS is deceptively simple: just let users search for what they need.

Behind the scenes, the reality of iOS 9 search is going to be a little more complex than that.

Read more

iOS 9 Picture in Picture→

Benjamin Mayo has a great summary of the benefits of Picture in Picture for iOS 9 on the iPad as compared to the Mac:

The thing about the iPad picture-in-picture implementation is that its actually better than how one would handle such a task on a Mac. On a Mac, trying to play a video in the corner whilst getting on with your work is difficult. Let’s take a video on YouTube playing in Safari. To play this in a corner of the screen on a Mac, you have to pull the window out into its own tab. Then, you have to manually drag the corners of the window to resize it and do your best to clip out all the unnecessary surrounding UI by hand. No doubt the window has a toolbar so you’ll probably have to do some awkward keyboard shortcut or hidden menu command to hide that as well.

Then you have to actually manage the window as you go on with your work. What do I mean by this? Well, with every other task you open you also have to make sure it doesn’t occlude the video playback window by dragging it out the way. The video can’t stay foremost so it’s actually really easy to lose the video amongst your other windows.

If you ever want to move the video from one corner to another, not only do you have to position the video on the screen, you also have to move all your other windows back over to the other side.

This mirrors my initial thoughts exactly. When I talk about the inherent complexities of desktop OSes, this is the type of issues I refer to. With an implementation built on years of distilling the experience to the simplest, iPad multitasking will make these differences even more obvious.

Permalink

iOS 9 Content Blockers→

Benjamin Mayo, writing for 9to5Mac:

Ad blocking extensions have been possible on Safari for Mac for a long time, but plugin architecture for Safari on iOS is much more limited. With iOS 9, Apple has added a special case of extension for ad blockers. Apps can now include ‘content blocker’ extensions that define resources (like images and scripts) for Safari to not load. For the first time, this architecture makes ad blockers a real possibility for iOS developers to make and iOS customers to install and use.

This has been, for me, the most puzzling new feature in iOS 9. Why is Apple doing this? Is the demand for ad blockers on iOS so high to justify the creation of a new extension point in Safari (and tons of questionable ad blockers coming to the App Store)? Could this be related to shady ad networks still finding ways to automatically redirect web views to the App Store?

The most plausible explanation I’m coming up with is that Apple wants to make it easier to develop third-party content filters (not necessarily ad blockers, like curbi) for parental and educational purposes without workarounds (like MDM and VPN certificates), but I’m not sure.

Permalink

iOS 9 Bringing Changes to URL Schemes→

Agile Tortoise’s Greg Pierce has an explanation of the changes coming to iOS 9 for apps that want to launch URL schemes:

There are two URL-related methods available to apps on iOS that are effected: canOpenURL and openURL. These are not new methods and the methods themselves are not changing. As you might expect from the names, “canOpenURL” returns a yes or no answer after checking if there is any apps installed on the device that know how to handle a given URL. “openURL” is used to actually launch the URL, which will typically leave the app and open the URL in another app.

Up until iOS 9, apps have been able to call these methods on any arbitrary URLs. Starting on iOS 9, apps will have to declare what URL schemes they would like to be able to check for and open in the configuration files of the app as it is submitted to Apple. This is essentially a whitelist that can only be changed or added to by submitting an update to Apple. It appears that certain common URLs handled by system apps, like “http”, “https”, do not need to be explicitly whitelisted.

In short, Apple wants to prevent apps from being able to scan a user’s device and know which apps are installed. Notably, this change comes a few months after Twitter started scanning user devices to see installed apps and deliver “a more personal Twitter experience”.

As Greg notes, Apple is doing this to protect customers’ privacy. Companies like Twitter had found a loophole to gather data about user devices that iOS doesn’t normally expose, and it makes sense for Apple to prevent this from happening in the future. The problem is that this system based on whitelists and limited number of URLs could be a serious threat to automation apps like Launch Center Pro and Launcher, which depend on launching any URL.

Since last year, various iOS teams have made an effort to obviate the need for URL schemes through extensions. This year, they’re going one step further. I agree with the underlying privacy concerns and I also believe that more developers should embrace extensions – how ironic that Twitter still doesn’t support them and they’re likely causing this change – but it’s important to note that some automation apps are based on the idea of launching URLs, not showing share sheets for extensions.

As Greg notes, there’s some confusion in this first beta of iOS 9. Hopefully Apple and developers will be able to work out a decent compromise by the final release.

Permalink