Some of my users are reporting an inability to sync via CloudKit between devices. I have not seen it on any of my devices, but one user got me some console logs that are showing the following error: <CKError 0x600000a0f840: "Partial Failure" (2/1011); "Failed to modify some records"; uuid = EDC7B3E3-02F8-43B7-83B6-22D17EF0442A; container ID = "iCloud.cribaudo.iphemeris"; partial errors: { C611E11F-3DC0-484C-8FC1-23473062D9D0:(com.apple.coredata.cloudkit.zone:defaultOwner) = <CKError 0x600000a04660: "Invalid Arguments" (12/2006); server message = "Cannot create or modify field 'CD_nameFirstChar' in record 'CD_Charts' in production schema"; op = D83EF1F7DD772042; uuid = EDC7B3E3-02F8-43B7-83B6-22D17EF0442A> I do not understand this: The field CD_nameFirstChar was added to the data model in the version 15. Automatic Migration is enabled. The CloudKit Console says the Private Database Container being used by my App is deployed to production. The entity CD_Charts (I only have one) that is deployed to production shows that field as present (CD_nameFirstChar). Why would this user be getting this error? As far as I can see they are running a version where migration to Model 15 should have been triggered at some point in the past. If somehow something went wrong with their migration, how would I fix it? Any thoughts / ideas are appreciated. One thing I should add is that the migration from Model 14 to 15 was not lightweight. I did use: @interface ModelMigration14to15 : NSEntityMigrationPolicy -(NSString *)nameFirstChar:(NSString *)name; @end And I used a MapModel14to15 which used the above function to set the value of nameFirstChar. The Value Expression for that attribute is: FUNCTION($entityPolicy,` "nameFirstChar:" , $source.name) from the above mentioned NSEntityMigrationPolicy class. This worked ok on all my devices and apparently on some user devices. This issues seems to effect only a small subset of my users but not all? So I am at a loss to understand why this would happen or how to fix it.

For the last week Xcode has simply refused to update the Swift Bridging Header when I add new Swift Classes?! It is getting to be a real pain in ****. I refactor a class into Swift then have to spend 2 days trying to get Xcode to see the new class. What the heck?! Anyone have any clue what is going on here and how to fix this? This is a MacOS Project that is quite old and has a lot of Obj-C that I have been refactoring over to Swift class by class. It was fine until recently, but lately it has been rather tough sledding. I have tried: Numerous clean and rebuilds. Deleting the derived data folder manually. Renaming the ProjectName-Swift.h file - One time doing that seemed to cause Xcode to notice and it rebuilt it but not subsequent times. Double checked all the settings. These are the settings for the Relevant section and all looks ok to me according to the Docs. I am out of ideas and while I see people running into this issue I have not found a reliable way to fix this.

I have a MacOS project with several targets and in which I have been refactoring Obj-C classes over to Swift 1 by 1. I have been doing this for months and all was fine and building well until the most recent class. But with that one the project simply refuses to build. I see the ProjectName-Swift.h file in the Project folder but the last build date was over a week ago and so it obviously does not include the new class, hence Xcode is complaining it can't find the new Swift Class. Understand the following before answering please: This is a very old and longstanding MacOS project with several targets, it is NOT a new MacOS project. I have previously added quite a few other Swift classes (using Swift 5) to this project and was able to build and run just fine. I have tried clean and build about 50 times and removing derived data. Nothing will force a rebuild of the ProjectName-Swift.h and the new class is definitely NOT in there. There are no other build issues with this project, just the one related to not being able to see the new class. The class was previously implemented in Obj-C and I was porting it over and that old class file is not referenced by the project at the moment. This Swift class ChartListTableCellView is NOT referenced in the obj.h file so it is not forward referenced there. The Bridge Header is imported in the .m that is complaining. Because Xcode is not seeing the Swift Class in the ProjectName-Swift.h it will not build and I am sort of in a chicken and egg circle jerk here. I even tried using the old Header at the top of the .m file where I need this class and it gets further but not far enough to build the Bridge Header. This is how the new class is declared so it should be visible. @objcMembers class ChartListTableCellView : NSView { private let grayBottomBorder = NSView() ... init() { super.init(frame: NSMakeRect(0, 0, 0, 0)) ... } ... } I am stumped and am out of ideas. Apple!! Seriously there needs to be a simple way to force a rebuild of the ProjectName-Swift.h file.

2023-03-21_11-29-41.0431_-0500-5252ac14231823143fb4e0959f659a68f61e6450.crash Since iOS 16 code that has been working for many years has been randomly crashing on some devices. We have NEVER seen it on any of our devices, but we are getting a lot of complaints and bad reviews from a small percentage of our installed base but which amounts to A LOT of users. This appears to be an iOS 16 bug that only manifests if users are allowing us to store data in iCloud. below is a typical crash report. Anyone else seeing this and have any ideas on a workaround. AND APPLE please get on this issue! Incident Identifier: 1AB6F163-8B35-4D8E-A78A-9514BFD2410B Beta Identifier: 82FFD7BA-5E70-40B9-B45E-B98F320675DF Hardware Model: iPhone14,5 Process: iPhemeris [9907] Path: /private/var/containers/Bundle/Application/5F6EDD27-0AB7-4AFC-B62C-88D29545C12C/iPhemeris.app/iPhemeris Identifier: cribaudo.iphemeris Version: 11.6.1 (146) AppStoreTools: 14E221 AppVariant: 1:iPhone14,5:16 Beta: YES Code Type: ARM-64 (Native) Role: Foreground Parent Process: launchd [1] Coalition: cribaudo.iphemeris [1985] Date/Time: 2023-03-22 23:17:38.5970 +0800 Launch Time: 2023-03-22 23:17:37.9265 +0800 OS Version: iPhone OS 16.3.1 (20D67) Release Type: User Baseband Version: 2.40.01 Report Version: 104 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x00000e387afc8fa0 -> 0x000000387afc8fa0 (possible pointer authentication failure) Exception Codes: 0x0000000000000001, 0x00000e387afc8fa0 VM Region Info: 0x387afc8fa0 is in 0x1000000000-0x7000000000; bytes after start: 173862064032 bytes before end: 238454796383 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL commpage (reserved) fc0000000-1000000000 [ 1.0G] ---/--- SM=NUL ...(unallocated) ---> GPU Carveout (reserved) 1000000000-7000000000 [384.0G] ---/--- SM=NUL ...(unallocated) UNUSED SPACE AT END Termination Reason: SIGNAL 11 Segmentation fault: 11 Terminating Process: exc handler [9907] Triggered by Thread: 0 Kernel Triage: VM - pmap_enter retried due to resource shortage VM - pmap_enter retried due to resource shortage VM - pmap_enter retried due to resource shortage VM - pmap_enter retried due to resource shortage VM - pmap_enter retried due to resource shortage Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0 Crashed: 0 libobjc.A.dylib 0x1cf9e5c20 objc_msgSend + 32 1 CoreFoundation 0x1d6864908 isEqualToString + 100 2 CoreData 0x1de140760 -[NSFetchedResultsController _computeSectionInfo:error:] + 712 3 CoreData 0x1de0c9c08 __43-[NSFetchedResultsController performFetch:]_block_invoke + 520 4 CoreData 0x1de102df8 developerSubmittedBlockToNSManagedObjectContextPerform + 156 5 CoreData 0x1de102948 -[NSManagedObjectContext performBlockAndWait:] + 208 6 CoreData 0x1de0dfb24 -[NSFetchedResultsController _recursivePerformBlockAndWait:withContext:] + 152 7 CoreData 0x1de0dda10 -[NSFetchedResultsController performFetch:] + 252 8 iPhemeris 0x104f26df8 -[SavedChartViewController initializeFetchedResultsController] + 460 9 iPhemeris 0x104f24560 -[SavedChartViewController viewDidLoad] + 1960 10 UIKitCore 0x1d8db205c -[UIViewController _sendViewDidLoadWithAppearanceProxyObjectTaggingEnabled] + 84 11 UIKitCore 0x1d8a4a35c -[UIViewController loadViewIfRequired] + 712 12 UIKitCore 0x1d8d10d68 -[UINavigationController _updateScrollViewFromViewController:toViewController:] + 124 13 UIKitCore 0x1d8bd7470 -[UINavigationController _startTransition:fromViewController:toViewController:] + 196 14 UIKitCore 0x1d8bd6928 -[UINavigationController _startDeferredTransitionIfNeeded:] + 608 15 UIKitCore 0x1d8bd5f78 -[UINavigationController __viewWillLayoutSubviews] + 96 16 UIKitCore 0x1d8bd5edc -[UILayoutContainerView layoutSubviews] + 172 17 UIKitCore 0x1d8a344c8 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 1980 18 QuartzCore 0x1d7f077fc CA::Layer::layout_if_needed(CA::Transaction*) + 500 19 QuartzCore 0x1d7f1aeb0 CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 148 20 QuartzCore 0x1d7f2c234 CA::Context::commit_transaction(CA::Transaction*, double, double*) + 444 21 QuartzCore 0x1d7f61630 CA::Transaction::commit() + 652 22 UIKitCore 0x1d8ec32b0 __34-[UIApplication _firstCommitBlock]_block_invoke_2 + 36 23 CoreFoundation 0x1d689e514 CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK + 28 24 CoreFoundation 0x1d6906d6c __CFRunLoopDoBlocks + 368 25 CoreFoundation 0x1d68d6b90 __CFRunLoopRun + 856 26 CoreFoundation 0x1d68dbeb0 CFRunLoopRunSpecific + 612 27 GraphicsServices 0x210ad1368 GSEventRunModal + 164 28 UIKitCore 0x1d8dd1668 -[UIApplication _run] + 888 29 UIKitCore 0x1d8dd12cc UIApplicationMain + 340 30 iPhemeris 0x104f18d1c main + 72 31 dyld 0x1f51d4960 start + 2528

According to this WWDC video: https://developer.apple.com/videos/play/wwdc2021/10203/ Beta Apps delivered via TestFlight App to testers will automatically and nearly instantly send 🤣 Crash Reports to Xcode Organizer. And the documentation states that this will happen REGARDLESS of the device Send Diagnostic Data setting. We have been using TestFlight for the last week and NOT ONE Crash report has been sent to either Organizer OR App Store Connect Test Flight dashboard. All we get are "Screenshots" with some typed feedback. What is going on APPLE?!

Seeing A LOT of crashes for this code which has been around for quite a while (on iOS 15). After a viewController that user has been using is dismissed we check some values to determine if we should prompt for a rating and write some values into NSUserDefaults and which is when the crash happens. This code gets called when the user clicks a Done Button to dismiss the viewController: -(void)dismissChart { [self.navigationController dismissViewControllerAnimated:YES completion:^{     if([IphemerisUtil okToRequestRatingUsingCount:OK_TO_REQUEST_REVIEW_COUNT])       [IphemerisUtil requestAppRating];   }]; } This is what is called and where the crash occurs: +(BOOL)okToRequestRatingUsingCount:(int)count {    int curVersion = [[[NSBundle mainBundle] objectForInfoDictionaryKey:@"CFBundleVersion"] intValue];        NSNumber *lastVerRated = [userSettings objectForKey:RateLastVersionRated];    int lastVersionRated = (lastVerRated != nil) ? [lastVerRated intValue] : 0;        NSNumber *ratePromptCnt = [userSettings objectForKey:RatePromptCounter];    int rateCounter = (ratePromptCnt != nil) ? [ratePromptCnt intValue] : 1;        NSDate *dateLastCounterIncrement = [userSettings objectForKey:RatePromptCounterLastDateIncrement];    if(!dateLastCounterIncrement) {      dateLastCounterIncrement = [NSDate date];      [userSettings setObject:dateLastCounterIncrement forKey:RatePromptCounterLastDateIncrement];    }        if(curVersion &gt; lastVersionRated) {      if(rateCounter &gt; count)        return YES;      else {        // Increment the counter only once a day        if([[NSDate date] timeIntervalSinceDate:dateLastCounterIncrement] &gt; (3600 * 24)) {          rateCounter++;          [userSettings setObject:[NSNumber numberWithInt:rateCounter] forKey:RatePromptCounter];        }      }   }   return NO; } One of the two userSettings:setObject is crashing. As indicated by this symbolicated crash log for the above code.

I've been seeing a lot of crash reports on iOS 15 for code that has been in place a long time. The crash report indicates this is happening during the call to saveAppData while trying to persist the state of the users tab order. There is a More Controller in the mix but this was working for literally years. I've been staring at this for days and can't find anything obvious. I am wondering if something changed with iOS 15 which is when this issue started . This is the relevant code: -(void)saveAppData { // Save Current Tab Order to Users Prefs NSMutableArray *savedOrder = [NSMutableArray arrayWithCapacity:TAB_BAR_NUMBER_OF_ITEMS]; NSArray *tabOrderToSave = _tabBarController.viewControllers; for(UIViewController *aViewController in tabOrderToSave) { [savedOrder addObject:@(aViewController.tabBarItem.tag)]; } [userSettings setObject:savedOrder forKey:SavedTabOrderKey];       // Save the TAG of selected TabBarItem   [userSettings setObject:@(_tabBarController.tabBar.selectedItem.tag) forKey:SavedTabLastViewedKey]; [userSettings synchronize]; } -(void)applicationDidEnterBackground:(UIApplication *)application { NSLog(@"**** Entering Background Saving Data");    [self saveAppData];     [self.coreDataUtil saveMOC]; } and here is the crash report. Any assistance on observations are most welcome. Thanks.

I use a WKWebView in the iOS and MacOS versions of my App. Both display the same HTML string (generated within the APP by the same shared class). The only difference in the HTML between iOS and MacOS is that on iOS this META is added to the head: meta name="viewport" content="initial-scale=1.0, minimum-scale=0.5, maximum-scale=3.0, shrink-to-fit=NO, user-scalable=YES" On MacOS the DOM inspector reports the correct page size (size of the HTML) 1864x844 element. And javascript run in the WKWebView after the page is fully rendered reports the same size given by the DOM inspector via these: document.documentElement.scrollWidth document.documentElement.scrollHeight But, on iOS BOTH the DOM Inspector (looking at a device in debug mode) as well as the same javascript run in the WKWebView reports an incorrect size for the html element, 768x895 The size it reports appear to be the visible viewport and this is long after the page was fully rendered. This is presenting a real problem because I need to be able to get the correct page size via Javascript run IN the page via the WKWebView evaluateJavaScript function. Interestingly though the WKWebView scrollView's contentSize IS correct. Any thoughts on what the heck is going on and how to get the correct size or is this an iOS WKWebView bug?! I've posted the same question along with pictures over on StackOverflow. The pictures help: [Same Question With Illustrative Pictures showing problem HERE].(https://stackoverflow.com/questions/66772470/wkwebview-size-fo-html-element-is-inconsistent-between-ios-and-macos)

I have Mac Apps and iOS Apps that have been in the App store for over 7 years. At the moment they are entirely separate Apps and do not use Catalyst. Is it possible to use the Subscription service to offer an annual subscription that offers access to the Mac version and the iOS version of the same App?

Can't enable the StoreKit test configuration file for a MacOS App. There is simply no dropdown from which to select it from in the Scheme Run Editor dialog? Am Running Xcode 12.0 Beta 5 on Catalina. This particular project is several years old and the MacOS App has been in the store for quite a while? To date I have been working in the latest version of Xcode 11. I followed the video and documentation steps to: Add a configuration file to the Project. Set test meta-data for several IAP non-consumables. But, when I try to enable the Configuration from Scheme Editor -> Run / Options there is NO Storekit Configuartion dropdown from which to select it. It is simply not there at all on the dialog?! Does the project have to be "converted" somehow to work with Xcode 12.