Offline Çalışan Uygulama: Offline-First Mimari Rehberi

Offline çalışan uygulama, internet bağlantısı olmadan da temel işlevlerini sürdüren uygulamadır. Google'ın resmî mimari rehberine göre bir uygulamanın offline-first sayılması için asgari şart, veri okumayı ağ olmadan yapabilmesidir; çevrimdışı yazma zorunlu değildir. Veri cihazda tutulur, bağlantı dönünce sunucuyla eşitlenir.

Bu tanım kulağa basit geliyor ama saha ekibi olan şirketlerin çoğu yanlış yerden başlıyor. "Bağlantı yoksa uyarı gösterelim" diye kurulan bir uygulama offline çalışan uygulama değildir; sadece daha kibar bir hata ekranıdır.

Depoda raf aralarına girildiğinde, şantiyenin bodrum katında, tarlada ya da tünelde sinyal düşer. O anda teknisyenin yaptığı iş kaybolursa sorun bağlantı değil, mimaridir. Bu rehber, offline çalışan uygulama kurarken verilmesi gereken kararları sırayla anlatıyor: veriyi nerede tutacaksınız, yazma işlemini nasıl kuyruklayacaksınız, iki cihaz aynı kaydı değiştirince kim kazanacak ve bunların tamamı bütçeye ne ekliyor.

Buradaki teknik sınırların tamamı Google, Apple ve Firebase'in kendi dokümanlarından alındı. Pazarlama metinlerinden değil.

İçindekiler

• Offline Çalışan Uygulama Nedir, Ne Değildir?
• Hangi Ekipler Buna Gerçekten Muhtaç?
• Yerel Veritabanı: Tek Doğru Kaynak
• Yazma Stratejileri: Online, Kuyruklu ve Tembel
• Senkronizasyon: Pull, Push ve Hibrit Yaklaşımlar
• Çakışma Çözümü: Son Yazan Kazanır Yeterli mi?
• Arka Plan Senkronizasyonu: Android ve iOS Aynı Değil
• Hazır Servis mi, Kendi Senkron Katmanınız mı?
• Offline Çalışan Uygulama Maliyetini Ne Belirler?
• Çevrimdışı Arayüz ve Test Kuralları
• Sıkça Sorulan Sorular

Offline Çalışan Uygulama Nedir, Ne Değildir?

Google'ın offline-first mimari rehberi tanımı net: uygulamanın çekirdek işlevlerinin tamamını veya kritik bir alt kümesini internet olmadan yürütebilmesi. Aynı doküman üç tipik senaryoyu sayıyor: sınırlı bant genişliği, asansör veya tünelde yaşanan geçici kesintiler ve yalnızca Wi-Fi ile çalışan tabletlerde olduğu gibi aralıklı erişim.

Buradaki ayrım önemli. Offline çalışan uygulama, sinyalin hiç olmadığı yerler için değil, sinyalin güvenilmez olduğu yerler için kurulur. Türkiye'de de dünyada da kapsama alanı dışında kalan nüfus küçük bir azınlık; sorun kapsamanın yokluğu değil, sürekliliğin olmaması.

Google'ın rehberi asgari şartı da yazıyor: offline-first bir uygulama en azından ağ erişimi olmadan okuma yapabilmelidir. Çevrimdışı yazma yeteneği offline-first olmanın koşulu değil, ayrı bir tercih. Bu cümle bütçe konuşmalarını kolaylaştırır, çünkü "okuma offline" ile "okuma ve yazma offline" arasındaki iş yükü farkı ciddidir.

Offline çalışan uygulama olmayan şeyler de var: bağlantı yokken uyarı gösteren uygulama, son görüntülenen ekranı bellekte tutan uygulama ve istekleri yeniden deneyen ama kalıcı kuyruk tutmayan uygulama. Üçü de uygulama kapatılınca veriyi kaybeder.

Ayrımı netleştiren tek bir test var: uygulamayı uçak moduna alıp kapatın, yeniden açın ve dün girdiğiniz kayıtları arayın. Kayıtlar karşınıza geliyorsa yerel bir doğruluk kaynağınız var. Boş liste görüyorsanız elinizde yalnızca bir önbellek var ve o önbellek kullanıcıyı korumuyor.

Hangi Ekipler Buna Gerçekten Muhtaç?

Her uygulamaya offline yetenek eklemek gerekmez. Masa başında, ofis Wi-Fi'siyle çalışan bir onay ekranı için bu yatırım boşa gider. Karar için pratik bir ölçüt var: kullanıcı, bağlantının olmadığı bir yerde veri üretiyor mu?

Üretiyorsa offline çalışan uygulama zorunludur. Tipik profiller şunlar:

• Saha servisi ve teknik ekipler: kazan dairesi, bodrum, çatı, asansör kuyusu. İş emri kapatma ve fotoğraf yükleme bu noktalarda yapılır.
• Depo ve lojistik: metal raf aralarında sinyal zayıflar; sayım ve barkod okutma kesintiye gelmez.
• Şantiye: kaba inşaat aşamasında ne Wi-Fi ne de düzgün hücresel kapsama olur.
• Tarım, madencilik, enerji: yerleşim dışı alanlar, tesis içi beton hacimler.
• Dağıtım ve kurye: araç içi, bodrum teslimatı, kapalı otopark.
• Satış temsilcileri: müşteri ziyaretinde sipariş ve tahsilat girişi.

Türkiye tarafında somut bir veri noktası var. BTK'nın 2026 birinci çeyrek pazar verileri raporuna göre 5G dönemi 1 Nisan 2026'da başladı ve operatörler hizmeti ilk etapta tüm il merkezlerinde açtı. Yani 2026'da bile şehir merkezinin dışı 4.5G'ye bağlı; mart sonu itibarıyla 4.5G gerçek kullanıcı sayısı 83.355.728. Aynı rapor mobil abone başına aylık veri kullanımını 20,8 GB olarak veriyor, sabit bağlantıdaki 322,4 GB'ın yanında küçük bir rakam.

Sahadaki işin yapıldığı yer tam olarak il merkezinin dışıdır. Kapsama haritasında yeşil görünen bir ilçede bile beton bodrum, metal çatı veya yüksek raflı depo sinyali bitirir. Bu yüzden saha ekibi için kurulan yazılımların offline davranışı, özellik listesinin en sonunda değil en başında konuşulmalı. Saha satış programı ve stok takip programı rehberlerinde bu senaryoların iş akışı tarafını ayrıntılı ele aldık.

Yerel Veritabanı: Tek Doğru Kaynak

Offline çalışan uygulama mimarisinde en kritik karar burada veriliyor. Google'ın rehberi yerel veri kaynağını uygulamanın kanonik doğruluk kaynağı olarak tanımlıyor: üst katmanların okuduğu her veri buradan gelmeli. Ağ katmanıyla doğrudan konuşan bir ekran kodu, bağlantı durumuna göre farklı davranan bir arayüz üretir.

Pratikte kullanılan yerel depolama seçenekleri şöyle:

Hazır servis tarafında Firebase'in davranışı iyi dokümante edilmiş. Firestore çevrimdışı erişim dokümanına göre kalıcı önbellek Android ve Apple platformlarında varsayılan olarak açık, web'de kapalı. Varsayılan önbellek eşiği 100 MB; en az 1 MB'a indirilebiliyor veya temizleme tamamen kapatılabiliyor. Eşik aşılınca Firestore eski ve kullanılmayan dokümanları periyodik olarak siliyor.

Bu önbellekte gözden kaçan bir ayrıntı var: çevrimdışı sorgular başlangıçta yalnızca önbellekteki dokümanlar üzerinde çalışır ve SDK varsayılan olarak koleksiyondaki tüm dokümanları tarar. Firebase'in kendi uyarısı, kullanıcı uzun süre çevrimdışı kalırsa sorgu performansının düşeceğini söylüyor. Çözüm olarak yerel sorgu indekslerinin otomatik oluşturulması öneriliyor; bu özellik varsayılan olarak kapalı ve uygulamanın her açılışında yeniden etkinleştirilmesi gerekiyor.

İlk açılışta ne kadar veri indireceğiniz de burada kararlaştırılır. Teknisyenin yalnızca kendi bölgesindeki müşterilere ihtiyacı varsa tüm müşteri tablosunu cihaza kopyalamak hem ilk kurulumu uzatır hem de kota harcar. Pratik yol, veriyi kullanıcıya göre filtrelemek ve sonraki turlarda yalnızca değişen kayıtları çekmek. Bunun için her tabloya bir güncelleme zaman damgası ve silinen kayıtlar için bir işaret alanı eklemeniz gerekir; silmeleri takip etmeyen bir senkronizasyon, cihazda hayalet kayıtlar bırakır.

Yazma Stratejileri: Online, Kuyruklu ve Tembel

Okuma tarafı çözüldükten sonra iş yazmaya gelir ve offline çalışan uygulama projelerinin çoğu burada tıkanır. Google üç strateji tanımlıyor ve her veri tipi için ayrı seçim yapmanızı istiyor.

Saha senaryolarının neredeyse tamamı üçüncü sıradadır. Teknisyenin kapattığı iş emri yerel veritabanına yazılmazsa veri kaybı riski doğar; Google rehberi de kritik veri için tembel yazmayı doğru tercih olarak gösteriyor.

Burada mimari bir uyarı var: online-only stratejiyi seçtiyseniz kullanıcıya o ekranı hiç açmamak ya da en azından devre dışı bırakmak gerekir. Bağlantı yokken doldurulan ama kaydedilemeyen bir form, kullanıcı açısından veri kaybıyla aynı şeydir.

Senkronizasyon: Pull, Push ve Hibrit Yaklaşımlar

Bağlantı döndüğünde yerel veri ile sunucu verisinin uzlaştırılması gerekir. Google rehberi iki temel yaklaşım tanımlıyor.

Çekmeli (pull-based) senkronizasyon veriyi ihtiyaç anında çeker; en yaygın yöntemi ekran bazlı, yani kullanıcı o ekrana gitmeden hemen önce veri almak. Uygulaması kolaydır ve gereksiz veri hiç indirilmez. Buna karşılık aynı ekrana tekrar girildiğinde değişmemiş veriyi yeniden indirme eğilimi vardır ve ilişkisel veride iyi ölçeklenmez. Google bu yöntemin kısa ve orta süreli kesintiler için uygun olduğunu, uzun çevrimdışı dönemlerde kullanıcının boş ya da bayat önbellekle karşılaşma riskinin arttığını belirtiyor.

İtmeli (push-based) senkronizasyon yerel veritabanını sunucunun bir kopyası gibi tutar: ilk açılışta temel veri indirilir, sonrasında sunucu bildirimiyle yalnızca değişen kayıtlar güncellenir. Avantajı net; uygulama süresiz çevrimdışı kalabilir, veri kullanımı minimumdur ve ilişkisel veride iyi çalışır. Bedeli de net: çakışma çözümü için sürüm takibi gerekir ve sunucunun senkronizasyonu desteklemesi şarttır.

Çoğu kurumsal uygulama hibrit gider. Sık değişen listeler çekmeli, kullanıcıya ait sabit veriler ve referans tabloları itmeli senkronize edilir. Offline çalışan uygulama tasarımında bu seçim tek seferde değil, tablo tablo yapılır.

Çakışma Çözümü: Son Yazan Kazanır Yeterli mi?

İki teknisyen aynı kaydı çevrimdışı değiştirip ikisi de bağlanınca ne olacak? Google rehberi mobil uygulamalarda yaygın yaklaşımı "son yazan kazanır" olarak veriyor: cihazlar yazdıkları veriye zaman damgası ekler, sunucu kendi durumundan eski olanı atar, yeni olanı kabul eder. Bunun için cihazın değişiklik zamanını takip eden bir defter tutması, yani sürümleme gerekir.

Kurumsal ürünlerin bunu nasıl uyguladığı öğretici. Microsoft'un mobil senkronizasyon çakışmaları dokümanına göre çevrimdışı yapılan değişiklikler kolon bazında sunucuya gönderiliyor ve her kolonun son güncellemesi saklanıyor; bu sayede çakışan değişiklikler yüzünden senkronizasyon başarısız olmuyor. Aynı doküman çakışma algılama seçeneğinin açılmasını önermiyor, çünkü açıldığında sunucudaki güncellemeler istemci güncellemelerini engelleyebiliyor ve çakışmaların elle çözülmesi gerekiyor.

Satır yerine kolon seviyesinde birleştirme, pratikte veri kaybını büyük ölçüde azaltır. İki teknisyen aynı iş emrinin farklı alanlarını doldurduysa ikisinin de girdisi korunur. Aynı alanı doldurduklarında ise kaçınılmaz olarak biri kaybeder.

Bunun tasarım tarafında bir dersi var: çakışma olasılığı yüksek alanları tek bir "durum" alanında toplamak yerine ayırmak. Tek bir durum alanı varsa son senkronize olan güncelleme diğerini siler. Aynı bilgi ayrı alanlara bölündüğünde iki girdi bir arada yaşayabilir.

Daha ileri bir seviye de mevcut. Martin Kleppmann ve ekibinin local-first software makalesi yedi ilke tanımlıyor; bunlardan biri doğrudan "ağ isteğe bağlıdır" diyor. Makale çakışmasız çoğaltılmış veri tiplerini (CRDT) temel teknoloji olarak öneriyor. CRDT yaklaşımı eşzamanlı düzenlemeleri kayıpsız birleştirir ama veri modelini ve ekip bilgisini ciddi şekilde zorlar. Kurumsal saha uygulamalarının çoğu için kolon bazlı son-yazan-kazanır yeterli; metin üzerinde ortak düzenleme yapılan ürünler için değil.

Arka Plan Senkronizasyonu: Android ve iOS Aynı Değil

Bu bölüm offline çalışan uygulama projelerinde en çok sürpriz üreten yer. İki platformun arka plan bütçesi birbirine benzemiyor ve tek bir "arka planda senkronize et" vaadi her ikisinde aynı şeyi ifade etmiyor.

Android tarafında WorkManager dokümanı sayıları açıkça veriyor: geri çekilme gecikmesi 10 saniyenin altına inemez, varsayılan politika 30 saniyelik gecikmeyle exponential ve LINEAR seçilirse denemeler yaklaşık 10, 20, 30, 40 saniye aralıklarıyla ilerler. Periyodik iş için en kısa tekrar aralığı 15 dakika. Senkronizasyon işine NetworkType.CONNECTED kısıtı koyarsanız iş, ağ gelene kadar hiç çalışmaz; bu da kuyruk boşaltmanın doğru yoludur.

iOS tarafında Apple'ın arka plan strateji dokümanı daha sıkı bir tablo çiziyor. Sistem işi ne zaman başlatacağına kendisi karar veriyor ve içerik yenileme görevine 30 saniyeye kadar çalışma süresi veriyor; bu sürede işi bitirip setTaskCompleted(success:) çağırmazsanız sistem uygulamayı sonlandırıyor. Ağır işler için BGProcessingTask var ama onun da zamanlamasını sistem seçiyor, tipik olarak cihaz şarjdayken.

Pratik sonuç şu: iOS'ta 500 kayıtlık bir kuyruğu arka planda boşaltacağınızı varsaymayın. Kuyruk, uygulama ön plandayken boşaltılmak üzere tasarlanmalı; arka plan görevleri yalnızca fırsat penceresi olarak kullanılmalı. Microsoft'un saha servisi senkronizasyon dokümanı da aynı gerçeği kabul ediyor: senkronizasyon ancak uygulama etkinken ve cihaz bağlıyken başlıyor, başladıktan sonra arka planda tamamlanabiliyor.

Üretimde en sık gözden kaçan ayrıntı oturum süresidir. Erişim jetonu çevrimdışıyken dolarsa uygulama kullanıcıyı giriş ekranına atar; o anda kuyrukta bekleyen kayıtlar da erişilemez hâle gelir. Bu yüzden offline çalışan uygulama tasarımında oturum süresini sahadaki en uzun çevrimdışı döneme göre belirlemeli, jeton yenilemeyi bağlantı döndüğü anda sessizce yapmalı ve kuyruğu oturumdan bağımsız bir yerde tutmalısınız.

Hazır Servis mi, Kendi Senkron Katmanınız mı?

Google rehberi bu kararı iki başlıkta topluyor: özel senkronizasyon yığını veya yönetilen bulut servisi. Özel yığında Room veya dosya tabanlı yerel depolama kurar, kendi ağ istemcinizi yazar ve uzlaştırma işçilerini WorkManager ile zamanlarsınız; karşılığında şema ve çakışma algoritması üzerinde tam kontrol alırsınız. Yönetilen servis tarafında Firestore gibi bir çözüm disk önbelleğini, çevrimdışı yazma kuyruğunu ve iki yönlü senkronizasyonu kendi üstlenir.

Hazır servisin maliyeti hız değil, bağımlılıktır. 2026'da bunun en net örneği MongoDB'de yaşandı: Atlas Device SDK'ları Eylül 2024'te kullanımdan kaldırıldı ve resmî kullanımdan kaldırma sayfasına göre 30 Eylül 2025'te ömrünü tamamladı. Aynı sayfa, Sync kullanan uygulamaların bu tarihten önce alternatif bir çözüme geçmesi ya da Sync'i kaldırması gerektiğini yazıyor. Cihaz üzerindeki veritabanı açık kaynak proje olarak yaşamaya devam etti; senkronizasyon kodu çıkarılmış topluluk dalları yayınlandı. Yani yerel kısım kaldı, senkronizasyon kısmı gitti.

Bu, hazır servisten kaçınmak için bir sebep değil. Fakat senkronizasyon katmanını değiştirmenin maliyeti, onu ilk kurma maliyetinden yüksektir. Seçim yaparken şu üç soruyu sormak işe yarar: veri modelim satıcıya özel bir yapıya mı kilitleniyor, çakışma kuralını kendim tanımlayabiliyor muyum, servis kapanırsa yerel veriyi dışa alabiliyor muyum. Firebase nedir yazısında hazır backend ile özel backend arasındaki bu dengeyi ayrıntılı karşılaştırdık.

Offline Çalışan Uygulama Maliyetini Ne Belirler?

Offline yetenek, bir uygulamanın üzerine sonradan eklenen bir anahtar değil. Mimariyi baştan etkilediği için proje bütçesine de tek bir kalem olarak değil, dağılmış biçimde yansır. Bütçe konuşmasında ayrıca ele alınması gereken başlıklar şunlar:

• Veri modelinin ikiye çıkması: yerel varlık ve ağ modeli ayrı tanımlanır, aralarına dönüştürücüler yazılır. Google rehberi bu iki modeli veri katmanına kapatıp üst katmanlara üçüncü bir tip sunmayı öneriyor.
• Kuyruk ve yeniden deneme altyapısı: kalıcı kuyruk, sıralı boşaltma, artan gecikmeli yeniden deneme ve başarısız kayıtların raporlanması.
• Çakışma kuralları: hangi alanda hangi taraf kazanır sorusunun tablo tablo cevaplanması ve sunucu tarafında sürümleme.
• Senkronizasyon hata yönetimi: Microsoft'un yaklaşımında başarısız her değişiklik ayrı bir hata kaydına yazılıyor ve yeniden denenebiliyor. Benzer bir hata kuyruğu olmadan sessiz veri kaybını fark etmezsiniz.
• Arayüz durumları: senkronize edildi, beklemede, hata aldı durumlarının her ekranda gösterilmesi.
• Test yükü: uçak modu, zayıf bağlantı, yarıda kesilen senkronizasyon ve uzun çevrimdışı dönem senaryolarının tekrar tekrar koşturulması.

Bu kalemlerin ortak özelliği şu: hiçbiri ekrana yeni bir buton eklemiyor. Demo sırasında görünmedikleri için teklif karşılaştırmasında da kolayca gözden kaçıyorlar. Offline yetenek isteyen bir projede iki teklif arasındaki fiyat farkı, çoğu zaman bu kalemlerin birinde ya var ya yok olmasından geliyor.

Kapsam kararını iki aşamalı vermek bütçeyi gerçekçi tutar. Birinci sürümde yalnızca okuma offline olsun, kritik iki ekranda tembel yazma bulunsun; ikinci sürümde kuyruk genişletilsin. Google'ın asgari tanımı tam olarak buna izin veriyor.

Kendi senaryonuz için büyüklük sırası görmek isterseniz mobil uygulama maliyet hesaplayıcı aracıyla özellik kapsamını işaretleyip bir aralık çıkarabilirsiniz. Platform tercihinin de maliyete etkisi var; React Native, Flutter ve native karşılaştırması bu tarafı ayrıntılı anlatıyor.

Çevrimdışı Arayüz ve Test Kuralları

Offline çalışan uygulama teknik olarak doğru kurulsa bile kullanıcı neyin kaydedildiğini görmüyorsa güven oluşmaz. Kurumsal ürünlerin ortaklaştığı birkaç arayüz kuralı var.

Senkronizasyon durumu kalıcı olarak görünür olmalı. Microsoft'un saha servisi uygulamasında senkronizasyon simgesi ana gezinmede her zaman duruyor ve bağlı mı, senkronizasyon sürüyor mu, hata var mı bilgisini tek bakışta veriyor. Ayrıca son senkronizasyon tarih ve saatini gösteren ayrı bir durum ekranı bulunuyor.

Kayıt bazında bekleme göstergesi de gerekir. Firestore bunu anlık görüntü meta verisiyle sağlıyor: fromCache değeri doğruysa veri önbellekten geliyor ve bayat ya da eksik olabilir. Yalnızca meta veri değiştiğinde olay üretilmediği için bu bilgiye güveniyorsanız dinleyiciye includeMetadataChanges seçeneğini vermeniz gerekiyor.

Kullanıcıya kontrol vermek de işe yarıyor. Microsoft yalnızca Wi-Fi'de senkronizasyon, isteğe bağlı senkronizasyon ve senkronizasyon sıklığını değiştirme ayarlarını yöneticiye açıyor; tabloya göre senkronizasyon aralığı 5 dakika ile 1 gün arasında ayarlanabiliyor. Ölçülü veri paketiyle çalışan sahada bu ayarlar fatura farkı yaratır.

Cihazdaki veriyi korumak da bu bölümün parçası. Offline çalışan uygulama, müşteri bilgisini ve iş emri geçmişini saatlerce cihazda tutar; telefon kaybolduğunda bu veri sizinle birlikte gitmez. Bu yüzden yerel veritabanını cihaz şifrelemesine güvenerek bırakmak yerine uygulama düzeyinde şifrelemeli, jetonları Keychain veya Keystore'da saklamalı ve uzaktan silme için bir yol bırakmalısınız. KVKK kapsamında kişisel veri işleyen bir saha uygulamasında bu önlemler teknik tedbir sayılır, isteğe bağlı iyileştirme değil.

Test tarafında uçak modu tek başına yetmez. Gerçek hatalar yarım kalan senkronizasyonlarda çıkar: kuyruk boşalırken bağlantı kopması, aynı kaydın iki cihazda değişmesi, uygulamanın kuyruk doluyken güncellenmesi. Yayın öncesinde App Store kuralı da hatırlanmalı; App Store İnceleme Kılavuzu 4.2.3 maddesi, ilk açılışta çalışabilmek için ek kaynak indirmesi gereken uygulamaların indirme boyutunu açıklamasını ve kullanıcıdan onay almasını istiyor. Büyük referans veri setini ilk açılışta indiren bir offline çalışan uygulama bu maddeye girer.

Web tarafında aynı güvenceyi beklemek de hata olur. MDN'nin depolama kotaları ve silme ölçütleri dokümanına göre Safari, siteler arası izleme koruması açıkken son yedi günde dokunulmamış bir origin'in betikle oluşturduğu verisini siliyor. Haftada bir kullanılan bir saha aracı için bu, veriyi bulamama demektir. Kalıcı çevrimdışı veri gereken senaryolarda native uygulama tercih edilmesinin somut sebeplerinden biri bu.

Sıkça Sorulan Sorular

Offline çalışan uygulama ile internetsiz uygulama aynı şey mi?

Hayır. İnternetsiz uygulama hiç sunucuya ihtiyaç duymaz, örneğin bir hesap makinesi veya tek kullanıcılı not uygulaması. Offline çalışan uygulama ise sunucuyla veri paylaşır ama bağlantı olmadığı sürelerde de çalışmaya devam eder ve bağlantı dönünce eşitlenir.

Çevrimdışı yazma yapmayan uygulama offline-first sayılır mı?

Sayılır. Google'ın mimari rehberine göre offline-first olmanın asgari koşulu ağ erişimi olmadan okuma yapabilmektir; çevrimdışı yazma ayrı bir tercihtir. Bu ayrım, projeyi iki aşamaya bölerek bütçeyi kontrol altında tutmanıza imkân verir.

Cihazda ne kadar veri tutulabilir?

Yerel veritabanı için pratik sınır cihaz depolamasıdır. Hazır servislerde varsayılanlar daha düşük: Firestore kalıcı önbelleğinin varsayılan eşiği 100 MB olup en az 1 MB'a indirilebilir veya temizleme kapatılabilir. Tarayıcı tabanlı çözümlerde ise kota tarayıcıya göre değişir ve veri silinebilir.

Aynı kaydı iki kişi çevrimdışı değiştirirse ne olur?

Çakışma kuralınıza bağlı. Yaygın yaklaşım son yazan kazanır; zaman damgası daha yeni olan kayıt kabul edilir, eski olan sessizce atılır. Bu yüzden zaman damgasını sunucu saatine göre normalize etmek gerekir; cihaz saatine güvenen bir kural, saati yanlış ayarlanmış tek bir telefon yüzünden doğru kaydı siler. Microsoft'un mobil senkronizasyonunda birleştirme kolon bazında yapıldığı için farklı alanları değiştiren iki kullanıcının girdisi birlikte korunur, aynı alanı değiştirdiklerinde biri kaybeder.

Senkronizasyon arka planda kendi kendine çalışır mı?

Kısmen. Android'de WorkManager ağ kısıtıyla bekleyip bağlantı gelince çalışabilir, periyodik iş için en kısa aralık 15 dakikadır. iOS'ta ise zamanlamaya sistem karar verir ve içerik yenileme görevine 30 saniyeye kadar süre verilir. Bu yüzden büyük kuyruklar uygulama ön plandayken boşaltılacak biçimde tasarlanır.

Bu yetenek projeye ne kadar ek süre getirir?

Tek bir çarpan vermek yanıltıcı olur; belirleyici olan kaç tablonun çevrimdışı yazmaya açılacağı ve çakışma kurallarının karmaşıklığı. Okuma tarafının çevrimdışına açılması genelde en hızlı adımdır. Veri modelinin ikiye çıkması, kalıcı kuyruk, hata kuyruğu, arayüz durumları ve genişleyen test matrisi ayrı kalemler olarak planlanmalıdır.

Hazır senkronizasyon servisi kullanmak riskli mi?

Hız kazandırır, bağımlılık yaratır. MongoDB Atlas Device Sync 30 Eylül 2025'te kapandı ve onu kullanan uygulamalar alternatif çözüme geçmek zorunda kaldı. Servis seçerken veri modelinin dışa alınabilir olması ve çakışma kuralını kendinizin tanımlayabilmesi en önemli iki ölçüt.

Offline çalışan uygulama kararı teknik bir detay gibi görünür ama sonuçları doğrudan operasyonda ortaya çıkar: sahada kaybolmayan iş emri, deponun raf arasında kesilmeyen sayımı, şantiyede akşam ofise dönmeden kapanan görev. Bu davranış sonradan eklenmediği, baştan mimariye yazıldığı sürece maliyeti de öngörülebilir kalır.

Doğru başlangıç noktası tüm veriyi çevrimdışına açmak değil; hangi ekranın hangi koşulda veri ürettiğini listelemek ve kritik olanları tembel yazmaya almaktır. Kendi saha senaryonuzu konuşmak isterseniz mobil uygulama geliştirme hizmet sayfamıza bakabilir, kapsam ve süre için iletişim formundan bize yazabilirsiniz.