Build Number — шта је то, значење параметра и инкремент

Аутор: IT Sectr Објављено: 2026-04-18 Време читања: 8 мин

Build Number — јединствени нумерички идентификатор компилације мобилне апликације који служи за интерну идентификацију верзија. За разлику од Version Name-а, овај параметар се не приказује кориснику, али је критичан за продавнице апликација. Према подацима Android Developers, 2025, исправна употреба Build Number-а спречава конфликте при објављивању ажурирања.

Главно

  • Build Number — нумерички идентификатор сваке компилације, који се користи за интерно вођење верзија.
  • У Android-у се поставља параметром versionCode у build.gradle, у iOS-у — CFBundleVersion у Info.plist.
  • Build Number мора да се повећава са сваком новом компилацијом — продавнице апликација проверавају овај услов.
  • За разлику од Version Name-а, Build Number се не приказује корисницима у Google Play-у и App Store-у.
  • Аутоматски инкремент Build Number-а кроз CI/CD искључује грешке дуплирања бројева компилација.

Шта је Build Number

Build Number — јединствени целобројни идентификатор који се додељује свакој компилацији мобилне апликације. Продавнице апликација га користе за одређивање новине верзије — што је број већи, то је компилација новија.

У Android-у овај параметар се назива versionCode, у iOS-у — CFBundleVersion. Оба параметра су обавезна за објављивање и морају монотоно да расту са сваком новом компилацијом.

Према подацима Google Play Console Help (2025), versionCode се проверава при сваком отпремању APK-а: ако отпремљена компилација има versionCode мањи или једнак већ објављеној, Google Play одбија фајл са грешком.

Користите Build Number за интерно праћење компилација — повежите број са commit hash-ом у систему контроле верзија за брзу идентификацију проблематичног издања.

Зашто је потребан Build Number

Build Number решава проблем јединствене идентификације сваке изграђене верзије апликације. Без њега је немогуће одредити која је компилација новија ако се Version Name није променио.

Продавнице апликација, попут Google Play-а и App Store-а, користе Build Number за решавање конфликата при ажурирању. Ако корисник инсталира нову верзију преко старе, систем упоређује Build Number и нуди ажурирање само ако је вредност већа.

Ова механика је критична за исправну доставу ажурирања: без монотоно растућег Build Number-а корисници могу да остану на старој верзији апликације.

Формати Build Number-а

Build Number може бити једноставан секвенцијални број (1, 2, 3...) или сложен, који кодира додатне информације. Сложени бројеви често укључују датум компилације или број компилације CI/CD система.

За Android versionCode је цео број типа int, максимална вредност — 2100000000. За iOS CFBundleVersion је низ од три броја раздвојених тачкама, сваки не већи од 255.

Према подацима Apple Developer (2025), CFBundleVersion подржава до 3 компоненте, али App Store их користи као један редни број за поређење верзија.

Build Number на Android-у

На Android-у Build Number се поставља параметром versionCode у фајлу build.gradle. То је цео број који мора бити јединствен за сваку верзију апликације објављену у Google Play-у.

Параметар се декларише унутар блока android.defaultConfig и мора да расте са сваким новим издањем. Google Play не дозвољава отпремање APK-а са versionCode-ом који је већ коришћен за другу верзију исте апликације.

Према подацима Google Play Developer API (2025), максимална вредност versionCode-а је 2100000000. Препоручује се почети од 1 и повећавати за 1 за сваку нову компилацију како би се избегло исцрпљивање лимита.

Користите сложени versionCode који кодира број верзије: Major * 1000000 + Minor * 1000 + Patch — ово поједностављује мапирање на семантичку верзију.

Ограничења versionCode-а у Android-у

versionCode има строга ограничења: то је 32-битни цео број са знаком, па је максимална вредност 2100000000. При исцрпљивању лимита апликација се неће моћи ажурирати у Google Play-у.

За Android App Bundle versionCode се такође наводи у base модулу, а сваки feature модул може имати сопствени versionCode. Google Play их обједињује у јединствени систем провере.

Ово ограничење је важно узети у обзир при избору стратегије верзионисања — пребрзи раст броја може довести до проблема на дуги рок.

Build Number на iOS-у

На iOS-у Build Number се поставља кључем CFBundleVersion у фајлу Info.plist. За разлику од Android-а, овај параметар је стринг, али такође мора да расте са сваком новом компилацијом.

Формат CFBundleVersion — од једног до три броја раздвојених тачкама. Сваки број не може прелазити 255. App Store интерпретира стринг као низ бројева за поређење: 1.0.1 се сматра новијим од 1.0.0.

Према подацима Apple Developer Documentation (2025), App Store Connect захтева јединственост CFBundleVersion-а за сваку отпремљену компилацију. Ако се отпреми компилација са већ коришћеним бројем, систем ће је одбити.

Управљајте CFBundleVersion-ом путем agvtool-а или скрипти компилације Xcode-а како бисте гарантовали монотони раст броја при свакој компилацији.

Интеграција са Build Settings Xcode-а

Xcode омогућава управљање CFBundleVersion-ом путем подешавања Build Settings. Поље „Current Project Version“ поставља основну вредност, а скрипте Build Phase могу аутоматски да га повећавају.

За CI/CD користите фластејн плагин increment_build_number, који чита тренутну верзију из Info.plist-а и повећава је за задату вредност. Ово гарантује јединственост сваке компилације.

Овакав приступ потпуно аутоматизује управљање Build Number-ом и искључује људске грешке при припреми издања.

Аутоматски инкремент Build Number-а

Аутоматски инкремент Build Number-а је стандардна пракса у модерним CI/CD пајплајновима. Ручно повећање броја компилације доводи до грешака и конфликата при објављивању.

GitHub Actions, GitLab CI и Jenkins пружају уграђене променљиве са бројем компилације. Ове променљиве се користе у Gradle или Xcode скриптама за аутоматску замену Build Number-а.

Према подацима GitLab CI Documentation (2025), променљива CI_PIPELINE_IID гарантује јединствени број за сваки пајплајн, што је идеално за употребу као Build Number.

Подесите аутоматски инкремент на нивоу CI/CD — ово ће елиминисати потребу за ручном променом Build Number-а при сваком комиту у релизну грану.

Популарни алати за аутоматизацију

GitHub Actions подржава уграђену променљиву run_number, која се аутоматски повећава за свако покретање пајплајна. Вредност се може проследити Gradle-у путем versionCode-а.

Jenkins користи променљиву BUILD_NUMBER, која је доступна у свим фазама компилације. За Xcode пројекте Jenkins покреће agvtool са овим бројем.

Бирајте алат који је интегрисан у ваш технолошки стек како бисте минимализовали додатна подешавања.

Build Number и Version Name

Build Number и Version Name раде као пар: први — за машине, други — за људе. Build Number обезбеђује техничку јединственост, Version Name — разумљиву семантику за корисника.

У Android-у ова два параметра су независна: versionCode може да расте без промене versionName-а (на пример, за исправку грешке компилације). У iOS-у CFBundleVersion такође није везан за CFBundleShortVersionString.

Према подацима Stack Overflow Developer Survey (2024), 82% тимова користи аутоматски инкремент Build Number-а, али само 45% аутоматизује ажурирање Version Name-а — ово је један од честих узрока грешака при издању.

Увек повећавајте Build Number при свакој компилацији, чак и ако се Version Name не мења — ово гарантује исправан рад механизма ажурирања у продавницама апликација.

Најбоље праксе за Build Number

Почните versionCode од 1 и повећавајте за 1 за сваку компилацију. За iOS користите аналоган приступ са CFBundleVersion-ом. Избегавајте сложене бројеве ако нема строге потребе — једноставан секвенцијални број је лакше пратити.

Повежите Build Number са бројем компилације CI/CD система — ово поједностављује праћење од грешке до конкретног комита. Git tag са бројем компилације и верзијом је најбоља пракса за контролу издања.

Примери подешавања Build Number-а

Примери кода показују како подесити аутоматски инкремент Build Number-а на обе платформе.

versionCode у Gradle-у са CI променљивом

У Android-у versionCode се може поставити преко променљиве окружења CI/CD-а. Ако променљива није постављена, користи се подразумевана вредност.

groovy
android {
    defaultConfig {
        versionCode System.getenv("CI_PIPELINE_ID")?.toInteger() ?: 1
        versionName "1.2.0"
    }
}

versionCode добија вредност из CI/CD променљиве, што гарантује јединственост броја за сваку компилацију у пајплајну.

Инкремент CFBundleVersion-а путем agvtool-а

У iOS-у за аутоматско повећање Build Number-а користи се agvtool, који је уграђен у Xcode Command Line Tools.

bash
# Повећање билд-номера за 1
xcrun agvtool next-version -all

# Постављање конкретног билд-номера
xcrun agvtool new-version -all "3.0.1"

Заставица -all ажурира верзију у свим таргетима пројекта, што гарантује синхронизацију вредности између главне апликације и проширења.

Fastlane за аутоматизацију

Fastlane — популарни алат за аутоматизацију компилације мобилних апликација. Плагин increment_build_number аутоматски повећава Build Number.

ruby
increment_build_number(
    build_number: ENV["BUILD_NUMBER"] ||
                 latest_testflight_build_number + 1
)

Fastlane се интегрише са било којим CI/CD системом и подржава како Android, тако и iOS пројекте.

Често постављана питања

Шта се дешава ако се Build Number не повећа?

Продавница апликација ће одбити отпремање. Google Play и App Store проверавају да ли је Build Number нове компилације већи од претходно објављене верзије. Ако услов није испуњен, отпремање ће бити одбијено.

Може ли се Build Number ресетовати на 1?

Само за нову апликацију. Након првог објављивања, Build Number може само да расте. Ресетовање на 1 довешће до грешке “versionCode already exists” при покушају објављивања нове верзије.

Који је максимални Build Number у Android-у?

2100000000 — максимална вредност за versionCode у Android-у, јер је то 32-битни цео број са знаком. При разумном повећању за 1 по компилацији, лимит ће трајати за милијарде билдова.

По чему се CFBundleVersion разликује од CFBundleShortVersionString-а?

CFBundleVersion — интерни број компилације који мора да расте са сваким билдом. CFBundleShortVersionString — корисничка верзија приказана у App Store-у. Први — за машине, други — за људе.

Да ли треба повећавати Build Number за тестне компилације?

Да, обавезно. TestFlight такође захтева да свака отпремљена компилација има јединствени Build Number. Ако се број не повећа, TestFlight ће одбити отпремање.

Резиме

  • Build Number — интерни нумерички идентификатор компилације, обавезан за објављивање у Google Play-у и App Store-у.
  • На Android-у се користи versionCode (цео број), на iOS-у — CFBundleVersion (стринг до 3 компоненте).
  • Број компилације мора монотоно да расте — продавнице одбијају компилације са неповећаним Build Number-ом.
  • Аутоматски инкремент кроз CI/CD искључује грешке и гарантује јединственост сваког билда.
  • Build Number је независан од Version Name-а — може се повећавати без промене корисничке верзије.
  • За Android користите CI/CD променљиве у Gradle-у, за iOS — agvtool или fastlane.
  • Максимални versionCode у Android-у — 2100000000, CFBundleVersion — до 255 за сваку од три компоненте.

Развићемо мобилну апликацију под кључ

IT Sectr креира iOS и Android апликације за стартапе и предузећа од 2017. године. Саветоваћемо вас и предложити најбоље решење.

Разговарајте о пројекту

Прочитајте такође