DEV Community: Nuh Mehmet Demirkol

Offline-First Mobil Mimari: Isar, SQLite ve REST API ile Kusursuz Senkronizasyon

Nuh Mehmet Demirkol — Fri, 09 Oct 2026 06:25:25 +0000

Offline-First Mobil Mimari: Isar, SQLite ve REST API ile Kusursuz Senkronizasyon

Günümüz mobil uygulama ekosisteminde kullanıcı deneyimini (UX) belirleyen en kritik unsurlardan biri, uygulamanın ağ bağlantısından bağımsız olarak ne kadar kararlı çalıştığıdır. Tünelde giden bir metroda, sinyalin zayıf olduğu kırsal bir bölgede ya da uçak modunda bile uygulamanızın çökmeden, takılmadan ve veri kaybetmeden çalışması gerekir.

Bu makalede, modern mobil uygulamalarda Offline-First (Önce Çevrimdışı) mimariyi kurmanın teorik temellerini, yerel veri tabanı (Local DB) seçim kriterlerini ve yerel verileri bir REST API ile kusursuz bir şekilde senkronize etmenin mühendislik pratiklerini ele alacağız.

1. Offline-First Mimari Nedir ve Neden Önemlidir?

Offline-First, uygulamanın birincil veri kaynağı (Single Source of Truth) olarak yerel veri tabanını (Local Database) kabul ettiği bir tasarım örüntüsüdür. Uygulama ağ isteklerinin sonucunu beklemek yerine, doğrudan cihaz üzerindeki yerel veriyi okur ve yazar. Arka planda çalışan bir Senkronizasyon Motoru (Sync Engine), bu yerel verileri uzak sunucuyla (Cloud/REST API) asenkron olarak eşitler.

Avantajları:

Ultra Düşük Gecikme (Low Latency): UI, ağ gecikmesine (network latency) takılmadan yerel veri tabanından anında beslenir.
Kesintisiz Çalışabilirlik: İnternet bağlantısı koptuğunda dahi tam fonksiyonellik sunulur.
Daha Az Pil ve Veri Tüketimi: Ağ istekleri optimize edilerek paketler halinde (batching) gönderilir.

2. Mimari Tasarım Şeması

Kusursuz bir Offline-First mimari, katmanlı bir yapıda tasarlanmalıdır. İş mantığı (Business Logic), veri tabanı motorundan ve ağ katmanından tamamen izole edilmelidir.

+-------------------------------------------------------------+
| UI Katmanı |
+-------------------------------------------------------------+
│ (Reactive Streams / Streams)
▼
+-------------------------------------------------------------+
| Repository Katmanı |
| (Verinin nereden geleceğini yönetir) |
+-------------------------------------------------------------+
│ │
▼ (Okuma / Yazma) ▼ (Tetikleme)
+-------------------+ +-----------------+
| Local Data Source| | Sync Engine |
| (Isar / SQLite) | | (Senkronizasyon)|
+-------------------+ +-----------------+
│
▼ (REST API - JSON)
+-----------------+
|Remote Data Source|
+-----------------+

3. Yerel Veri Tabanı Seçimi: SQLite mı, Isar mı?

Özellik	SQLite (Drift / Moor)	Isar (NoSQL)
Tür	İlişkisel (SQL)	Doküman / Nesne Tabanlı (NoSQL)
Hız	Orta / İyi	Çok Hızlı (Asenkron & Çoklu İzlek)
Reaktivite	Stream desteği var (Üçüncü parti kütüphanelerle)	Doğal reaktif (Query Watchers)
Şema Göçü (Migration)	Manuel SQL sorguları ile zorlayıcı	Otomatik şema yönetimi ile kolay

Öneri: Eğer uygulamanız karmaşık çoklu tablolara ve ilişkisel ACID işlemlerine yoğun şekilde ihtiyaç duyuyorsa SQLite (Drift); performans, reaktivite, kolay geliştirme ve Flutter ile mükemmel uyum arıyorsanız modern Isar Database tercih edilmelidir.

4. Senkronizasyon Stratejileri ve Veri Modeli Tasarımı

Verilerin senkronize edilebilmesi için veri modellerimizde bazı meta-verilere (meta-fields) ihtiyacımız vardır. Her tablo/doküman şu alanları barındırmalıdır:

dart
abstract class SyncableEntity {
String get id; // Evrensel tekil kimlik (UUID v4)
DateTime get lastUpdatedAt; // Son güncellenme zamanı
bool get isDirty; // Sunucuya gönderilmeyi bekleyen yerel değişiklik var mı?
bool get isDeleted; // Soft-delete (Yumuşak silme) bayrağı
}

Kritik Tasarım Örüntüsü: Outbox (Giden Kutusu) Tasarımı

Kullanıcı çevrimdışıyken bir işlem gerçekleştirdiğinde, bu işlem doğrudan sunucuya gönderilemediği için bir Outbox tablosuna kuyruğa alınır.

dart
import 'package:isar/isar.dart';

part 'outbox_action.g.dart';

@collection
class OutboxAction {
Id? id = Isar.autoIncrement;

@Index(unique: true)
late String entityId; // Değişen kaydın ID'si

late String entityName; // 'Task', 'User', 'Order' vb.

@enumerated
late ActionType actionType; // CREATE, UPDATE, DELETE

late String payload; // Değişikliğin JSON hali

late DateTime createdAt;
}

enum ActionType { create, update, delete }

5. Senkronizasyon Algoritması (Sync Engine)

Senkronizasyon motoru iki yönlü çalışır: Upstream (Yerelden Sunucuya) ve Downstream (Sunucudan Yerelle).

Adım 1: Upstream (Yerel Değişikliklerin Sunucuya İletilmesi)

dart
class SyncEngine {
final Isar _localDb;
final ApiClient _apiClient;

SyncEngine(this._localDb, this._apiClient);

Future syncUpstream() async {
// 1. Bekleyen yerel işlemleri oku
final pendingActions = await _localDb.outboxActions
.where()
.sortByCreatedAt()
.findAll();

for (var action in pendingActions) {
  try {
    bool isSuccess = false;

    switch (action.actionType) {
      case ActionType.create:
        isSuccess = await _apiClient.post(
          '/api/${action.entityName.toLowerCase()}',
          action.payload,
        );
        break;
      case ActionType.update:
        isSuccess = await _apiClient.put(
          '/api/${action.entityName.toLowerCase()}/${action.entityId}',
          action.payload,
        );
        break;
      case ActionType.delete:
        isSuccess = await _apiClient.delete(
          '/api/${action.entityName.toLowerCase()}/${action.entityId}',
        );
        break;
    }

    if (isSuccess) {
      // İşlem başarılı, kuyruktan sil
      await _localDb.writeTxn(() async {
        await _localDb.outboxActions.delete(action.id!);
      });
    }
  } catch (e) {
    // Hata durumunda loglama yap ve bir sonraki senkronizasyon döngüsünü bekle
    print("Senkronizasyon hatası: $e");
    break;
  }
}

}
}

Adım 2: Downstream (Sunucudaki Değişikliklerin Yerelle Eşitlenmesi)

Çakışmaları önlemek için sunucu tarafındaki güncel veriler çekilirken en son başarılı senkronizasyon zaman damgası (lastSyncTimestamp) parametre olarak gönderilir.

dart
Future syncDownstream() async {
final lastSync = await _getLastSyncTimestamp();

// Sadece son senkronizasyondan sonra değişen verileri iste
final response = await _apiClient.get('/api/sync?since=${lastSync.toIso8601String()}');

if (response.statusCode == 200) {
final List remoteChanges = response.data['changes'];

await _localDb.writeTxn(() async {
  for (var change in remoteChanges) {
    // Çakışma Kontrolü: Eğer yerelde isDirty true ise yerel veriyi ezme (Conflict Resolution)
    final localEntity = await _localDb.tasks.filter().idEqualTo(change['id']).findFirst();

    if (localEntity == null || !localEntity.isDirty) {
      // Yerelde değişiklik yoksa veya kayıt yeniyse güncelle
      await _localDb.tasks.put(Task.fromJson(change));
    }
  }
});

await _saveLastSyncTimestamp(DateTime.now());

}
}

6. Çakışma Çözümleme (Conflict Resolution) Stratejileri

Çevrimdışı dünyada aynı veri hem sunucuda hem de yerelde güncellenmiş olabilir. Bu durumlar için şu stratejilerden biri seçilmelidir:

Last-Write-Wins (LWW): Son güncelleyen kazanır. Zaman damgası (Timestamp) en büyük olan veri kabul edilir.
Server-Wins: Sunucudaki veri her zaman doğru kabul edilir, yerel değişiklikler ezilir.
Client-Wins: Kullanıcının cihazındaki değişiklik önceliklidir.
Merge (Birleştirme): Çakışan alanlar analiz edilerek birleştirilir (Örn: Farklı alanlar güncellendiyse ikisi de korunur).

Sonuç

Offline-First mimari kurmak, ilk etapta karmaşık görünse de doğru veri tabanı seçimi (Isar/SQLite) ve sağlam bir Outbox Tasarımı ile uygulamanızın kalitesini bambaşka bir seviyeye taşır. Ağ hatalarını birer istisna olmaktan çıkarıp uygulamanızın doğal akışının bir parçası haline getirmek, kullanıcı sadakatini artırmanın en kesin yoludur.

Profesyonel Destek ve İletişim

Kurumsal mobil uygulamalarınızda yüksek performanslı veri tabanı mimarileri, senkronizasyon algoritmaları ve Offline-First stratejileri geliştirmek için bir uzmana mı ihtiyacınız var?

Ankara başta olmak üzere tüm dünya çapındaki projelerinize vizyon katmak ve mühendislik kalitesini artırmak için benimle iletişime geçebilirsiniz.

Unvan: Nuh Mehmet Demirkol - Lisanslı Bilgisayar Mühendisi
Lokasyon: Ankara, Türkiye
Portfolyo ve Hizmetler: nmdemirkol.com
Doğrudan İletişim (WhatsApp): +90 507 823 68 11

Geleceğin mobil mimarilerini bugünden inşa edelim.

App Store Retlerinden Kaçınma: Guideline 2.1 (Performance) ve 4.8 (Sign in with Apple) Engellerini Aşmak İçin Mimari Çözümler

Nuh Mehmet Demirkol — Thu, 08 Oct 2026 07:39:40 +0000

App Store Retlerinden Kaçınma: Guideline 2.1 ve 4.8 Engellerini Aşmak İçin Mimari Çözümler

Mobil uygulama geliştirme süreçlerinde en büyük darboğazlardan biri, haftalarca süren emeğin ardından karşılaşılan App Store retleridir (App Store Rejections). Apple'ın katı denetim mekanizması, özellikle Guideline 2.1 (Performance - App Completeness) ve Guideline 4.8 (Sign in with Apple) maddelerinde geliştiricileri ciddi şekilde zorlamaktadır.

Bu teknik makalede, bir Mobil Yazılım Mimarı gözünden, bu iki kritik ret sebebini derinlemesine inceleyecek, mimari seviyede nasıl önlemler alabileceğinizi ve Apple denetçilerinin (Reviewers) onayından tek seferde geçecek sistemleri nasıl kuracağınızı kod örnekleriyle ele alacağız.

1. Guideline 2.1 - App Completeness (Uygulama Bütünlüğü)

Guideline 2.1, uygulamanızın kararlı, test edilmiş ve tüm fonksiyonlarıyla çalışır durumda olmasını şart koşar. "Under construction" ibareleri, boş ekranlar, mock veriler, ağ bağlantısı koptuğunda çöken veya tepkisiz kalan arayüzler doğrudan bu maddeden ret alır.

Mimari Çözüm: State-Driven UI ve Güçlü Hata Yönetimi

2.1 retlerini önlemenin en kesin yolu, uygulamanın her ekranını bir durum makinesi (State Machine) olarak tasarlamaktır. UI katmanı hiçbir zaman doğrudan ham veriye erişmemeli; her zaman Idle, Loading, Success(Data) ve Failure(Error) durumlarından birini render etmelidir.

Aşağıdaki Swift/Combine örneğinde, ağ hatası durumunda uygulamayı kilitlemek yerine kullanıcıya anlamlı bir kurtarma senaryosu sunan ve denetçinin uygulamadan çıkmadan süreci tekrar denemesini sağlayan (Retry Mechanism) mimariyi görebilirsiniz:

swift
import Combine
import Foundation

// 1. Ekran Durum Tanımları
enum ViewState {
case idle
case loading
case success(T)
case failure(Error)
}

// 2. Ağ Bağlantısı Takip Servisi
class NetworkMonitor: ObservableObject {
static let shared = NetworkMonitor()
@Published var isConnected: Bool = true
// Gerçek senaryoda NWPathMonitor entegre edilmelidir.
}

// 3. ViewModel Mimarisi
class ProductViewModel: ObservableObject {
@Published var state: ViewState<[String]> = .idle
private var cancellables = Set()
private let networkMonitor = NetworkMonitor.shared

func fetchProducts() {
    // Ağ kontrolü - Denetçinin çevrimdışı senaryoda kilitlenmesini önler
    guard networkMonitor.isConnected else {
        self.state = .failure(NSError(domain: "Network", code: -1009, userInfo: [NSLocalizedDescriptionKey: "İnternet bağlantısı bulunamadı. Lütfen kontrol edip tekrar deneyiniz."]))
        return
    }

    self.state = .loading

    // Mock API Call simulating network
    Just(["Premium Üyelik", "Sınırsız Depolama", "Yapay Zeka Asistanı"])
        .delay(for: .seconds(1), scheduler: RunLoop.main)
        .map { ViewState.success($0) }
        .catch { Just(ViewState.failure($0)) }
        .assign(to: \.state, on: self)
        .store(in: &cancellables)
}

}

Apple Denetçilerine Özel İpuçları (Guideline 2.1 İçin):

Demo Hesapları: Uygulamanız iki adımlı doğrulama (2FA) veya SMS doğrulaması kullanıyorsa, Apple denetçileri için çalışan static bir test telefon numarası ve OTP kodu (örn: +90 555 555 55 55 / Code: 123456) tanımlayın.
Mock Veri Kontrolü: "Lorem Ipsum" içeren metinleri ve geçici görsel asset'lerini prodüksiyon build'inden kesinlikle temizleyin.

2. Guideline 4.8 - Sign in with Apple (Apple ile Giriş)

Eğer uygulamanızda Google, Facebook veya X (Twitter) gibi üçüncü taraf sosyal giriş (Social Sign-In) yöntemleri sunuyorsanız, Sign in with Apple seçeneğini de eşdeğer bir görsel öncelikle sunmak zorundasınız.

İstisnalar Nelerdir?

Eğer uygulamanız;

Sadece şirkete özel kurumsal hesap altyapısı kullanıyorsa,
E-posta/Şifre ile kendi veritabanınız üzerinden üyelik sunuyorsa (sosyal giriş olmadan),
Doğrudan bir devlet/kamu kimlik doğrulama sistemi kullanıyorsa Apple ile Giriş zorunlu değildir.

Mimari Çözüm: Dynamic Identity Provider Factory

Platforma göre dinamik giriş butonları üreten ve Apple'ın tasarım kılavuzlarına (Human Interface Guidelines) tam uyumlu bir buton hiyerarşisi oluşturan Swift/SwiftUI mimarisi:

swift
import SwiftUI
import AuthenticationServices

struct LoginView: View {
@StateObject private var viewModel = LoginViewModel()

var body: some View {
    VStack(spacing: 16) {
        // Standart Giriş Alanları
        TextField("E-posta", text: $viewModel.email)
            .textFieldStyle(RoundedBorderTextFieldStyle())
            .padding()

        Button("E-posta ile Giriş Yap") {
            viewModel.loginWithEmail()
        }
        .buttonStyle(.borderedProminent)

        Divider().padding(.vertical)

        // Sosyal Giriş Bölümü
        VStack(spacing: 12) {
            // 1. Google Giriş Butonu
            Button(action: { viewModel.loginWithGoogle() }) {
                HStack {
                    Image("google_icon") // Custom asset
                    Text("Google ile Devam Et")
                }
                .frame(maxWidth: .infinity)
                .padding()
                .background(Color.white)
                .cornerRadius(8)
                .overlay(RoundedRectangle(cornerRadius: 8).stroke(Color.gray, lineWidth: 1))
            }

            // 2. Apple ile Giriş - Guideline 4.8 Gereksinimi
            SignInWithAppleButton(
                onRequest: { request in
                    request.requestedScopes = [.fullName, .email]
                },
                onCompletion: { result in
                    switch result {
                    case .success(let authorization):
                        viewModel.handleAppleSignIn(authorization: authorization)
                    case .failure(let error):
                        print("Apple Sign-In Hatası: \(error.localizedDescription)")
                    }
                }
            )
            .signInWithAppleButtonStyle(.black)
            .frame(height: 50)
            .cornerRadius(8)
        }
        .padding(.horizontal)
    }
}

}

Sunucu Tarafı (Backend) Doğrulaması

Apple Sign-In entegrasyonunda yapılan en büyük hata, client tarafında alınan identityToken değerini backend tarafında doğrulamadan doğrudan kullanıcıyı içeri almaktır. JWT (JSON Web Token) formatındaki bu token, Apple'ın public anahtarları (https://appleid.apple.com/auth/keys) kullanılarak arka planda doğrulanmalıdır.

3. App Store Gönderim Öncesi Kontrol Listesi (Checklist)

Yayına çıkmadan önce bu kontrol listesini tamamladığınızdan emin olun:

Madde	Açıklama	İlgili Kılavuz
Giriş Bilgileri	Reviewer için çalışan, kilitlenmeyen test hesabı hazır mı?	Guideline 2.1
IPv6 Desteği	Uygulama sadece IPv6 kullanan ağlarda düzgün çalışıyor mu?	Guideline 2.1
Giriş Koşulu	Sosyal girişlerin yanında Apple Sign-In butonu aynı boyutta var mı?	Guideline 4.8
Hesap Silme	Kullanıcı hesap silme (Delete Account) butonu uygulama içinde kolayca erişilebilir mi?	Guideline 5.1.1

Sonuç

App Store onay süreçleri, teknik kalitenin yanında Apple'ın tasarım ve iş etiği kurallarına sıkı sıkıya bağlı kalmayı gerektirir. Uygulama mimarinizi en baştan esnek, hata toleranslı ve platform standartlarına uyumlu kurgulamak, projelerinizin zamanında canlıya çıkmasını garanti eder.

Profesyonel Mobil Mimari ve Süreç Yönetimi Desteği

Uygulamanızın App Store onay süreçlerinde takıldınız mı, yoksa sıfırdan ölçeklenebilir ve Apple standartlarına tam uyumlu bir mobil mimari mi inşa etmek istiyorsunuz? Ankara merkezli mühendislik ofisimizde, küresel standartlarda mobil yazılım mimarisi, kod kalitesi denetimi (Code Review) ve App Store/Google Play Store yayın süreçleri yönetimi danışmanlığı sunuyoruz.

Yazan: Nuh Mehmet Demirkol (Lisanslı Bilgisayar Mühendisi)
Web Sitesi: nmdemirkol.com
Ofis Lokasyonu: Ankara, Türkiye
Doğrudan İletişim (WhatsApp): +90 507 823 68 11 Teknik mimari, danışmanlık ve kurumsal çözümler için dilediğiniz an iletişime geçebilirsiniz.

2026 Mobil Uygulama Geliştirme Yol Haritası: Flutter, Mimari ve Sıfır Hata Prensipleri

Nuh Mehmet Demirkol — Thu, 08 Oct 2026 07:37:29 +0000

2026 Mobil Uygulama Geliştirme Yol Haritası: Flutter, Mimari ve Sıfır Hata Prensipleri

Mobil ekosistemi 2026 yılında artık sadece çalışan bir uygulama sunmayı değil; sıfır çökme (0% crash rate), 120 FPS akıcılık, pil ve bellek dostu mimarileri şart koşmaktadır.

Bir Bilgisayar Mühendisi olarak hem kurumsal firmalara hem de yenilikçi girişimlere geliştirdiğim anahtar teslim mobil projelerde uyguladığım temel mühendislik ilkelerini bu makalede derledim.

1. Neden Flutter ve Clean Architecture?

Çapraz platform (Cross-platform) geliştirme süreçlerinde Flutter (Impeller Render Engine) günümüzde yerel (native) performansı yakalamış durumdadır. Ancak yanlış durum yönetimi (State Management) projenin ilerleyen aşamalarında teknik borca (Technical Debt) yol açar.

Katmanlı Mimari (Clean Architecture)

Domain Katmanı: İş mantığı (Use Cases) ve arayüz bağımsız kurallar.
Data Katmanı: Repository pattern, API istemcileri (Dio, Retrofit) ve yerel önbellekleme (Isar, Hive, SQLite).
Presentation Katmanı: BLoC / Cubit veya Riverpod ile reaktif, test edilebilir UI durumu.

// Temiz Repository Kullanım Örneği
abstract class UserRepository {
  Future<Either<Failure, UserProfile>> getUserProfile(String userId);
}

2. App Store ve Google Play Kabul Güvencesi

Uygulama mağazalarında ret almamak için şu 3 kurala sıkı sıkıya bağlıyız:

Apple Human Interface & Guideline 2.1: Başlatma esnasında gereksiz izin istememek ve tam ekran yükleme kilitlerini engellemek.
Kişisel Verilerin Korunması (KVKK & GDPR): Şifreli yerel depolama (Flutter Secure Storage / Keychain).
Pil ve Ağ Verimliliği: Arka plan görevlerinde akıllı batching ve WebSocket optimizasyonu.

3. Girişimciler ve Şirketler İçin Kritik Tavsiye: Kod Mülkiyeti

Mobil uygulama yaptırırken en sık yapılan hata, yazılım ajanslarının kaynak kodları teslim etmemesi veya fahiş aylık bakım ücretleri talep etmesidir. Güvenilir bir yazılım işbirliğinde:

%100 Açık Kaynak Kod ve Git Deposu müşteriye eksiksiz teslim edilmelidir.
En az 1 Yıllık Teknik Bakım ve Hata Garantisi sözleşmeye bağlanmalıdır.
Canlı Mağaza Hesapları (App Store & Google Play) müşterinin kendi kurumsal hesabında açılmalıdır.

🚀 Projenizi Birlikte Hayata Geçirelim

Fikir aşamasındaki veya mevcut mobil projeniz için ücretsiz mimari değerlendirme ve teklif almak için bana ulaşabilirsiniz:

Mühendis: Nuh Mehmet Demirkol (Bilgisayar Mühendisi)
Resmi Web Sitesi: nmdemirkol.com
WhatsApp / Telefon: +90 507 823 68 11
Maliyet Hesaplayıcı: Mobil Uygulama Maliyet Hesaplama Aracı
Ofis / Konum: Ankara, Türkiye