Furthermore this only happens if I use a color from my assets.xcassets catalog. So it appears to be a bug, which is color catalog related and affects the current state of the UIView and its subcomponents. If I revert back to using a default color, there's no issue whatsoever. Feedback # FB12984060 I can post the code and maybe the storyboard and you can try this yourself.

It should respect the active/inactive state as is at runtime, and rebuild the UI wiht those components, not throwaway your state, and revert back to the NSLayoutConstraints as set in the storyboard. Let me put it this way. If I have 10 NSLayoutConstraints, 9 of which are set to inactive in the storyboard and only one is active, if at runtime the app makes the 9 layout constraint active and the 1 active constraint inactive, light/dark mode change will revert to the original storyboard setup.

No, it should not go back to the initial storyboard state, where constraint X was deactivated. It should work with the current UIView hierarchy and the current constraints, with whatever their active state was set in the code. Why would this also happened when changing from light/dark mode? With rotation or changing light/dark mode, the current UIView hierarchy and its current set of layout constraints should be respected, especially if they were modifications to their state in the code.

The issue also happens on a device running iOS 17.0 beta 6 BTW, but the app was built as an archive and installed on the iOS 17.0 device using Xcode 14.3.1. I did not use Xcode 15 beta for that.

My testing is on a iPhone running iOS 16.6, using Xcode 14.3.1. The issue does not occur on a simulator running 16.4, possibly because it is an iOS 16.6 issue. I will create and post a simple app to reproduce this issue.

Hi @kennnn, did you update your branch's pod file with the post_install hook and run pod install again? Maybe that's why it failed on your branch?

Thanks @kennnn!!

@icape, I have the same issue. All of my targets build correctly using Command B, as well as archiving them, however export localization fails, complaining that my source code cannot compile due to a missing -umbrella.h file of a specific pod of mine. Need to know what flags are passed to the export localization's build process

The issue with this solution is that if I do a new pod install, the ...-frameworks.sh files are regenerated and I have to update that text all over again. I updated pod as well with the latest version but that did not fix it the issue

Looks like a lot more devs are now having similar issues issue with App Store Connect. Now logging into app store connect gives me a blank screen when I go to my apps page. I was able to upload my app via the transporter. Am now waiting for the dreaded ITMS-90338: Non-public API usage - exception.

@oviano thank you for confirming that you're also having a similar issue. This is strongly leading me to believe that it's App Store Connect, since system_status says that App Store Connect has 2 unresolved problems