Seeking Architecture and Layout Recommendations for a .NET 10 MAUI Tablet POS App

For a tablet-first .NET MAUI POS app on .NET 10, the platform guidance in the context points toward using Shell for navigation and app structure, and then building the POS layout itself as a custom page hierarchy within that Shell.

1. Root layout / Shell

.NET MAUI Shell is designed to give a single place to describe the visual hierarchy, a common navigation experience, and URI-based navigation for any page in the app. It also lets pages define their own appearance (colors, nav bar, tab bar, title view, etc.) via attached properties.

For a POS:

• Use a standard AppShell as the root to define the overall structure (flyout items, tabs, high-level sections).
• Implement the actual POS workspace (product catalog + cart) as one or more ContentPages that use a Grid or other layout to create the split view.
• If a persistent sidebar is needed, it can be:
  • A FlyoutItem with FlyoutBehavior="Locked" for a permanent left menu, or
  • A custom Grid-based layout inside a single ContentPage where the left column is the catalog/navigation and the right column is the cart.

Shell supports multiple ShellContent entries per Tab, which are navigable via top tabs. That can be used for multi-pane workflows if needed. Pages are typically created on demand via DataTemplate in ShellContent, which keeps startup lean.

2. Authentication flow

Shell provides attached properties to control page appearance, including hiding the navigation bar or tab bar on specific pages. For example, a LoginPage can:

• Disable the navigation bar using the NavBarIsVisible attached property.
• Use Shell.TitleView to completely control what appears in the nav bar when visible.

Shell also respects page visibility via IsVisible. A page with IsVisible = false cannot be navigated to. This can be used to hide authenticated-only sections until login is complete.

The context does not prescribe a single “standard” login pattern, but within Shell the common pattern is:

• Keep AppShell as the root.
• Use Shell navigation to move between LoginPage and the main POS pages.
• Control nav bar visibility and other chrome via Shell attached properties instead of swapping Application.Current.MainPage.

3. Routing and navigation

Shell provides a URI-based navigation scheme that permits navigation to any page in the app. Pages are defined as ShellContent within FlyoutItem or Tab elements, typically using DataTemplate to create pages on demand. This avoids reflection-based registration:

• Define the visual hierarchy and routes declaratively in AppShell XAML.
• Use Shell’s URI navigation to move between pages.
• The BindingContext of each ShellContent is inherited from the parent Tab, which can be used with DI to provide view models at the tab level.

This approach removes the need for reflection-based route discovery and keeps routing explicit and predictable.

4. Design / UI patterns for tablet POS

The context shows several Shell capabilities that are useful for a tablet POS layout:

• Use Shell.TitleView to place custom views (e.g., status indicators, user info, quick actions) in the navigation bar. This can be any View, including a layout with multiple children.
• Use a ContentPage as the root of the POS workspace, with a Grid or StackLayout to create a split view (catalog vs. cart). ContentPage can only have one child, so use a layout (e.g., Grid) as that child and place multiple regions inside it.
• For data-heavy UIs, use layouts like VerticalStackLayout and HorizontalStackLayout inside the grid regions to organize controls.

Shell’s page configuration features (colors, nav bar visibility, tab bar visibility, title view) let the POS workspace be full-screen and focused, while still benefiting from Shell’s navigation and URI routing.

Putting it together for a .NET 10 tablet POS skeleton:

• Root: AppShell defines high-level sections (POS, reports, settings) as FlyoutItem/Tab/ShellContent entries.
• POS workspace: a ContentPage created via ShellContent ContentTemplate, whose content is a Grid with columns for catalog and cart.
• Authentication: a LoginPage within Shell, with nav bar hidden via NavBarIsVisible and visibility-controlled access to authenticated sections.
• Routing: explicit Shell hierarchy and URI navigation, no reflection-based registration.
• Chrome: use Shell.TitleView for custom header content on POS pages; hide nav bar where needed.

References:

• .NET MAUI Shell overview
• .NET MAUI Shell pages
• .NET MAUI Shell flyout
• Create a .NET MAUI Shell app
• Create a .NET MAUI app

Hello @Gibran Trujillo Martinez ,

Thanks for your question.

1. I recommend using a Hybrid approach: Shell for top-level navigation routing, and a custom Grid-based layout inside your ContentPage for the actual POS split-view. You should not rely on Shell's Flyout as the visual backbone of your POS screen.

Since Shell's Flyout, even when locked — is fundamentally designed as a navigation drawer, not a persistent dual-pane content host. Its purpose is to slide between app sections, not to keep two live content areas, a product catalog and a cart, simultaneously visible and interactive on the same screen at all times.

2. Yes. Swapping Application.Current.Windows[0].Page between LoginPage and AppShell is the correct and recommended standard in .NET 10. LoginPage should never live inside Shell's hierarchy. Using VisualStateManager to hide navigation bars on a login page that sits inside Shell is an anti-pattern you should fully abandon.

Regarding handling the login flow, you can refer to these following workarounds:

• JWT + SecureStorage: for internal apps with a custom backend.
• WebAuthenticator + OIDC: for apps authenticating against an external Identity Provider like Azure AD.
• .NET 10 Passkeys: the headline new standard in .NET 10, enabling passwordless biometric login natively via ASP.NET Core Identity, with no third-party library required

3. I suggest using explicit, modular feature-based DI and route registration using extension methods — one module per feature area. For maximum compile-time safety and AOT compatibility, this can be elevated further with C# Source Generators. Both approaches completely eliminate runtime Reflection.
4. For a tablet-first, data-heavy POS, the recommended approach is the MVVM pattern with feature-based project structure, CollectionView with GridItemsLayout for product browsing, a persistent cart panel in a split Grid, and open-source UI kits such as Syncfusion Essential UI Kit and Uranium UI as your component foundation. Avoid building everything from scratch and avoid heavy commercial-only dependencies where free, high-quality alternatives exist.

I hope this addresses your question. If this response was helpful, please consider following the guidance to provide feedback.