Shopify, yapay zekâ kodlama ajanlarını gerekçe göstererek React Native'den native Swift ve Kotlin'e geçiyor

Shopify, mobil geliştirmede en yakından izlenen bahislerden birini geri alıyor. dev.to'ya göre, yaklaşık beş yıl boyunca React Native'i savunan ve Ocak 2025'te bile framework'ün Shopify'da güçlü bir geleceği olduğunu söyleyen şirket, Shop ve diğer amiral gemisi uygulamalarını native Swift ve Kotlin ile yeniden inşa ediyor; platformlar arasında ortak bir codebase olmayacak.

Öne sürülen gerekçe

Shopify 2020 civarında React Native'i benimsediğinde sorun, her özelliği platform başına bir kez olacak şekilde iki kez geliştirmenin mühendislik kapasitesini fazla tüketmesiydi. dev.to'nun aktardığına göre şirketin yeni argümanı, yapay zekâ kodlama ajanlarının bu maliyeti ortadan kaldırdığı: şirket içi deneyler, ajanların diğer platformun bitmiş kodunu referans alarak bir özelliği başka bir platformda uygulayabildiğini, çeviriyi, testi ve incelemeyi sınırlı insan müdahalesiyle hallettiğini göstermiş.

Bunu ölçekli biçimde yürütmek için şirket, işi otomatik testlerden geçmesi, zorlu bir inceleme aşamasını temizlemesi ve sonrakinin başlaması için insan onayı alması gereken checkpoint'lere bölen Helix adlı iç araç zincirini kurmuş. Bir CLI katmanı, ajanların simulator başlatmadan iş mantığını çalıştırmasını sağlıyor; bu görünüşe göre gerçek bir darboğazmış. Shop uygulamasının çalışan bir prototipten tamamen yeniden inşa edilmiş, yayımlanmış bir uygulamaya bildirildiğine göre on iki haftada geçtiği ve uygulamanın çoğunu yapay zekânın yazdığı söyleniyor.

Shopify'ın anlatısındaki pürüzler

Yıllardır React Native'i alenen savunmuş biri tarafından yazılan dev.to analizi, hikâyenin birkaç noktasını sorguluyor:

• Performans karşılaştırmaları, JavaScript ile native kod arasındaki iletişimi iyileştiren büyük revizyon olan React Native'in New Architecture'ından öncesine ait; yani karşılaştırmanın baseline'ı ekiplerin bugün kullandığından daha eski bir framework.
• Shopify Expo kullanmıyordu; Expo ise build'leri, over-the-air güncellemeleri ve geliştirici client'larını hallediyor. Bu olmadan ekipler etkili bir şekilde bu araçların daha zayıf bir kopyasını yeniden inşa ediyor — native'le cross-platform karşılaştırmasının gizlediği bir maliyet.
• Yeniden yazım uygulama boyutını yaklaşık bir megabyte küçültmüş; bu da şişkinliğin çoğunlukla framework'ten değil, asset'lerden, yerelleştirmeden ve medyadan geldiğini düşündürüyor.
• React Native'in belki de en büyük pratik avantajı olan over-the-air güncellemelere neredeyse hiç değinilmemiş. Bunlar bir ekibin hatayı app store incelemesi olmadan yamasını sağlarken, gerçek kullanıcıların büyük bir kısmı hep eski native build'lerde kalıyor; native kodun bunun bir karşılığı yok.

Geçerli olan eleştiriler

Aynı yazı gerçek sorunları da kabul ediyor: Xcode ve CocoaPods üzerinden yürüyen bağımlılık yönetimi, React ya da JavaScript'le pek ilgisi olmayan şekillerde zahmetli; framework'ün kolay yaklaşımı daha geniş bir yetenek yelpazesini çektiği için sıradan React hataları mobilde daha sert düşüyor; sürüm yükselttmeleri temiz bir yeniden kurulumun çoğu zaman daha hızlı olacağı kadar güvenilmez hale gelmiş; ve ekipler, yeni platform özelliklerini çıktığı gün kullanmak yerine Meta'nın yol haritasının下游'unda oturuyor.

Tek kişilik bir port farklı bir hikâye anlattı

dev.to'da aktarılan ayrı bir deney zaman çizelgesini karmaşıklaştırıyor. Yarı zamanlı çalışan bir geliştirici, bir ajana bir simulator, mevcut bir React Native uygulaması ve bir referans uygulama vermiş ve haftalar yerine saatler içinde neredeyse tamamlanmış bir SwiftUI portu almış. Öne sürülen en olası açıklama model seçimi; büyük çapraz dil portları görünüşe göre işi hangi modelin yaptığına bağlı olarak ya başarılı oluyor ya da sürüklünüyor.

Bu deney ayrıca framework hızının ötesinde bir noktayı da gün yüzüne çıkardı: SwiftUI'nin navigation stack'i geri gitme kaydırmasını yalnızca ekranın sol kenarındaki dar bir şeritten tanıyor, oysa birçok kullanıcı ekranın ortasından geri kaydırıyor ve Apple'ın kendi birinci parti uygulamaları ikisini de kapsayacak özel gesture yönetimiyle geliyor. Native otomatik bir UX kazancı değil — her iki durumda da bilinçli emek gerekiyor.

Framework'ün arkasındaki yetenek sorusu

Analiz, bu hikâyenin en sonuç doğuran kısmının React Native'i kimin sürdürdüğüyle ilgili olduğunu savunuyor. Zirvesinde Meta'nın React Native'de, çekirdek React ve web tarafının toplamından kabaca on kat fazla mühendisi olduğu bildiriliyor. Bu yatırım küçülüyor: geçtiğimiz yıl birkaç kıdemli mühendis Meta'dan ayrıldı; bir kısmı yapay zekâ kodlama araçları yapan şirketlere katıldı. Framework ortadan kalkmıyor, ama arkasındaki yetenek derinliği gözle görülür biçimde değişti ve beş yıllık bir framework bahsi, benchmark sonuçlarının yanında sürdürücünün sağlığını da tartmalı.

Neden önemli

Ajanlar aynı özelliği iki kez geliştirmeyi gerçekten ucuzlatıyorsa, cross-platform framework'lerin ekonomik gerekçesi sektör genelinde zayıflar ve Helix'in checkpoint deseni — her aşamada otomatik testler, zorlu inceleme ve insan onayı — diğer ekiplerin kopyalayacağı bir şablona dönüşür. Ama dev.to eleştirisi kanıtın manşetten daha ince olduğunu gösteriyor: eski bir mimari, eksik araç zinciri ve göz ardı edilmiş bir over-the-air avantajı karşılaştırmayı bulanıklaştırıyor. Mühendislik liderleri için pratik çıkarımlar şunlar: yeniden yazım benchmark'larını titizlikle inceleyin, ajan destekli portlamayı büyük ölçüde modele bağlı görün ve her uzun vadeli framework seçiminde sürdürücü yatırımını hesaba katın.