React Native 0.85 nel 2026: Nuovo Animation Backend, API TypeScript Strict e Domande da Colloquio

React Native 0.85 rappresenta un punto di svolta significativo nell'evoluzione del framework mobile di Meta. Rilasciata nella prima metà del 2026, questa versione introduce cambiamenti architetturali profondi che ridefiniscono il modo in cui le animazioni vengono gestite, il sistema di tipi viene applicato e le applicazioni comunicano con il livello nativo. Non si tratta di un semplice aggiornamento incrementale: la 0.85 consolida anni di lavoro sulla New Architecture e porta a maturazione concetti che erano rimasti sperimentali nelle versioni precedenti.

Per gli sviluppatori che lavorano quotidianamente con React Native, questa release richiede attenzione particolare. Le breaking change sono contenute ma impattanti, il nuovo backend di animazione cambia le regole del gioco sulle performance, e la modalità Strict TypeScript API impone un rigore che molti team troveranno inizialmente scomodo ma, nel lungo periodo, estremamente vantaggioso.

Shared Animation Backend: la fine della frammentazione

Una delle novità più attese della versione 0.85 è lo Shared Animation Backend, un motore di animazione unificato che fonde le capacità di Animated e react-native-reanimated in un unico sistema nativo. Fino alla versione 0.84, gli sviluppatori dovevano scegliere tra la API Animated integrata — limitata nelle proprietà supportate dal driver nativo — e la libreria Reanimated, più potente ma esterna e con un proprio overhead di integrazione.

Con il nuovo backend, useNativeDriver: true supporta finalmente le proprietà di layout come width, height, margin e padding. Questo era uno dei limiti storici più frustranti della API Animated originale, che costringeva gli sviluppatori a ricorrere a workaround con transform o a installare Reanimated anche per animazioni relativamente semplici.

import { Animated, Pressable, View, StyleSheet } from 'react-native';
import { useRef, useState } from 'react';

function ExpandableCard() {
  const widthAnim = useRef(new Animated.Value(120)).current;
  const heightAnim = useRef(new Animated.Value(80)).current;
  const [expanded, setExpanded] = useState(false);

  const toggle = () => {
    const toWidth = expanded ? 120 : 300;
    const toHeight = expanded ? 80 : 200;

    // Layout props with useNativeDriver — new in 0.85
    Animated.parallel([
      Animated.spring(widthAnim, {
        toValue: toWidth,
        useNativeDriver: true, // Now supports layout props
      }),
      Animated.spring(heightAnim, {
        toValue: toHeight,
        useNativeDriver: true,
      }),
    ]).start();

    setExpanded(!expanded);
  };

  return (
    <Pressable onPress={toggle}>
      <Animated.View
        style={[
          styles.card,
          { width: widthAnim, height: heightAnim },
        ]}
      />
    </Pressable>
  );
}

const styles = StyleSheet.create({
  card: {
    backgroundColor: '#61DAFB',
    borderRadius: 8,
  },
});

Il risultato pratico è immediato: animazioni di layout che girano a 60fps costanti senza passare dal thread JavaScript, eliminando i jank visibili soprattutto su dispositivi Android di fascia media.

Come funziona internamente il nuovo backend

Il cuore tecnico dello Shared Animation Backend si basa su un sistema a doppio percorso di aggiornamento. Quando un'animazione viene avviata con useNativeDriver: true, il framework valuta la natura delle proprietà animate e seleziona automaticamente il percorso ottimale.

Per le proprietà di trasformazione (opacity, transform, scale), il percorso rimane quello classico: aggiornamenti diretti al livello di rendering nativo senza coinvolgere il layout engine. Per le proprietà di layout (width, height, margin), il nuovo backend utilizza un meccanismo di layout incrementale che ricalcola solo il sottoalbero interessato, evitando il costo di un layout pass completo.

Questa architettura a doppio percorso è resa possibile dall'integrazione profonda con Fabric, il renderer moderno di React Native. Fabric espone API C++ che permettono al backend di animazione di richiedere aggiornamenti di layout parziali, qualcosa che il vecchio renderer non supportava.

Architettura Post-Bridge: JSI e TurboModules

La versione 0.85 segna la definitiva maturazione dell'architettura post-bridge. Il vecchio bridge JavaScript-nativo, basato sulla serializzazione JSON asincrona, è stato rimosso completamente. Tutte le comunicazioni passano ora attraverso JSI (JavaScript Interface), un layer C++ che consente chiamate sincrone e dirette tra JavaScript e il codice nativo.

La novità più rilevante in questa release è il lazy-loading predefinito dei TurboModules. Nelle versioni precedenti, tutti i moduli nativi venivano inizializzati all'avvio dell'applicazione, contribuendo a tempi di cold-start elevati. Con la 0.85, i TurboModules vengono caricati solo al primo accesso effettivo, con una riduzione della memoria iniziale stimata intorno al 40%.

// TurboModules now lazy-load by default in 0.85
// Cold-start memory reduced by ~40%
import { TurboModuleRegistry } from 'react-native';

// Module loads only when first accessed, not at app startup
const CameraModule = TurboModuleRegistry.getEnforcing('Camera');

// Direct synchronous call via JSI — no bridge serialization
const hasPermission = CameraModule.checkPermission();

Questo approccio migliora sensibilmente l'esperienza utente nei primi secondi dopo l'apertura dell'app, un fattore critico per la retention e per le metriche di performance monitorate dagli app store.

Supporto TLS in Metro

Una novità che interessa particolarmente gli ambienti enterprise è il supporto nativo per TLS in Metro, il bundler di React Native. Dalla 0.85 è possibile configurare Metro per servire bundle e gestire Fast Refresh tramite connessioni HTTPS e WSS (WebSocket sicuro).

const fs = require('fs');
const { getDefaultConfig } = require('@react-native/metro-config');

const config = getDefaultConfig(__dirname);

// Enable HTTPS + WSS (Fast Refresh over secure WebSocket)
config.server.tls = {
  ca: fs.readFileSync('./certs/ca.pem'),
  cert: fs.readFileSync('./certs/cert.pem'),
  key: fs.readFileSync('./certs/key.pem'),
};

module.exports = config;

Questa funzionalità risolve un problema concreto per i team che operano in reti aziendali con proxy TLS obbligatorio o che necessitano di testare funzionalità che richiedono un contesto sicuro (come le API di geolocalizzazione o i pagamenti in-app durante lo sviluppo).

Breaking Changes e guida alla migrazione

Ogni aggiornamento maggiore porta con sé delle rotture di compatibilità. La 0.85 ne introduce alcune che richiedono interventi specifici nel codice esistente.

Il preset Jest cambia nome, passando da react-native a @react-native/jest-preset. Questo richiede un aggiornamento nella configurazione dei test:

module.exports = {
  preset: 'react-native',
};

// jest.config.js — after
module.exports = {
  preset: '@react-native/jest-preset',
};

Un'altra modifica riguarda StyleSheet.absoluteFillObject, che viene deprecato in favore di StyleSheet.absoluteFill:

const overlay = StyleSheet.absoluteFillObject;

// After (0.85+)
const overlay = StyleSheet.absoluteFill;

Si tratta di un cambiamento apparentemente minore, ma che può generare warning in progetti di grandi dimensioni con centinaia di file di stile. L'utilizzo di un tool di ricerca e sostituzione globale è consigliato per gestire la migrazione in modo efficiente.

Miglioramenti agli strumenti di sviluppo

La 0.85 porta aggiornamenti significativi ai DevTools integrati. Il nuovo pannello dedicato alle animazioni nel React Native DevTools permette di ispezionare in tempo reale lo stato di ogni animazione attiva, visualizzando curve di interpolazione, valori correnti e il percorso di aggiornamento utilizzato (transform vs layout).

Il profiler di rete è stato potenziato con il supporto per la visualizzazione delle richieste GraphQL decostruite, mostrando query, variabili e tempo di risposta in un formato strutturato. Per i team che utilizzano Apollo Client o urql, questo rappresenta un miglioramento tangibile nel debugging delle interazioni con le API.

È stata inoltre introdotta la possibilità di connettere simultaneamente più client DevTools al medesimo dispositivo, permettendo a VS Code, React Native DevTools e agenti di coding AI di operare in parallelo senza terminare le sessioni reciproche.

Shadow Tree Commit Branching

Un miglioramento architetturale interno ma con impatto diretto sulle performance è lo Shadow Tree Commit Branching. Nelle versioni precedenti, ogni aggiornamento allo shadow tree (la rappresentazione intermedia tra il virtual DOM di React e la vista nativa) competeva per lo stesso percorso di commit delle animazioni. Con la 0.85, il sistema supporta il branching dei commit, separando gli aggiornamenti guidati dalle animazioni da quelli guidati dallo stato React.

Questo meccanismo riduce la latenza percepita nelle transizioni complesse, dove più componenti vengono aggiornati contemporaneamente. Il risultato è particolarmente evidente nelle schermate con liste complesse e header animati, dove il frame drop durante lo scroll veloce è stato ridotto significativamente.

Infrastruttura per la View Transition API

La 0.85 getta le basi per la View Transition API, un sistema che permetterà transizioni animate dichiarative tra schermate diverse. Un nuovo feature flag viewTransitionEnabled controlla questa funzionalità, che è disattivata per default nella 0.85. Si tratta di infrastruttura per un rilascio futuro, non ancora una funzionalità rivolta agli utenti.

Il concetto è analogo alla View Transitions API del web: definire elementi condivisi tra due viste e lasciare che il framework gestisca automaticamente l'animazione di transizione.

Strict TypeScript API

La novità forse più divisiva della 0.85 è la modalità Strict TypeScript API. Attivabile tramite una condizione personalizzata nel tsconfig.json, questa modalità espone tipizzazioni più rigorose per tutte le API del framework.

{
  "compilerOptions": {
    "customConditions": ["react-native-strict-api"]
  }
}

Con la modalità strict attivata, molte API che precedentemente accettavano any o tipi union ampi diventano fortemente tipizzate. La strict API genera i tipi direttamente dal codice sorgente anziché mantenerli manualmente. Limita le esportazioni al file indice pubblico react-native, impedendo la dipendenza da percorsi interni che si rompono tra versioni.

L'obiettivo dichiarato dal team di Meta è duplice: migliorare l'esperienza di sviluppo grazie a un autocompletamento più preciso e ridurre una categoria di bug runtime legati a valori di tipo errato passati a componenti nativi. La modalità è opt-in nella 0.85, ma la roadmap indica che diventerà il comportamento predefinito in una futura versione.

Per i team che adottano già regole ESLint rigorose e TypeScript in modalità strict, l'attivazione dovrebbe essere relativamente indolore. Per progetti con una base di codice meno tipizzata, la transizione potrebbe richiedere un investimento significativo in refactoring.

Domande da colloquio tecnico su React Native 0.85

Per chi si prepara a colloqui tecnici nel 2026, la conoscenza delle novità della 0.85 è diventata un argomento frequente. Ecco le domande più rilevanti:

Qual è la differenza fondamentale tra il vecchio bridge e JSI? Il bridge serializzava ogni messaggio in JSON e lo passava in modo asincrono tra i thread JavaScript e nativo. JSI fornisce un'interfaccia C++ diretta che permette chiamate sincrone, eliminando il costo di serializzazione e deserializzazione. Questo consente anche la condivisione diretta di oggetti tra i due mondi senza copie intermedie.

Come funziona il lazy-loading dei TurboModules nella 0.85? I TurboModules vengono registrati nel registry all'avvio ma non vengono istanziati. L'inizializzazione avviene solo alla prima chiamata a TurboModuleRegistry.getEnforcing(). Questo riduce il consumo di memoria al cold-start di circa il 40%, poiché molti moduli non vengono mai utilizzati in una singola sessione.

Perché lo Shared Animation Backend può animare proprietà di layout con il native driver? Grazie all'integrazione con Fabric, il backend può richiedere ricalcoli di layout incrementali limitati al sottoalbero interessato. Il vecchio renderer richiedeva un layout pass completo, rendendo troppo costoso animare proprietà come width o height sul thread nativo.

Cosa succede se un modulo nativo non viene trovato con getEnforcing? Il metodo lancia un'eccezione JavaScript sincrona. Esiste anche TurboModuleRegistry.get() che ritorna null se il modulo non è disponibile, permettendo un fallback graceful.

Quale vantaggio concreto porta il Shadow Tree Commit Branching? Separa gli aggiornamenti dello shadow tree guidati dalle animazioni da quelli guidati dallo stato React in branch indipendenti. Ogni branch esegue il commit in modo indipendente e si riconcilia ai confini del frame. Questo riduce il jank delle animazioni causato da re-render React che competono per lo stesso percorso di commit.

Conclusione

React Native 0.85 non è una release che si limita ad aggiungere funzionalità superficiali. Con lo Shared Animation Backend, il lazy-loading dei TurboModules e la Strict TypeScript API, questa versione affronta tre dei problemi più sentiti dalla community: performance delle animazioni, tempi di avvio e sicurezza dei tipi.

La rimozione definitiva del bridge chiude un capitolo lungo anni e semplifica il modello mentale richiesto agli sviluppatori. Non esistono più due percorsi di comunicazione da comprendere: JSI è l'unico canale, e i TurboModules l'unica interfaccia verso il nativo.

Per i team che pianificano la migrazione, il consiglio è di iniziare dall'attivazione della Strict TypeScript API in un branch separato per valutare l'impatto sul codice esistente, procedere con l'aggiornamento del preset Jest e delle API Android deprecate, e infine sperimentare con il nuovo backend di animazione per sostituire i workaround accumulati nelle versioni precedenti.

La direzione è chiara: React Native si sta trasformando in una piattaforma dove le performance native non sono più un compromesso ma il comportamento predefinito, e dove il sistema di tipi diventa un alleato concreto anziché una formalità opzionale.