Archive for December 2, 2016

Friday, December 2, 2016

The RawRepresentable Protocol in Swift

Ole Begemann:

Note that adding raw values to an enum doesn’t affect how the enum is laid out in memory. The compiler always determines how many bits it needs to discriminate between all enum cases and then assigns a unique integer tag value to each case. Even for enums with integer raw values, this tag is not the same as the raw value — they are completely different things. This also means you don’t have to worry that an enum with strings as raw values will take up more memory than a “plain” enum — the constant strings are only stored once in the binary, not for each instance.

[…]

In fact, the raw value syntax is simply shorthand for conforming the enum to the RawRepresentable protocol, which defines the rawValue property and initializer. When you define the above enum, the compiler generates code equivalent to this[…]

[…]

Once you realize that there’s no magic behind enums with raw values, it opens up the possibility to use all kinds of types as raw values.

File Reference URLs Don’t Work in Swift 3

SR-2728:

In Swift 3.0 (i.e. Xcode 8.0 or Xcode 8.1 beta 1), a call to fileReferenceURL does not give a file reference URL anymore... this code

import Foundation
let string = "file:///Users/admin"
if let url = NSURL(string: string) {
  if let ref = url.fileReferenceURL() {
    print ("ref = (ref)")
  }
}

prints

ref = file:///Users/admin/

while it should have been printing

ref = file:///.file/id=6571367.437879/

as it did, correctly, in Swift 2.2 (and before) in Xcode 7.3.1 for example.

Via Charles Srstka:

.fileReferenceURL doesn’t exist on URL. It does exist on NSURL, but thanks to the bridging magic it returns a URL, which the ObjC-Swift bridge turns into a normal file path URL.

Frédéric Blondiau has some workarounds, but these are distasteful to me because they rely on the internal details of both NSURLFileResourceIdentifierKey and file reference URLs.

It seems like the proper short-term solution would be to write some Objective-C code to return an object that is not bridged to URL. This could probably be the actual NSURL typed as id. Or, if you’re going to use an opaque token anyway, another option would be to store bookmark data. I assume that would be slower, though.

Update (2018-09-08): Christian Tietze:

Swift 4.1 has a simpler mechanism to ensure you get a NSURL instead of a URL – the only type that supports file reference URLs as of September 2018, still.

if let fileRefURL = (url as NSURL).fileReferenceURL() as NSURL? { 
    print(fileRefURL)
}

Try that in the Swift 4.1 REPL to see that it works. Whew.

I do understand that there may be reasons to remove fileReferenceURL from URL and leave it on NSURL, but when you do invoke it on NSURL, I think it should at least return another NSURL object that works as expected instead of bridging to Swift’s URL struct that, for some reason, won’t work.

Update (2019-01-08): Jens Ayton:

No, wait! It actually crashes when you bridge the file reference NSURL to URL.

Status Board Discontinued

Cabel Sasser (MacRumors):

Unfortunately, while Status Board became a beloved friend to offices around the world, sales weren’t enough to sustain further development.

[…]

First, we had hoped to find a sweet spot between consumer and pro users, but the market for Status Board turned out to be almost entirely pro, which limits potential sales on iOS — as we’ve learned the hard way over the past couple of years, there’s not a lot of overlap right now between “pro” and “iOS”. Second, pro users are more likely to want a larger number of integrations with new services and data sources, something that’s hard to provide with limited revenue, which left the app “close but not quite” for many users. Finally, in the pro/corporate universe, we were simply on the wrong end of the overall “want a status board” budget: companies would buy a $3,000 display for our $10 app.

JM:

You should have done a native Apple TV version of this when it became possible. Would make total sense to me.

Cabel Sasser:

Apple never provided an official WebKit view for Apple TV apps, and Status Board depends heavily upon them, for custom panels, etc. So unfortunately, it wasn’t possible to port an Apple TV version, even though that would make the most sense…

Amazon Fire TV Stick 2

Joe Rosensteel:

Apple doesn’t offer anything remotely in this price range [$30]. The 3rd generation Apple TV was discounted to $70, and then discontinued this September without any replacement, leaving the $150 4th generation Apple TV as the least expensive streaming device Apple makes. It’s also not as portable as an HDMI stick device.

[…]

I certainly think that if you’ve been frustrated by trying to AirPlay Amazon Video that you should purchase this, because I don’t think hell is going to freeze over any time soon.

If someone isn’t an Amazon Prime member, or they want to exclusively use iTunes media, then this isn’t a good option. If you want HBO, Netflix, and Prime video with voice search at a relatively inexpensive price-point, then this is the best option, and I would encourage you to consider it before the sale ends.

The Limitations of Android N Encryption

Matthew Green:

Android’s early attempts at adding encryption to their phones followed the standard PC full-disk encryption paradigm. Beginning in Android 4.4 (Kitkat) through Android 6.0 (Marshmallow), Android systems shipped with a kernel device mapper called dm-crypt designed to encrypt disks at the sector level.

[…]

In principle, a clever implementation could evict sensitive cryptographic keys from RAM when the device locks, then re-derive them the next time the user logs in. Unfortunately, Android doesn’t do this — for the very simple reason that Android users want their phones to actually work. Without cryptographic keys in RAM, an FDE system loses access to everything on the storage drive. In practice this turns it into a brick.

[…]

In the Apple system, the contents of each file is encrypted under a unique per-file key (metadata is encrypted separately). The file key is in turn encrypted with one of several “class keys” that are derived from the user passcode and some hardware secrets embedded in the processor.

[…]

By giving developers the option to individually protect different files, Apple made it possible to build applications that can work while the device is locked, while providing strong protection for files containing sensitive data.

Apple even created a fourth option for apps that simply need to create new encrypted files when the class key has been evicted from RAM. This class uses public key encryption to write new files. This is why you can safely take pictures even when your device is locked.

[…]

If you’re an optimistic type, you’ll point out that Android is clearly moving in the right direction. […] On the other hand, you might notice that this is a pretty goddamn low standard. In other words, in 2016 Android is still struggling to deploy encryption that achieves (lock screen) security that Apple figured out six years ago.

Copyright © 2000–2024 Michael Tsai.