Mobil uygulama mı, web uygulaması mı? İşletmeler için karar rehberi

Üç seçenek: yerel, çapraz platform ve web uygulaması

“Uygulama yaptırmak istiyoruz” cümlesi aslında üç farklı teknik yolun herhangi birini anlatıyor olabilir. Karar vermeden önce bu üçünü ayırmak gerekir:

1. Yerel (native) uygulama: Her işletim sistemi için o sistemin kendi diliyle ve araçlarıyla ayrı ayrı yazılan uygulamadır; Android için Kotlin, iOS için Swift gibi. Cihazın özelliklerine en doğrudan erişen ve performansı en öngörülebilir yoldur. Karşılığında iki platform için iki ayrı kod tabanı yazılır ve bakımı yapılır.
2. Çapraz platform uygulama: Flutter gibi bir teknolojiyle tek kod tabanından hem iOS hem Android uygulaması üretilir. Kullanıcı açısından mağazadan indirilen normal bir uygulamadır. Çoğu iş uygulaması için yeterlidir; çok özel donanım işlerinde sınırları olabilir.
3. Web uygulaması ve PWA: Tarayıcıda açılan, bir web sitesinden çok bir araç gibi davranan yazılımdır. Mağazadan indirilmez; linke tıklayınca açılır. Progressive Web App (PWA) ise bunun kurulabilir hâlidir: ana ekrana eklenir, kendi penceresinde açılır ve doğru kurulduğunda bağlantı zayıfken de çalışabilir.

PWA nedir, ne değildir?

Google’ın web.dev belgeleri PWA’yi, modern tarayıcı yetenekleriyle geliştirilmiş, güvenilir çalışan ve kurulabilen web uygulamaları olarak tanımlıyor. Kurulabilirliğin temeli, uygulamanın adını, simgesini ve nasıl açılacağını anlatan bir web app manifest dosyasıdır. Çevrimdışı çalışmayı ve arka planda bildirim almayı ise service worker sağlar: uygulama ile sunucu arasında duran, istekleri yakalayıp önbellekten ya da ağdan cevap verebilen bir betik. Service worker yalnızca güvenli bağlantıda (HTTPS) çalışır.

Kurulum her platformda aynı görünmez. Android’de ve masaüstünde Chrome ile Edge bir kurulum seçeneği sunar. iPhone ve iPad’de tarayıcı kendiliğinden kurulum önermez; kullanıcı Paylaş menüsünden “Ana Ekrana Ekle”yi seçer. Bu fark, iOS kullanıcısı yoğun bir kitlede kurulum oranını doğrudan etkiler; kullanıcıya bu adımı göstermek tasarımın parçası olmalıdır.

Asıl soru “uygulama mı, site mi?” değil; “kullanıcımın telefonda neye ihtiyacı var, onu en az bakım yüküyle hangi yol verir?”

Karar tablosu: altı ölçütte karşılaştırma

Aşağıdaki tablo, kararı etkileyen ölçütleri üç seçenek için yan yana koyuyor. Rakam içermiyor; çünkü süre ve bütçe, seçenekten çok uygulamanın kapsamına bağlı.

Ölçüt	Yerel (native)	Çapraz platform	Web uygulaması / PWA
Cihaz özelliklerine erişim	En geniş: kamera, sensörler, Bluetooth, arka plan işleri	Çoğu özellik eklentilerle; çok özel donanım işlerinde sınır olabilir	Tarayıcının izin verdiği kadar (kamera, konum gibi); destek tarayıcıya ve işletim sistemine göre değişir
Bildirim	Tam destek	Tam destek	Android ve masaüstünde tarayıcı üzerinden; iPhone ve iPad’de iOS/iPadOS 16.4’ten beri yalnızca ana ekrana eklenmiş web uygulamalarında, kullanıcı izniyle
Mağaza görünürlüğü	App Store ve Google Play’de listelenir	App Store ve Google Play’de listelenir	Mağazada listelenmez; arama motorlarında bulunur, linkle ve QR kodla paylaşılır
Güncelleme	Her sürüm mağaza incelemesinden geçer, kullanıcı güncellemeyi alır	Yerel ile aynı	Sunucuya yüklendiği anda herkeste güncel; inceleme beklenmez
Bakım	İki ayrı kod tabanı; her işletim sistemi güncellemesine uyum	Tek kod tabanı; teknoloji ve eklenti güncellemeleri takip edilir	Tek kod tabanı; farklı tarayıcılarda test
Maliyeti etkileyenler	Platform sayısı, ekran ve özellik sayısı, sunucu tarafı, iki ekipli bakım	Ekran ve özellik sayısı, entegrasyonlar, sunucu tarafı	Ekran ve özellik sayısı, çevrimdışı ve bildirim ihtiyacı, sunucu tarafı

Tablonun gözden kaçan satırı “güncelleme”dir. Bir web uygulamasında hatayı düzeltip yayına aldığınızda herkes bir sonraki açılışta düzeltilmiş sürümü görür. Mağaza uygulamasında aynı düzeltme inceleme sürecinden geçer ve bazı kullanıcılar eski sürümde kalabilir. Sık değişen içerik ve kurallarla çalışan işletmeler için bu fark, maliyetin kendisi kadar önemlidir.

Hangi işletmeye hangisi?

Teknik karar, işin kendisinden çıkar. Sık karşılaştığımız durumlara göre genel eğilim şöyle:

1. Randevu, rezervasyon, katalog ve teklif formu: Klinik, salon, büro, restoran gibi işletmelerde müşteri çoğunlukla bir kez gelir, işini görür ve çıkar. İyi tasarlanmış bir web uygulaması ya da mobil uyumlu bir web sitesi çoğu zaman yeterlidir; müşteriyi bir uygulama indirmeye ikna etmek gerekmez.
2. İç kullanım panelleri ve saha formları: Teklif, sipariş, stok, servis kaydı gibi işler için çalışanların telefondan açtığı bir web paneli hızlı ve ekonomik bir başlangıçtır. Bu tür size özel panelleri ve araçları masaüstünde ve telefonda tarayıcıdan çalışacak şekilde kuruyoruz. Kamera ile belge tarama, konum takibi ya da bağlantısız bölgede çalışma kritikse mağaza uygulaması gündeme gelir.
3. Kampanya ve kısa süreli etkinlikler: Birkaç gün ya da hafta yoğun kullanılacak bir araç için mağaza süreci çoğu zaman gereksiz bir yüktür. Link, sosyal medyada paylaşıldığı anda kullanılabilir olmalıdır.
4. Sadakat, sık sipariş ve düzenli bildirim: Müşterinin haftada birkaç kez açtığı, bildirimin işin merkezinde olduğu yapılarda mağaza uygulaması güçlü bir seçenektir. Kitleniz ağırlıklı olarak iPhone kullanıyorsa, web bildirimlerinin yalnızca ana ekrana eklenmiş uygulamalarda çalıştığını hesaba katın.
5. Cihaza derinden bağlı ürünler: Bluetooth cihazla konuşan, sensör verisi işleyen ya da yüksek performanslı grafik isteyen uygulamalarda yerel veya çapraz platform geliştirme gerekir.

Kendi işlerimizden bir örnek: referanslarımız arasındaki 6 Haziran Rozet Stüdyosu, kendi sosyal sorumluluk projemiz olarak geliştirdiğimiz bir web uygulaması. Ceza infaz personeli adını, kurumunu ve unvanını yazıyor, fotoğrafını seçiyor ve rozetini telefonundan indiriyor; uygulama indirmek gerekmiyor. Fotoğraf sunucuya yüklenmiyor, işlem kullanıcının tarayıcısında yapılıyor. 700’den fazla rozet oluşturuldu. Kısa sürede çok kişiye ulaşması gereken bir kampanya için mağaza uygulaması burada gereksiz bir engel olurdu.

Mağaza yayın süreci: genel hatlarıyla

Mağaza uygulaması seçtiyseniz, yayın kendi başına bir iş adımıdır. Süreler Apple ve Google’ın kendi işleyişine bağlıdır; burada yalnızca genel akışı anlatıyoruz.

App Store

Apple, App Store İnceleme Yönergeleri’nde her uygulamanın yayından önce incelendiğini belirtiyor. Gönderilen sürümün eksiksiz ve çalışır olması beklenir; giriş gerektiren uygulamalarda inceleme ekibine bir deneme hesabı verilmesi ve sunucu tarafının açık tutulması gerekir. Gizlilik politikası bağlantısı hem mağaza bilgilerinde hem uygulamanın içinde kolayca erişilebilir olmalıdır. İşletmeleri en çok ilgilendiren madde ise asgari işlevsellik kuralıdır: Apple, yeniden paketlenmiş bir web sitesinin ötesine geçmeyen, yeterince kullanışlı ya da “uygulama gibi” olmayan uygulamaların App Store’a ait olmadığını açıkça yazıyor.

Google Play

Google Play’de yayından önce Play Console’daki uygulama içeriği beyanları tamamlanır: gizlilik politikası, reklam içerip içermediği, giriş gerekiyorsa erişim bilgileri, hedef kitle, içerik derecelendirmesi ve hassas izin kullanılıyorsa izin beyanları. Kasım 2023’ten sonra açılan kişisel geliştirici hesaplarında, uygulama herkese açılmadan önce belirli sayıda testçiyle kapalı test yapılması ve ardından üretim erişimi için başvurulması gerekiyor.

Her iki mağazada da geliştirici hesaplarının sizin adınıza açılmasını öneriyoruz; uygulama sizin markanızla yayınlanır ve hesabın sahipliği sizde kalır.

Önce web uygulamasıyla başlayıp sonra mağazaya geçmek

Pek çok işletme için en sağlıklı yol, fikri önce bir web uygulamasıyla gerçek kullanıcıya açmak, kullanım verisi gelince mağazaya geçmektir. Bu yolun işe yaraması için baştan iki şeye dikkat etmek gerekir:

1. Sunucu tarafını ayrı kurun: Verinin ve iş kurallarının bir API arkasında durduğu bir yapıda, sonradan yazılacak mobil uygulama aynı sunucuyu kullanır. Böylece mağazaya geçişte yalnızca arayüz katmanı yeniden yazılır, üyelikler ve kayıtlar olduğu gibi kalır.
2. Mağaza yolunu baştan bilin: web.dev belgelerine göre bir PWA, Google Play’de Trusted Web Activity ile paketlenerek yayınlanabilir; bunun için uygulama ile sitenin aynı geliştiriciye ait olduğu Digital Asset Links ile doğrulanır. App Store tarafında ise yalnızca siteyi gösteren bir kabuk, az önce andığımız asgari işlevsellik kuralına takılabilir. iOS’ta ciddi bir mağaza varlığı istiyorsanız, çapraz platform bir uygulamayı ikinci aşama olarak planlamak daha gerçekçidir.

Bu yaklaşım bütçeyi de korur: ilk sürümde hangi özelliklerin gerçekten kullanıldığını görürsünüz ve mağaza uygulamasına yalnızca işe yarayanları taşırsınız. Web tarafının bütçesini neyin belirlediğini merak ediyorsanız web sitesi fiyatları rehberimiz iyi bir başlangıç.

Sık yapılan hatalar

1. “Herkesin uygulaması var” diye uygulama istemek: Müşterinin yılda birkaç kez kullanacağı bir iş için uygulama indirtmek zordur. Önce kullanım sıklığını ve gerçek ihtiyacı yazın.
2. Bildirimi web uygulamasında her cihazda aynı sanmak: iPhone ve iPad’de web bildirimi, uygulama ana ekrana eklenmeden ve kullanıcı izin vermeden çalışmaz. Kitlenin cihaz dağılımına göre plan yapılmalı.
3. Web sitesini olduğu gibi mağazaya koymaya çalışmak: Uygulamaya özgü değer katmayan bir kabuk, App Store incelemesinde reddedilebilir ve kullanıcıya da bir şey kazandırmaz.
4. Bakımı bütçeye yazmamak: Mağaza uygulamaları işletim sistemi güncellemelerine uyum ister; web uygulamaları da tarayıcı değişikliklerine karşı test edilmelidir. Yayın, işin sonu değil başlangıcıdır.
5. Uygulama içi tarayıcıları unutmak: Linkler çoğu zaman Instagram ya da WhatsApp içinden açılır ve bu kısıtlı tarayıcılarda bazı işlemler sorun çıkarabilir. 6 Haziran Rozet Stüdyosu’nda indirme adımı için kullanıcıyı harici tarayıcıya yönlendiren bir uyarı ekledik; test, kullanıcının gerçekten kullanacağı ortamda yapılmalı.
6. Mesajlaşmayı unutmak: Bazen müşterinin istediği bir uygulama değil, sorusuna hızlı cevaptır. Randevu ve bilgi taleplerinde WhatsApp yapay zekâ asistanı ya da yapay zekâ otomasyonları bir uygulamadan daha hızlı sonuç verebilir.

Seven’s Design olarak bir uygulama talebinde ilk işimiz, ihtiyacın gerçekten mağazadan indirilen bir uygulama mı yoksa telefonda çalışan bir web uygulaması mı olduğunu birlikte netleştirmek oluyor. Fikrinizi ve kullanıcılarınızı anlatmak isterseniz teklif formundan bize yazabilirsiniz; doğru yolu, kapsamı ve yazılı teklifi birlikte çıkaralım.

Sıkça sorulan sorular

Kaynaklar

Bu yazıda dayandığımız birincil kaynaklar (erişim: Kasım 2026). Platform kuralları ve belgeler değişebilir; güncel metni kaynağından kontrol edin.

• web.dev: Progressive Web Apps
• web.dev: PWA kurulumu
• web.dev: Service worker
• MDN: Service Worker API
• WebKit: iOS ve iPadOS’ta web uygulamaları için Web Push
• Chrome for Developers: Trusted Web Activity
• Apple: App Store İnceleme Yönergeleri
• Play Console Yardım: Uygulama içeriği beyanları
• Play Console Yardım: Yeni kişisel hesaplar için test şartları