Aplicații mobile în 2026: nativ, Flutter, React Native, .NET MAUI sau PWA?

Agenții de vânzări ai unei firme de distribuție lucrează toată ziua pe teren. Iau comenzi de la magazine, scanează coduri de bare, fac poze la rafturi și trimit totul la sediu. Până acum foloseau o aplicație web pe telefon, care se bloca exact în magazinele fără semnal. Directorul comercial are o soluție: „Facem o aplicație mobilă. Și vreau să fie în App Store, ca să arate serios.”

Echipa are trei opțiuni pe masă. Două aplicații native, una pentru iOS și una pentru Android, scrise de oameni diferiți. O aplicație cross-platform, cu Flutter, React Native sau .NET MAUI. Sau o aplicație web mai bună, adică o PWA. Fiecare are susținători convinși, iar fiecare costă altfel, nu doar la început, ci în fiecare an în care aplicația rămâne în magazine.

Acesta e al patrulea articol din seria despre alegerea tehnologiei de UI. Am trecut prin web, desktop-ul nativ în .NET și desktop-ul cu tehnologii web. Acum trecem pe ecranul cel mai mic și, de multe ori, cel mai important: telefonul.

Harta: patru drumuri spre telefon

• Nativ — Swift și SwiftUI pentru iOS, Kotlin și Jetpack Compose pentru Android. Două baze de cod, experiența cea mai bună pe fiecare platformă.
• Cross-platform cu UI propriu — Flutter desenează singur fiecare pixel, la fel ca Avalonia pe desktop. Aceeași interfață peste tot, controlată complet de framework.
• Cross-platform cu controale native — React Native și .NET MAUI scriu codul o singură dată, dar afișează controalele native ale fiecărei platforme. Compose Multiplatform și Kotlin Multiplatform ocupă o poziție intermediară: logica e mereu comună, iar UI-ul poate fi comun sau nativ.
• Web — o PWA, adică o aplicație web instalabilă, cu iconiță pe ecranul principal, funcționare offline și, în anumite condiții, notificări push.

Ca și în articolele anterioare, aceeași componentă simplă arată mult despre filozofia fiecărei opțiuni. Iată un buton care numără atingerile.

SwiftUI (iOS nativ)

struct Counter: View {
    @State private var count = 0

    var body: some View {
        Button("Atingeri: \(count)") { count += 1 }
    }
}

Jetpack Compose (Android nativ)

@Composable
fun Counter() {
    var count by remember { mutableIntStateOf(0) }
    Button(onClick = { count++ }) {
        Text("Atingeri: $count")
    }
}

Flutter

class Counter extends StatefulWidget {
  const Counter({super.key});

  @override
  State<Counter> createState() => _CounterState();
}

class _CounterState extends State<Counter> {
  int count = 0;

  @override
  Widget build(BuildContext context) => ElevatedButton(
        onPressed: () => setState(() => count++),
        child: Text('Atingeri: $count'),
      );
}

React Native

import { useState } from 'react';
import { Button } from 'react-native';

export function Counter() {
  const [count, setCount] = useState(0);
  return <Button title={`Atingeri: ${count}`} onPress={() => setCount(count + 1)} />;
}

.NET MAUI

public partial class CounterViewModel : ObservableObject
{
    [ObservableProperty]
    [NotifyPropertyChangedFor(nameof(Text))]
    private int count;

    public string Text => $"Atingeri: {Count}";

    [RelayCommand]
    private void Increment() => Count++;
}

<Button Text="{Binding Text}" Command="{Binding IncrementCommand}" />

SwiftUI și Jetpack Compose seamănă izbitor, pentru că ambele au adoptat UI-ul declarativ. React Native e aproape identic cu React-ul din primul articol. Flutter cere ceva mai mult cod de ceremonie, dar e complet previzibil. Iar MAUI folosește exact același ViewModel cu CommunityToolkit.Mvvm ca WPF, Avalonia și Uno din articolul despre desktop.

Nativ: cel mai bun rezultat, la cel mai mare cost

O aplicație nativă are acces imediat la orice funcționalitate nouă a sistemului de operare, cel mai bun comportament pentru animații, gesturi și accesibilitate și cea mai mică distanță între documentația oficială și codul tău. Când Apple sau Google lansează un API nou, aplicația nativă îl poate folosi din prima zi, fără să aștepte un plugin.

Prețul este dublarea. Două baze de cod, două seturi de teste, de obicei doi oameni sau două echipe, iar fiecare funcționalitate se scrie și se depanează de două ori. Pentru o firmă mică, asta înseamnă de obicei că una dintre platforme rămâne mereu în urmă.

Merită amintit Kotlin Multiplatform: logica de business, accesul la rețea și baza de date locală se scriu o singură dată în Kotlin și se folosesc atât pe Android, cât și pe iOS. Interfața poate rămâne nativă pe fiecare platformă. Iar dacă vrei să împarți și interfața, Compose Multiplatform este stabil pe iOS din 2025. E un drum bun pentru echipele care au pornit cu Android și vor să ajungă pe iOS fără o rescriere completă.

Alege nativ când: aplicația este produsul principal, experiența utilizatorului e un avantaj competitiv, folosești intens funcții de platformă (cameră avansată, AR, widget-uri, integrare cu ceasul) sau ai buget pentru două echipe.

Flutter: o singură interfață, desenată peste tot la fel

Flutter folosește limbajul Dart și propriul motor de randare. Pe iOS și Android, motorul implicit este acum Impeller. Nu folosește controalele native, ci desenează totul singur. Rezultatul este o interfață identică pe toate dispozitivele, animații fluide și un hot reload foarte rapid. Este, probabil, cea mai productivă experiență de dezvoltare din toată lista.

Flutter a ajuns una dintre cele mai folosite tehnologii pentru aplicațiile noi, iar ecosistemul de pachete e mare și matur. Comunitatea a discutat mult despre nivelul de investiție al Google după reorganizările din 2024, dar framework-ul a continuat să primească lansări regulate.

Limitele vin tocmai din abordarea lui. Aplicația nu va arăta automat ca o aplicație iOS sau Android, ci ca o aplicație Flutter, dacă nu lucrezi conștient la acest aspect. Dart e o limbă pe care echipa probabil trebuie s-o învețe, deși cei care vin din C# sau Java se adaptează repede. Iar orice funcționalitate nativă fără pachet existent trebuie scrisă de două ori, în Swift și în Kotlin, printr-un platform channel.

Alege Flutter când: vrei o interfață de brand, identică pe iOS și Android, o echipă mică ce trebuie să livreze pe ambele platforme rapid, sau o aplicație cu UI bogat și animații.

React Native: React pe telefon, cu controale native

React Native rulează logica în JavaScript sau TypeScript și afișează controale native. Pentru o echipă care lucrează deja cu React pe web, e cea mai scurtă cale spre mobil: aceleași concepte, aceleași hook-uri, de multe ori aceeași logică de business și chiar aceleași biblioteci.

În ultimii ani, React Native a schimbat complet arhitectura internă. Noua arhitectură, care elimină vechea punte asincronă dintre JavaScript și codul nativ, a devenit implicită în versiunea 0.76, iar din versiunea 0.82 nu mai poate fi dezactivată. Pentru proiectele noi, recomandarea comunității și a echipei React Native este să pornești cu Expo. Expo se ocupă de build-uri, de pachetele native și de actualizările aplicației, și elimină o bună parte din durerile istorice ale lui React Native.

Limitele: depinzi de calitatea bibliotecilor din comunitate pentru funcționalitățile native, iar actualizarea între versiuni majore poate fi uneori costisitoare. Aplicațiile mai vechi, rămase pe arhitectura veche, au de făcut o migrare serioasă.

Alege React Native când: ai deja o echipă React și vrei să împarți logică și oameni între web și mobil, sau vrei aspect nativ pe fiecare platformă cu o singură bază de cod.

.NET MAUI: C# pe telefon, pentru echipele .NET

.NET MAUI este succesorul lui Xamarin.Forms. Un singur proiect, C# și XAML, controale native pe Android, iOS, macOS și Windows. Pentru o echipă .NET, argumentul e același ca la Blazor: aceeași limbă, aceleași biblioteci, aceleași DTO-uri și aceeași injecție de dependențe ca în backend.

MAUI are și un avantaj pe care celelalte nu îl au: Blazor Hybrid. Cu BlazorWebView, componentele Razor din aplicația web pot rula pe telefon, nativ, cu acces la cameră, GPS și fișiere, la fel ca în articolul despre desktop. Pentru o echipă care are deja un SaaS în Blazor, asta poate însemna o aplicație mobilă construită în mare parte din componentele existente.

Să fim însă onești: MAUI are o reputație mixtă. Mulți dezvoltatori au raportat probleme de stabilitate, tooling mai lent și un ecosistem de biblioteci mult mai mic decât la Flutter sau React Native. Microsoft a investit în ultimele versiuni în primul rând în calitate și performanță. În .NET 10 a apărut și suport experimental pentru rularea pe CoreCLR pe Android, în locul runtime-ului Mono. Tot pentru mobil, merită amintit că și Avalonia și Uno Platform, prezentate în articolul despre desktop, ajung pe iOS și Android.

Alege MAUI când: echipa este .NET, aplicația e de business (formulare, liste, sincronizare cu un backend ASP.NET Core), vrei să reutilizezi componente Blazor sau migrezi o aplicație Xamarin.Forms existentă.

PWA: aplicația care nu trece prin magazin

Înainte de orice framework mobil, merită pusă întrebarea: chiar ai nevoie de o aplicație în magazin? O PWA este o aplicație web care se poate instala pe ecranul principal, funcționează offline prin service workers și se actualizează la fiecare deploy, fără review și fără ca utilizatorii să facă nimic.

Pe Android, PWA-urile sunt foarte bine suportate. Browserul poate propune instalarea, notificările push funcționează, iar o PWA poate fi publicată chiar și în Google Play, printr-un Trusted Web Activity.

Pe iOS, situația e mai complicată. Notificările push funcționează din iOS 16.4, dar doar pentru aplicațiile adăugate pe ecranul principal. Instalarea se face manual, din meniul Share, fără un prompt automat. Lipsesc sincronizarea în fundal și accesul la Bluetooth sau NFC, iar spațiul de stocare poate fi golit de sistem după o perioadă lungă de neutilizare. Pentru cei din Uniunea Europeană, e bine de știut că Apple a renunțat în 2024 la planul de a elimina aplicațiile web de pe ecranul principal în UE, deci PWA-urile continuă să funcționeze și aici.

Alege PWA când: aplicația e în principal formulare, liste și conținut, utilizatorii pot fi instruiți să o instaleze (cum se întâmplă la aplicațiile interne ale unei firme), iar nevoia de hardware se limitează la cameră și GPS.

Costurile ascunse ale unei aplicații în magazine

Comparațiile dintre framework-uri se opresc de obicei la cod. Dar o aplicație mobilă are un cost de întreținere care nu apare pe web, indiferent de tehnologia aleasă:

• Conturi și review. Contul de dezvoltator Apple costă anual, iar cel Google Play o singură dată. Fiecare versiune trece printr-un review care poate dura de la câteva ore la câteva zile și care, uneori, se încheie cu o respingere.
• Build-uri pentru iOS. Ai nevoie de macOS și Xcode, pe un Mac propriu sau într-un serviciu de build în cloud.
• Actualizări anuale obligatorii. Google Play cere ca aplicațiile să țintească o versiune recentă de Android, iar Apple cere build-uri cu SDK-uri recente. Chiar dacă aplicația nu primește funcționalități noi, trebuie reconstruită și republicată periodic.
• Versiuni vechi în producție. Pe web, toți utilizatorii au mereu ultima versiune. Pe mobil, o parte din utilizatori rămân luni de zile pe versiuni vechi. Pentru backend, asta înseamnă versionarea API-ului și compatibilitate cu versiunile mai vechi, plus un mecanism de actualizare forțată pentru cazurile critice.
• Notificări push. Ai nevoie de APNs pentru iOS și FCM pentru Android, de obicei unificate printr-un serviciu precum Firebase Cloud Messaging sau Azure Notification Hubs, plus gestionarea token-urilor de dispozitiv în backend.
• Actualizări fără magazin. Expo (pentru React Native) și Shorebird (pentru Flutter) permit livrarea unor corecturi direct pe dispozitive, fără un nou review, în limitele permise de regulile magazinelor. Pentru o echipă mică, merită luat în calcul.

Ce faci cu aplicațiile rămase pe Xamarin

Suportul oficial pentru Xamarin s-a încheiat pe 1 mai 2024. Aplicația nu se oprește din funcționat, dar problema apare la actualizări: magazinele cer build-uri cu SDK-uri recente, pe care Xamarin nu le mai primește. Cu fiecare an, devine tot mai greu, apoi imposibil, să publici o versiune nouă.

Drumul firesc este migrarea pe .NET modern:

1. Xamarin.Forms se migrează pe .NET MAUI. Conceptele, XAML-ul și o mare parte din cod se păstrează, dar renderer-ele personalizate trebuie rescrise ca handlere.
2. Xamarin.Android și Xamarin.iOS se migrează pe .NET for Android și .NET for iOS, cu modificări relativ mici.
3. Înainte de migrare, verifică dependențele. Multe pachete NuGet pentru Xamarin nu mai sunt întreținute și trebuie înlocuite. De obicei, aici se ascunde cea mai mare parte din efort.
4. Dacă aplicația are puține ecrane, iar echipa s-a schimbat între timp, compară costul migrării cu cel al unei rescrieri în Flutter sau React Native. Nu e întotdeauna evident care e mai mic.

Tabelul de decizie

Greșelile pe care le văd cel mai des

• Aplicație în magazin pentru imagine. „Să fim în App Store” nu e o cerință tehnică. Dacă utilizatorii sunt angajații firmei, o PWA bine făcută rezolvă problema cu o fracțiune din cost.
• Offline adăugat la final. Lucrul offline nu e o funcționalitate, ci o arhitectură: bază de date locală, coadă de sincronizare, rezolvarea conflictelor. Dacă e o cerință, trebuie proiectată din prima zi.
• API fără versionare. Prima schimbare incompatibilă din backend blochează toți utilizatorii care nu și-au actualizat aplicația.
• Testare doar pe telefoane noi. Utilizatorii reali au telefoane de trei ani, cu memorie puțină și semnal slab. Testează și pe un Android ieftin.
• Framework ales după limbaj, nu după echipă. O echipă .NET care alege Flutter doar pentru că e popular va petrece primele luni învățând Dart, Flutter și ecosistemul lui, în loc să livreze.
• Migrarea de pe Xamarin amânată. Fiecare lună de amânare scurtează perioada în care încă mai poți publica actualizări fără o criză.

Recapitulare

• Nativ oferă cea mai bună experiență și acces imediat la platformă, cu prețul a două baze de cod. Kotlin Multiplatform reduce dublarea, fără să renunțe la UI-ul nativ.
• Flutter oferă o interfață identică peste tot și o productivitate excelentă, cu Dart și propriul motor de randare.
• React Native e drumul natural pentru echipele React, iar cu noua arhitectură și Expo e mult mai matur decât acum câțiva ani.
• .NET MAUI e alegerea firească pentru echipele .NET și singura care aduce componentele Blazor pe telefon, dar ecosistemul e mai mic și reputația, mixtă.
• PWA e opțiunea pe care merită s-o verifici prima. Pe Android e excelentă, iar pe iOS are limite clare.
• Costurile ascunse (review, actualizări anuale obligatorii, versiuni vechi în producție) contează mai mult decât alegerea framework-ului.

În ultimul articol din serie punem totul cap la cap și răspundem la întrebarea cea mai grea: cât cod poți împărți, de fapt, între web, desktop și mobil? Comparăm .NET MAUI, Avalonia, Uno, Flutter, Compose Multiplatform și React Native pe același scenariu, vedem ce se împarte ușor și ce nu, iar la final construim un tabel de decizie pentru toată seria.