The new UIView properties maximumContentSizeCategory and minimumContentSizeCategory sound really useful. But I’m finding the following odd behaviors and am not sure whether these are bugs or features: Setting these properties on a scene's root UIWindow has no effect. The WWDC video says it applies “to view hierarchies” but it seems you actually need to set these directly on each view controller’s root view individually. Maybe that’s by design to prevent “abuse” without requiring a bit of extra work. If you set them on a UITableView the result is inconsistent. It affects cell content correctly, but section headers and footers don’t respect the setting, giving a weird result where the headers and footers can be larger than the cells. I would expect it to affect the table’s entire view hierarchy (cells, headers, and footers) in order to give a coherent appearance. I’m seeing these behaviors on all iOS 15 releases including the current 15.4 beta 2.

When an app is running full screen, is there an API to detect when a secondary app is running as a Slide Over window on top? I don't see anything in the lifecycle calls or trait collection that indicates this. Why? I want to modify my app logic when running behind a Slide Over window, as a consequence of this issue where CLLocationManager’s location authorization request API doesn't work as expected when in one of the iPad multitasking modes. That causes a bad user experience where the user clicks a button expecting an authorization prompt, but nothing happens. (A cleaner solution would be to detect when the system defers presenting the location authorization prompt, but that doesn't seem to be supported either. The prompt can eventually appear after dismissing the Slide Over window, but that's too late to help a confused user.)

This is a problem that I can repro on one iPhone 12 Pro Max here, and is reported by a few users in the field, but doesn't repro on any other devices here and I can't find a pattern to it (except all user reports so far are on iOS 15). Depending on how widespread it is, it could be pretty bad. Basically, if you write a simple socket-based app to (in my case) connect to an HTTP server, send a GET request for a very large file, read some bytes of the response, and then close the socket before the download completes, then after one or more iterations of this sequence, it stops working. Specifically, after it "breaks", then subsequently trying to connect a socket to any host at all fails by timing out. It remains "broken" even after killing and relaunching my app. And (here's the scary part) BSD sockets are now "broken" for all other apps on the device and remain broken until you reboot the device. It’s as if the BSD network stack in the OS kernel has fallen over. Really. Of course I'm preparing to submit an FB including a minimalist sample app that demonstrates the issue. But it seems like a rare occurrence that luckily happens to affect my own phone, so I wanted to see if this sounds familiar to anyone else. I'm thinking there's nothing an app should be able to do within its own process/sandbox that should affect the behavior of system APIs for other apps and require a reboot to fix. So, yeah.

I just submitted a feedback for this (FB9662125) but in the spirit of “share and enjoy”… The cool new Generate Info.plist File feature in Xcode 13 crashes if you try to put an NSLocationTemporaryUsageDescriptionDictionary in your Info.plist file. Here’s a simple repro scenario: Create a minimal iOS app (no Core Data, no tests) Go to target settings → Info tab → Custom iOS Target Properties Click the (+) button on any row to begin inserting a new row Select Privacy - Location Temporary Usage Description Dictionary Click somewhere else or press Return to commit the selection Xcode crashes immediately More generally, it seems that Xcode crashes any time it tries to regenerate your Info.plist file if it contains an NSLocationTemporaryUsageDescriptionDictionary, even if (for example) you manually pasted that dictionary into the file earlier. In that case, merely tapping the (+) button in step 3 above is enough to crash it.