# .NET MAUI em 2026: Desenvolvimento Multiplataforma e Perguntas de Entrevista

> Tutorial de .NET MAUI para 2026: construir aplicativos multiplataforma com .NET 10, handlers, MVVM, HybridWebView. Inclui perguntas de entrevista com respostas detalhadas.

- Published: 2026-06-01
- Updated: 2026-06-01
- Author: SharpSkill
- Tags: .net maui, multiplataforma, tutorial, entrevista, migração xamarin, .net 10, desenvolvimento mobile
- Reading time: 11 min

---

.NET MAUI (Multi-platform App UI) se consolidou como um framework multiplataforma de nível produção com o .NET 10. Lançado como uma versão Long-Term Support com suporte até novembro de 2028, o .NET MAUI 10 é distribuído como workload e pacotes NuGet, entregando melhorias em qualidade, desempenho e novas APIs como os aprimoramentos do HybridWebView e SafeAreaEdges. Este tutorial aborda a construção de um aplicativo multiplataforma, a arquitetura que faz o MAUI funcionar, e as perguntas de entrevista que os times de contratação fazem em 2026.

> **.NET MAUI 10 LTS**
>
> O .NET 10 é uma versão Long-Term Support (com suporte até novembro de 2028). O MAUI 10 prioriza qualidade e desempenho em vez de novos controles de UI — tornando-o a versão mais estável do MAUI até o momento. Agora é distribuído como workload do .NET e pacotes NuGet, permitindo o versionamento fixo por projeto.

## Configurando um Projeto .NET MAUI 10 do Zero

O caminho mais rápido para um aplicativo MAUI funcional começa com a CLI do .NET. O .NET 10 introduz um template de projeto atualizado que inclui as configurações padrão do .NET Aspire, conectando telemetria e descoberta de serviços nativamente.

```bash
# Instalar o workload MAUI (se ainda não estiver presente)
dotnet workload install maui

# Criar um novo aplicativo MAUI
dotnet new maui -n CrossPlatformDemo
cd CrossPlatformDemo

# Executar no emulador Android
dotnet build -t:Run -f net10.0-android
```

A estrutura de projeto único consolida o código específico de cada plataforma em uma pasta `Platforms/` enquanto compartilha o restante. O arquivo `MauiProgram.cs` serve como raiz de composição — é onde os serviços, fontes e handlers são registrados.

```csharp
// MauiProgram.cs
using Microsoft.Extensions.Logging;

public static class MauiProgram
{
    public static MauiApp CreateMauiApp()
    {
        var builder = MauiApp.CreateBuilder();
        builder
            .UseMauiApp<App>()
            .ConfigureFonts(fonts =>
            {
                fonts.AddFont("OpenSans-Regular.ttf", "OpenSansRegular");
            });

        // Register services for dependency injection
        builder.Services.AddSingleton<IApiService, ApiService>();
        builder.Services.AddTransient<MainViewModel>();

#if DEBUG
        builder.Logging.AddDebug();
#endif

        return builder.Build();
    }
}
```

A injeção de dependências no MAUI segue o mesmo padrão do ASP.NET Core. Serviços Singleton persistem durante toda a vida do aplicativo, serviços Transient são criados a cada solicitação, e serviços Scoped — embora disponíveis — requerem cautela porque o MAUI não tem um conceito de escopo integrado como as requisições HTTP.

## Handlers: A Arquitetura por Trás da Renderização Multiplataforma

O MAUI substituiu os renderers do Xamarin.Forms por uma arquitetura de handlers. Os handlers mapeiam cada controle multiplataforma para sua contraparte nativa através de uma camada de abstração fina. A diferença-chave: handlers são sem estado e desacoplados da view virtual, tornando-os mais rápidos e fáceis de personalizar.

```csharp
// CustomEntryHandler.cs — Customizing the Entry control on Android
using Microsoft.Maui.Handlers;

public class CustomEntryHandler : EntryHandler
{
    protected override void ConnectHandler(MauiAppCompatEditText platformView)
    {
        base.ConnectHandler(platformView);
        // Remove the default underline on Android
        platformView.SetBackgroundColor(Android.Graphics.Color.Transparent);
    }
}

// Register in MauiProgram.cs
builder.ConfigureMauiHandlers(handlers =>
{
    handlers.AddHandler<Entry, CustomEntryHandler>();
});
```

No .NET 10, os controles Entry e Editor no Android mudaram de `AppCompatEditText` para `MauiAppCompatEditText`, adicionando suporte nativo para o evento `SelectionChanged`. Os handlers aprimorados de CollectionView e CarouselView introduzidos no .NET 9 agora são os padrão no iOS e Mac Catalyst, resolvendo problemas de estabilidade que existiam há bastante tempo.

## MVVM com CommunityToolkit.Mvvm: Eliminando Código Repetitivo

O gerador de código-fonte [CommunityToolkit.Mvvm](https://learn.microsoft.com/en-us/dotnet/communitytoolkit/mvvm/) elimina aproximadamente 80% da cerimônia MVVM. Sem implementação manual de `INotifyPropertyChanged`, sem wrappers de comando — os atributos controlam a geração de código.

```csharp
// MainViewModel.cs
using CommunityToolkit.Mvvm.ComponentModel;
using CommunityToolkit.Mvvm.Input;

public partial class MainViewModel : ObservableObject
{
    private readonly IApiService _apiService;

    public MainViewModel(IApiService apiService)
    {
        _apiService = apiService;
    }

    // Source generator creates the 'Title' property with change notification
    [ObservableProperty]
    private string _title = string.Empty;

    // Source generator creates the 'IsLoading' property
    [ObservableProperty]
    private bool _isLoading;

    // Source generator creates an async ICommand
    [RelayCommand]
    private async Task LoadDataAsync()
    {
        IsLoading = true;
        try
        {
            Title = await _apiService.FetchTitleAsync();
        }
        finally
        {
            IsLoading = false;
        }
    }
}
```

O XAML faz binding diretamente nas propriedades e comandos gerados:

```xml
<!-- MainPage.xaml -->
<ContentPage xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             xmlns:vm="clr-namespace:CrossPlatformDemo.ViewModels"
             x:DataType="vm:MainViewModel">
    <VerticalStackLayout Padding="20" Spacing="16">
        <Label Text="{Binding Title}"
               FontSize="24"
               HorizontalOptions="Center" />
        <Button Text="Load Data"
                Command="{Binding LoadDataCommand}"
                IsEnabled="{Binding IsLoading, Converter={StaticResource InverseBoolConverter}}" />
        <ActivityIndicator IsRunning="{Binding IsLoading}"
                           IsVisible="{Binding IsLoading}" />
    </VerticalStackLayout>
</ContentPage>
```

O atributo `x:DataType` habilita compiled bindings, que são mais rápidos que bindings baseados em reflexão e produzem erros em tempo de compilação quando um caminho de binding está incorreto.

## HybridWebView no .NET 10: A Ponte entre Nativo e Web

[HybridWebView](https://learn.microsoft.com/en-us/dotnet/maui/user-interface/controls/hybridwebview) permite incorporar conteúdo web dentro de um aplicativo MAUI mantendo comunicação bidirecional entre C# e JavaScript. O .NET 10 adiciona três capacidades: invocação JavaScript do tipo fire-and-forget, eventos de inicialização para configuração específica da plataforma, e interceptação de requisições web.

```csharp
// MainPage.xaml.cs — HybridWebView interaction
public partial class MainPage : ContentPage
{
    public MainPage()
    {
        InitializeComponent();

        // Initialization event for platform-specific tweaks
        hybridWebView.WebViewInitialized += (sender, args) =>
        {
            // Access the native platform view after initialization
            System.Diagnostics.Debug.WriteLine("WebView ready");
        };
    }

    // Call JavaScript from C#
    private async void OnCallJsClicked(object sender, EventArgs e)
    {
        var result = await hybridWebView.InvokeJavaScriptAsync<string>(
            "getFormData",  // JS function name
            HybridSampleContext.Default.String  // JSON serialization context
        );
        await DisplayAlert("Result", result, "OK");
    }

    // Fire-and-forget: no return type needed (.NET 10)
    private async void OnResetClicked(object sender, EventArgs e)
    {
        await hybridWebView.InvokeJavaScriptAsync("resetForm");
    }
}
```

O JavaScript correspondente recebe as chamadas e pode enviar mensagens de volta para o C#:

```javascript
// wwwroot/index.html (HybridWebView content)
function getFormData() {
    return JSON.stringify({
        name: document.getElementById('name').value,
        email: document.getElementById('email').value
    });
}

function resetForm() {
    document.getElementById('name').value = '';
    document.getElementById('email').value = '';
}
```

Exceções JavaScript lançadas durante `InvokeJavaScriptAsync` agora são automaticamente encaminhadas para o .NET como exceções, eliminando falhas silenciosas.

## SafeAreaEdges: Layouts Pixel-Perfect em Cada Dispositivo

O .NET MAUI 10 introduz a propriedade `SafeAreaEdges` em Layout, ContentView, ContentPage, Border e ScrollView. A nova enumeração (`None`, `SoftInput`, `Container`, `Default`, `All`) substitui o antigo `Page.UseSafeArea` específico do iOS por uma abordagem multiplataforma.

```xml
<!-- Granular safe area control per section -->
<ContentPage xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
             SafeAreaEdges="All">
    <Grid RowDefinitions="Auto,*,Auto">
        <!-- Header respects all safe areas -->
        <Border Grid.Row="0" SafeAreaEdges="Container">
            <Label Text="Header" />
        </Border>

        <!-- Content scrolls under safe areas -->
        <ScrollView Grid.Row="1" SafeAreaEdges="SoftInput">
            <VerticalStackLayout Padding="16">
                <Entry Placeholder="Type here..." />
            </VerticalStackLayout>
        </ScrollView>

        <!-- Footer avoids home indicator -->
        <Border Grid.Row="2" SafeAreaEdges="Container">
            <Label Text="Footer" />
        </Border>
    </Grid>
</ContentPage>
```

`SoftInput` ajusta o conteúdo quando o teclado virtual aparece. `Container` evita entalhes, sensores e o indicador de home. Esses valores podem ser combinados por controle, permitindo que um cabeçalho fique sob a barra de status enquanto a área de conteúdo permanece livre.

## Migração do Xamarin.Forms para o .NET MAUI

O Xamarin.Forms chegou ao fim do suporte em maio de 2024. A migração para o MAUI envolve mudanças estruturais além de uma simples troca de namespaces. A seguir, um checklist de migração baseado em conversões de projetos reais:

> **Fim de vida do Xamarin**
>
> O Xamarin.Forms não tem mais suporte desde maio de 2024. Aplicativos que ainda rodam sobre Xamarin carregam riscos de segurança e compatibilidade. O .NET MAUI 10 (LTS, com suporte até novembro de 2028) é o alvo de migração designado.

1. **Estrutura do projeto** — Converter os projetos específicos de cada plataforma para o modelo de projeto único do MAUI. Mover o código compartilhado para a raiz, código de plataforma sob `Platforms/`.
2. **Namespaces** — Substituir `Xamarin.Forms` por `Microsoft.Maui.Controls` e `Xamarin.Essentials` por `Microsoft.Maui.Essentials` (agora integrado ao MAUI).
3. **Renderers para Handlers** — Renderers personalizados precisam ser reescritos como handlers. A API de handlers é mais simples, mas a lógica de mapeamento difere.
4. **Inicialização** — Substituir a inicialização em `App.xaml.cs` por `MauiProgram.cs` usando o padrão builder.
5. **Pacotes NuGet** — Muitos pacotes da era Xamarin têm equivalentes no MAUI. Verificar a compatibilidade antes de atualizar.
6. **Injeção de dependências** — O MAUI usa `Microsoft.Extensions.DependencyInjection` nativamente. Substituir qualquer container DI de terceiros ou chamadas ao `DependencyService`.

O [.NET Upgrade Assistant](https://dotnet.microsoft.com/en-us/platform/upgrade-assistant) automatiza partes dos passos 1-2, mas os handlers (passo 3) e ajustes de lógica de negócio requerem trabalho manual.

## Perguntas de Entrevista .NET MAUI Essenciais para 2026

Estas perguntas refletem o que os times de contratação perguntam em 2026, com base no ecossistema atual do .NET 10.

### Como a arquitetura de handlers do MAUI difere dos renderers do Xamarin.Forms?

Os renderers no Xamarin.Forms eram fortemente acoplados tanto ao controle multiplataforma quanto à view nativa, criando uma dependência bidirecional. Os handlers no MAUI são mapeadores sem estado: recebem notificações de mudança de propriedades e as aplicam à view nativa através de um dicionário de mappers. Esse desacoplamento significa que os handlers são mais fáceis de testar, estender e reutilizar. Os dicionários `PropertyMapper` e `CommandMapper` substituem o padrão de override `OnElementPropertyChanged`, tornando a personalização explícita em vez de estar enterrada em instruções switch.

### Quais são as armadilhas dos tempos de vida de DI específicos do MAUI?

O MAUI suporta os tempos de vida Singleton, Transient e Scoped, mas o Scoped se comporta de maneira diferente do ASP.NET Core. Não existe um limite de escopo natural (como uma requisição HTTP). Um serviço Scoped registrado no MAUI age como um Singleton a menos que escopos personalizados sejam criados manualmente. Erros comuns: registrar um ViewModel como Singleton quando ele contém estado específico da página (dados obsoletos ao navegar), ou registrar uma conexão de banco de dados como Transient (esgotamento do pool de conexões). A regra geral: ViewModels são Transient, serviços são Singleton, e Scoped deve ser evitado a menos que o ciclo de vida do escopo seja gerenciado explicitamente.

> **Dica de entrevista**
>
> Ao responder perguntas sobre injeção de dependências, é importante demonstrar compreensão de como o ciclo de vida do MAUI difere do modelo de escopo por requisição do ASP.NET Core. Os entrevistadores buscam consciência sobre vazamentos de memória e problemas de estado obsoleto específicos de aplicativos móveis de longa execução.

### Qual a diferença entre compiled binding e binding baseado em reflexão no MAUI?

Bindings baseados em reflexão resolvem os caminhos de propriedades em tempo de execução usando `System.Reflection`, o que é lento e produz erros em runtime para erros de digitação. Compiled bindings, habilitados com `x:DataType`, resolvem os caminhos de binding em tempo de compilação. O compilador gera código de acesso direto às propriedades, pulando a reflexão completamente. Isso melhora o tempo de inicialização, reduz alocações de memória e detecta erros de binding durante o build. No .NET 10, o novo gerador de código-fonte XAML otimiza ainda mais ao compilar o XAML em tempo de build em vez de parseá-lo em tempo de execução.

### Quais estratégias existem para compartilhar código entre um aplicativo MAUI e um backend ASP.NET Core?

A abordagem recomendada utiliza uma biblioteca de classes compartilhada contendo DTOs, lógica de validação e regras de negócio. Tanto o aplicativo MAUI quanto o backend ASP.NET Core referenciam essa biblioteca. O .NET 10 reforça esse padrão com a nova [integração .NET Aspire para MAUI](https://learn.microsoft.com/en-us/dotnet/maui/whats-new/dotnet-10), que fornece descoberta de serviços e telemetria entre projetos mobile e backend. Contratos compartilhados usando geradores de código-fonte do `System.Text.Json` garantem consistência na serialização. A restrição-chave: a biblioteca compartilhada deve ter como alvo `net10.0` (não TFMs específicos de plataforma) para permanecer portável.

### Qual a diferença entre HybridWebView e BlazorWebView no MAUI?

O BlazorWebView hospeda uma aplicação Blazor completa dentro do aplicativo MAUI. Componentes Razor são renderizados em uma WebView incorporada, mas o runtime .NET executa nativamente (não via WebAssembly). O HybridWebView é mais leve: carrega conteúdo HTML/CSS/JS estático e fornece interoperabilidade de C# para JavaScript sem a sobrecarga do framework Blazor. A escolha depende do caso de uso. O BlazorWebView é adequado para times com componentes Blazor existentes que desejam reuso de código. O HybridWebView é adequado para cenários onde conteúdo web existente (dashboards, mapas, editores) precisa de integração nativa sem um framework completo.

Para aprofundar esses conceitos, é possível praticar mais [perguntas de entrevista .NET no SharpSkill](/technologies/dotnet) com exercícios interativos.

## Conclusão

- O .NET MAUI 10 é uma versão LTS (suporte até novembro de 2028) focada em estabilidade e desempenho, não em adição constante de funcionalidades — tornando-o uma escolha confiável para aplicativos multiplataforma em produção
- A arquitetura de handlers substitui os renderers do Xamarin por mapeadores sem estado, melhorando a testabilidade e personalização através de `PropertyMapper` e `CommandMapper`
- Os geradores de código-fonte do CommunityToolkit.Mvvm removem a maior parte do código repetitivo MVVM — os atributos `[ObservableProperty]` e `[RelayCommand]` substituem implementações manuais de `INotifyPropertyChanged` e comandos
- O HybridWebView no .NET 10 adiciona chamadas JavaScript fire-and-forget, eventos de inicialização e interceptação de requisições para integração nativa-web
- SafeAreaEdges fornece controle granular e multiplataforma sobre entalhes, teclados e barras do sistema, substituindo o antigo `UseSafeArea` limitado ao iOS
- A migração do Xamarin.Forms requer reescrita de handlers e refatoração da inicialização — o .NET Upgrade Assistant lida com mudanças de namespaces, mas trabalho manual continua necessário para renderers personalizados
- A preparação para entrevistas deve focar na arquitetura de handlers vs renderers, armadilhas de tempos de vida de DI em aplicativos de longa execução, compiled bindings e as diferenças entre HybridWebView e BlazorWebView

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/pt/blog/dotnet/dotnet-maui-cross-platform-development-interview-questions