Visual Studio Maui IOS

Thanks for the reply. Tried... xcodebuild -downloadPlatform iOS -exportPath ~/Downloads -buildVersion 26 Finding content... iOS 26 is not available for download. Then... I try remove the version... xcodebuild -downloadPlatform iOS -exportPath ~/Downloads Finding content... Automatically resolved architecture variant for platform iOS as 'universal'. 2025-10-10 06:40:33.916 xcodebuild[13587:476834] DVTDownloadable: Download Failed. Downloadable: { architectures = ( arm64, x86_64 ); authentication = none; category = simulator; contentType = cryptexDiskImage; dictionaryVersion = 2; downloadMethod = mobileAsset; fileSize = 10066611438; identifier = com.apple.dmg.iPhoneSimulatorSDK26_0; isInternalContent = 0; isUserInitiated = 1; name = iOS 26.0 Universal Simulator (23A343); patchableFrom = ( ); platform = com.apple.platform.iphoneos; simulatorVersion = { buildUpdate = 23A343; version = 26.0; }; version = 26.0.0.0; }. Download failed. Thanks.

So, first off, there are two critical details I need to clarify: Note in MAC OS everything (same DExt and UserClient-code) works fine in the background and in the foreground. macOS doesn't implement any of the app suspension semantics iPadOS does, which means you can't really compare the behavior of the two systems. That leads to here: 1 variation A) UserClientApp has attribute [Background modes][Enable external communications]. The external-accessory background mode is totally unrelated to DriverKit and isn't actually doing anything in your app. It allows apps using the ExternalAccessory framework to communicate with their accessory in the background, but that framework (iOS 3.0) and the background mode (iOS 4.0) are MUCH older than DriverKit. Making this as explicit as possible: B) A way to pursue Apple-store to accept (without MFI) an UserClientApp with [Enable external communication]. ...adding external-accessory is not changing ANYTHING about how your app wakes/sleep in the background.

Thanks for the post, this is very interesting, how you tried by providing the path to download the file? xcodebuild -downloadPlatform iOS -exportPath ~/Downloads -buildVersion 26 Let me know what error you get. Albert Pascual
  Worldwide Developer Relations.

Thank you for your post. I have a few questions. Is that your application, Zeon Charging? You also mentioned that the bug appears on the iPhone 14 with iOS 16.0.1 but does not occur on the iPhone 16 with the same version of iOS. Have you tested the latest beta version of iOS? The crucial aspect is that the same version of iOS is experiencing the issue, but the iPhone model is different. Is that correct? Do you get the same results with just the relevant code in a small test project? If so, please share a link to your test project. That'll help us better understand what's going on. If you're not familiar with preparing a test project, take a look at Creating a test project. Albert Pascual
  Worldwide Developer Relations.

Here's an sample code that can produce the problem. It happens on rotate in simulator, only in iOS 26.* Expectation: should have the same lead spacing regardless of the rotation of the device. struct ContentView: View { @State private var showingSharePopover = false var body: some View { NavigationStack { VStack { Button { showingSharePopover = true } label: { Label(Show Share Options, systemImage: square.and.arrow.up) .font(.title2) .padding(.vertical, 10) .padding(.horizontal, 20) } .buttonStyle(.borderedProminent) .tint(.indigo) .controlSize(.large) .shadow(radius: 5) .sheet(isPresented: $showingSharePopover, content: { }) } .navigationBarBackButtonHidden(false) .toolbar { ToolbarItem(placement: .topBarLeading) { Button { } label: { HStack { Image(systemName: square.and.arrow.left) Text(Done) } } } } .padding() } } }

As explained in iOS Background Execution Limits ==> When the user ‘force quits’ an app by swiping up in the multitasking UI, iOS interprets that to mean that the user doesn’t want the app running at all. So: If the app is running, iOS terminates it. iOS also sets a flag that prevents the app from being launched in the background. That flag gets cleared when the user next launches the app manually. This gesture is a clear statement of user intent; there’s no documented way for your app to override the user’s choice. So, the best approach to this is first train your users so they understand that force quit will stop data collection. And if they still do it, then it is their choice for you to respect. So, how you solve this depends on your use case and the user experience you are trying to achieve. You can send push notifications if your server suspects that this has happened (no data updated for a while, for example) to encourage the users to tap on it, which will relaunch

Like a fellow developer mentioned in your other thread, for your GPS device to work seamlessly with iOS and CoreLocation, it would have to be an approved MFi (Made For I(...)) device. You can more information about joining the MFi program here: https://mfi.apple.com