I know writing a custom NSMergePolicy is rarely needed, but if you do find you need to write one, Apple’s lack of documentation makes it nearly impossible to diagnose if you do it wrong. I wrote the missing documentation so you don’t have to flounder around like I did.
TLDR: Be sure to call super, or else it all falls apart. Not intuitive, but the base merge policy respects your changes.
https://quigs.blog/how-to-write-a-custom-coredata-nsmergepolicy/
#CoreData #SwiftData #iOS #Apple #Developer #iOSDev #Documentation #Blog #HowTo
#coredata #swiftdata #iOS #apple #developer #iosdev #documentation #blog #howto
Asking for a friend: how would you model your #CoreData/#SwiftData schema for an activity feed with different types of activities (like a log of events where each events can have its own attributes)? Objects would be used in a List + FetchRequest for example.
1. Inheritance? I’m a bit worried about performance/evolution issues as one single table will store all properties.
2. Common Entity with properties shared by all events (like timestamp) related to all events?
3. Something else?
I’m on Mastodon for two things.
I build things on Apple platforms. I make @tact. I read (a lot) and post (a little) about related technologies: #Swift, #SwiftUI, #Combine, #CloudKit, #CoreData, #Xcode, #concurrency, as well as product design.
I support Ukraine. I follow Ukrainians and friends of 🇺🇦. Please donate to 🇺🇦 until 🗑🇷🇺 is gone: https://u24.gov.ua or any other respected charity. My Twitter is mostly about Ukraine - https://twitter.com/jaanus
#introduction #swift #swiftui #Combine #cloudkit #coredata #xcode #concurrency
I think it's time to say goodbye to some Objective-C code from 2013. I used NSKeyedUnarchiver at that time, and switch to #CoreData many years ago.
#coredata #indiedev #BuildInPublic
So many reasons to target iOS 17+ & drop support for older versions:
- MapKit for #SwiftUI (annotations & overlays)
- #CoreLocation now supports live updates using Swift concurrency’s async/await capability
- #SwiftData (no, just a joke, I'll stick to my #CoreData stack for now)
#swiftui #corelocation #swiftdata #coredata
@MakeAppPie oh! It comes from #CoreData where description cannot be used for an attribute name in an entity.
Has anyone built an app with #CoreData #CloudKit sharing where participants needs to link their CloudKit identity to a database Person entity object? Like a task management app with assignees join the project.
I was thinking about a flow with a "self-selection process" where participants select an existing Person from the database (or create a new one) when joining the share.
The app would then store the CKShare.currentUserParticipant.userIdentity.userRecordID as a field on the Person object.
Anyone have any experience putting their SwiftUI PersistenceController, CoreData xcdadamodeld file, and NSManagedObject Subclasses in a 📦 Swift Package?
Im getting this crash as soon as I moved it into a package. Any ideas why that might be? (Yes, I know I’m force unwrapping a few things 🙈. Any suggestion to improve this or fix this error would be appreciated 🙂)
@matt1corey hey Matt. I’m digging a bit more into #CloudKit Sharing (with #CoreData & #NSPersistentCloudKitContainer). I know you implemented sharing in your apps.
In an app where I want to attribute an event to a specific user, how would you do that? E.g. a task management app with assignee and assignees can be added by sharing to them. I want to track who created/edited/completed a task for example (like a log of events/activities). Should I add the userRecordName in the object?
#cloudkit #coredata #nspersistentcloudkitcontainer
Hey, (re) #introduction time!
I’m the creator/developer of CardBoard: boardgame scoring app. I launched in the very early days of #SwiftUI, using lots of #Combine, #CloudKit and #CoreData. For v2 I’m doing a complete rewrite: moving to iOS 17 #SwiftUI and #SwiftData. I’m building in public for those who want to follow the journey and learn with me!
#swiftdata #coredata #CloudKit #combine #SwiftUI #Introduction
How tf are you supposed to make a selectable list in SwiftUI using IDs in the selection state? SwiftData does this fairly effortlessly, but I had to convert to CoreData (because SwiftData stupidly isn’t backported to previous iOS versions), and despite compiling, selection doesn't actually work.
I can’t find any good examples of how to do this online, and the few I find use the entire object for selection, rather than just the IDs.
SwiftData uses MyEnttiy.ID, which exists in CoreData (NSManagedObject conforms to Identifiable), but that doesn’t appear to be a type I can use to fetch an object from NSManagedObjectContext.
The app is 💯 built in #SwiftUI.
#CoreData is used for local data persistency and #CloudKit is used to sync data between devices (both user content & preferences).
#RevenueCat is used to process and manage auto-renewable subscriptions.
#swiftui #coredata #cloudkit #RevenueCat
It is bonkers to me how absolutely stupid Core Data can be. You can't make await calls inside the async perform block, and you can't pass back the object you want and access it outside the perform block. So you have to pass it as a dictionary, or marshal it into some other “safe” type. And then you have to create another perform block later, *and fetch it again*, to update it.
And the WWDC presenters are so proud of these limitations.
Trying to write SwiftUI code to edit a Core Data entity, and wow, it is hard to do! Seems impossible to do elegantly. I hope SwiftData is better.
But yeah, it seems you *must* create a bindable @State property for each property of your entity you want to be able to edit in your UI, set them all in .onAppear(), and then update the entity on save, or on a bunch of .onChange(of:) handlers.
Makes it particularly difficult to separate the details of the form from a simpler parent that handles setting up and saving or discarding (and confirming with the user if they want to discard).
Since Core Data properties must be optional, you can’t bind to them directly. Although optionality generally complicates SwiftUI primitives anyway.
#iOS #macos #swift #swiftui #coredata #xcode
I'm used to defining Models in #Vapor using their code based approach. I do not like it, but it's my only option so I deal with it.
For #CoreData, I can use the GUI to define models and setup relationships. I'm very much used to this. The graph view makes it trivial to visualise relationships across models.
#SwiftData completely disregards this and requires defining models in code. Makes visualising or getting an overview of relationships across models non-trivial.
#Swift #CoreData #Combine #Concurrency #AsyncSequence #NotificationCenter
Can anyone more familiar with above topics help me understand what’s going on here?
I thought that NotificationCenter Combine-based and AsyncSequence-based API-s behave exactly the same. Now I hit a case where they don’t. Their behavior differs based on whether I give it the sending object or not.
Why?
#swift #coredata #combine #concurrency #asyncsequence #notificationcenter
@brandonhorst isn’t #SwiftData supposed to be compatible with #CoreData? Could you mix and match?
Notes from my WWDC23 Core Data lab, mostly about CloudKit sync but touching on SwiftData and a few other things https://useyourloaf.com/blog/wwdc23-core-data-lab-notes/ #WWDC23 #CoreData
@SwiftData is really nice to work with compared to #CoreData, but there are a lot of things you still have to be aware of. Looking forward to new books from @donnywals and Mark Moeykens (Big Mountain Studio). I am going on my annual wine tour/purchase during @twostraws Hacking with Swift Live, but I am going to sign up anyway just to get the videos and make sure I have everything covered.