In iOS 27, willTransition(to:with:), registerForTraitChanges(), and other mechanisms to monitor size classes do not change when an iPhone interface is resized. Only viewWillTransition(to:with:) is invoked with a new size. And this only happens on the iPhone: the iPad continues to work as it has in the past. It appears that this is intended behavior. That is not to say that it's intuitive behavior. Many experienced developers are encountering the "horizontal size is always compact" behavior and immediately thinking "this must be a beta bug": https://fatbobman.com/en/posts/from-size-class-to-available-space/ But it's not. I get that the new size class behavior is expressing static device semantics and is no longer a dynamic size indicator. The problem is that the tools we have been using to build layouts for the past decade use size classes as dynamic sizing indicators. Storyboards can contain variations that specify whether a constraint is used for regular or compact widths/ heights. Developers have used this ability to automatically adjust layouts as the size classes change. In one case, I use this capability to adjust a top-over-bottom layout in a portrait configuration to a side-by-side in a landscape configuration: switching centering, leading/trailing, and aspect ratios to fit the available size. I suspect that many developers who have taken the time to create a unique layout for an iPad are doing something similar. (Ironically, the folks who treated an iPad as a big iPhone are the ones least affected by this change.) When iPadOS got the ability to resize interfaces (as UIScene windows), I made sure that the automatic size class contraints worked correctly and made adjustments as necessary. That work now has to be discarded and switched over to something more universal. If this is truly the intended behavior going forward, time needs to be invested in updating the tooling behind automatic constraint variations: There should be warnings when the storyboard is compiled. I have dozens of automatic contraints embedded in the storyboard: and they're hard to find (each subview has its own contraints, so it's a manual traversal of a huge tree). There should be runtime warnings that your code that inspects size classes won't be executed. This was the biggest "what the hell is going on?" when trying to resize the interface the first time. At a higher level, Apple engineers have described what is happening. They have not explained why the iPhone is behaving differently than an iPad. And that's the root of this whole situation being unintuitive. We've got no clue. And developers without a clue are unlikely to adopt a new technology. It's essential that Apple explains this change in more detail. Yes, you're going to have to obfuscate it and make us read between the lines, but it's got to be done. (Everyone understands the changes regarding mainScreen wink wink, for example.) A reply in this thread would be a good place to start this explanation.

I'm trying to setup a macOS 26 build environment in a VM (using UTM and the virtualization framework Apple provides). I have Xcode 26 installed and have logged into my Apple ID and verified that the team and other configuration looks fine in Xcode settings. When trying to build the macOS app, I see errors saying the VM's device ID has not been registered. I have confirmed that the device ID is registered both in the Provisioning portal AND the downloaded .provisionprofiles (in Library > Developer > Xcode > UserData). This problem appears on multiple targets (e.g. the main app and extensions). If I try to manually provision the app, using the Provisioning portal, I can build the product, but it will not launch because of Gatekeeper issues. Finally, signing to run locally doesn't work either. As the app launches, frameworks refuse to load because Team IDs don't match. With ad hoc provisioning, there are no Team IDs. I've come to the conclusion that this just isn't possible. Which is a shame because I need to support products with a build environment on macOS 15 and cannot move over to macOS 26 yet. I suspect many developers outside of Apple are in a similar position.

There are use cases where someone who's using an Apple Pencil may not want to enter text via Scribble. A simple example is writing "UIViewController" in a text view is unlikely to be successful. I'd like to disable Scribble in this case and let the keyboard become the input mechanism. (Disabling Scribble system-wide in Settings is both cumbersome and overkill.) The closest I can come to making this happen is by adding a UIScribbleInteraction on a UITextView and returning false when scribbleInteraction(shouldBeginAt:) is called. This disables Scribble on the text view, and prevents writing from being converted into text, but the input widget still appears on screen and isn't very useful. Here is a sample project that demonstrates the problem: http://files.iconfactory.net/craig/bugs/Scribbler.zip Hopefully, I'm doing something wrong here. If not, I'm happy to submit this as a FB. -ch

I'm working on a macOS app that uses a JSContext and I want to debug it with the Safari Web Inspector. According to Session 402 at WWDC 2016 the following entitlement is required: <key>com.apple.webinspector.allow</key> <true/> This is easy enough to add, but it causes the app to crash at launch with a code signing issue. The console shows that taskgated-helper is reporting just before the crash: Unsatisfied entitlements: com.apple.webinspector.allow For anyone who finds this, here's what you need to know: https://webkit.org/blog/13936/enabling-the-inspection-of-web-content-in-apps/ Basically, there's now a inspectable property on both the WKWebView and JSContext. Unfortunately, there's no mention of the old entitlement in the WebKit blog post, so it's impossible for folks using the old technique to find. Hopefully this post will bridge this gap. It also might be something for @eskimo to add to his (always helpful) code signing documentation. -ch

I'm in the process of updating an app that uses complications that originally had a deployment target of watchOS 4.3. These complications used CLKComplicationSupportedFamilies defined in Info.plist. There are no CLKComplicationDescriptors in use. Updated complications that use a new CLKComplicationDescriptor.identifier display correctly in the complication picker, but the original complication that's using CLKDefaultComplicationIdentifier displays "--" or "---" depending on placement. This happens whether you are using a ComplicationController instance or WidgetKit. Using CLKDefaultComplicationIdentifier as the identifier when creating the CLKComplicationDescriptor doesn't work: the complication doesn't appear in the picker. My question is there a way to "upgrade" an older complication configured by the customer to a new complication identifier? I'm not using WidgetKit for this project so a widgetMigrator isn't an option. -ch