Mobil uygulama geliştirme: fikirden mağazaya, kodu ve hesapları sizde.

Mobil uygulama yaptırmadan önce neler hazırlanmalı?

Mobil uygulama geliştirme, bir fikri iOS ve Android kullanıcılarının telefonuna kurabileceği, güvenli ve bakımı sürdürülebilir bir ürüne dönüştürme işidir. İlk görüşmeye şu bilgilerle gelirseniz mobil uygulama yaptırma süreci hızlanır; kapsam ve bedel çok daha çabuk netleşir:

• Tek cümlelik amaç: uygulama kimin hangi sorununu çözecek?
• Örnek uygulamalar: beğendiğiniz ya da rakip 3-5 uygulama ve nedenleri.
• Olmazsa olmaz özellikler: ilk sürümde mutlaka olması gereken 3-5 işlem.
• Mevcut sistemler: web sitesi, CRM, ERP, ödeme kuruluşu ya da stok yazılımı.
• Marka dosyaları: logo, renkler ve varsa uygulama ikonu.
• Şirket bilgileri: Apple ve Google geliştirici hesapları için yasal unvan ve D-U-N-S numarası; numara yoksa başvuruyu birlikte başlatırız.
• Bütçe aralığı ve hedef tarih: kapsamı gerçekçi çizmemizi sağlar.

Hepsinin hazır olması şart değil; eksikleri keşif çalışmasında birlikte tamamlarız. Bazı işler komşu hizmetlerimizde ilerler. Örneğin uygulamanın tanıtım sayfası ve web tarafı web tasarım işimizdir; ürün, sepet ve kampanya kurgusu ise e-ticaret danışmanlığı kapsamındadır. Logo, uygulama ikonu ve renk sistemi henüz netleşmediyse marka kimliği çalışmasıyla başlamak tasarım sürecini de hızlandırır.

Native mi, çapraz platform mu, PWA mı?

Doğru teknoloji, uygulamanın ne yapacağına ve bütçenize göre değişir. Bu yüzden teknolojiyi kapsamdan sonra seçeriz, önce değil. Seçenekleri kabaca şöyle karşılaştırabiliriz:

• Native (Swift, Kotlin): her platform için ayrı kod tabanı. Kamera, Bluetooth, arka plan işleri ya da yoğun animasyon gibi cihaza derin bağlı özelliklerde en geniş kontrolü verir; ancak iki kod tabanı iki kat bakım demektir.
• React Native: tek kod tabanından iOS ve Android uygulaması. Resmi belgelere göre bileşenler Android ve iOS’un kendi görünümleriyle çalışır; belgeler yeni projeler için Expo gibi bir framework önerir.
• Flutter: Dart diliyle tek kod tabanı. Flutter, yayın sürümünü doğrudan makine koduna derler ve arayüzü kendi motoruyla çizer.
• PWA: tarayıcıda çalışan ve ana ekrana eklenebilen web uygulaması. Tek kod tabanıyla her cihaza ulaşır; iOS 16.4 ile ana ekrana eklenen web uygulamaları bildirim de alabiliyor.

Pratikte çoğu iş uygulamasında çapraz platform, bütçe ile hız arasındaki dengeyi en iyi kuran seçenektir. Buna karşılık cihaz donanımına yoğun erişen ya da platforma özgü deneyim isteyen projelerde native yolu öneririz. Mağaza gerektirmeyen, içerik ağırlıklı ve hızlı başlangıç isteyen işlerde ise PWA ciddi bir alternatiftir. Mevcut sitenizin mobil deneyimini mobil uyumluluk testi ile ölçebilir, tasarım yaklaşımı için mobil öncelikli tasarım yazımıza göz atabilirsiniz.

Fikirden MVP’ye: kapsam nasıl netleşir?

Yeni bir uygulamada en pahalı hata, her özelliği ilk sürüme sıkıştırmaktır. Bu nedenle işe bir keşif çalışmasıyla başlarız: uygulamayı kim kullanacak, hangi sorunu çözecek, hangi üç işlem değerini kanıtlayacak? Cevaplar netleşince kullanıcı hikâyelerini, ekran listesini ve kabul kriterlerini yazılı bir kapsam dokümanına dökeriz.

Ardından MVP’yi, yani fikri gerçek kullanıcıyla sınayacak en küçük sürümü tanımlarız. Örneğin bir randevu uygulamasında hizmet seçimi, saat seçimi, bildirim ve iptal ilk sürüme girer. Puanlama, sadakat programı ve çoklu şube raporları ise ikinci aşamaya kalır. Böylece bütçenin büyük kısmını, kullanıcıların gerçekten kullandığı özelliklere ayırırsınız.

Tasarım da aynı sırayla ilerler: önce tel kafes akışları, sonra tıklanabilir prototip, en son görsel tasarım. Prototipi siz telefonunuzda deneyip onaylamadan geliştirmeye geçmeyiz, çünkü bir ekranı tasarımda değiştirmek kodda değiştirmekten çok daha ucuzdur. Geliştirmeyi kısa sprintlerle yürütür, her sprint sonunda çalışan bir sürümü test cihazınıza göndeririz. Bu çalışma biçimini Agile ve Scrum yazımızda ayrıntılı anlattık. Tasarım tarafında teklif topluyorsanız UI/UX hizmeti almadan önce bakmanız gereken noktalar da işinize yarar.

Backend, yönetim paneli ve entegrasyonlar bütçeyi nasıl etkiler?

Kullanıcının gördüğü ekranlar işin yalnız bir yarısıdır. Diğer yarısı görünmez: hesapları, verileri ve iş kurallarını yöneten backend, ekibinizin kullandığı yönetim paneli ve dış servislerle konuşan entegrasyonlar. Birçok teklifte bu kısım belirsiz kalır. Bizim kapsam dokümanımızda ise her entegrasyon ayrı bir satırdır.

• Kimlik ve hesap: e-posta, telefon ya da sosyal giriş. Üçüncü taraf giriş sunan uygulamalardan Apple, veri toplamayı sınırlayan eşdeğer bir giriş seçeneği de ister (Kural 4.8).
• Bildirimler: iOS ve Android için anlık bildirim altyapısı, segment ve zamanlama kuralları.
• Ödeme: dijital içerik ve abonelikte varsayılan olarak mağazanın kendi ödeme sistemi; fiziksel ürün ve hizmette ise kart ya da Apple Pay gibi harici ödeme. Apple’ın 3.1.1 ve 3.1.3(e) kuralları ile Google Play’in ödeme politikası, bölgesel istisnalar hariç, bu ayrımı açıkça yapar; ABD ve AB gibi pazarlarda ek koşul ve ücretlerle harici ödeme de mümkün.
• İş sistemleri: CRM, ERP, muhasebe, harita ve kargo servisleri.

Backend dilini ve mimarisini de ölçeğe göre seçeriz; Python ve Go karşılaştırmamız bu kararın mantığını anlatır. Uygulamanız web sitenizle aynı müşteri verisini paylaşacaksa CRM ve ERP entegrasyonları yazımız iyi bir başlangıç noktasıdır. Özetle, backend ne kadar net tasarlanırsa uygulamaya sonradan özellik eklemek o kadar kolay olur.

Mobil uygulamaya yapay zeka özellikleri nasıl eklenir?

Akıllı arama, metin özetleme, sohbet asistanı, fotoğraftan ürün tanıma ya da kişisel öneri gibi özellikler artık bir uygulamanın sıradan parçası olabiliyor. Bunları iki yoldan kurarız:

• Cihaz üzerinde: iOS’ta Apple’ın Foundation Models framework’ü, Android’de ML Kit GenAI API’leri (Gemini Nano) veriyi telefondan çıkarmadan çalışır ve kullanım başına ücret doğurmaz. Ancak yalnız destekleyen cihazlarda çalışır ve kısa görevlere uygundur.
• Bulut modelleri: OpenAI, Google Gemini ya da Anthropic Claude gibi servisler daha güçlüdür; buna karşılık kullanım başına ücretlidir ve veri sağlayıcıya gider.

İkinci yolda gizlilik öne çıkar. Apple, kişisel veriyi üçüncü taraf bir yapay zeka servisiyle paylaşan uygulamalardan bunu açıkça belirtmesini ve paylaşımdan önce kullanıcıdan açık izin almasını ister (Kural 5.1.2(i)). Bu yüzden sağlayıcıyı, gönderilen veriyi ve amacı izin ekranında açıklar, gizlilik etiketlerine ve Data safety formuna işleriz.

Maliyet için kullanıcı başına kota ve harcama tavanı koyar, modeli dar bir görevle sınırlarız. Ayrıca yapay zekayı önce küçük bir özellikle denemenizi, kullanıcıya gerçekten fayda sağlıyorsa büyütmenizi öneririz.

App Store ve Google Play yayın süreci nasıl işler?

Mağaza yayını, geliştirmenin son dakikasına bırakılacak bir iş değildir. İlk kuralımız nettir: geliştirici hesaplarını, şirketinizi bağlamaya yetkili kişi olarak kendi şirketiniz adına açarsınız, ekibimizi de bu hesaplara rol ile davet edersiniz. Apple’da hesap sahibi (Account Holder) sözleşmeleri kabul eder ve ekibe Admin ya da App Manager gibi roller verir. Play Console’da da kullanıcıları davet edip uygulama bazında izin tanımlarsınız. Şirket hesabı için iki mağaza da D-U-N-S numarası ister; bu numarayı almak zaman alabildiği için başvurunuzu ilk hafta birlikte başlatırız.

Apple’ın App Store İnceleme Yönergeleri de bu yaklaşımı destekler: uygulamayı, fikri mülkiyet ve ilgili haklara sahip olan ya da bunların lisansını almış kişi veya şirket göndermelidir (Kural 5.2.1). Apple, hazır şablonla üretilen ve içerik sahibinin kendi hesabından gelmeyen uygulamaları da reddeder (Kural 4.2.6). İnceleme süreleri ise iki mağazada farklıdır:

• App Store: Apple, başvuruların ortalama yüzde 90’ını 24 saatten kısa sürede incelediğini belirtir. Giriş gerektiren uygulamalarda inceleme ekibi bir demo hesap ya da Apple’ın önceden onayıyla tam özellikli bir demo modu ister.
• Google Play: inceleme bazı hesaplarda yedi güne, istisnai durumlarda daha uzuna çıkabilir. Üstelik 13 Kasım 2023’ten sonra açılan kişisel hesaplar, yayından önce en az 12 test kullanıcısıyla 14 gün kesintisiz kapalı test yürütmek zorundadır.

Ret gelirse gerekçeyi okur, düzeltir ve yeniden göndeririz; haksız bir karar olduğunu düşünürsek Apple’ın App Review Board itiraz yolunu kullanırız. Bu arada en sık ret nedenlerinden biri, mevcut web sitesini olduğu gibi paketleyen uygulamalardır. Apple, uygulamanın paketlenmiş bir web sitesinin ötesine geçen özellik ve arayüz sunmasını ister (Kural 4.2).

KVKK, GDPR ve mağaza gizlilik beyanlarını nasıl yönetiyoruz?

Bir uygulama, kameradan konuma kadar telefondaki hassas verilere erişebilir. Bu yüzden gizliliği yayından önceki son güne değil, tasarımın ilk gününe koyarız. Her izni gerçekten gereken ekranda, neden istediğini açıklayan bir metinle isteriz. Apple da uygulamaların yalnız temel işlev için gereken veriye erişmesini ve izin metinlerinin kullanımı eksiksiz anlatmasını şart koşar.

Mağazalar ayrıca şu beyanları ister:

• App Store gizlilik etiketleri: uygulamanın ve içine eklediğiniz üçüncü taraf SDK’ların topladığı veriler. Apple bu bilgiyi yeni uygulama ve güncelleme göndermek için zorunlu tutar; reklam amaçlı takip için ayrıca App Tracking Transparency izni gerekir.
• Google Play Data safety formu: hiç veri toplamayanlar dahil yayındaki tüm uygulamalar için zorunludur ve bir gizlilik politikası bağlantısı ister.
• Hesap silme: hesap açılabilen uygulamalarda hem Apple hem Google, uygulama içinden hesap silme yolu ister. Google ayrıca web üzerinden silme talebi için bir bağlantı bekler.

Türkiye’deki kullanıcılar için KVKK kapsamında bir aydınlatma metni gerekir. Analitik ya da bildirim servisleriniz veriyi yurt dışındaki sunuculara taşıyorsa, 1 Haziran 2024’ten beri geçerli kurallarda standart sözleşme ve imzadan sonra beş iş günü içinde Kurum’a bildirim gündeme gelebilir. AB’deki kullanıcılar içinse GDPR’ın tasarımdan itibaren veri koruma ilkesi geçerlidir.

Backend’i ekibimiz barındırıyor ya da bakımını yapıyorsa, veri işleyen sıfatıyla yazılı bir veri işleme sözleşmesi imzalarız; AB’deki kullanıcıların verisi için standart sözleşme maddelerini de ekleriz. Aydınlatma metni ve gizlilik politikası gibi hukuki metinleri avukatlar hazırlar; biz veri envanterini ve teknik bilgiyi sağlarız, süreci ise çalıştığımız avukatların desteğiyle biz yönetiriz. Genel çerçeve için KVKK ve GDPR uyumu yazımıza bakabilirsiniz.

Mobil uygulama geliştirme ne kadar sürer, toplam maliyeti ne belirler?

Süre ve maliyet, ekran sayısından çok iş kurallarının karmaşıklığına bağlıdır. İki ekranlık bir uygulama bile ödeme, çoklu kullanıcı rolü ve canlı konum içeriyorsa büyük bir projedir. Bu nedenle kesin takvimi keşif çalışmasından sonra, yazılı kapsamla birlikte veririz. Kapsam netleşmeden verilen her tarih ancak bir tahmindir.

Takvimi en çok uzatan kalemler şunlardır:

• Belirsiz kapsam: geliştirme sırasında sürekli eklenen yeni özellikler.
• Dış bağımlılıklar: ödeme kuruluşu onayları, kurumsal API erişimleri ve D-U-N-S başvurusu.
• İçerik: metin, görsel ve ürün verisinin geç gelmesi.
• Mağaza süreci: kapalı test şartı, inceleme süresi ve olası ret döngüleri.

Toplam sahip olma maliyetini de baştan konuşuruz. Geliştirme bedelinin yanında Apple Developer Program’ın yıllık üyelik ücreti, Google Play Console’un tek seferlik kayıt ücreti, sunucu ve veritabanı, bildirim, SMS ve harita gibi servislerin bedeli ile yıllık bakım bütçesi hesaba girer. Mağaza ve servis ücretlerini doğrudan kendi hesabınızdan ödersiniz; böylece hiçbir altyapı bize bağlı kalmaz. Web tarafında hazır seçenekleri görmek isterseniz paketler sayfamız fikir verir. Uygulama için ise kapsamı ve bedeli ön görüşmeden sonra yazılı iletiriz.

Yayından sonra bakım neden şart?

Bir uygulama yayına çıktığı gün bitmez; işletim sistemleri, mağaza kuralları ve kullandığınız kütüphaneler her yıl değişir. Örneğin Google Play, hedef API seviyesi şartına göre 31 Ağustos 2026’dan itibaren yeni uygulamalardan ve güncellemelerden Android 16’yı (API seviyesi 36) hedeflemelerini istiyor. Mevcut uygulamalar da hedef API’lerinden daha yeni Android sürümü çalıştıran cihazlarda yeni kullanıcılara görünmeye devam etmek için en az Android 15’i (API 35) hedeflemek zorunda. Güncellenmeyen bir uygulama bu yüzden sessizce görünürlük kaybeder.

Ayrıca 30 Eylül 2026’dan itibaren Brezilya, Endonezya, Singapur ve Tayland’daki sertifikalı Android cihazlarda, Play dışından dağıtılanlar dahil uygulamaların doğrulanmış bir geliştiriciye kayıtlı olması gerekiyor; Google bu şartı 2027’de tüm dünyaya yaymayı planlıyor.

Bakım planımız şu işleri kapsar:

• Sürüm uyumu: yeni iOS ve Android sürümlerinde test, hedef API ve SDK güncellemeleri.
• Hata ve çökme takibi: çökme raporlarını izler, kritik hataları öncelikle düzeltiriz.
• Güvenlik: kütüphane güncellemeleri, sunucu yamaları ve düzenli yedekler.
• Ölçüm: analitik olayları, dönüşüm hunisi ve mağaza istatistikleri.

Yayın sonrası büyüme de planın parçasıdır. Mağaza sayfasındaki başlık, açıklama, ekran görüntüleri ve anahtar kelimeler için temel ASO ayarlarını yaparız. Kampanya bağlantılarınızı UTM oluşturucu ile etiketleyebilir, basılı materyallere indirme bağlantısını QR kod oluşturucu ile ekleyebilirsiniz. Uygulamanıza trafik getirmek için Google Ads yönetimi ve SEO danışmanlığı hizmetlerimiz aynı strateji altında çalışır.

Mobil uygulama geliştirme firması seçerken nelere bakmalısınız?

Teklifleri karşılaştırırken yalnız toplam bedele bakmak yanıltıcıdır. Aynı rakam bir firmada backend ve bakım dahil bir ürün, diğerinde yalnız ekran tasarımı anlamına gelebilir. Karar vermeden önce şu soruları sormanızı öneririz:

• Sahiplik: kaynak kod deposu, mağaza hesapları, sunucu ve alan adı kimin adına?
• Kapsam: ekran listesi, entegrasyonlar ve kabul kriterleri yazılı mı?
• Test: TestFlight ya da kapalı testle gerçek cihazlarda deneme var mı?
• Bakım: yayından sonraki güncellemeler, hata düzeltmeleri ve hedef API işleri nasıl yürüyecek?
• Deneyim: firma daha önce benzer karmaşıklıkta yazılım geliştirdi mi?

Biz bu soruların cevabını sözleşmeye yazarız. İlk görüşmede fikrinizi dinler, uygun teknolojiyi ve olası riskleri açıkça söyleriz; bir işin bize uygun olmadığını düşünürsek bunu da söyleriz. Talha Aslan dijital pazarlama uzmanı, Google Partner ve Full Stack Developer olarak stratejiyi ve sonucun sorumluluğunu taşır. Ekibimiz yazılım tarafında SaaS platformları, CRM ve otomasyon sistemleri geliştirdi. Çalışmalarımızı referanslar sayfasında görebilir, projenizi konuşmak için bize yazabilirsiniz.