Tech —

RAW shooting, a harsher Gatekeeper, and more obscure macOS and iOS 10 changes

We went digging for the features that nerds will care the most about.

The onstage presentations don't encompass every new feature in iOS 10 and macOS Sierra.
Enlarge / The onstage presentations don't encompass every new feature in iOS 10 and macOS Sierra.
Andrew Cunningham

When Apple announced iOS 10 and macOS Sierra at its WWDC keynote yesterday, it hit most of the high notes. Big user-facing features like the Siri API on iOS and Siri on the Mac, the revamped Messages app, Universal Clipboard, and tweaks to Photos and Apple Music got stage time, but as the company said, there was more stuff that didn’t get any attention.

Our previews and reviews of the beta and final versions of the OSes will cover all of those features and lots of the smaller, less notable tweaks to Apple’s built-in apps, but, after a few hours of digging through the developer documentation, we’ve also unearthed a few neat under-the-hood tweaks in both Sierra and iOS 10.

iCloud syncing without the Mac App Store

Can someone check the Mac App Store’s pulse? I’m worried about it.

iCloud API support was one of the carrots that Apple has offered to developers in the Mac App Store as a way of compensating for the sandboxing stick. Sierra removes that particular requirement; now, any app signed with a valid Developer ID can use CloudKit, iCloud Keychain, iCloud Drive, push notifications, MapKit, and VPN entitlements in their apps.

This will hopefully increase the extent to which these features are used in OS X apps, as well as provide some cloud infrastructure to independent developers who want to offer cloud storage and other services without dealing with the Mac App Store. None of it is available for unsigned apps, though, and anyone developing unsigned apps (or using unsigned code or disk images alongside a signed app) will have more hoops to jump through in Sierra.

Gatekeeper tweaks

The Gatekeeper feature in Sierra can't be disabled entirely, at least not in the GUI.
Enlarge / The Gatekeeper feature in Sierra can't be disabled entirely, at least not in the GUI.

Since it was introduced in Mountain Lion, the Gatekeeper security feature in OS X has always offered an option to completely disable it. In the first Sierra beta, this is no longer the case—you can let your Mac run only apps from the Mac App Store or App Store apps along with properly signed apps from outside the App Store (the latter is the default, as it has been since the feature was introduced).

Don’t panic. You can still run unsigned apps by right-clicking (or control-clicking) on them and clicking Open, and after you’ve run them once they’ll continue to run without issue. And disabling Gatekeeper entirely via the terminal with the sudo spctl --master-disable command is also still possible. But obviously Apple wants most people to leave Gatekeeper enabled to lessen the chance that they’ll run some insecure app.

If you sign your apps but happen to modify them after signing them, or if your signed app runs unsigned code from a zip file or disk image, Gatekeeper’s behavior has also changed. Every time you launch a signed app, it’s actually launched from a randomized path somewhere on your hard drive. To the user, they’ll still appear as though they’re in your Applications folder or wherever you’ve put them, but under the hood it will actually be launched and run from somewhere else, deterring attacks that rely on a particular app being stored at a particular or fixed path. According to Apple, this renders apps incapable of executing external code. This can be rectified if you offer the code within a signed disk image or via the Mac App Store.

Aside from the security features, the changes to Gatekeeper send a subtle message from Apple to developers: we can’t make you use the Mac App Store, but we can at least try to make you sign your apps.

Time Machine over SMB and the slow death of AFP

Server Message Block (SMB, sometimes known colloquially as "Windows file sharing") became the default network file sharing protocol in OS X back in 2013, replacing the Apple Filing Protocol (AFP). But for a long time, being the "default" didn't really mean anything; AFP support was still present, still did all the stuff it used to do, and was still in fact required for things like networked Time Machine backups. SMB supported encryption while AFP didn't, but for simple home sharing, being "deprecated" didn't make much of a difference.

In Sierra, we're starting to see some practical effects of that decision. The release notes for the OS X Server 5.2 beta are enlightening—one of the testing focus areas is "Time Machine backup using SMB," implying that Time Machine backups will soon work over SMB without any of the hacky workarounds currently required. Whether this just means that Time Machine will work over Apple's in-house version of SMB or that it will also extend to Windows' implementation or open source Samba implementations isn't clear, but it's a step in that direction regardless.

And there are signs elsewhere that SMB is being built up while AFP is left to rot. AFP shares won't work on APFS formatted drives. SMB signing, a security feature, is now required by default. It's all little stuff, but bit by bit the venerable AFP protocol is fading away.

New file system: APFS

We have already written about this one pretty extensively, so I won't dwell long on it here, but John Siracusa's dream has finally been realized (kind of): Apple has a new file system, and it's going to start using it on all of its devices from the Apple Watch all the way up to the Mac Pro.

Lest you get too excited, it doesn't look like APFS is going to become the default option on Macs or anything else this year—Apple has said that it’s coming in 2017, and you’ll be able to convert your existing HFS+ partitions without data loss. The version in the first developer build can't be used as a boot drive, among many other things, and you need to format disks with it using the command line. But it's definitely coming, and it should definitely add some useful new features once it's here in earnest.

RAW and DCI-P3 image capture support

Apple's table of iDevice camera capabilities.
Enlarge / Apple's table of iDevice camera capabilities.
Apple

Apple spent a bunch more time on iOS than any of its other operating systems yesterday, so there’s less to dig up on that side. Here’s a good one: a new class called AVCapturePhotoOutput will let camera apps capture RAW photo data from certain iPhone and iPad cameras.

For the layperson, a simplified explanation: RAW files have much larger file sizes than the standard JPGs that the built-in Camera app spits out, but they also retain every scrap of data that the sensor picked up when the picture was taken. When you need to make more extreme changes to white balance, contrast, exposure, and other settings, having all of that extra data makes a big difference.

Android has had a RAW shooting API since version 5.0 was released in late 2014, but this is the first time anything like it has been available to iDevices. It’s limited to the very newest hardware, though. According to this Apple page that details the camera capabilities of various iPhones and iPads, the only devices that will offer RAW shooting are the iPhone 6S, 6S Plus, and SE, and the 9.7-inch iPad Pro. And on all of those devices, only the rear camera can shoot RAW, not the front.

The 9.7-inch iPad Pro can also shoot photos using the wider DCI-P3 color gamut, a feature that some high-end Apple hardware has picked up in the last year. Only that iPad and the 4K and 5K Retina iMacs will be able to display that extra color data. Apple has also expanded support for DCI-P3 in the graphics stack in macOS 10.12 and iOS 10—this applies to Core Graphics, Core Image, Metal, and AVFoundation (a key framework for viewing and editing video).

Both RAW and DCI-P3 support will likely become available to more devices as new hardware is released. For now, it’s only something you can enjoy if you’ve got newer stuff.

Channel Ars Technica