Recently I was trying to update my app to detect and support the latest Series 12 and Ultra 4 watches, as there is an element in the app that draws on the corners of the watch, hence corner radiuses must be matched with the device. That is a very small change, and I was still using Xcode 26.6 to build that app, as the app still supports watchOS 8.4 and above for now. However, the binary was rejected with the following in App Store Connect: 90389: Size limit exceeded. The size of the watchOS variant at “/Payload/Pigeon.app” is 105MB, which exceeds the maximum allowable size of 75MB after app thinning. For details about reducing your app’s size, view: https://developer.apple.com/documentation/xcode/reducing-your-app-s-size. Considering that the recent prior builds (the last being from Sep 7) all uploaded and processed fine, with pretty much similar contents and sizes, just minor fixes and minor feature changes for TestFlight users, I don't see why this latest build should be rejected, unless there is a change in how it is calculated under the hood. My prior presumption was that the size limit was calculated based on each architecture slice, so as long as no slices exceed 75MB, it should be alright. (and it appears to be the case for the past years) My guess here is that, since the uploaded binary still contained an armv7k slice, it fails the validation, as perhaps something was changed in the backend to not consider it, but rather to consider as a whole, which resulted in the rejection. The requirement to have a minimum SDK of 27/Xcode 27 only starts on April 2027, so until then, I don't see why there should be a change in this calculation or premature size limitation for app updates that still target watchOS 8. I've tried to recompile the app with an updated minimum OS deployment of watchOS 9 via Xcode 27, which drops armv7k, and sure enough, App Store Connect takes it. I've filed this as FB24807214. I assume it's a bug. Let me know if it isn't. Thank you. PS: Food for thought, its 2026, all watches that supports the latest watchOS 27 comes with 64GB of storage, up from 8/16GB of storage, in 2017, when the watchOS app size limit was last increased from 50MB to 75MB. Maybe its time for a fresh review?

It appears that starting with macOS Sequoia, Quick Look Preview extension no longer loads MapKit maps correctly anymore. Map tiles do not appear, leaving users with a beige background. Users report that polylines do render correctly, but annotations appears black. This was previously working fine in prior macOS versions including Sonoma. STEPS TO REPRODUCE Create a macOS app project, with an associated document. Ensure project has a Quick Look preview extension, with necessary basic setups. Ensure that the extension mentioned in (2) must have a MKMapView. Any other cosmetic changes, etc, does not need to be implemented to observe the base issue. Do note that it has been reported that in addition to the map tiles not loading, annotations don't render correctly as well.

Looking into making requests using URLSession via a proxy, on watchOS, and found that in URLSessionConfiguration, there's a proxyConfigurations property. However, since ProxyConfiguration is part of the Network framework, does it means that TN3135 low level networking rules also applies in this case?