I'm trying to understand how to best position my iOS apps in the event that—for whatever reason—I'm unable to release another version after submitting a version built with Xcode 26 that uses UIDesignRequiresCompatibility = YES. For the sake of this discussion, assume that my apps require updates for proper UI presentation with the Liquid Glass UI, and that I'm submitting an initial version with UIDesignRequiresCompatibility = YES. I need to make an initial update for iOS 26 right away, because running the app linked with the iOS 18.x SDK (as currently shipping on the App Store) on iOS 26 introduces UI usability problems. Now, I have actually revised the UI for Liquid Glass and this requires slightly different behaviors for the legacy UI path (iOS 18.6 or iOS 26.0 with UIDesignRequiresCompatibility = YES) versus Liquid Glass UI path. My Liquid Glass adoption UI may be "good enough," and it's certainly better than the results obtained when rebuilding with Xcode 26 and running without any updates at all (which produces a very poor, if not unusable, user experience), but I am not satisfied with these updates at present and I hope to make additional improvements before enabling the revised UI for users. However, in the event that I cannot make another update for whatever reason, I need to ensure that users will never be exposed to the UI behavior that results from running with UIDesignRequiresCompatibility = NO with the code supporting Liquid Glass adoption disabled. As long as Apple will guarantee going forward that an app built with Xcode/iOS 26.0 SDK including UIDesignRequiresCompatibility = YES in its plist will always use the old rendering mode in any future OS, then perhaps everything is fine. However, if that's not the case, then I think I need some way to detect the enablement state of the new Liquid Glass UI at runtime (which goes beyond a simple @available check, e.g. iOS 26+ with "compatibility mode" disabled) so that I can provision to have my code supporting Liquid Glass adoption be automatically enabled in the event that my app never receives another update and a future OS ignores the UIDesignRequiresCompatibility key in its plist. I'm assuming that testing the value of the key in the plist at runtime would be insufficient, since it would still be present but ignored. This sort of continuity planning seems like something that many developers would be concerned about. What is Apple's guidance on this? So far I haven't found any clear discussion of this concern. Note: My app is UIKit-based, mostly Objective-C with a bit of Swift only for TipKit.

(I made a mistake and saved too soon. Nothing to see here. Sorry!)

I have installed the macOS 26 WWDC beta on a secondary volume, and set it up with two user accounts (both administrators). However, the options for switching users without fully logging out are nowhere to be found. The topic is still included in macOS Help and is shown when searching for “fast” in System Settings, however, the option is hidden/missing in the pref pane when selected. Filed FB18155517 (macOS 26 beta: No Fast User Switching?)

Prior to iOS 26, it was possible to design an inputAccessoryView(Controller) that would integrate seamlessly with the system keyboard, by which I mean appearing as a natural extension of the system keyboard. For example, using CYRKeyboardButton https://github.com/tmcintos/CYRKeyboardButton. To date, I have successfully used this to provide an enhanced numeric key row within my apps, which is a distinguishing feature of these apps. It took a lot of engineering and testing effort to perfect this design. However, with iOS 26 the design is completely broken due to the system keyboard UI change, which makes it impossible to display an inputAccessoryView seamlessly along the top of the system keyboard (see attached screenshots). In my opinion, it is just plain reckless for Apple to make these kinds of trivial UI changes, which break existing app designs without adding any significant value to the user experience. iOS ≤ 18.x: iOS 26 beta:

I installed the WWDC beta on UTM and I'm unable to find the option to disable the so-called "Natural Scrolling". Has this been removed and if so, can we get it put back? I use a mouse with scroll wheel and everything is going opposite the direction I expect in the macOS 26 VM.

Support for menus in Storyboards is yanked without ever being deprecated (to my knowledge)? Really? WTF? This is a major step backwards, Apple. So nice to have to spend a month rewriting my app after WWDC each year. Re-creating a complex menu hierarchy in code is exactly what I wanted to do. Ugh.

Anyone else seeing this? I reported the regression back in March 2025 and have no reply from Apple. My apps are Obj-C, in case it matters. DESCRIPTION After updating to iOS 18.3.x, | noticed a regression in the title menu behavior of my UlDocumentViewController-based shipping apps on the App Store [1]: Instead of displaying the document icon supplied by the app, the share menu item displays a placeholder icon instead, and iconservicesagent error messages are emitted in the log stream [2]. STEPS TO REPRODUCE Install one of the apps from note [1] below. Launch the app, tap the document/title menu at top center of the screen, and observe first menu item. RESULTS Expected: App-provided document icon displayed to left of first menu item ("W-1" or "W68" document icon). Actual: Placeholder icon displayed. REGRESSION Occurs: iOS 18.3 (iPad) iOS 18.3.1 (iPhone) iOS 18.3.2 (iPhone) Does Not Occur: iOS 18.2,18.3 Simulator iOS 18.0-18.2? [| no longer have a device with < 18.3 to confirm regression point] NOTES: [1] WOZNIAC-1 <https://apps.apple.com/us/ app/wozniac-1/id6474085354> and WOZNIAC-68 <https://apps.apple.com/us/app/ wozniac-68/id6736677781>. [2] When the problem occurs, the following log messages are omitted: Error returned from iconservicesagent image request: <|STagIcon: 0x30299c040> Tag: alvm, Class: public.filename-extension, Base type: public.item - <|SImageDescriptor: Ox300dd5860> - (37.00, 48.00)@3x v:40000 1:5 a: 0:0:0:0 t:() b:0 s:2 ps:0 digest: 0D3223D0-9AЕ3-3B19-A081-ACACE55691B7 error: Error Domain=NSOSStatusErrorDomain Code=-609 "Client is disallowed from making such an icon request" UserInfo={NSLocalizedDescription=Client is disallowed from making such an icon request}

At a WWDC24 consultation with the keyboards and input team, I was referred to the UITextInputContext class for detecting hardware keyboard status. However, it's not obvious how this class is intended to be used. I would like to receive notifications when the UITextInputContext state changes, however, I see no way to accomplish this. I've tried using KVO to observe state changes of the current property of UITextInputContext.class or the hardwareKeyboardInputExpected property of UITextInputContext.current, but receive no change notifications when a USB hardware keyboard is attached/detached, and hit an assertion when trying to stop observing, indicating that the observer is not registered. So I don't think KVO works. I am interested in knowing whether a hardware keyboard is attached when the virtual onscreen keyboard is hidden or shown (which occurs when the hardware keyboard is attached/detached), so that I may adjust the state of my inputAccessoryView accordingly (it should be hidden when a hardware keyboard is attached). I've had some success checking the state of UITextInputContext.current.hardwareKeyboardInputExpected during keyboard willHide/willShow notifications (or in a block executed via dispatch_async()), however, it seems that the property value does not change until the first key press after attaching a hardware keyboard, or after the first virtual onscreen key press after detaching a hardware keyboard. The latter is problematic because there are no more keyboard hide/show notifications in which to perform the needed update to my inputAccessoryView UI after the UITextInputContext state change occurs following hardware keyboard disconnection. Perhaps it's meant that I should monitor key press events and check the status there instead?

macOS 15 (beta) has borked my desktop, changing a longstanding Dock behavior (for the worse); Apple says it’s expected behavior. :( I wonder if anyone else is affected by this change. I have my displays positioned as shown in the attached Screenshot, with a 4K BENQ Thunderbolt Display positioned above the internal display of an M2 MacBook Air. Prior to macOS 15, I was able to place the dock at the bottom of the upper display using the technique described here https://apple.stackexchange.com/a/208750 This allows taking advantage of the much greater real estate on the external display. As of macOS 15 (WWDC developer beta), this no longer works, and I can find no way to move the dock to the upper external display, and my dock remains squeezed into the tiny space available on my internal display (see attached photo).

I'm wondering how I can remove the new Writing Tools item from the context menu of a custom view, e.g. using removeMenuForIdentifier: in -buildMenuWithBuilder:.

In the WWDC24 session Evolve your document launch experience, it is mentioned that apps linked against the iOS 17 SDK would not get the new document launch experience. However, I found that the new document browser is active in my iOS 17 app when installed from the App Store on iOS 18, without rebuilding it. This (along with other iOS 18 UIKit behavioral regressions) renders the app unusable when running under iOS 18. To be clear, my app uses a UIDocumentViewController as the root view controller of a UINavigationController and is implemented primarily in Obj-C. I don't want to show the new document browser to users at app launch time. The current behavior of my app is that it always launches to either the current document or a new document and then allows the user to open a new document using the document picker if desired (this was accomplished by invoking the action associated with the Documents button on iOS 17; see related feedback FB13418866: ER: UIDocumentViewController should provide API to allow customization of Documents button behavior). The new UIDocumentViewController behavior is problematic because it has replaced the Documents button with a backAction that moves the user into the new document browser with no way to back out, aside from picking a document or creating a new document. Previously, the user could choose Cancel to exit the document picker and get back to the currently-open document without choosing a new one. While the new UIDocumentViewController behavior looks nice for apps like Swift Playgrounds, it is problematic for apps that want to take advantage of the UIDocument infrastructure without forcing the user to deal with a more complicated browser-centric app UI. I would expect there to be some way to maintain the previous behavior as it existed on iOS 17, but I don't see any way to do this. Suggestions welcome. Thanks!

In testing my app with the WWDC24 iOS 18 beta, I have noticed that most of the menu items in the navigation bar and title menu are either missing, disabled, or nonfunctional. The structure of my app's UI is a UIDocumentController subclass as the root view controller of a UINavigationController. In debugging the problem with title menu items, I noticed that the responder chain from the UICommand.sender now starts at the UINavigationBar and goes up from there, without passing through the UIDocumentViewController itself. Now, only the actions I've defined in the AppDelegate are accessible. I'm not exactly sure how this was organized on iOS 17, but the responder chain did include the UIDocumentViewController, where I have implemented most of the menu item actions. This seems like a UIKit bug, but I am investigating possible workarounds in case Apple does not fix it. Suggestions welcome.

The same problem encountered with iOS 17 beta 1 and beta 2 is back: Unable to create a secure connection to the server ("bad certificate format" -9,808).

I have a custom document-based iOS app that also runs on macOS. After implementing -activityItemsConfiguration to enable sharing from the context menu, I found that the app crashes on macOS when selecting Share… from the context menu and then selecting Save (i.e. Save to Files under iOS). This problem does not occur on iOS, which behaves correctly. - (id<UIActivityItemsConfigurationReading>)activityItemsConfiguration { NSItemProvider * provider = [[NSItemProvider alloc] initWithContentsOfURL:self.document.presentedItemURL]; UIActivityItemsConfiguration * configuration = [UIActivityItemsConfiguration activityItemsConfigurationWithItemProviders:@[ provider ]]; // XXX crashes with com.apple.share.System.SaveToFiles return configuration; } Additionally, I found that to even reach this crash, the workaround implemented in the NSItemProvider (FBxxx) category of the sample project is needed. Without this, the app will crash much earlier, due to SHKItemIsPDF() erroneously invoking -pathExtension on an NSItemProvider. This appears to be a second bug in Apple’s private ShareKit framework. #import <UniformTypeIdentifiers/UniformTypeIdentifiers.h> @implementation NSItemProvider (FBxxx) // XXX SHKItemIsPDF() invokes -pathExtension on an NSItemProvider (when running under macOS, anyway) -> crash - (NSString *)pathExtension { return self.registeredContentTypes.firstObject.preferredFilenameExtension; } @end Again, this all works fine on iOS (17.5) but crashes when the exact same app build is running on macOS (14.5). I believe these bugs are Apple's. Any idea how to avoid the crash? Is there a way to disable the "Save to Files" option in the sharing popup? I filed FB13819800 with a sample project that demonstrates the crash on macOS. I was going to file a TSI to get this resolved, but I see that DTS is not responding to tech support incidents until after WWDC.

Though I cannot find any documentation, it seems that UIPasteboard cannot be used from a Quick Look Preview app extension. I have such an extension, which contains a view that supports copying text as follows: - (IBAction)copy:(nullable id)sender { UIPasteboard * pboard = UIPasteboard.generalPasteboard; pboard.string = _rep.text; } This is invoked from a context menu (edit menu) item. This works fine In the simulator, but on device the pasteboard remains empty and errors like the following are emitted: -[PBServerConnection pasteboardWithName:createIfNeeded:authenticationBlock:dataOwnerBlock:error:] failed with error: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.pasteboard.pasted was invalidated: failed at lookup with error 159 - Sandbox restriction." UserInfo={NSDebugDescription=The connection to service named com.apple.pasteboard.pasted was invalidated: failed at lookup with error 159 - Sandbox restriction.} It's unclear to me why such functionality would be problematic and necessary to block. It would be nice if this were documented clearly, as I wasted a lot of time trying to figure out why this was not working. (And no, I have not filed a feedback report or TSI yet, as I'm presently very short on time, and I don't have a sample project prepared to demonstrate the issue.)