“Visual Studio Maui IOS”

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.

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.

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 existing iOS 12 users (e

still hasn't even been fixed in iOS 26.4 which is absolutely insane to me. Only workaround I've implemented was to force the source grid to rebuild after the detail view actually disappears and it fixes the swipe to dismiss getting stuck behavior but then causes the source to flash once it's settled.

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.

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.

We have a VoIP app with more call features. Sometimes, we received some feedback about call ended. After checking the log file, it shows there are user actions (e.g., from func provider(_ provider: CXProvider, perform action: CXEndCallAction)), If you want to look into this in depth, then the best approach is to get the user to capture a sysdiagnose and use the console log to see if you can determine what's going on. A few notes on that: The log doesn't need to be captured immediately after the issue. Even logs captured a few hours later are often quite useful. It IS critical that the device NOT have been rebooted since the problem occurred. If it has been rebooted, so much log context is lost that the log is generally useless. You can find instructions for triggering and collecting a sysdiagnose here. Having said that, one comment on this: But the user said no user actions. So we doubt if there is a system-level event or error that will end this call. Then the details of the end call reason would be very hel

I'm seeing exactly the same crash, same source code, same Xcode version two weeks ago did not have the issue. I've pushed a new build 2 days ago and users with iOS 12 are getting a crash on launch.