Visual Studio Maui IOS

Thank you for sharing this article — it directly touches on the issue I’m currently facing. I have actually tried both approaches mentioned: 1.Using .distanceWalkingRunning or .distanceCycling samples to accumulate distance and determine per-kilometer (or per-mile) ranges. This is a reasonable suggestion, but it comes with a major drawback. For example, processing a 100 km cycling workout produces a very large number of samples, and the overhead becomes even greater when handling multiple workouts in bulk. In other words, this method is valid but not efficient. 2.As edorphy pointed out, Apple Watch’s Activity app does record per-kilometer and per-mile split points as HKWorkoutEvents. In my own testing, these event markers are actually more accurate than the splits derived from accumulating .distanceWalkingRunning or .distanceCycling samples. This leads to a simple but important question: how can developers make effective use of the HKWorkoutEvents that Apple Watch already records and stores in HealthKit? In o

Same here, this is very frustrating. Not working either in iOS TF or Mac TF. Error: Unable to Accept Invite The Apple Account you're currently signed in with, d*****@gmail.com, doesn't match the one associated to this invitation. You can sign in to TestFlight with the original Apple Account, d*****@gmail.com, or request a new invitation from the developer.

Thanks Kevin! Moving performCountWork into the launchHandler (instead of before register) fixed it, simply because the call to set the totalUnitCount did not happen because currentBackgroundContinuedProcessingTask is nil at that time. Makes sense why it was indeterminate, it was never given a total! 😄 performCountWork still doesn't have to be called in the launchHandler, as long as I have the data to be able to set the total unit count when the task gets created at any time during the already in-flight operation, that approach works too. If I did that though, that brings up a question, what if the operation completes before the launchHandler is invoked (if I were to use the queue strategy)? A task would start for work that's already completed and thus wouldn't get progress updates and setTaskCompleted wouldn't be invoked. It seems much more straightforward to use the fail strategy and perform the work in the launchHandler (and if it the submit request fails perform the work without a BGContinuedProcessingTas

Indeed, I used test numbers that I called previously. Can you update the doc? Please file a bug asking the documentation to be updated and post the bug number back here. Having said that: I did not see this information anywhere. ...while the behavior above is new in iOS 26, there have ALWAYS been exceptions that would cause us to bypass a call directory entry. Notably, the user direct contact takes precedence over CXCallDirectory. This has always been the case but has never been formally documented as such. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Thanks for the feedback report. To add to that, Sliders have gotten an update in iOS 26. Controls like toggles, segmented pickers, and sliders now transform into liquid glass during interaction. Please review the WWDC session: Build a SwiftUI app with the new design to learn more about the new behaviors and design of Sliders.

I have double checked my models against the incoming JSON and it all matches up properly. I inserted the recommended code above and it indeed crashes on the modelContext.save but it never gets to the catch. It simply display a SIGABRT stating An abort signal terminated the process. Such crashes often happen because of an uncaught exception or unrecoverable error or calling the abort() function. Executing the exact same code works perfectly in iOS 18 without any changes. Calling the same endpoint and using the same JSON returned by that endpoint works without a hitch. It seems to me that if the code works in iOS 18 and fails in iOS 26, that seems to be indicative of a change in the framework that I cannot check, no?

Thank you for sharing your post. To assist you further, and find the correct person to help you, could you please provide additional information about your environment, including all the versions you are using? Additionally, please describe the steps you take to reproduce the issue. If you are attempting to deploy code to the simulator, please include any relevant code snippets. It is possible that the issue is related to the version of the simulator you are using. To download the iOS 26 Simulator, run: xcodebuild -downloadPlatform iOS -exportPath ~/Downloads -buildVersion 26 If the issue is part of CoreDevice, another engineer can review your answer with more expertise than I possess. Albert Pascual
  Worldwide Developer Relations.

In your code snippet you had: navigationControllerWithVC.navigationBar.isTranslucent = false We don't recommend using isTranslucent for this level of customization in UINavigationBar. For iOS 18 and below, use UINavigationBarAppearance for customization purposes and starting in iOS 26, reduce your use of custom backgrounds in navigation elements and controls. Prefer to remove custom effects and let the system determine the navigation bar background appearance. Please review Customizing your app’s navigation bar and TN3106: Customizing the appearance of UINavigationBar You also called: tableView.reloadData() We also don't recommend you calling reloadData. Ideally use a combination of UITableViewDiffableDataSource which handles automatically diffing sections & items for you, and generating the correct batch updates on the tableView or your own change detection for properties within existing items so you can call the reconfigure or reload APIs on the diffable snapshot as needed, to update c

Ah sorry for the lack of details, thanks for addressing this issue. Here's a swift code snippet to reproduce this issue: import MetalKit class MetalTestView: MTKView { var commandBuffer: MTL4CommandBuffer? var commandQueue: MTL4CommandQueue? } If you build with a real device selected, such as iPhone 14 with iOS 26 beta installed, the build succeeds, but if you build with iPhone 17 simulator with iOS 26, the build fails and complains that Cannot find type 'MTL4CommandBuffer/MTL4CommandQueue' in scope. Any way to get the simulator to recognize metal 4 types?

buildVersion 23A339 The buildVersion option takes the OS version of the platform you want to download. For example, to download the iOS 26 Simulator, run: xcodebuild -downloadPlatform iOS -exportPath ~/Downloads -buildVersion 26

In iOS 26.1 beta the problem seems to be resolved for me. Can anyone confirm if it has also been fixed in version 26.0.1? I’d prefer not to downgrade just to check. Thanks!

Dual booting (triple in my case - 14/15/26) is not a viable option for Xcode development and testing of an app because different versions of macOS support different versions of Xcode. While Xcode 26.0.1 currently runs on macOS 26 and macOS 15.6, it certainly can't be run on macOS 14 and I can easily see a time in the near future where some version of Xcode 26.x requires macOS 26. Dual/triple booting does sound like a way to at least be able to run Test Flight so I can at least do my own verification of functionality before pushing the test build to beta testers. In my specific case, my app is not a game. It's a productivity app. My primary testing concern is ensuring the UI works correctly under different versions of macOS (and iOS for that matter). Being able to do this with VMs would make things SO much easier. One copy of Xcode on the host. One copy of the source code on the host. One build on the host. Then run that one binary (stored on the host) in the different VMs. It would be just like testi