Visual Studio Maui IOS

Hi, thanks for mentioning the .exp file approach. This works well with the scenario I explained above (dynamic framework depending on static libs). However, when I tried this with a slightly different project configuration, I faced linker errors. I replaced the static libs with dynamic libs. So, now I have a dynamic framework with 3 target dependencies, each being a dynamic library. This project builds and runs fine when tested on the iOS simulator. But according to our other discussion here, when I test this on a real iPhone, it builds fine but fails at runtime with a linker error: 0_abort_with_payload and Xcode shows the following assembly instructions specifying the error Thread 1: signal SIGABRT - dyld`: 0x1aa0a15f8 <+0>: mov x16, #0x209 0x1aa0a15fc <+4>: svc #0x80 -> 0x1aa0a1600 <+8>: b.lo 0x1aa0a1620 ; <+40> 0x1aa0a1604 <+12>: pacibsp 0x1aa0a1608 <+16>: stp x29, x30, [sp, #-0x10]! 0x1aa0a160c <+20>: mov x29, sp 0x1aa0a1610 <+24>: bl 0x1aa040064

I think this is an issue with my app. If I set .delegate before setting .preferredDisplayMode and .preferredSplitBehavior then topColumnForCollapsingToProposedTopColumn gets called. My app had it the other way around so it was properly just luck that I didn't see an issue on older iOS versions.

Hi @robevans, I'm unable to reproduce the issue, as reported, in my own Xcode project. Because the provided example above will not build successfully due to missing types, I replaced your implementation with the following: import SwiftUI struct ContentView: View { @State private var selection = 0 var body: some View { TabView(selection: $selection) { Tab(Home, systemImage: circle.hexagonpath.fill, value: 0) { Color.red } } .tabViewBottomAccessory { Menu(Post Review) { Button { print(Other submitted.) } label: { Label(Submit Other, systemImage: building.2.fill) } Button { print(Bed submitted.) } label: { Label(Submit Bed, systemImage: bed.double.fill) } } } } } #Preview { ContentView() } However, if the above still does not resolve your issue, please consider adding the following view modifier to your button's content: Button { print(Button tapped!) } label: { SomeCustomView() } .contentShape(.rect) To learn more, read the following documentation: contentshape(_:eofill:) https://developer.apple.com/documentati

Hi @377632523@qq.com, I'm unable to reproduce the issue, as reported, in my own Xcode project. Because the provided example above will not build successfully due to missing types, I replaced your implementation with the following: import SwiftUI struct PhotosMainView: View { @State private var searchText: String = var body: some View { TabView { Tab(Library, systemImage: photo.on.rectangle) { NavigationStack { scrollView(colors: [.red, .orange, .yellow]) .navigationTitle(Library) } } Tab(Albums, systemImage: square.grid.2x2) { NavigationStack { scrollView(colors: [.yellow, .green, .teal]) .navigationTitle(Albums) } } Tab(Search, systemImage: magnifyingglass, role: .search) { NavigationStack { scrollView(colors: [.blue, .purple, .pink]) .navigationTitle(Search) .searchable(text: $searchText) } } } .tabBarMinimizeBehavior(.onScrollUp) .tabViewStyle(.sidebarAdaptable) .tabViewBottomAccessory { TimelineAccessoryView() } } // Trivial helper view to visualize scrolling. @ViewBuilder func scrollView(colors

I am testing on iOS 26. I have reproduced the bug and collected a sysdiagnose (thank you for your guidance). I have uploaded the sysdiagnose to my bug report, so if you could get my ticket back in the loop I'd appreciate it. Thanks!

Could you try reproducing the issue using this sample project: Customizing your app’s navigation bar and verify on iOS 26.1 Beta 3. Please reply back with your findings.

First off, I need to repeat what I asked here: Why? What are you trying to do? More specifically, why does your app need to be awake in the background? The system has multiple APIs for managing background work and it's entirely possible there IS an API that would meet your needs. Notably, we just introduced BGContinuedProcessingTask which will allow your app to stay awake in the background for an extended period of time (several minutes). If you're trying to complete work on the user's behalf, that API is the solution. In my tests 2 weeks ago, I (might be by my mistake) saw a correspondence between external-accessoryand the facts of callbacks from IOServiceAddMatchingNotification. Were you testing using Xcode? The issue here is that in order to debug your app, Xcode disables normal app suspension, which ends up keeping your app awake in the background forever. That then makes all sorts of things work with normally wouldn't. Having said that, the word correlation did raise a possibility I hadn't really conside