I received the following crash: Thread 0 Crashed: libsystem_kernel.dylib __pthread_kill + 8 libsystem_pthread.dylib pthread_kill + 296 (pthread.c:1721) libsystem_c.dylib abort + 124 (abort.c:122) libc++abi.dylib __abort_message + 132 (abort_message.cpp:66) libc++abi.dylib demangling_terminate_handler() + 304 (cxa_default_handlers.cpp:76) libobjc.A.dylib _objc_terminate() + 156 (objc-exception.mm:496) libc++abi.dylib std::__terminate(void (*)()) + 16 (cxa_handlers.cpp:59) libc++abi.dylib __cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 88 (cxa_exception.cpp:152) libc++abi.dylib __cxa_throw + 92 (cxa_exception.cpp:299) libobjc.A.dylib objc_exception_throw + 448 (objc-exception.mm:385) Foundation -[NSConcreteMutableAttributedString initWithString:] + 268 (NSAttributedString.m:1049) CloudDocs -[BRCloudPathComponentDisplayMetadata initWithDisplayName:suffix:url:icon:] + 180 (BRCloudPathComponentDisplayMetadata.m:75) CloudDocs -[NSURL(BRCloudPathComponent) br_pathComponentDisplayMetadataWithOptions:]_block_invoke + 516 (BRCloudPathComponentDisplayMetadata.m:292) CloudDocs -[NSArray(BRAdditions) br_transform:keepNull:] + 228 (NSArray+BRAdditions.m:20) CloudDocs -[NSURL(BRCloudPathComponent) br_pathComponentDisplayMetadataWithOptions:] + 76 (BRCloudPathComponentDisplayMetadata.m:276) AppKit -[NSPathCell _autoUpdateCellContents] + 2080 (NSPathCell.m:442) AppKit -[NSPathCell setURL:] + 76 (NSPathCell.m:599) AppKit -[NSPathControl setURL:] + 64 (NSPathControl.m:366) I tried reproducing on my end by passing various URLs in iCloud Drive to an NSPathControl, file reference urls, attempting to evict a URL from iCloud Drive then settings the URL property without luck. Setting the URL to nil does not crash (the property is nullable). I have no idea how to trigger that code path. Anyone else run into this and have a workaround?

I have (had) a view controller that does a bit of manual layout in a -viewDidLayout override. This was pretty easy to manage - however since introducing NSGlassEffectView into the view hierarchy I sometimes am getting hit with "Unable to simultaneously satisfy constraints" and Appkit would break a constraint to 'recover.' It appears translatesAutoresizingMaskIntoConstraints is creating some really weird fixed width and height constraints. Here I wasn't doing any autolayout - just add the glass view and set its frame in -viewDidLayout. At runtime since I do manual layout in -viewDidLayout the frames are fixed and there is no real "error" in my app in practice though I wanted to get rid of the constraint breaking warning being logged because I know Autolayout can be aggressive about 'correctness' who knows if they decide to throw and not catch in the future. In my perfect world I would probably just prefer a view.doesManualLayout = YES here - the subviews are big containers no labels so localization is not an issue for me. Rather than playing with autoresizing masks to get better translated constraints I decided to set translatesAutoresizingMaskIntoConstraints to NO and make the constraints myself. Now I get hit with the following exception: "The window has been marked as needing another Layout Window pass, but it has already had more Layout Window passes than there are views in the window" So this happens because the view which now has constraints -- I adjusted the frame of it one point in -viewDidLayout. My question is - is not legal to make changes in -viewDidLayout - which seems like the AppKit version of -viewDidLayoutSubviews. In UIKit I always thought it was fine to make changes in -viewDidLayoutSubviews to frames - even if constraints were used - this is a place where you could override things in complex layouts that cannot be easily described in constraints. But in AppKit if you touch certain frames in -viewDidLayout it can now cause this exception (also related: https://developer.apple.com/forums/thread/806471) I will change the constant of one of the constraints to account for the 1 point adjustment but my question still stands - is it not legal to touch frames in -viewDidLayout when autolayout constraints are used on that subview? It is (or at least was if I remember correctly) permitted to change the layout in -viewDidLayoutSubviews in UIKit but AppKit seems to be more aggressive in its checking for layout correctness). What about calling -sizeToFit on a control in viewDidLayout or some method that has side effect of invalidating layout in a non obvious way, is doing things like this now 'dangerous?' Shouldn't AppKit just block the layout from being invalidated from within -viewDidLayout - and leave whatever the layout is as is when viewDidLayout returns (thus making -viewDidLayout a useful place to override layout in the rare cases where you need a sledgehammer?)

I'll try to ask a question that makes sense this time :) . I'm using the following method on NSFileManager: (BOOL) getRelationship:(NSURLRelationship *) outRelationship ofDirectoryAtURL:(NSURL *) directoryURL toItemAtURL:(NSURL *) otherURL error:(NSError * *) error; Sets 'outRelationship' to NSURLRelationshipContains if the directory at 'directoryURL' directly or indirectly contains the item at 'otherURL', meaning 'directoryURL' is found while enumerating parent URLs starting from 'otherURL'. Sets 'outRelationship' to NSURLRelationshipSame if 'directoryURL' and 'otherURL' locate the same item, meaning they have the same NSURLFileResourceIdentifierKey value. If 'directoryURL' is not a directory, or does not contain 'otherURL' and they do not locate the same file, then sets 'outRelationship' to NSURLRelationshipOther. If an error occurs, returns NO and sets 'error'. So this method falsely returns NSURLRelationshipSame for different directories. One is empty, one is not. Really weird behavior. Two file path urls pointing to two different file paths have the same NSURLFileResourceIdentifierKey? Could it be related to https://developer.apple.com/forums/thread/813641 ? One url in the check lived at the same file path as the other url at one time (but no longer does). No symlinks or anything going on. Just plain directory urls. And YES calling -removeCachedResourceValueForKey: with NSURLFileResourceIdentifierKey causes proper result of NSURLRelationshipOther to be returned. And I'm doing the check on a background queue.

I notice if I pop a view controller off a UINavigationController's navigation stack using the interactivePopGestureRecognizer, every so often the view controller being popped off is not being released from memory. Haven't been able to come up with a workaround or determine anything that seems to make the issue reproduce reliably. I simply log out dealloc in the view controller that is going to be popped. Push and pop a few times and notice that dealloc doesn't log out after it is being popped off. Not sure if something in the UI (other animation) that is interrupting the pop gesture's _UINavigationInteractiveTransition ... I haven't been able to track down what is retaining my view controller. When the issue happens I can see it is still in memory (I have it listen to UISceneWillEnterForegroundNotification and I put the scene in the background then move it to the foreground and hit a breakpoint). But...I can't seem to figure out what is strongly retaining the view controller. From he debugger I start setting view controller properties to nil to see if I can break a potential retain cycle I created) but no luck. I'm only able to reproduce the memory leak when I dismiss the view controller with the interactive pop gesture (not the back button). I know that's not a lot to go on but am wondering if someone has experience anything similar and has a potential workaround?

Started happening kind of out of nowhere. Any ideas?

Have an app I'm working on that stores an item in the keychain. Everything was was working fine. I have a button in the UI that allows the user to clear out the keychain item:NSDictionary *query = @{(__bridge id)kSecClass: (__bridge id)kSecClassGenericPassword, (__bridge id)kSecAttrService: service, (__bridge id)kSecAttrAccount: accountKey}; OSStatus status = SecItemDelete((__bridge CFDictionaryRef)(query));Status is -25244 which is errSecInvalidOwnerEdit. This app created the keychain item to begin with. What would be the appropriate way to handle this type of error?

So, a UItableview inside a *regular* UIViewController (not using UITableviewcontroller).1) This view controller is embedded in a UINavigationController. The navigation item has "automatic' large title mode.2) The navigation controller's nav bar prefers large title.3) When the table view is scrolled, the big title does *not* shrink to the *regular* title size like in the iOS mail app. Instead, the table view content overlaps the navbar and bleeds through, making a UI glitch.On iOS 12 the scrolled content does not overlap the nav bar. This is new in IOS 13. Anyone get this and have a workaround?

My developer account uses a different AppleId from the AppleID I use on my devices. Therefore, when I test on my device, I can't look at any of the data in the CloudKit dashboard. It would be a real pain in the neck to have to sign out of icloud and use my developer apple id on my devices just to test. Is there no way to use a different AppleID for CloudKit in the "sandbox" environment like we can for IAP?

I'm getting ready to release a new app that uses CloudKit. I just deployed my Development schema to Production in CloudKit dashboard. Is there a way to run my app from Xcode using the CloudKit Production environment for testing? Details of how to test in the production environment are described here: https://developer.apple.com/library/archive/documentation/DataManagement/Conceptual/CloudKitQuickStart/TestingYourApp/TestingYourApp.html But would be faster (and easier for debugging potential issues) if I could select tell Xcode to use the production environment when running from the debugger. Is this supported? Thanks

After upgrading to Xcode 14 I cannot submit an update to one of my apps that uses the GoogleMobileAdsSDK. I'm getting the following error when I try to submit to the App Store: Missing or invalid signature. The bundle 'com.firebase.Firebase-nanopb' at bundle path 'Payload/PATH_HERE/nanopb.framework' is not signed using an Apple submission certificate. Anyone else getting this and know of a solution?

Testing on the iPhone 14 Pro simulator I notice if the device is in the landscape orientation, snapshot images my app takes are clipped (the x origin is off). I take a snapshot of a view like this: -(UIImage*)getSnapshotForView:(UIView*)snapShotView {  UIGraphicsBeginImageContextWithOptions(snapShotView.bounds.size, NO, 0.0f); [snapShotView drawViewHierarchyInRect:snapShotView.bounds afterScreenUpdates:YES]; UIImage *snapShotImage = UIGraphicsGetImageFromCurrentImageContext(); UIGraphicsEndImageContext(); return snapShotImage; } So I have an iPhone SE 3rd gen and all is working fine. But I figured I'd test in the iPhone 14 Pro simulator. When the simulator is in landscape mode the generated image is inset like 100 points on the x origin and the content is clipped off on the right side. So I looked at the view I was snapshotting and I thought I wasn't accounting for safe area insets properly (right and left) but I was. The subviews of the view I'm snapshotting all have the expected CGRect value for their frames. Looks like iPhone 14 Pro is rendering snapshots location on the x axis when the device is in landscape mode (at least that appears to be the case in the simulator at least). Any ideas if I'm doing something wrong?

I’m trying to migrate a custom UITableViewCell to use a content configuration so I can properly subclass the content view (setting a subclass on the content view in Interface Builder apparently is not supported). So when I load up the cell and set the content configuration my console is flooded with these logs: Warning: You are setting a new content configuration to a cell that has an existing content configuration, but the existing content view does not support the new configuration. This means the existing content view must be replaced with a new content view created from the new configuration, instead of updating the existing content view directly, which is expensive. Use separate reuse identifiers for different types of cells to avoid this. Make a symbolic breakpoint at UIContentConfigurationAlertForReplacedContentView to catch this in the debugger. Cell: <MyCellSubclassHere: 0x15d0b5c00> Existing content configuration: (null); New content configuration: <MyCustomConfigurationHere: 0x6000034ad190> As you can see the existing content configuration is nil. I tried setting my custom content configuration as early as possible (by overriding the designated initializer on UITableViewCell) as a workaround but that didn't work. Still console spew. And by the time cellForRowAtindexPath: is called the content configuration is always nil and has to be rebuilt (apparently UIKit is setting it to nil in prepareForReuse?) I also tried overriding -setContentConfiguration: to catch when the configuration is being set to nil but UIKit must be setting the ivar to nil directly, because the setter is never called with nil. Anyone know of a workaround? I don't want to ship an app that constantly logs this out on scroll. I opened FB11595949

I noticed an Xcode Extension I wrote a couple of years ago isn't showing up in the Editor menu of Xcode. So I opened up the project, ran the Extension and the grayed out version of Xcode shows up but my extension no longer appears in the "Editor" menu. So I just tried to create a brand new Xcode project, with an Xcode extension. Right out of the box, no code changes from the template, and I can't get the new project's Xcode extension to appear in the "Editor menu". In System Preferences the app is checked off under "Xcode Extensions" but still nowhere to be found?

Experimenting with Mac Catalyst a bit. I see sometimes the compiler warns me about an API and suggests this fix:   if (@available(macCatalyst 15.0,*)) { /// Use API for this version of catalyst.... } And when I switch back to run on an iOS device the warning comes back and this time I get the suggestion: if (@available(iOS 15.0, *)) { //iOS 15 } If I just use the @available iOS 15 check and remove the macCatalyst check the compiler stops warning me when I try building on my Mac and on iOS, but the same isn't true the other way around (if I have code inside the macCatalyst version check, switching to build for an iOS device still warns me). I was expecting that code inside the if @available(macCatalyst 15,*) statement would only run on Mac catalyst if the version of macOS supports the API, but would not run on iOS at all (even if the API is available there too) but I still get compiler warnings on iOS and a suggestion for an extra if (@available(iOS 15.0, *)) which produces the following:  if (@available(macCatalyst 15.0,*))     {         if (@available(iOS 15.0, *))         { //do something iOS 15 and later...and macCatalyst 15 and later. } } What do I make of the macCatalyst availability check? It comes up in code completion but just using the iOS check seems like the correct way (it silences compiler warnings but I haven't tested on an older version of macOS to see if using any of this API would produce a crash). I conclude that if (@available(iOS 15.0, )) should be used pretty much always instead of if (@available(macCatalyst 15.0,)) and if I need code only for Mac Catalyst I should check the TARGET_OS_MACCATALYST macro instead:  #if TARGET_OS_MACCATALYST #else //iOS only #endif Is that correct?

Working on a Mac Catalyst version of one of my apps. I noticed making changes on my iPhone (debug environment) aren't being pushed to my Mac (also in debug environment). Then when I quit and relaunch the app and manually force an iCloud sync at launch I get all the changes. At app launch I see the following method is being called on my AppDelegate after I attempt to register remote notifications: -application:didFailToRegisterForRemoteNotificationsWithError: with the error: Notifications are not allowed for this application" UserInfo={NSLocalizedDescription=Notifications are not allowed for this application}. Anyone experience this and have a solution? Under "Signing and Capabilities" I see an entry for Push Notifications for iOS and macOS.