Is it possible/allowed/supported to pass an NSManagedObject in the propertiesToUpdate dictionary of NSBatchUpdateRequest. obj-c MYManObjType* manObj = myManObject;/*Fetched using the same moc*/ NSBatchUpdateRequest* updateRqst = [NSBatchUpdateRequest batchUpdateRequestWithEntityName:@"relatedManObj"]; updateRqst.predicate = someValidPredicateDefinedElsewhere; updateRqst.propertiedToUpdate = @{@"myManObjRealtionship":manObj}; updateRqst.resultType = NSUpdatedObjectsCountResultType;... updateRqst.affectedStores = @[self.moc.persistentStoreCoordinator.persistentStores]; NSBatchUpdateResult* result = [self.moc executeRequest:updateRqst error:&err]; I keep getting this error: ** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Invalid relationship ... But the relationship IS valid, and the 'assigned' object is of the correct type.

I am trying to get CoreData(Sync'd via NSPersistentCloudKitContainer, although that is not particularly relevant for the current issue) to play nicely (or even at all) with UICollectionViewDiffableDataSource. The stumbling block seems to be concerned with [NSManagedObject hash]. I need the diffing engine to notice a change when there is a change in the specific managedObject-subclass, AND/OR (at least some) of its child managedObject-subclasses. Example: So, in the above example object graph, I need the Posts datasource to notice when the 'name' of the Tag changes, and react accordingly. i.e. {Post.tags.any.name} The simplest solution would be if I could override[Post hash], but of course that's not allowed. Even obj-c method-swizzling does not work without complaining. Class 'Post' for entity 'Post' has an illegal override of NSManagedObject -hash Adding 'computed values' with the parent managed-object does not work; computed vars don't seem to be included in the [hash] implementation. Any ideas what to try next?

I am trying to set a Notification that triggers on a certain day, then repeats each day after. So I need a NSCalendarNotificationTrigger, defining the FULL components set, (Year down to Minute/Second). But in this case, repeats does nothing at all. Which seems like an interesting, and not very flexible, design choice. Thus, it seems that I will need to create the single (non-repeating) calendar Noti, and, somehow, figure out how to replace it with a daily-repeating (hour and minute components) once it has fired. Any insight, or work-arounds appreciated. The old/deprecated since iOS 10, UILocalNotification could set a repeatInterval: (NSCalendarUnit), much more flexible. #LessIsNotMore

As a long-time Obj-C dev (since iPhone OS 2) I decided that SwiftUI was the nudge to use Swift! ¯\&#92;&#95;(ツ)_/¯ Thus, I am still trying to understand how a language can be so type-vague in code, and so type-pedantic in the compiler!!! Pulling my hair out trying to get Swift/SwiftUI to instantiate a UIHostingController<>, for use with CoreData class MyCoreDataHostingController : UIHostingController<MyCoreDataView> { required init?(coder: NSCoder) {//Instantiate From Storyboard let context = (UIApplication.shared.delegate as! AppDelegate).persistentContainer.viewContext let contentView = MyCoreDataView().environment(\.managedObjectContext, context) super.init(coder: coder, rootView: contentView) //Cannot convert value of type 'some View' to expected argument type 'MyCoreDataView' } } struct MyCoreDataView: View { var body: some View { Text("Core Data View") } } How can I FORCE Swift to INFER the correct/appropriate type? What I have tried so far. 5 let contentView = MyCoreDataView() Compiles/runs, but does not include CoreData. 6 super.init(coder: coder, rootView: contentView as! MyCoreDataView) Compiles, but crashes at instantiation. Could not cast value of type 'SwiftUI.ModifiedContent<MyHostingController.MyCoreDataView, SwiftUI.EnvironmentKeyWritingModifier<_C.NSManagedObjectContext>>' (...) to 'MyHostingController.MyCoreDataView' (...). ... or is this simply not possible? (yet)

Does anyone know the secret to getting self-sizing UICollectionViewCell to work. I have a cell template, build using stackViews, all wrapped in a UIView with constraints to the Cell object (IB cell size is 320 x 185). I have used: NSCollectionLayoutSize* groupSize = [NSCollectionLayoutSize sizeWithWidthDimension:[NSCollectionLayoutDimension fractionalWidthDimension:0.80] heightDimension:[NSCollectionLayoutDimension estimatedDimension:100.0f]]; But all of the cells appear at size 300 x 185 on iPhoneX screen size. Despite some cell having shrunken text and others with extra space.

After many months/years of trying to create my own CoreData/iCloud sync engine, and getting about 90% of the way there; I gave up and started using NSPersistentCloudKitContainer, forcing us to drop support for iOS 12-. At first all seemed fine, however, today it all went horribly wrong (still investigating why) I now have 'duplicate' CKRecords of single ManagedObjects in CloudKit, and (it seems, although still tracking down the model) disconnected 'references'. Having looked at CloudKit Dashboard is seems that NSPersistentCloudKitContainer does not use ANY references, but simply a String of the UUID of the referenced CKRecord. I can only presume that this is a workaround to prevent Referencing a (not yet) non-existent CKRecord. So, this presents several questions: Is the lack of CKReference by design, or a bug? What defensive programming is in place to prevent duplications or corrupt references when using Stringly-Typed pseudo-references? Is there a way to inform the NSPersistentCloudKitContainer that a CKRecordFieldKey is unique? Is it 'safe' to 'correct' the CloudKit RecordZone in order to fix the corruption? 3a. I am curious that CloudKit does not support the UUID type?!

Where is the My Questions link?

Trying to get Compositional Layout working (in Obj-C: legacy code base, legacy dev) with CollView in StoryBoard. Keep getting this error: > 'Invalid section definition. Please specify a valid section definition when content is to be rendered for a section. This is a client error.' Looking at the Code Sample I cannot see what I'm doing differently. Here is the code. @implementation TemplatePickerCompLayout (UICollectionViewCompositionalLayout*)initWithCoder:(NSCoder *)coder{ self = [super initWithCoder:coder]; self.collectionView.collectionViewLayout = [self createStandardCompLayout]; return self; } (UICollectionViewLayout*)createStandardCompLayout{ NSCollectionLayoutSize* itemSize = [NSCollectionLayoutSize sizeWithWidthDimension:[NSCollectionLayoutDimension fractionalWidthDimension:1.0] heightDimension:[NSCollectionLayoutDimension fractionalHeightDimension:1.0]]; NSCollectionLayoutItem* item = [NSCollectionLayoutItem itemWithLayoutSize:itemSize]; item.contentInsets = NSDirectionalEdgeInsetsMake(5.0f, 5.0f, 5.0f, 5.0f); NSCollectionLayoutSize* groupSize = [NSCollectionLayoutSize sizeWithWidthDimension:[NSCollectionLayoutDimension fractionalWidthDimension:0.80] heightDimension:[NSCollectionLayoutDimension absoluteDimension:120.0f]]; NSCollectionLayoutGroup* group = [NSCollectionLayoutGroup horizontalGroupWithLayoutSize:groupSize subitem:item count:1]; group.contentInsets  = NSDirectionalEdgeInsetsMake(10.0f, 30.0f, 10.0f, 30.0f); NSLog(@"Group:\n%@",group.visualDescription); UICollectionViewLayout* rtnLayout = [[UICollectionViewCompositionalLayout alloc]initWithSectionProvider:^NSCollectionLayoutSection * _Nullable(NSInteger section, id&lt;NSCollectionLayoutEnvironment&gt; _Nonnull env) { NSLog(@"env:%@ [%zd]",env,section) NSCollectionLayoutSection* sectionDef = nil; if (section == 0) { sectionDef = [NSCollectionLayoutSection sectionWithGroup:group]; sectionDef.contentInsets = NSDirectionalEdgeInsetsMake(10.0f, 10.0f, 10.0f, 10.0f); } else { sectionDef = [NSCollectionLayoutSection sectionWithGroup:group]; sectionDef.contentInsets = NSDirectionalEdgeInsetsMake(10.0f, 50.0f, 10.0f, 50.0f); } return sectionDef; }]; return rtnLayout; } @end