My Apple Watch has the same issue. It was connected, then after Xcode 15.3 (released) it stopped talking to Apple Watch device. I unpaired to repair and have never been able to find or see the watch again. Tried toggling developer mode on the watch, no dice. I can connect the watch to Xcode 15.3 on my Laptop, but no longer on mu desktop. If I run: xcrun devicectl list devices the watch is NOT listed as one of the visible devices. All I see are the iPhone and iPad which had also been setup as dev devices?! Why has this issue been ongoing for so long?! I am seeing people reporting this back 8 months now?!

You do it on the watch. Push Crown -> Settings Icon -> Privacy & Security -> Scroll to bottom and -> Developer Mode -> Turn on the Switch and follow the instrucions.

Damn it Apple! Xcode 15.3 stopped seeing my Apple Watch Ultra 2. So I disconnected thinking I was going repair it and now NADA. I have been crawling all over the net looking for solutions for this. Restarted pretty much everything numerous times. Run Sysdiags, blah blah nothing is working. My iPhone sees it and all of that is working just fine. But Xcode and Devices and Simulators DO NOT see it. Ran the terminal command above and it does not show up. I have the device connected via BOTH bluetooth and WIFI but oddly it (the watch) does NOT see the Mac when searching for Bluetooth devices (system settings are open and on Bluetooth) or anything else for that matter. xcrun devicectl list devices DOES NOT show the watch only my iPhones and iPads. Odd. Devices: Name Hostname Identifier State Model iPad 2024 xx-iPad-2024.coredevice.local C72B3F88-06A9-4CD4-8AFA-49AD478540AB connected iPad Air (5th generation) (iPad13,16) iPhone13 xx-iPhone13.coredevice.local 43A16EBE-911D-4F89-AA42-3DF3B0D21AF9 connected iPhone 13 (iPhone14,5) No watch?! And yet it is right here and talking to my iPhone?!

The CloudKit Console says the development schema and which has the field nameFirstChar field is indicated as deployed to production. However I DO NOT see it over on the production side. See the images. How is this possible and or what am I missing? The data is syncing just fine on all my devices and perhaps some users ... I think. And I ran this code at various points to deploy development to production: func initializeCloudKitSchemaForNewModel() { coreDataLogger.log("*** Initialize CloudKit Scheme for New Model - Start") if(!useiCloud) { return } do { // Use the container to initialize the development schema. let options = NSPersistentCloudKitContainerSchemaInitializationOptions() try pc.initializeCloudKitSchema(options:options) } catch { coreDataLogger.error("*** CoreDataUtil Initializing new schema: \(error)") } coreDataLogger.log("*** Initialize CloudKit Scheme for New Model - End") }

So the only solution I was able to arrive it was to: NOT use the same name for the Swift Class as the old class being refactored into Swift. Have BOTH in the project. Get it to build. Then go back and change all the references to the old class name to new class name. This was the ONLY way to get the ProjectHeader-Swift.h to get built and include the class. This file should probably be built on the fly and dynamically as long as there are no errors in any Swift Classes.

How does one get around this circle jerk issue?! The Swift file has NO compile errors that I can see but other things will not build because they are not seeing the full definition of the Swift class and are complaining about the forward Class not having various properties defined in the Swift class. Seriously Apple this is a bit backwards no? Xcode should automatically generate that file as long as there are no build issues in a Swift class.

Holy s*** figure it out!! Super EZ.. simply renamed ProjectName-Swift.h to oldProjectName-Swift.h and Xcode instantly rebuilt ProjectName-Swift.h and stopped complaining. Wow.

Additional Info. I tried commenting out all references in the Obj-C file to the above class to see if I could get a build that regenerated ProjectName-Swift.h. Didn't work.But when I change Build Setting for "Objective-C Generated Interface Header Name" to: $(SRCROOT)/$(SWIFT_MODULE_NAME)-Swift.h, I get "invalid task ('SwiftMergeGeneratedHeaders .... with mutable output but no other virtual output node?! Any thoughts

@jamie_sq or anyone have any thoughts regarding this issue related to NSFetch and sectionHeaders? The code in question has worked for years but started failing on iOS 16. After seeing this post and realizing it had something to do with section ordering and seeing that it seems to only happen on devices using foreign languages we looked more carefully at our code and realized that the nameFirstLetter method of our NSManagedObject which is the ONLY Entity in our CoreData database and which returns the string used for sectionNameKeyPath was not properly handling Unicode characters. nameFirstLetter method simply grabs the first character of NAME field on the NSManagedObject. Name is an actual stored field and this method takes the first character and returns it. We improved this to use rangeOfComposedCharacterSequenceAtIndex. That works ok until we tried to do [str localizedUppercaseString] on it. And NOW we see exactly the crash our customers are seeing. -(NSString *)nameFirstLetter { if(self.name != nil) { return [self.name substringWithRange:[self.name rangeOfComposedCharacterSequenceAtIndex:0]]; /* The above works with the issue that sections show up for lower case letters and then again for uppercase. As soon as we do the following the NSFetchResultController CRASHES with the _computeSectionInfo error */ return [[self.name substringWithRange:[self.name rangeOfComposedCharacterSequenceAtIndex:0]] localizedUppercaseString]; } else return @"?"; } We don't understand why this should be a problem given that the NSFetchResultController is initialized to do localizedCaseInsensitiveCompare? This is how we set up the FetchControllers sorts. -(void)initializeFetchedResultsController { // Already inititialized if(_fetchedResultsController != nil) return; // Create and configure a fetch request for Charts NSManagedObjectContext *moc = ((iPhemerisAppDelegate *)[[UIApplication sharedApplication] delegate]).coreDataUtil.pc.viewContext; if(!moc) { NSLog(@"*** SavedChartView MOC NOT READY"); return; } NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init]; NSEntityDescription *entity = [NSEntityDescription entityForName:@"Charts" inManagedObjectContext:moc]; [fetchRequest setEntity:entity]; // Create the sort descriptors array NSSortDescriptor *nameDescriptor = [[NSSortDescriptor alloc] initWithKey:@"name" ascending:YES selector:@selector(localizedCaseInsensitiveCompare:)]; NSSortDescriptor *chartTypeDescriptor = [[NSSortDescriptor alloc] initWithKey:@"chartType" ascending:YES selector:@selector(localizedCaseInsensitiveCompare:)]; NSArray *sortDescriptors = [[NSArray alloc] initWithObjects:nameDescriptor, chartTypeDescriptor, nil]; [fetchRequest setSortDescriptors:sortDescriptors]; // Create and initialize the fetch results controller. _sectionNameKeyPath = @"nameFirstLetter"; _fetchedResultsController = [[NSFetchedResultsController alloc] initWithFetchRequest:fetchRequest managedObjectContext:moc sectionNameKeyPath:_sectionNameKeyPath cacheName:nil]; _fetchedResultsController.delegate = self; }

We now understand this issue much better. Working with Testers on devices using Japanese and Foreign languages and making some small changes to better handle Unicode we can reproduce the issue, but do not understand how to fix. We noticed the mismatch between the first character index on this screen shot attached and realized that our code to return the first character was not handling Unicode properly. We therefore modified the code that returns the first Character of the Name Field and which produces the index of first letters running down the right side to be like so. This code is a method on our NSManagedObject that is the object used as the Entity in the DB for fetching. It has some debug Log statements. This code crashes if we use the localizedUppercaseString and does not if we remove that? // Used by NSFetchedResultController Table of Charts by first letter -(NSString *)nameFirstLetter { if(self.name != nil) { //return [[self.name substringToIndex:1] localizedUppercaseString]; NSString *str = [self.name substringWithRange:[self.name rangeOfComposedCharacterSequenceAtIndex:0]]; NSLog(@"**** Name:[%@] 1st[%@] Upper[%@]", self.name, str, [str localizedUppercaseString]); return [str localizedUppercaseString]; //[[self.name substringWithRange:[self.name rangeOfComposedCharacterSequenceAtIndex:0]] localizedUppercaseString]; } else return @"?"; } It is crashing with a FetchRequest that is initialized using this code below. There is some issue created by doing the localizedUpperCase and the _sectionNameKeyPath that uses that returned value in the FetchRequest _fetchedResultsController = [[NSFetchedResultsController alloc] initWithFetchRequest:fetchRequest managedObjectContext:moc sectionNameKeyPath:_sectionNameKeyPath cacheName:nil]; -(void)initializeFetchedResultsController { // Already inititialized if(_fetchedResultsController != nil) return; // Create and configure a fetch request for Charts NSManagedObjectContext *moc = ((iPhemerisAppDelegate *)[[UIApplication sharedApplication] delegate]).coreDataUtil.pc.viewContext; if(!moc) { NSLog(@"*** SavedChartView MOC NOT READY"); return; } NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init]; NSEntityDescription *entity = [NSEntityDescription entityForName:@"Charts" inManagedObjectContext:moc]; [fetchRequest setEntity:entity]; // Create the sort descriptors array NSSortDescriptor *nameDescriptor = [[NSSortDescriptor alloc] initWithKey:@"name" ascending:YES selector:@selector(localizedCaseInsensitiveCompare:)]; NSSortDescriptor *chartTypeDescriptor = [[NSSortDescriptor alloc] initWithKey:@"chartType" ascending:YES selector:@selector(localizedCaseInsensitiveCompare:)]; NSArray *sortDescriptors = [[NSArray alloc] initWithObjects:nameDescriptor, chartTypeDescriptor, nil]; [fetchRequest setSortDescriptors:sortDescriptors]; // Create and initialize the fetch results controller. _sectionNameKeyPath = @"nameFirstLetter"; _fetchedResultsController = [[NSFetchedResultsController alloc] initWithFetchRequest:fetchRequest managedObjectContext:moc sectionNameKeyPath:_sectionNameKeyPath cacheName:nil]; _fetchedResultsController.delegate = self; }

More information. We have managed to get Crashlytics logging to work and these are being sent with FireBase CrashReports. Thus far: Crashing devices are NOT in low power mode. Crashing devices are NOT getting any low memory notices. Crashing devices ARE actually completing the CoreData / Cloudkit setup successfully as far as we can tell and notify the UITableView using CoreData to initialize the FetchResultController. At that point or after the UITableView viewDidLoad we attempt to make a FetchRequest. It is at this point that some devices (only a small percentage) crash deep in CoreData framework with _computSectionInfo error, like so: 1 CoreFoundation 0x9908 isEqualToString + 100 2 CoreData 0xc0760 -[NSFetchedResultsController _computeSectionInfo:error:] + 712 3 CoreData 0x49c08 __43-[NSFetchedResultsController performFetch:]_block_invoke + 520 4 CoreData 0x82df8 developerSubmittedBlockToNSManagedObjectContextPerform + 156 5 CoreData 0x82948 -[NSManagedObjectContext performBlockAndWait:] + 208 6 CoreData 0x5fb24 -[NSFetchedResultsController _recursivePerformBlockAndWait:withContext:] + 152 7 CoreData 0x5da10 -[NSFetchedResultsController performFetch:] + 252 8 iPhemeris 0x1cf1c -[SavedChartViewController viewDidLoad] + 120 (SavedChartViewController.m:120)

Thanks Apple for the response, but from where I sit there have been many crashes not still no crash reports?!

@iAmBowser - We have never seen the crash on any of our devices or connected to Xcode. Only via reports and now users on TestFlight. Yes it is in CoreData framework, we think it is a framework/Cloudkit issue and have filed a bug report. What the original question states is we are hoping to find a work around. The issue only occurs with CloudKit enabled which CANNOT be run on simulators. We doubt it is a database issue as this particular model has been working on many user devices and there are NO relationships, simply Entities. We have tried 7 builds at this point via TestFlight attempting to use alternate approaches or more delayed approaches to initialize CoreData/Cloudkit. All the devices continue to crash in the same way and nothing we have tried prevents it accept the user turns off using iCloud. We have tried to use Crashlytics to get log statements as to where it is crashing during start, but it seems to crash too quickly to even get those. We are stuck

As of right now Mar. 22, 2023 NO TestFlight build that is crashing is delivering ANY crash reports. I am having to have users email them manually. What is going on APPLE?!

Issue STILL there in 16.3.1?! Does anyone have anymore information on this and how to resolve it or a workaround?! This is starting to be a real issue for me with bad reviews.