I just finished updating my app to support the new screen sizes for the iPhone 16 series devices (iPhone16 Pro and iPhone 16 Pro Max). In testing the changes, I've come across what I hope is simply a bug in the Xcode 16 simulators. I don't have any actual devices (yet) that I can use to test. In landscape mode, my app presents a "tab" on the right side of the screen that can be tapped to bring out another view. Activating the tab is based on capturing the screen coordinates from a "tap". In Xcode 16, using the iPhone16 simulators on IOS 18, the area of the tab does not recognize that a tap has occurred. After hours of banging my head against my laptop, it dawned on me that the area of the screen that hosts the "tab" is in exactly the same location as "unavailable area" that represents the camera on the simulator. I have arrived at the assumption that the issue is that the simulator is treating the same space at the bottom of the device as it treats that reserved area at the top of the screen. Has anyone else experienced this? Is this a bug in the simulator or is this expected behavior on the iPhone 16 series devices?

My app creates dynamic copies of UI controls that are based on a custom UIButton subclass using this legacy approach: let archivedButton = try NSKeyedArchiver.archivedData(withRootObject: self, requiringSecureCoding: false) guard let buttonDuplicate = try NSKeyedUnarchiver.unarchiveTopLevelObjectWithData(archivedButton) as? UIWagerButton else {return nil } I am currently trying to work passed the deprecation of NSKeyedUnarchiver.unarchiveTopLevelObjectWithData(data: Data) Per the guidance, I should be replacing that line with the following and ensuring that the custom class implements NSSecureCoding guard let buttonDuplicate = try NSKeyedUnarchiver.unarchivedObject(ofClass: UIWagerButton.self, from: archivedButton) else {return nil} However, while the code does compile and run, decoding the data reference throws the following error: value for key 'UIButtonStatefulContent' was of unexpected class 'NSMutableDictionary' I can only assume that if I get passed this specific property, there will be other properties that are also problematic. Question: Is this a bug? Or, am I now responsible for navigating the underlying property matrix of this UIControl to specifically, manually, handle the encoding and decoding of each of it's properties?

I'm using XCode 14.3.1, but this has been happening for a long time. After editing multiple storyboards, XCode becomes sluggish and eventually just stops responding. For me, it seems to happen after 4-5 storyboards are edited in succession. In today's example, I changed the name of a view controller that is shared by 9 storyboards. Despite opening one storyboard, changing the VC, and closing that storyboard before moving on to the next one, once I get to number 4 or 5, I have to close XCode and re-open. In some cases, I have to "Force Quit". Not only is XCode non-responsive, but it "tanks" my Macbook. I am observing when I am able to quit XCode that, despite having closed the storyboard editor, as XCode is shutting down, it cycles through each of the storyboards that had been opened during my editing. Each storyboard is briefly shown in a greyed out tab at the top of the studio and then a "No Editor" tab shows briefly. Is there some caching/optimizing going on in the background that needs to be reviewed?

I have not been able to find much chatter at all about the impact of not having dsym files via TestFlight to support Crashlytics reporting. Currently, I download the files from TestFlight and then upload them to Firebase. Then, a Slack integration is used to notify me when there is a new crash that needs to be investigated. Does the new change to XCode 14 basically remove Crashlytics from equation? Since I rely on Apple to sign the apps, I'm assuming that nothing local can be used. But, I'm also "still learning". Any insights/suggestions are appreciated.

My app deals card games. It also displays full screen ads at regular intervals. A while back ago, I introduced a consumable IAP to allow the Players to have X number of hands to be dealt without any ads being shown. I intentionally did not want to time box the feature. I wanted players to know how many hands they could reliably play without seeing an ad. At the time, App Review rejected the app and indicated that I could not offer that type of purchase as a consumable purchase; instead, if I wanted to offer an ad-free experience, it needed to be based on a subscription. I never fully understood the rejection and have yet to be able to find anything that clearly explains that "rule". I have been getting feedback/requests from my Players to offer this type of feature. Does anyone know if this is still the case or have any references to help understand this limitation that appears to be based solely on the fact that it is related to ads?

Apps appear to download and then the button state switches back to “install” and the app icon on the device indicates “waiting”

I activated a test build a few hours ago and users are still not getting the update. The Developer Status Page shows it "green", but all evidence points to the contrary. Normally, we get notifications instantaneously when a new build is ready for evaluation.

Out of the blue, I've started to get this message when trying to test IAP using TestFlight. On a couple of occassions, the message was different and referred to an inability to create a secure SSL connection. I have gone back and checked multiple prior builds and they present the same issue. I looked at the Developer Status page and everything is green. Is anyone else having this problem?