> rehber --mobil-uygulama
İstanbul'da mobil uygulama geliştirme hizmeti nedir?
Mobil uygulama geliştirme, bir iş fikrinin iOS ve Android cihazlarda çalışan, App Store ve Google Play'den indirilebilen bir ürüne dönüştürülmesi hizmetidir. Uni Digital Group olarak İstanbul'da keşif, UX/UI tasarım, uygulama ve backend geliştirme, test, mağaza yayını ve bakım adımlarını tek bir ekip içinde yürütüyoruz.
Ofisimiz Beşiktaş'ta, Levent ile Etiler arasında. Toplantıları iş yerinizde, ofisimizde veya çevrim içi yapıyoruz. Proje boyunca test sürümlerini kendi telefonunuzda deneyerek ilerlersiniz; kararları ekran görüntüleri yerine çalışan uygulama üzerinden verirsiniz. “Mobil uygulama yaptırmak istiyorum ama nereden başlayacağımı bilmiyorum” diyorsanız bu rehber, ilk görüşmeden önce kararlarınızı netleştirmeniz için hazırlandı.
Native mi, cross-platform mu: hangi teknolojiyi seçmelisiniz?
Native geliştirmede iOS için Swift, Android için Kotlin ile iki ayrı uygulama yazılır. Cross-platform geliştirmede ise React Native veya Flutter ile tek kod tabanından iki platforma birden çıkılır. İçerik, katalog, rezervasyon ve hesap yönetimi ağırlıklı uygulamalarda cross-platform genellikle yeterlidir; cihaz donanımını yoğun kullanan projelerde native öne çıkar.
React Native, resmî sitesinde belirtildiği gibi JavaScript ile yazılan arayüzü platformun yerel bileşenleriyle çizer. Flutter ise Google tarafından desteklenen, tek kod tabanından yerel olarak derlenen çok platformlu uygulamalar üretmeye yarayan açık kaynaklı bir çatıdır. İki yaklaşımı temel ölçütlerle karşılaştırdık:
Native ve cross-platform mobil uygulama geliştirmenin karşılaştırması| Ölçüt | Native (Swift / Kotlin) | Cross-platform (React Native / Flutter) |
|---|
| Kod tabanı | Her platform için ayrı kod | iOS ve Android için ortak kod; platforma özel kısımlar ayrıca yazılır |
|---|
| Cihaz özelliklerine erişim | Yeni platform özelliklerine en doğrudan erişim | Çoğu özellik hazır eklentilerle; eksik kalan için native modül yazılır |
|---|
| Arayüz | Platformun kendi bileşenleri ve araçlarıyla tam kontrol | React Native yerel bileşenlerle çizer; Flutter her pikseli kendi çizim motoruyla kontrol eder |
|---|
| Geliştirme ve bakım | İki kod tabanı; değişiklikler iki kez yapılır | Tek kod tabanı; değişikliklerin çoğu bir kez yapılır |
|---|
| Uygun olduğu projeler | Artırılmış gerçeklik, yoğun grafik, gelişmiş kamera ve sensör kullanımı | E-ticaret, rezervasyon, içerik, kurumsal iç uygulamalar ve MVP |
|---|
| Gereken yetkinlik | Swift ve Kotlin uzmanlığı | JavaScript/TypeScript (React Native) veya Dart (Flutter) |
|---|
Kararı kod dilinden önce ürün ihtiyacı belirler. Keşif aşamasında kamera, konum, Bluetooth, bildirim ve ödeme gibi cihaz özelliklerini listeliyor, her biri için bakımı süren hazır bir eklenti olup olmadığını kontrol ediyor ve teknoloji önerimizi bu listeye göre gerekçelendiriyoruz.
Her fikir uygulama gerektirmez. İçerik ağırlıklı bir tanıtım için mobil uyumlu bir kurumsal web sitesi daha hızlı ve ekonomik olabilir. Apple da App Store İnceleme Yönergeleri'nin 4.2 maddesinde, yeniden paketlenmiş bir web sitesinin ötesine geçmeyen uygulamaların mağazaya uygun olmayabileceğini belirtiyor.
Bir mobil uygulama projesi hangi parçalardan oluşur?
Mağazada gördüğünüz uygulama, projenin yalnızca bir parçasıdır. Eksiksiz bir mobil uygulama projesi; UX ve arayüz tasarımını, iOS ve Android uygulamasını, verileri yöneten backend ve API katmanını, içerik ile siparişlerin yönetildiği admin panelini, push bildirimlerini, analitiği, mağaza yayınını ve yayından sonraki bakımı birlikte kapsar.
UX ve arayüz tasarımı
Kullanıcı akışlarını önce wireframe ile çıkarır, tıklanabilir bir prototipte dener, ardından iOS ve Android'in arayüz alışkanlıklarına uygun görsel tasarıma geçeriz. Prototip, kapsam hatalarını kod yazılmadan yakalamaya yardımcı olur.
Backend ve API
Kullanıcı hesapları, siparişler, içerikler ve bildirim tetikleri sunucu tarafında çalışır. ERP, CRM veya e-ticaret altyapınızla entegrasyon gerekiyorsa API katmanını bu sistemlere göre tasarlar; kapsamlı ihtiyaçları özel yazılım geliştirme ve ERP yazılımı ve otomasyon hizmetlerimizle aynı planda ele alırız.
Admin paneli
Kampanya, içerik, kullanıcı ve sipariş yönetimi için web tabanlı bir yönetim paneli kurarız. Böylece bir metni veya görseli değiştirmek için her seferinde yeni sürüm yayınlamanız gerekmez.
Push bildirimleri
Sipariş durumu, randevu hatırlatması ve kampanya duyuruları için bildirim altyapısı kurarız. Bu iş için kullandığımız Firebase Cloud Messaging, Google'ın belgelerine göre iOS ve Android'i birlikte destekleyen, platformlar arası bir mesajlaşma çözümüdür.
Analitik
Ekran görüntülenmelerini, dönüşüm adımlarını ve çökme raporlarını ölçmeden yapılan geliştirme tahmine dayanır. Analitik olaylarını keşifte belirlenen iş hedeflerine göre kurar, yayından sonra kararları bu veriyle veririz.
Mağaza yayını
App Store Connect ve Google Play Console kayıtlarını, ekran görüntülerini, açıklama metinlerini, gizlilik beyanlarını ve inceleme notlarını hazırlar, inceleme sürecini takip ederiz.
Bakım ve zorunlu güncellemeler
Apple ve Google teknik şartlarını düzenli olarak günceller. Google Play, 31 Ağustos 2026'dan itibaren yeni uygulamaların ve güncellemelerin Android 16'yı (API düzeyi 36) hedeflemesini istiyor. Apple ise 28 Nisan 2026'dan bu yana App Store Connect'e yüklenen uygulamaların Xcode 26 ve iOS 26 SDK'sı ile derlenmesini şart koşuyor. Bakım, uygulamanın bu şartlara uyumlu kalmasını sağlar.
Mobil uygulama geliştirme süreci hangi adımlardan oluşur?
Süreci altı adımda yürütüyoruz: keşif, prototip, MVP geliştirme, test, mağaza yayını ve bakım. Her adımın sonunda çıktıyı sizinle birlikte gözden geçirip onayınızla bir sonraki adıma geçiyoruz; böylece kapsam, bütçe ve takvim her aşamada birlikte kontrol ediliyor. Adımların ayrıntısını mobil uygulama geliştirme süreci yazımızda da anlattık.
- Keşif. Hedef kullanıcıyı, çözülecek sorunu, olmazsa olmaz özellikleri ve entegrasyonları netleştiririz. Çıktı; ekran listesi ve önceliklendirilmiş özellik listesinden oluşan yazılı bir kapsam dokümanıdır.
- Prototip. Ana akışları tıklanabilir bir prototipte canlandırır, sizinle ve mümkünse birkaç gerçek kullanıcıyla deneriz. Geliştirmeye yalnızca onaylanmış akışlarla başlarız.
- MVP geliştirme. İlk sürümde fikri doğrulayacak çekirdek özellikleri geliştiririz. Kısa aralıklarla test sürümleri paylaşır, geri bildirimlerinizi bir sonraki geliştirme dönemine alırız.
- Test. Farklı cihaz ve işletim sistemi sürümlerinde işlev, performans ve güvenlik testleri yaparız. iOS'ta Apple'ın TestFlight servisiyle, Android'de Google Play'in kapalı test kanalıyla gerçek kullanıcılardan geri bildirim toplarız.
- Mağaza yayını. Mağaza kayıtlarını, gizlilik beyanlarını ve inceleme notlarını hazırlayıp uygulamayı App Store ve Google Play incelemesine göndeririz. Ret gelirse gerekçeyi ilgili kurala göre düzeltip yeniden göndeririz.
- Bakım. Çökme raporlarını ve kullanıcı geri bildirimlerini izler, işletim sistemi güncellemelerine uyum sağlar, yeni özellikleri planlı sürümlerle yayınlarız.
App Store ve Google Play'de yayın için hangi şartlar var?
İki mağaza da uygulamayı yayından önce inceler. Apple, App Store İnceleme Yönergeleri'ne; Google ise Google Play geliştirici politikalarına uyum arar. Ortak beklentiler şunlardır: eksiksiz ve çalışan bir sürüm, uygulama içinde ve mağaza kaydında gizlilik politikası, doğru veri beyanı ve hesap açılabilen uygulamalarda hesabı silme imkânı.
App Store ve Google Play yayın şartlarının karşılaştırması| Konu | App Store (Apple) | Google Play |
|---|
| Kurallar | App Store İnceleme Yönergeleri | Geliştirici Politika Merkezi |
|---|
| Gizlilik | Uygulama içinde ve App Store Connect'te gizlilik politikası bağlantısı (Yönerge 5.1.1(i)); ürün sayfasında gösterilen gizlilik ayrıntıları | Veri güvenliği formu; veri toplamayan uygulamalar da formu doldurup gizlilik politikası bağlantısı vermeli |
|---|
| Hesap silme | Hesap oluşturulabiliyorsa silme işlemi uygulama içinden başlatılabilmeli (Yönerge 5.1.1(v)) | Uygulama içi silme yolu ve silme talebi için bir web bağlantısı |
|---|
| Test | TestFlight ile iç ve dış test kullanıcıları | 13 Kasım 2023'ten sonra açılan kişisel hesaplarda, en az 12 test kullanıcısıyla aralıksız 14 günlük kapalı test |
|---|
| İnceleme süresi | Apple'a göre başvuruların ortalama %90'ı 24 saatten kısa sürede incelenir | Bazı hesaplarda 7 güne, istisnai durumlarda daha uzun sürebilir |
|---|
| Teknik şart | 28 Nisan 2026'dan bu yana Xcode 26 ve iOS 26 SDK ile derleme | 31 Ağustos 2026'dan itibaren Android 16 (API düzeyi 36) hedefleme |
|---|
| Hesap sahibi | Kurum olarak kayıtta D-U-N-S numarası gerekir; kurum adı mağazada satıcı olarak görünür | Kişisel veya kurumsal geliştirici hesabı |
|---|
Apple, App Review sayfasında çözülmemiş inceleme sorunlarının ortalama %40'tan fazlasının 2.1 Uygulama Bütünlüğü maddesiyle, yani çökme, yer tutucu içerik ve eksik bilgi gibi konularla ilgili olduğunu belirtiyor. Bu yüzden giriş gerektiren uygulamalarda inceleme ekibi için demo hesabı hazırlıyor, backend servislerini inceleme boyunca açık tutuyor ve yer tutucu içerik bırakmıyoruz.
Ödeme modeli de baştan planlanmalı. Dijital içerik veya abonelik satan uygulamalar kural olarak Apple'ın uygulama içi satın alma sistemini kullanır (Yönerge 3.1.1). Fiziksel ürün veya uygulama dışında tüketilen hizmet satan uygulamalar ise ödemeyi Apple Pay ya da kart girişi gibi başka yöntemlerle alır (Yönerge 3.1.3(e)).
Uygulamanın hangi hesaptan yayınlanacağı da önemlidir. Apple, bankacılık ve sağlık gibi düzenlemeye tabi alanlarda hizmet veren uygulamaların bireysel geliştiriciler yerine hizmeti sunan tüzel kişilikçe gönderilmesini istiyor (Yönerge 5.1.1(ix)). Genel olarak da uygulamayı şirketinizin geliştirici hesabından yayınlamanızı öneriyoruz; mağaza kaydı ve kullanıcı ilişkisi baştan sizin adınıza olur.
Mobil uygulamada KVKK ve veri güvenliği nasıl sağlanır?
Uygulamanız kişisel veri işliyorsa 6698 sayılı Kişisel Verilerin Korunması Kanunu'ndaki yükümlülükler geçerlidir: kullanıcıyı veri toplanırken aydınlatmak, verilere hukuka aykırı erişimi önleyecek teknik ve idari tedbirleri almak ve yurt dışındaki sunuculara aktarımda Kanun'un 9. maddesine uymak. Bu nedenle güvenliği kodlamadan önce, tasarım aşamasında ele alıyoruz.
- Aydınlatma ve izinler: Kanun'un 10. maddesi, veriler elde edilirken veri sorumlusunun kimliğinin, işleme amacının, verinin aktarılabileceği tarafların, toplama yönteminin, hukuki sebebin ve ilgili kişinin haklarının bildirilmesini şart koşar (KVKK: Aydınlatma Yükümlülüğü). Aydınlatma metnine uygulama içinden ulaşılmasını; konum, kamera ve rehber gibi izinlerin yalnızca ilgili özellik kullanılırken ve gerekçesiyle istenmesini sağlarız.
- Teknik ve idari tedbirler: KVKK'nın veri güvenliği sayfasına göre veri sorumlusu, uygun güvenlik düzeyini sağlayacak her türlü teknik ve idari tedbiri almak zorundadır. Mobil tarafta bu tedbirler arasında şifreli bağlantı (HTTPS/TLS), belirteç tabanlı kimlik doğrulama, rol bazlı yetkilendirme, hassas verinin cihazda şifreli saklanması ve erişim kayıtları yer alır.
- Yurt dışına aktarım: Sunucu, analitik veya bildirim servisleri yurt dışındaysa aktarım, 1 Haziran 2024'te yürürlüğe giren değişiklikle yenilenen 9. maddeye göre yeterlilik kararı ya da standart sözleşme gibi uygun güvencelere dayanmalıdır (KVKK: Yurt Dışı Aktarım).
- Mağaza beyanlarıyla tutarlılık: Aynı veri envanteri App Store gizlilik ayrıntılarında ve Google Play veri güvenliği formunda da beyan edilir; uygulamaya eklenen üçüncü taraf SDK'ların topladığı veriler de bu beyana dahildir.
Konuyu mobil uygulama güvenliği ve KVKK uyumlu geliştirme yazımızda daha ayrıntılı ele aldık. Web sitenizdeki çerez ve aydınlatma metinleri için KVKK ve çerez politikası rehberimize bakabilirsiniz. Kanunun tam metni Mevzuat Bilgi Sistemi'nde yer alıyor.
Not: Bu bölüm genel bilgilendirme amaçlıdır ve hukuki görüş değildir. Projenize özgü değerlendirme için bir KVKK uzmanına veya avukata danışmanızı öneririz.
Mobil uygulama yaptırmak için görüşmeden önce neler hazırlanmalı?
Görüşmeye bir sayfalık bir özetle gelmek keşif süresini kısaltır ve farklı firmalardan aldığınız teklifleri karşılaştırılabilir kılar. Özette çözmek istediğiniz sorun, hedef kullanıcı, ilk sürümde şart olan özellikler, entegre edilecek sistemler, örnek aldığınız uygulamalar, bütçe aralığı ve hedef yayın tarihi yer almalı.
- Sorun ve hedef kullanıcı: Uygulama kimin, hangi işini kolaylaştıracak? Tek cümlelik net bir cevap, özellik tartışmalarında pusula olur.
- Özellik listesi: Özellikleri “ilk sürümde şart” ve “sonra eklenebilir” diye ikiye ayırın; MVP kapsamı bu ayrımdan çıkar.
- Örnek uygulamalar: Beğendiğiniz ve beğenmediğiniz birkaç uygulamayı nedenleriyle not edin.
- Mevcut sistemler: Web sitenizin, e-ticaret altyapınızın, ERP, CRM veya ödeme kuruluşunuzun API erişimi olup olmadığını öğrenin.
- Geliştirici hesapları: Apple Developer Program'a kurum olarak kaydolmak için D-U-N-S numarası, kurum alan adına bağlı bir e-posta adresi ve yayında bir web sitesi gerekiyor. Google Play Console hesabını da şirketiniz adına açmanızı öneriyoruz.
- Marka ve içerik: Logo, renkler, yazı tipleri, metinler ve görseller hazırsa tasarım ve geliştirme daha hızlı ilerler.
- KVKK hazırlığı: Hangi kişisel verileri hangi amaçla işleyeceğinizi ve aydınlatma metni ile gizlilik politikasını kimin hazırlayacağını belirleyin.
- Bütçe ve takvim: Bir bütçe aralığı ve hedef yayın tarihi, kapsamı gerçekçi kurmamızı sağlar.
Mobil uygulama teklifi nasıl hazırlanıyor?
Teklifi keşif görüşmesinden sonra, kapsamı ekran ve özellik bazında yazıya dökerek hazırlıyoruz. Fiyatı platform sayısı, özellik ve ekran kapsamı, backend ile admin paneli ihtiyacı, entegrasyonlar ve tasarım düzeyi belirliyor. Paketlerin başlangıç fiyatlarını ve fiyatı etkileyen etkenleri mobil uygulama fiyatları sayfamızda ayrıntılı olarak paylaşıyoruz.
Yazılı teklifte kapsamdaki özellikleri, teslim edilecek dosyaları, test ve yayın adımlarını, bakım süresini ve ödeme planını ayrı ayrı yazıyoruz. Kapsam dışında kalan istekleri de ayrıca belirtiyoruz; böylece farklı firmaların tekliflerini aynı kapsam üzerinden karşılaştırabilirsiniz. Hazırsanız teklif formumuzu doldurabilir veya iletişim sayfamızdan bize ulaşabilirsiniz.
İstanbul'da mobil uygulama şirketi seçerken nelere bakmalısınız?
Bir mobil uygulama şirketi seçerken yayındaki uygulama örneklerine, keşif ve test sürecinin nasıl işlediğine, kaynak kod ile mağaza hesaplarının kime ait olacağına, bakım koşullarına ve KVKK yaklaşımına bakın. Fiyat tek başına ölçüt değildir; aynı kapsamı içermeyen iki teklif aynı işi anlatmaz.
- Yayındaki işler: Mağazadan indirebildiğiniz uygulamaları kendiniz deneyin. Bizim çalışmalarımız için referanslarımızı inceleyin.
- Süreç: Keşif, prototip ve test adımları teklifte yazılı mı?
- Sahiplik: Kaynak kodun, tasarım dosyalarının ve mağaza hesaplarının kime ait olacağı sözleşmede açıkça yazıyor mu?
- Bakım: Yayından sonra hata düzeltme ve işletim sistemi uyumu nasıl ücretlendiriliyor?
- İletişim: Proje boyunca kiminle, hangi sıklıkta görüşeceksiniz?
Kendi yöntemimizi de bu sorulara göre anlatıyoruz: keşif sonrası yazılı kapsam, onaylı prototip, düzenli test sürümleri ve yayından sonra planlı bakım. Sonuç vaadi yerine süreci şeffaf tutmayı tercih ediyoruz.