Mobile App Wiki

Mobile App Wiki

mobileapp.wiki

Ana Sayfa

Kategoriler

mobileapp.wiki

Mobile App Wiki

Mobil uygulama geliştirme bilgi tabanı

GizlilikAna SayfaSitemapRSS
© 2026 mobileapp.wiki
Ana Sayfa/Geliştirme/App Versioning (Sürüm Numaralandırma)
Geliştirme5 dk okuma

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

Mobil uygulamalarda sürüm numaralandırma rehberi. SemVer, iOS buildNumber, Android versionCode, store kuralları ve EAS Build stratejileri.

versioningsemverbuild numberversioncodeiosandroideas buildsürümstoreci cd

İçindekiler

Genel BakışSemVer (Semantic Versioning)KurallarNe Zaman Ne Artırılır?iOS VersiyonlamaCFBundleShortVersionString (Version)CFBundleVersion (Build Number)iOS Örnek SenaryoXcode'da AyarlamaAndroid VersiyonlamaversionNameversionCodebuild.gradle'da AyarlamaStore Gönderiminde Versiyon KurallarıApple App StoreGoogle PlaySık Yapılan HatalarEAS Build'de Versiyon Yönetimiapp.json / app.config.jsEAS Build Otomatik ArtırmaOtomatik Artırma StratejileriCI/CD Pipeline'daScript ileGit Tag StratejisiVersiyon Gösterme (In-App)Özet TabloSonuçİlgili Konular

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?

DeğişiklikÖrnekArtır
Uygulamayı sıfırdan yeniden yazdınRN -> Flutter geçişiMAJOR
Tamamen yeni navigasyon yapısıTab'dan drawer'a geçişMAJOR
Yeni ekran/özellik ekledinProfil düzenleme eklendiMINOR
Yeni API entegrasyonuPush notification eklendiMINOR
Crash düzelttinNull pointer fixPATCH
Typo düzelttinYazım hatası düzeltmePATCH
Performans iyileştirmesiListe render optimizasyonuPATCH

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

PlatformKullanıcı GörseliDahili NumaraArtırma Kuralı
iOSCFBundleShortVersionStringCFBundleVersion (buildNumber)Build her zaman artmalı
AndroidversionNameversionCodeversionCode her zaman artmalı
EAS Buildexpo.versionbuildNumber / versionCodeautoIncrement kullan

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ı)

Bu makaleyi nasıl buldunuz?

Paylaş

← Önceki

React Native

Sonraki →

Flutter

İlgili Makaleler

React Native

Meta'nın JavaScript tabanlı cross-platform framework'ü React Native rehberi. iOS ve Android native uygulama geliştirme, Expo ve New Architecture.

Flutter

Google'ın Dart tabanlı cross-platform UI toolkit'i Flutter rehberi. Tek codebase ile iOS, Android, Web ve Desktop uygulama geliştirme stratejileri.

Expo

React Native için hızlı geliştirme platformu Expo rehberi. EAS Build, OTA güncelleme, cloud build, managed workflow ve SDK modülleri detayları.

CI/CD (Mobil)

Mobil uygulamalar için CI/CD pipeline rehberi. EAS Build, Fastlane, Bitrise, Codemagic ve GitHub Actions ile sürekli entegrasyon ve dağıtım.

Code Signing (iOS)

iOS uygulama imzalama süreci rehberi. Certificate ve provisioning profile yönetimi, automatic ve manual signing, Fastlane Match ve CI/CD entegrasyonu.