NativeWind vs Tamagui vs Unistyles 3 (…

Aggiornato: 20 Giugno 2026

Nel 2026 le tre librerie di styling che dominano la conversazione React Native sono NativeWind v4, Tamagui e Unistyles 3. La scelta non e' una questione di performance (i benchmark le mettono tutte sotto i 3ms di overhead per render), ma di filosofia del team, modello mentale e target di piattaforme. Se vieni dal web e ami Tailwind, NativeWind. Se costruisci un design system universale web + mobile, Tamagui. Se hai un'app native-first sulla Nuova Architettura e vuoi controllo a basso livello con un core in C++, Unistyles 3. Sotto trovi la comparazione completa, con codice eseguibile e i criteri che applico io quando avvio un nuovo progetto.

NativeWind v4 compila le classi Tailwind a build time e ha endorsement ufficiale di Expo: e' la scelta default per team che vengono dal web.
Tamagui include un compilatore ottimizzante che estrae stili e oggetti a build time, piu' una libreria di componenti universali. Vince quando devi spedire web + iOS + Android dallo stesso codebase.
Unistyles 3 (versione corrente 3.2.5, giugno 2026) richiede React Native 0.78+ e la Nuova Architettura: usa Fabric e un core C++ per skippare il bridge.
StyleSheet built-in resta la scelta zero-dipendenze piu' veloce a runtime, ma non offre theming, breakpoint ne' dark mode.
Le performance differenziano poco. Scegli in base a team, design system e supporto cross-platform richiesto.
Tutte e tre supportano la Nuova Architettura (Fabric). Unistyles 3 la richiede, le altre due la consigliano.

Tabella comparativa: NativeWind vs Tamagui vs Unistyles

Prima di entrare nei dettagli, ecco la tabella che uso io nelle code review architetturali quando un team mi chiede "quale prendiamo?". I valori riflettono lo stato a giugno 2026 con le versioni stabili attuali.

Caratteristica	NativeWind v4	Tamagui	Unistyles 3
Modello mentale	Classi Tailwind	Componenti tipizzati + token	StyleSheet con superpoteri
Compilazione	Build time (Babel + Metro)	Build time (Tamagui compiler)	Runtime + core C++/JSI
Supporto web	Si' (via react-native-web)	Si', di prima classe	Si' (parser CSS custom)
Nuova Architettura	Compatibile	Compatibile	Richiesta (Fabric obbligatorio)
React Native minimo	0.72+	0.74+	0.78+
Componenti pre-fatti	No (solo utility)	Si' (Button, Stack, Sheet...)	No (solo styling)
Dark mode / theming	Si' (CSS variables)	Si' (token + themes)	Si' (runtime themes)
Endorsement ufficiale	Expo	Nessuno	Nessuno
Download settimanali npm	~518k	~91k	~69k
Curva di apprendimento	Bassa (se conosci Tailwind)	Alta (tanti concetti)	Media

I numeri di download arrivano da npm trends al confronto delle cinque librerie. NativeWind ha l'effetto rete piu' forte; Tamagui ha piu' stelle GitHub (13.5k vs 7.5k vs 2.7k) ma adozione inferiore. Segno che e' amato dai team che lo usano, ma con una barriera d'ingresso piu' alta.

NativeWind v4: Tailwind nativo con compilatore

NativeWind v4, mantenuto da Mark Lawlor, e' stato una riscrittura architetturale rispetto a v2. Il parsing delle classi e' passato da runtime a build time, ed e' qui che si gioca la performance. Le classi className diventano oggetti StyleSheet ottimizzati durante la build, quindi a runtime React Native non fa nessun lavoro extra. Il flusso e' familiare a chiunque venga dal web: configuri tailwind.config.js, importi nativewind nel tuo entry point e scrivi className. Il preset Expo lo configura per te in una riga, ed e' il motivo per cui Expo lo raccomanda nella propria documentazione.

// app.tsx
import { View, Text, Pressable } from "react-native";
import "./global.css"; // import Tailwind

export default function Card({ title, onPress }: { title: string; onPress: () => void }) {
  return (
    <Pressable
      onPress={onPress}
      className="bg-white dark:bg-zinc-900 rounded-2xl p-4 shadow-md active:opacity-80"
    >
      <Text className="text-lg font-semibold text-zinc-900 dark:text-zinc-50">
        {title}
      </Text>
      <Text className="text-sm text-zinc-500 mt-1">
        Tocca per aprire
      </Text>
    </Pressable>
  );
}

NativeWind v4 ha aggiunto CSS variables, animazioni con keyframe e una gestione dark mode che riflette quella di Tailwind 3+. Per il dark mode hai due opzioni: media query (prefers-color-scheme) o classe (class mode con un provider). Io uso class mode perche' lascia all'utente la scelta indipendente dal sistema. Un pattern che ho visto chiedere in ogni app consumer negli ultimi tre anni, francamente.

Limiti reali che ho incontrato in produzione. Gli stili dinamici basati su props (es. className={`bg-${color}-500`}) non funzionano, perche' il compilatore deve conoscere le classi a build time. La soluzione e' cva (class-variance-authority) o una mappa esplicita. E' lo stesso problema che hai con Tailwind sul web, ma su mobile fa piu' male perche' le animazioni interpolanti chiedono spesso valori intermedi. Ho perso mezza giornata su questo nel mio ultimo progetto, vale la pena saperlo in anticipo.

Tamagui: design system universale con compilatore ottimizzante

Tamagui non e' solo styling. E' un design system completo con componenti pre-fatti (Button, Stack, Sheet, Dialog), un sistema di token, theming nidificato e, soprattutto, un compilatore ottimizzante che a build time hoista oggetti, estrae CSS statico per il web e dedupe i nodi. E' la libreria che usi quando il tuo target e' web + iOS + Android dallo stesso albero di componenti.

La forza di Tamagui sta nel cross-platform reale: lo stesso <Stack> genera div con CSS atomico sul web e View con StyleSheet su native. Per chi viene da React Native Paper o Gluestack la differenza chiave e' l'estrazione statica: il compilatore Tamagui puo' convertire una prop dinamica in una classe CSS statica quando il valore e' deducibile, eliminando completamente il lavoro a runtime.

// Button.tsx
import { Button, Stack, Text, styled } from "tamagui";

const PrimaryButton = styled(Button, {
  backgroundColor: "$blue10",
  color: "white",
  borderRadius: "$4",
  pressStyle: { backgroundColor: "$blue11", scale: 0.98 },
  variants: {
    size: {
      sm: { paddingHorizontal: "$3", height: 36 },
      md: { paddingHorizontal: "$4", height: 44 },
      lg: { paddingHorizontal: "$5", height: 52 },
    },
  } as const,
  defaultVariants: { size: "md" },
});

export default function CTA() {
  return (
    <Stack padding="$4" gap="$3">
      <Text fontSize="$6" fontWeight="700">Inizia gratis</Text>
      <PrimaryButton size="lg">Crea il tuo account</PrimaryButton>
    </Stack>
  );
}

Il prezzo da pagare e' la complessita'. Tamagui ha tanti concetti: token, themes, variants, media query, shorthands, pseudo styles. Per un'app piccola e' overkill. Per un design system condiviso tra tre piattaforme con un team di otto persone e' una manna. Il consiglio che do sempre: se non hai un design system documentato in Figma con token gia' definiti, l'investment in Tamagui e' prematuro.

Unistyles 3: C++, Fabric e zero hook

Unistyles 3.0, rilasciato nel 2025 da Jacek Pudysz, e' la libreria di styling piu' interessante architetturalmente del 2026. E' l'unica sul mercato che usa codice nativo e C++ per costruire una rappresentazione completa degli stili lato C++, leggendo dipendenze e attaccando aggiornamenti direttamente ai componenti Fabric. Il risultato: zero hook React, zero re-render quando cambi tema o orientamento.

Il requisito non negoziabile e' la Nuova Architettura. Fabric obbligatorio, React Native 0.78 minimo. Se la tua app e' ancora sull'old architecture, Unistyles 3 non parte. Per chi ha completato la migrazione (e a meta' 2026 dovrebbe averla fatta) e' il pagamento finale che ti ripaga in performance.

// unistyles.ts
import { StyleSheet } from "react-native-unistyles";

const lightTheme = {
  colors: { background: "#ffffff", text: "#0f172a", primary: "#3b82f6" },
  spacing: (n: number) => n * 4,
} as const;

const darkTheme = {
  colors: { background: "#0f172a", text: "#f8fafc", primary: "#60a5fa" },
  spacing: (n: number) => n * 4,
} as const;

StyleSheet.configure({
  themes: { light: lightTheme, dark: darkTheme },
  settings: { adaptiveThemes: true },
});

// Card.tsx
import { View, Text } from "react-native";
import { StyleSheet } from "react-native-unistyles";

export default function Card({ title }: { title: string }) {
  return (
    <View style={styles.card}>
      <Text style={styles.title}>{title}</Text>
    </View>
  );
}

const styles = StyleSheet.create((theme) => ({
  card: {
    backgroundColor: theme.colors.background,
    padding: theme.spacing(4),
    borderRadius: 16,
  },
  title: { color: theme.colors.text, fontSize: 18, fontWeight: "600" },
}));

La sintassi e' quasi indistinguibile da StyleSheet built-in, ed e' proprio il punto. Migri da StyleSheet a Unistyles in un pomeriggio per file. La differenza e' che il C++ engine aggiorna automaticamente gli stili quando cambi tema, runtime, orientamento o breakpoint, senza far ri-renderizzare l'albero React. Se hai mai profilato un cambio tema con un context provider e visto la flame chart accendersi, capisci l'appeal.

Per i dettagli del motore C++ e dell'integrazione con Fabric, consulta direttamente la documentazione ufficiale di Unistyles 3. Spiega come Unistyles ottiene il "view tree" da Fabric e attacca aggiornamenti incrementali. Se vuoi vedere il roadmap e i release piu' recenti, le release notes su GitHub sono aggiornate al rilascio 3.2.5.

Qual e' la migliore libreria di styling per React Native?

Risposta onesta da lead engineer: non esiste una migliore libreria in assoluto. Esistono scelte migliori per contesto. Detto questo, se devo dare una raccomandazione default per un nuovo progetto a giugno 2026, parto da NativeWind v4. Le ragioni sono pragmatiche piu' che tecniche:

Velocita' di onboarding: il 70% degli sviluppatori frontend conosce gia' Tailwind. Risparmi due settimane di training.
Endorsement Expo: significa template ufficiali, documentazione integrata e un ciclo di feedback aperto con il team Expo.
Compatibilita' retroattiva: funziona con la vecchia architettura, quindi non blocca la migrazione.
Ecosistema: quasi tutti i template Expo (with-router, with-tailwindcss, with-state) ti danno NativeWind pre-configurato.

Cambio default se: target principale e' web cross-platform (Tamagui), oppure ho un team senior che vuole il massimo della performance e ha gia' completato la migrazione alla Nuova Architettura React Native con JSI e Fabric (Unistyles 3).

Performance e benchmark: cosa dicono i numeri

I benchmark indipendenti piu' recenti, come quelli pubblicati nel react-native-style-libraries-benchmark di efstathiosntonas, mostrano un quadro consistente: NativeWind v4, Tamagui (compilato) e Unistyles 3 finiscono entro il 5% di StyleSheet built-in su iPhone 15 Pro per render iniziali e re-render. Le librerie runtime-based come twrnc hanno un overhead 5-10x piu' alto, ma rimangono comunque sotto i 15ms per render. Irrilevante per UI standard.

Dove i numeri iniziano a divergere e' nei cambi tema runtime e nelle liste lunghe. Unistyles 3 brilla in entrambi i casi grazie al motore C++ che evita re-render React. Tamagui ha overhead leggermente piu' alto per via dei suoi componenti, ma compensa con CSS atomico estratto sul web. NativeWind si comporta come StyleSheet, perche' diventa StyleSheet a build time.

Se le tue liste sono il collo di bottiglia, abbinare una di queste librerie a FlashList v2 o Legend List per liste performanti conta molto piu' della scelta della libreria di styling. Profila prima, ottimizza poi.

Bundle size: il fattore meno discusso

Il bundle JavaScript e' dove Tamagui paga di piu'. La libreria completa con tutti i componenti aggiunge circa 120 KB minified+gzipped. NativeWind v4 aggiunge circa 25 KB, Unistyles 3 circa 40 KB (piu' i moduli nativi). Per app B2B questa differenza non sposta nulla. Per app consumer con startup budget aggressivi, e' un argomento reale. In contesti retail e media, dove il primo render conta in secondi, ho visto progetti scartare Tamagui solo per questo.

StyleSheet built-in: quando ha ancora senso

Vale la pena ricordare che StyleSheet built-in di React Native non e' obsoleto. E' ancora la scelta corretta quando:

Stai costruendo una libreria di componenti riutilizzabile che non vuole forzare una dipendenza sui consumer.
L'app e' piccola (meno di 30 schermate) e non hai theming ne' dark mode complessi.
Stai lavorando su un fork di React Native (es. Windows, macOS) dove le librerie sopra non sono supportate.
Hai un memory budget strettissimo (kiosk, embedded) e ogni KB di JS conta.

Lo combino sempre con un piccolo helper di theming custom, una trentina di righe, quando non voglio dipendenze. Per il resto, ammetto che e' raro che parta da StyleSheet pure in un nuovo progetto consumer nel 2026. Le funzionalita' che ti perdi (dark mode reattivo, breakpoint dichiarativi, theming nidificato) sono ormai requisiti, non lussi.

Come scelgo io: criteri pratici per il 2026

Ecco la flowchart mentale che applico in pre-progetto. Sei domande in cinque minuti, e in genere arrivo a una raccomandazione difendibile.

L'app deve girare anche su web come prima classe? Se si', Tamagui vince di gran lunga sul rendering web.
Il team conosce Tailwind? Se si' e la risposta a 1 e' no, NativeWind v4 e' la scelta a minor attrito.
Sei sulla Nuova Architettura (RN 0.78+) e ti importa il render zero-cost su cambio tema? Se si', Unistyles 3.
Devi spedire una libreria distribuita ad altri team? StyleSheet built-in, niente dipendenze esterne.
Hai bisogno di componenti pronti (Button, Sheet, Dialog) out of the box? Tamagui, gli altri due sono solo styling.
Stai migrando da CSS-in-JS web? NativeWind se vieni da Tailwind, Unistyles se vieni da styled-components.

Onestamente? Sei delle ultime app che ho spedito hanno usato NativeWind per quattro progetti, Tamagui per una (era cross-platform pesante con Next.js + Expo) e Unistyles per una (app finanziaria con dark mode dinamico e cambio tema basato su orario). Tutte e sei sulla Nuova Architettura. Quando il team che mi consulta non ha vincoli forti, parto da NativeWind e cambio solo se la prima settimana mostra resistenza chiara.

Migrazione tra librerie: cosa aspettarsi

Le migrazioni piu' dolorose che ho fatto, con stime reali misurate su codebase tra 80 e 150 componenti:

Da styled-components/RN a NativeWind. Facile, perche' entrambi pensano per componenti. Lo script di trasformazione open source jscodeshift piu' un po' di lavoro a mano: stima 1 settimana per 100 componenti.

Da NativeWind a Tamagui. Piu' lunga, perche' Tamagui ti spinge a riorganizzare il design system in token. La parte ostica non e' la sintassi, ma il refactor concettuale. Stima 3 settimane per 100 componenti, piu' Figma sync con il team design.

Da StyleSheet a Unistyles 3. Quasi trasparente, sintassi simile. Devi solo configurare i temi una volta. Stima 2-3 giorni per 100 componenti, e il diff e' minuscolo da reviewer.

Per le animazioni avanzate ricorda che la libreria di styling e' ortogonale alla libreria di animazione. Tutte e tre giocano bene con Reanimated 4 e le sue API CSS-like, quindi non c'e' lock-in incrociato tra le scelte.

Domande frequenti

NativeWind e' meglio di StyleSheet?

Dipende dal team. A livello di runtime, NativeWind v4 diventa StyleSheet a build time, quindi le performance sono praticamente identiche. NativeWind vince in DX se conosci Tailwind e in funzionalita' integrate (theming, dark mode, breakpoint). StyleSheet vince in zero-dipendenze.

Tamagui funziona con la Nuova Architettura di React Native?

Si', Tamagui e' completamente compatibile con Fabric e la Nuova Architettura a partire dalle versioni rilasciate nel 2024. Non la richiede come Unistyles 3, ma ne beneficia. Verifica la compatibilita' della tua versione esatta sulla documentazione ufficiale.

Posso usare Tailwind CSS direttamente in React Native?

Non direttamente: Tailwind genera CSS, e React Native non interpreta CSS standard. Servono librerie ponte come NativeWind (compilatore Babel) o twrnc (parser runtime). NativeWind v4 e' la soluzione raccomandata da Expo e la piu' matura nel 2026.

Cosa cambia in Unistyles 3 rispetto a Unistyles 2?

Unistyles 3 e' una riscrittura con core C++/JSI integrata con Fabric. Elimina gli hook React per aggiornare gli stili, supporta cambi tema senza re-render e richiede la Nuova Architettura. Unistyles 2 rimane mantenuto per chi non puo' migrare.

Quale libreria di styling e' piu' veloce in React Native?

Sui render iniziali, tutte e tre (NativeWind v4, Tamagui compilato, Unistyles 3) sono entro il 5% di StyleSheet built-in: la differenza e' impercettibile. Sui cambi tema runtime e sulle liste lunghe Unistyles 3 vince grazie al motore C++ che evita re-render React.