Best ASP.NET approach + modern hybrid mobile tech for content/tool sites like CitizenPass.ca?

Youness Haji 40 Reputation points
2026-07-09T17:16:43.7733333+00:00

I run a portfolio of Canadian-focused content and web tool sites (similar in concept to CitizenPass.ca and CitizenApp.ca — bilingual EN/FR informational platforms with quiz/practice-test style tools, content pages, and a companion mobile app).

I'm evaluating the best modern approach using ASP.NET for the web side, and I'd like advice on two fronts:

  1. ASP.NET architecture: For a content-heavy, SEO-driven site (server-rendered pages, bilingual routing, dynamic quiz/practice-test functionality, and a CMS-like content pipeline), would you recommend ASP.NET Core with Razor Pages, Blazor Server/WebAssembly, or a traditional MVC approach? What are the tradeoffs for SEO performance and page load speed compared to something like Next.js, which seems to be a common choice for similar sites?
  2. Hybrid mobile development: I want the same site/tool logic to also power an iOS and Android app (ideally sharing as much business logic/backend as possible with the web app). Is .NET MAUI currently a solid choice for this, or would something like a Blazor Hybrid app be a better fit given a Razor/ASP.NET backend? Are there newer approaches within the .NET ecosystem worth considering for shipping a hybrid app tied closely to an ASP.NET Core backend?

Any real-world experience, architecture diagrams, or comparisons (ASP.NET Core + MAUI vs. ASP.NET Core + a JS-based frontend/React Native) would be really helpful. Looking for something maintainable long-term with good SEO on the web side and a smooth path to native-feeling mobile apps.

Developer technologies | C#
Developer technologies | C#

An object-oriented and type-safe programming language that has its roots in the C family of languages and includes support for component-oriented programming.

0 comments
Answer accepted by question author
Nancy Vo (WICLOUD CORPORATION) 8,155 Reputation points Microsoft External Staff Moderator
2026-07-10T03:31:19.25+00:00

Hello @Youness Haji ,

Thanks for your question.

You can refer to these following techniques to achieve your goals of strong SEO on the web and a native-feeling mobile app while maximizing code reuse:

  • Web Frontend: Use ASP.NET Core Razor Pages. For a content-heavy, public-facing site, server-rendered HTML is still the gold standard for SEO and fast page loads. Blazor is a great technology, but Blazor WebAssembly has a heavy initial payload, and Blazor Server requires a persistent connection that isn't ideal for mobile browser reliability or simple content crawling.
  • Shared Backend: Build a standalone ASP.NET Core Web API. This will serve as the central engine for your CMS logic, quizzes, and user data. Both your Razor Pages web app and your mobile app will consume this API, ensuring your business logic is written only once.
  • Mobile App: Go with .NET MAUI connected to your Web API. Because you are using Razor Pages for the web (not Blazor), Blazor Hybrid wouldn't give you UI component reuse anyway. .NET MAUI will compile down to native UI controls, giving your iOS and Android users a much smoother, platform-authentic experience compared to a web-view wrapper.

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

Was this answer helpful?

2 people found this answer helpful.
0 comments
Answer accepted by question author
Bruce (SqlWork.com) 85,196 Reputation points
2026-07-09T18:39:41.2366667+00:00

picking MVC vs Razor is a personal choice. Razor receives the new features, and you can build a sharable libraries in Razor. So, it probably a better pick. Neither give much in the way of CMS features. for a .net based CMS see Orchard:

https://orchardcore.net

Blazor would be a poor choice for a complete website, but handy for app like pages. Its SEO is poor unless you design the pages as static first, so the server can pre-render. many web crawlers can not scrape interactive Blazor pages.

Coding Blazor is a lot like react as Blazor used react's component and event model. Blazor uses a js library that collects events and has a virtual dom like reacts to render the html. the js code communicates to the blazor code over a websocket if server or browser message support if WASM (currently WASM can not access the dom, or intercept browser events, this must be done in js)

for Blazor Server scaling can be an issue, as every Blazor app keeps a socket open to the server, and the server to need to keep the complete app context for each users. You can think of it as running separate application instance for each active user for the life of the page. also Blazor server pages freeze if the connection is lost, so its a poor choice for mobile devices.

its easy to share the backend api with mobile and website pages, if you start with a separate WebApi project for the website.

While Hybrid Maui and Blazor use Razor syntax for the UI, the code is not compatible with Razor pages as they use a different binding and event models.

a Hybrid Maui app runs the Blazor app in a web view, so there can be a lot of sharing between the two, but as its web page based, a hybrid app will not look native.

In contrast Maui and react native uses the native UI controls so its look and fell is closer. But in both cases the UI is the intersection of controls, and may require platform specific code to get the right feel. if you are a .net developer, Maui is probably a better choice (though it has a lot less public libraries).

I've used cross platform Mobile development before and migrated back to native for the following reasons:

  • IOS has Swift-UI and Android has Jetpack. building UI with these tools is a better than the xml style of cross platform toolkits
  • the third party libraries are often not maintained, and can lead to issues down the road
  • the cross platform development tools are always behind and somewhat fragile.
  • calling platform specific code requires learning the native platform anyway.
  • for IOS the cross platform tools use the Objective-C api and UI, while all the new UI improvements are in Swift UI. The story is similar for android.
  • you spend a lot of time debugging the build and deployment tools. be sure to never fall behind in releases.

.

Was this answer helpful?

1 person found this answer helpful.
0 comments

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Youness Haji 40 Reputation points
    2026-07-14T00:15:16.9+00:00

    Thank you both — this is genuinely one of the more useful threads I've come across on this topic, and it gives me a clear path forward.

    @Nancy Vo — the breakdown into Web Frontend / Shared Backend / Mobile App is exactly the mental model I was missing. I'd been going back and forth on Blazor mainly because it's the "newer" .NET option, but your point about Blazor Server needing a persistent connection — and how poorly that suits mobile browser reliability — is a good reminder that newer isn't always better for this use case. Landing on ASP.NET Core Razor Pages for the web, a standalone Web API as the shared engine, and .NET MAUI for native mobile gives me a stack where I'm not fighting the framework to hit SEO and performance goals.

    @Bruce (SqlWork.com) — really valuable to get the perspective of someone who's actually shipped cross-platform and migrated back to native. A few things that stood out:

    • Starting with a separate WebAPI project from day one so the web and mobile app share the same backend logic without any rework later
    • The explanation of how Blazor's event/rendering model works under the hood (the JS-to-Blazor websocket bridge, WASM's current DOM/event limitations) — that clarified a lot about why Blazor behaves the way it does, not just that it does
    • The honest rundown on cross-platform tooling: third-party library maintenance risk, the UI toolkit gap (Swift UI/Jetpack vs. XML-style cross-platform controls), and the reality that platform-specific code creeps in regardless of which framework you pick
    • Your own experience of migrating back to native after trying cross-platform first carries a lot of weight — that's not a hypothetical trade-off, that's earned knowledge

    This all lines up with what I'm seeing operationally on sites like CitizenPass.ca and CitizenApp.ca: keeping the public-facing, SEO-driven pages server-rendered while centralizing quiz logic, content, and user data behind one API that any client — web or native — can consume. It keeps the SEO-critical surface simple while still giving me a real path to a native-feeling mobile app down the line.

    Marking both answers as helpful — between the two of you, I've got both the "what" and the "why," which is exactly what I needed before committing to an architecture. Thanks again for taking the time to write such thorough responses.

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