Apple has updated its APFS Guide (via Thomas Zoechling):
APFS has case-sensitive and case-insensitive variants. The case-insensitive variant of APFS is normalization-preserving, but not normalization-sensitive. The case-sensitive variant of APFS is both normalization-preserving and normalization-sensitive. Filenames in APFS are encoded in UTF-8 and aren’t normalized.
HFS+, by comparison, is not normalization-preserving. Filenames in HFS+ are normalized according to Unicode 3.2 Normalization Form D, excluding substituting characters in the ranges U+2000–U+2FFF, U+F900–U+FAFF, and U+2F800–U+2FAFF.
The first developer preview of APFS, made available in macOS Sierra in June 2016, offered only the case-sensitive variant. In macOS 10.12.4, the APFS developer preview was updated to also include a case-insensitive variant. In iOS 10.3, the case-sensitive variant of APFS is used.
[…]
Directory hard links are not supported by Apple File System. All directory hard links are converted to symbolic links or aliases when you convert from HFS+ to APFS volume formats on macOS.
[…]
Apple plans to document and publish the APFS volume format specification when Apple File System is released for macOS in 2017.
Regarding the normalization issues that I raised last week:
Developers should be aware of behavior differences between normalization sensitivity and insensitivity which may arise when an iOS device upgrades to iOS 10.3 and migrates the filesystem from HFS+ to APFS. For example, attempting to create a file using one normalization behavior and opening that file using another normalization behavior may result in ENOENT, or “File Not Found” errors. Additionally, storing filenames externally, such as in the defaults database, CoreData, or iCloud storage may cause problems if the normalization scheme of the filename being stored is different from what exists on-disk.
But Apple doesn’t describe any solutions.
It’s also not documented how long APFS filenames can be. It would be nice to have an API for this.
Update (2017-03-31): I think “normalization-preserving, but not normalization-sensitive” means that (like HFS+ on the Mac, unlike APFS on iOS) you cannot have multiple files whose names differ only in normalization. And you can look up a file using the “wrong” normalization and still find it. Additionally, beyond what HFS+ offers, if you create a file and then read the directory contents, you’ll see the filename listed using the same normalization that you used.
Update (2017-04-02): Here’s a thread with someone confused because Apple’s guide said that using NSURL would handle the normalization issues, but it didn’t.
Update (2017-04-07): Howard Oakley:
The TL;DR is that both variants of APFS will cause problems – they are just different problems requiring different solutions. Either way, many current apps, tools, and scripts will perform strangely when run on APFS, and many will therefore need to be revised and updated to cope with it.
Update (2017-04-14): DropDMG 3.4.6 adds support for creating blank case-insensitive APFS disk images to help developers test their Mac apps with the new file system.
Update (2017-06-19): See also WWDC 2017 session 715.
Apple File System (APFS) DropDMG File System iOS iOS 10 Mac macOS 10.12 Sierra Programming Time Machine Unicode
Vincent Esche:
Now what If I told you that none of these hold true for Set<Float>, Set<Double>, and consequently Set<V>?
How can this be, given that both, Float and Double conform to Hashable (and therefor also Equatable), one of the (quite literally) key-requirements of Set<Float> and Set<Double>.
[…]
Yep, there’s indeed more than one NaN: a total of 8388606 of them in Float alone, to be specific. And even more of them are to be found in Double.
Update (2017-03-31): Joe Groff:
There’s WIP to make floats Equatable and Comparable using level 2 comparison (so NaN == NaN, NaN < number, -0 != 0)
That way you get sound behavior when floats end up in generic containers, but the expected level-1 semantics working concretely with floats.
Floating Point Language Design Programming Swift Programming Language
Jeff Carlson:
Luminar is a bold bet intended to compete against Photoshop — still the biggest gorilla in the jungle for professionals and enthusiasts — while also beckoning those who haven’t yet moved on from Apple’s long-discontinued Aperture. Luminar is also trying to appeal to casual photographers who want more image editing capabilities than Apple’s Photos. Plus, with its $69 price, Luminar hopes to appeal to the folks who don’t want to pay Adobe’s monthly or yearly subscription fee to use Photoshop.
[…]
One of the things I like about Luminar is that it’s relentlessly non-destructive. When editing photos, you don’t want to actually change the pixels in the original image, something older software did and many of Photoshop’s legacy controls still do. Non-destructive editing not only makes it easy to revert to the original and start over, but also change different aspects of what you’ve edited to that point.
[…]
It’s worth calling out the fact that Luminar does not attempt to manage your photo library. I normally wouldn’t even bring that up, since Luminar is an editing application, but Macphun has said that a future update will add library management, too. If you’re accustomed to managing, opening, and editing photos in Lightroom or Photos, it feels almost archaic to edit image files in another app.
Indeed.
Luminar Mac Mac App macOS 10.12 Sierra Photography
Twitter (tweet):
Now, when you reply to someone or a group, those @usernames won’t count toward your Tweet’s 140 characters.
[…]
Who you are replying to will appear above the Tweet text rather than within the Tweet text itself, so you have more characters to have conversations.
[…]
When reading a conversation, you’ll actually see what people are saying, rather than seeing lots of @usernames at the start of a Tweet.
OnLeaks:
Cool but this put a stop to the .@username trick... 😕 How to display replies to all our followers in our timeline now?...
Twitter (via MacRumors):
For the past seven years, everyone who has created an account on Twitter starts out with their default profile photo as an egg. This was a playful way to reference how eggs hatch into birds that send all the Tweets you see on Twitter! But now it’s time for something new – something that encourages people to upload their own photos for more personal expression. So today, we’re introducing a new default profile photo.
Twitter Web
Flickr:
In lieu of text comments, reactions also eliminate the need for translations. Now members from all over the world can come together through reactions to each others’ photos. The introduction of Reaction GIFs in the comment section will be the first step towards an image-only version of Flickr, because words simply aren’t enough anymore.
[…]
When the popup window comes up, a 5-second countdown will begin. Hurry up! Get ready! You will have 3 seconds to react while a video records. Once the video records, it will automatically process and post a GIF comment, saving the photo privately to your Camera Roll.
Flickr GIF Web
