SwiftUI List performance

On the workaround front, you’re using MKMapView via UIViewRepresentable. If you switch to the shiny new Map SwiftUI view, does that avoid the problem? Haha I knew you were going to say that. :) Probably, but we still support back to iOS 16 so that's not currently an option. And, since it's just annoying log entries... Another option is to filter these log entries out in Xcode: Thanks for that! I also found the right-click / hide option in the logs that allow the filtering by various categories which definitely helps a lot. As always, thanks so much for your help.

[quote='873874022, FT-cfoy, /thread/811791?answerId=873874022#873874022, /profile/FT-cfoy'] I wish I could ignore it [/quote] )-; [quote='873870022, FT-cfoy, /thread/811791?answerId=873870022#873870022, /profile/FT-cfoy'] I've submitted a bug report with this FB21768382 [/quote] Thanks. That’s definitely the right choice in this situation. Also, please add a sysdiagnose log to that bug, one taken on your device shortly after reproducing the issue. That helps with the triage. On the workaround front, you’re using MKMapView via UIViewRepresentable. If you switch to the shiny new Map SwiftUI view, does that avoid the problem? Another option is to filter these log entries out in Xcode: Locate the Filter box at the bottom of the Console debug area. Copy the string subsystem:com.apple.PerfPowerServices and paste it into the box. That’ll create a Subsystem filter. In the menu hanging off that filter, select “≠ is not”. For many other systems log hints and tips, see Your Friend the System Log. Share and Enjo

[quote='873863022, DTS Engineer, /thread/813853?answerId=873863022#873863022'] may I ask you to file a bug with that project? [/quote] Before you do that, I’d like to clarify what you mean by this: [quote='813853021, OC_s, /thread/813853, /profile/OC_s'] How do I determine the real values? [/quote] What specific information are you looking for here? And what do you plan to do with that information? This matters because Mac Catalyst is returning values that make sense in the iOS-ish environment that’s expected by such apps. It is possible to get ‘real’ values, but the best way to do that depends on your specific setup. For example, the systemName property is uninteresting in a Mac Catalyst app because the real system name is macOS. So you can do this [1]: let systemName: String #if targetEnvironment(macCatalyst) systemName = macOS #else systemName = device.systemName #endif However, that’s just one of these properties. The best path for the other properties varies based your the specific property and your ulti

@DTS Engineer Our iOS app receives filenames from a server (e.g., ~TestFile.irfd). We need to extract the filename without extension for display purposes. The original code used: func getFileName(fileNameWithExtension: String) -> String { // Pure string manipulation - correct for filename handling let fileName = URL(fileURLWithPath: fileNameWithExtension).lastPathComponent return fileName } This worked on iOS 18, but broke on iOS 26 when customers started using filenames beginning with ~. We don't actually need a URL or path. We're doing pure string manipulation on a filename to extract components. We used URL(fileURLWithPath:) as a convenient way to get lastPathComponent, but that's semantically wrong for our use case. This will be right suitable approach for our case, let fileName = (fileNameWithExtension as NSString).lastPathComponent This is the right approach because: We have a filename, not a path We need string manipulation, not path resolution NSString.lastPathComponent doesn't perform pat

Thanks Quinn. This looks to possibly be an internal Apple bug with MKMapView. I can recreate the issue with the following code: import MapKit import SwiftUI struct MyMapkitView: UIViewRepresentable { typealias UIViewType = MKMapView func makeUIView(context: Context) -> MKMapView { return MKMapView() } func updateUIView(_ uiView: MKMapView, context: Context) {} } struct ContentView: View { var body: some View { VStack { MyMapkitView() } .padding() } } Which immediately gives the errors below that match what I'm seeing in my app. I wish I could ignore it, but it quite literally is happening 2-3 times a second so the log is completely buried with these messages. This only started happening when I upgraded Xcode to 26.

Thanks for that!! Very useful, I would review each string as the NSExtensionPrincipalClass does not look correct to me but is set by Xcode, but it's been a while since I create an extension, I should try today to create a new one to see how it works. I'll invite extension experts to look at your configuration. As Xcode sets your string must be correct, just make sure the method get called? $(PRODUCT_MODULE_NAME).handler.... https://developer.apple.com/documentation/BundleResources/Information-Property-List/NSExtension/NSExtensionPrincipalClass NSExtensionPointIdentifier com.apple.passkit.issuer-provisioning NSExtensionPrincipalClass $(PRODUCT_MODULE_NAME).IssuerExtensionHandler https://developer.apple.com/documentation/bundleresources/managing-your-app-s-information-property-list#Manually-supply-an-information-property-list-file https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/AppExtensionKeys.html So it I follow the docume