I tried the above solutions and even using UIBarItem's setTitleAttributes for state, but none of them worked consistently for me. As a last effort, I set the tintColor on the UIBarButtonItem: let isEnabled = <computed property> myBarButtonItem.isEnabled = isEnabled myBarButtonItem.tintColor = isEnabled ? UIColor.systemBlue : UIColor.systemGray

I think there's more to the story that bears consideration: @IBOutlet annotation merely allows a variable to be exposed to Interface builder. It doesn't require it to actually be correctly connected to a Xib. If it were unconnected and the variable were referenced within code, the app would crash. We've all experienced this developer error. Fatal error: Unexpectedly found nil while implicitly unwrapping an Optional value 2. Contrary to a popular WWDC presentation by a UIKit engineer (2015?) who stated that IBOutlets should now be strong, the Apple docs haven't changed. It still recommends @IBOutlet's should be weak var and implicitly unwrapped, since as QuinceyMorris states above, the view hierarchy does hold strong references to correctly attached IBOutlets, thus allowing the object holding the IBOutlet to do so weakly. 3. As always, the devil is in the details with a notable exception: If a UI element is to be added or removed programmatically, it may need to be held with a strong reference because removing a weakly held IBOutlet element from the view hierarchy that currently holds it strongly would cause it to be immediately deallocated if no other references held it strongly.

@eskimo this is happening from within Xcode (File > New > Playground) Xcode 15.2 for me

just posted a bug to Apple Developer Feedback...this is still an issue in iPadOS 17 App is using a UISplitViewController with the new column style init. Both primary and secondary child view controllers are subclasses of UITableViewController (yes, I need to move to CollectionViewController ASAP)... This bug occurs when I am in landscape and select iPadOS "Split View" by tapping on the 3 dots menu on top of the screen. As my app slides to the left, this Xcode console occurs. The backtrace from the symbolic break point indicates there are NO calls in my code in the back trace. This is an apple UIKit bug! Workaround for overriding layouSubviews likely to work... here's the backtrace... (lldb) bt thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 4.1 frame #0: 0x00000001942cd8dc UIKitCore`UITableViewAlertForLayoutOutsideViewHierarchy frame #1: 0x0000000193579fd0 UIKitCore`-[UITableView _updateVisibleCellsNow:] + 208 frame #2: 0x0000000193579e34 UIKitCore`-[UITableView layoutSubviews] + 148 frame #3: 0x000000019332797c UIKitCore`-[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 1528 frame #4: 0x000000019273caa8 QuartzCore`CA::Layer::layout_if_needed(CA::Transaction*) + 500 frame #5: 0x000000019332aa2c UIKitCore`-[UIView(Hierarchy) layoutBelowIfNeeded] + 296 frame #6: 0x000000019341efac UIKitCore`-[_UIViewControllerTransitionCoordinator _applyBlocks:releaseBlocks:] + 128 frame #7: 0x000000019337b590 UIKitCore`-[_UIViewControllerTransitionContext __runAlongsideAnimations] + 272 frame #8: 0x0000000193aa0fc4 UIKitCore`-[_UIWindowAnimationController animateTransition:] + 288 frame #9: 0x00000001936a363c UIKitCore`-[UIWindow _adjustSizeClassesAndResizeWindowToFrame:] + 620 frame #10: 0x000000019337e29c UIKitCore`-[UIWindow _resizeWindowFrameToSceneBoundsIfNecessary] + 204 frame #11: 0x000000019346402c UIKitCore`-[UIWindow _sceneBoundsDidChange] + 64 frame #12: 0x0000000193465490 UIKitCore-[_UIScenefbsSceneBasedMetricsCalculator _updateMetricsOnWindows:animated:] + 940 frame #13: 0x00000001934650bc UIKitCore-[UIWindowScene _computeMetricsForWindows:animated:] + 88 frame #14: 0x00000001935287b8 UIKitCore`__55-[UIWindowScene _computeMetrics:withTransitionContext:]_block_invoke + 104 frame #15: 0x00000001935282b0 UIKitCore`-[UIWindowScene _computeTraitCollectionAndCoordinateSpaceForcingDelegateCallback:withAction:] + 296 frame #16: 0x000000019352817c UIKitCore`-[UIWindowScene _computeMetrics:withTransitionContext:] + 104 frame #17: 0x00000001943290b8 UIKitCore`-[UIWindowScene _computeMetricsAndCrossFadeInLiveResize:withTransitionContext:] + 192 frame #18: 0x000000019342dd98 UIKitCore`+[BSAnimationSettings(UIKit) tryAnimatingWithSettings:fromCurrentState:actions:completion:] + 736 frame #19: 0x000000019342d620 UIKitCore`_UISceneSettingsDiffActionPerformChangesWithTransitionContextAndCompletion + 224 frame #20: 0x0000000193609fac UIKitCore`-[_UIWindowSceneGeometrySettingsDiffAction _updateSceneGeometryWithSettingObserverContext:windowScene:transitionContext:] + 448 frame #21: 0x000000019342f728 UIKitCore`-[_UIWindowSceneGeometrySettingsDiffAction _performActionsForUIScene:withUpdatedFBSScene:settingsDiff:fromSettings:transitionContext:lifecycleActionType:] + 1048 frame #22: 0x00000001937b10a8 UIKitCore`__64-[UIScene scene:didUpdateWithDiff:transitionContext:completion:]_block_invoke.225 + 612 frame #23: 0x000000019342c454 UIKitCore`-[UIScene _emitSceneSettingsUpdateResponseForCompletion:afterSceneUpdateWork:] + 216 frame #24: 0x000000019342c2c4 UIKitCore`-[UIScene scene:didUpdateWithDiff:transitionContext:completion:] + 244 frame #25: 0x000000019342c104 UIKitCore`-[UIApplicationSceneClientAgent scene:handleEvent:withCompletion:] + 336 frame #26: 0x00000001a955c5b4 FrontBoardServices`-[FBSScene updater:didUpdateSettings:withDiff:transitionContext:completion:] + 660 frame #27: 0x00000001a955c300 FrontBoardServices`__94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke_2 + 152 frame #28: 0x00000001a955c19c FrontBoardServices`-[FBSWorkspace _calloutQueue_executeCalloutFromSource:withBlock:] + 168 frame #29: 0x00000001a955c0b8 FrontBoardServices`__94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke + 344 frame #30: 0x0000000105d36b34 libdispatch.dylib`_dispatch_client_callout + 20 frame #31: 0x0000000105d3a530 libdispatch.dylib`_dispatch_block_invoke_direct + 300 frame #32: 0x00000001a9558520 FrontBoardServices`FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK + 52 frame #33: 0x00000001a95584a0 FrontBoardServices`-[FBSMainRunLoopSerialQueue _targetQueue_performNextIfPossible] + 240 frame #34: 0x00000001a9558378 FrontBoardServices`-[FBSMainRunLoopSerialQueue _performNextFromRunLoopSource] + 28 frame #35: 0x000000019110112c CoreFoundation`CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION + 28 frame #36: 0x00000001911003a8 CoreFoundation`__CFRunLoopDoSource0 + 176 frame #37: 0x00000001910feb5c CoreFoundation`__CFRunLoopDoSources0 + 244 frame #38: 0x00000001910fd898 CoreFoundation`__CFRunLoopRun + 828 frame #39: 0x00000001910fd478 CoreFoundation`CFRunLoopRunSpecific + 608 frame #40: 0x00000001d46564f8 GraphicsServices`GSEventRunModal + 164 frame #41: 0x000000019352162c UIKitCore`-[UIApplication _run] + 888 frame #42: 0x0000000193520c68 UIKitCore`UIApplicationMain + 340 frame #43: 0x0000000104eb4220 MyApp`main at AppDelegate.swift:13:7 frame #44: 0x00000001b3e22dcc dyld`start + 2240

In Xcode 15, tap your project upper left, then your target, then Build Settings, then select "All" (not just Basic).

Just like @blaap, I too wasted most of a full day on this. My app uses a framework I built. The framework uses 'default build settings' including the "Skip install" set to NO. I wanted to use the automatic signing but that always produced an archive with the "Distribute Content" that @joerick mentions. It had been a while since I setup an app in the store so I forgot that it should say "Distribute App". Once I followed @joerick advice, I quickly found and changed Skip install to YES and BINGO, I have Distribute App and Validate App both enabled!! Apple would do well to have some tips and suggestions so others don't burn up a day on this crap since the framework used default settings. FWIW, I also unchecked "Allow Archiving for Simulator" because that seems to disable the Distribute App and Validate App options. Instead, I just created an archive for Any iOS

I modified the above func to add code to detect if the Help Session already exists: func helpMenuTappedHandler(_ action: UIAction) { // check if Help Window already exists before requesting one if let helpScene = UIApplication.shared.connectedScenes.first(where: { $0.session.configuration.name == SceneConfiguration.helpWindowConfiguration }), let helpWindowScene = helpScene as? UIWindowScene { let window = helpWindowScene.keyWindow ?? helpWindowScene.windows.first window?.makeKeyAndVisible() return } .... } This does seem to work, except that if the Help Window is behind the Main Window, the call window?.makeKeyAndVisible() does not bring that Window in front of the other Main window as expected... I'm starting to wonder if I should just create the Help window as another window inside the Main UIScene instead of in its own Scene. Thoughts?

Not directly related but it's close :D I see my help Help Window shows up under the Window menu, but it has the same name as the Main Window (the app name). How can I edit the name of the window used in the Window Menu?

I have no private relay enabled. iPadOS Mail client continues to work just fine and is running 17.x...my macOS is at Sequoia 15.1.1 and I'm planning to hold off on 15.2 until I hear iOS 18 fixes mail or that 15.2 doesn't break Mail.

So if I deleted my IMAP mail account on the iPhone, quit Mail app, then re-add the IMAP mail account. I get the current set of mail. Thereafter, I don't. I've tested with both Push and Fetch and it doesn't seem to make any difference. It defaults on my account to Push which should be accurate since I have Push Notifications setup on that old macOS Mail server with a valid certificate.

just to clarify, this widely discussed problem is not related to encryption, certs, nor VPN, although other mail issues may be reported This problem is about broken sync of mailbox in iOS 18 mail with IMAP.

https://discussions.apple.com/thread/255760058?login=true&sortBy=newest_first Oddly this thread got locked when it started heating up...nothing to do with inactivity.

I can attest this is the same in 2025. I had released a 1.0 then a 2.0 of the app, then a trademark issue came up with the app name. Given that the bundle identifier used the app name in it, I decided given the low volume of paid customers that I would change the bundle identifier also. You may ask, why bother since the bundle identifier is not seen by anyone? However when you use the Share button within the app store after you go to your app, the URL that is created includes both the bundle identifier and the Apple ID created for your app. There is a URL that only includes the Apple ID for the app for purposes of posting a link to the app store app, however the default Share link that any user could use to share the app to someone else does include the bundle identifier in the URL. One other note. I was trying to get the new app approved by Apple Review team before taking down the old app, and they rejected the new app during review using the SPAM reason for rejection. After I removed the old app (which is a two step process - remove app from sales world wide (if paid), and remove app from store), I resubmitted for review and was approved, then released new app. I did try to see if Apple had a way to keep the same Apple ID for the app, and just change the bundle identifier but that does not seem, sadly, to be the case. They should and could probably fix that but...