Yapay zekaya mobil uygulama yaptırmak: nereye kadar gidiyor

Yapay zeka aracı bir mobil uygulama için gerçek bir React Native ve Expo projesi üretebiliyor, boş bir mockup değil. Güvenilir şekilde üretemediği şey; mağaza incelemesinden geçen, geçerli bir imza sertifikası taşıyan, doğru cihaza push bildirim gönderen ve yeni inceleme gerektirmeden güvenle güncellenebilen bir sürüm. Bu fark tarayıcıda görünmez, çünkü tarayıcı hiçbir zaman imza ya da mağaza listelemesi istemez. Uygulama telefona indiği an aradaki uçurum ortaya çıkar.

Yapay zeka mobilde tam olarak neyi üretiyor

Bir yapay zeka aracına "randevu uygulaması yap" dediğinde çıkan sonuç genelde çalışan bir React Native ve Expo projesi, boş bir kabuk değil. Ekranlar gerçek gezinmeyle bağlanır, formlar state tutar, çoğunlukla Supabase veya Firebase olan bir backend'e gerçek istek atar. Prototip aşamasında bu, haftalar sürecek bir iskelet işini bir güne indirir.

Sınır da aynı hızda ortaya çıkıyor. Kimlik doğrulama genelde demo modunda kalıyor. Ödeme, hiçbir şeyi tahsil etmeyen bir buton oluyor. Push bildirim hiç kurulmuyor. Mağaza gereksinimleri, gizlilik politikası linki, veri toplama beyanı, hesap silme akışı tamamen atlanıyor, çünkü yerel bir demo çalıştırmasında hiçbiri sorulmuyor.

Web prototipi ile mağaza uygulaması nerede ayrışıyor

Tarayıcıda çalışan bir sayfa ile telefona kurulu bir uygulama farklı kurallara tabi. Tarayıcı kimseden imza istemez, mağaza uygulaması imzasız yayınlanamaz. Web sayfası yeniden dağıtımın olduğu an güncellenir, mağaza uygulaması önce bir inceleme kuyruğundan geçmek zorunda, ve o kuyruğun yerel geliştirme ortamının hiç test etmediği görüşleri var.

İlk kez mağazaya gönderenleri en çok şaşırtan satır dağıtım, ki bir sonraki bölüm tam olarak bunu anlatıyor. Kısayolu da yok: mobil uygulama geliştirme işimiz tam olarak bu son kilometreyi, mağaza hesapları dahil, üstlenmek için var.

Apple'ın "şablon uygulama" maddesi seni neden ilgilendiriyor

App Store inceleme kriterleri yapay zeka araçlarını doğrudan adlandırmıyor, ama üç madde tam olarak yapay zeka üretimi bir uygulamanın düşeceği hataya işaret ediyor: aynı aracın ürettiği her uygulamaya benzemek.

Bunların hiçbiri yapay zeka destekli bir uygulamanın ilke gereği reddedildiği anlamına gelmiyor. Anlamı, inceleme riskinin tek bir noktada toplandığı: gönderim senin ürünün gibi mi okunuyor, kendi geliştirici hesabından mı gidiyor, işine özgü işlevsellik taşıyor mu, yoksa bir üretim aracının varsayılan çıktısının bir kopyası gibi mi duruyor. Çözüm kozmetik değil. Ürünü isimlendirmek, geliştirici hesabını kendi adına almak ve bu uygulamayı aynı prompt'un üreteceği bir sonrakiyle değiştirilemez kılan özellikleri kurmak.

İmzalama ve sürüm yönetimi: kod bittiğinde iş bitmiyor

Bir derlemenin telefona inebilmesi bile, bir web deploy'unun hiç dokunmadığı bir imza zinciri gerektiriyor. iOS tarafında EAS Build üç kimlik bilgisini yönetiyor: distribution sertifikası (bir Apple Developer hesabı başına bir tane, belirli bir uygulamaya değil geliştiriciye bağlı), provisioning profile (uygulamaya özel, 12 ay sonra süresi doluyor, ama bu süre dolumu yayındaki uygulamaları etkilemiyor; EAS bir sonraki derlemede otomatik yeniliyor) ve push bildirim anahtarları (hesap başına en fazla iki tane, sertifikaların aksine süresi dolmuyor). Android tarafında EAS keystore'u üretip saklıyor, çoğu ekip Google Play App Signing'i tercih ediyor: bu durumda nihai imzalama anahtarını Google tutuyor, geliştiricide sadece bir yükleme sertifikası kalıyor.

Web'den gelen ekipleri şaşırtan kısım şu: bunların hiçbiri kodu üreten yapay zeka aracına ait değil, bize de ait değil. Uygulamanın sahibinin kontrol ettiği geliştirici hesaplarında durmak zorunda, çünkü o hesabı sonradan kaybetmek, zaten yayında olan bir uygulamaya güncelleme gönderme yeteneğini de kaybetmek demek.

Push bildirim ve cihaz izinleri ayrı bir mühendislik

Çalışan bir bildirim için üç şeyin aynı anda olması gerekiyor: Expo Notifications veya OneSignal gibi bir sağlayıcıya kayıtlı bir cihaz token'ı, kullanıcının vermesi gereken OS seviyesinde bir izin, ve o izin reddedildiğinde, sonradan geri alındığında ya da uygulama yeni bir cihaza kurulduğunda ne olacağını takip eden bir durum makinesi. Bunların hiçbiri bir demo derlemede yok, çünkü bir demo hiçbir zaman bir token'ın bayatlayacağı ya da bir iznin geri alınacağı kadar uzun çalışmıyor.

İzin isteminin kendisi opt-in oranını doğrudan etkileyen bir UX kararı: neden istendiğini açıklamadan bildirim izni istemek, kullanıcı bildirime değer bir şey yaptıktan sonra gösterilen bir istemin genelde koruduğu opt-in'leri kaybettiriyor. Yapay zeka üretimi bir ekran akışı bu sıralamayı neredeyse hiç kodlamıyor, çünkü gerçek bir kullanıcının ne zaman evet diyeceğine dair hiçbir verisi yok.

Mağaza incelemesi olmadan neyi güncelleyebilirsin

EAS Update, JavaScript ve varlık değişikliklerini yeni bir binary ve yeni bir inceleme kuyruğu olmadan havadan gönderiyor. Sınır kesin, derece meselesi değil.

Bu yol ne zaman anlamsız

Ürün girişsiz, ödemesiz, bildirimsiz tek ekranlık bir şeyse, mağaza uygulaması genelde yanlış kap oluyor; bir web uygulaması bu listenin tamamından kurtarıyor. Şirket içinde zaten özel bir mobil ekip varsa buradaki değer daralıyor: yeniden yapım değil, imzalama hattının ve mağaza gönderiminin odaklı bir incelemesi. Ve uygulama arka planda kalıcı işlem ya da derin donanım erişimi gibi köprünün zayıf kaldığı bir şeye dayanıyorsa, yapay zeka üretimi bir React Native iskeletiyle başlamak, native'den başlamaktan daha fazla zaman yiyor.

Prototipten yayına: hangi parça kalıyor, hangisi yeniden yazılıyor

Yaptığımız devralmalarda ekranlar, gezinme ve backend'e giden API çağrılarının çoğu genelde neredeyse olduğu gibi kalıyor. Her seferinde yeniden yazılan şey bu yazının anlattığı aynı dört başlık: kimlik doğrulamanın demo modundan çıkarılması, mağaza kuralına uyan gerçek bir ödeme akışı, gerçek cihaz token'larına bağlanan push, ve ilk sürümü kimin yazdığından bağımsız olarak sahibinin kontrol ettiği bir imzalama ve güncelleme hattı. Aynı React Native ve Expo yığını üzerine kurulu mobilite süper uygulamamız Ulassana, tam bu yoldan geçti: ilk çalışan derlemeden gerçek sürücü trafiği taşıyan bir sürüme. Yayın sonrasında bozulan şeyler, süresi dolan sertifikalar, SDK yükseltmeleri ve hiç bitmeyen mağaza yeniden incelemeleri LumiCare kapsamında kalıyor.

Sık sorulan sorular

Başka birinin yapay zekayla yazdığı React Native veya Expo uygulamasını devralır mısınız?
Evet. Önce kodu okuyup neyin kaldığını, neyin yeniden yazılacağını söylüyoruz; web devralmalarında işleyen yapay zeka projesi tamamlama sürecinin aynısı.

App Store ve Google Play'e aynı anda mı gönderiyorsunuz?
İki derleme de imzalandıktan sonra genelde paralel gönderiyoruz, ama Apple'ın inceleme kuyruğu ile Google'ınki birbirinden bağımsız ve kendi hızında ilerliyor; ikisi nadiren aynı gün yayına giriyor.

OTA güncelleme mağaza incelemesini tamamen ortadan kaldırıyor mu?
Hayır. Sadece JavaScript, varlık ve metin değişiklikleri için kaldırıyor. Native koda, izinlere veya SDK sürümüne dokunan her şey yine tam bir derleme ve yeni inceleme istiyor.

Mevcut Supabase veya Firebase backend'imizi koruyabilir miyiz?
Çoğu devralmada evet. Backend ve mobil istemci ayrı sistemler; şema ve erişim kuralları sağlamsa mobil taraf backend'e dokunmadan düzeltiliyor. Backend'in gerçekten korunmaya hazır olup olmadığını hızlıca görmek için yapay zeka ile yazılan uygulamalar için yayın öncesi güvenlik kontrol listesi yazımız işe yarıyor.

Bildirim izni reddedilirse uygulama çalışmaya devam eder mi?
Etmek zorunda. Reddedilen izin uygulamanın açıkça ele alması gereken bir durum, bir kenar durumu değil; uygulama temel işlevini sürdürüyor ve sadece bir cihaz token'ı hiç kaydetmiyor.