Share via

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

Gibran Trujillo Martinez 20 Reputation points
2026-05-06T17:37:23.2666667+00:00

Hello everyone!

I work at a company where we heavily use .NET MAUI for our internal applications. I’ve been tasked with building a brand-new Point of Sale (POS) app specifically designed for Tablets, and we want to build it using .NET 10 to take advantage of the latest performance improvements and best practices.

Some context on our current architecture: In our older MAUI apps (which run mainly on phones), we’ve been using a highly customized shell architecture relying on SimpleToolkit.SimpleShell. We currently do things like:

  • Using Reflection at startup to find and register all Routing pages dynamically.
  • Manually grabbing ToolbarItems from pages and injecting them into the custom Shell's layout.
  • Using VisualStateManager to hide the Shell's Navigation Bar and Back Buttons when navigating to a LoginPage.
  • Heavy reliance on DevExpress UI controls across the board.

While this worked for our older phone apps, I feel this approach is obsolete, slow on startup, and over-engineered for a .NET 10 Tablet POS app.

What I am looking for: Since a Tablet POS typically requires a "split-view" layout (e.g., product catalog on the left/center, and the current order/cart always visible on the right), I would love to hear your recommendations on how to structure the skeleton of this new app:

  1. Root Layout / Shell: Should we stick to the native MAUI <Shell> and use something like FlyoutBehavior="Locked" for a persistent sidebar, or should we ditch Shell entirely for the main POS view and just use a root Grid to handle the split-screen?
  2. Authentication Flow: What is the current standard in .NET 10 for handling the login flow? Is swapping Application.Current.MainPage between LoginPage and AppShell the best approach instead of trying to hide Shell navigation bars?
  3. Routing: Since we want to drop our slow Reflection-based route registration, what is the cleanest way to handle DI and route registration in .NET 10 for a large enterprise app?
  4. Design / UI Patterns: Are there any recommended open-source MAUI POS templates, UI kits, or design patterns you’ve found successful for tablet-first data-heavy applications?

Any insights, articles, or architectural advice to help us start off on the right foot with .NET 10 would be greatly appreciated. Thank you!Hello everyone!

I work at a company where we heavily use .NET MAUI for our internal applications. I’ve been tasked with building a brand-new Point of Sale (POS) app specifically designed for Tablets, and we want to build it using .NET 10 to take advantage of the latest performance improvements and best practices.

Some context on our current architecture: In our older MAUI apps (which run mainly on phones), we’ve been using a highly customized shell architecture relying on SimpleToolkit.SimpleShell. We currently do things like:

  • Using Reflection at startup to find and register all Routing pages dynamically.
  • Manually grabbing ToolbarItems from pages and injecting them into the custom Shell's layout.
  • Using VisualStateManager to hide the Shell's Navigation Bar and Back Buttons when navigating to a LoginPage.
  • Heavy reliance on DevExpress UI controls across the board.

While this worked for our older phone apps, I feel this approach is obsolete, slow on startup, and over-engineered for a .NET 10 Tablet POS app.

What I am looking for: Since a Tablet POS typically requires a "split-view" layout (e.g., product catalog on the left/center, and the current order/cart always visible on the right), I would love to hear your recommendations on how to structure the skeleton of this new app:

  1. Root Layout / Shell: Should we stick to the native MAUI <Shell> and use something like FlyoutBehavior="Locked" for a persistent sidebar, or should we ditch Shell entirely for the main POS view and just use a root Grid to handle the split-screen?
  2. Authentication Flow: What is the current standard in .NET 10 for handling the login flow? Is swapping Application.Current.MainPage between LoginPage and AppShell the best approach instead of trying to hide Shell navigation bars?
  3. Routing: Since we want to drop our slow Reflection-based route registration, what is the cleanest way to handle DI and route registration in .NET 10 for a large enterprise app?
  4. Design / UI Patterns: Are there any recommended open-source MAUI POS templates, UI kits, or design patterns you’ve found successful for tablet-first data-heavy applications?

Any insights, articles, or architectural advice to help us start off on the right foot with .NET 10 would be greatly appreciated. Thank you!

Developer technologies | .NET | .NET Multi-platform App UI
0 comments

Answer accepted by question author

  1. Nancy Vo (WICLOUD CORPORATION) 4,190 Reputation points Microsoft External Staff Moderator
    2026-05-07T06:49:23.8066667+00:00

    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.

    1. 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
    1. 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.
    2. 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.

    Was this answer helpful?

    1 person found this answer helpful.

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Q&A Assist
    2026-05-06T17:37:53.3333333+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    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.

    1. 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.
    1. 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.

    1. 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:

    Was this answer helpful?

    1 person found this answer helpful.

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.