Use iPad vertical space more efficiently with tabs and split navigation

[muhiro12]

Priority assessment — 2026-09-29

• Owner priority: 3/5
• Final priority: 2/5
• Rationale: The potential gain is limited mainly to iPad while the layout change can be structurally heavy and may interact with nested split navigation. That risk is poorly matched to the current release stage.
• Sequencing: Defer the composition experiment until after 4.0 unless measurement reveals a clearly low-risk native fix.

Problem

On iPad, Cookle's top-level TabView occupies a top tab-bar region and each tab then embeds its own NavigationSplitView below it.

The result is that the split-view content begins below the tab-bar area instead of feeling like it uses the full iPad canvas. With already information-dense split navigation, the lost vertical space is noticeable.

MainTabView currently uses the native role-based TabView but does not apply a dedicated iPad tab-view style/placement policy.

Goal

Find the best native iPad composition for top-level destinations plus split navigation, maximizing usable content space without replacing system tab/navigation behavior with a custom bar.

Options to compare

• Keep the current top tab bar and accept/rescope its reserved content area if this is the correct system behavior.
• Evaluate .tabViewStyle(.sidebarAdaptable) on iPad.
• Evaluate the current API for defaultAdaptableTabBarPlacement, including a sidebar default where appropriate.
• Determine whether integrating top-level tabs into a sidebar is compatible with Cookle's existing per-feature NavigationSplitView sidebars or creates confusing nested sidebars.
• Investigate whether current iPadOS APIs support the desired visual effect of content extending behind/around a floating tab presentation. Do not assume that a system top tab bar can be overlaid on arbitrary split content.
• Preserve iPhone's compact bottom-tab behavior.

Acceptance criteria

• Current iPad geometry is measured/screenshotted on at least one portrait and landscape size.
• At least the current top-bar design and one native alternative are compared.
• The chosen design has a clear reason for how top-level tabs coexist with feature-level sidebars.
• Recipe/Diary/Photo split views gain usable space or the current system-reserved region is explicitly accepted as the better tradeoff.
• iPhone tab behavior and Search tab activation remain correct.
• No custom floating tab implementation is introduced unless native approaches are proven insufficient and the benefit clearly justifies it.

References: Apple SidebarAdaptableTabViewStyle, AdaptableTabBarPlacement, and defaultAdaptableTabBarPlacement.