NativeWind: Tailwind CSS su React Native

Se lavori con Tailwind CSS sul web e ti trovi a costruire un'app React Native, NativeWind è la prima cosa che cerchi. La promessa è semplice: stessa API, stessa sintassi, stesso modello mentale. Scrivi className="flex-1 bg-gray-900 p-4" invece di style={{ flex: 1, backgroundColor: '#111827', padding: 16 }}.

L'ho usato per ReD Sposi dall'inizio, e nel complesso la promessa regge. Ma ci sono differenze importanti che vale la pena conoscere prima di assumere che "è Tailwind su mobile".

Come funziona sotto il cofano

React Native non ha un DOM e non usa CSS. Lo styling avviene tramite la StyleSheet API di React Native, che accetta un sottoinsieme di proprietà CSS con alcune differenze semantiche.

NativeWind v4 — la versione attuale, compatibile con Tailwind v3 e v4 — funziona in due modi: compile-time e runtime. Durante il build, le classi vengono analizzate e convertite in stili React Native; a runtime, le classi dinamiche vengono risolte tramite un piccolo engine CSS-in-JS.

Il risultato per lo sviluppatore è che puoi scrivere className direttamente sui componenti di React Native:

<View className="flex-1 items-center justify-center bg-zinc-950">
  <Text className="text-white text-lg font-semibold">Ciao</Text>
</View>

Non c'è nessun StyleSheet.create, nessun oggetto stile, nessun inline style per la maggior parte dei casi. È una riduzione di rumore significativa.

Dove funziona bene

Il layout con flexbox è dove NativeWind brilla di più, perché React Native usa flexbox come sistema di layout nativo — e il mapping da classi Tailwind a proprietà React Native è quasi perfetto.

<View className="flex-row items-center gap-3 px-4 py-3">
  <Image className="w-10 h-10 rounded-full" source={...} />
  <Text className="flex-1 text-white">{name}</Text>
</View>

Colori, tipografia, spaziatura — tutto funziona come ti aspetti. Le varianti responsive esistono ma hanno un significato diverso su mobile (non si basano sulla viewport width nello stesso modo), ed è meglio non usarle come faresti sul web.

Le classi condizionali con clsx o cn funzionano come sul web:

<TouchableOpacity
  className={cn(
    "px-4 py-2 rounded-lg",
    isActive ? "bg-blue-600" : "bg-zinc-800"
  )}
>

Dove si sente la differenza

Non tutte le classi CSS esistono. Alcune proprietà CSS non hanno un equivalente in React Native — display: grid, position: fixed, overflow: scroll nel senso web. NativeWind non le supporta semplicemente perché React Native non le supporta.

I valori arbitrari sono più limitati. Su web puoi scrivere w-[342px] liberamente. Su React Native funziona in molti casi, ma ci sono proprietà dove le unità o i valori non si comportano come atteso — ad esempio le percentuali in certi contesti di layout annidato.

shadow-* funziona diversamente. Le ombre su iOS e Android hanno API diverse, e le classi shadow-* di NativeWind cercano di astrarlo, ma il risultato visivo non è identico tra le piattaforme. Per ombre precise, spesso finisco comunque con uno stile inline.

I dark mode tokens. NativeWind supporta dark: prefix, ma richiede configurazione esplicita per usare il sistema di color scheme del dispositivo. Non è complicato, ma non è automatico come sul web.

Il vero vantaggio: il costo cognitivo tra web e mobile

Il beneficio principale di NativeWind non è scrivere meno codice. È che lavoro con lo stesso vocabolario su web e mobile.

Per ReD Sposi, ho tre app che si guardano: l'app mobile Expo, il pannello admin Vite, e la landing Next.js. Tutte e tre usano Tailwind o NativeWind. Quando cambio contesto tra un'app e l'altra, non cambio sintassi di styling. bg-zinc-950, text-white, rounded-lg significano la stessa cosa ovunque.

Questo abbassa il costo cognitivo del context switching. Non risolve tutto — React Native e il browser hanno differenze fondamentali che nessuna libreria di styling può nascondere — ma la parte visuale e strutturale del lavoro diventa molto più fluida.

Vale la pena rispetto agli stili inline?

Per un progetto nuovo con Tailwind già in testa: sì, inequivocabilmente.

Per un progetto esistente con StyleSheet.create già in uso: dipende dalla quantità di codice e dalla disponibilità a migrare gradualmente. NativeWind può coesistere con gli stili esistenti, quindi la migrazione è possibile in modo incrementale.

Per un team che non conosce Tailwind: probabilmente no. NativeWind ha senso se porti già il modello mentale di Tailwind — senza quello, è un'astrazione in più da imparare senza il vantaggio della familiarità.

Nel mio caso, è stata la scelta giusta dall'inizio, e non sono tornato indietro.