I don’t have access to another computer. Xcode downloads and installs the aar file. There must be a way to trick Xcode into thinking it downloaded the file itself and then completing the installation. I would think it’s just a matter of putting the aar file in the right directory.

Thank you. Setting preferredPlacement to fixed was the missing piece. I already had allowsHiding set to false and I’m not using any tab groups. The Edit button no longer appears in the sidebar. But I have discovered an iOS 26 (and iOS 18) bug in the process. I need to file a bug report but here’s the issue. I present the tab bar controller as a modal view controller on an iPad. If I resize the app window from full screen to a size that is horizontally compact while the tab bar controller is in view, the tab bar controller of course changes from showing a sidebar to showing an old style tab bar on the bottom with a More tab. Selecting the More tab now shows an Edit button. But only in this case. If the tab bar controller is presented after the app window is made horizontally compact, then the More tab does not show the Edit button.

Xcode 26 adds a new option (I think it’s new, I don’t have Xcode 16 anymore to check) that lets you indicate that a tab is pinned automatically which is exactly what the OP is looking for. But sadly Xcode 26 has a rotten regression that was fixed in an early beta and broken again in a later beta - as you open more tabs, the tab widths (all of them) get smaller and smaller so you can’t tell what file is in each. Horrible change. I do recall that in Xcode 16, a tab automatically becomes pinned if the file is edited, or at least that was an option I had been using. That could explain the behavior the OP is seeing. Tabs get replaced if the tab had an unedited file in it. A new tab would be opened if the current tab had an edited file in it.

I didn’t notice when it was added but iOS 26 RC now has UIView cornerConfiguration and related properties.

Sadly none of these issues are resolved in iPadOS 26 RC. I’m really disappointed in how Apple has ignored such glaring issues for 3 months despite bug reports being filed with trivial demonstration apps provided. I’m going to be embarrassed to release my app update with iOS 26 support (these aren’t the only long unfixed iOS 26 bugs affecting my app). Please Apple, take more pride than this.

The “tapping the x in the search field cancels the search” issue has been in iPadOS 26 since beta 1. iPadOS 26 now emulates how Mac Catalyst apps have behaved for years. The issue doesn’t apply to iOS 26 since that shows a separate Cancel button. You can use FB17888632 as a demonstration of the issue. That is another search related issue I filed against iOS 26 beta 1 that still isn’t fixed in iPadOS 26 beta 9. It’s impacting my app and it also easily demonstrates the issue with the search getting cancelled when tapping the x icon to clear the search.

You may want to reconsider removing the standard iOS settings menu. It gives the user easy access to your app’s privacy and notification settings along with a few others. In my own app I have my own in-app settings screens. I simply added another menu item to the app menu so the user can either choose to go to the app’s page in the iOS Settings app or open my own in-app settings screen.

Submit version 1.15.2 to the App Store using the code for version 1.15 (or fix the bug in 1.15.1). Treat it like any other app update. There‘s no way to simply remove 1.15.1 from the App Store. If it’s a critical issue, request an expedited review when you submit the update. If granted then the app will be reviewed more quickly.

How are you trying to access the URL? In what delegate method? Normally when you get a URL to a file outside your sandbox, the URL is only valid until the delegate method returns. Post some relevant code and clarify what APIs you are using.

I had no trouble replacing the View menu with code similar to the following: override func buildMenu(with builder: any UIMenuBuilder) {     super.buildMenu(with: builder)     if builder.system == .main {         let cmd = UIKeyCommand(title: "Hello", image:nil, action:#selector(doStuff), input: "1", modifierFlags: .command)         let menu = UIMenu(image: nil, options: .displayInline, children: [cmd])         if let view = builder.menu(for: .view) {             let newView = view.replacingChildren([menu])             builder.replace(menu: .view, with: newView)         }     } } With that code the View menu only shows the one menu item I created. Tested with Xcode 26 beta 7 running on a simulated iPad running iPadOS 26 beta 6.

The documentation for showsCancelButton clearly states that this property is ignored on an iPad so that is expected behavior. So this means that tapping the little x icon causing the search to be cancelled is, unfortunately, also expected. A Mac Catalyst version of a UIKit app has always had this undesired behavior. It seems Apple is making the iPad version work the same. It’s a poor choice in my opinion. File a request via Feedback Assistant asking for it to be changed. There are many bugs in iOS 26 related to UISearchBar. I’ve filed at least 3 separate bug reports and Apple doesn’t seem to care since none have been fixed. 2 of my reports were filed against beta 1. And my reports are about clearly broken functionality, not just things I would prefer to behave differently. But you should file your own bug reports for any incorrect or undesired behavior. Apple needs to know that things don’t work and that they are affecting people’s apps. Here’s a post I made summarizing the issues I’m still facing: https://developer.apple.com/forums/thread/797701

Getting this fixed now is almost pointless. In two weeks the GM for macOS 26 likely will be out. We needed this fixed months ago so we could test the beta macOS while using a stable macOS. Maybe we’ll get lucky and by next June we’ll be able to test macOS 27 beta using macOS 26.6.3 and Xcode 26.4.

@HarrisRap Can you clarify what exactly appears to be fixed? And I assume you mean in beta 8. None of my tinting/coloring issues appear to be fixed when tested on an iPad with iPadOS 26 beta 8.

None of these issues are resolved in iPadOS 26 beta 8.

There are several existing discussions on this bug. Many people have filed bug reports since beta 1. So far it seems as if Apple really wants black and white interfaces starting with iOS 26. The tintColor of UIBarButtonItem can work in some cases. Basically only for prominent buttons not made with a custom view. Feel free to file a bug report. Maybe one more will be enough for Apple to fix the problem.