Possible replacement of UIKit Splitview controller

[BPerlakiH]

As discovered in PR #1258, our current UIKit-based SplitViewController is incompatible with Apple’s newer SwiftUI navigation architecture.

When attempting to programmatically select a detail screen, we encounter a duplicated navigation bar—a known issue when combining UIHostingController with NavigationStack, as discussed on Stack Overflow. While there are workarounds to mitigate this, they introduce complexity and don't fully resolve the architectural mismatch.

Given this, it may be time to reassess our reliance on UIKit for split view navigation. Ideally, we should migrate to a SwiftUI-only solution using NavigationSplitView, which offers better integration, cleaner navigation logic, and improved compatibility with modern APIs.

⚠️ Note: Most iPad views are currently tied to the existing UIKit implementation, so this transition will require thorough testing across screen sizes and platforms.

[kelson42]

@BPerlakiH Please carry on with the assessment and post the pro/cons + time estimation here.

[BPerlakiH]

@kelson42 I looked further into this.

The pros are:

• that we can cut down on some custom code we had for iOS, that was doing some bridging between old UIKit classes to SwiftUI
• this way the code will be much closer to what we have on macOS

The cons:

• some of the essential parts for this are available only from iOS 17 (currently we are on min. 16.6)
• it is a larger piece of work to replicate what we have: rebuilding the side navigation menu, the navigation needs to change quite a bit as well

I think, it would make sense to do it in this order:

• release Kiwix with the iOS 26 fixes first
• update the minimum version of iOS to 17, and do some clean up of removing old iOS 16 APIs
• then start working on this part

Realistically it is a 1 to 2 weeks work.

[kelson42]

OK, LGTM but moving to 3.12 milestone.