Mobil Uygulama Yaptırmadan Önce Teknik ve Ticari Kontrol Listesi

Kısa özet: Her dijital ürünün mobil uygulamaya ihtiyacı yoktur. Kullanıcıların temel işlemi masaüstünde yaptığı, sık cihaz özelliği kullanmadığı veya ürün fikrinin henüz doğrulanmadığı durumlarda responsive web uygulaması daha ekonomik olabilir. Mobil uygulama gerekiyorsa iOS ve Android geliştirme yaklaşımı, backend, üyelik, ödeme, bildirim, mağaza hesapları, veri politikaları ve sürekli bakım modeli geliştirmeden önce belirlenmelidir.

Kısa doğrudan cevap

Mobil uygulama yaptırmadan önce ilk karar, “iOS mu Android mi?” değil, uygulamanın gerçekten gerekli olup olmadığıdır. Mobil uygulama; kamera, konum, Bluetooth, çevrim dışı kullanım, sık bildirim veya saha operasyonu ürünün temel değeriyse güçlü bir tercih olabilir. Kullanıcılar ürünü seyrek kullanacak, işlemler çoğunlukla masaüstünde yapılacak veya uygulama yalnızca mevcut web sitesini gösterecekse responsive web uygulaması yeterli olabilir. Mobil uygulama yatırımı; yalnızca geliştirme ücretinden değil, Apple ve Google geliştirici hesapları, backend, mağaza incelemesi, ödeme altyapısı, bildirimler, analitik, güvenlik, işletim sistemi güncellemeleri ve sürekli bakım maliyetlerinden oluşur.

Önce şu soruyu sorun: Gerçekten mobil uygulama gerekiyor mu?

Bir işletmenin müşterilerinin mobil telefon kullanması, o işletmenin mutlaka mobil uygulama geliştirmesi gerektiği anlamına gelmez. Kullanıcıların önemli bir kısmı mobil cihazdan web sitesine erişebilir. Ancak mobil uygulama yüklemek ayrı bir davranıştır:

• Kullanıcı mağazada uygulamayı bulur.
• Uygulamaya güvenmesi gerekir.
• İndirme yapar.
• Gerekirse hesap oluşturur.
• Depolama ve bildirim izni verir.
• Uygulamaya tekrar dönmek için yeterli değer görür.

Ürünün kullanım sıklığı ve sağladığı değer bu adımları karşılamıyorsa, kullanıcı uygulamayı indirmeyebilir veya kısa süre sonra silebilir.

Mobil uygulama daha anlamlı olabilir

• Kullanıcı ürünü haftada birkaç kez veya her gün kullanacaksa
• Saha çalışanları veri girecekse
• Kamera, konum, Bluetooth, NFC veya biyometrik doğrulama gerekiyorsa
• Çevrim dışı çalışma ürünün temel gereksinimiyse
• Push bildirimleri iş akışının önemli parçasıysa
• Kullanıcı hareket halindeyken işlem tamamlayacaksa
• Telefon rehberi, takvim veya cihaz sensörleri kullanılacaksa
• Mobil uygulama markanın temel müşteri deneyimiyse
• App Store veya Google Play görünürlüğü ticari açıdan önemliyse
• Kullanıcı uygulamayı kişisel çalışma alanı olarak kullanacaksa

Web uygulaması yeterli olabilir

• Kullanıcı ürüne ayda birkaç kez girecekse
• Temel işlem form doldurma veya bilgi görüntülemeyse
• Ürün büyük tablolar ve ayrıntılı raporlar içeriyorsa
• Kullanıcıların çoğu masa başında çalışıyorsa
• Uygulama fikri henüz doğrulanmadıysa
• Hızlı MVP çıkarmak öncelikliyse
• Kamera, konum veya çevrim dışı kullanım kritik değilse
• Mağaza inceleme ve yayın süreçleri istenmiyorsa
• Tek bir kod tabanıyla web ve mobil tarayıcı hedefleniyorsa
• Bütçe ilk aşamada sınırlıysa

Progressive Web App yaklaşımı, web uygulamalarının yüklenebilir, çevrim dışı çalışabilir ve bazı platformlarda push notification kullanabilir hale gelmesini sağlayabilir. Ancak tarayıcı ve işletim sistemi desteği aynı değildir; bazı cihaz yetenekleri platforma göre sınırlı kalabilir. Bu nedenle PWA kararı, ihtiyaç duyulan özelliklerin gerçek cihazlarda desteklenip desteklenmediği kontrol edilerek verilmelidir.

Mobil uygulama, web sitesinin küçültülmüş kopyası olmamalıdır

Mobil uygulama geliştirmedeki en yaygın hatalardan biri, mevcut web sitesindeki bütün menü ve sayfaların uygulamaya taşınmasıdır. Mobil uygulama kullanıcısı genellikle belirli ve hızlı işlemler yapmak ister:

• Sipariş durumunu görmek
• Rezervasyon oluşturmak
• Bir talebi onaylamak
• Bildirim almak
• Fotoğraf yüklemek
• Saha verisi girmek
• Randevu kontrol etmek
• Ödeme yapmak
• Mesaj veya destek talebi göndermek

Mobil uygulama projesinde önce şu soru cevaplanmalıdır: Kullanıcının telefonunda en sık tamamlayacağı üç işlem nedir? Bu üç işlem net değilse proje büyük ihtimalle kullanıcı ihtiyacından değil, “mobil uygulamamız da olsun” beklentisinden doğuyordur.

Web uygulaması, PWA ve mağaza uygulaması karşılaştırması

PWA, web ve native uygulama arasında otomatik bir “en iyi çözüm” değildir. Tarayıcı uyumluluğu, cihaz yetenekleri ve kullanıcıların uygulamayı nasıl keşfedeceği ayrıca değerlendirilmelidir.

iOS ve Android ayrı mı geliştirilmelidir?

Mobil uygulamalar üç temel yaklaşımla geliştirilebilir:

• iOS ve Android için ayrı native uygulama
• Cross-platform uygulama
• Web/PWA tabanlı yaklaşım

Native geliştirme nedir?

Native geliştirmede iOS ve Android için platformun kendi araçları ve teknolojileri kullanılır. Örneğin:

• iOS: Swift ve SwiftUI/UIKit
• Android: Kotlin ve Jetpack Compose

İki platform için farklı kod tabanları veya önemli ölçüde farklı uygulama katmanları bulunabilir.

Native geliştirme ne zaman anlamlıdır?

• Yoğun kamera veya görüntü işleme
• Bluetooth ve cihaz bağlantıları
• Karmaşık arka plan işlemleri
• Ses ve video işleme
• Yüksek performanslı animasyon veya oyun
• Sağlık ve sensör verileri
• Platforma özgü kapsamlı deneyim
• Mevcut büyük native uygulamaya yeni modül ekleme
• Her platform için ayrı ürün ekibinin bulunduğu şirketler

Native geliştirmenin avantajları

• Platform API’lerine doğrudan erişim
• Yeni iOS ve Android özelliklerine erken erişim
• Platforma özgü kullanıcı deneyimi
• Karmaşık native yeteneklerde daha az ara katman
• Performans optimizasyonunda daha geniş kontrol

Native geliştirmenin riskleri

• İki ayrı geliştirme süreci
• İki ayrı test yükü
• Özelliklerin platformlarda farklı tarihlerde çıkması
• Daha yüksek ekip ve bakım ihtiyacı
• Aynı iş kuralının iki kez uygulanması
• iOS ve Android arasında davranış farkları

Cross-platform yaklaşım ne zaman uygundur?

Cross-platform geliştirmede uygulamanın önemli bir bölümü ortak kod tabanından üretilir. React Native, React kullanarak iOS ve Android için native uygulamalar geliştirmeyi sağlar. Flutter ise mobil, web ve masaüstü platformlarını ortak bir kod tabanıyla hedefleyen bir yapı sunar.

Cross-platform için uygun projeler

• Form, liste, panel ve kullanıcı hesabı ağırlıklı uygulamalar
• Rezervasyon ve randevu sistemleri
• B2B operasyon uygulamaları
• Müşteri ve bayi portalları
• İçerik ve üyelik uygulamaları
• E-ticaret ve sipariş uygulamaları
• Bildirim ve hızlı işlem odaklı mobil uygulamalar
• Web backend’i hazır olan ürünler
• iOS ve Android’i aynı anda çıkarmak isteyen küçük ve orta ekipler

Cross-platform avantajları

• İş mantığının önemli bölümü ortak olabilir.
• İki platform paralel geliştirilebilir.
• Tek ekip iki mağazayı yönetebilir.
• Hata düzeltmeleri büyük ölçüde ortak uygulanabilir.
• MVP daha hızlı yayımlanabilir.
• Tasarım sistemi iki platformda daha tutarlı kalabilir.

Cross-platform her şeyi tek kodla mı çözer?

Hayır. React Native, platforma özgü dosya ve kod kullanma imkânı sunar. Flutter da farklı platformlar için ayrı entegrasyonlar ve eklentiler kullanabilir. Kamera, bildirim, ödeme, deep link, dosya sistemi ve mağaza ayarlarında iOS ile Android arasında ayrı yapılandırma yapılması gerekir. Bu nedenle “tek kod tabanı” şu anlama gelmemelidir:

• Tek test yeterlidir.
• iOS ve Android aynı davranır.
• Native bilgiye ihtiyaç yoktur.
• Mağaza süreçleri ortaktır.
• Bütün kod yüzde 100 paylaşılır.

Daha doğru ifade şudur: Ürün mantığının ve arayüzün önemli bir bölümü paylaşılabilir; platforma özgü alanlar ayrı geliştirilir ve test edilir.

Native mi cross-platform mu? Karar tablosu

Teknoloji kararı yalnızca ilk geliştirme süresine göre verilmemelidir. Ekip deneyimi, native modül ihtiyacı, uygulama ömrü, güncelleme sıklığı ve platform özellikleri birlikte değerlendirilmelidir.

Mobil uygulama için backend gerekli mi?

Çoğu ticari mobil uygulamada evet. Mobil uygulama kullanıcının cihazında çalışan istemci katmanıdır. Kullanıcı hesapları, şirket verileri, siparişler, rezervasyonlar ve abonelik durumları yalnızca cihaz üzerinde güvenilir biçimde yönetilemez.

Backend’in yönettiği işlemler

• Kullanıcı kayıt ve girişleri
• Yetkilendirme
• Veri tabanı
• Kullanıcılar arası veri senkronizasyonu
• Sipariş ve rezervasyon
• Ödeme doğrulama
• Abonelik durumu
• Bildirim gönderme
• Dosya yükleme
• Yönetim paneli
• Raporlama
• Audit log
• Harici API entegrasyonları
• E-posta ve SMS
• Hesap silme ve veri dışa aktarma

Backend gerekmeyebilecek basit uygulamalar

• İnternetsiz hesap makinesi
• Basit kişisel not uygulaması
• Tek cihazda çalışan araç
• Sunucuyla veri paylaşmayan yardımcı uygulama
• Tamamen yerel içerik kullanan uygulama

Ancak kullanıcı girişi, ödeme, abonelik, bildirim veya birden fazla cihaz arasında senkronizasyon varsa backend ihtiyacı ortaya çıkar.

Push bildirim için neden backend gerekir?

Apple Push Notification service ve Firebase Cloud Messaging, bildirimlerin güvenilir bir sunucu ortamından gönderilmesini temel mimarinin parçası olarak tanımlar. Uygulama cihaz token’larını toplar; sunucu hangi kullanıcıya, ne zaman ve hangi mesajın gönderileceğine karar verir. Bildirim altyapısı yalnızca “mesaj gönderme” özelliği değildir. Şunların da tasarlanması gerekir:

• Bildirim izni
• Cihaz token güncellemeleri
• Kullanıcının bildirim tercihleri
• Pazarlama ve operasyon bildirimi ayrımı
• Çoklu cihaz kullanımı
• Zamanlama
• Bildirime tıklanınca açılacak ekran
• Başarısız bildirimlerin takibi
• Kullanıcı çıkış yaptığında token ilişkisinin kaldırılması

Üyelik ve kullanıcı yapısı nasıl planlanmalıdır?

Mobil uygulamaya sonradan üyelik eklemek, yalnızca giriş ekranı eklemek değildir.

Başlangıçta cevaplanması gerekenler

• Kullanıcı kendi hesabını oluşturabilir mi?
• Hesabı şirket yöneticisi mi açar?
• E-posta, telefon veya sosyal giriş mi kullanılacak?
• Bir kullanıcı birden fazla şirkete bağlı olabilir mi?
• Kullanıcı rolleri nelerdir?
• Misafir kullanım olacak mı?
• Kullanıcı cihaz değiştirdiğinde verileri nasıl gelir?
• Hesap kapatıldığında veriler ne olur?
• Kullanıcı uygulama içinden hesabını silebilir mi?
• Şirket çalışanı ayrıldığında erişimi kim kaldırır?
• Çok faktörlü doğrulama gerekir mi?
• Kullanıcı parolasını unuttuğunda süreç nasıl işleyecek?

Apple, hesap oluşturmayı destekleyen uygulamaların uygulama içinden hesap silme işlemini başlatabilmesini ister. Google Play de hesap oluşturan uygulamalarda kullanıcıya açık hesap silme seçeneği ve ilgili veri güvenliği açıklamalarını gerektirir. Bu nedenle hesap silme özelliği proje sonunda mağaza reddi geldiğinde eklenmemelidir. Veri modeli ve yasal saklama süreleriyle birlikte başlangıçta planlanmalıdır.

Mobil uygulamada ödeme nasıl çalışır?

Ödeme yaklaşımı, satılan ürün veya hizmetin türüne göre değişir.

Fiziksel ürün veya gerçek dünyada sunulan hizmet

Örnekler:

• Yemek siparişi
• Ulaşım
• Fiziksel ürün
• Otel rezervasyonu
• Yüz yüze danışmanlık
• Saha hizmeti

Bu modellerde kredi kartı, banka veya harici ödeme sağlayıcıları kullanılabilir. Yine de ülke, sektör ve mağaza kuralları yayın öncesinde kontrol edilmelidir.

Uygulama içindeki dijital özellik veya içerik

Örnekler:

• Premium uygulama özellikleri
• Dijital üyelik
• Uygulama içi kredi
• Video veya içerik aboneliği
• Dijital eğitim içeriği
• Oyun içi ürün

Apple ve Google, uygulama içindeki dijital ürünler ve dijital hizmetler için kendi billing sistemlerini temel yöntem olarak öngörür; ancak bölge, ürün türü ve özel programlara bağlı istisnalar bulunabilir. Bu nedenle ödeme mimarisi, hedef ülkeler ve ürünün niteliği belirlenmeden yalnızca “Stripe ekleriz” şeklinde tasarlanmamalıdır.

Abonelik için backend neden önemlidir?

Kullanıcı aboneliği:

• Mağazadan iptal edebilir.
• Ödeme başarısız olabilir.
• Paket değiştirebilir.
• İade alabilir.
• Yeniden abone olabilir.
• Farklı cihazdan satın alabilir.
• Aile paylaşımı kullanabilir.

Bu değişikliklerin yalnızca uygulama ekranından izlenmesi yeterli değildir. Apple, App Store Server Notifications üzerinden abonelik ve iade durumlarının sunucuya iletilmesini destekler. Google Play de Real-time Developer Notifications ve Play Developer API aracılığıyla abonelik yaşam döngüsünün backend üzerinde yönetilmesini önerir.

Ödeme için başlangıçta belirlenmesi gerekenler

• Fiziksel mi dijital mi satılıyor?
• Tek seferlik ödeme mi abonelik mi?
• Aylık ve yıllık paket var mı?
• Ücretsiz deneme olacak mı?
• Paket yükseltme ve düşürme nasıl olacak?
• İade durumunda erişim ne zaman kapanacak?
• Kullanıcı web ve mobilde aynı üyeliği kullanabilecek mi?
• Fatura kim tarafından kesilecek?
• Vergi ve para birimi nasıl yönetilecek?
• Apple ve Google abonelikleri tek backend’de nasıl birleştirilecek?
• Satın alma geri yükleme özelliği olacak mı?
• Abonelik durumları ne sıklıkla doğrulanacak?

App Store ve Google Play maliyetleri nelerdir?

Geliştirici hesabı ücretleri

Apple Developer Program ücreti yıllık 99 ABD dolarıdır veya desteklenen ülkelerde yerel para birimiyle tahsil edilebilir. Belirli kâr amacı gütmeyen kurumlar, eğitim kurumları ve kamu kuruluşları ücret muafiyetine uygun olabilir. Google Play Console kayıt ücreti ise 25 ABD dolarıdır ve tek seferliktir. Bu ücretler toplam uygulama maliyetinin çok küçük bir bölümüdür.

Gözden kaçan diğer maliyetler

• UX ve UI tasarımı
• iOS ve Android geliştirme
• Backend geliştirme
• Yönetim paneli
• Cloud ve veri tabanı
• Dosya depolama
• E-posta ve SMS
• Bildirim altyapısı
• Harita ve konum servisleri
• Ödeme komisyonları
• Analitik ve hata izleme
• Test cihazları
• Mağaza görselleri
• Gizlilik metinleri
• Uygulama bakım ve güncellemeleri
• Müşteri desteği
• Yeni işletim sistemi sürümlerine uyum
• App Store ve Google Play politika değişiklikleri

Mağaza komisyonu tek bir yüzde değildir

Dijital ürün satışlarında Apple ve Google’ın hizmet ücretleri; ürün türü, pazar, geliştirici programı, gelir seviyesi, abonelik ve bölgesel kurallara göre değişebilir. Apple’ın resmî üyelik sayfası farklı programlarda yüzde 15 ve yüzde 30 oranlarının uygulanabildiğini; Google Play ise farklı hizmet ücreti programlarının bulunduğunu açıklar. Bu nedenle maliyet planında tek ve evrensel bir mağaza komisyonu kullanılmamalıdır. Yayın öncesinde hedef ülkeler, ödeme yöntemi ve ürün türü için güncel koşullar yeniden doğrulanmalıdır.

Geliştirici hesapları kimin adına açılmalıdır?

Mobil uygulama dış kaynakla geliştirilse bile mağaza hesaplarının işletmenin kontrolünde olması önerilir. Apple’da organizasyon hesabıyla yayımlanan uygulamalar şirketin hukuki tüzel kişilik adı altında listelenir ve organizasyon kaydı için D-U-N-S Number istenebilir. Google Play ise kişisel ve organizasyon geliştirici hesabı seçenekleri sunar.

İşletmenin kontrolünde olması gerekenler

• Apple Developer hesabı
• App Store Connect hesabı
• Google Play Console hesabı
• Uygulama bundle ID ve package name
• Push notification anahtarları
• Firebase veya cloud hesabı
• Domain
• Kaynak kod repository’si
• Analytics hesabı
• Ödeme sağlayıcısı
• Uygulama imzalama anahtarları
• Gizlilik politikası sayfası
• Destek e-posta adresi

Ajans veya bağımsız geliştirici bu hesaplara gerekli rollerle davet edilmelidir. Projenin ajansın kişisel hesabından yayımlanması; devir, ödeme, sözleşme ve erişim problemleri oluşturabilir.

Mağaza yayını neden proje takvimine eklenmelidir?

Mobil uygulamanın kodunun tamamlanması, aynı gün mağazada yayımlanacağı anlamına gelmez. Apple bütün uygulamaları, güncellemeleri, uygulama içi satın almaları ve belirli mağaza içeriklerini inceleme sürecinden geçirir. Apple App Review Guidelines güvenlik, performans, iş modeli, tasarım ve hukuki alanları kapsar. Google Play tarafında da geliştirici hesabı, veri güvenliği, içerik derecelendirmesi, hedef API, ödeme ve kullanıcı verisi politikaları bulunur.

Mağaza reddine neden olabilecek yaygın konular

• Uygulamanın temel işlevinin çalışmaması
• Eksik demo hesabı
• Uygulamanın yalnızca web sitesini göstermesi
• Yanlış ödeme yöntemi
• Hesap silme seçeneğinin bulunmaması
• Gizlilik politikasının eksik olması
• Toplanan verilerin yanlış beyan edilmesi
• Kamera veya konum izninin açıklanmaması
• Boş veya tamamlanmamış ekranlar
• Uygulamanın girişten sonra test edilememesi
• Kullanıcı tarafından üretilen içerikte moderasyon eksikliği
• Abonelik şartlarının açık gösterilmemesi
• Uygulama ekran görüntülerinin gerçek uygulamayı yansıtmaması

Apple, uygulama gizliliği beyanlarında geliştirici ve üçüncü taraf ortakların topladığı verilerin doğru ve güncel biçimde açıklanmasını ister.

Proje planında bulunması gereken mağaza hazırlıkları

• Uygulama adı
• Açıklama
• Anahtar kelimeler
• Kategori
• Yaş derecelendirmesi
• Ekran görüntüleri
• Uygulama ikonu
• Gizlilik politikası
• Destek URL’si
• Hesap silme URL’si
• Test hesabı
• İnceleme notları
• Abonelik ürünleri
• Ülke ve fiyatlandırma
• Data safety / app privacy beyanları
• TestFlight ve Play test süreci

Push bildirim gerçekten gerekli mi?

Push bildirim, mobil uygulama yaptırmak için tek başına yeterli sebep değildir. Yanlış kullanılan bildirimler kullanıcıların izni kapatmasına veya uygulamayı silmesine neden olabilir.

Operasyonel bildirim örnekleri

• Sipariş durumu değişti
• Randevu yaklaşıyor
• Teklif onay bekliyor
• Ödeme başarısız oldu
• Saha görevi atandı
• Yeni mesaj geldi
• Belge süresi doluyor

Pazarlama bildirimi örnekleri

• Kampanya
• Yeni özellik
• İçerik önerisi
• İndirim
• Kullanıcıyı geri çağırma

Operasyonel ve pazarlama bildirimleri ayrı izin ve tercih mantığıyla yönetilmelidir.

Bildirim kontrol listesi

• Kullanıcıya izin neden isteniyor?
• İzin uygulama açılır açılmaz mı istenecek?
• Kullanıcı bildirim türlerini seçebilir mi?
• Aynı olay birden fazla bildirim oluşturabilir mi?
• Gece saatlerinde bildirim gönderilecek mi?
• Bildirime tıklanınca doğru ekran açılıyor mu?
• Kullanıcı çıkış yaptığında cihaz ilişkisi kaldırılıyor mu?
• Hassas bilgi kilit ekranında gösteriliyor mu?
• Bildirim gönderimi raporlanıyor mu?
• Başarısız token’lar temizleniyor mu?

FCM; tek cihaz, cihaz grupları veya konu abonelikleri gibi farklı hedefleme yöntemleri sunar. Ancak hedefleme ve kullanıcı tercihleri uygulamanın backend’i tarafından güvenli biçimde yönetilmelidir.

Mobil uygulamanın sürekli bakım maliyeti neden vardır?

“Uygulama çalışıyor, neden bakım gerekiyor?” sorusu mobil projelerde de sık görülür. Mobil uygulama sabit bir ortamda çalışmaz. Zaman içinde şunlar değişir:

• iOS ve Android sürümleri
• App Store ve Google Play politikaları
• Minimum işletim sistemi desteği
• SDK ve framework sürümleri
• Bildirim servisleri
• Ödeme API’leri
• Harita ve konum servisleri
• Cihaz ekran boyutları
• Güvenlik gereksinimleri
• Gizlilik izinleri
• Üçüncü taraf paketler
• Mağaza sertifikaları
• Backend servisleri

Apple, App Store’un ve inceleme kurallarının zaman içinde değiştiğini ve uygulamaların mağazada kalmak için gelişmeye devam etmesi gerektiğini belirtir.

Sürekli bakım kapsamı

• Framework ve SDK güncellemeleri
• iOS ve Android uyumluluk testleri
• Güvenlik güncellemeleri
• Mağaza politika kontrolleri
• Bağımlılık güncellemeleri
• Crash analizi
• Performans izleme
• Backend bakımı
• Yedekleme
• Bildirim ve ödeme servislerinin kontrolü
• Yeni cihaz testleri
• Gizlilik beyanlarının güncellenmesi
• Mağaza sertifikalarının yenilenmesi
• Kritik hata müdahalesi
• Küçük kullanıcı deneyimi iyileştirmeleri

Bakım ile yeni özellik aynı şey değildir

Sözleşmede bakım kapsamına giren ve girmeyen işler açıkça yazılmalıdır.

Mobil uygulama maliyeti nasıl değerlendirilmelidir?

Maliyet ekran sayısıyla ölçülmemelidir. Aynı sayıda ekrana sahip iki uygulamanın teknik karmaşıklığı tamamen farklı olabilir.

Maliyeti etkileyen temel faktörler

• Kullanıcı rolü sayısı
• iOS ve Android yaklaşımı
• Kamera ve konum kullanımı
• Çevrim dışı çalışma
• Backend
• Yönetim paneli
• Ödeme ve abonelik
• Push notification
• Harita
• Mesajlaşma
• Dosya yükleme
• Video ve ses
• Çoklu dil
• Veri aktarımı
• Entegrasyonlar
• Güvenlik
• Test kapsamı
• Mağaza yayın süreci
• Analitik ve hata izleme

İlk yıl toplam maliyeti

İlk yıl mobil ürün maliyeti = Analiz ve ürün planlama + UX/UI tasarımı + mobil geliştirme + backend ve yönetim paneli + entegrasyonlar + test ve mağaza yayını + cloud ve üçüncü taraf servisler + bakım Yalnızca uygulama ekranlarının teklifini karşılaştırmak, ürünün gerçek maliyetini göstermez.

Mobil uygulama teklifinde neler bulunmalıdır?

Analiz ve kapsam

• Hedef kullanıcılar
• Temel kullanım senaryoları
• MVP kapsamı
• iOS ve Android kapsamı
• Web panel ihtiyacı
• Backend kapsamı
• Kullanıcı rolleri
• Entegrasyonlar
• Başarı metrikleri

Tasarım

• Kullanıcı akışları
• Wireframe
• UI tasarımı
• Tasarım sistemi
• iOS ve Android uyarlamaları
• Erişilebilirlik
• Revizyon sayısı

Teknik geliştirme

• Kullanılacak teknoloji
• Minimum iOS ve Android sürümleri
• Backend teknolojisi
• Veri tabanı
• API
• Bildirim sistemi
• Çevrim dışı kullanım
• Ödeme
• Analitik
• Güvenlik

Mağaza yayını

• App Store hesabı
• Play Console hesabı
• TestFlight
• Play test kanalları
• Ekran görüntüleri
• Mağaza metinleri
• Gizlilik beyanları
• İnceleme desteği
• Reddetme durumunda düzeltme kapsamı

Proje sonrası

• Kaynak kod teslimi
• Hesap ve anahtar teslimi
• Teknik dokümantasyon
• Garanti süresi
• Bakım
• Kritik hata müdahalesi
• Yeni sürüm uyumluluğu
• Destek ve geliştirme ücretleri

Karar matrisi: Mobil uygulama gerçekten gerekli mi?

Her başlığı 0–2 arasında puanlayın:

• 0: Gerekli değil
• 1: Kısmen önemli
• 2: Ürünün temel ihtiyacı

Sonuçların yorumlanması

0–6 puan: Önce web uygulaması değerlendirilmelidir

Mobil uygulama yatırımı erken olabilir. Responsive web veya PWA ile ürün doğrulanabilir.

7–13 puan: Hibrit yaklaşım değerlendirilebilir

Web uygulamasına ek olarak sınırlı mobil uygulama veya cross-platform MVP hazırlanabilir.

14–20 puan: Mobil uygulama güçlü bir yatırım olabilir

Cihaz yetenekleri ve kullanım sıklığı ürünün temel değeridir. Mobil ürün önceliklendirilebilir. Bu puanlama InoviqLab tarafından sunulan ön değerlendirme çerçevesidir; ürün ve kullanıcı araştırmasının yerine geçmez.

Mobil uygulama yaptırmadan önce kontrol listesi

Ürün kararı

• Mobil uygulamanın çözdüğü problem tek cümlede anlatılabiliyor mu?
• Kullanıcının en sık yapacağı üç işlem belirlendi mi?
• Responsive web seçeneği değerlendirildi mi?
• PWA seçeneği değerlendirildi mi?
• Kullanım sıklığı tahmin değil, kullanıcı görüşmesiyle doğrulandı mı?
• İlk sürümün kapsamı sınırlandırıldı mı?
• Başarı metriği belirlendi mi?

Platform ve teknoloji

• iOS ve Android aynı anda mı yayımlanacak?
• Native ve cross-platform seçenekleri karşılaştırıldı mı?
• Platforma özgü özellikler listelendi mi?
• Minimum işletim sistemi sürümleri belirlendi mi?
• Kullanılacak paketlerin bakım durumu kontrol edildi mi?
• Gerçek cihaz test planı hazır mı?

Backend ve veri

• Backend ihtiyacı tanımlandı mı?
• Kullanıcı ve rol yapısı çıkarıldı mı?
• Veri tabanı ve dosya depolama planlandı mı?
• Yönetim paneli gerekli mi?
• Yedekleme planı var mı?
• Hesap silme süreci tasarlandı mı?
• Kullanıcı verisinin hangi ülkede tutulacağı belirlendi mi?
• API ve entegrasyonlar listelendi mi?

Ödeme ve abonelik

• Fiziksel ve dijital ürün ayrımı yapıldı mı?
• Apple ve Google ödeme politikaları kontrol edildi mi?
• Tek seferlik ve abonelik seçenekleri belirlendi mi?
• Paket değişikliği ve iptal süreci tasarlandı mı?
• Backend satın alma doğrulaması planlandı mı?
• İade ve geri yükleme süreçleri tanımlandı mı?
• Mağaza komisyonları maliyet planına eklendi mi?

Bildirim

• Operasyonel ve pazarlama bildirimleri ayrıldı mı?
• Kullanıcı bildirim tercihleri planlandı mı?
• Deep link akışları tasarlandı mı?
• Bildirim gönderme backend’i tanımlandı mı?
• Hassas verinin kilit ekranında görünmesi değerlendirildi mi?

Hesap ve sahiplik

• Apple Developer hesabı şirket adına mı?
• Google Play hesabı şirket kontrolünde mi?
• Cloud hesabı işletmeye mi ait?
• Kaynak kod repository’si işletmenin erişiminde mi?
• Uygulama imzalama anahtarları güvenli biçimde saklanıyor mu?
• Domain ve gizlilik politikası şirket kontrolünde mi?
• Ajans değişiminde devir süreci var mı?

Mağaza yayını

• Uygulama adı ve mağaza metinleri hazır mı?
• Ekran görüntüleri hazırlanacak mı?
• Gizlilik politikası var mı?
• Data safety ve app privacy beyanları hazır mı?
• Hesap silme özelliği mevcut mu?
• İnceleme için test hesabı sağlanacak mı?
• Reddetme sonrası düzeltme süreci teklife dâhil mi?

Bakım

• İlk 12 aylık bakım bütçesi ayrıldı mı?
• Kritik hata müdahale süresi tanımlandı mı?
• iOS ve Android sürüm güncellemeleri kapsamda mı?
• Mağaza politika kontrolleri bakım kapsamına giriyor mu?
• Backend ve cloud bakımı tanımlandı mı?
• Crash ve performans izleme kurulacak mı?
• Yeni özellik ve bakım işleri ayrıldı mı?

Kimler için mobil uygulama uygundur?

• Saha operasyonu yürüten işletmeler
• Sık rezervasyon veya sipariş alan platformlar
• Müşterinin uygulamaya düzenli döneceği ürünler
• Bildirim ve hızlı onay gerektiren B2B sistemler
• Kamera ve konum kullanan süreçler
• Çevrim dışı veri girişi gereken operasyonlar
• Mobil sadakat ve üyelik deneyimi geliştiren markalar
• Ürünü webde doğrulanmış ve mobil talebi oluşmuş işletmeler
• Backend ve bakım bütçesi ayırabilen şirketler

Kimler için henüz gerekli olmayabilir?

• Yalnızca kurumsal tanıtım isteyenler
• Kullanıcının ürüne seyrek gireceği işletmeler
• Mobil uygulamayı yalnızca prestij için isteyenler
• Ürün fikrini kullanıcılarla doğrulamayanlar
• Backend ve bakım bütçesi ayırmayanlar
• Mevcut web deneyimi henüz düzeltilmemiş olanlar
• Uygulamada web sitesinden farklı bir değer sunamayanlar
• Mağaza hesaplarını ve kaynak kodu ajansın hesabına bırakmayı planlayanlar
• İçerik ve müşteri destek süreci bulunmayanlar

InoviqLab değerlendirmesi

Bu bölüm InoviqLab’ın değerlendirmesidir; Apple, Google ve teknoloji sağlayıcılarının resmî bilgilerinden ayrıdır. Mobil uygulama projelerinde en pahalı hata yanlış framework seçimi değildir. En pahalı hata, web uygulamasının yeterli olduğu bir ürünü mağaza uygulamasına dönüştürmektir. Mobil uygulama geliştirme kararı şu üç unsur birlikte bulunduğunda güçlenir:

• Kullanıcı uygulamaya düzenli dönecek.
• Telefonun yetenekleri gerçek değer sağlayacak.
• İşletme ürünü sürekli bakım ve geliştirmeyle destekleyecek.

İkinci önemli hata, mobil uygulamayı yalnızca ön yüz olarak değerlendirmektir. Kullanıcı hesabı, bildirim, ödeme, abonelik ve farklı cihazlarda veri senkronizasyonu varsa projenin önemli bölümü backend ve operasyon altyapısıdır. Ekranlar tamamlandığında ürünün tamamlandığını düşünmek gerçekçi değildir. Üçüncü hata, cross-platform yaklaşımı “tek kod yazılır ve her yerde aynı çalışır” şeklinde yorumlamaktır. Cross-platform geliştirme maliyeti azaltabilir; ancak:

• Kamera izinleri
• Bildirimler
• Ödeme
• Deep link
• Dosya sistemi
• Mağaza kuralları
• Ekran davranışları

iOS ve Android’de ayrı test edilmelidir. Dördüncü hata, mağaza hesaplarının geliştirici veya ajansın kişisel hesabında tutulmasıdır. Uygulama şirketin dijital varlığıdır. Kaynak kod, cloud, mağaza hesapları ve ödeme sistemleri işletmenin kontrolünde olmalı; dış ekipler yetkilendirilmiş kullanıcı olarak çalışmalıdır. Beşinci hata, bakım bütçesinin ilk tekliften çıkarılmasıdır. Bakım bütçesi olmayan mobil uygulamalar zaman içinde:

• Mağaza kurallarına uyumsuz hale gelebilir.
• Yeni işletim sistemi sürümlerinde hata verebilir.
• Kullanılan paketlerde güvenlik açığı taşıyabilir.
• Ödeme veya bildirim entegrasyonları bozulabilir.
• Yeni cihazlarda sorun yaşayabilir.

InoviqLab açısından sağlıklı süreç şu sırayla ilerlemelidir:

• Kullanıcı ve problem doğrulaması
• Web, PWA ve mobil uygulama karşılaştırması
• MVP kapsamı
• Native veya cross-platform kararı
• Backend, veri ve kullanıcı mimarisi
• Ödeme ve mağaza politikası analizi
• UX prototipi
• Teknik geliştirme
• Gerçek cihaz testleri
• Mağaza hazırlığı ve inceleme
• Analitik ve hata izleme
• Sürekli bakım ve ürün geliştirme

Sonuç

Mobil uygulama yaptırmadan önce teknoloji değil, ürün ihtiyacı netleştirilmelidir. Mobil uygulama şu durumlarda güçlü bir yatırımdır:

• Kullanıcı uygulamaya sık dönecekse
• Kamera, konum veya bildirim temel değer sağlıyorsa
• İşlem sahada tamamlanıyorsa
• Çevrim dışı kullanım gerekiyorsa
• Mobil deneyim webden belirgin biçimde daha iyi olacaksa

Responsive web veya PWA şu durumlarda daha uygun olabilir:

• Kullanım seyrekse
• Ürün henüz doğrulanmadıysa
• İşlemler çoğunlukla masaüstündeyse
• Cihaz özellikleri gerekmiyorsa
• Hızlı ve düşük riskli MVP hedefleniyorsa

Mobil uygulama teklifini yalnızca ekran ve geliştirme ücreti üzerinden değerlendirmeyin. Aşağıdaki alanlar teklif ve ürün planında açıkça bulunmalıdır:

• iOS ve Android yaklaşımı
• Backend
• Kullanıcı ve rol sistemi
• Ödeme ve abonelik
• Push notification
• Veri güvenliği
• App Store ve Google Play hesapları
• Mağaza inceleme süreci
• Kaynak kod sahipliği
• Sürekli bakım

Doğru soru: “Mobil uygulama yaptırmalı mıyız?” değil, “Kullanıcının mobil cihazında hangi işi, webden belirgin biçimde daha iyi çözebiliriz?” olmalıdır.