Bir mobil uygulamanın App Store ve Google Play’de yayına alınması, geliştirme sürecinin son butonuna basmak gibi görünür. Sahada ise durum daha farklıdır: mağaza hesabı doğrulaması, paket imzalama, gizlilik beyanları, test kullanıcıları, ekran görüntüleri, sürüm açıklamaları, App Review notları, Google Play politika formları ve yayın sonrası crash takibi aynı zincirin parçalarıdır.
Özellikle kurumsal uygulamalarda yayınlama aşaması “APK/IPA yükledik, bitti” yaklaşımıyla yönetilirse, proje canlıya çıkmadan önce ret alabilir veya canlıya çıktıktan sonra mağazadan kaldırılabilir. Sağlık, finans, e-ticaret, üyelikli platform, konum kullanan servis, abonelikli içerik veya yapay zekâ destekli özellik barındıran uygulamalarda bu risk daha da artar.
Atalay Tech’in mobil uygulama geliştirme projelerinde yayın süreci, geliştirme planının en başında düşünülür. Çünkü App Store ve Google Play, sadece son teslim kanalı değil; uygulamanın güvenlik, performans, veri kullanımı ve kullanıcı deneyimi açısından denetlendiği iki ana kalite kapısıdır.
App Store Google Play yayınlama süreci, mobil uygulamanın iOS ve Android mağazalarında kullanıcıya açılmadan önce geçtiği teknik, hukuki, görsel ve operasyonel kontrollerin tamamıdır.
Bu süreçte genellikle şu başlıklar birlikte ilerler:
Apple, App Store inceleme sürecinde uygulamaları güvenlik, performans, iş modeli, tasarım ve yasal uygunluk başlıkları altında değerlendirir. Apple’ın resmi App Review Guidelines dokümanı bu çerçeveyi açıkça belirtir. Google tarafında ise Play Console üzerinden mağaza bilgileri, uygulama erişimi, veri güvenliği, hedef kitle, reklam kullanımı ve politika beyanları ayrı ayrı yönetilir. Google’ın Play Console yayınlama rehberi bu hazırlığın incelemeye gönderilmeden önce tamamlanmasını ister.
Bu yüzden yayınlama süreci, yazılım geliştirme ekibi, ürün sahibi, tasarımcı, hukuk/KVKK danışmanı ve operasyon ekibinin birlikte çalıştığı bir teslim fazıdır.
Yayın öncesi hazırlık, uygulamanın mağaza tarafından reddedilmesini önleyen en kritik aşamadır. Bu aşamada yalnızca uygulamanın açılması değil; gerçek kullanıcı senaryolarının tamamlanması, hatalı akışların yakalanması ve mağaza politikalarının karşılanması gerekir.
Örneğin üyelikli bir mobil uygulamada sadece “kayıt ol” ekranının çalışması yetmez. Apple ve Google inceleme ekipleri, test hesabıyla giriş yapabilmeli, kapalı özellikleri görebilmeli, ödeme veya abonelik varsa test akışına ulaşabilmeli ve hesap silme gibi yasal gereklilikleri deneyimleyebilmelidir.
| Hazırlık Alanı | App Store İçin Gereken | Google Play İçin Gereken |
|---|---|---|
| Geliştirici hesabı | Apple Developer Program | Google Play Console |
| Ücret modeli | 99 USD/yıl | 25 USD tek seferlik |
| Test dağıtımı | TestFlight | Internal / closed testing |
| Paket formatı | IPA | AAB önerilir |
| Mağaza yönetimi | App Store Connect | Play Console |
| Veri beyanı | App Privacy | Data Safety formu |
| İnceleme notu | Review Notes | App access instructions |
| Yayın kontrolü | Manual release / phased release | Managed publishing / staged rollout |
Apple Developer Program’ın yıllık ücreti resmi olarak 99 USD’dir. Google Play Console tarafında ise geliştirici hesabı için 25 USD tek seferlik kayıt ücreti bulunur. Bu tutarlar mağaza hesabı ücretidir; uygulama geliştirme, test, bakım, sunucu veya tasarım maliyetini kapsamaz. Kaynaklar için Apple’ın membership sayfası ve Google’ın Play Console başlangıç dokümanı incelenebilir.
Atalay Tech tarafında yayın öncesi kontrol listesi genellikle geliştirme sürecinin son haftasına bırakılmaz. Keşif aşamasında uygulamanın ödeme, üyelik, konum, kamera, galeri, bildirim, yapay zekâ, sağlık verisi veya üçüncü taraf API kullanıp kullanmadığı netleştirilir. Çünkü bu özelliklerin her biri mağaza incelemesinde farklı beyan ve izin gerektirir.
App Store ve Google Play yayınlama sürecinin ilk pratik adımı geliştirici hesabıdır. Uygulamanın kimin adıyla yayınlanacağı bu noktada belirlenir.
Bir şirket için geliştirilen uygulama, çoğu zaman şirketin kendi geliştirici hesabı üzerinden yayınlanmalıdır. Böylece mağazada görünen yayıncı adı, marka güveni ve hesap sahipliği müşteride kalır. Ajans hesabı üzerinden yayınlamak kısa vadede kolay görünebilir; fakat uzun vadede uygulama devri, ödeme yönetimi, mağaza içi sözleşmeler ve marka sahipliği açısından sorun çıkarabilir.
Bireysel hesap, tek kişi adına açılır. Kurumsal hesap ise şirket adına açılır ve genellikle daha profesyonel görünür. Kurumsal uygulama, B2B platform, e-ticaret, sağlık, eğitim veya finans çözümü geliştiriliyorsa kurumsal hesap tercih edilmelidir.
| Kriter | Bireysel Hesap | Kurumsal Hesap |
|---|---|---|
| Mağazada görünen ad | Kişi adı | Şirket adı |
| Marka güveni | Sınırlı | Daha güçlü |
| Ekip yönetimi | Daha kısıtlı | Daha kontrollü |
| Devir süreci | Riskli olabilir | Daha düzenli |
| B2B uygunluğu | Düşük/orta | Yüksek |
| Önerilen kullanım | Kişisel proje | Ticari ürün |
Örneğin bir girişimci MVP doğrulaması için bireysel hesapla başlayabilir. Fakat yatırım görüşmeleri, kurumsal müşteri edinimi veya marka bilinirliği hedefleniyorsa kurumsal hesap daha sağlıklı olur.
Bu karar, uygulamayı sadece yayına almakla ilgili değildir. Uygulamanın kime ait görüneceğini, kullanıcıların markaya güvenini ve ilerideki operasyonel esnekliği etkiler.
Yayın aşamasında teknik ekibin hazırladığı dosya, mağazaya gönderilecek production build’dir. iOS tarafında IPA, Android tarafında ise genellikle Android App Bundle yani AAB kullanılır.
Bu build, geliştirme ortamındaki test uygulamasıyla aynı şey değildir. Production build içinde debug logları temizlenmiş, ortam değişkenleri doğru ayarlanmış, API endpointleri canlı sunucuya yönlendirilmiş, push notification sertifikaları bağlanmış ve hata takip araçları yapılandırılmış olmalıdır.
React Native, Flutter veya native geliştirme fark etmeksizin sürümleme disiplini kritik önemdedir. iOS tarafında build number, Android tarafında versionCode doğru artırılmazsa mağaza yeni sürümü kabul etmez.
React Native mobil uygulama geliştirme projelerinde tek kod tabanı avantaj sağlar; ancak iOS ve Android yayın ayarları yine ayrı ayrı yönetilir. Örneğin push notification izin metni iOS’ta farklı bir kullanıcı deneyimiyle gösterilirken, Android’de bildirim izni ve kanal yönetimi farklı davranabilir.
| Teknik Başlık | iOS | Android | Dikkat Edilecek Nokta |
|---|---|---|---|
| Paket kimliği | Bundle ID | Package name | Sonradan değiştirmek zordur |
| Build dosyası | IPA | AAB | Store uyumluluğu kontrol edilmeli |
| Sürüm alanı | Version + build | Version name + versionCode | Her gönderimde artırılmalı |
| İmza | Apple sertifikaları | Upload key / app signing | Kaybolursa süreç uzar |
| Test kanalı | TestFlight | Internal/closed testing | Yayın öncesi gerçek cihaz testi şart |
| Crash takibi | Xcode / üçüncü taraf araçlar | Play Console / üçüncü taraf araçlar | İlk 48 saat yakından izlenmeli |
Teknik build hazırlığında sık yapılan hata, canlı API ile test veritabanını karıştırmaktır. Bir uygulama mağazadan onay alsa bile canlı kullanıcıların test verisi görmesi ciddi güven kaybı oluşturur. Bu nedenle staging ve production ortamları ayrı tutulmalıdır.
Kullanıcı uygulamayı indirmeden önce mağaza sayfasıyla karşılaşır. Mağaza sayfası yalnızca pazarlama alanı değildir; inceleme ekibinin de uygulamayı anlamasını sağlar.
Başarılı bir mağaza sayfasında şu öğeler net olmalıdır:
Ekran görüntüleri gerçek uygulama arayüzünü yansıtmalıdır. Uygulamada olmayan özelliklerin görselde gösterilmesi, kullanıcı şikâyetine ve mağaza politikasına aykırılığa yol açabilir.
Örneğin randevu uygulaması geliştirildiyse ekran görüntülerinde yalnızca “modern tasarım” vurgusu yapmak yeterli değildir. Kullanıcı hangi adımlarla randevu alacağını, bildirim alıp almayacağını, profilini nasıl yöneteceğini ve ödeme varsa ödeme akışının nerede başladığını anlayabilmelidir.
| Mağaza Öğesi | İyi Uygulama | Riskli Uygulama |
|---|---|---|
| Uygulama adı | Marka + işlev netliği | Anahtar kelime yığını |
| Açıklama | Gerçek özellikleri anlatır | Abartılı vaat içerir |
| Ekran görüntüsü | Canlı arayüzden alınır | Uygulamada olmayan özellik gösterir |
| İkon | Sade ve ayırt edici | Başka marka/logoya benzer |
| Kategori | Kullanım amacına uygun | Trafik almak için yanlış seçilmiş |
| Gizlilik bağlantısı | Erişilebilir ve güncel | Boş sayfa veya hatalı link |
Mobil uygulama mağaza sayfası, SEO’dan çok ASO yani App Store Optimization alanına girer. Ancak web tarafındaki marka görünürlüğüyle birlikte düşünülmelidir. Uygulama sayfası, web sitesi ve destek sayfası aynı dili konuşmalıdır.
App Store ve Google Play yayınlama sürecinde en çok gözden kaçan alanlardan biri veri beyanıdır. Uygulama hangi verileri topluyor? Bu veriler kullanıcıyla ilişkilendiriliyor mu? Üçüncü taraf servislerle paylaşılıyor mu? Kullanıcı hesabını silebiliyor mu? Konum, kamera, mikrofon, galeri veya kişi listesi gibi izinler gerçekten gerekli mi?
Bu sorulara net cevap verilemediğinde mağaza incelemesi uzayabilir. Daha kötüsü, uygulama yayına çıktıktan sonra politika ihlali nedeniyle askıya alınabilir.
Örneğin bir sosyal ağ uygulaması profil fotoğrafı, mesajlaşma verisi, bildirim tokenı ve cihaz bilgisi işleyebilir. Bir e-ticaret uygulaması teslimat adresi, ödeme işlem referansı ve sipariş geçmişi tutabilir. Bir sağlık uygulaması ise daha hassas veri kategorilerine yaklaşabilir. Her biri için mağaza beyanı, KVKK metni ve uygulama içi izin akışı farklı tasarlanmalıdır.
Google Play’in son yıllarda güvenlik tarafındaki denetimleri artırdığı görülüyor. Google’ın 2025 güvenlik raporlarına yansıyan açıklamalarında, politika ihlali yapan milyonlarca uygulamanın engellendiği veya reddedildiği belirtilmiştir. Bu yaklaşım, geliştiriciler için “formu rastgele doldurmak” döneminin kapandığını gösterir. Google’ın geliştirici politikaları ve Play Console veri güvenliği alanı bu yüzden dikkatle ele alınmalıdır.
Atalay Tech’in mobil uygulama, web platformu ve AI entegrasyonu projelerinde gizlilik tarafı yalnızca metin olarak düşünülmez. Teknik mimaride token yönetimi, API yetkilendirme, log maskeleme, kullanıcı silme, veri saklama süresi ve üçüncü taraf entegrasyonlar birlikte değerlendirilir.
Mağaza inceleme ekibi uygulamayı test eder; fakat kalite kontrol ekibinizin yerine geçmez. Uygulama mağazaya gönderilmeden önce gerçek cihazlarda test edilmelidir.
Sadece simülatörde çalışan bir uygulama, gerçek cihazda kamera izni, bildirim izni, ağ kopması, düşük bellek, farklı ekran boyutu veya eski işletim sistemi nedeniyle hata verebilir. Bu yüzden yayın öncesi test planı cihaz çeşitliliği içermelidir.
Ayşe, 28 yaşında freelance tasarımcı. Yeni bir pazar yeri uygulamasına giriyor, hesap oluşturuyor, portföy görsellerini yüklüyor, bildirim izni veriyor, ödeme almak için profilini tamamlıyor ve ilk teklifini gönderiyor.
Bu senaryoda test edilmesi gereken noktalar şunlardır:
Buna benzer persona bazlı testler, mağaza reddinden daha önemli bir problemi yakalar: gerçek kullanıcı kaybı. İlk sürümde kötü deneyim yaşayan kullanıcıların geri dönmesi zordur.
| Test Alanı | Kontrol Edilecek Nokta | Örnek Hata |
|---|---|---|
| Giriş/kayıt | E-posta, SMS, sosyal giriş | Test hesabı çalışmıyor |
| İzinler | Kamera, konum, bildirim | İzin reddinde ekran kilitleniyor |
| Performans | Açılış, listeleme, medya | İlk ekran 8 saniyede açılıyor |
| API | Timeout, 500 hata, yetki | Hata mesajı kullanıcıya ham dönüyor |
| Ödeme | Başarılı/başarısız işlem | Başarısız ödeme sipariş oluşturuyor |
| Hesap silme | Kullanıcı talebi | Menüde görünmüyor |
| Dil | TR/EN içerik | Mağaza açıklamasıyla uygulama dili uyuşmuyor |
Yayın öncesi testte amaç sıfır hata iddiası değildir. Amaç, mağaza incelemesini ve ilk kullanıcı deneyimini bozacak kritik hataları yayından önce yakalamaktır.
App Store incelemesi, Apple’ın App Store Connect üzerinden gönderilen uygulamayı değerlendirdiği aşamadır. Apple; uygulama performansına, çökme durumuna, yanıltıcı açıklamalara, gizlilik beyanına, ödeme sistemine, hesap silme gereksinimlerine ve tasarım kalitesine bakar.
Apple’ın resmi App Review sayfasında, uygulamaların ve güncellemelerin güvenli ve güvenilir bir deneyim sunmak için incelendiği belirtilir. Bu yüzden review notes alanı ciddiye alınmalıdır.
Review notes içine şu bilgiler yazılabilir:
Örneğin sadece davet koduyla girilen bir uygulama geliştirildiyse, Apple inceleme ekibi bu davet koduna sahip değilse uygulamayı reddedebilir. Bu ret, yazılım hatasından değil; inceleme erişimi eksikliğinden kaynaklanır.
App Store’da sık görülen ret nedenleri şunlardır:
Ret almak projenin başarısız olduğu anlamına gelmez. Fakat ret yanıtı teknik, hukuki ve ürün açısından doğru okunmalıdır. Panikle rastgele düzeltme yapmak yerine, ilgili guideline maddesiyle eşleştirip net yanıt vermek gerekir.
Google Play tarafında yayın süreci Play Console üzerinden yönetilir. Uygulama dosyası, mağaza bilgileri, veri güvenliği formu, içerik derecelendirmesi, hedef kitle, reklam beyanı, uygulama erişimi ve test kanalları birlikte değerlendirilir.
Google Play’de managed publishing ve staged rollout gibi özellikler, yayını daha kontrollü yapmayı sağlar. Google’ın Publishing overview dokümanı, planlanan yayın tarihinden önce değişikliklerin erken gönderilmesini önerir. Bu pratik özellikle kampanya, lansman veya basın duyurusu yapılacak projelerde önemlidir.
Google Play’de Android App Bundle kullanımı, cihazlara göre optimize edilmiş dağıtım sağlar. Ancak bu teknik avantajın mağaza hazırlığıyla desteklenmesi gerekir. Veri güvenliği formu hatalı doldurulmuşsa, uygulama teknik olarak kusursuz olsa bile inceleme süreci uzayabilir.
Google Play’de sık görülen sorunlar şunlardır:
Android tarafında cihaz çeşitliliği daha geniştir. Bu yüzden sadece üst segment bir cihazla test yapmak yeterli değildir. Düşük RAM’li cihaz, farklı ekran oranı, eski Android sürümü ve üreticiye özel davranışlar dikkate alınmalıdır.
Yayınlama maliyeti ikiye ayrılır: mağaza hesap ücretleri ve profesyonel yayın hazırlığı maliyeti. Apple ve Google’ın resmi hesap ücretleri düşük görünse de, gerçek maliyeti belirleyen şey uygulamanın karmaşıklığıdır.
Basit bir içerik uygulamasının yayın hazırlığı birkaç gün içinde tamamlanabilir. Üyelik, ödeme, bildirim, sohbet, harita, medya yükleme, abonelik, AI entegrasyonu veya admin paneli içeren bir uygulamada yayın hazırlığı çok daha geniş kapsamlıdır.
Aşağıdaki tablo tahmini proje kapsamı mantığıyla okunmalıdır. Net bütçe; tasarım durumu, kod kalitesi, mağaza hesabı sahipliği, backend hazır olup olmadığı ve test ihtiyacına göre değişir.
| Kapsam | Tipik İçerik | Tahmini Yayın Hazırlığı | Tahmini Maliyet Aralığı |
|---|---|---|---|
| MVP uygulama | Giriş, profil, temel listeleme | 3-7 iş günü | 30.000-80.000 TL + KDV |
| Orta ölçek | Bildirim, API, admin panel, medya | 1-3 hafta | 80.000-180.000 TL + KDV |
| Kurumsal uygulama | Rol bazlı yapı, ödeme, KVKK, entegrasyon | 3-6 hafta | 180.000-400.000 TL + KDV |
| Sorunlu mevcut proje | Eski kod, ret geçmişi, eksik belge | 2-8 hafta | 120.000-500.000 TL + KDV |
Bu tablo, yalnızca yayın hazırlığı ve mağaza uyumluluk çalışmaları için düşünülmelidir. Sıfırdan ürün geliştirme, tasarım, backend, panel, API ve bakım kapsamı farklı bütçelendirilir. Kapsamı daha net görmek isteyenler mobil uygulama fiyatları aracını kullanarak ilk fikir seviyesinde maliyet aralığı çıkarabilir.
mobil uygulama yaptırmak isteyen işletmeler için yayın sürecinin baştan planlanması daha sağlıklıdır. Çünkü uygulama bittikten sonra “mağazaya uygun hale getirme” çalışması, çoğu zaman en başta doğru tasarlamaktan daha maliyetli olur.
App Store veya Google Play’den ret gelmesi, yayının tamamen durduğu anlamına gelmez. Ret mesajı doğru analiz edilirse süreç hızlıca toparlanabilir.
İlk yapılması gereken şey, ret gerekçesini teknik hata, politika uyumsuzluğu, eksik bilgi veya ürün deneyimi problemi olarak sınıflandırmaktır. Her ret aynı şekilde çözülmez.
| Ret Türü | Olası Neden | Doğru Yaklaşım |
|---|---|---|
| Teknik ret | Crash, login hatası, boş ekran | Hata logu incelenir, yeni build gönderilir |
| Politika ret | Veri, ödeme, içerik, izin | İlgili politika maddesiyle düzeltme yapılır |
| Erişim ret | Test hesabı yok, kapalı ekran | Review notes / app access bilgisi güncellenir |
| Metadata ret | Yanıltıcı açıklama, hatalı görsel | Mağaza sayfası revize edilir |
| Tasarım/işlev ret | Minimum fayda yok, webview algısı | Ürün deneyimi güçlendirilir |
Ret cevabına duygusal değil, operasyonel yaklaşmak gerekir. “Bizde çalışıyor” demek yerine, inceleme ekibinin hangi cihazda, hangi adımda, hangi hesapla sorun yaşadığını anlamak gerekir.
Atalay Tech projelerinde ret yönetimi, tek seferlik cevap yazma işi olarak ele alınmaz. Gerekirse build yenilenir, review notes güncellenir, test hesabı sıfırlanır, gizlilik linki düzeltilir ve mağaza açıklaması yeniden düzenlenir.
Uygulama yayına çıktıktan sonra süreç bitmez. İlk 7 gün; crash oranı, kullanıcı yorumları, indirme kaynağı, kayıt dönüşümü ve mağaza görünürlüğü açısından en kritik dönemdir.
Örneğin 10.000 reklam tıklaması alan bir uygulamada kayıt ekranı hatalıysa, mağaza yayını teknik olarak başarılı olsa bile iş hedefi başarısız olur. Benzer şekilde uygulama açılış süresi yüksekse kullanıcılar ilk oturumda terk edebilir.
İlk hafta takip edilmesi gereken göstergeler:
Bu aşamada teknik destek ve bakım kritik hale gelir. Mağazaya çıkmış bir uygulama, özellikle ilk kampanya döneminde izlenmeden bırakılmamalıdır. Küçük bir API hatası bile yüzlerce kullanıcıyı etkileyebilir.
Yayın sonrası bakım yalnızca hata düzeltme değildir. Yeni işletim sistemi sürümleri, mağaza politika değişiklikleri, güvenlik yamaları, kütüphane güncellemeleri ve kullanıcı geri bildirimleri düzenli olarak yönetilmelidir.
Atalay Tech’in mobil uygulama, web platformu, yönetim paneli ve AI entegrasyonu projelerinde gördüğü en net gerçeklerden biri şudur: yayın süreci sona bırakıldığında maliyet ve stres artar.
Örneğin uygulamada hesap silme ihtiyacı baştan düşünülmemişse, yayın öncesi yalnızca bir buton eklemek yetmeyebilir. Backend’de kullanıcı verilerinin nasıl anonimleştirileceği, ilişkili siparişlerin nasıl saklanacağı, mesajların ne olacağı ve log kayıtlarının nasıl yönetileceği de tasarlanmalıdır.
Benzer şekilde yapay zekâ destekli bir özellik üçüncü taraf API’ye kullanıcı verisi gönderiyorsa, bu durum hem uygulama içi izin metinlerinde hem de mağaza veri beyanlarında karşılık bulmalıdır. AI özelliği “sonradan eklenen küçük bir detay” gibi görünse de mağaza politikaları açısından veri işleme meselesine dönüşebilir.
Sağlıklı bir yayın planı şu sırayla ilerler:
Bu yaklaşım, blog içeriğinin satın alma niyetini karşılaması için değil; doğru proje yönetimi perspektifi vermesi için önemlidir. Hizmet kapsamını detaylı incelemek isteyen işletmeler ana sayfadaki mobil hizmet yapısına, teknik kapsam ve süreç detaylarına ayrı olarak bakmalıdır.
Basit ve iyi hazırlanmış bir uygulamada yayın hazırlığı birkaç iş günü içinde tamamlanabilir; ancak mağaza inceleme süresi, hesap doğrulaması, test süreci ve olası retler nedeniyle toplam takvim uzayabilir. Kurumsal uygulamalarda 1-3 haftalık yayın penceresi ayırmak daha gerçekçidir. Özellikle ödeme, abonelik, konum, sağlık verisi, mesajlaşma veya kullanıcı üretimli içerik barındıran projelerde mağaza beyanları daha dikkatli hazırlanmalıdır. Kampanya veya lansman tarihi varsa uygulamayı son gün incelemeye göndermek risklidir. En doğru yaklaşım, mağaza hazırlığını geliştirme sürecinin sonuna değil, proje planının içine yerleştirmektir.
Uygulamayı resmi App Store ve Google Play mağazalarında yayınlamak için geliştirici hesabı gerekir. iOS tarafında Apple Developer Program üyeliği, Android tarafında ise Google Play Console hesabı kullanılır. Teorik olarak bir ajans kendi hesabından yayın yapabilir; fakat ticari projelerde bu önerilmez. Uygulamanın marka sahipliği, mağazada görünen yayıncı adı, ödeme yönetimi, yorumlara erişim, uygulama devri ve uzun vadeli kontrol açısından hesabın işletmeye ait olması daha sağlıklıdır. Ajans teknik süreci yönetebilir; ancak hesap sahipliği mümkün olduğunca marka tarafında kalmalıdır.
Normal şartlarda aynı uygulamayı düzeltip yeniden incelemeye göndermek için mağazaya ayrıca ret başına ücret ödenmez. Fakat ret süreci zaman ve operasyon maliyeti oluşturur. Teknik ekip yeni build hazırlayabilir, mağaza açıklaması değişebilir, gizlilik politikası güncellenebilir veya uygulama içinde akış revizyonu gerekebilir. Bu nedenle retlerin asıl maliyeti, doğrudan mağaza ücreti değil; kaybedilen zaman, lansman gecikmesi ve ek geliştirme eforudur. İyi hazırlanmış test hesabı, doğru review notes, güncel gizlilik linki ve net veri beyanları ret riskini ciddi ölçüde azaltır.
Hedef kitleye göre sadece Android ile başlamak mantıklı olabilir; ancak bu karar pazar, bütçe ve ürün stratejisine bağlıdır. Türkiye’de Android cihaz kullanımı geniş olduğu için MVP testlerinde Android öncelikli ilerlemek bazı projelerde avantaj sağlar. Fakat premium kullanıcı kitlesi, abonelik modeli, kurumsal müşteri veya iOS ağırlıklı hedef segment varsa App Store’u dışarıda bırakmak dönüşüm kaybına yol açabilir. React Native gibi çapraz platform teknolojiler, iOS ve Android’i aynı ürün mantığıyla geliştirme avantajı sunar. Yine de yayın süreci her mağaza için ayrı ayrı yönetilmelidir.
Evet, fakat anahtar kelime kullanımı doğal olmalıdır. Uygulama adı, kısa açıklama, uzun açıklama ve ekran görüntüleri kullanıcıya gerçek değeri anlatmalıdır. Sadece arama hacmi için tekrarlanan kelimeler mağaza sayfasını zayıflatır ve kullanıcı güvenini düşürür. Örneğin bir randevu uygulaması “en iyi randevu, hızlı randevu, kolay randevu” gibi tekrarlar yerine; hangi kullanıcı için hangi problemi çözdüğünü, bildirimleri, takvim entegrasyonunu ve iptal akışını net anlatmalıdır. Mağaza optimizasyonu, pazarlama metni ile ürün gerçekliği arasında denge ister.
Pratikte evet. Mobil işletim sistemleri, cihazlar, mağaza politikaları ve üçüncü taraf servisler sürekli değişir. Bugün çalışan bir bildirim entegrasyonu, ileride işletim sistemi güncellemesi veya sertifika problemi nedeniyle bozulabilir. Sunucu tarafındaki API hataları, ödeme sağlayıcı değişiklikleri, güvenlik güncellemeleri ve kullanıcı yorumları da düzenli takip edilmelidir. Bakım yapılmayan uygulamalarda crash oranı artabilir, mağaza puanı düşebilir ve kullanıcı kazanım maliyeti boşa gidebilir. Bu nedenle yayın sonrası dönem, geliştirme sürecinin devamı olarak görülmelidir.
Bu, seçilen teknolojiye bağlıdır. Native geliştirmede iOS için Swift, Android için Kotlin/Java ile ayrı kod tabanları kullanılabilir. React Native veya Flutter gibi çapraz platform yaklaşımlarında tek ana kod tabanı üzerinden iki platforma uygulama çıkarılabilir. Ancak tek kod tabanı, tek yayın süreci anlamına gelmez. App Store Connect ve Play Console mağaza bilgileri, test kanalları, izin açıklamaları, paket imzalama ve platforma özel kontroller ayrı yönetilir. Bu yüzden teknoloji seçimi geliştirme hızını etkiler; fakat mağaza uyumluluğu yine platform bazlı ele alınmalıdır.
Çoğu ticari uygulamada gizlilik politikası bağlantısı fiilen zorunlu hale gelir. Kullanıcı verisi toplayan, hesap oluşturan, konum isteyen, ödeme alan, bildirim gönderen veya üçüncü taraf servis kullanan uygulamalarda gizlilik metni eksikliği ciddi sorundur. Destek sayfası, iletişim adresi ve web sitesi de kullanıcı güveni açısından önemlidir. Mağaza inceleme ekipleri bu bağlantıların çalışıp çalışmadığını kontrol edebilir. Boş, hatalı veya uygulamayla ilgisiz gizlilik politikası linki ret sebebi olabilir. Bu nedenle yayın öncesinde web tarafındaki destek ve politika sayfaları da hazırlanmalıdır.
Mobil uygulama bütçesi yalnızca yazılım geliştirme bedelinden oluşmaz. Kapsam, tasarım, entegrasyon, güvenlik, test, mağaza yayını, bakım ve büyüme maliyetleri birlikte planlanmalıdır. Bu rehber, MVP'den kurumsal uygulamalara kadar gerçekçi bütçe kalemlerini anlatır.
ERP entegrasyonlu mobil uygulama; saha satış, bayi siparişi, stok takibi, servis operasyonu ve yönetici raporlarını ERP verisiyle mobilde kullanılabilir hale getirir. Bu rehberde kullanım senaryoları, entegrasyon mimarisi, maliyet aralıkları, güvenlik, test süreci ve proje planlaması teknik açıdan ele alınır.
Restoran sipariş uygulaması geliştirme; menü yönetimi, online ödeme, kurye takibi, kampanya kurgusu, POS entegrasyonu ve müşteri sadakati gibi birçok katmanı birlikte planlamayı gerektirir. Bu rehber, restoran zincirleri ve bağımsız işletmeler için teknik kapsamı, maliyet aralıklarını ve geliştirme sürecini açıklar.
