Fatbobman:
However, the release of iOS 18 cast a shadow over this beautiful vision. A year after its first appearance, SwiftData underwent a major underlying refactoring. Although this adjustment was aimed at shifting from a strong coupling with Core Data to supporting more flexible multi-persistence solutions—a direction undoubtedly correct—it seems that the significant changes led to considerable impact on the new version’s stability.
Disappointingly, a large amount of SwiftData code that ran well on iOS 17 encountered various problems in the new version. For a data persistence framework that shoulders heavy responsibilities, these issues are undoubtedly fatal. What’s more worrying is that the complexity of these problems means they may not be thoroughly resolved in the short term. It is foreseeable that throughout the iOS 18 cycle, developers choosing to use SwiftData will have to continuously grapple with these challenges.
[…]
SwiftData’s performance on iOS 18 put me in a dilemma. For an application centered on data management, stability and reliability are non-negotiable. After repeated deliberation, I had to make a tough decision: abandon the thousands of lines of SwiftData code I had completed and return to Core Data.
[…]
When rebuilding the Core Data project, I decided to integrate the modern thinking I learned from SwiftData, using a more innovative approach to harness this time-tested framework.
Personally, I think the sweet spot is using mature frameworks like Core Data and Cocoa from Swift. Apple hasn’t done as much as I’d hoped to make this ergonomic, but there’s a lot you can do yourself. I actually go further than the example here and make all managed object initializers take the required attributes plus the context as arguments.
Previously:
Update (2024-10-17): See also: Hacker News.
Core Data iOS iOS 18 Mac macOS 15 Sequoia Programming Swift Concurrency Swift Programming Language SwiftData
Azad Balabanian (via Federico Viticci):
The Vision Pro has quickly become an essential item that I take onto every flight.
It’s a fantastic device to travel with—Be it by train or by plane, it offers an unparalleled opportunity to selectively tune out your environment and sink into an engaging activity like watching a movie or just working on your laptop.
In this blog post, I’ll outline what I’ve learned about the Vision Pro while traveling, explain some of the functionality, shine light onto its drawbacks, as well as assess how it fares against solutions like a phone or a laptop.
[…]
The problem is that for meals that require eyesight to coordinate (aka using a fork to pick up food from a plate), as soon as you look down at your food, the tracking often gets lost. This causes the movie to stop playing and for you to have to look forward for the tracking to re-initialize.
[…]
Here, it doesn’t matter what my front seat neighbor does, I can just tilt my screen down, place the laptop on my lap or tray, pull up a virtual monitor, and get to work.
He uses a generic lens protector instead of the bulky Apple case, adds an Anker battery bank, and uses an extra third-party strap to make it more comfortable.
Airplane Apple Vision Pro Mac macOS 15 Sequoia Travel visionOS visionOS 2
Filipe Espósito (Hacker News, MacRumors, Dan Moren):
As just announced by the FIDO Alliance, the new specifications aim to promote user choice by offering a way to import and export passkeys. The draft of the new specifications establishes the Credential Exchange Protocol (CXP) and Credential Exchange Format (CXF) formats for transferring not only passkeys, but other types of credentials will also be supported.
[…]
1Password, which worked with the FIDO Alliance on the new specifications, has already committed to supporting the new passkey import and export formats as soon as they become available. Other companies such as Dashlane, Bitwarden, NordPass, and Google also worked on the draft of the new specifications.
Although nothing has been said about Apple, the company is also part of the FIDO Alliance and was one of the first to introduce support for passkeys in 2022 with iOS 16.
I don’t love this framing because, to me, “export” means that it generates a standalone file that I can do with what I please. I can edit it. Or back it up and import it later—possibly into a different app. As far as I can tell, this is not that. It’s more of a way to transfer passkeys between password managers. It’s specifically designed to “export” an encrypted blob that can only be read by the password manager that requested the export. There’s no use even storing the exported file because, unless you have a way to back up the receiving private key, you won’t even be able to import it again. Maybe a third-party developer will make an app that requests/receives an export and lets you access your own data.
Jeff Johnson:
Export and import should have been extremely simple. Instead, they took years to come up with some convoluted system where the only possibility is to transfer from one vendor lock-in to another vendor lock-in.
The FIDO Alliance would probably say that not allowing true exporting makes it more secure, but I think that’s only true in a kind of security-through-obscurity way. If you make an encrypted happy path for transferring credentials, people will use it because it’s easier. Credential exchange does open the way for people to get at the decrypted data—it just makes it a pain and requires trusting an additional helper app. (Or are they going to somehow prevent non-big-players from participating?) If someone has direct access to my Mac and unlocked password manager, it’s game over, anyway. So I fail to see what this is really protecting against. Do they think people will export CSV files and leave them on unencrypted storage?
Jay Peters:
“It is critical that users can choose the credential management platform they prefer, and switch credential providers securely and without burden,” the FIDO Alliance wrote in its press release.
It’s about platforms, not giving you control of your data.
Martin Pilkington:
This is a big improvement, but I’m still very wary of any authentication system whose secret I can’t easily write down on a piece of paper.
Yes that may seem insecure, but I would also consider having a system that pretty much only major vendors can support to also be insecure in other ways. Loss of access is just as bad as being hacked as an authentication failure point.
I really want to like Passkeys given they’re technically much better, but their flaw is they require you to trust Big Tech (and do so in a far more important way than with passwords). Unfortunately Big Tech has used up pretty much all its remaining trust budget 🤷♂️
Phil Dennis-Jordan:
I particularly resent how they’re treating their proprietary, heavily networked implementations in always-connected devices as superior to a mostly-airgapped FIDO2 device. Those USB key like devices don’t have great UX, but I’d rather see some iteration on that idea than allowing Big Tech to silently sync (i.e. delete, copy, insert, etc.) those secrets in my phone.
Micah R Ledbetter (via Hacker News):
Passkeys are a technically interesting idea with many upsides, but I am concerned about the power they take away from users.
[…]
The passkey spec is designed intentionally such that:
- Sites that use passkeys, like your bank, can tell what app you keep your passkeys in
- Site that use passkeys can choose to support some apps and not others
This is not a hypothetical concern –
it’s being discussed today with regard to the open source KeePassXC app.
[…]
The second ticket linked above makes it clear that sites are prepared to block passkey apps not just for their default settings, but for allowing certain actions to happen at all. In that ticket, the concern is that passkeys can be exported without being encrypted.
tadfisher:
There are FIDO Alliance folks posting Github issues requesting to remove features such as plaintext exporting of credentials, with the explicit threat that the Alliance might block such “open” passkey providers in the future. A local database is not enough, it needs to be locked in a secure element or protected with some TPM-like scheme.
The spec allows for hardware attestation as well, to ensure passkeys are being provided from blessed computing environments. Hopefully implementers continue to ignore this anti-feature, because it’s entirely stupid to lock out users who want to control their own security; at the same time, letting anyone with an Android phone restore passkeys from the cloud with one of their device PINs.
Terr_:
I would also be concerned about whether you can recover when a provider becomes unusable or hostile, and there is no cooperative migration path.
That might be the company going bankrupt, a physical or digital disaster, geopolitical firewalls, or simply a Kafka-esque bureaucracy where your entire account has been deleted without appeal because the company decided it was easier than figuring out the truth behind some moderation issue.
David Heinemeier Hansson (Lobsters):
We had originally planned to go all-in on passkeys for ONCE/Campfire, and we built the early authentication system entirely around that. It was not a simple setup! Handling passkeys properly is surprisingly complicated on the backend, but we got it done. Unfortunately, the user experience kinda sucked, so we ended up ripping it all out again.
The problem with passkeys is that they’re essentially a halfway house to a password manager, but tied to a specific platform in ways that aren’t obvious to a user at all, and liable to easily leave them unable to access of their accounts. Much the same way that two-factor authentication can do, but worse, since you’re not even aware of it.
Vincent:
With this blog post, I want to share with you the learnings on my way when working on a passkey-first auth solution and passkey intelligence with Corbado. All the hard truths, the unknown unknowns (factors that were not anticipated prior to my experience, essentially things we did not know we did not know), and the misconceptions should be uncovered, so that you know what to consider when implementing your own passkey-based authentication.
[…]
Implementing passkeys in a real-life project is 100x harder than you might initially think (trust us – we’ve gone through it).
Jeff Johnson (Mastodon, Hacker News):
I don’t want to place my credentials database under someone else’s control and because I don’t trust the availability and reliability of cloud sync. I prefer to manage credentials myself. Thus, I was surprised to find two passkeys in the “Passkeys Information.csv” file. I don’t recall ever creating a passkey.
[…]
What I didn’t realize until now is that enabling iCloud Keychain also automatically generated apple.com passkeys. I must have missed it at the time or forgot, but Apple automatically assigned passkeys to users of iOS 17, iPadOS 17, and macOS 14 Sonoma. Since passkeys require iCloud Keychain, it makes sense that this happened the exact same time that iCloud Keychain was (forcibly) enabled on my iPad. However, I seem to have lost the passkeys when I manually disabled iCloud Keychain, because the new Passwords app in iPadOS 18 shows zero passkeys. I have no idea how to revoke the lost credentials on Apple’s systems.
My question is, why does Apple have all of this personal, private information, stored in plain text?
Previously:
Update (2024-10-17): Dimitri Bouniol:
For what its worth, exporting passkeys is non-trivial, because authenticators are sometimes expected to count how many times they’ve signed a challenge, specifically so the server can ensure it hasn’t been copied and used on the side by a non-trusted 3rd party 😔
1Password Apple Password Manager iCloud Keychain iOS KeePass Mac Passkeys Privacy Security Web
Howard Oakley:
When you create the disk image, macOS creates and attaches its container, and creates and mounts the file system within that. This is then saved to disk as a regular file occupying the full size of the disk image, plus the overhead incurred by the disk image container itself. No sparse files are involved at this stage.
When that disk image is mounted next, its container is attached through diskarbitrationd, then its file system is mounted. If that’s APFS (or HFS+), it undergoes Trimming, as with other mounts. That coalesces free storage blocks within the image to form one contiguous free space. The disk image is then saved in APFS sparse file format, skipping that contiguous free space. When the file system has been unmounted and the container detached, the space used to store the disk image has shrunk to the space actually used within the disk image, plus the container overhead. Unless the disk image is almost full, the amount of space required to store it on disk will be smaller than the full size of the disk image.
[…]
The size of read-write disk images is therefore variable depending on the contents, the effectiveness of Trimming in coalescing free space, and the efficiency of APFS sparse file format.
[…]
Although read-write disk images stored as sparse files are efficient in their use of disk space, they’re still not as compact as sparse bundles.
Howard Oakley:
Read speeds for sparse bundles and read-write disk images were high, whether the container was encrypted or not. On the internal SSD, encryption resulted in read speeds about 1 GB/s lower than those for unencrypted tests, but differences for the external SSD were small and not consistent.
Write speeds were only high for sparse bundles, where they showed similar effects with encryption. Read-write disk images showed write speeds consistently about 1 GB/s, whether on the internal or external SSD, and regardless of encryption.
When unencrypted, read and write speeds for sparse (disk) images were also slower. Although faster than read-write disk images when writing to the internal SSD, read speed was around 2.2 GB/s for both. Results for encrypted sparse images were by far the worst of all the tests performed, and ranged between 0.08 to 0.5 GB/s.
Surprisingly good results were obtained from a new-style virtual machine with FileVault enabled in its disk image. Although previous tests had found read and write speeds of 4.4 and 0.7 GB/s respectively, the Sequoia VM achieved 5.9 and 4.5 GB/s.
Sparse bundles generally have the best performance, though plain read-write images can be faster for reading. Single-file sparse disk images are slow.
Howard Oakley:
If you’re going to use disk images of any type, then getting the right tool for the job is essential. This article considers the leading candidates:
- Disk Utility, bundled with macOS
- DropDMG, $24.99 from C-Command, or from the App Store
- Spundle, free from its Product Page here
hdiutil, the command tool bundled with macOS.
Previously:
Apple File System (APFS) Disk Image DropDMG Mac macOS 12 Monterey macOS 15 Sequoia Virtualization
