ELIYTE Blog

Mobil uygulama geliştirme rehberi: fikirden mağazaya

Uygulama fikri ile App Store/Google Play'deki canlı ürün arasında geçen yol, çoğu kişinin sandığından farklıdır: kodun kendisinden çok doğrulama, cihaz testi ve mağaza süreçleri işi belirler. Bu rehber o yolun adımlarını anlatır.

Mobil uygulama yaptırma süreci, web sitesi sürecinin yakın akrabasıdır; fark iki yerdedir — cihaz testi katmanı ve mağaza inceleme süreçleri. Bu rehber, fikirden mağaza yayınına kadar adımları ve her adımda dikkat edilecekleri anlatır.

1. Fikir doğrulama: "kim, neden indirsin?"

Geliştirmeden önce sorulacak soru "nasıl yapılır" değil, "kim neden kullanır"dır. İyi doğrulama üç cevabı netleştirir: hedef kullanıcının bu soruyu bugün nasıl çözdüğü (el ile, tabloyla, mevcut uygulamayla), sizin çözümün neyi azalttığı ve kullanıcı gerçekten kaydolmaya/kullanmaya istekli mi. Bu cevaplar kapsamı da belirler: ilk sürümde hangi özellik olmalı, hangisi sonraya kalmalı.

2. MVP ve prototip

Web tarafında anlattığımız MVP disiplini burada daha da kritiktir: uygulama geliştirmenin döngüleri uzundur, yanlış yolda ilerlemenin bedeli büyüktür. İlk hedef, çekirdek değeri taşıyan çalışan prototip — kullanıcı akışını uçtan uca gerçekleştiren yalın sürüm. Bu prototipte akış test edilir, kapsam ondan sonra büyütülür. Biz her projeye çalışan demo ile başlarız; demo beğenilmeden ödeme alınmaz.

3. Platform kararı: tek kod mu, native mi?

Çoğu iş uygulaması ve standart tüketici uygulaması için çapraz platform (tek kod, iki mağaza) doğru tercihtir — bakım tek yerde, sürümler eşzamanlı, maliyet tek tabana bölünür. Native ayrı geliştirme, performansın donanıma derinden bağlı olduğu durumlar için saklıdır (ağır oyun motorları, kamera/AR yoğun uygulamalar). Teknik karşılaştırmanın ayrıntısı React Native çapraz platform rehberimizde.

4. Cihaz testleri: laboratuvar dünyada değil, cepte

Uygulama, geliştiricinin telefonunda sorunsuz çalışıp eski bir Android'de takılabilir. Yayın öncesi test matrisi: küçük/büyük ekranlar, eski işletim sistemi sürümü, zayıf bağlantı, arka planda geçiş, izin redleri (kamera, bildirim). Bu matris ne kadar geniş, mağaza redleri ve ilk haftanın kötü yorumları o kadar az olur.

5. Mağaza yayın süreçleri

İki mağazanın da inceleme takvimi sürece dahil edilmelidir. En yaygın red nedenleri: eksik gizlilik politikası ve KVKK aydınlatma metni, App Store'un "giriş yaptırmadan inceleme" gereksinimi için sağlanmayan test hesabı, çöken akışlar ve ekran görüntüsü/uygulama uyuşmazlığı. Yayın öncesi mağaza denetim listesi bu redlerin çoğunu önceden yakalar.

6. Yayın sonrası: bakım ve ölçüm

Yayın, ürünün açılışıdır: işletim sistemi güncellemeleriyle uyum sürümleri, kullanıcı geri bildiriminden gelen iyileştirme döngüleri, çökme ve oturum ölçümü. Kaynak kod ve mağaza hesaplarının müşteri adına tutulması, web tarafındakiyle aynı devir ilkesidir. Sürecin yazılım tarafındaki genel çerçevesi ihtiyaca özel yazılım süreci rehberimizde anlatılmıştır.

ELIYTE'nin yaklaşımı

Biz mobil uygulamaları tek kod tabanıyla, çalışan prototipten mağaza yayınına kadar bu adımlarla yürütürüz; kendi ürünlerimizden biri olan Kanban Eliyte bu sürecin çıktısıdır. Fikrinizi anlatın; çalışan bir demo önerisiyle genellikle aynı iş günü içinde döneriz. İletişim: iletisim@eliyte.com veya WhatsApp +90 537 863 86 00.

UYGULAMA FİKRİNİZİ MAĞAZAYA KADAR BİRLİKTE TAŞIYALIM

Fikrinizi anlatın; çalışan bir demo önerisiyle genellikle aynı iş günü içinde dönelim.

iletisim@eliyte.com

Sık sorulan sorular

Mobil uygulama yaptırma süreci nasıl ilerler?

Web sitesi sürecine benzer ama daha uzun test katmanıyla: fikir doğrulama ve kapsam, çalışan prototip, geliştirme döngüleri, cihaz testleri, mağaza yayını ve bakım. Fark, iki mağazanın (App Store, Google Play) inceleme süreçlerinin takvime eklenmesi gerektiğidir.

iOS ve Android için ayrı uygulama mı, tek kod mu?

Çoğu proje için tek kod tabanı (çapraz platform) doğru tercihtir: aynı özellikler iki platforma da çıkar, bakım tek yerde yürütülür. Performansın cihaz donanımına derinden bağlı olduğu (ağır oyunlar, artırılmış gerçeklik) özel durumlarda native ayrı geliştirme değerlendirilir.

Uygulama mağaza onayını neden alamayabilir?

En yaygın nedenler: eksik gizlilik politikası, giriş yaptırmadan çalışan demo olmaması (App Store'un inceleme gereksinimi), çöken ekranlar ve metadata uyuşmazlığı. Yayın öncesi mağaza denetim listesiyle bu redler büyük ölçüde önlenebilir.

Uygulama yayına girdikten sonra ne yapılır?

Üç süreklilik yürütülür: sürüm bakımı (işletim sistemi güncellemeleriyle uyum), kullanıcı geri bildirimlerinden gelen iyileştirme döngüleri ve ölçüm (çökme oranı, oturum süresi). Yayın bir bitiş değil, ürünün kullanıma açılışıdır.