Hizmet detayı

Mobil Uygulama Geliştirme

iOS ve Android için Flutter, React Native, Kotlin ve Swift ile yerel performansta mobil uygulamalar. App Store ve Google Play yayınlama süreçlerinde uçtan uca destek.

Done Dynamics; iOS mobil uygulama geliştirme, Android mobil uygulama geliştirme ve çapraz platform projelerde uçtan uca teslim yapan bir kurumsal yazılım şirketidir. Flutter, React Native, Kotlin ve Swift ile yerel performansta ürünler üretir; App Store ve Google Play yayınlama sürecini (sertifika, paketleme, mağaza optimizasyonu, beta dağıtım ve App Review yönetimi) uçtan uca biz yürütürüz.

Platformlar

iOS, Android ve çapraz platform — tek elden

Kullanıcılarınızın hangi telefonu kullandığı önemli değil; uygulamanız her ikisinde de yerel hisseder.

iOS

iPhone, iPad ve iPadOS için Apple Human Interface Guidelines ile uyumlu, yerel performanslı uygulamalar. iOS 15 ve üzeri desteklenir.

Android

Material Design 3 prensiplerine uyan, Android 8.0 ve üzeri tüm cihazlarda akıcı çalışan uygulamalar. Tablet ve Wear OS de kapsamda.

Çapraz Platform

Tek kod tabanından iOS ve Android — Flutter veya React Native ile zaman ve maliyetten kazanın, kullanıcı yerel deneyim alsın.

Yerel (Native)

Performans veya donanım entegrasyonu kritikse Kotlin ile saf Android, Swift ile saf iOS yazıyoruz. Tam yerel deneyim, tam yerel hız.

2 dakika · 4 soru

Mobil uygulama gerçekten gerekli mi, yoksa mobil site yeter mi?

Dört soru soruyoruz. Cevaplarınız mobil siteyi işaret ediyorsa bunu açıkça söylüyoruz.

Şu an yayında olan bir mobil uygulamanız var mı?

Soru 1 / 4

Şu an yayında olan bir mobil uygulamanız var mı?
Teknoloji

Flutter, React Native, Kotlin, Swift

İhtiyaca göre çapraz platformdan saf yerele kadar seçeriz; modaya değil, projenin gereksinimine göre.

Flutter

Dart tabanlı, tek kod tabanından iOS ve Android. Yüksek FPS, hızlı geliştirme, geniş paket ekosistemi. MVP'den kurumsala kadar.

React Native

JavaScript/TypeScript ekibiniz varsa ideal. Native modüllerle iOS ve Android API'larına tam erişim. Expo ve bare workflow desteği.

Kotlin

Android için resmi dil. Jetpack Compose ile modern, deklaratif UI. Coroutines ile temiz asenkron kod. Tam yerel performans.

Swift

iOS için resmi dil. SwiftUI ile modern arayüz, Combine ile reaktif veri akışı. ARKit, Core ML ve HealthKit gibi Apple çerçevelerine doğal erişim.

Çevrimdışı destek

SQLite, Realm, Hive, Drift. Yerel veri tabanı, çevrimdışı sıra ve çakışma çözümleme. İnternet kesilse de iş durmaz.

Backend ve API

REST ve GraphQL servisler, kimlik doğrulama, anlık bildirim (FCM, APNs), gerçek zamanlı veri (WebSocket, Supabase).

App Store ve Google Play

Yayınlama sürecinde uçtan uca destek

Mağaza süreci kod kadar kritik. Sertifika ve imzadan ASO\'ya, TestFlight\'tan App Review itirazına kadar her adımı biz yürütürüz.

  • App Store Connect

    Sertifika, profil ve App ID kurulumu; bundle yapılandırması; ekran görüntüleri, açıklama ve anahtar kelime stratejisi; TestFlight ile beta dağıtım; App Review başvurusu ve red gelirse itiraz/yanıt yönetimi.

  • Google Play Console

    Geliştirici hesabı kurulumu, AAB paketleme, imzalama (Play App Signing), Play Console ürün sayfası optimizasyonu, kapalı/açık test kanalları, üretim yayını ve politika ihlali yanıtları.

  • Mağaza Görsel ve Metin

    İkon, splash, mağaza ekran görüntüleri, kısa açıklama, uzun açıklama, anahtar kelime, kategori. ASO (App Store Optimization) prensiplerine göre.

  • Sürüm Sonrası Operasyon

    Çökme raporları, kullanıcı yorumlarına yanıt, hotfix yayınları, sürüm notları, otomatik dağıtım hattı (Fastlane/CI). Yayın bir kez değil, süregelen operasyon.

Kullanım Alanları

Üretebileceğimiz mobil uygulamalar

Müşteri uygulamasından saha aracına, e-ticaret uygulamasından IoT panele kadar geniş yelpaze.

Müşteri Uygulamaları

Sadakat, sipariş, randevu, kataloğunuz cebinde — markanızı her gün açılan ekrana taşıyan tüketici uygulamaları.

Saha & Operasyon

Teknisyen, kurye, depo personeli için barkod, imza, fotoğraflı tutanak ve çevrimdışı destekli iş emri uygulamaları.

Kurumsal İç Uygulama

Personel onayları, izin, bildirim, dahili katalog — şirket içi süreçlerin hep yanınızda olan mobil hali.

E-Ticaret & Pazaryeri

Hızlı ödeme, anında bildirim, kişiselleştirilmiş ana sayfa. Web sitenizden 2-3 kat dönüşüm uplift'i.

Sağlık & Fitness

HealthKit, Google Fit ve giyilebilir cihaz entegrasyonları ile veri toplayan, raporlayan, hedef takip eden uygulamalar.

IoT & Donanım

BLE, NFC, kamera, sensör entegrasyonları. Akıllı cihazlarınızı kullanıcıya bağlayan kontrol paneli olarak mobil uygulama.

Neden bizimle?

Mobil uygulama, ürünün cebe taşınmış halidir

Bu yüzden sadece kod değil; tasarım, ASO, yayın, analitik ve sürüm sonrası operasyon tek elden gelir.

  • Yerel görünüm, yerel hız

    Flutter ve React Native dahil her seçimde, animasyonlar 60+ FPS'de akar; jank yok, gecikme yok.

  • Tek ekipten dört çıktı

    Aynı ekip iOS, Android, App Store paketi ve Play paketi teslim eder. Koordinasyon yükü size geçmez.

  • Erişilebilirlik standart

    VoiceOver, TalkBack, dinamik yazı tipi boyutu ve renk kontrastı her ekran için kontrol edilir.

  • Marka kimliği güçlü

    Splash, ikon seti, mağaza görselleri ve onboarding — sadece kod değil, üründen önce gelen ilk izlenim.

  • Analitik ve hata izleme

    Crashlytics/Sentry, kullanım analitiği, AB testi altyapısı kurularak teslim edilir.

  • Sağlayıcı bağımlılığı yok

    Kaynak kod ve mağaza hesapları size aittir. İstediğiniz an başka bir ekibe geçirebilirsiniz.

Güvenlik

Mobilde güvenlik — kontrol listesi

Telefonda güvenlik tarayıcıdaki kadar görünür değildir; her madde gözle görülür hâle getirilir.

  • TLS 1.3 üzerinden sunucu iletişimi, sertifika sabitleme ile MITM koruması.
  • Hassas veriler iOS Keychain ve Android Keystore içinde, donanım destekli güvenlik unsurlarıyla saklanır.
  • Biyometrik kimlik doğrulama (Face ID, Touch ID, Android Biometric) hazır.
  • Kod karartma (R8/ProGuard, Swift Symbol Stripping) ile tersine mühendislik direnci.
  • OWASP Mobile Top 10 ve MASVS rehberlerine göre güvenlik denetimi.
  • KVKK ve GDPR uyumlu izin akışı, veri saklama ve silme süreçleri standart paket dahil.
Süreç

Fikirden mağaza yayınına

Beş aşamada teslim; her aşamada görünür çıktı.

  1. 01

    Keşif ve Hedefleme

    Hedef kitleyi, platformları, başarı ölçütlerini ve mağaza yayın gereksinimlerini birlikte netleştiririz.

  2. 02

    Tasarım ve Prototip

    iOS Human Interface Guidelines ve Material Design 3 paralel uygulanır. Tıklanabilir prototiple kullanıcı testi yapılır.

  3. 03

    Mimari ve Yığın

    Yerel mi (Kotlin/Swift), çapraz platform mu (Flutter/React Native) — performans, ekip ve süre kısıtına göre seçeriz.

  4. 04

    Geliştirme

    Test odaklı geliştirme, kod incelemesi ve sürekli entegrasyon. Haftalık beta dağıtım TestFlight ve internal track üzerinden.

  5. 05

    Yayın ve Süreç

    App Store ve Google Play başvuru, red yönetimi, ASO optimizasyonu. Yayın sonrası analitik, çökme izleme ve sürüm planı sizinle.

Ticari model

12 ay sabit · sürprizsiz yenileme

Mobil uygulama mağazada yayınlandığında bitmiş sayılmaz: iOS ve Android her yıl yeni sürüm çıkarır, mağaza kuralları değişir, sertifikaların süresi dolar. Bu yüzden hizmet 12 aylık sözleşmeyle veriliyor. Kapsam ve bedel baştan yazılır, yıl içinde değişmez; mağaza uyum güncellemeleri ve bakım bu bedelin içindedir. Yıl sonunda kullanım, yeni özellik talepleri ve bir sonraki yılın kapsamı birlikte gözden geçirilip sözleşme yeniden imzalanır — otomatik uzayan bir taahhüt yok.

İlgili hizmetler

İhtiyaca özel uygulama →

Mobil + masaüstü ve web aynı kod tabanından — Flutter ve .NET MAUI ile çoklu platform deneyimi.

Kurumsal web tarafı →

Mobil uygulamanızın arka ucunu ve yönetim panelini Next.js veya Astro ile kurarız.

Mobil veri güvencesi →

SQLite ve Realm tabanlı yerel veri tabanınız için bulut yedekleme ve eşitleme altyapısı.

Bir sonraki yazılım projenize hazır mısınız?

Ekibimizle 30 dakikalık ücretsiz bir keşif görüşmesi planlayın.

Proje Başlat Daha Fazla →

Mobil uygulama geliştirme: iki yol, tek karar

Mobil uygulama geliştirme: iki yol, tek karar

Aynı işi yapan iki uygulama sahaya iki ayrı yoldan çıkar. Biri Kotlin ve Swift ile her platform için ayrı yazılır; diğeri Flutter ya da React Native ile tek kod tabanından hem App Store'a hem Google Play'e gider. Mobil uygulama geliştirme bütçesinin nereye akacağı çoğu projede bu çatalda belli olur, daha ilk satır yazılmadan. Done Dynamics dört yığını da sahada kullanan bir kurumsal yazılım şirketi: Flutter, React Native, Kotlin ve Swift. Hangisinin seçileceğine modaya bakarak değil, uygulamanın ne yapacağına bakarak karar veriyoruz.

Aşağıdaki metin o kararın nasıl verildiğini anlatıyor. Donanıma ne kadar yaklaşacağınız, animasyonun ne kadar yoğun olacağı, ekibinizin hangi dili zaten bildiği, bakımı bir yıl sonra kimin devralacağı — hepsi aynı denklemin içinde duruyor. Sorular teknik görünür, karşılıkları ticaridir. Yanlış yığın seçimi kendini ikinci yılda faturayla hatırlatır; doğru seçim ise mobil uygulama geliştirmede harcanan eforun büyük kısmını arayüz tekrarı yerine ürünün kendisine aktarır.

Native ile çapraz platform arasındaki gerçek fark

Tartışma çoğu zaman yanlış yerden başlar. "Hangisi daha hızlı" sorusu, cihazların bugünkü işlemci gücünde neredeyse anlamını yitirdi; kullanıcı arayüzü akıcılığı iki tarafta da yakalanabiliyor. Asıl ayrım şurada: uygulamanız işletim sisteminin ne kadar derinine iniyor? Liste ekranı, form, kimlik doğrulama, sipariş akışı, bildirim — bunların tamamı çapraz platformda rahatça karşılanır. Kod tek, mağaza iki. Bakım yükü de tek gövdede toplandığı için küçük ve orta ölçekli ekipler bu tarafta nefes alır.

Kotlin ve Swift'e geçmenin gerekçesi genellikle üç başlıktan doğar: sürekli çalışan arka plan işleri, işletim sistemine yeni gelen bir çerçeveyi ilk günden kullanma isteği ve donanımla sıkı temas. Bir de dördüncüsü var, teknik olmayan ama en belirleyicisi: ekip. Şirketinizde iki Android geliştiricisi çalışıyorsa ve uygulamayı uzun vadede onlar taşıyacaksa, Flutter tercihiyle kendi ekibinizi kenara itmiş olursunuz. Alanya yazılım ekibimizle yaptığımız keşif görüşmelerinde bu soruyu ilk yarım saatte sorarız, çünkü cevabı mimariyi baştan değiştirir.

Bütçe tarafında aritmetik görünenden karmaşık. Tek kod tabanı iki platformu birden karşıladığı için ilk teslim maliyeti belirgin şekilde düşer; buna karşılık platforma özgü ince ayarlar, mağaza gereksinimleri ve nadiren de olsa yerel modül yazma ihtiyacı bu kazancın bir kısmını geri alır. İki ayrı native uygulama ise ilk gün pahalıdır ve her yeni özellikte iki kez ödeme yaparsınız. Kararı verirken bakılacak süre on iki ay değil, otuz altı ay.

Bir de karma yaklaşım var, sahada az konuşulur ama işe yarar. Uygulamanın gövdesi çapraz platformda kurulur, yalnızca kritik bir modül — arka planda çalışan konum takibi, kamera üzerinde gerçek zamanlı işlem ya da özel bir donanım protokolü — yerel kodla yazılıp köprüyle bağlanır. Böylece maliyetin büyük kısmı tek gövdede kalır, riskli parça kendi dilinde ele alınır. Mobil uygulama geliştirme kararını "ya hep ya hiç" olarak kurmak zorunda değilsiniz. Keşif aşamasında çıkardığımız gereksinim listesinde kaç maddenin yerel koda ihtiyaç duyduğuna bakar, sınır oradan geçer.

Donanıma yaklaştıkça denklem değişiyor

Kamera, NFC, Bluetooth Low Energy, ivmeölçer, barkod okuyucu, biyometrik doğrulama. Bir uygulama bunlardan birine dokunduğu anda tartışma teoriden çıkar. Çapraz platform tarafında bu köprülerin çoğu hazır paketlerle kuruluyor; paketin bakımı sürüyorsa mesele yok. Sürmüyorsa ne olur? O köprüyü siz yazarsınız, yani Kotlin ve Swift bilgisi projeye zaten girer.

Animasyon yoğunluğu ikinci eşik. Ekranlar arası geçişten ibaret bir hareket dili her yerde akar. Sürekli hareket eden bir harita katmanı, kare kare çizilen bir grafik ya da parmakla sürüklenen fizik tabanlı bir arayüz konuşulurken hesap değişir. Mobil uygulama geliştirme tarafında en çok yanılan varsayım şudur: prototipte akıcı görünen ekran, gerçek veriyle ve orta seviye bir telefonda aynı davranmaz. Bu yüzden performans testini üst segment cihazda değil, kullanıcı tabanınızın alt yarısını temsil eden cihazda yaparız.

Saha uygulamalarında tablo daha da netleşir. Depoda barkod okuyan, teknisyenin imzasını alan, fotoğraflı tutanak tutan bir araçta pil tüketimi ve kamera gecikmesi ölçülebilir iş kaybına dönüşür. Antalya yazılım projelerinde otel ve turizm operasyonlarından gelen taleplerin ağırlığı da burada toplanıyor: vardiya boyunca elde kalan, şarj bitirmeyen, tek elle kullanılan uygulamalar.

Tasarım ve erişilebilirlik: iki platform, iki alışkanlık

iOS kullanıcısı geri gitmek için ekranın solundan parmağını kaydırır. Android kullanıcısı sistem hareketini bekler. Sekmelerin nerede duracağı, onay diyaloğunun düğme sırası, tarih seçicinin görünümü, paylaşma menüsünün davranışı — hepsi iki dünyada farklı yerleşmiştir. Tek tasarımı iki platforma zorlamak, kullanıcıya "bu uygulama benim telefonuma ait değil" hissi verir. Bu his ölçülemez ama terk oranında görünür.

Çalışma yöntemimiz şu: ortak bir tasarım dili kurulur, platforma özgü kalıplar korunur. Apple'ın arayüz kılavuzuyla Material tasarım prensipleri paralel okunur; marka kimliği ikisinin üstünde durur. Tıklanabilir prototiple erken kullanıcı testi yapmak, kodda haftalar kazandırır — çünkü akış hatası tasarımda düzeltilirse bir saatlik iş, geliştirmede düzeltilirse bir haftalık iş olur.

Erişilebilirlik bu bölümün ayrılmaz parçası. Ekran okuyucu desteği, dokunma alanlarının yeterli büyüklükte olması, dinamik yazı tipi boyutuyla bozulmayan yerleşim ve renk kontrastı her ekran için kontrol edilir. Yaşlı kullanıcı grubuna hitap eden bir uygulamada yazı boyutu ayarını görmezden gelmek, kullanıcı tabanının bir kısmını daha ilk gün kaybetmek demektir. Mobil uygulama geliştirme tekliflerimizde erişilebilirlik ayrı bir ek kalem değil, teslimin standardı olarak yer alıyor.

API tarafı: uygulamanın asıl konuştuğu yer

Ekranlar görünen kısım. Uygulamanın kaderini belirleyen ise arkadaki sözleşmedir. İyi tasarlanmış bir API, mobil tarafın işini üçte bire indirir; kötü tasarlanmış olanı ise her ekranda telafi kodu yazdırır. Sayfalama nasıl yapılıyor, hata kodları makine tarafından okunabilir mi, tarih alanları hangi saat diliminde geliyor, listeler değişiklik damgasıyla mı dönüyor — bunlar mobil ekibin ilk gün sorduğu sorulardır.

Bir uygulamanın en pahalı hatası, her ekranın kendi veri modelini uydurmasıdır. Onun yerine tek bir sözleşme belirleriz ve sürümleriz. Sözleşme sürümlenirse eski uygulama sürümleri kırılmadan yaşamaya devam eder; sürümlenmezse bir sabah kullanıcıların yarısı boş ekrana bakar. Mobil tarafta güncellemeyi zorlayamazsınız. Kullanıcı isterse yıllarca eski sürümde kalır, bunu tasarımın parçası kabul etmek gerekir.

Şu detay projelerin çoğunda kazanç yaratır: aynı arka uç API'si web ile paylaşılabilir. Kurumsal panelinizi Next.js ya da Astro ile kurup mobil uygulamayı aynı servislere bağladığınızda iş kuralları tek yerde durur. İndirim mantığını iki kez yazmazsınız, yetkilendirmeyi iki kez sürdürmezsiniz. İstanbul yazılım tarafındaki müşterilerimizde en sık kurduğumuz yapı budur — mobil ve web aynı çekirdeği paylaşır, sadece arayüz katmanı ayrışır. Bir kurumsal yazılım şirketi için bu, teslim ettiği sistemin uzun ömürlü olup olmayacağını belirleyen tercihtir.

Kimlik doğrulama tarafında da mobilin kendine özgü kuralları var. Tarayıcıda oturumu çerezle taşırsınız; telefonda jeton yönetimi size kalır. Kısa ömürlü erişim jetonu ve yenileme jetonu ikilisi kurulur, jetonlar cihazın kasasında saklanır, uygulama arka plandan döndüğünde sessizce yenilenir. Kullanıcı her açılışta yeniden giriş yapmak zorunda kalmamalı — ama jeton çalınırsa da sınırsız yaşamamalı. İki gereksinim birbirine ters çalışır ve dengeyi işin niteliği belirler: bir bankacılık uygulamasıyla bir yemek siparişi uygulamasının oturum ömrü aynı olamaz. Mobil uygulama geliştirme projelerinde bu ayarı iş sahibiyle konuşarak belirliyoruz, varsayılan bırakmıyoruz.

İnternet kesildiğinde uygulama ne yapıyor?

Depo, bodrum kat, tünel, kırsal saha, uçak. Bağlantının olmadığı yerlerde uygulamanın davranışı ürünün kalitesini doğrudan belirler. En kötü senaryo, kullanıcının doldurduğu formu gönderirken hata alması ve verinin buharlaşması. İkinci kötü senaryo, verinin gönderildiğini sanması.

Çözüm katmanlı kurulur. Yerel bir veri tabanı — SQLite, Realm ya da Drift — uygulamanın kendi gerçeğini tutar. Yazma işlemleri bir kuyruğa alınır, bağlantı geldiğinde sırayla akar. Kuyruk kalıcıdır, yani kullanıcı uygulamayı kapatsa da içeriği durur. Buraya kadar herkes hemfikir. Zor kısım çakışma çözümlemesi: aynı kaydı iki kişi farklı yerlerde değiştirdiyse hangisi kazanır? Basit senaryolarda son yazan kazanır kuralı yeter. Stok, randevu ya da fiyat gibi alanlarda ise alan bazlı birleştirme ve sunucu tarafında karar mercii şart. Bu kararı iş sahibiyle birlikte veririz, çünkü teknik değil operasyonel bir tercihtir.

Çevrimdışı çalışan uygulamalarda test yükü de artar. Uçak modunda, zayıf sinyalde, bağlantı ortasında kopan istekle senaryolar tek tek yürütülür. Mobil uygulama geliştirme sürecinde bu testlerin atlanması, yayından sonra en çok geri dönüş üreten eksiktir. Alanya yazılım tarafında otel ve marina sahalarında yaşadığımız kapsama sorunları, bu testlerin neden gerçek ortamda tekrarlanması gerektiğini defalarca gösterdi.

Bildirim ve derin bağlantı: küçük görünen, uzun süren işler

Anlık bildirim teklif aşamasında tek satırlık bir kalemdir. Uygulamada ise en çok ayrıntı barındıran başlıklardan biri. Firebase Cloud Messaging ve APNs üzerinden ilerlenir; jetonların yaşam döngüsü, kullanıcı çıkış yaptığında jetonun temizlenmesi, aynı hesabın birden çok cihazda açık olması, sessiz bildirimle veri çekme, izin isteme anının doğru seçilmesi. Kullanıcıya uygulamayı açar açmaz bildirim izni sormak reddedilme oranını yükseltir; izni değer gösterdikten sonra istemek ise kabul oranını belirgin biçimde artırır.

Derin bağlantı tarafı daha teknik. E-postadaki ya da mesajdaki bir bağlantıya tıklayan kullanıcının doğrudan ilgili ürün ekranında açılması için iOS tarafında evrensel bağlantı, Android tarafında uygulama bağlantısı doğrulaması kurulur; alan adının kökünde doğrulama dosyası yayınlanır. Uygulama kurulu değilse ne olacağı da ayrı bir karardır: mağazaya mı gidilir, web sürümüne mi düşülür, kurulum sonrası bağlantı hatırlanır mı? Antalya yazılım ekiplerinin pazarlama tarafıyla ortak çalıştığı yer tam olarak burasıdır, çünkü kampanya bağlantısının nereye düştüğü dönüşüm oranını doğrudan etkiler.

Bildirim içeriğinin kendisi de teknik olduğu kadar operasyonel bir konu. Kime, ne zaman, hangi sıklıkta gönderileceği kararlaştırılmazsa sonuç bellidir: kullanıcı bildirimleri kapatır ve kanal tümden kaybedilir. Kapatılan bildirim geri açılmaz, bunu baştan kabul etmek gerekir. Segmentasyon, sessiz saat tanımı ve tercih ekranı bu yüzden ilk sürüme konur. Sipariş durumu gibi işlemsel bildirimlerle pazarlama bildirimlerinin ayrı kanallarda tutulması da işe yarar — kullanıcı kampanyaları kapatırken kargo bildirimini kaybetmez. Mobil uygulama geliştirme sürecinde bu ayrımı yapmayan uygulamalar, üç ay sonra bildirim izni oranının neden düştüğünü sorguluyor.

İmzalama, çökme raporu, sürüm yönetimi

Mağaza tarafında geri dönüşü olmayan tek kalem imzalama anahtarlarıdır. Android imzalama anahtarını kaybeden bir ekip, aynı paket adıyla güncelleme yayınlayamaz. Bu yüzden anahtarlar ve sertifikalar ilk günden şifreli kasada tutulur, en az iki kişide erişim bulunur ve yedeği ayrı bir ortamda durur. Apple tarafında sertifika ve profil süreleri takvime bağlanır. Süresi dolmuş bir sertifika yüzünden yayın gecikmesi yaşamak, önlenebilir bir kayıptır.

Çökme raporlaması yayından önce kurulur, sonra değil. Crashlytics ya da Sentry, sembol dosyalarıyla birlikte yapılandırılmadığında raporlar okunamaz hâle gelir; ekranda anlamsız bellek adresleri görürsünüz. Doğru kurulduğunda ise şunu söyleyebilirsiniz: bu çökme yalnızca belirli bir Android sürümünde, belirli bir üreticinin cihazlarında, kamera izni reddedildiğinde oluşuyor. Bu cümleyi kurabilmek düzeltme süresini günlerden saatlere indirir.

Kullanım analitiği de aynı kurulumun parçası. Hangi ekranda kaç kullanıcı düşüyor, kayıt akışının hangi adımında vazgeçiliyor, arama kutusuna ne yazılıyor? Bu veriler olmadan ürün kararları tahmine dayanır. Toplanan verinin kişisel veri niteliği taşıyıp taşımadığı da baştan değerlendirilir; izin akışı, saklama süresi ve silme talebi karşılama yolu uygulamanın içine yerleştirilir. Mağazalar da veri toplama beyanını her sürümde soruyor — beyan ile gerçek davranış arasında fark çıkarsa yayın reddedilir.

Sürüm yayını kademeli yapılır. Google Play tarafında yüzdelik dağıtım, Apple tarafında aşamalı yayın kullanılır; ilk dilimde çökme oranı yükselirse yayın durdurulur. Zorunlu güncelleme mekanizması da uygulamanın içine baştan konur — sunucu bir asgari sürüm bildirir, altındaki sürümler kullanıcıyı güncellemeye yönlendirir. İstanbul yazılım ekipleriyle yürüttüğümüz projelerde bu mekanizmayı standart kabul ediyoruz. Mobil uygulama geliştirme işinin yayından sonra başladığını söylemek abartı değil.

Mağaza takvimi ve işletim sistemi ritmi

Yayın planı yaparken tek başınıza değilsiniz. App Store ve Google Play inceleme süreçleri araya girer. Aynı gün sonuçlanan başvurular da olur, birkaç güne yayılanlar da; ilk yayın genellikle güncellemelerden daha uzun sürer, çünkü uygulama ilk kez bütün olarak incelenir. Reddedilme ihtimalini de takvime yazmak gerekir. Red gerekçelerinin büyük kısmı teknik değil politika kaynaklıdır: eksik gizlilik açıklaması, hesap silme yolunun bulunmaması, izin metninin yetersizliği, test hesabı verilmemesi. Bu kalemleri baştan hazırlarsanız süreç kısalır. İnceleme ekibine test hesabı, örnek veri ve gerekiyorsa kısa bir kullanım videosu bırakmak da işi hızlandırıyor; giriş yapamayan bir inceleyici uygulamayı değerlendiremez ve dosya doğrudan geri döner. Lansman tarihini mağaza onayına değil, onay sonrasına planlamak da basit ama sık atlanan bir tedbir.

İşletim sistemlerinin yıllık bir ritmi var. Apple yaz başında geliştirici konferansında yeni sürümü tanıtır, sonbaharda yayına alır; Android tarafı da benzer bir yıllık takvimle ilerler. Her yeni sürüm beraberinde yeni izin kuralları, arka plan kısıtları ve arayüz değişiklikleri getirir. Bunun anlamı şu: uygulamanız yılda en az bir kez, siz hiçbir yeni özellik istemeseniz bile bakım görmek zorunda. Yaz aylarında beta sürümlerle test yapmak, sonbaharda panikle düzeltme yayınlamaktan ucuzdur.

Geriye dönük uyumluluk penceresi ayrı bir tercih. Çok eski sürümleri desteklemek, geliştirme süresini uzatır ve modern çerçevelerden yararlanmayı engeller; fazla dar tutmak ise kullanıcı kaybettirir. Uygulamanızın gerçek kullanıcı dağılımına bakarak karar veririz, tahminle değil. Alanya yazılım ofisimizde bu veriyi mağaza konsollarından çıkarıp müşteriyle birlikte okuyoruz. Bir kurumsal yazılım şirketi için desteklenen sürüm aralığı sözleşmeye yazılan bir taahhüttür, sonradan değişen bir detay değil.

Fiyatı ne belirliyor?

Kimse tek bir rakamla cevap veremez, veren de yanılıyordur. Fiyatı belirleyen ilk kalem ekran sayısıdır — ama basit bir sayım değil bu. Kayıt ekranıyla harita üzerinde filtrelenen bir liste ekranı aynı hanede yer almaz. Kaç ekran değil, kaç farklı davranış sorusu daha doğrudur.

İkinci kalem entegrasyonlar. Ödeme altyapısı, harita, kimlik doğrulama, kurumsal kaynak planlama sistemine bağlanma, muhasebe entegrasyonu. Her biri hem geliştirme hem test hem de karşı taraftaki sistemin hazır olmasını bekleme süresi getirir. Karşı sistem eskiyse ve belgesi yoksa süre uzar. Üçüncü kalem çevrimdışı gereksinimi: kuyruk, yerel veri tabanı, çakışma çözümü ve bunların testi ciddi bir mühendislik yükü demektir, uygulamanın yüzde onu gibi görünse de eforun çok daha fazlasını alır.

Dördüncüsü platform sayısı. Tek platformla başlamak mobil uygulama geliştirme maliyetini belirgin şekilde düşürür ve ürünü erken sahaya çıkarır; kullanıcı tabanınız ağırlıklı olarak tek tarafta toplanıyorsa mantıklı bir başlangıçtır. Beşincisi ve en sık atlananı, yayın sonrası bakım. Mağaza politikaları değişir, işletim sistemi güncellenir, kütüphaneler yaşlanır, sertifikalar biter. Bunları hesaba katmadan yapılan bütçe, ikinci yılda sürprizle karşılaşır. Antalya yazılım tekliflerimizde bakım kalemini ayrı satır olarak yazmamızın sebebi bu. Mobil uygulama geliştirme yatırımını sadece teslim gününe göre ölçen bir hesap, gerçek maliyetin yarısını görür.

Son bir not: kaynak kodun ve mağaza hesaplarının kime ait olduğu da fiyatın gizli bileşenidir. Kod sizde değilse, ekip değiştirme maliyeti sıfırdan yazmakla eşitlenir. İstanbul yazılım pazarında en sık duyduğumuz şikâyet bu — devralınamayan projeler.

Sıkça sorulan sorular

Tek kod tabanıyla hem iOS hem Android'i karşılamak her projede mantıklı mı?
Hayır. Uygulama ağırlıklı olarak veri gösteriyor, form dolduruyor, sipariş alıyor ve bildirim gönderiyorsa Flutter veya React Native ile tek gövde kurmak hem süreyi hem bakımı azaltır. Sürekli arka plan işleri, yoğun animasyon, derin donanım erişimi ya da işletim sistemine yeni gelen çerçeveleri ilk günden kullanma ihtiyacı varsa Kotlin ve Swift ile ayrı yazmak daha az sorun çıkarır. Kararı keşif aşamasında, gerçek gereksinim listesine bakarak veriyoruz.
Uygulamanın arka ucunu web sitemizle aynı yerden besleyebilir miyiz?
Evet, tercih ettiğimiz kurulum da bu. Aynı REST ya da GraphQL servisleri hem mobil uygulamayı hem web panelini besler; iş kuralları, yetkilendirme ve raporlama tek yerde toplanır. Böylece bir kampanya kuralını değiştirdiğinizde iki ayrı kod tabanında düzeltme yapmanız gerekmez. Alanya yazılım ekibimiz projelerin çoğunu bu şekilde kurguluyor.
App Store ve Google Play yayın sürecini kim yürütüyor?
Süreci biz yürütüyoruz. Geliştirici hesabı kurulumu, sertifika ve profil yapılandırması, paketleme ve imzalama, mağaza ürün sayfası metinleri ve görselleri, beta dağıtım, inceleme başvurusu ve red gelirse gerekçeye yanıt üretme adımları dahil. Mağaza hesapları sizin adınıza açılır, sahiplik size aittir; biz yalnızca yetkili olarak çalışırız.
Çevrimdışıyken girilen veriler kaybolur mu?
Kalıcı bir kuyruk kurulduğunda kaybolmaz. Kullanıcının girdiği kayıt önce cihazdaki veri tabanına yazılır, bağlantı geldiğinde sunucuya iletilir ve iletildiği doğrulanınca kuyruktan düşer. Uygulama kapansa, telefon kapansa bile kuyruk yerinde durur. Kritik olan, aynı kaydın başka bir yerde değiştirilmesi hâlinde hangi sürümün geçerli sayılacağının önceden kararlaştırılmış olmasıdır.
İşletim sistemi yeni sürüm çıkardığında uygulama bozulur mu?
Çoğunlukla bozulmaz, ama davranış değişir. Yeni izin kuralları, arka plan çalışma kısıtları ve arayüz güncellemeleri her yıl geliyor. Yaz aylarında yayınlanan beta sürümlerde uygulamayı test edip sonbahara hazır girmek en sağlıklı yol. Mobil uygulama geliştirme anlaşmalarımızda yıllık işletim sistemi uyumluluk kontrolü bakım kapsamında yer alıyor.
Yayından sonra geliştirme duruyor mu?
Durmuyor. Çökme raporları gelir, kullanıcı yorumları birikir, mağaza politikaları değişir, bağımlılıklar yaşlanır. Sürüm planı genellikle küçük düzeltmeler ve dönemsel özellik paketleri şeklinde ilerler. Antalya yazılım ve İstanbul yazılım tarafındaki kurumsal müşterilerimizle bu ritmi baştan takvime bağlıyoruz, çünkü plansız güncelleme hem ekibi hem kullanıcıyı yoruyor. Bakımı da içeren bir kurumsal yazılım şirketi anlaşması, ilk teslimden çok daha uzun bir dönemi kapsar.