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 ]]; // *** 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) // *** 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.)

Hi, I'm interested in creating a font with alternate glyphs that are accessed via Unicode variation selectors, but I'm getting the impression that macOS does not really support these, generally. For example, I'm unable to enter the variation selectors (other than U+FE0F) into a document in Pages or TextEdit using Unicode Hex Input. Is my hunch correct? I'm interested in using the standardized variations listed here: http://unicode.org/Public/UNIDATA/StandardizedVariants.txt Specifically, slashed zero: 0030 FE00; short diagonal stroke form; # DIGIT ZERO Thanks for any insight you may be able to provide.