Verificați compatibilitatea React Native înainte să pierdeți alternativa

O migrare devine mai greu de diagnosticat când aceeași actualizare schimbă arhitectura și elimină posibilitatea de revenire. Tranziția React Native din octombrie 2025 oferă o lecție generală utilă: stabiliți compatibilitatea cât timp arhitectura anterioară mai poate fi selectată, apoi treceți la versiunea care elimină alegerea. Pregătirea dependențelor ar trebui să fie o condiție de lansare, susținută de dovezi din aplicația efectivă.

Privind retrospectiv din noiembrie 2026, React Native 0.82 a apărut la 8 octombrie 2025. Această versiune a făcut obligatorie arhitectura nouă, New Architecture. Argumentul de aici privește acea tranziție istorică, nu recomandă ca o aplicație să rămână acum pe termen nedefinit la 0.81. O migrare actuală trebuie să țină seama și de versiunile susținute și de schimbările intermediare aplicabile punctului său de plecare.

Opțiunea de revenire nu mai schimbă arhitectura

Anunțul 0.82 precizează că newArchEnabled=false pe Android și RCT_NEW_ARCH_ENABLED=0 pe iOS sunt ignorate. Aplicația rulează tot pe arhitectura nouă. Prezența unei opțiuni într-un fișier de configurare nu dovedește, așadar, că alternativa mai este disponibilă. Sensul opțiunii este stabilit de versiunea care o citește.

Responsabilii proiectului recomandau trecerea mai întâi a unui proiect nemigrat la React Native 0.81 sau Expo SDK 54, ultimele versiuni care permiteau arhitectura veche, apoi activarea și verificarea arhitecturii noi acolo. Succesiunea separă compatibilitatea arhitecturii de etapa ulterioară în care aceasta devine obligatorie. Nu promite că toate celelalte schimbări din 0.82 sunt lipsite de consecințe.

React Native 0.81 a fost lansat la 12 august 2025. Anunțul său descrie și schimbări de platformă, inclusiv vizarea Android 16 și mutarea suportului JavaScriptCore integrat către un pachet al comunității. Aceste detalii fac din etapa intermediară o muncă reală de inginerie. Ar fi înșelător să prezentați 0.81 ca pe un simplu comutator, fără schimbări proprii de platformă sau de dependențe.

Articolul este o analiză a informațiilor publice despre framework. Nu inspectează aplicații mobile AL+, nu accesează Mac-ul unui dezvoltator, nu compilează cod nativ și nu raportează teste pe dispozitive. Compatibilitatea unei aplicații concrete rămâne o întrebare pentru dovezi din codul, dependențele și dispozitivele susținute de acea aplicație. Anunțurile oferă limita frameworkului, nu rezultatul aplicației.

Compatibilitatea privește întregul ansamblu de dependențe

O aplicație ipotetică poate avea o interfață JavaScript restrânsă și totuși să depindă de biblioteci native pentru stocare, cameră sau navigare. Decizia de migrare are nevoie de versiunile exacte ale dependențelor și de modulele native proprii. Apariția numelui unui pachet pe o listă generală de compatibilitate nu dovedește că versiunea fixată, modificările locale și configurația de platformă din aplicație funcționează împreună.

Pentru fiecare legătură nativă importantă, identificați acțiunea utilizatorului care ar scoate la iveală un eșec. Deschiderea unui selector de imagini și revenirea la un formular neterminat este o condiție de acceptare mai utilă decât constatarea că pachetul pentru cameră este prezent. Pornirea reușită este necesară, dar nu dovedește că întregul flux păstrează datele sau tratează corect întreruperile.

Păstrați dovezile proporționale cu aplicația. O aplicație simplă, cu puține integrări native, nu are nevoie să inventeze un program complicat de certificare. O aplicație al cărei rol comercial depinde de lucrul în fundal sau de cod nativ propriu are nevoie de verificări care ajung la acele trasee. Delimitarea relevantă urmează promisiunile aplicației, inclusiv tratarea erorilor și platformele susținute, nu lungimea listei de pachete.

Și responsabilitatea trebuie atribuită cuiva. Dacă un modul extern incompatibil blochează migrarea, cineva trebuie să decidă între actualizare, înlocuire, întreținerea unei corecții sau amânare. Anunțul 0.82 îndrumă problemele dependențelor către autorii bibliotecilor, iar erorile din nucleu către sistemul de raportare al frameworkului. Este o îndrumare despre locul raportării, nu garanția unei remedieri până la termenul aplicației.

Arhitectura obligatorie nu face obligatoriu fiecare experiment

Versiunea 0.82 oferea separat Hermes V1 experimental, cu activare opțională. Includea și React 19.1.1. Niciun fapt nu ar trebui reformulat ca obligație de a adopta toate experimentele noi ale mediului de execuție pentru a migra arhitectura. Separarea schimbărilor opționale poate ușura identificarea cauzei unui eșec și explicarea planului de migrare.

Anunțul păstra și straturile de interoperabilitate și nu elimina API-urile arhitecturii vechi din nucleu în acea versiune. Arhitectura nouă obligatorie este, așadar, o afirmație mai restrânsă decât dispariția tuturor claselor vechi în 0.82. Compatibilitatea printr-un strat de interoperabilitate și continuarea rulării pe arhitectura veche sunt lucruri diferite. Păstrați distincția când evaluați declarația de compatibilitate a unei biblioteci.

O notă de lansare poate stabili aceste fapte despre framework fără să dovedească performanța aplicației. Măsurătorile responsabililor proiectului pentru experimentele Hermes nu devin o promisiune de accelerare pentru altă aplicație. Migrarea pentru compatibilitate poate fi justificată prin suport și ușurința întreținerii chiar fără un câștig de performanță măsurat. Criteriile de acceptare ar trebui să spună ce problemă urmărește să rezolve actualizarea.

Repetiția este utilă când răspunde unei incertitudini

Cel mai puternic contraargument este că o aplicație deja verificată pe arhitectura nouă câștigă puțin din repetarea unei migrări intermediare doar ca formalitate. Dacă dovezile existente acoperă dependențele și fluxurile sale, actualizarea directă poate fi potrivită. Principiul general este separarea riscurilor nerezolvate, nu obligarea fiecărei echipe să treacă prin toate versiunile istorice.

Și amânarea poate fi justificată când o dependență critică rămâne incompatibilă și nu există un înlocuitor acceptabil. Amânarea are nevoie de un responsabil, un motiv și un moment de reconsiderare. Nu ar trebui justificată prin presupunerea că o opțiune de dezactivare a arhitecturii va funcționa și după actualizare. La fel, un termen-limită nu stabilește singur compatibilitatea neverificată.

Pentru mentenanța software, consemnați arhitectura care rulează, dovezile necesare pentru dependențe și versiunea după care vechea opțiune este ignorată. Alegeți apoi cea mai scurtă succesiune care rezolvă necunoscutele reale. Un plan util de migrare face vizibil punctul de angajament înainte ca utilizatorii să depindă de rezultat.