Yapay zeka tarafından üretilen kod kullanarak bir fikirden iOS/Android yayınına adım adım rehber — araç seçimi, test ve mağaza gönderimi için net seçimlerle.

İyi bir AI destekli geliştirme, kod düzenleyicisini açmadan önce başlar. Fikriniz bulanıksa, AI ekranlar ve özellikler üreterek sizi meşgul edebilir ama asıl değeri yaratmayabilir. İşiniz ona net bir hedef vermektir.
Uygulamanın kim için olduğunu ve hangi sıkıntıyı giderdiğini içeren tek bir cümle yazın. Yeterince spesifik olsun ki yabancı biri bile durumu hayal edebilsin.
Örnek şablon:
“[kullanıcı türü]’nün [bir iş yapmasını] kolaylaştırmak için [yaygın bir engeli kaldırma].”
Örnek:
“Freelance tasarımcılara müşteri bilgilerini kaydedip şablonları yeniden kullanarak faturaları 60 saniyenin altında göndermede yardımcı olun.”
Kullanıcı hikâyeleri özellik değil eylem tanımlar; MVP’nizi gerçek davranışlara dayandırır.
İlk sürümünüz temel değeri en az hareketli parçayla kanıtlamalı. Fikirlerinizi iki sepete ayırın:
Kısa bir kural: onu kaldırdığınızda uygulama ana problemi çözmeye devam ediyorsa, olmazsa olmaz değildir.
MVP'nin çalıştığını söyleyebilecek tek ölçülebilir bir sonucu seçin. Örnekler:
Bu metriği daha sonra ne inşa edeceğinize ve neleri görmezden geleceğinize karar vermek için kullanacaksınız.
AI’den ekran veya kod üretmesini istemeden önce uygulamanın nerede çalışacağını ve hangi araçların kullanılacağını belirleyin. Bu, promptları odaklar ve gerçek kısıtlarınıza uymayan kod üretimini önler.
En basit soru ile başlayın: Kullanıcılarınız bugün nerede?
Emin değilseniz, web sitesi analizleri, e-posta listesi, müşteri görüşmeleri veya cihaz türünü soran kısa bir kayıt formu gibi sinyallere bakın.
Çoğu MVP için çapraz platform en hızlı yol sunar.
Çapraz platform (MVP’ler için önerilir)
Native (Swift/Kotlin)
Native seçin eğer platforma özgü özelliklere (ileri seviye kamera işlem hattı, karmaşık Bluetooth, yüksek performanslı animasyonlar) güçlü bağımlılığınız varsa veya zaten bir native ekibiniz varsa.
Teknoloji yığınınız veri ihtiyaçlarınızla eşleşmeli:
Her AI promptunda tutturacağınız dört kısıtı not edin: bütçe, zaman çizelgesi, kodlama rahatlığı ve bakım beklentileri (gelecek ay hataları kim düzeltecek?). Bu adım “güzel demo kodu”nun gönderilmeye uygun sağlam koda dönüşmesini sağlar.
Daha rehberli bir iş akışı isterseniz ve birden fazla araçta promptları birleştirmek istemiyorsanız, Koder.ai gibi sohbet merkezli platformlar bu kısıtları proje boyunca tutmanıza yardımcı olabilir. Sohbette hedefi tanımlarsınız, ekran ekran iterasyon yaparsınız ve hazır olduğunuzda kaynak kodunu dışa aktararak projeyi kendi repoya taşırsınız.
AI’den kod üretmesini istemeden önce ona somut bir şey verin. Basit bir kullanıcı akışı ve az sayıda ekran proje odaklı kalmasını sağlar, tekrar işleri azaltır ve promptlarınızı netleştirir.
MVP için kullanıcı değeri elde etmek adına dokunulması gereken birkaç ekranla başlayın — MVP için 5–10’u geçmeyin. Kağıda çizin, beyaz tahta kullanın veya Figma’da hızlı çerçeveler oluşturun.
Tipik MVP ekran seti:
Her ekrana bir cümlelik amaç verin: “Ana ekran kullanıcının projelerini gösterir ve yeni proje oluşturma düğmesi sunar.” gibi.
“Mutlu yol”u şu sıra ile yazın:
Geri dönen kullanıcılar için ikinci kısa akış ekleyin: “Uygulamayı aç → son durum hemen gösterilsin → devam et.” Bu, navigasyon ve varsayılan durumlara öncelik vermenize yardımcı olur.
Sakladığınız bilgileri ve nerede göründüğünü listeleyin. Basit tutun:
Bu, listeler, detay ekranları ve formlar için temel olur.
Her ekran için not edin:
Bu notlar “sadece demo” UI’leri engeller ve ilk AI yapılmış versiyonun gerçek hissetmesini sağlar.
AI ile üretilen kod, ona “küçük ama eksiksiz” bir spesifikasyon verdiğinizde çok daha iyi sonuç verir. Bunu, belirsizliği ortadan kaldıran ve ekranlar arasında tutarlılığı sağlayan tek sayfalık bir brifing gibi düşünün.
Kısa ama spesifik tutun. İçerik:
Kopyalayıp tekrar yapıştırabileceğiniz kompakt şablon:
App: <isim>
Goal: <bir cümle>
Users: <kim>
MVP features:
1) ...
Screens:
- Home: ...
- Detail: ...
Data:
- <Entity>: field(type), ...
Rules:
- Validation: ...
- Empty states: ...
Out of scope: ...
İsterseniz sohbet merkezli bir üretici (örn. Koder.ai) kullanıyorsanız, bu şablonu “planlama modu” girdisi olarak değerlendirin. Paylaşılan, tekrarlanabilir bir spec AI odaklı bir inşa sürecini oturtur.
AI her seferinde yapıyı yeniden icat etmesin diye beklentileri baştan koyun:
“Bütün uygulamayı yap” yerine: bir ekran + navigasyon + minimal mock veri isteyin. Sonra yineleyin: UI’yı ince ayar yapın, gerçek veriye bağlayın, kenar durumları ekleyin. Daha hızlı incelersiniz ve karışık değişikliklerden kaçınırsınız.
Promplarda tekrar kullandığınız bir not tutun: uygulama spesifikasyonu, kodlama kuralları, alınan kararlar ve güncel dosya ağacı. Bunu her isteğin başına yapıştırın ki AI tutarlı kalsın — ayrı oturumlar arasında bile.
Bu adımda hedefiniz basit: sahte verilerle gerçek bir cihazda veya emülatörde “tıklanabilir” bir uygulama çalışır duruma getirmek. Çalışan bir kabuk ivme kazandırır ve eksikleri ortaya çıkarır.
Seçtiğiniz çerçevede (Flutter veya React Native) temiz bir başlangıç projesi için prompt atın; içinde:
Ondan sonra AI’nin önerisini resmi dokümantasyonla karşılaştırın. AI iskelet kurmada iyidir ama paket isimleri ve sürümler değişebilir.
Hızlıca çalışır bir iskelet ve daha çabuk deploy edilebilir bir yol isterseniz, Koder.ai sohbetten ön uç + arka uç iskeletini oluşturup çalışır tutabilir — ilk kablo bağlarını harcamadan hız sağlar.
Her ekran için isteyin:
Bu sizi kontrol altında tutar ve hata ayıklamayı kolaylaştırır. Her ekran üretildikten sonra uygulamayı çalıştırıp akışı tıklayın, sonra devam edin.
Erken küçük bir bileşen seti oluşturulmasını isteyin — sonra her yerde bunları tekrar kullanın:
Bu, her ekranın farklı görünmesini engeller ve ileride hız kazandırır.
AI’ye açıkça söyleyin: API anahtarlarını uygulamaya gömme. Ortam değişkenleri, derleme zamanı yapılandırması veya güvenli depolama kullanın. Eğer bir backend API anahtarına ihtiyacınız varsa, onu sunucu tarafında tutun ve mobil uygulamaya sadece güvenli uç noktalar açın.
Gerçek servisleri bağladığınızda, temiz bir altyapı kurduğunuz için memnun olursunuz.
UI ve navigasyon çalıştıktan sonra uygulamaya “gerçek veri” verin: gerçek hesaplar ve güvenilir ağ çağrıları. AI üretimli kod bu aşamada zaman kazandırabilir—eğer onu net kontratlarla yönlendirirseniz.
Çoğu MVP için şu seçeneklerden birini seçin:
Pratik kural: kullanıcılar, birkaç tablo ve dosya yüklemeleri gerekiyorsa Firebase/Supabase genellikle yeterlidir. Bağlamınıza göre kendi API’nizi tercih edin.
Kısa bir “veri spesifikasyonu” verip şunu isteyin:
Örnek prompt:
We use Supabase.
Entities: UserProfile(id, name, email, created_at), Task(id, user_id, title, due_date, done).
Rules: users can only access their own tasks.
Generate: SQL tables, RLS policies, and client code for list/create/update tasks.
Üretileni gözden geçirin. Eksik indeksler, belirsiz alan adları veya “admin erişimi” gibi gönderilmemesi gereken kısaltmalar olup olmadığını kontrol edin.
Ağ çağrıları sıklıkla başarısız olur. AI’den uygulamasını isteyin:
Küçük bir UX detayı: yükleniyor göstergesi gösterin ama aynı zamanda iptal/geri olanağı verin, böylece uygulama takılı hissetmez.
Firebase, Supabase veya kendi API’niz olsun, "veri sözleşmesini" dokümente edin:
Bunu repoda kısa bir README olarak saklayın. Sonra AI’ye özellik eklerken sözleşmeyi yapıştırın — yeni kod mevcut ekranları bozmadan uyumlu kalsın.
AI çok kod üretebilir — ama hız yalnızca uygulama gerçek telefonlarda, gerçek kullanıcılarla ve tuhaf girişlerle doğru davranıyorsa işe yarar. Amacınız her şeyi test etmek değil; güveni yıkabilecekleri test etmek: çökmeler, engellenen temel akışlar ve bariz UI hataları.
Kullanıcının tamamlaması gereken 3–5 temel eylemi seçin (ör. kayıt, giriş, öğe oluşturma, ödeme, mesaj gönderme). Bunları sürüm kapısı gibi düşünün. Bu akışlardan herhangi biri başarısızsa, yayınlamayın.
AI’den şu tür mantık için birim testleri isteyin:
Test başarısızsa, sadece kodu yeniden üretmeyin — AI’den nedenini açıklamasını ve en küçük güvenli düzeltmeyi önermesini isteyin.
Birim testleri navigasyon veya API bağlantı hatalarını yakalamaz. Bazı entegrasyon testleri ekleyin:
Emülatör yardımcıdır ama gerçek cihazlar şikayet edilen sorunları yakalar: yavaş başlatma, klavye örtüşmesi, kamera izinleri, kötü ağ. Minimum testler:
Basit bir liste tutun: yeniden üretme adımları, beklenen vs gerçek sonuç, cihaz/OS ve ekran görüntüleri.
Düzeltme sıralaması:
Bu disiplin AI üretimli kodu gönderilebilir bir uygulamaya dönüştürür.
AI daha hızlı göndermenize yardımcı olabilir, ama aynı zamanda güvenli olmayan varsayılanlar (hardcode anahtarlar, çok geniş izinler, ayrıntılı loglama veya güvensiz depolama) üretebilir. Güvenlik ve gizliliği yayın engeli olarak ele alın — küçük bir MVP için bile.
Öncelikle kimlik doğrulama, veri depolama, ağ ve loglama ile ilgili her şeye hızlı bir göz atın.
Temel özelliğiniz için gerçekten ihtiyaç duyduğunuz kişisel verileri isteyin. Uygulamanız kişiler, kesin konum veya arka planda izleme olmadan çalışabiliyorsa—bunları istemeyin. Veri minimizasyonu riski azaltır, uyumluluk yükünü hafifletir ve mağaza incelemesini kolaylaştırır.
En azından ayarlar ekranında açık bir Gizlilik Politikası bağlantısı ve mağaza listesi için açıklama bulundurun. Kişisel veri (e-posta, analiz kimlikleri, çökme raporları) topluyorsanız veya uygulamalar arası izleme yapıyorsanız, gerektiğinde uygulama içinde açık bir açıklama ekleyin.
Basit bir desen:
AI sıkça kütüphane çeker — bazen eski olanları. Bağımlılık taraması (örn. GitHub Dependabot) ekleyin ve düzenli güncellemeler planlayın. Yükseltme yaptığınızda temel akışları (giriş, ödeme, çevrimdışı, onboarding) yeniden çalıştırın.
Düzenlenmiş bölgelerde kullanıcılarınız varsa, temel olarak gerekli olabilir: onay istemleri (gerekliyse), veri silme/aktarma yolları ve mağaza “veri güvenliği” formlarına uygun açıklamalar. Emin değilseniz, ne topladığınızı ve neden topladığınızı dokümante edin—sonra uygulamayı buna göre ayarlayın.
Eğer veri ikametgahı önemliyse (ör. belirli bir ülkede çalıştırma gerekliyse), bunu erken karar verin çünkü barındırma ve üçüncü taraf servis seçimlerini etkiler. Koder.ai gibi platformlar küresel AWS üzerinde çalışır ve farklı bölgelerde dağıtım yapabilir; bu da uluslararası lansmanlarda uyumluluk planlamasını kolaylaştırabilir.
İlk çalışan derleme bir kilometre taşıdır — ama cilalama kullanıcıların uygulamayı tutmasını sağlar. AI’yı kopya önerilerinde, kenar ekranlarında ve performans ipuçlarında hızlandırıcı olarak kullanın; sonra gerçek cihazlarda doğrulayın.
Kullanıcıların fark ettiği anlara odaklanın: uygulama başlatma, ilk ekran renderı, kaydırma ve kaydetme eylemleri.
Başlatma süresini optimize etmek için kullanılmayan kütüphaneleri kaldırın, ilk ekrandan sonra yapılabilecek işleri erteleyin ve önbelleğe alınabilecekleri cacheleyin (ör. son görülen öğeler). Görselleri doğru boyutlarda dışa aktarın, modern formatları kullanın ve katmanın altındaki görselleri tembel yükleyin.
API kullanımınızı izleyin. Talepleri birleştirin, basit debouncing ekleyin ve yavaş çağrılar için ilerleme göstergeleri gösterin. AI üretimli kod kullanıyorsanız, pahalı UI yeniden çizimleri konusunda AI’den küçük refactor önerileri isteyin.
Metinleri okunaklı yapın (sistem yazı boyutlarını destekleyin), iyi renk kontrastı sağlayın ve dokunma hedeflerini rahat büyüklükte tutun. İkonlar ve butonlar için erişilebilirlik etiketleri ekleyin ki ekran okuyucular eylemleri açıklayabilsin.
Pratik kural: bir eylem sadece ikonla gösteriliyorsa, bir metin etiketi veya erişilebilirlik açıklaması ekleyin.
Net hata mesajları oluşturun: ne olduğunu ve ne yapılacağını söyleyin (“Kaydedilemedi. Bağlantınızı kontrol edip tekrar deneyin.”). Kullanıcıyı suçlayan ifadelerden kaçının.
Boş durumlar yardımcı olmalı: ekranın ne için olduğunu açıklayın ve sonraki adımı sunun (“Henüz proje yok—ilkini oluşturun”). AI mikro metin çevirileri için iyidir; tonu tutarlı tutun.
Ana eylemler için minimal etkinlik seti ekleyin (kayıt, ilk başarılı eylem, satın alma/yükseltme, paylaşım). Az tutun ve takip edilenleri dokümante edin. Gerekliyse opt-in yapın ve gizlilik bilgilerinde gösterin.
Daha iyi QA kontrol listesi isterseniz, bunu ekip dokümanlarınıza veya /blog/app-polish-checklist gibi basit bir dahili sayfaya ekleyin.
Uygulamanız mükemmel çalışsa bile mağaza listelemesi belirsizse zor bulunur. AI burada yararlı çünkü birkaç seçenek hızlıca üretebilir—sonra en iyi olanı seçip düzeltirsiniz.
AI’den farklı açılarda (problem-odaklı, fayda-odaklı, özellik-odaklı) birkaç alternatif isteyin. Tonu kitlenizle ve uygulamanın gerçek yetenekleriyle tutarlı tutun.
Create 5 app name ideas (max 30 chars), 5 subtitles (max 30 chars),
1 short description (80–100 chars), and 1 full description (up to 4,000 chars).
App: [what it does]
Audience: [who it’s for]
Top 3 benefits: [list]
Top 5 features: [list]
Avoid claims about medical/financial guarantees. Include a clear privacy note.
Also suggest 20 keywords (single words/short phrases).
Sonra: jargonları kaldırın, belirsiz vaatleri somut sonuçlarla değiştirin ve listede sözü edilen her özelliğin MVP’de gerçekten olduğundan emin olun.
AI ekran görüntüsü hikâyesi planlamada yardımcı olabilir: ana akışı gösteren 5–8 ekran, her biri kısa bir başlıkla. Başlıkları küçük telefonlarda okunabilir tutun.
Platform kurallarını AI’ye bırakmayın—App Store Connect ve Google Play Console’daki boyut ve sayı kurallarını doğrulayın, sonra metni ona göre oluşturun.
AI’dan ikon fikirleri ve renk yönleri beyin fırtınası isteyin, ama son ikonu küçük boyutlarda kolay tanınır ve basit tutun.
Son olarak, mağaza gereksinimleri için destek iletişim bilgilerini hazırlayın:
AI çıktılarını taslak olarak değerlendirin; doğrulamak ve uyumluluk sağlamak sizin işiniz.
Gönderme çoğunlukla evrak işi ve imzalama/inceleme kuralları etrafında birkaç tuzak içerir. Bunu kontrol listesiyle yönetin, son dakika telaşı gibi düşünmeyin.
Benzersiz tanımlayıcıları erken oluşturun veya doğrulayın:
Doğru derlemeleri oluşturun:
Yaygın hata: debug ayarlarını release’e karıştırmak (yanlış API uç noktaları, loglama veya izinler). Yüklemeden önce release yapılandırmanızı iki kez kontrol edin.
Cihaz-spesifik sorunları yakalamak için resmi ön sürüm kanallarını kullanın:
Gerçek cihazlarda en az bir tam “mutlu yol” ve hesap oluşturma/giriş, ödemeler (varsa) ve uç durumları test edin.
Basit bir sürümleme stratejisi seçin ve ona sadık kalın:
Değişiklikleri açıklayan sürüm notlarını yazın. AI ile taslak hazırladıysanız doğruluğunu kontrol edin—mağazalar belirsiz veya yanıltıcı notları sevmez.
“İnceleğe Gönder”e basmadan önce Apple ve Google yönergelerindeki sık rastlanan hataları tarayın:
İnceleme sorular sorarsa, test hesap detayları, yeniden üretme adımları ve bir sonraki derlemede neyi değiştirdiğinizi spesifik olarak yanıtlayın.
Yayın noktası bitiş çizgisi değildir — gerçek dünya verisini aldığınız andır. Yayından sonra hedef basit: problemleri erken yakalayın, kullanıcıların gerçekten ne istediğini öğrenin ve küçük geliştirmeleri düzenli ritimde yayınlayın.
İlk günden itibaren çökme raporu ve temel analitiği kurun. Çökme raporları ne kırıldı, hangi cihazda ve çoğu zaman neden kırıldığını söyler. Bunu anahtar olaylarla (kayıt tamamlandı, satın alma denendi, ana ekran görüntülendi) eşleştirin.
İlk 1–2 hafta boyunca mağaza yorumlarını ve destek e-postalarını günlük izleyin. Erken kullanıcılar fiilen QA ekibinizdir — dinleyin.
Ham geri bildirim karışıktır: kısa yorumlar, duygusal ifadeler, tekrar eden şikâyetler. AI ile bunları özetleyip “giriş sorunları”, “kafa karıştıran onboarding” veya “özellik talebi: karanlık mod” gibi temalara ayırın.
Pratik iş akışı:
Daha iyi sonuç için bağlam (app versiyonu, cihaz, kullanıcı tarafından bahsedilen adımlar) ekleyin ve “muhtemel kök neden” isteyin, sadece özet değil.
Büyük sürümlere yönelmekten kaçının. Güvenilir bir düzen güven oluşturur.
Sık gönderim yapıyorsanız, küçük değişiklikler tercih edin ki bir regresyon olursa kaynağını bulmak kolay olsun. Koder.ai gibi platformlardaki anlık görüntü ve geri alma özellikleri denemeyi ve hızlı geri almayı kolaylaştırır.
Araçlara ve iterasyonlara nasıl bütçe ayıracağınıza karar verirken, /pricing sayfasına bakın.
Daha iyi prompting örnekleri ve kod inceleme alışkanlıkları için /blog/ai-coding-guide ile devam edin.
Tek cümlelik bir problem ifadesi yazın: kimin için olduğu ve hangi sıkıntıyı giderdiği belli olsun; sonra bunu 3–5 kullanıcı hikâyesine (özellik değil eylem odaklı) dökün.
Her şeyden önce, özellikleri olmazsa olmaz ve iyi olur olarak ayırın ve bir başarı metriği seçin (ör. görev başına kazanılan süre) — bu, önceliklendirme için rehberiniz olur.
Kullanıcılarınızın bugün nerede olduğuna bakın:
Emin değilseniz, analytics, e-posta listesi, müşteri görüşmeleri veya kısa bir kayıt formu ile cihaz türü sinyali toplayın.
Çoğu MVP için çapraz platform en hızlısıdır:
Platforma özel (Swift/Kotlin) tercih edin: karmaşık kamera iş akışları, Bluetooth veya yüksek performanslı animasyonlar gibi platforma özgü özelliklere güçlü bağımlılık varsa ya da zaten yerel bir ekibiniz varsa.
Veri ihtiyaçlarınıza göre backend seviyesini eşleştirin:
Pratik kural: kullanıcılar + birkaç tablo + dosya yüklemeleri gerektiren bir uygulama için Firebase veya Supabase çoğunlukla yeterlidir.
AI’ye verilecek kısa ama eksiksiz bir spesifikasyon hazırlayın:
Tekrarlanabilir bir bağlam dokümanını her promptun başına yapıştırın, böylece çıktı tutarlı kalır.
Teslimleri küçük parçalara bölün:
“Bütün uygulamayı oluştur” demekten kaçının; bu, hata ayıklaması ve değişiklik yönetimi zor, karışık kod üretir.
Erken bir tıklanabilir kabuk çalıştırın:
Her adımın ardından uygulamayı çalıştırın ve “mutlu yol”u tıklayarak ilerleyin.
Ana kurallar:
Eğer AI, kolaylık için kimlik bilgilerini “hardcode” önerecekse, bunu bir yayımlama engeli olarak ele alın.
Güveni zedeleyecek şeyleri test edin:
Test başarısız olursa, AI’ye nedenini açıklayıp en küçük güvenli düzeltmeyi önermesini isteyin.
Sık reddedilme nedenleri ve çözümleri:
Gönderme öncesi TestFlight/Play test kanallarına yükleyin ve gerçek cihazlarda tam mutlu yolu çalıştırın.