“testflight the requested app is not avaliable”

The same situation with our app, crashes on iOS 12 on startup if the app was built and processed by TestFlight after March 25. More than 400 active users of iOS 12 won't get the update if the issue is not resolved :(

Bluetooth scanning in the background on watchOS is not only throttled, but works in a whole different manner than on iOS, and has its own additional limitations. You might want to take a look at the sample Interacting with Bluetooth peripherals during background app refresh and also refer to the WWDC Session Get timely alerts from Bluetooth devices on watchOS to understand who BLE background scanning works on watchOS.

I am still experiencing this as of today. No way to store the certificates -> No valid certificates found for any of the recipients -> unencrypted sadness.

Same problem here, seems to be some active problem at App Store Connect side.

That makes sense and is how I interpreted it. For now, I had to disable it though so users do not run into issues. Or better set: I do not get bombarded with support questions 😊 Fair enough! Feedback number: FB22380104 Perfect, thank you. FYI, it's likely that you'll be notified that this bug is a duplicate in the next few days. Many developers interpret this as meaning that their bug was unnecessary and is being ignored“; however, that's a misunderstanding of what's going on, particularly when someone at Apple (like me) asks for a bug. As you might imagine, the combination of our own testing and the volume of users means that it's pretty likely that SOMEONE has filed a bug before you. So, yes, that means that many bugs are effectively telling us about an issue we already knew about. However, what gets missed there is that the reason to file a bug isn't just to tell us about the problem“; it's also about documenting impact so we can properly prioritize work and scheduling. __ Kevin

The same for Organic Maps: internal CI TestFlight build on March 25 works on iOS 12 device, the same binary with a few string resource changes, built on March 26 does not work. Built with the frozen version of Xcode 26.2. That implies some kind of Apple involvement when builds are uploaded.

Because we are forced through MTU 1500, we are incurring significant performance penalties: Have you filed a bug on this and, if so, what's the bug number? Is there an undocumented boot-arg or network sysctl parameter that permits overriding the AppleUserECM 1500 MTU hard-limit for 2.5G USB adapters on Apple Silicon? No, not that I'm aware of. Are there any roadmap plans from the DriverKit/Networking team to re-enable standard Jumbo Frame negotiation for RTL8156 hardware using the generic ECM driver? In general, Apple's future plans aren't really something I can discuss. Does Apple grant NetworkingDriverKit Entitlements to independent developers specifically for the purpose of writing custom hardware overrides to patch missing MTU features in the default ECM stack? Approval here would primarily depend on the hardware you’re asking to create a DEXT for and, in particular, how broad the request configuration is[1]. However, we do approve developers for DriverKit entitlements who are not

accessibilityPreviousTextNavigationElement and accessibilityNextTextNavigationElement are not meant to represent previous/next line inside a single UITextView; they should point to another accessibility element, not a line number or string. In your case, UIAccessibilityReadingContent supports line-by-line touch exploration, but left/right swipe still moves between accessibility elements, not internal lines of one text view. That’s why touch works but swipe does not. The correct approach is to keep the UITextView for display and expose each visible line as its own UIAccessibilityElement, with accessibilityLabel set to the line text and accessibilityFrameInContainerSpace set to that line’s frame. Once the lines are separate accessibility elements and returned in order, VoiceOver will naturally use right swipe for the next line and left swipe for the previous line. You can optionally link neighboring lines with accessibilityNextTextNavigationElement and accessibilityPreviousTe

Thanks for the clarification. However, this is quite concerning from a developer and user-impact perspective. This app version was: • successfully built and uploaded with Xcode 16.4 • accepted in App Review • distributed through the App Store Despite having a deployment target of iOS 12, the build is now crashing on launch for all iOS 12 users, without any prior warning during submission or review. As a result, a previously working user base on iOS 12 has effectively lost access to the app overnight after updating, which is a significant regression in functionality. If iOS 15 is now a strict requirement for App Store distribution, it would be much safer for developers if: • the upload was rejected at submission time, or • a clear warning was shown before release rather than allowing distribution of a build that cannot run on supported devices declared in the app’s deployment target. Is there any recommended way to: Restore functionality for existi

Distribution through the App Store requires a minimum deployment target of iOS 15. For future reference, you can find this information listed on the Xcode Support webpage.