iPadOS 17.7.7

This is still an issue with iOS/iPadOS 26.2 beta 1. I'm getting comments from users of my app due to this bug that has been around since iOS/iPadOS 26.0 beta 1. Apple, please fix all of the issues related to search scope buttons.

@Martin81 I get the ReportCrash issue running an iOS 26.1 simulator such as an iPhone 17 Pro. And it is showing a wallpaper. The only sims that don't show a wallpaper in my case are iPad simulators running iPadOS 26.1. But here's what's really weird. I ran the Photos app in the iPhone 17 Pro simulator (which is showing the default wallpaper and causing high CPU). While viewing one of the stock simulator photos I chose Use as Wallpaper. I went through the steps. Even though the chosen image is now appearing as a black wallpaper, it did fix the high CPU problem for that simulator. Such a strange set of bugs.

We were able to confirm that this setup works on macOS, but does not work on iOS/iPadOS. Our goal is PKCS#11-style certificate signing using USB hardware tokens. On macOS, the token is recognized through TKTokenWatcher, and we are able to obtain a usable SecKey via CryptoTokenKit and perform signing successfully. However, on iOS, although the token is detected as a smart card, we are not able to access the private key for signing: TKTokenWatcher does not report the token SecKeyCreateWithData does not produce a usable signing SecKey The smart card appears in TKSmartCardToken slots, but when sending APDU commands, the token returns 6985 / CACC errors (security status not satisfied) If there is an officially supported iOS-level workflow for accessing and using a private key on a USB smart card for signing, we would appreciate documentation or guidance.

There's no macOS-like menu bar when the user chooses Full Screen Apps. I didn't know this and some of my app's functionality can only be accessed through the main menu bar. So I was thinking I could show some alternative way to access those features when in that mode. iPadOS has supported the ability to open a new scheme through drag and drop using UIDragItem and NSItemProvider and dragging it to the edge of the screen. When a user chooses Full Screen Apps, this no longer works for opening a new scene. I'd like to disable the drag and drop if it's not going to actually do anything. Those are two main things I can think of so far that depend on the user's choice of multitasking mode.

Are all of you posting bug reports with Feedback Assistant? Make sure you do. Be sure your report includes the steps needed to reproduce the issue and include the sysdiagnose attachment. What version of macOS is everyone seeing this issue with? In my case I'm running macOS 26.0.1. I don't know if the version of macOS matters or not. I see the issue with both Xcode 26 and Xcode 26.1. It's just requires starting an iOS/iPadOS 26.1 simulator. I have no issue when running an iOS/iPadOS 26.0 simulator.

Please verify and report back if you're able to reproduce the issue using Bringing Photos picker to your SwiftUI app sample on iOS, iPadOS 26.1 RC & macOS. Thanks

Thanks for the clarifications. Just FYI, in networking, raw socket usually refers to raw IP sockets, hence my confusion. So, lemme summarise the issue: You have an iOS app. It talks to a Wi-Fi based accessory over TCP. With iPhone 16, this all works as expected. With iPhone 17, things go wrong, such that your TCP socket disconnects after 20 seconds. After that, your app is unable to reconnect. And the only way to resolve the issue is to restart the Wi-Fi subsystem on your accessory. Is that right? If so, this sounds eminently bugworthy. While there are lots of ways that local networking can go wrong, the fact that this fails when the only variable you change is moving from iPhone 16 to 17 suggests that it’s caused by a Wi-Fi level issue on iPhone 17. DevForums focuses on Apple APIs and tools, and isn’t really set up to help with Wi-Fi level issues. Given your description of the problem, I think it makes sense for you to file a bug so that our Wi-Fi engineering team can investigate. In your bug, make it clear

[quote='864098022, Pasjonsfrukt, /thread/803580?answerId=864098022#864098022, /profile/Pasjonsfrukt'] Sorry for the late response! [/quote] No worries. I have plenty of other things to do (-: [quote='864098022, Pasjonsfrukt, /thread/803580?answerId=864098022#864098022, /profile/Pasjonsfrukt'] We have not seen the issue when we connect to the AP through Settings > Wi-Fi. [/quote] OK. The reason I asked is that here on the Apple Developer Forums our primary focus is on APIs. If you were able to reproduce the problem in Settings then that’d eliminate any possibility that your iOS code is incorrect. Without being able to reproduce it in Settings, it’s possible that this is a bug in your app (you occasionally pass in the wrong Wi-Fi details) or in the Network Extension layer that you’re calling (as opposed to the core Wi-FI layer that does all the heavy lifting here). However, the actual error you’re seeing here, failed to association error 1, is a strong indication of an issue in the core Wi-Fi code. If I’m re

NWConnection isn’t really set up to deal with UDP broadcasts. My advice, sadly, is that you use BSD Sockets for this. BSD Sockets is a much harder API to use correctly. I have lots of hints and tips in Broadcasts and Multicasts, Hints and Tips. The most critical point is that, when working with broadcasts and multicasts, you should target a specific interface. If you try to send a broadcast without specifying the interface, it’s hard to predict which interface it’ll be sent over. [quote='805719021, Tetsuya_0, /thread/805719, /profile/Tetsuya_0'] I suspect this may be a regression bug in the iPadOS 26 security sandbox [/quote] Well, it’s certainly a regression, but I doubt it’s in the sandbox. Usually the sandbox causes things to fail with EPERM. You are feel to file a bug about NWConnection, but I’m concerned that it’ll struggle to get traction given the state of broadcast support in Network framework. If you need a fix for this in the short-to-medium term, I recommend that you switch to BSD Sockets.