.NET Backend Development for Mobile Applications
ASP.NET Core is an obvious choice when product lives in Microsoft ecosystem: Azure, Active Directory, Power BI, MS SQL Server. For Xamarin/MAUI teams it's also shared language with mobile client — business logic in shared libraries, C# everywhere.
Typical .NET Backend Issues for Mobile
Blocking I/O in async code. .Result or .Wait() on Task inside async method — deadlock in ASP.NET Core Synchronization Context. Mobile client gets timeout, server — hung request. Diagnosed via dotnet-trace and async void report. Fix: await everywhere, no exceptions, and ConfigureAwait(false) in library code.
EF Core lazy loading in API. By default EF Core 8 disables lazy loading, but enable UseLazyLoadingProxies() — each navigation property foreach becomes separate SQL. For mobile API use explicit loading: Include() / ThenInclude() or projection via Select() straight to DTO — faster and doesn't pull extra fields.
Stack and Approaches
Basic stack: ASP.NET Core 8, EF Core 8 + PostgreSQL (Npgsql) or MS SQL Server, MediatR for CQRS pattern, FluentValidation, Serilog for structured logs to Elasticsearch/Seq.
Authentication — ASP.NET Core Identity + JWT Bearer via Microsoft.AspNetCore.Authentication.JwtBearer. For enterprise apps — Azure AD / Microsoft Entra ID integration via Microsoft.Identity.Web: couple lines of config and MSAL on mobile client enable SSO out of the box.
Push notifications: Azure Notification Hubs if infrastructure on Azure — managed service over FCM and APNs, scales to millions of devices. Alternative — direct integration via official FirebaseAdmin NuGet and dotnet-apns (HTTP/2).
Case: corporate mobile app for 3000 employees, iOS + Android. Backend ASP.NET Core 6, MS SQL Server, Azure Service Bus for event bus. Problem: endpoint /api/reports/summary ran 4–8 seconds, exceeded mobile client timeout. Reason — EF Core built query with 6 JOINs through navigation properties, MS SQL didn't use indexes due to CAST in WHERE clause. Solution: switch to Dapper for analytics queries, add computed index. Result: 180 ms.
CQRS with MediatR
For mobile API, CQRS justified even on small projects: read models optimized for client screens (no extra fields), write models for business logic. MediatR pipeline behavior — convenient place for validation (FluentValidation), logging, retry policies (Polly).
// Query handler with projection — only needed fields
public async Task<ProductListDto> Handle(GetProductsQuery request, ...)
{
return await _context.Products
.Where(p => p.IsActive)
.Select(p => new ProductListDto(p.Id, p.Name, p.Price, p.ThumbnailUrl))
.ToListAsync(cancellationToken);
}
SignalR for Realtime
If mobile client needs realtime (chat, live tracking, real-time notifications) — SignalR with Azure SignalR Service for horizontal scaling. On iOS SignalR client (SignalRClient via microsoft-signalr npm or SwiftSignalRClient) supports WebSocket with automatic Long Polling fallback.
Deployment
Docker + Azure Container Apps or AKS. dotnet publish --configuration Release -r linux-x64 with --self-contained produces binary without .NET Runtime dependency in image (but increases size). For Kubernetes — health checks via IHealthCheck interface, liveness and readiness endpoints.
Timeline: API with 15–20 methods, Identity, pushes, Azure integration — 4–6 weeks. Enterprise system with AD, Service Bus, complex role model — 10–16 weeks.