Isn't this literally what SwiftData was made for?
November 20, 2025 at 9:48 PM
Isn't this literally what SwiftData was made for?
Understandable. And have you tried Menu or Confirmation Dialog with a custom subview inside, at the bottom? It would still morph, but at least "2025" would be part of it.
November 5, 2025 at 9:37 PM
Understandable. And have you tried Menu or Confirmation Dialog with a custom subview inside, at the bottom? It would still morph, but at least "2025" would be part of it.
you could use a popover instead
November 5, 2025 at 9:20 PM
you could use a popover instead
Liquid Glass is expensive. Battery lasts one hour less.
October 31, 2025 at 7:12 PM
Liquid Glass is expensive. Battery lasts one hour less.
That makes sense. Though I’m not sure why they went with this tiny performance gain only to turn iOS26 into a power hog 😆
October 31, 2025 at 4:45 PM
That makes sense. Though I’m not sure why they went with this tiny performance gain only to turn iOS26 into a power hog 😆
wait what? Why would it not trigger updates for equatable properties? Is that to say that the update will not trigger if an equatable property *is not* changed, i.e. newValue == oldValue?
October 31, 2025 at 10:16 AM
wait what? Why would it not trigger updates for equatable properties? Is that to say that the update will not trigger if an equatable property *is not* changed, i.e. newValue == oldValue?
linking to X from Bluesky?
a man in a military uniform is standing in front of a room with people sitting at tables .
ALT: a man in a military uniform is standing in front of a room with people sitting at tables .
media.tenor.com
October 28, 2025 at 8:16 PM
linking to X from Bluesky?
please please please make an iPad port, this would work really well on that platform (as do Crying Suns)
October 18, 2025 at 11:07 AM
please please please make an iPad port, this would work really well on that platform (as do Crying Suns)
Reason #379430 to not use Siri
September 25, 2025 at 9:07 PM
Reason #379430 to not use Siri
maybe something for @massicotte.org (or anyone else) to turn into a blog post. I just feel like this is not addressed as much as it should be, given how important it is. It's easy to think that "await" tells the actor to sit and twiddle its thumbs. Which is inaccurate.
September 21, 2025 at 8:39 PM
maybe something for @massicotte.org (or anyone else) to turn into a blog post. I just feel like this is not addressed as much as it should be, given how important it is. It's easy to think that "await" tells the actor to sit and twiddle its thumbs. Which is inaccurate.
I'm sorry you're having this trouble. I would start by checking the CloudKit dashboard, and verifying where the data actually gets stored (development or production). That will tell you a lot. Also, double-check that your Xcode is not inadvertently accessing the production version of CloudKit.
September 20, 2025 at 6:55 PM
I'm sorry you're having this trouble. I would start by checking the CloudKit dashboard, and verifying where the data actually gets stored (development or production). That will tell you a lot. Also, double-check that your Xcode is not inadvertently accessing the production version of CloudKit.
Before you do this, you should investigate the other part, which is that preview (in-memory) data should not be persisted, and therefore should not be backed up, and therefore should not be mixed in with your personal data in the development schema.
September 20, 2025 at 5:57 PM
Before you do this, you should investigate the other part, which is that preview (in-memory) data should not be persisted, and therefore should not be backed up, and therefore should not be mixed in with your personal data in the development schema.
Not at all. But I see you have no interest in a meaningful conversation. So we can leave it at that.
September 20, 2025 at 9:19 AM
Not at all. But I see you have no interest in a meaningful conversation. So we can leave it at that.
Yes, exactly! A version from Xcode and a version from App Store will sync from separate containers.
September 20, 2025 at 8:56 AM
Yes, exactly! A version from Xcode and a version from App Store will sync from separate containers.
By the way this is designed so you can tweak your model during development, before pushing it to users. After you push it, the model cannot be erased (though it can be expanded); this is to protect the integrity of your users' data :-)
September 19, 2025 at 9:01 PM
By the way this is designed so you can tweak your model during development, before pushing it to users. After you push it, the model cannot be erased (though it can be expanded); this is to protect the integrity of your users' data :-)
If you're using your own app, you should do it from TestFlight or App Store. That way, your personal data (as a user) and your debug data (as a developer) will never get mixed up, even if preview uses persistence by mistake or bug.
September 19, 2025 at 8:59 PM
If you're using your own app, you should do it from TestFlight or App Store. That way, your personal data (as a user) and your debug data (as a developer) will never get mixed up, even if preview uses persistence by mistake or bug.
Ah, that's your problem. Yes, there is a difference. When you develop your app and test CloudKit, everything sits in a separate (development) schema. When you are ready, you *manually* push your model to the actual (production) schema. Then, it can be used from TestFlight/AppStore.
September 19, 2025 at 8:58 PM
Ah, that's your problem. Yes, there is a difference. When you develop your app and test CloudKit, everything sits in a separate (development) schema. When you are ready, you *manually* push your model to the actual (production) schema. Then, it can be used from TestFlight/AppStore.
Mopping is actually disappearing pretty fast, what with half-empty office places and big robots in malls. Plumbing is where it's at.
September 19, 2025 at 7:22 PM
Mopping is actually disappearing pretty fast, what with half-empty office places and big robots in malls. Plumbing is where it's at.
I suppose that could happen with development version data if you're not using the in-memory store option. But your actual data (which should sit isolated in the production version of iCloud) should remain unaffected.
September 19, 2025 at 7:10 PM
I suppose that could happen with development version data if you're not using the in-memory store option. But your actual data (which should sit isolated in the production version of iCloud) should remain unaffected.
If you follow this default setup, it cannot happen that preview data populates your production data. It also cannot happen that simulator data populates your production data.
September 19, 2025 at 6:42 PM
If you follow this default setup, it cannot happen that preview data populates your production data. It also cannot happen that simulator data populates your production data.
When you or other people use your app, the data should be persisted in iCloud’s production version. When you use simulator or test device, data should be in iCloud’s development version. When you use previews, data should not be persisted at all.
September 19, 2025 at 6:41 PM
When you or other people use your app, the data should be persisted in iCloud’s production version. When you use simulator or test device, data should be in iCloud’s development version. When you use previews, data should not be persisted at all.
I feel like you’re mixing up 2 things. 1) In-memory data (for previews) vs persisted data (for simulator and test devices, using debug iCloud). And 2) debug iCloud vs production iCloud (on TestFlight and App Store).
September 19, 2025 at 6:39 PM
I feel like you’re mixing up 2 things. 1) In-memory data (for previews) vs persisted data (for simulator and test devices, using debug iCloud). And 2) debug iCloud vs production iCloud (on TestFlight and App Store).