Cos'è React Native e cosa significa davvero 'nativo'

Sai già usare React, qualcuno ti ha detto che "con React Native fai le app con le stesse competenze", e alla prima schermata scopri che non puoi usare un div, che il CSS non esiste e che il tuo componente preferito del sito non compila. Allora cosa si riusa davvero? E perché si chiama "nativo" se scrivi JavaScript? In questo articolo trovi le due risposte, che sono collegate.

Cos'è React Native

React Native è un framework open source creato da Meta che ti fa scrivere app per iOS e Android in JavaScript o TypeScript usando il modello di React, ma che a schermo mostra i componenti nativi veri della piattaforma, non una pagina web e non un'imitazione disegnata a mano.

Se stai ancora valutando l'approccio generale — nativo, cross-platform o PWA — parti da come scegliere la tecnologia per un'app mobile. Se sei già al bivio con Flutter, il confronto sintetico è in React Native o Flutter. Qui invece guardiamo come funziona dentro.

Cosa significa "nativo" qui

La parola "nativo" crea equivoci, quindi partiamo da cosa non è.

• Non è una WebView. L'app non apre un browser nascosto che mostra HTML. Quello è l'approccio di Capacitor.
• Non disegna i pixel da sé. Quello è l'approccio di Flutter, che imita i controlli di sistema con il proprio motore.
• Non compila il tuo JavaScript in Swift o Kotlin. Il tuo codice resta JavaScript e gira in un motore JavaScript dentro l'app (di norma Hermes, sviluppato apposta per React Native).

Quello che succede è questo: quando scrivi <Text> o <TextInput>, React Native crea il vero componente di testo o il vero campo di input di iOS o di Android. La tastiera, la selezione del testo, lo scorrimento, l'accessibilità sono quelli del sistema, perché è il sistema a gestirli.

La conseguenza pratica è che l'app si comporta come un'app della piattaforma senza sforzo: su iOS lo scorrimento ha il rimbalzo di iOS, su Android quello di Android. E quando Apple o Google aggiornano l'aspetto dei loro controlli, l'app tende a seguirli, perché usa i loro componenti.

Il rovescio: le due piattaforme non sono identiche, e a volte lo stesso codice produce risultati leggermente diversi. Per questo esistono Platform.OS e i file .ios.tsx / .android.tsx per differenziare dove serve.

Il ponte tra JavaScript e nativo

Se il tuo codice è JavaScript e i componenti sono nativi, deve esistere qualcosa che li collega. È il pezzo più importante da capire.

Il vecchio modello: il bridge

Per anni React Native ha funzionato con un bridge asincrono: il mondo JavaScript e il mondo nativo si scambiavano messaggi serializzati in JSON, in coda, senza potersi chiamare direttamente. Funzionava, ma aveva un collo di bottiglia evidente: ogni interazione — un gesto, un aggiornamento di layout, una lettura da un modulo nativo — pagava il costo di serializzare, accodare e deserializzare.

Nella pratica si traduceva in liste che "scattavano" durante lo scorrimento veloce, animazioni legate ai gesti poco fluide, e l'impossibilità di fare chiamate sincrone al codice nativo anche quando sarebbero state naturali.

La nuova architettura

La nuova architettura ha sostituito quel modello con tre pezzi che vale la pena saper nominare:

Componente	Cosa fa
JSI (JavaScript Interface)	Permette al JavaScript di tenere riferimenti diretti a oggetti nativi e chiamarli, anche in modo sincrono, senza passare da messaggi JSON
Fabric	Il nuovo sistema di rendering, che usa JSI per aggiornare l'interfaccia nativa in modo più diretto e prevedibile
TurboModules	Il nuovo modo di scrivere moduli nativi, caricati solo quando servono e chiamabili direttamente tramite JSI

Non devi conoscerli nel dettaglio per scrivere un'app: se usi componenti e librerie aggiornate, ci lavorano sotto senza che tu li veda. Ti serve sapere che il collo di bottiglia del bridge asincrono non è più il modello di riferimento, quindi molte critiche storiche sulle prestazioni di React Native che trovi online si riferiscono a un'architettura superata. Per i dettagli delle singole versioni, vedi le note di rilascio ufficiali.

Cosa riusi dal web (e cosa no)

Questa è la parte che delude chi arriva dallo sviluppo web con aspettative sbagliate.

Cosa riusi davvero:

• Il linguaggio. JavaScript o TypeScript, con tutti gli strumenti che conosci.
• Il modello mentale di React. Componenti, props, stato, hook come useState e useEffect: identici.
• La logica. Validazione, chiamate alle API, gestione dello stato globale, formattazione dei dati: se è scritta senza dipendere dal browser, la condividi tra sito e app.
• Buona parte delle librerie JavaScript che non toccano il DOM.

Cosa non riusi:

• Niente HTML. Non esistono div, span, p, img. Esistono View, Text, Image, Pressable.
• Niente CSS. Gli stili si scrivono in oggetti JavaScript con StyleSheet. La sintassi ricorda il CSS, il layout usa Flexbox, ma non ci sono selettori, cascata, media query classiche o file .css.
• Niente DOM. Qualsiasi libreria che manipola document o window non funziona.
• Il testo va sempre dentro <Text>. Una stringa lasciata dentro una View è un errore.

import { View, Text, Pressable, StyleSheet } from "react-native";

export function SchedaProdotto({ nome, prezzo, onAggiungi }: Props) {
  return (
    <View style={styles.card}>
      <Text style={styles.titolo}>{nome}</Text>
      <Text>{prezzo}</Text>
      <Pressable style={styles.bottone} onPress={onAggiungi}>
        <Text style={styles.testoBottone}>Aggiungi</Text>
      </Pressable>
    </View>
  );
}

const styles = StyleSheet.create({
  card: { padding: 16, borderRadius: 12, backgroundColor: "#fff" },
  titolo: { fontSize: 18, fontWeight: "600", marginBottom: 8 },
  bottone: { marginTop: 12, padding: 12, backgroundColor: "#2563eb", borderRadius: 8 },
  testoBottone: { color: "#fff", textAlign: "center" },
});

Chi conosce React legge questo codice senza difficoltà. Ma non è codice che puoi incollare da un sito: è React con altri mattoni.

Expo: il modo consigliato di partire oggi

Se inizi un progetto React Native da zero, la documentazione ufficiale oggi suggerisce di farlo con un framework, e quello di riferimento è Expo.

Expo è una piattaforma costruita sopra React Native che ti dà un insieme di strumenti e librerie pronte per le cose che ogni app deve fare.

npx create-expo-app@latest mia-app
cd mia-app
npx expo start

Cosa ti evita, concretamente:

• Configurare Xcode e Android Studio il primo giorno. Puoi partire provando l'app sul tuo telefono con l'app Expo Go, o con una build di sviluppo.
• Scrivere moduli nativi per le funzioni comuni. Fotocamera, notifiche, file, posizione, autenticazione: esistono librerie expo-* mantenute e documentate.
• Gestire a mano i progetti nativi. Con il prebuild Expo genera le cartelle iOS e Android dalla configurazione, e i config plugin modificano quei progetti in modo ripetibile invece che con ritocchi manuali.
• La navigazione. Expo Router organizza le schermate in base ai file, in modo simile a come fanno i framework web.

Poi c'è EAS (Expo Application Services), il servizio cloud per le build e la distribuzione: compila l'app per iOS anche se non hai un Mac, gestisce certificati e profili di firma, invia le build agli store e permette di distribuire aggiornamenti del solo codice JavaScript senza passare da una nuova revisione, entro le regole degli store. I piani e i limiti del servizio cambiano: verifica alla fonte.

Per la pubblicazione vera e propria, i passaggi sono in come pubblicare un'app sull'App Store; per Android il percorso passa invece dalla Google Play Console.

Il punto onesto: prima o poi tocchi il nativo

React Native copre la grande maggioranza delle esigenze di un'app tipica. Ma quando ti serve una funzione del dispositivo che nessuna libreria espone — un SDK proprietario di un produttore, un'API di sistema appena uscita, un'integrazione hardware particolare — devi scrivere un modulo nativo. In Swift per iOS e in Kotlin per Android.

Non è un dramma: sono spesso poche decine di righe, ed Expo ha strumenti per scriverli in modo ordinato. Ma significa che "solo JavaScript" è vero per la maggior parte del lavoro, non per tutto. Se il tuo team non ha nessuno disposto a leggere Swift o Kotlin, tienilo presente prima di impegnarti.

Lo stesso vale per il debugging: quando un problema nasce nel progetto nativo — una build che fallisce, un permesso configurato male, una dipendenza nativa in conflitto — i messaggi di errore arrivano da Xcode o da Gradle, non da JavaScript.

Errori comuni

Aspettarsi di copiare il codice di un sito React. La logica sì, l'interfaccia no. Progetta da subito separando la logica condivisibile dai componenti visivi.

Renderizzare liste lunghe con map dentro una ScrollView. Funziona con venti elementi, crolla con duemila: tutti gli elementi vengono creati subito, anche quelli fuori schermo. Per le liste usa FlatList o SectionList, che creano solo ciò che è visibile, oppure librerie alternative come FlashList per i casi più esigenti. E fornisci sempre una keyExtractor stabile.

Testare solo sul simulatore. Il simulatore gira sul processore del tuo computer, molto più potente di un telefono medio. Animazioni, scorrimento e tempi di avvio vanno verificati su dispositivi reali, possibilmente anche su un Android di fascia bassa. Per iOS, la distribuzione ai tester passa da TestFlight.

Valutare le prestazioni in modalità debug. In sviluppo l'app è molto più lenta che in produzione. Prima di concludere che "React Native è lento", prova una build di release.

Usare librerie abbandonate. L'ecosistema è enorme ma disomogeneo. Prima di aggiungere una dipendenza con parti native, controlla che sia mantenuta e compatibile con la nuova architettura.

In sintesi

React Native ti fa scrivere in JavaScript ma mostra componenti nativi veri. È questo il significato di "nativo": non il linguaggio, ma quello che l'utente vede e tocca, che è l'interfaccia del sistema.

La nuova architettura ha tolto il collo di bottiglia storico. JSI, Fabric e TurboModules hanno sostituito il bridge asincrono, e molte critiche sulle prestazioni che circolano online si riferiscono al modello precedente.

Dal web riusi linguaggio, React e logica, non l'interfaccia. Niente HTML, niente CSS, niente DOM: le competenze si trasferiscono, il codice visivo va riscritto.

Expo è il punto di partenza sensato, ma il nativo non sparisce del tutto. Ti evita la maggior parte della configurazione e con EAS risolve build e distribuzione, però per le funzioni non coperte da librerie servirà comunque qualcuno che sappia mettere le mani su Swift e Kotlin.

Se vuoi solide basi di JavaScript e React prima di passare al mobile, trovi i percorsi nei corsi. Se invece hai un'app da sviluppare e vuoi valutare se React Native è la scelta giusta, puoi guardare i miei servizi.