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.
Update (2024-10-18): Peter Steinberger:
So a year in, SwiftData is now worse than it was in the initial release?
Honestly, don’t trust Apple there, use something open source that is properly maintained and has tests, like GRDB.
Update (2024-11-08): See also this thread from Steve Troughton-Smith:
What’s the consensus on SwiftData? Are any big apps using it? Does it have blockers or major issues to worry about?
Uhl Albert:
SwiftData performance was so bad on iOS 17 that I switched my app to CoreData to make it usable. I submitted two test projects to Apple code-level support. They acknowledged the problem and advised me to “try it in iOS 18 beta.”
I did, and while there was much less lag, memory usage was still double that of CoreData.
Here’s my Apple Dev Forum thread with more details and links to the test projects.
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 😔
Update (2024-10-18): Lawrence Abrams:
Amazon has seen massive adoption of passkeys since the company quietly rolled them out a year ago, announcing today that over 175 million customers use the security feature.
I would not call it quiet since when users log in it prompts them to add a passkey. If you don’t store cookies it will ask you every time.
Kyle Howells:
This is a worrying decree of platform lock-in.
I expect a lot of issues when people lose access to their devices or try to login from a new computer.
Currently, this is not an issue because Amazon allows both password and passkey access to the same account (thus negating some of the benefits of passkeys). But the goal is for passkeys to replace passwords, and some sites already prevent you from using both. So backup and transfer of passkeys are very important.
Apple’s Ricky Mondello has been entertaining my questions about this. My conclusion is that the current situation (pre-CXF and CXP) is not good. You have very little control over your passkeys and can easily get into trouble if something goes wrong. There is always the option of using recovery, e.g. sending a special link to your e-mail, to generate a new passkey. Some people do this as a matter of course whenever they need to log in because they don’t remember their passwords. This horrifies me, as I think of passwords more as irreplaceable secrets to be carefully guarded. Recovery via e-mail (or postal mail) does not easily scale to large numbers of logins, and I don’t think it’s very secure, as people often leave their mail open on an unlocked device. And, as passkeys replace passwords, it may be difficult to access your e-mail without a passkey, creating a circular problem.
When Credential Exchange becomes available, I think it will help a lot, though I still have some concerns.
The Passwords app seems unlikely to support backups directly, so you would need to periodically export manually to maintain control of your data. Will this be limited?
As I suggested in the initial post, it will be possible to write an app that lets users truly export their data, not just transfer it. I was worried that, because sites can block certain authenticators, such an app might only be useful as a utility and could not be used as an actual password manager. It seemed that this was being used to pressure KeePassXC into not allowing exports. However, Mondello says that the identification is “extremely intentionally, an optional unattested hint string.” In other words, like a Web browser’s “User-Agent,” the password manager could identify itself however it wants.
I still don’t like that sites get to see which password manager I’m using. This is a privacy violation, as I doubt the big players are going to let me use a custom user agent. But if this is at least possible (in future versions or with indie password managers) it would prevent users from being locked out due to sites not liking a particular authenticator or big players going to war with each other.
At this point, I would say that I’m cautiously optimistic. However, the whole passkeys system is so complex that I’m sure there are important questions that I don’t even know to ask and failure modes I haven’t considered.
Jeff Johnson:
The credential exchange protocol introduces phishing to passkeys.
What stops an attacker from tricking a victim into approving a transfer of passkeys to a credential provider under the control of the attacker? I’ve read the working drafts, and they’re appalling terse on the subject of security considerations.
John Gruber (Mastodon):
I don’t have strong feelings about passkeys, but I am vaguely unsettled by them. There’s no way to use passkeys without using a proper password manager, like Apple Passwords with iCloud Keychain, or 1Password. But if you’re using a proper password manager, your passwords should all be unique and random, and you should have convenient access to 2FA codes. So what’s the point of passkeys if they can only be used by people who are already using a good password manager? Perhaps the thinking is that too many users just can’t be budged from the risky habit of using passwords they have memorized, and passkeys are a way to break that habit because they can’t be memorized.
The main benefits vs. a password manager seem to be that users can be phished and convinced to bypass the safe auto-fill and that incompetent sites store unsalted passwords, which can then be leaked.
John Gruber (Mastodon):
A friend texted me with another argument for passkeys: it’s somewhat common for websites to break password autofill. Maybe it’s deliberate, in the name of fighting bots? But whether deliberate or not, with passkeys, they have to work with your browser’s connected password manager. So maybe passkeys are a net win for convenience, even for technically-knowledgeable users who are unlikely to fall for phishing scams.
They are also more convenient than 2FA.
Alex R:
I think a lot of the passkey discourse(™) comes about because we’re a cohort of highly technical early adopters who already have password managers set up with sync, autofill, and two-factor auth. For those users, passkeys might lack some features (although I think the gaps are being filled rapidly there), but they aren’t really the people for whom passkeys are a big improvement.
opoto:
From the other side of this correct consideration, the point is to explain to the non tech users that from now they will need to use a password/passkey manager. This introduces complexity for them.
Miguel Arroz:
A bit of feedback: the main problem to me is not the security factor (passkeys are more secure than passwords, period) but the apparent lack of control and ownership of my credentials.
[…]
Why is an Apple platform, macOS, seemingly intentionally hiding my own credential to my Apple account, at least in the Passwords app?
Update (2024-10-23): See also: Dithering.
Update (2024-11-05): Chris Adamson:
Cool new bits that just went up in AuthenticationServices: ASCredentialExportManager and ASCredentialImportManager. This will allow password manager apps on macOS/iOS/visionOS to exchange credentials like passwords and passkeys. Cool thing is, OS acts as an intermediary between the two apps, and none of your credentials are written to the filesystem mid-flight.
They are Swift-only.
1Password Apple Password Manager iCloud Keychain iOS KeePass Mac Passkeys Passwords Phishing Privacy Security Top Posts Two-Factor Authentication (2FA) 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:
Update (2024-10-18): Howard Oakley:
While this remarkable bug is present in macOS Sequoia 15.0 and 15.0.1, I’m afraid its days are numbered. If you want to experience the TARDIS sparse bundle, you’ve only got another week or two, as it appears to be fixed in the current beta of 15.1.
Update (2024-10-21): Howard Oakley:
- Sparse bundles are more complicated than read-write disk images (UDRW), with band size to be set, and compaction to be performed.
- Default band size appears to work well, and manually setting band size should seldom be necessary.
- Both types appear highly efficient in their use of disk space, with only small differences between them.
- Although it might be important to compact sparse bundles in some cases, the amount of free space returned by compaction is unlikely to be significant in many circumstances.
Perhaps this is because we don’t have tools to defragment the free space on APFS volumes.
Previously:
Update (2024-12-17): Howard Oakley:
Sparse bundles (UDSB) remain generally faster in use than read-write (UDRW) disk images.
[…]
When sparse bundle performance is critical, it may be worth optimising band file size instead of using the default.
Apple File System (APFS) Disk Image DropDMG Mac macOS 12 Monterey macOS 15 Sequoia Virtualization
