I have an odd bug. Whenever I run my app from Xcode, the order of sceneDelegate calls and view controller view lifecycle calls is different. When I run the app from Xcode I get what I thought was the standard lifecycle order of calls: 2022-02-25 12:10:04.9980 viewWillAppear()  2022-02-25 12:10:05.0380 In sceneWillEnterForeground  2022-02-25 12:10:05.0390 In sceneDidBecomeActive()  2022-02-25 12:10:05.0410 viewDidAppear()  But, if I take the same Xcode debug build and run it on my iPhone the view controller's viewDidAppear() is called before sceneDidBecomeActive(): 2022-02-25 12:08:43.8740 viewWillAppear() 2022-02-25 12:08:43.8790 In sceneWillEnterForeground **2022-02-25 12:08:43.8810 viewDidAppear() ** 2022-02-25 12:08:44.1690 In sceneDidBecomeActive() This happens every time. The issue I have is that since I spend most of my time in Xcode, I assumed that the order I was getting was always the same, so my code depends on that. Why does this happen and is there a way of guaranteeing that the root controller's viewDidAppear() is called after sceneDidBecomeActive() Thanks

Greetings, Trying to submit another build of my app to TestFlight, and while the first submission a few weeks ago was accepted and successfully passed the first TestFlight review for external testing, subsequent builds are now failing with that error either while uploading the app, or after it's uploaded and its state is "Processing". This is frustrating because without knowing the name of the private API being claimed that the app is using I have no clue as to where to even look. While I know that I'm not using any private Apple APIs in the app, I do link with 12 pods, so perhaps one of those pods is now using an Apple private API? The last action I remember taking after first successful submission, is to ensure that I could debug on an iOS simulator, since I'm on an M1 Mac and no longer on an Intel mac. Maybe that has something to do with it? Aside from opening a TSI, any suggestion as to how I can find the culprit? Or if it's a corrupted binary, how do I find out why or what is corrupted? If need be I will post the list of pods which I'm using. Thanks in advance

Hello, I am reaching out as I have encountered a problem while working with Xcode (versions 1.4.3 and 1.4.3.1), targeting iOS 16, that has me stumped. I currently have a project with multiple targets, all of which build successfully under normal circumstances. However, when I try to export localizations, I encounter build errors specifically related to a pod's umbrella.h header file. I want to stress that no such issues occur during regular builds for any of my targets. Given the nature of the error, I am wondering if there are specific flags or settings that are applied during the build process for exporting localizations that could potentially differ from a regular build. If there are, could these differences account for the discrepancies I am witnessing in terms of the success of the regular build versus the failure of the export localizations process? I would greatly appreciate any insights or guidance on how to resolve this. If anyone has encountered a similar issue or knows of any differences in the build process when exporting localizations, I'd be thankful for your input. Thank you in advance for your time and help.

Hello fellow developers, I've encountered a peculiar issue in iOS 16 that I wanted to bring to light and see if anyone else has experienced the same. Issue Description: When designing a user interface in a storyboard, if I set the alpha value of a UI component (e.g., UIView, UIButton) to 0.0 within the storyboard, and then programmatically change that alpha value to 1.0 during runtime, the alpha value unexpectedly reverts back to its original storyboard value (0.0) when the device transitions between light and dark modes. Steps to Reproduce: Create a UI component in a storyboard and set its alpha to 0.0. Programmatically change the alpha value of the component to 1.0 during runtime. Trigger a light/dark mode transition on the device. Observe that the component's alpha value reverts to 0.0. Additional Observations: This behavior seems as if the UIView is being reloaded from the storyboard during the mode transition. However, breakpoints set in viewDidLoad() and loadView() are not triggered during the mode change, indicating that the views are not being reloaded in the traditional sense. This issue was observed in iOS 16, but it's unclear if it's present in previous iOS versions. Has anyone else experienced this behavior? If so, are there any known workarounds or fixes? It's crucial for ensuring a consistent user experience across mode transitions. Thank you for your insights and assistance!

I have a complex project with > 10 targets, 14 pods and have issues with exporting localizations using Xcode 15. All my targets build in both DEBUG and RELEASE mode. It is only when I try to export localizations that it breaks. The error is always cannot find UIKit/UIKit.h. Cleaning the project and deleting derivedData folder has not worked for me. It would be ideal if I could do an export localization for a specified target only.