App Versioning (Sürüm Numaralandırma)

Genel Bakış

Sürüm numaralandırma basit görünüyor ama yanlış yapıldığında store reject'leri, kullanıcı karışıklığı ve build hataları kaçınılmaz. iOS ve Android'in versiyon mantığı farklı, store'ların kuralları ayrı. Bu rehberde SemVer'den başlayıp platform bazlı detaylara, EAS Build entegrasyonuna ve otomatik artırma stratejilerine kadar her şeyi anlatıyoruz.

SemVer (Semantic Versioning)

Endüstri standardı olan SemVer formatı: MAJOR.MINOR.PATCH

Kurallar

• MAJOR (1.x.x -> 2.0.0): Breaking change, büyük UI değişikliği, mimari değişiklik
• MINOR (1.1.x -> 1.2.0): Yeni özellik eklendi, geriye uyumlu
• PATCH (1.1.1 -> 1.1.2): Bug fix, küçük düzeltme, performans iyileştirmesi

Ne Zaman Ne Artırılır?

SemVer'de MAJOR 0 iken (0.x.x) uygulama "geliştirme aşamasında" kabul edilir. İlk store yayınında 1.0.0'dan başla.

iOS Versiyonlama

iOS'ta iki farklı versiyon numarası var:

CFBundleShortVersionString (Version)

• Kullanıcının gördüğü versiyon: "1.2.3"
• SemVer formatında olmalı
• App Store'da gösterilen numara bu
• Her yeni store gönderiminde artmalı veya aynı kalabilir
• Aynı version ile birden fazla build gönderebilirsin

CFBundleVersion (Build Number)

• Apple'ın dahili takip numarası
• Genelde tam sayı: "1", "2", "42", "156"
• Her TestFlight ve App Store gönderiminde artmalı
• Aynı version altında bile her build'de farklı olmalı
• Asla azalamaz (Apple bunu kontrol ediyor)

iOS Örnek Senaryo

v1.0.0 (build 1) -> İlk yayın
v1.0.0 (build 2) -> Hotfix, aynı version farklı build
v1.0.1 (build 3) -> Patch update
v1.1.0 (build 4) -> Yeni özellik
v1.1.0 (build 5) -> TestFlight'a tekrar gönderim
v2.0.0 (build 6) -> Major update

Xcode'da Ayarlama

• Xcode -> Target -> General -> Version: "1.2.0"
• Xcode -> Target -> General -> Build: "15"
• Info.plist'te: CFBundleShortVersionString ve CFBundleVersion

Android Versiyonlama

Android'de de iki farklı numara var ama mantık biraz farklı:

versionName

• Kullanıcının gördüğü versiyon: "1.2.3"
• SemVer formatında olmalı
• Google Play'de gösterilen numara
• String olduğu için "1.2.3-beta" gibi suffix eklenebilir
• Ama store yayınında temiz SemVer önerilir

versionCode

• Google'ın dahili takip numarası
• Tam sayı (integer): 1, 2, 42, 156
• Her Google Play gönderiminde artmalı
• Asla azalamaz (Google bunu kontrol ediyor)
• Maksimum değer: 2100000000
• AAB (Android App Bundle) kullanıyorsan her ABI/density split'te farklı olabilir

build.gradle'da Ayarlama

android {
    defaultConfig {
        versionCode 15
        versionName "1.2.0"
    }
}

Store Gönderiminde Versiyon Kuralları

Apple App Store

• Aynı version ile birden fazla build gönderebilirsin (build number farklı olmalı)
• Reject sonrası aynı version + yeni build ile tekrar gönderebilirsin
• Version aynı kalabilir ama build number her zaman artmalı
• TestFlight build'leri de build number tüketiyor

Google Play

• Her yeni upload'da versionCode artmalı
• Internal testing, closed testing, open testing ve production aynı versionCode havuzunu kullanıyor
• Bir track'e yüklediğin versionCode'dan küçük olanı başka track'e yükleyemezsin
• Staged rollout'ta mevcut versionCode ile devam edebilirsin

Sık Yapılan Hatalar

• Build number/versionCode artırmayı unutmak (store reject)
• Test build'lerde production ile aynı numarayı kullanmak
• Farklı branch'lerde aynı versiyon numarasını kullanmak
• Version'ı artırıp build number'ı sıfırlamak (iOS'ta sorun)

EAS Build'de Versiyon Yönetimi

Expo EAS Build kullanıyorsan versiyon yönetimi daha kolay:

app.json / app.config.js

{
  "expo": {
    "version": "1.2.0",
    "ios": {
      "buildNumber": "15"
    },
    "android": {
      "versionCode": 15
    }
  }
}

EAS Build Otomatik Artırma

EAS Build'in autoIncrement özelliği versiyon artırma işini otomatikleştirir:

{
  "build": {
    "production": {
      "autoIncrement": true
    },
    "preview": {
      "autoIncrement": true
    }
  }
}

• autoIncrement: true -> iOS buildNumber ve Android versionCode'u otomatik artırır
• autoIncrement: "buildNumber" -> Sadece iOS buildNumber artırır
• autoIncrement: "versionCode" -> Sadece Android versionCode artırır
• EAS sunucusu son build numarasını takip eder, çakışma olmaz
• app.json'daki değeri otomatik günceller (remote sync)

EAS Build'in autoIncrement'i kullanıyorsan, manuel artırma yapma. İkisini karıştırmak numara çakışmasına neden olur.

Otomatik Artırma Stratejileri

EAS dışında da otomatik artırma yapılabilir:

CI/CD Pipeline'da

• GitHub Actions veya Bitrise'da build step'ine versiyon artırma ekle
• Git tag'den version oku, build numarasını pipeline run sayısından al
• Örnek: version = git tag (v1.2.0), buildNumber = GitHub run number

Script ile

• package.json'daki version'ı kaynak olarak kullan
• npm version patch/minor/major ile SemVer artır
• Post-version script ile app.json'ı güncelle
• Git hook (pre-commit) ile kontrol et

Git Tag Stratejisi

• Her store gönderiminde git tag oluştur: v1.2.0-build.15
• Tag'ler version history'ni takip etmeni sağlar
• Hangi commit'in hangi store version'a denk geldiğini görebilirsin
• CI/CD'de tag push'u otomatik build tetikleyebilir

Versiyon Gösterme (In-App)

Kullanıcıya ve destek ekibine yardımcı olmak için versiyon bilgisini uygulamada göster:

• Ayarlar ekranının en altında: "Versiyon 1.2.0 (build 15)"
• React Native'de: expo-constants veya react-native-device-info
• Flutter'da: package_info_plus
• Bug report'larda versiyon bilgisi otomatik eklensin
• Remote config ile minimum desteklenen versiyon kontrolü yap (force update)

Özet Tablo

Sonuç

Versiyon numaralandırma projenin ilk gününden itibaren düzgün kurulmalı. SemVer'i benimseyip, build numaralarını otomatikleştirmek en sağlıklı yaklaşım. EAS Build kullanıyorsan autoIncrement'i aç ve manuel müdahale etme. Kullanmıyorsan CI/CD pipeline'ına versiyon artırma step'i ekle. Her store gönderiminde git tag oluşturmayı alışkanlık haline getir.

İlgili Konular

• Widgets (iOS & Android)
• Device Testing (Cihaz Testi)
• Google Play Closed Testing (14 Gün Kuralı)