Shopify renunță la React Native în favoarea Swift și Kotlin. Motivul nu este ce crezi.

Shopify renunță la React Native în favoarea Swift și Kotlin. Motivul nu este ce crezi.

Shopify se desparte de React Native. Pe 10 septembrie 2026, directorul de mobil al companiei, Mustafa Ali, a publicat două articole de inginerie în care anunța că aplicațiile Shopify sunt reconstruite în Swift și Kotlin, cu câte o bază de cod per platformă. Aplicația Shop a fost deja lansată ca versiune complet nativă. Urmează aplicația principală Shopify, cu peste 300 de ecrane, o aplicație pentru Apple Watch și widget-uri pentru ecranul de blocare, programată pentru mai târziu în acest an.

Ceea ce face această știre demnă de citit este momentul ales. În ianuarie 2025, aceeași persoană a scris un articol intitulat „Cinci ani de React Native la Shopify“ și a spus industriei că dacă nu ați mai încercat React Native de ceva vreme, acum este un moment bun să vă uitați din nou. Douăzeci de luni mai târziu, face migrarea. Nu este o companie care s-a săturat de un framework. Este o companie care a văzut că una dintre ipotezele ei de bază s-a schimbat și a avut curajul să o spună public.

Ipoteza era legată de cost. Shopify a trecut la React Native în 2020 pentru a nu mai construi fiecare funcție de două ori. Ali este direct în privința faptului că framework-ul și-a făcut treaba: „Aplicațiile React Native pot fi rapide. Ale noastre sunt.“ Motivul plecării nu este performanța. Este faptul că agenții AI de programare au ajuns suficient de buni încât să scrie aceeași funcție în Swift și Kotlin nu mai costă cât costa înainte. Odată ce un agent poate prelua o mare parte din a doua implementare, argumentul principal pentru o bază de cod comună devine mai slab, în timp ce beneficiile mersului spre nativ — mai aproape de platformă și cu mai puține straturi de dependențe — rămân exact acolo unde erau.

Cifrele sunt reale. Reconstruită nativ, aplicația Shop a redus timpul de pornire la rece cu 23% pe iOS și 50% pe Android. Sesiunile cu crash-uri au scăzut de aproximativ zece ori, de la o stabilitate a sesiunilor de 99,5% la 99,95%. Build-urile Android de lansare s-au accelerat cu aproximativ 75%, binarul Android s-a micșorat cu 109 MB, iar feed-ul menține 120 FPS la derulare. Șase ingineri au dus aplicația de la dovada conceptului la App Store în 12 săptămâni, după ce un singur inginer a petrecut o săptămână demonstrând că ideea poate funcționa.

Unde v-am putea încetini

Titlul pe care toată lumea l-a distribuit este „AI a ucis cross-platform.“ Detaliul mai util este îngropat în descrierea migrării: cel mai mare câștig de viteză al Shopify a venit din decuplarea logicii de business de UI, astfel încât să ruleze fără interfață grafică, controlată de un instrument în linie de comandă în loc de un simulator. Agenții lor puteau itera în milisecunde în loc să supravegheze un simulator timp de minute la fiecare modificare. Acest truc nu are nicio legătură cu Swift sau Kotlin. Îl puteți face și în React Native astăzi. Puneți logica în module simple fără importuri de UI, rulați-le sub Node în spatele unui CLI subțire, și agenții voștri, și testele voastre, obțin același ciclu rapid. În lucrările noastre native iOS și Android, și în aplicațiile din domeniul sănătății și IoT pe care le-am construit acolo unde corectitudinea contează mai mult decât pixelii, această separare este singura modificare care aduce beneficii indiferent dacă un agent atinge vreodată codul.

Al doilea lucru care merită spus cu voce tare: Shopify a avut în continuare nevoie de experți nativi. Propriul lor articol admite că codul generat a introdus duplicare, derivă arhitecturală și probleme de performanță, și că expertiza nativă a rămas esențială. Costul a două baze de cod nu a dispărut. S-a mutat de la scrierea codului la revizuirea lui. Revizuirea codului Swift pe care nu l-ai scris tu, și să știi dacă este cu adevărat bun, reprezintă partea costisitoare, și nu se paralelizează ca generarea. Un startup de cinci persoane nu are capacitatea de revizuire a Shopify. Copiați decizia fără să copiați capacitatea de revizuire și veți ajunge cu două baze de cod și jumătate din încredere.

Deci sfatul concret: nu citiți asta ca un semnal pentru a rescrie ceva. Citiți-l ca un îndemn de a face un experiment. Alegeți un ecran, scoateți logica lui de sub UI într-un modul headless cu propriile teste și măsurați cât de mai rapid lucrează atât inginerii, cât și agenții voștri cu el. Este o zi de refactorizare, este reversibil și vă spune mai multe despre propria voastră bază de cod decât orice metrică Shopify.

Există și o lecție de securitate mai discretă în articolul lui Ali din 2025. El a semnalat că dependența React Native față de bibliotecile terțe îți lărgește suprafața de atac a lanțului de aprovizionare. Încă adevărat, și nu unic pentru React Native. Fiecare proiect nativ se bazează la rândul lui pe pachete. În cadrul angajamentelor noastre de pentesting, arborele de dependențe este unul dintre primele locuri unde ne uităm, deoarece un pachet tranzitiv compromis este o modalitate de intruziune mult mai comună decât un bug în propriul cod. Mai puține straturi de framework pot însemna mai puține componente de auditat, dar numai dacă urmărești cu adevărat ce introduci.

Nimic din toate acestea nu înseamnă că React Native s-a terminat. Shopify este un caz foarte specific: aplicații uriașe, buget pentru inferență AI și recenzori nativi, și o migrare iminentă la New Architecture care a făcut o reconstrucție de la zero competitivă față de actualizarea în loc. Majoritatea echipelor nu se află în această situație. Stiva potrivită depinde în continuare de echipa ta, de aplicațiile tale și de cât de mult din a doua construcție poți să ai cu adevărat încredere că un agent poate prelua.

Dacă a decide între nativ, cross-platform sau o refactorizare headless pentru următoarea ta versiune mobilă sună familiar, hai să vorbim. Am livrat atât aplicații native, cât și cross-platform și îți vom spune direct când o rescriere este alegerea greșită.

expert-analysismobile-developmentreact-nativetech-news