Mobil Uygulama6 dk okuma

Nasıl Telefon Uygulaması Yaptırabilirim?

Telefon uygulaması yaptırmak platform, kapsam ve doğru ekip kararından geçer. Adım adım süreç, mağaza onayı ve sık yapılan hatalar.

Nasıl Telefon Uygulaması Yaptırabilirim?

Telefon uygulaması yaptırmak üç kararla başlar: hangi platform (iOS, Android ya da ikisi birden), hangi geliştirme yöntemi (native ya da cross-platform) ve kiminle çalışacağınız. Bu üçü netleşmeden alınan her karar yeniden yazılma riski taşır.

AppFellas 2013'ten beri girişimciler ve kurumsal firmalar için mobil uygulama geliştiriyor; iOS ve Android'i çoğunlukla React Native ile tek kod tabanından yürütüp mağaza yayın sürecini de üstleniyor. Fikriniz varsa mobil uygulama hizmetimize göz atabilir ya da doğrudan iletişime geçebilirsiniz.

1. Native mi, Cross-Platform mı?

Native geliştirme, iOS için Swift/Objective-C, Android için Kotlin/Java ile ayrı ayrı kod yazmak demektir. Cihazın tüm özelliklerine en hızlı erişimi sağlar ama iki ayrı kod tabanı, iki ayrı geliştirme süreci anlamına gelir. Cross-platform yaklaşımda (React Native, Flutter gibi) tek kod tabanından hem iOS hem Android için uygulama üretilir; bakım tek yerden yapılır ama kamera, konum, bildirim gibi bazı native özelliklerde ek entegrasyon gerekebilir.

KriterNative (Swift/Kotlin)Cross-Platform (React Native/Flutter)
Kod tabanıiOS ve Android ayrı ayrı yazılırTek kod tabanı, iki platforma derlenir
Bakımİki ayrı ekip/süreç gerekebilirTek yerden güncellenir
PerformansDonanıma en yakın performansÇoğu uygulama için yeterli, ağır grafik/oyun işlerinde native öne çıkar
Platforma özgü özelliklerAnında ve tam erişimÇoğunlukla kütüphane ile erişilir, bazı yeni API'lerde gecikme olabilir
Uygun olduğu durumOyun, AR/VR, donanım-yoğun uygulamalarSipariş, sadakat, randevu, içerik gibi çoğu ticari uygulama

Çoğu ticari uygulama için (sipariş, randevu, sadakat, içerik) cross-platform yeterli ve daha sürdürülebilirdir. Kamera efektleri, gerçek zamanlı oyun mantığı veya donanıma çok yakın işlemler gerektiren uygulamalarda native tercih edilir.

2. Uygulama Fikrinizi ve Kapsamınızı Netleştirin

Uygulamanın çözdüğü tek bir sorunu bir cümleyle yazabiliyor olmalısınız. "Kullanıcı X yapmak istediğinde Y sorunuyla karşılaşıyor, uygulama bunu Z şekilde çözüyor" formülü işe yarar. Bu cümleyi kuramıyorsanız, fikir henüz netleşmemiştir.

Ardından hedef kullanıcıyı ve rakip uygulamaları inceleyin. Mağazada benzer uygulamaların yorumlarını okumak, kullanıcıların neden şikayet ettiğini veya neyi eksik bulduğunu gösterir — bu, kendi özellik listenizi şekillendirmek için ücretsiz bir araştırmadır.

3. Özellik Listesini Daraltın: MVP Mantığı

İlk sürümde her özelliği koymak istemek, uygulama geliştirmede en sık yapılan hatadır. MVP (minimum uygulanabilir ürün) mantığı, sadece temel işlevi kanıtlayacak özellikleri ilk sürüme koymayı, gerisini kullanıcı geri bildirimine göre eklemeyi önerir.

  • Çekirdek işlev: Uygulamanın var olma sebebi olan tek akış (örneğin sipariş verme).
  • Hesap/giriş: Basit bir kayıt ve oturum açma akışı.
  • Bildirim: Kullanıcıyı geri çağıracak minimum push bildirim altyapısı.
  • Temel analitik: Kullanıcıların neyi kullanıp neyi kullanmadığını görmek için.

Ödeme entegrasyonu, çoklu dil, gelişmiş filtreleme gibi özellikler genellikle ikinci sürüme bırakılabilir. Az özellikle çıkıp gerçek kullanıcı verisiyle büyümek, tahmine dayalı kapsamlı bir ilk sürümden daha az risklidir.

4. Kim Geliştirecek: Kendiniz mi, Freelancer mı, Ajans mı?

Kodlama biliyorsanız ve basit bir uygulamaysa kendiniz geliştirebilirsiniz. Bilmiyorsanız üç seçenek var: freelancer, yazılım ajansı veya bünyenizde bir ekip kurmak. Freelancer daha düşük maliyetli olabilir ama tek kişiye bağımlılık, tasarım-geliştirme-test sürecinin tek elden yürümesi riskini taşır. Ajans, tasarımcı, geliştirici ve test sürecini bir arada sunar; proje bittiğinde elinizde bakımı yapılabilir bir kod tabanı kalması gerekir — bunu sözleşmede net şekilde isteyin.

Kimi seçerseniz seçin, daha önce yayınlanmış uygulamalarını mağazadan indirip inceleyin. Portföydeki ekran görüntüsü ile gerçek uygulama arasında fark olup olmadığını görmek, en güvenilir referans kontrolüdür.

SeçenekMaliyet esnekliğiKalite kontrolüBakım sürekliliği
Kendi geliştirmenizEn düşük maliyet, ama zaman maliyeti yüksekTamamen size bağlıSiz devam ettirdiğiniz sürece sürer
FreelancerGenelde ajanstan ucuzTek kişinin becerisiyle sınırlıKişi projeden ayrılırsa risk oluşur
Yazılım ajansıKapsamlı hizmet, buna göre fiyatlanırTasarım, geliştirme, test ayrı uzmanlıkla yürürEkip yapısı sayesinde sürdürülebilir
İç ekip (in-house)Sabit ve sürekli maliyetÜrüne tam hakimiyetEn yüksek süreklilik, ama kurulumu zaman alır

5. Kullanıcı Arayüzünü (UI) Tasarlayın

Arayüz, uygulamanın kullanıcıyla konuştuğu yerdir. Önce wireframe (tel çerçeve) ile ekranların düzenini kağıt üzerinde netleştirin, sonra renk, tipografi ve ikonografiyle görsel tasarıma geçin. Wireframe aşamasını atlayıp doğrudan görsel tasarıma başlamak, sonradan büyük yapısal değişiklikler gerektirir — bu da zaman kaybettirir.

AppFellas

Fikrinizi konuşalım.

Ücretsiz keşif görüşmesinde projenizi, bütçenizi ve zaman çizelgenizi netleştirelim.

6. Geliştirme ve Test

Geliştirme sırasında özellikler parça parça test edilmeli, hepsi bitince tek seferde test edilmemelidir. Fonksiyonel testler (özellik beklendiği gibi çalışıyor mu) ve kullanıcı testleri (gerçek kişiler uygulamayı nasıl kullanıyor) ayrı ayrı yapılmalı. Beta test grubu oluşturmak — arkadaş çevresi, mevcut müşteriler veya TestFlight/Play Console kapalı test kanalları üzerinden — yayından önce görülmeyen hataları ortaya çıkarır.

Test aşamasını tek tür testle sınırlamayın. Regresyon testi, yeni eklenen bir özelliğin eskiden çalışan bir akışı bozup bozmadığını kontrol eder. Performans testi, uygulamanın zayıf internet bağlantısında veya eski bir cihazda nasıl davrandığını gösterir. Güvenlik testi ise özellikle ödeme veya kişisel veri işleyen uygulamalarda atlanmaması gereken bir adımdır — kullanıcı verisinin nasıl saklandığı ve iletildiği baştan tasarlanmalıdır.

7. Mağaza Onay Süreci: App Store ve Google Play Farkı

Google Play, uygulamaları genellikle otomatik kontrollerle değerlendirir. Apple App Store'un inceleme süreci daha ayrıntılıdır ve insan incelemesi içerir; bu yüzden Apple tarafında red alma ihtimali daha yüksektir. İki mağazanın da kendi tasarım ve içerik kuralları (Human Interface Guidelines / Material Design ve mağaza politikaları) vardır, bunlara uymayan uygulamalar reddedilir.

Mağazaya gönderirken teknik onayla birlikte mağaza sayfasını da (ekran görüntüleri, açıklama, anahtar kelimeler) düşünün — buna uygulama mağazası optimizasyonu (ASO) denir. İyi bir başlık ve doğru kategori seçimi, uygulamanız yayınlandıktan sonra arama sonuçlarında bulunabilirliğini doğrudan etkiler.

  • Eksik veya yanıltıcı uygulama açıklaması
  • Gizlilik politikası linkinin olmaması
  • Çökme yapan veya boş ekran bırakan akışlar
  • Ödeme veya hesap silme akışının mağaza kurallarına uymaması
  • Test hesabı bilgisi verilmemesi (incelemeciler giriş yapamıyorsa uygulama reddedilir)

Red aldıysanız panelde yazan sebebi düzeltip yeniden gönderebilirsiniz; bu normal bir süreçtir, ilk seferde onay almak zorunlu değildir.

Süreç Ne Kadar Sürer, Neye Bağlıdır?

Kesin bir süre vermek yanıltıcı olur çünkü süre; kapsamın genişliğine, kaç platform için geliştirildiğine, dış sistemlerle (ödeme, harita, CRM) kaç entegrasyon yapılacağına ve tasarımın ne kadar özelleştirildiğine göre değişir. Basit bir sipariş takip uygulaması ile ödeme, çoklu dil ve gerçek zamanlı bildirim içeren bir uygulamanın iş yükü aynı değildir.

Süreyi tahmin etmek yerine kapsamı küçültmek elinizdeki en güçlü kontrol aracıdır: MVP mantığıyla ilerlediğinizde, ilk sürümün ne zaman biteceğini kapsam belirler, kapsamı siz belirlersiniz.

8. Lansman Sonrası: Ölçme ve İyileştirme

Uygulama yayınlandıktan sonra iş bitmiş sayılmaz. Kullanım analitiği (hangi ekranlar terk ediliyor, hangi özellik hiç kullanılmıyor) ilk haftaların en değerli verisidir. Mağaza yorumlarını takip edin, kritik hataları hızlı güncellemeyle kapatın, kullanıcıdan gelen tekrarlayan talepleri yol haritasına ekleyin.

Örnek Senaryo: Bir Kahve Zincirinin Sipariş Uygulaması

Fiziksel şubeleri olan bir kahve zincirinin sırası şöyle işleyebilir: önce tek akış netleştirilir ("müşteri şubeye gelmeden önce sipariş verip sırasını bekletmeden ürünü alsın"), MVP kapsamı menü + sepet + sipariş takibi + push bildirimle sınırlı tutulur, sadakat puanı ve kupon gibi özellikler ikinci sürüme bırakılır. React Native ile tek kod tabanından iOS ve Android eş zamanlı geliştirilir, kapalı beta grubunda şube çalışanları ve düzenli müşteriler test eder, geri bildirimler yayından önce akışa işlenir.

Şube sayısı arttıkça uygulamaya sadakat puanı, çoklu şube seçimi ve kurye entegrasyonu gibi özellikler ikinci ve üçüncü sürümlerde eklenir. Böylece ilk yatırım küçük kalır, her yeni özellik gerçek kullanım verisiyle gerekçelendirilir.

Sık Yapılan Hatalar

  • İlk sürüme her özelliği sığdırmaya çalışmak ve lansmanı geciktirmek
  • Wireframe aşamasını atlayıp doğrudan görsel tasarıma başlamak
  • Beta test grubu olmadan doğrudan mağazaya göndermek
  • Gizlilik politikası ve hesap silme akışı gibi mağaza zorunluluklarını sona bırakmak
  • Lansmandan sonra analitik kurmayı unutmak — hangi özelliğin işe yaradığını bilmeden karar vermek

Telefon uygulaması yaptırmak, doğru sırayla ilerleyen bir süreçtir: netleşmiş bir fikir, daraltılmış bir kapsam, doğru platform kararı ve test edilmiş bir ürün. Fikrinizi konuşmak isterseniz bize yazabilir, önce yaptığımız işlere buradan göz atabilirsiniz.

Sık sorulan sorular

Telefon uygulaması yaptırmak için kodlama bilmem gerekir mi?

Hayır. Bir freelancer, yazılım ajansı veya geliştirme ekibiyle çalışarak kod bilmeden de uygulama yaptırabilirsiniz. Sizden beklenen, uygulamanın ne yapacağını ve hangi sorunu çözeceğini net anlatabilmenizdir.

Önce iOS mü Android mi geliştirmeliyim, yoksa ikisi birlikte mi?

Cross-platform araçlarla (React Native, Flutter) ikisini aynı anda, tek kod tabanından geliştirmek artık yaygın ve genellikle daha az bakım yükü getirir. Kaynaklarınız çok kısıtlıysa hedef kitlenizin ağırlıklı kullandığı platformdan başlamak da bir seçenektir.

Uygulamam App Store'dan reddedilirse ne olur?

Panelde red sebebi yazılı olarak bildirilir. Sebebi düzeltip uygulamayı yeniden gönderebilirsiniz; bu App Store sürecinin normal bir parçasıdır ve uygulamanızın kalitesizliği anlamına gelmez.

MVP ile tam kapsamlı uygulama arasındaki fark nedir?

MVP, uygulamanın çekirdek işlevini kanıtlayan en küçük sürümdür. Tam kapsamlı ürün ise kullanıcı geri bildirimiyle zaman içinde MVP'nin üzerine eklenen özelliklerin toplamıdır. İlk sürümde her şeyi koymaya çalışmak yerine önce çekirdek işlevi doğrulamak daha az risklidir.

Uygulama yayınlandıktan sonra ne yapmalıyım?

Analitik verisini takip edin, mağaza yorumlarını okuyun, kritik hataları hızlı güncellemeyle kapatın. Lansman bir bitiş değil, gerçek kullanıcı verisiyle ürünü iyileştirmeye başladığınız noktadır.

Paylaş

Bu konuyu projenize uygulayalım.

Yazıda anlatılanları kendi ürününüzde nasıl hayata geçireceğinizi ücretsiz keşif görüşmesinde konuşalım.