Mobil Uygulama mı Web Uygulaması mı: Hangisini Ne Zaman Geliştirmelisiniz (ve Maliyeti Ne Kadar)

Dijital bir ürün geliştirirken vereceğiniz en kritik kararlardan biri, harekete geçirici mesaj düğmenizde hangi rengi kullanacağınız ya da arkasına hangi veritabanını koyacağınız değildir. Bu karar; mobil uygulama mı, web uygulaması mı, yoksa ikisi arasında bir şey mi geliştireceğinizdir — ve çoğu ekip bu kararı çok hızlı, çok duygusal biçimde ya da rakiplerin ne yaptığına aşırı odaklanarak alır.

Bu hatayı sayamayacağımız kadar çok gördük. Bir kurucu, "müşteriler bunu bekliyor" gerekçesiyle ilk günden bir iOS uygulamasına ihtiyaç duyduğuna ikna olmuş hâlde bize geliyor. Altı ay ve 80.000 dolar sonra uygulama mağazada yerini alıyor, haftada iki indirme alıyor ve işletmenin edinimi artıracak pazarlama bütçesi kalmıyor. Bunun tersini de gördük — bir B2B SaaS şirketi, Android kapsamını tamamlayana kadar lansman yapmayı erteliyor; oysa web uygulamaları bir staging ortamında bitmiş ve test edilmemiş hâlde bekliyordu.

Mobil ile web arasındaki tercih, hırs veya teknik yetkinlik meselesi değildir. Kullanıcılarınızın gerçekte nerede olduğu, ne yapmaları gerektiği ve ne kadar sürdürebileceğiniz meselesidir. Doğru karar verirseniz daha hızlı gönderir, daha az harcar ve daha fazla kişiye ulaşırsınız. Yanlış karar verirseniz, bir web sitesi olarak mükemmel çalışacak bir ürün için yıllarca iki ayrı kod tabanını yönetirsiniz.

Bu rehber, müşterilere danışmanlık yaparken içsel olarak kullandığımız çerçeveyi size dürüstçe aktarma girişimimizdir. Seçenekleri net biçimde tanımlayacak, ödünleşimleri ele alacak, gerçek maliyet rakamlarını paylaşacak ve bugün kendi ürününüze uygulayabileceğiniz bir karar çerçevesi sunacağız.

---

Seçeneklerin Tanımı

Herhangi bir karşılaştırma yapmadan önce neyi karşılaştırdığımız konusunda uzlaşmamız gerekir. Bu terimler gevşek biçimde kullanılıyor ve bu belirsizlik insanlara paraya mal oluyor.

Native Mobil Uygulama (iOS ve/veya Android)

Native mobil uygulama, belirli bir işletim sistemi için o sistemin tercih ettiği araçlar ve diller kullanılarak geliştirilir. iOS uygulamaları, Xcode ve Apple'ın UIKit ya da SwiftUI çerçeveleri kullanılarak Swift veya Objective-C ile geliştirilir. Android uygulamaları ise Android Studio ve Google'ın Jetpack Compose ya da View sistemi kullanılarak Kotlin veya Java ile geliştirilir. Native bir uygulama, cihazın işletim sisteminde doğrudan çalışır, tüm donanım API'lerine tam erişime sahiptir ve App Store veya Google Play üzerinden dağıtılır.

Native uygulamalar en iyi performansı, cihaz donanımına en kapsamlı erişimi ve platforma özgü en gelişmiş kullanıcı deneyimini sunar. Ayrıca geliştirme maliyeti en yüksek olan, en fazla uzmanlık gerektiren ve her iki platformda bulunmak istiyorsanız iki tamamen ayrı kod tabanına yol açan uygulamalardır.

Çapraz Platform Mobil Uygulama (React Native / Flutter)

Çapraz platform uygulama, tek bir ortak kod tabanıyla yazılır ancak hem iOS hem de Android'de çalışacak şekilde derlenir veya render edilir. İki baskın çerçeve React Native (Meta tarafından geliştirilen, JavaScript/TypeScript ile yazılan) ve Flutter (Google tarafından geliştirilen, Dart ile yazılan) olarak öne çıkmaktadır. Her ikisi de uygulama mağazaları üzerinden dağıtılan ve cihazın native özelliklerinin çoğuna — ancak tamamına değil — erişebilen uygulamalar üretir.

Çapraz platform geliştirme "bir kez yaz, her yerde çalıştır" olarak konumlandırılmaktadır; ancak bu vaadin önemli çekinceler gerektirdiğini ilerleyen bölümlerde ele alacağız. Temel çekicilik maliyet açısındandır: tek ekip, tek kod tabanı, iki platform.

Progresif Web Uygulaması (PWA)

Progresif Web Uygulaması, modern web standartlarıyla geliştirilmiş ve birçok açıdan native mobil uygulama gibi davranabilen bir web sitesidir. PWA'lar kullanıcının ana ekranına eklenebilir, çevrimdışı çalışabilir, push bildirimleri alabilir (Android'de ve — önemli kısıtlamalarla — iOS'ta) ve kamera ile GPS gibi belirli donanım özelliklerine tarayıcı API'leri aracılığıyla erişebilir. Uygulama mağazaları yerine tarayıcı üzerinden sunulur ve kullanıcı müdahalesi olmaksızın otomatik olarak güncellenir.

PWA'lar gerçek bir orta yolu temsil eder. Native uygulamalardan daha ucuza geliştirilirler ve uygulama mağazası varlığı ya da onay süreci gerektirmezler; ancak aşağıda ayrıntılandıracağımız, özellikle Apple cihazlarında gerçek özellik eksiklikleri mevcuttur.

Duyarlı Web Uygulaması

Duyarlı web uygulaması, düzenini farklı ekran boyutlarına — masaüstü, tablet ve mobil — uyarlayan ancak native uygulama deneyimini taklit etmeye çalışmayan tarayıcı tabanlı bir uygulamadır. Bir URL'de bulunur, çalışmak için internet bağlantısı gerektirir ve tarayıcı aracılığıyla erişilir. Bu, B2B araçlarının, SaaS kontrol panellerinin, yönetim panellerinin ve iç işletme sistemlerinin büyük çoğunluğu için standart seçenektir.

Duyarlı web uygulamaları çoğu ürün için varsayılan tercihtir. Geliştirmesi en az maliyetli, üzerinde yinelemesi en hızlı olan, platform bekçilerinden onay gerektirmeyen ve herhangi bir ek kod olmaksızın tarayıcısı olan her cihaza ulaşan uygulamalardır.

---

Native Mobilin Her Zaman Kazandığı Durumlar

Ürün türlerinin native mobilin bir tercih değil, bir zorunluluk olduğu net kategoriler vardır. Ürününüz bunlardan birine giriyorsa, tereddütsüz native geliştirmenizi öneririz.

Donanım erişimi ürününüzün merkezindedir. Uygulamanız sürekli GPS takibi, arka planda konum hizmetleri, gerçek zamanlı kamera işleme, NFC ödemeleri veya etiket okuma, Bluetooth Low Energy bağlantıları, temel Face ID istemlerinin ötesinde biyometrik kimlik doğrulama ya da Apple Watch veya Android Wear'dan kalp atış hızı gibi sağlık sensörlerine erişim gerektiriyorsa native geliştirmeniz gerekir. Web platformu son birkaç yılda cihaz erişimi konusunda anlamlı ilerleme kaydetmiştir; ancak native API'ler hâlâ çok daha yetenekli, güvenilir ve desteklidir. Bir kargo takip uygulaması, tıbbi cihaz eşlik uygulaması, temassız ödeme aracı — bunlar isteğe bağlı native uygulamalar değildir. Olmak zorunda oldukları için native'dir.

Çevrimdışı öncelikli yaklaşım, bir güzel özellik değil, temel bir gerekliliktir. Kullanıcılarınız düşük veya sıfır bağlantı ortamlarında düzenli olarak çalışıyorsa — saha çalışanları, lojistik operatörleri, uzak bölge araştırmacıları, pilotlar — ve uygulamanızın veri işlemesi, karmaşık durumu depolaması ve bağlantı yeniden sağlandığında güvenilir biçimde senkronize olması gerekiyorsa, native bu iş için önemli ölçüde daha güçlü araçlar sunar. PWA'lardaki service worker'lar birçok kullanım durumu için çevrimdışı işlevselliği karşılar; ancak native SQLite, Core Data, Room ve arka plan senkronizasyon temelleri büyük ölçekte daha güçlü ve daha kapsamlı biçimde test edilmiştir.

Push bildirimleri birincil etkileşim mekanizmasıdır. Evet, web push bildirimleri mevcuttur. Evet, PWA'lar Android'de bunları destekler. Ancak tüm ürün etkileşim modeliniz zamanında ve güvenilir push bildirimlerine bağlıysa — bir mesajlaşma uygulaması, gerçek zamanlı bir iş birliği aracı, canlı bir ticaret platformu — APNs ve FCM üzerinden native push hâlâ en güvenilir iletim yoludur. iOS 16.4'te tanıtılan iOS web push gelişmiş olmakla birlikte, native'de mevcut olmayan kısıtlamaları taşımaya devam etmektedir.

Bir oyun, AR/VR deneyimi ya da hesaplama yoğun herhangi bir şey geliştiriyorsunuz. WebGL ve WebAssembly, tarayıcının grafik yeteneklerini önemli ölçüde genişletmiştir; ancak gecikmeye duyarlı, GPU yoğun deneyimler için native, ihtiyacınız olan performans kapasitesine, Metal ve Vulkan'a erişime ve araç zinciri olgunluğuna sahiptir.

Birincil edinim kanalınız App Store'dur. "App Store Optimizasyonu" gerçekten büyümeyi beklediğiniz yol ise — organik mağaza keşfi pazara açılma stratejinizin bir parçasıysa — mağazada yer almanız gerekir. Tarayıcıdan yüklenen bir PWA, App Store arama sonuçlarında yer almaz. İş modeliniz Apple'ın veya Google'ın mağazaları üzerinden dağıtım gerektiriyorsa, native veya çapraz platform gerçek tek seçeneğinizdir.

---

Web Uygulamasının Yeterli Olduğu Durumlar

Şaşırtıcı derecede çok sayıda ürün için web uygulaması her şeyi karşılar — hatta dağıtım engelini tamamen ortadan kaldırdığı için çoğu zaman native uygulamadan daha iyi performans gösterir.

Çoğu B2B aracı ve iç yazılım. Kullanıcılarınız ürününüze öncelikle masaüstünden erişen çalışanlar, yükleniciler veya profesyonel müşterilerden oluşuyorsa — zaman zaman telefonda kullansalar bile — duyarlı bir web uygulaması neredeyse her zaman yeterlidir. Satın alma araçları, İK platformları, proje yönetim yazılımları, CRM kontrol panelleri, finansal raporlama sistemleri: bunlar tarayıcı sekmelerinde yaşar. Bir B2B aracı için native uygulama, kullanıcıya net bir fayda sağlamaksızın ikinci bir bakım yüzeyi oluşturur.

Kontrol panelleri, yönetim panelleri ve raporlama araçları. Bunlar temelden veri yoğun, etkileşim hafif arayüzlerdir. Gerçekten kullanılabilir olmak için genellikle büyük ekranlara ihtiyaç duyarlar; bu da mobili en iyi ihtimalle ikincil bir platform konumuna getirir. Web uygulamasını iyi geliştirin. Duyarlı yapın. Zaten kimsenin telefonunda kullanmayacağı bir kontrol paneli için native uygulama geliştirmeyin.

Rezervasyon, planlama ve randevu sistemleri. Kullanıcılar bunlara bir bağlantı üzerinden erişir — bir e-posta, SMS, QR kodu veya arama sonucu aracılığıyla. Rezervasyon akışı kısadır, oturum seyrek gerçekleşir ve kullanıcıdan üç dakikada tamamlanan bir iş akışı için uygulama yüklemesini istemek için zorlayıcı bir neden yoktur. Hızlı, mobil optimize edilmiş bir web sayfası bu bağlamda yükleme engelini ortadan kaldırdığı için bir uygulamadan daha iyi performans gösterir.

Erken aşama ürünler. Bir iş fikrini doğruluyorsanız, talebi test ediyorsanız veya hızla üzerinde yinelemeyi planladığınız bir MVP geliştiriyorsanız, web uygulamasıyla başlayın. Daha hızlı hareket eder, daha az harcar ve daha fazla esnekliğe sahip olursunuz. Ürünün gerçekte ne olması gerektiğini öğrendiğinizde her zaman sonradan native uygulama ekleyebilirsiniz. Sıralama sorusunu sonundaki SSS bölümünde ele alacağız.

Kullanıcıların bağlantı, e-posta veya arama yoluyla ulaştığı her türlü ürün. Keşif ve erişim tarayıcı üzerinden gerçekleşiyorsa — trafiğiniz öncelikli olarak referans, e-posta veya organik aramadan geliyorsa — bir web uygulaması kullanıcılarla tam olarak bulundukları yerde buluşur. Onlardan ürününüzü kullanabilmeden önce App Store'dan geçmelerini istemek dönüşüm oranını ciddi biçimde düşürür.

---

Progresif Web Uygulamaları — Orta Yol

PWA'lar, Google'ın 2015'te kavramı öne çıkarmasından bu yana önemli ölçüde olgunlaştı. Müşterilere bunları anlatırken hem neler yapabilecekleri hem de hâlâ nerede eksik kaldıkları konusunda dikkatli davranıyoruz; çünkü "bir PWA'nın teoride yapabilecekleri" ile "bir iPhone'da güvenilir biçimde yapabilecekleri" arasındaki uçurum hâlâ gerçektir.

Bir PWA'nın Gerçekten Yapabilecekleri

• Çevrimdışı işlevsellik — service worker'lar ve Cache API kullanılarak bir PWA, kaynakları önbelleğe alabilir, verileri IndexedDB'de depolayabilir ve ağ mevcut olmadığında çalışan bir arayüz sunabilir
• Ana ekrana yükleme — Android'de tarayıcı istemi aracılığıyla, iOS'ta ise Safari'deki "Ana Ekrana Ekle" seçeneğiyle bir PWA, ana ekranda bir simge olarak yüklenebilir ve bağımsız bir pencerede başlatılabilir
• Push bildirimleri — Android'de PWA push bildirimleri tarayıcının push hizmeti aracılığıyla güvenilir biçimde çalışır. iOS'ta (Safari 16.4+) web push artık desteklenmektedir ancak arka planda iletim ve bildirim gruplandırması konusunda çekinceler mevcuttur
• Kamera ve mikrofon erişimi — MediaDevices API aracılığıyla PWA'lar kamera ve mikrofona erişebilir. Bu, fotoğraf çekimi, QR kod taraması ve temel görüntülü sohbet için yeterlidir
• Coğrafi konum — tüm önemli tarayıcılarda PWA'larda çalışır, konuma duyarlı özellikler için uygundur
• Otomatik güncellemeler — kullanıcı müdahalesi gerekmez. Yeni bir sürüm yayınladığınızda kullanıcılar bir sonraki ziyaretlerinde onu alır

Bir PWA'nın Hâlâ Yapamadıkları

• iOS'ta arka plan senkronizasyonu sınırlıdır. Service worker arka plan senkronizasyonu iOS Safari'de tam olarak desteklenmez; bu da bir mesajlaşma uygulaması veya görev yöneticisinin ihtiyaç duyduğu türde güvenilir arka plan veri senkronizasyonunun native olmadan gerçekleştirilememesi anlamına gelir
• App Store varlığı yoktur. PWA'lar Apple'ın App Store'una veya Google Play'e gönderilemez. Bu, organik mağaza keşfinin, uygulama mağazası yorumlarının ve yalnızca bu kanallar aracılığıyla uygulama edinen kullanıcılara ulaşma imkânının olmadığı anlamına gelir
• NFC, Bluetooth'a (anlamlı düzeyde) veya gelişmiş sağlık API'lerine erişim yoktur
• Sınırlı arka plan işleme. Uygulama ön planda olmadığında çalışması gereken görevler — konum takibi, ses çalma meta veri kontrolleri, sensör sorgulama — web bağlamlarında kısıtlanmıştır

PWA'nın Doğru Tercih Olduğu Durumlar

Çevrimdışı desteğe, ana ekran yüklemeye veya temel push bildirimlerine ihtiyaç duyuyorsunuz ancak App Store varlığına ihtiyacınız yok ve donanım gereksinimleriniz kamera ve GPS ile sınırlıysa PWA doğru tercihtir. Belirli bir restoran grubuna ait yemek sipariş uygulaması, iç personel için saha veri toplama aracı, bir hizmet işletmesi için müşteri portalı — bunlar güçlü PWA adaylarıdır. Maliyetin %40-50'si kadar bir bedelle native uygulama hissinin %80'ini elde edersiniz.

---

Çapraz Platform ve Native — Gerçek Ödünleşimler

React Native ve Flutter için satış konuşması açıktır: tek kod tabanı yaz, hem iOS hem Android'e gönder, para tasarrufu et. Pratikte gerçeklik daha nüanslıdır.

React Native

React Native, JavaScript/TypeScript geliştiricilerinin native platform API'lerine köprü ile React tarzı bileşen mantığını kullanarak mobil uygulamalar geliştirmesini sağlar. Geliştirici deneyimi ilk günlere kıyasla dramatik biçimde iyileşti — Hermes motoru, yeni mimari (Fabric) ve üçüncü taraf kütüphane ekosistemi onu geniş bir uygulama yelpazesi için güvenilir bir seçenek haline getiriyor.

React Native şu durumlarda iyi çalışır: standart UI desenleri olan uygulamalar, mevcut JavaScript/React uzmanlığına sahip ekipler, pazara çıkış hızının platforma özgü mükemmel görünümden daha önemli olduğu ürünler.

React Native şu durumlarda zorlanır: karmaşık özel animasyonlar, derin donanım entegrasyonu, her iki platformda aynı anda gerçekten native hissettirmesi gereken uygulamalar ve güçlü disiplin olmaksızın aynı kod tabanı üzerinde çalışan büyük ekipler.

Flutter

Flutter farklı bir yaklaşım benimser — kendi kullanıcı arayüzünü tamamen kendisi render eder ve native platform widget'larını bypass eder. Bu onu platformlar arası son derece tutarlı ve UI render'lama açısından yüksek performanslı kılar; ancak uygulamanızın tam olarak native bir iOS veya Android uygulaması gibi görünüp hissettirmeyeceği anlamına gelir. Google, Flutter'a yoğun yatırım yapmıştır ve artık tek bir kod tabanından iOS, Android, web, masaüstü ve gömülü hedeflere derleme yapabilmektedir.

Flutter şu durumlarda iyi çalışır: Dart ile rahat olan ekipler, platformlar arası görsel tutarlılığın platforma özgü kurallardan daha önemli olduğu uygulamalar ve masaüstü veya web sürümüne de ihtiyaç duyan ürünler.

Flutter şu durumlarda zorlanır: kullanıcıların native platform geleneklerini (iOS'a özgü gezinme hareketleri gibi) beklediği uygulamalar, native iOS veya Android SDK'larıyla derin entegrasyon ve React Native'e kıyasla daha küçük — ancak büyüyen — kütüphane ekosistemi.

%70-80 Kod Paylaşımı Efsanesi

Hem React Native hem de Flutter ekipleri düzenli olarak platformlar arasında %70-80 kod paylaşımını temel bir avantaj olarak öne sürer. Bu teknik olarak doğru, pratik açıdan ise yanıltıcıdır. Platforma özgü olan %20-30'luk kısım genellikle en zor %20-30'dur — kamera hatları, push bildirim yönetimi, derin bağlantı, arka plan modları ve uygulama mağazası entegrasyon kodu. Paylaşılan %70'lik kısım büyük ölçüde UI bileşenleri ve iş mantığından oluşur; bu gerçekten değerlidir, ancak bir native'in fiyatına iki native uygulama alacağınızı varsayarak bütçe planlamamalısınız. Gerçekçi bir çapraz platform projesi, iki ayrı native uygulamanın yaklaşık %60-70'ine mal olur, %50'sine değil.

---

Maliyet Karşılaştırması

Bunlar, kendi proje teslimat deneyimimize ve mevcut piyasa ücretlerine dayanan gerçekçi aralıklardır. Buradaki "MVP", gönderilmeye hazır, eksiksiz bir ilk sürümü ifade eder — cilalı, özellik tamamlanmış bir ürünü değil.

Platform	MVP Geliştirme Maliyeti (USD)	Süre	Süregelen Bakım (Yıllık)
Duyarlı Web Uygulaması	15.000 – 60.000 $	8–20 hafta	5.000 – 20.000 $
Progresif Web Uygulaması	20.000 – 70.000 $	10–22 hafta	6.000 – 22.000 $
React Native (iOS + Android)	55.000 – 150.000 $	18–36 hafta	18.000 – 45.000 $
Flutter (iOS + Android)	50.000 – 140.000 $	16–34 hafta	16.000 – 40.000 $
Native iOS + Android (ayrı)	100.000 – 280.000 $+	28–52 hafta	30.000 – 80.000 $

Bu rakamlar hakkında birkaç not. Web uygulaması aralığının geniş olmasının nedeni, karmaşıklığın büyük ölçüde değişmesidir — 15.000 dolarlık basit bir rezervasyon sistemi, 60.000 dolarlık çok kiracılı bir SaaS platformundan çok farklı bir üründür. React Native ve Flutter aralıkları, tasarım ve QA dahil iki ila üç kişilik bir geliştirici ekibini varsayar. Native iOS + Android aralığı, paralel olarak yürütülen iki ayrı geliştirme akışını varsayar; sırayla yapılması zaman katabilir ancak paylaşılan tasarım varlıkları ve API çalışması sayesinde maliyeti %15-20 oranında azaltabilir.

Bakım maliyetleri işletim sistemi uyumluluk güncellemelerini, bağımlılık güncellemelerini, hata düzeltmelerini ve küçük özellik eklemelerini kapsar. Büyük özellik geliştirmeyi kapsamaz.

---

Uygulama Mağazası Maliyetleri ve Kısıtlamaları

Apple'ın App Store'u veya Google Play üzerinden dağıtım yapmayı planlıyorsanız, iş modelinizi belirleyici biçimde etkileyebilecek platform maliyetlerini geliştirme yatırımının ötesinde anlamanız gerekir.

Apple, uygulama içi satın alımlar ve aboneliklerden %30 komisyon alır. Uygulamanızda satılan herhangi bir ücretli işlevsellik varsa — abonelikler, krediler, dijital içerik — Apple %30 alır (küçük geliştiriciler ve ikinci yıl abonelikleri için %15). Aylık 50 dolarlık aboneliği olan bir SaaS ürünü için bu, tek bir işletme maliyeti ödemeden önce kullanıcı başına aylık 15 dolar gidiyor demektir. Pek çok B2B ürünü bu nedenle uygulama içi satın almalardan kaçınır ve kullanıcıları web üzerindeki ödeme sayfasına yönlendirir. Apple'ın yönergeleri bu konuda giderek daha katı hale geliyor — AB'deki DMA Avrupalı kullanıcılar için bazı kuralları değiştirdi, ancak küresel olarak komisyon yapısı çoğu kategori için geçerliliğini koruyor.

Uygulama inceleme gecikmeleri gerçektir ve öngörülemezdir. Apple'ın inceleme süreci ortalama iki ila dört gün sürer, ancak daha uzun sürebilir ve bir ret, yayın takviminizi bir hafta veya daha fazla geciktirebilir. Ürününüz hızlı yineleme gerektiriyorsa — acil düzeltmeler, A/B testleri, özellik bayrakları — App Store inceleme döngüsü, web uygulamasının sahip olmadığı bir sürtüşme yaratır. Kritik bir satış döneminde hata düzeltmesi App Store incelemesinde beklerken önemli gelir kaybeden müşterilerimiz oldu. Bu risk web'de mevcut değildir.

Yönerge kısıtlamaları mimari kararları zorla şekillendirebilir. Apple, uygulamaların yapıp yapamayacakları konusunda açık kurallara sahiptir — kullanıcı verisi silme işlemlerini nasıl ele almaları gerektiği, abonelik koşullarını nasıl sunmaları gerektiği, hangi içerik kategorilerine izin verildiği ve giderek artan ölçüde hangi ödeme yöntemlerine izin verildiği. Ürününüz düzenlenmiş veya hassas herhangi bir kategoriye yakınsa, App Store yönergelerinin ürün yol haritanızı beklenmedik biçimlerde şekillendirdiğini görebilirsiniz.

Bazı ürünler için — özellikle pazar yerleri, medya platformları ve karmaşık fiyatlandırma modelleri olan ürünler — App Store kısıtlamaları, web uygulamasını birincil ürün haline getirmek ve mobil uygulamayı birincil kanal yerine destekleyici bir kanal olarak konumlandırmak için güçlü bir argümandır.

---

Bakım Gerçekliği

Ekipler geliştirme maliyetlerini karşılaştırırken, gönderme maliyetinin sahip olma maliyeti olmadığını sıklıkla unutur. Her iki platformda da native mobil uygulama, web uygulamasının gerektirmediği süregelen yükümlülükler yaratır.

İşletim sistemi sürüm güncellemeleri zorunludur, isteğe bağlı değildir. Apple ve Google, her büyük işletim sistemi sürümüyle eski API'leri kullanımdan kaldırır, kullanıcı arayüzü kurallarını değiştirir ve yeni sistem gereksinimleri sunar. Her sonbahar yeni bir iOS sürümü gelir ve uygulamanızın işlevsel kalmak ve en son yönergelere uymak için test edilmesi, güncellenmesi ve yeniden gönderilmesi gerekir. Bu güncellemeleri görmezden gelirseniz uygulamanız yeni cihazlarda çalışmayı durduracak, uyumsuzluk nedeniyle mağazadan kaldırılacak ya da kullanıcı güvenini zedeleyen görsel ve davranışsal gerilimeler yaşanacaktır. Bu bir defalık bir maliyet değildir — kalıcı, tekrarlayan bir taahhüttür.

İki native uygulama iki bakım akışı anlamına gelir. iOS ve Android bağımsız döngülerde güncellenir. Bir platformda çalışan bir değişiklik zaman zaman diğerinde ayrı bir düzeltme gerektirebilir. Uygulamanızın bağımlı olduğu üçüncü taraf kütüphaneler her platform için farklı zaman çizelgelerinde geliştiriliyor olabilir. Üç ila beş yıllık bir ürün yaşam döngüsü boyunca iki native uygulamanın kümülatif bakım maliyeti, orijinal geliştirme maliyetine eşit olabilir veya onu aşabilir.

Web uygulamaları anında ve sessiz biçimde güncellenir. Bir web uygulamasına düzeltme veya yeni özellik deploy ettiğinizde, her kullanıcı sayfayı bir sonraki yükleyişinde onu alır. İnceleme süreci yok, sürüm parçalanması yok, telefonunu güncellemediği için ürününüzün iki yıl önceki sürümünü çalıştıran kullanıcılar yok. Yinelemeli geliştirme döngüleri yürüten ekipler için bu önemli bir operasyonel avantajdır.

---

Öneri Çerçevemiz

Bu soruları sırayla kullanın. Ürününüzün eninde sonunda ne olabileceğini hayal ettiğiniz şekilde değil, bugün var olduğu haliyle dürüstçe yanıtlayın.

1. Temel özellikleriniz yalnızca native'de mevcut donanım erişimi gerektiriyor mu? (Sürekli arka plan GPS, NFC, Bluetooth LE, gelişmiş kamera API'leri, sağlık sensörleri) — Evet ise, native veya çapraz platform geliştirin. Hayır ise devam edin.

2. Çevrimdışı öncelikli işlevsellik bir güzel özellik değil, temel bir gereklilik mi? (Kullanıcılar düzenli olarak bağlantısız ortamlarda çalışır ve tam uygulama işlevselliğine ihtiyaç duyar) — Evet ise, native veya çapraz platformu değerlendirin. Hayır ise devam edin.

3. App Store birincil kullanıcı edinim kanalınız mı? (Büyüme modeliniz organik mağaza keşfine bağlıdır) — Evet ise, mağazada yer almanız gerekir. Hayır ise devam edin.

4. Kullanıcılarınız öncelikli olarak mobil mi ve ürününüzle günde birkaç kez mi etkileşime giriyor? (Ürününüz ara sıra kullanılan bir araç değil, günlük kullanım tüketici uygulamasıdır) — Evet ise, PWA veya çapraz platform uygulamayı değerlendirin. Hayır ise devam edin.

5. Push bildirimlerine temel bir etkileşim mekanizması olarak ihtiyaç duyuyor musunuz? — Evet ise ve iOS'u hedefliyorsanız, çapraz platform uygulama ile web push'un sınırlamalarını kabul etmek arasında karar vermeniz gerekecektir. Hayır ise devam edin.

Bu noktaya ulaştıysanız: duyarlı web uygulaması neredeyse kesinlikle en iyi başlangıç noktanızdır. İyi geliştirin, mobilde hızlı yapın ve kullanıcı verileriniz gerçekte neye ihtiyaç duyduklarını söylediğinde mobil uygulama sorusunu yeniden değerlendirin.

---

Cyberbeak'te Bu Karara Nasıl Yaklaşıyoruz

Varsayılan önceliğimiz web uygulamasıyla başlamaktır. Bunları tercih ettiğimiz için değil, geliştirmeleri daha ucuz olduğu için de değil (her ne kadar genellikle öyle olsa da) — web uygulamaları bir ürünün erken aşamalarında büyük miktarda riski ortadan kaldırdığı için.

Bir web uygulaması, native uygulamanın yarısı kadar sürede geliştirilebilir. Bir bekçinin onayı olmadan güncellenebilir. Kullanıcıların herhangi bir şey yüklemesini gerektirmeden her cihazda onlara ulaşır. Ve mobil uygulama eklemenin zamanı geldiğinde — çünkü gerçek kullanıcılar buna ihtiyaç duyduklarını söylüyor, çünkü veriniz oturumların %80'inin mobilde gerçekleştiğini ve native özelliklerle etkileşimin gerçekten artacağını gösteriyor — bunu ilk günden native başlayan bir ekibin sahip olmadığı ürün bilgisiyle ekleyeceksiniz.

Pratikte, ilk günden native mobil ile başlamayı önerdiğimiz ürünler az sayıda kategoriye giriyor: App Store keşfedilebilirliğinin büyümenin merkezinde olduğu tüketici uygulamaları, ilk günden gerçekten donanım erişimine ihtiyaç duyan ürünler ve ürünün "hissinin" değer önerisinin merkezinde o kadar önemli olduğu ki native'den azının onu zayıflatacağı uygulamalar.

Geri kalanı için — B2B araçları, SaaS platformları, rezervasyon ve planlama sistemleri, pazar yerleri, iç araçlar ve erken aşama tüketici ürünleri — web ile başlıyor, mükemmel hale getiriyor ve kanıt gerektirdiğinde mobil katmanı ekliyoruz.

Çapraz platformun gerçekten mantıklı olduğu durumlarda, zaten JavaScript'te çalışan ekipler için React Native'e ve ürün birden fazla platformu kapsıyorsa (web, mobil ve masaüstü) veya görsel tutarlılık birincil gereksinim olduğunda Flutter'a yöneliyoruz.

---

SSS

Web uygulamasıyla başlarsam daha sonra mobil uygulama ekleyebilir miyim?

Evet ve bu genellikle doğru sıralamadır. Web uygulamasıyla başlamak hiçbir seçeneği kapatmaz — mobil uygulama kararını iyi almanız için kullanıcı verilerini ve ürün netliğini sağlar. Web uygulamanız için geliştireceğiniz API katmanı, mobil uygulamanızın tüketeceği aynı API katmanıdır. Sıfırdan geliştirmeniz gereken tek şey mobil ön yüz olacak ve bunu yaptığınız zaman ne yapması gerektiğini tam olarak biliyor olacaksınız.

React Native hakkında ne düşünüyorsunuz — artık neredeyse native kadar iyi değil mi?

React Native önemli ölçüde iyileşti ve geniş bir uygulama yelpazesi için gerçekten yetenekli bir çerçevedir. Standart UI desenleri olan ve derin donanım gereksinimleri olmayan ürünler için, çoğu kullanıcı için native'den ayırt edilemeyecek sonuçlar üretir. Hâlâ geride kaldığı yerler ise karmaşık animasyonlar, platforma native hissettiren özel gezinme hareketleri ve platformun yapabileceği şeylerin sınırlarını zorlaması gereken uygulamalardır. Uygulamanızın değer önerisi büyük ölçüde deneyimin etkileşim kalitesiyle ilgiliyse, React Native ile native arasındaki fark önem kazanabilir. Çoğu iş uygulaması için kazanmaz.

Web uygulaması ve mobil uygulamayı aynı anda geliştirmeli miyim?

Başlangıçta neredeyse hiçbir zaman. İkisini eşzamanlı olarak geliştirmek ön yüz maliyetinizi ikiye katlar, QA yüzeyinizi ikiye katlar, ekibinizin dikkatini böler ve kullanıcı geri bildirimi almadan önce her iki platform için tasarım kararları vermenizi zorlar. İstisna, her ikisi için net, doğrulanmış bir durum olduğunda — araştırmalardan biri masaüstünde diğeri mobilde olan, her birinin farklı bir bağlamda ürüne ihtiyaç duyduğu iki farklı kullanıcı grubunuz olduğunu bildiğinizde. Bu senaryo var, ama azınlıktadır. Biriyle başlayın, öğrenin, ardından genişletin.

Mobil ile web tercihi lansman zaman çizelgemi nasıl etkiler?

Native iOS uygulaması, karmaşıklığa bağlı olarak, eşdeğer web uygulamasına kıyasla tipik bir ürün zaman çizelgesine yaklaşık sekiz ila on altı hafta ekler. Çapraz platform dört ila on hafta ekler. PWA, standart duyarlı web uygulamasının üzerine iki ila dört hafta ekler. Bir son tarihe bağlıysanız — belirli bir lansman etkinliği, bir finansman kilometre taşı, mevsimsel bir pencere — bu fark belirleyici olabilir. Web uygulamasının yeterli olacağı bir lansman için native uygulama ısrarı nedeniyle tüm pazar penceresini kaçıran ürünler gördük.

Masaüstü uygulamaları hakkında ne düşünüyorsunuz — bu ayrı bir konu mu?

Büyük ölçüde evet, ancak ilişkilidir. Günümüzde geliştirilen "masaüstü uygulamaları"nın çoğu ya Electron'da (özünde paketlenmiş bir tarayıcı) çalışan web uygulamaları ya da Windows ve macOS için gerçekten native masaüstü uygulamalardır. Çoğu iş yazılımı için Electron veya bir web uygulaması yeterlidir. Notion, Figma, VS Code ve Slack gibi araçların tamamı Electron uygulamalarıdır — performans sınırlamaları gerçektir ancak çoğu kullanım durumu için kabul edilebilirdir. Gerçekten native masaüstü geliştirme (macOS için Swift, Windows için WinUI), hesaplama yoğun araçlar, yaratıcı yazılımlar veya işletim sistemi entegrasyonunun zorunlu olduğu ürünler için haklı kılınır. Flutter, özellikle zaten mobil için kullanıyorsanız, çapraz platform masaüstü için de güvenilir bir seçenektir.

---

Bu kararı bir ürün için düşünüyorsanız ve gerçekten geliştirip deploy ettiğimiz şeylere dayanan bir perspektif istiyorsanız, konuşmaktan mutluluk duyarız. Belirli bir platformu önermiyoruz — yapmaya çalıştığınız şey için en mantıklı olanı öneriyoruz. İletişime geçin ve ürününüzü anlatın.