iPadOS 17.7.7

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.

My intent was iPadOS 26, not 28. I have posted another thread here: https://developer.apple.com/forums/thread/805719 To the administrators, please kindly delete or close this thread for me. I apologize for the confusion.

This isn't even fine-tuning, this is just trying to get the entire List to stop being redrawn when something minor happens, end even when nothing has changed! Accessibility DWC hasn't changed, but SwiftUI thinks it has, and so the List redraws every row. I swipe one row and tap the edit button, the List jumps back to the top. No reason at all for that. Nothing has changed, but SwiftUI decides @self, @identity changed so it redraws every row. How did anything change? I didn't change the .id() of the rows - they use the id of the Item which has not changed. When this @State private var showDeleteConfirmation: Bool = false changes on one row because the user swiped and tapped the delete button, the entire List is redrawn. Why? I fear I'm going to end up with hundreds of stupid little hacks to get things to work, and they'll just fail on the next point release of the OS. And, as I've said on multiple occasions over the past week, across three other posts on this subject, this did not happen until iOS/iPadOS

I've been seeing the same issue for a while now. I have both Xcode 26.0 and Xcode 26.1 beta 3. Running either causes the same issue as soon as I open an iOS/iPadOS 26.1 simulator. I only have a missing wallpaper on iPad simulators with iPadOS 26.1. iPhone simulators show the wallpaper. But either causes the CPU spike due to the ReportCrash process. I can have all of the iOS/iPadOS 26.0 simulators running that I want with no CPU spike. Launch a single iOS/iPadOS 26.1 simulator and in seconds my CPU spikes and stays there. Close that one simulator and everything goes back to normal. I filed FB20868503

Thanks for the confirmation. The best path forward here is for you to file a bug about this. DevForums focuses on Apple APIs and tools, and none of those are involved in this specific issue. In your bug, make it clear as to whether you’re the accessory developer or you’re using an accessory built by someone else. When you file your bug, make sure to install the Wi-Fi for iOS/iPadOS debug profile so that your sysdiagnose log captures extra debugging information. I also think it’d be helpful for you to include a packet trace. I think that an RVI packet trace will capture the necessary info, but if you have the ability to take a packet trace from the perspective of your accessory then include that as well. Oh, and as things are working on iPhone 15, include packet traces of that case as well, to act as a contrast. Once you’re done, please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

All of these are still an issue with iPadOS 26.1 RC

Still an issue with iPadOS 26.1 RC

iOS 26.0.1 iPadOS 26.0.1 XCode 26.0 (17A324) Worked fine with previous iOS versions.