This Week's Sponsor:

Dropzone 5

Improve your Drag-and-Drop Workflow

Posts in Linked

Apple News to Have Human Editors, Curation→

Jordan Kahn, writing for 9to5Mac on a job listing that indicated Apple News is going to have human editors in addition to algorithms:

Apple’s job listing notes that News editors will be responsible for gathering “the best in breaking national, global, and local news.” They will also be working firsthand with publications to “drive relationships with some of the world’s leading newsrooms, ensuring that important breaking news stories are surfaced quickly, and enterprise journalism is rewarded with high visibility.” And Apple won’t just be curating stories from the big players. It also mentions a focus on surfacing original content from “the largest to the smallest” publishers. News editors will also track social media for breaking stories, according to the job listing, and “recognize and communicate key content trends to senior management.”

And here’s Dan Moren for Six Colors:

But what fascinates me here is the bigger message: that the most profitable and arguably most powerful technology company in the world firmly believes that technology alone simply isn’t good enough for these sorts of determinations. I don’t think it’s necessarily a view you’d hear espoused at the highest levels of Google, for example.

First thought I had: I’m curious to see how they will curate the Technology section in Apple News.

Permalink

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

Twitter Removing the 140 Character Limit from Direct Messages→

With a post on the Twitter Developers forum yesterday, Product Manager for Direct Messages Sachin Agarwal has announced that Twitter will be removing the limit of 140 characters from DMs this summer:

We’ve done a lot to improve Direct Messages over the past year and have much more exciting work on the horizon. One change coming in July that we want to make you aware of now (and first!) is the removal of the 140 character limit in Direct Messages. In order to make this change as seamless as possible for you we’ve included some recommendations below to ensure all your applications and services can handle these longer format messages before we flip the switch.

When I first read this, I felt skeptical. Much of Twitter’s appeal to me lies in the streamlined approach to short messages that fly by in the timeline. But, some of my most important conversations over the years have started from Twitter DMs. From this standpoint, it’s surprising that Twitter hasn’t put more thought in the DM product as a messaging platform, alienating users who were looking for a direct, nimble communication system – and pushing them to other services.

The strength of Twitter DMs is, for me, the existing graph between users (people I’m interested in), speed, and the lack of baggage from email. Lately, I’ve come to like the ability to easily share links and pictures in DMs as well. I don’t know if raising the character limit to 10k characters will by itself improve DMs, but Twitter is wasting an opportunity with DMs, so maybe their new CEO could use this as a starting point.

Permalink

Julie Adenuga, Apple’s New DJ→

I’m fascinated by Apple’s choice to pick Julie Adenuga as the DJ for Beats 1 in London. I wasn’t familiar with her work before, but she seems exactly like the type of music expert and entertainer that could make Beats 1 an important part of Apple Music. The Fader profile on her contains a lot of interesting details:

Adenuga’s radio career began at Rinse FM in 2010, shortly before the UK pirate station got its official FM status. Along with her BFF Sian Anderson—now a BBC Radio 1Xtra DJ—she took a gamble on asking the station managers for a show, despite having zero experience. “We didn’t have a clue what we were doing,” Adenuga remembered in her official Rinse bio a couple of years ago. The pair went in to record their first show armed with nothing but great taste in music and a willingness to chat for hours. A producer showed them how to operate a CDJ on the fly, because they couldn’t mix; “we’d just stop and start tunes. We had no DJ experience, but we just played the music and were talking rubbish. It worked. Luckily.” Bringing the rare combination of fire music selections and a banging sense of humour to the station, Adenuga and Anderson hosted a show called Mewzik Box from 2010 - 2011, taking a weekly 11am - 1pm slot.

Noisey has also a good article on Adenuga’s career.

Permalink

Connected: We Should Start a Bank Rumours Website→

(Mostly) live from San Francisco, the guys talk about all things WWDC 2015, including new versions of OS X and iOS, improvements to the iPad and the introduction of Apple Music.

In this week’s Connected, I talk about the potential for Search in iOS 9, discuss the implications of iPad multitasking, and share my thoughts on the Apple Music introduction. It’s a good one. You can listen here.

Sponsored by:

  • Field Notes: Buy a year-long Colors subscription starting with the Workshop Companion, and use the code ‘RELAY’ and you’ll get 3 Carpenter Pencils and a 3-Pack of “Pitch Black” memo books free.
  • OmniFocus from The Omni Group: Now on the Apple Watch.
  • Igloo: An intranet you’ll actually like, free for up to 10 people.
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

Metal for OS X→

I worried that “Metal” had become Apple’s version of “Blast Processing,” a catch phrase in the 90s for the Sega Genesis. In commercials, Sega would gloat that only the Genesis had “Blast processing.” The only problem was, Blast Processing didn’t really do anything that mattered.

But it turns out, I was wrong.

Metal for OS X is huge — and it’s going to be a much bigger deal on the Mac than it is on your iPhone or iPad. If you use a Mac to produce professional content, chances are, Metal is about to drastically speed up the professional apps you use like Adobe Illustrator and Autodesk Maya.

Writing for iMore, Brianna Wu explains why Metal for OS X – announced at WWDC 2015 – will be a big deal for games and professional apps on the Mac. It was great to see Campo Santo in Apple’s slides, too.

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

App Thinning and iOS 9→

Apple already talked in the keynote about how it had reduced the amount of space required the iOS 9 OTA update from around 4.6GB to 1.3GB, but a more transformative technology only got a passing mention: App Thinning. In short, apps in iOS 9 will leave your phone or tablet with more free space in the first place.

Say you have an iPhone 5C, which uses a 32-bit CPU and a GPU that doesn’t support the Metal API. Download a modern universal game, and that binary includes 64-bit code, iPad and “3x” iPhone 6 Plus assets, and Metal API code that it doesn’t need. It only needs the 32-bit code, “2x” iPhone-sized assets, and the OpenGL graphics code. App Slices will let your device download just the chunks your device needs.

Andrew Cunningham has a good overview of the developer features powering App Thinning, Apple’s effort to reduce app sizes in iOS 9.

I forgot that I had a similar idea in 2012, when Apple was rumored to introduce a Retina iPad that would increase app sizes going forward (as it did). I wrote:

I see two solutions. Either Apple gets the carriers to agree to larger download sizes, establishing a new “average” that should work for most apps (let’s say 60 MB as Panzarino suggests), or they rebuild the download mechanism completely by allowing devices to “ignore” resources they don’t need. The second solution would be a “cleaner” approach, in that it would address the root of this likely scenario – that is, devices downloading apps containing all kinds of images and resources for Retina and non-Retina displays.

By “localizing” images in a way languages are localized on the OS, Apple could find a way to know if an image is destined to an iPad or not. And if so, if it’s also destined to a Retina iPad, or old-generation iPad. Furthermore, in theory, this would also allow Apple to differentiate between images used by an iPhone and iPad which, right now, are always downloaded within the same, single .app package.

App Thinning – and the three core features behind it – sound promising, but we’ll have to assess their effects in practice and wait to see how many developers start supporting them. Apple doesn’t seem to be willing to discontinue lower capacity iOS devices, but at least they’re trying to save space in other ways.

Permalink