Mobil uygulama nasıl yapılır?
Mobil uygulama yedi adımda yapılıyor: kapsamı yazmak, akışı taslakla denemek, mağaza hesaplarını açmak, uygulamayı geliştirmek, test etmek, incelemeye gönderip yayınlamak, yayından sonra ölçüp güncellemek. Önce uygulamanın gerekli olup olmadığına bakın; tekrar eden kullanım, bildirim ya da cihaz özelliği yoksa mobil uyumlu site yeter. Maliyeti kapsam, platform seçimi ve bakım belirliyor.
Mobil uygulama nasıl yapılır sorusuna cevap vermeden önce başka bir soruyu sormanız gerekiyor: Uygulama gerçekten gerekli mi? Sitemdeki mobil uygulama sayfası da bu soruyla başlıyor, çünkü uygulama mobil uyumlu siteden pahalı ve bakımı sürekli. Gerekliyse yol belli: kapsam, tasarım, geliştirme, test, mağaza kayıtları ve yayın. Aşağıda her adımı, Apple ve Google'ın resmî belgelerinden 2 Ekim 2026'da doğruladığım şartlarla anlatıyorum.
Yazı karardan yayın sonrası bakıma kadar ilerliyor. Tek bir maliyet rakamı vermiyorum; kalemleri ve neye göre değiştiklerini yazıyorum. Ajansın bu işi nasıl yürüttüğü sitemdeki mobil uygulama geliştirme sayfasında yazıyor; burada işin kendisine odaklanıyorum.
Uygulama mı, mobil uyumlu site mi, PWA mı?
Üç seçeneğin farkı, kullanıcıdan ne istediklerinde ve telefonun özelliklerine ne kadar erişebildiklerinde. Mobil uyumlu site adres yazılınca açılıyor, kurulum istemiyor. PWA, yani progresif web uygulaması, MDN'nin tanımıyla bir web sitesi gibi tek kod tabanından birçok cihazda çalışıyor; bir uygulama gibi cihaza kurulabiliyor, çevrimdışı ve arka planda işleyebiliyor. Mağaza uygulaması ise App Store ve Google Play üzerinden kuruluyor.
| Seçenek | Kullanıcı ne yapıyor? | Ne zaman mantıklı? |
|---|---|---|
| Mobil uyumlu site | Adresi açıyor, kurulum yok | Bilgi vermek, teklif ve randevu toplamak, arama motorundan müşteri çekmek |
| PWA | Tarayıcıdan açıyor, isterse cihaza kuruyor | Sık kullanılan, hafif ve çevrimdışı çalışması yeterli araçlar |
| Mağaza uygulaması | Mağazadan indiriyor | Bildirim, kamera, konum, barkod ya da güçlü çevrimdışı çalışma işin kendisi olan işler |
Uygulamayı haklı çıkaran dört durum
- Kullanıcı aynı işi tekrar tekrar yapıyor: sipariş, randevu, takip, ölçüm girişi.
- Kullanıcıya siz ulaşmak zorundasınız: sipariş durumu, randevu hatırlatması.
- Kamera, konum, barkod okuma ya da NFC gerekiyor.
- Uygulama internet yokken de çalışmalı: saha ekibi, depo sayımı, teslimat.
Tarayıcı bir yere kadar gider; sonrası uygulamanın alanı. Dördünden hiçbiri sizin için geçerli değilse aynı bütçeyle hızlı, mobil uyumlu bir site daha çok iş getirir; sitemdeki mobil uygulama sayfası da aynı şeyi söylüyor. Örnek de o sayfada: İş ortağı bir firmayla birlikte yürüttüğüm Tekno Kart'ta bilinçli olarak uygulama yapılmadı, çünkü kart telefona dokundurulunca profil tarayıcıda açılıyor ve karşı tarafın bir şey indirmesi gerekmiyor. Kendi fikrinize de aynı soruyu sorun: Kullanıcı bunun için bir uygulama indirmeye değer bulur mu?
Siteyi olduğu gibi bir uygulama kabuğuna sarmak da çözüm değil. Apple'ın inceleme kurallarının 4.2 maddesi, uygulamanın yeniden paketlenmiş bir web sitesinin ötesinde özellik, içerik ve arayüz sunmasını istiyor; yeterince kullanışlı ya da "uygulama gibi" değilse mağazaya kabul edilmeyebilir. Mobil site yolunu seçerseniz kurulum ve test ayrıntılarını mobil uyumlu web sitesi yazısında topladım, sayfaları kurmanın kapsamı için web tasarım sayfasına bakabilirsiniz.
Native, çapraz platform ya da web teknolojisi: Hangisini seçmeli?
Uygulamayı iki biçimde yazabilirsiniz: her platform için ayrı (native) ya da tek kod tabanından iki platforma. Üçüncü yol, yukarıda anlattığım PWA. Seçimi ekibinizin neyi bildiği, iki platforma da ihtiyacınız olup olmadığı ve bakımı kimin yapacağı belirliyor.
Native geliştirme
iOS için Swift ve Xcode, Android için Kotlin ve Android Studio kullanıyorsunuz. Apple, Swift'i Apple platformları için dil, Xcode'u geliştirme, test ve dağıtım aracı olarak tanıtıyor. Android Studio, Android'in resmî geliştirme ortamı; Kotlin de Android geliştirmede tam destekli. Bedeli açık: İki ayrı kod tabanı demek, aynı özelliği iki kez yazmak ve iki yazılımı ayrı ayrı güncellemek demek.
Çapraz platform: Flutter ve React Native
Flutter, kendi tanımıyla tek kod tabanından yerel derlenen, çok platformlu uygulamalar için açık kaynak bir çatı; Dart diliyle çalışıyor. React Native ise React kullanarak Android ve iOS uygulaması yazmanızı sağlıyor ve kendi sayfasına göre React bileşenlerini platformun yerel arayüz öğelerine dönüştürüyor.
Ben hangisini seçerim?
Giriş, liste, form, bildirim ve ödeme ekranlarından oluşan bir işletme uygulaması için tek kod tabanlı bir çatıyı tercih ediyorum: Özelliği bir kez yazıyor, iki platforma gönderiyorsunuz. Sitemdeki mobil uygulama sayfası da aynı yolu izlediğini yazıyor. Cihaza çok yakın çalışacak bir işiniz varsa, örneğin gelişmiş kamera işleme, native'e daha sıcak bakarım. Bunlar benim ölçütlerim, kesin kural değil.
Adım adım mobil uygulama geliştirme süreci nasıl işler?
Süreç yedi adımdan oluşuyor. Sırayı değiştirmeyin; en pahalı hatalar ilk iki adımda, kodlamaya başlamadan önce gizleniyor.
- İhtiyacı ve ilk sürümün kapsamını yazın. Uygulamanın hangi işi çözeceğini, hangi ekranlardan oluşacağını ve ilk sürümde nelerin olmayacağını kâğıda dökün.
- Akışı tıklanabilir bir taslakla deneyin. Tek elle kullanım, dokunma hedeflerinin boyutu ve geri dönüş davranışı bu aşamada çözülüyor. Kod yazılmadan önce düzeltmek, sonradan düzeltmekten genellikle daha ucuza geliyor.
- Mağaza hesaplarını erkenden açın. Apple'da kuruluş kaydı D-U-N-S numarası istiyor, Google'da kişisel hesabın yayından önce 14 günlük kapalı testi var; ikisi de takvimi uzatabilir. TestFlight App Store Connect üzerinden, Google'ın kapalı testi Play Console üzerinden yürüyor. Ayrıntısı bir sonraki bölümde.
- Geliştirin ve ara sürümleri gerçek telefona kurun. Arka uç (hesaplar, veri, yönetim paneli) varsa ona bağlanın, yoksa uygulamayla birlikte kurun.
- Test edin. Apple'ın 2.1 maddesi uygulamanın cihazda hata ve kararlılık açısından denenmiş olmasını, girişi olan uygulamada demo hesabın verilmesini ve arka uç servisinizin açık tutulmasını istiyor. Apple beta dağıtımı için TestFlight'ı gösteriyor; Google'da kapalı test var.
- Mağaza metinlerini hazırlayıp yayına gönderin. Gizlilik politikası, veri beyanı ve mağaza açıklamaları hazır olsun, sonra incelemeyi bekleyin. Ret gelirse gerekçeyi giderip yeniden gönderin.
- Ölçün, güncelleyin. İndirme sayısı başarı ölçüsü değil; indirenlerin birinci, yedinci ve otuzuncu günde uygulamayı hâlâ açıp açmadığına bakın.
Mağaza hesabı ve inceleme: Neleri baştan hazırlamalısınız?
İki mağaza da yayından önce geliştirici hesabı istiyor ve ikisinin şartları farklı. Aşağıdaki tablo, 2 Ekim 2026'da resmî sayfalarda gördüğüm hâli gösteriyor; ücretler ve şartlar değişebiliyor, başvurmadan önce sayfaları yeniden açın.
| Konu | Apple | Google Play |
|---|---|---|
| Kayıt ücreti | Yılda 99 USD. Fiyat bölgeye göre değişebiliyor, kayıt sırasında yerel para birimiyle gösteriliyor | 25 USD, tek seferlik |
| Hesap türü | Bireysel (şahıs ya da tek kişilik işletme) veya kuruluş | Kişisel veya kuruluş |
| Kuruluş şartı | Tüzel kişilik, D-U-N-S numarası, kuruluşun alan adına bağlı e-posta, herkese açık ve çalışan web sitesi | D-U-N-S numarası zorunlu; Google'a göre başvuru ücretsiz |
| Yayın öncesi test | Beta için TestFlight | 13 Kasım 2023'ten sonra açılan kişisel hesapta kapalı test: en az 12 test kullanıcısı, kesintisiz en az 14 gün |
Hesabı kimin adına açtığınız önemli. Apple, kuruluş adını (bireysel kayıtta yasal adınızı) mağazada uygulamanın satıcı adı olarak gösteriyor. Ayrıca DBA, ticari ad ve şube kayıtlarını kabul etmediğini yazıyor. Hesabı bir ajansın adına açtırırsanız mağazada görünen sahip de ajans olur. Sitemdeki mobil uygulama sayfası bu yüzden hesapların müşterinin adına açıldığını yazıyor; bu mağazanın kuralı değil, ajansın taahhüdü, o yüzden sözleşmede de arayın.
Apple incelemesinde takılan maddeler
- 2.1: Yer tutucu metin, boş web sitesi ya da geçici içerik kalmamış, tam çalışan bir sürüm gönderin.
- 5.1.1(i): Gizlilik politikasının bağı hem App Store Connect'teki alanda hem uygulamanın içinde, kolay erişilir yerde olmalı.
- 5.1.1(v): Uygulamada hesap oluşturulabiliyorsa hesabı uygulamanın içinden silme seçeneği de gerekiyor.
Google Play politikalarında takılan maddeler
- Gizlilik politikası bağı mağaza sayfasında ve uygulamanın içinde bulunmalı, adres çalışır durumda olmalı.
- Veri güvenliği formunu doldurmak zorundasınız: Uygulamanın ve içindeki SDK'ların topladığı veriyi beyan ediyorsunuz.
- Hesap oluşturan uygulama, uygulama içi silme yolunun yanında hesap silme talebi için bir web bağı da sunmalı.
Gizlilik politikası ve KVKK metni uygulamadan önce sitenizde hazır olsun. Hangi yasal metinlerin gerektiğini web sitesinde olması gerekenler yazısında sıraladım.
Mobil uygulama fiyatları neye göre değişir?
Bu yazıda uygulama fiyatı vermiyorum: Mobil uygulama geliştirme maliyetini kapsam belirliyor, kapsamı görmeden söylenen rakam tahmin olur. Sitemdeki mobil uygulama sayfası da sabit fiyat listesi vermiyor; nihai kapsam ve bütçe ihtiyaç görüşmesinin sonunda yazılı olarak netleşiyor. Önceden bilinen tek kalem mağaza kayıt ücretleri; onları yukarıdaki tabloda verdim. Gerisi şu kalemlere bağlı:
| Kalem | Neye göre değişiyor? |
|---|---|
| Kapsam | Ekran sayısı ve ilk sürümde neyin olup neyin olmayacağı |
| Tasarım | Hazır bileşenler mi, markaya özel arayüz ve çizim mi |
| Platform seçimi | Tek kod tabanı mı, iki ayrı native uygulama mı |
| Arka uç | Kullanıcı hesapları, veri ve yönetim paneli var mı; hazır sisteme bağlanmak mı, sıfırdan kurmak mı |
| Entegrasyonlar | Ödeme, muhasebe, kargo gibi dış sistem sayısı |
| Cihaz özellikleri | Bildirim, konum, kamera, barkod, çevrimdışı çalışma |
| Mağaza ve test | Geliştirici hesapları, test turları, olası inceleme reddi ve yeniden gönderim |
| Bakım | İşletim sistemi güncellemelerine uyum, çöküş takibi, mağaza şartlarındaki değişiklik |
Arka uç gerekiyorsa o da ayrı bir iş kalemi. Özel yazılım sayfası 2 Ekim 2026 itibarıyla çalışma modellerini "50.000 TL'den başlayan fiyatlarla" gösteriyor. Bu rakam özel yazılım içindir, bir mobil uygulamanın fiyatı değildir; kapsamınıza göre ikisi birlikte de gerekebilir, ayrı da.
Teklifleri karşılaştırırken dört soru sorun: Geliştirici hesapları kimin adına açılacak? Kaynak kod teslimde sizde mi? Bakım fiyata dâhil mi, ayrı mı? İnceleme reddi çıkarsa yeniden gönderim ek ücret mi? Sitemdeki mobil uygulama sayfasında dördünden üçünün cevabı açıkça yazılı: Hesaplar müşterinin adına açılıyor, kaynak kod teslimde müşteriye geçiyor, reddedilme hâlinde yeniden gönderimden ek ücret çıkmıyor. Dördüncüsü için sayfa bakımın işin kapsamına dâhil olduğunu yazıyor, fiyata nasıl yansıdığını söylemiyor; onu teklifte sorun.
Yayından sonra neler değişir?
Uygulama, yayınlandığı gün bitmiyor. Sitemdeki mobil uygulama sayfası bunu şöyle koyuyor: Uygulamalar siz hiçbir şey yapmasanız bile bozulur, çünkü işletim sistemleri yenilenir ve mağaza yeni zorunluluklar getirir. Google'ın hedef API düzeyi kuralı resmî bir örnek: 31 Ağustos 2026'dan itibaren yeni uygulamalar ve güncellemeler çoğu türde Android 16'yı (API düzeyi 36) hedeflemek zorunda; Wear OS ve Android Automotive OS için 35, Android TV ve Android XR için 34 yazıyor. Mevcut uygulamalar Android 15'i (API düzeyi 35) hedeflemezse, hedeflerinden daha yeni Android çalıştıran cihazlarda yeni kullanıcılara sunulmuyor. Bakım bütçesini baştan ayırın.
Uygulamanın bir tanıtım sayfası da gerekiyor. Apple kuruluş kaydında herkese açık ve çalışan bir web sitesi istiyor; uygulamanın sayfasını bu sitede tutmak mantıklı. Sayfayı diğer sayfalarınız gibi arama için kurmak isterseniz SEO hizmeti sayfasına bakın; sitenin hızını da Core Web Vitals yazısındaki ölçütlerle kontrol edin.
Sık Sorulan Sorular
Mobil uygulama yapmak için kodlama bilmem gerekir mi?
Uygulamayı kendiniz yazacaksanız evet. Bir ekiple çalışacaksanız kodlamadan çok kapsamı yazılı hâle getirmeniz gerekiyor: uygulamanın çözdüğü iş, ekranlar, ilk sürümde olmayacaklar.
iPhone ve Android için ayrı uygulama yaptırmam şart mı?
Hayır. Flutter ve React Native gibi çatılar tek kod tabanından iki platforma uygulama üretiyor. Ayrı native uygulama, iki kod tabanı ve iki ayrı bakım demek; cihaza çok yakın bir ihtiyacınız yoksa tek kod tabanı benim ilk tercihim.
Uygulamayı mağazaya koymak ücretli mi?
Evet. Apple Developer Program 2 Ekim 2026'da yılda 99 USD; Apple fiyatın bölgeye göre değişebildiğini ve kayıt sırasında yerel para biriminde gösterildiğini yazıyor. Google Play Console için sayfa 25 USD'lik tek seferlik kayıt ücreti diyor.
Google Play'de kişisel hesapla ilk yayın neden en az iki hafta sürüyor?
Google'ın sayfasına göre 13 Kasım 2023'ten sonra açılan kişisel hesaplar, yayından önce en az 12 test kullanıcısıyla kesintisiz en az 14 gün kapalı test yapmak zorunda; bu yüzden ilk yayın en az iki hafta sürüyor. Sonra üretim erişimi için başvuruyorsunuz. Sayfa bu şartı yalnız kişisel hesaplar için anlatıyor; kuruluş hesabı açacaksanız güncel şartı Google'ın sayfasından okuyun.
Mobil uygulama ne kadar sürede yapılır?
Kapsam belirliyor, tek rakam vermiyorum. Sitemdeki mobil uygulama sayfasındaki plan ihtiyaç ve kapsam için 1-2. haftayı, akış ve arayüz için 2-4. haftayı, geliştirmeyi dördüncü haftadan itibaren, mağaza yayını için 2-3 haftayı öngörüyor.
PWA mağaza uygulamasının yerini tutar mı?
İhtiyacınıza bağlı. MDN'ye göre PWA cihaza kurulabiliyor ve çevrimdışı çalışabiliyor; işiniz bunlarla bitiyorsa PWA yeterli olabilir. Uygulamanın mağazada bulunması ya da cihaz özelliklerine derin erişim gerekiyorsa mağaza uygulaması gerekiyor.
Mağaza hesabı kimin adına açılmalı, kaynak kod kimde kalmalı?
Bu iki konu ayrı ve ikisi de sözleşmeye bağlı; hesap sahipliği tek başına mülkiyet demek değil. Apple hesabın adını mağazada satıcı adı olarak gösteriyor, yani hesabı kimin adına açtığınız mağazada görünen sahibi belirliyor. Kaynak kodun kime geçeceğini ise mağaza değil sözleşmeniz belirliyor; yazılı isteyin. Sitemdeki mobil uygulama sayfasında şöyle yazıyor: Hesaplar sizin adınıza açılıyor, kaynak kod teslimde size geçiyor. Uygulamanın gerekip gerekmediğini birlikte değerlendirmek isterseniz iletişim sayfasından yazabilirsiniz.
