# App Store Connect build number: versio ja buildinumero

> Versio on asiakkaiden näkemä numero, build number yksilöi jokaisen latauksen. Parin on oltava yksilöllinen: Expolla EAS kasvattaa buildia puolestasi.

Alkuperäinen sivu: [App Store Connect build number: versio ja buildinumero](https://devoria.fr/fi/blog/app-store-connect-build-number-versio-buildinumero)
Kirjoittaja: [Mehdi Azizi](https://devoria.fr/fi/mehdi-azizi)
Julkaistu: 2026-11-04
Sisältö tarkistettu viimeksi: 2026-11-04


App Store Connectin build number on buildinumero: avain `CFBundleVersion`, joka yksilöi jokaisen latauksen. Versio, `CFBundleShortVersionString`, on numero, jonka asiakkaasi näkevät App Storessa. **Apple vaatii, että version ja buildinumeron pari on yksilöllinen: samaa buildinumeroa voi käyttää vain kerran saman version sisällä.**

Expolla asetat version itse, ja EAS voi kasvattaa buildinumeroa jokaisessa tuotantobuildissa. Tämä opas selittää molemmat numerot, Applen säännöt, virheet ITMS-90062 ja ITMS-90189 sekä sen, mitä tarkistaa, kun buildisi ei näy.

Julkaisen iOS-sovellukseni Expolla ja EAS:llä, muun muassa Solysin, TradaZenin ja Noleran. Alempana näytetyt asetukset ovat niiden `eas.json`-tiedostoista.

## Versio ja buildinumero: mikä ero?

Kaksi Info.plistin avainta tunnistaa sovelluksesi. [Applen dokumentaatio CFBundleShortVersionStringistä](https://developer.apple.com/documentation/bundleresources/information-property-list/cfbundleshortversionstring) kuvaa sen käyttäjälle näkyväksi versioksi: kolme pisteillä erotettua kokonaislukua, kuten 10.14.1. [CFBundleVersionin dokumentaatio](https://developer.apple.com/documentation/bundleresources/information-property-list/cfbundleversion) puhuu buildin versiosta: yhdestä kolmeen kokonaislukua, vain numeroita ja pisteitä.

| Osa          | iOS-avain                  | Kuka sen näkee | Expo-kenttä       |
| ------------ | -------------------------- | -------------- | ----------------- |
| Versio       | CFBundleShortVersionString | Asiakkaasi     | `version`         |
| Buildinumero | CFBundleVersion            | Sinä ja Apple  | `ios.buildNumber` |

Kuvitteellinen esimerkki: version 1.4.0 testauksen aikana lataat buildit 12, 13 ja 14, ja valitset sitten niistä yhden tarkastukseen. [App Store Connectin ohje](https://developer.apple.com/help/app-store-connect/manage-builds/upload-builds) tiivistää asian: versio liittää buildin sen sivuun, ja buildinumero yksilöi sen kaikkialla järjestelmässä.

## Applen kasvatussäännöt

1. **Parin on oltava yksilöllinen.** [Xcode Cloudin dokumentaation](https://developer.apple.com/documentation/xcode/setting-the-next-build-number-for-xcode-cloud-builds) mukaan App Store Connect vaatii yksilöllisen version ja buildinumeron yhdistelmän. iPhone-sovellus voi siis aloittaa uudelleen ykkösestä uudessa versiossa. Mac-sovellus ei voi: sen numeron on aina kasvettava.
2. **Hyväksytty versio on suljettu.** Kun Apple on hyväksynyt version 1.4.0, et voi enää lisätä siihen buildeja. Seuraavalla on oltava suurempi numero.
3. **Jokaista lukua verrataan kokonaislukuna.** 1.10 tulee 1.9:n jälkeen, koska 10 on suurempi kuin 9. Versio 1.9, joka ladataan hyväksytyn 1.20:n jälkeen, hylätään.

Neuvoni: **pidä buildinumero kokonaislukuna, joka kasvaa aina, äläkä nollaa sitä ykköseen.** Ykkösestä aloittaminen on iPhonella sallittua, mutta koko sovelluksen elinkaaren ajan yksilöllinen numero estää sekoittamasta kahta buildia TestFlightissa. Näin näen omissa sovelluksissani remote-tilassa: laskuri jatkaa versiosta toiseen.

## Version ja buildin hallinta Expolla ja EAS:llä

[Expon versiosivu](https://docs.expo.dev/build-reference/app-versions/), päivitetty 25. syyskuuta 2026, erottaa roolit. Versio (`version` app.jsonissa) on sinun vastuullasi: muutat sitä, kun valmistelet uutta julkaisua. Buildinumeron (`ios.buildNumber`) voit antaa EAS:n hoidettavaksi. Expo mainitsee muuten sen kasvattamisen unohtamisen yleisenä syynä latauksen hylkäämiseen.

Kaikki säädetään eas.jsonissa:

```json
{
  "cli": {
    "appVersionSource": "remote"
  },
  "build": {
    "production": {
      "autoIncrement": true
    }
  }
}
```

- **`"remote"`**: EAS:n palvelimet säilyttävät buildinumeron. Tämä on suositeltu toiminta EAS CLI 12:sta lähtien. Laskuri alkaa konfiguraatiosi arvosta tai ykkösestä, ja sen jälkeen `ios.buildNumber` ohitetaan.
- **`"local"`**: konfiguraatiosi on ratkaiseva. `autoIncrement`-asetuksella EAS muokkaa tiedostosi `ios.buildNumber`-arvoa, ja sinun on commitoitava muutos jokaisen buildin jälkeen.
- **`autoIncrement`**: [eas.jsonin referenssi](https://docs.expo.dev/eas/json/) hyväksyy buildille arvon `true` tai `"buildNumber"`, ja arvon `"version"` version viimeisen numeron kasvattamiseen. Expo tarkentaa, ettei `"version"` ole tuettu remote-tilassa.

Minulla TradaZen ja Nolera ovat `remote`-tilassa. Solys on jäänyt `local`-tilaan: sen buildinumero asuu app.jsonissa, ja jokainen tuotantobuild kasvattaa sitä tiedostossa. **Molemmat toimivat, mutta remote-tila poistaa unohtuneen commitin riskin.**

Kaksi komentoa täydentää kokonaisuuden. `eas build:version:set` alustaa etälaskurin: syötä viimeisin Applelle lähetetty numero. `eas build:version:sync` kopioi etäarvot projektiisi, mikä on hyödyllistä, jos joskus käännät Xcodella. EAS Updaten kanssa remote-tila ei toimi `nativeVersion`-käytännön kanssa: Expo suosittelee `appVersion`-käytäntöä.

## ITMS-90062: versio on jo hyväksytty

Viesti näyttää tältä (kuvitteelliset numerot):

```text
ERROR ITMS-90062: This bundle is invalid. The value for key
CFBundleShortVersionString [1.4.0] in the Info.plist file must
contain a higher version than that of the previously approved
version [1.4.0].
```

Apple on jo hyväksynyt version 1.4.0: et voi enää lisätä siihen buildia. **Nosta versiota app.jsonissa, esimerkiksi 1.4.1:een, ja aja build uudelleen.** Pelkkä buildinumeron muuttaminen ei riitä.

Jos virhe toistuu, vaikka `version` on ajan tasalla, etsi `ios.version`-kenttää. [Expon konfiguraatioreferenssin](https://docs.expo.dev/versions/latest/config/app/) mukaan se ohittaa iOS:llä `version`-kentän. Sama korjaus pätee sukulaisvirheeseen ITMS-90186, "Invalid Pre-Release Train", joka kertoo version olevan suljettu uusilta buildeilta.

## ITMS-90189: Redundant Binary Upload

Tässä ongelma on buildinumerossa:

```text
ERROR ITMS-90189: Redundant Binary Upload. You've already uploaded
a build with build number '12' for version number '1.4.0'.
```

Pari 1.4.0 (12) on jo Applella. Expolla toistuu neljä syytä:

- **Käytetyssä profiilissa ei ole `autoIncrement`-asetusta.** Jos luot erillisen profiilin TestFlightia varten, kuten Noleran profiili, lisää asetus sinnekin.
- **Etälaskuri on jäljessä.** Siirryit `remote`-tilaan manuaalisten latausten jälkeen: aja `eas build:version:set` viimeisimmällä Applen tuntemalla numerolla.
- **Commit unohtui local-tilassa.** Seuraava build alkaa vanhasta numerosta.
- **Lähetät saman binäärin uudelleen.** Valitse `eas submit` -komennolla uusi build, ei vanhaa.

**Korjaus on aina sama: uusi build suuremmalla numerolla.**

## "No builds available": buildisi ei näy

Build lähti, mutta sivusi ei tarjoa sitä. Tarkista tässä järjestyksessä.

1. **Sitä käsitellään vielä.** Apple käsittelee jokaisen buildin ennen sen näyttämistä ja lähettää sinulle sähköpostin lopuksi. [Expo](https://docs.expo.dev/submit/ios/) puhuu yleensä 10-15 minuutista. [Applen mukaan](https://developer.apple.com/help/app-store-connect/manage-builds/view-builds-and-metadata) jos käsittely kestää yli 24 tuntia, on avattava Feedback Assistant -tiketti.
2. **Se odottaa salausilmoitustasi.** Tämä on tila Missing Compliance, josta lisää alempana.
3. **Versio ei täsmää.** Build 1.4.1 ei asetu App Store Connectissa versiolle 1.5.0 valmistellun sivun alle. Yhdenmukaista ne.
4. **Välissä on julkaistu versio.** [Buildin valintaa koskevan ohjeen](https://developer.apple.com/help/app-store-connect/manage-builds/choose-a-build-to-submit) mukaan lista näyttää silloin vain sen julkaisun jälkeen ladatut buildit.
5. **Testaaja ei näe sitä.** TestFlight-sovelluksessa "no builds available" tarkoittaa usein, että build ei ole missään ryhmässä, odottaa beta-tarkastusta tai on vanhentunut. Yksityiskohdat ovat artikkelissa [TestFlight iPhone-sovelluksen testaamiseen](https://devoria.fr/fi/blog/testflight-testaa-iphone-sovellus-ennen-lahetysta).

### Tilat, jotka kannattaa tuntea

Tilat, jotka useimmiten selittävät puuttuvan buildin, [Applen listan](https://developer.apple.com/help/app-store-connect/reference/app-build-statuses) mukaan. Processing ja Failed eivät ole siinä: ne ovat lataustiloja, jotka kuvataan [buildien seurannassa](https://developer.apple.com/help/app-store-connect/manage-builds/view-builds-and-metadata).

| Tila               | Mitä se tarkoittaa               | Korjauksesi                 |
| ------------------ | -------------------------------- | --------------------------- |
| Processing         | Apple käsittelee buildia         | Odota sähköpostia           |
| Failed             | Virhe käsittelyssä               | Lue virhe, lähetä uudelleen |
| Missing Compliance | Salausta ei ilmoitettu           | Vastaa tai Info.plist       |
| Invalid Binary     | Lataus ei vaatimusten mukainen   | Korjaa, uusi build          |
| Expired            | 90 päivää ylitetty               | Uusi build                  |
| Ready to Submit    | Valmis testiin tai tarkastukseen | Lisää se ryhmään            |

### Ilmoita salaus kerralla

Ilman `ITSAppUsesNonExemptEncryption`-avainta [Apple](https://developer.apple.com/documentation/bundleresources/information-property-list/itsappusesnonexemptencryption) esittää vaatimustenmukaisuuskysymykset jokaisessa uudessa versiossa. Expossa kentän nimi on `ios.config.usesNonExemptEncryption`:

```json
{
  "expo": {
    "ios": {
      "config": {
        "usesNonExemptEncryption": false
      }
    }
  }
}
```

`false` tarkoittaa: ei salausta tai vain vapautettua salausta. [Apple tarkentaa](https://developer.apple.com/documentation/security/complying-with-encryption-export-regulations), että järjestelmään sisäänrakennettu salaus, kuten HTTPS-yhteydet, on yleensä vapautettu, ja että vastaus kattaa myös kirjastosi. Kaikki kolme sovellustani ilmoittavat `false`. **Laita `false` vain, jos se pitää paikkansa sovelluksesi kohdalla: ilmoitus sitoo sinua.**

## Voiko jo lähetetyn buildin numeroa muuttaa?

Ei. Numero on kirjattu allekirjoitettuun binääriin: sen korjaamiseen tarvitaan uusi build.

Voit kuitenkin vaihtaa versioosi liitetyn buildin. Apple sallii vain yhden buildin per versio, mutta [voit vaihtaa sen niin monta kertaa kuin haluat](https://developer.apple.com/help/app-store-connect/manage-builds/choose-a-build-to-submit) tarkastukseen lähettämiseen asti:

1. Avaa versio App Store Connectissa, Build-osio.
2. Vie osoitin nykyisen buildin päälle ja klikkaa poistopainiketta, miinusmerkkiä.
3. Klikkaa lisäyspainiketta, plusmerkkiä, valitse oikea build ja tallenna.

Buildin poistaminen versiosta ei poista sitä tililtäsi. Jos versio on jo tarkastuksessa, [peru ensin lähetys](https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/remove-a-submission-from-review): tarkastus alkaa alusta.

## Ennen seuraavaa latausta

Buildinumero on vain yksi latauksen tarkistuksista. Build-image voi laukaista virheen [ITMS-90725](https://devoria.fr/fi/blog/itms-90725-sdk-version-issue-expo), ja allekirjoituksella on omat ansansa, jotka käydään läpi artikkelissa [iOS-kehittäjävarmenne ja provisioning profile](https://devoria.fr/fi/blog/ios-kehittajavarmenne-provisioning-profile-expo). Koko ketju buildista TestFlightiin on artikkelissa [iOS-sovelluksen julkaisu ilman Macia](https://devoria.fr/fi/blog/ios-sovellus-julkaisu-ilman-macia-expo-eas), ja tarkastusajat artikkelissa [App Store -tarkastuksen kesto](https://devoria.fr/fi/blog/app-store-tarkistuksen-kesto). Kaikki vaiheet on koottu sivulle [sovelluksen julkaisu App Storessa](https://devoria.fr/fi/expertise/julkaise-sovellus-app-storeen).

Jos valmistelet ensimmäistä julkaisuasi, [tee ilmainen diagnoosi](https://devoria.fr/fi/diagnostic): se kertoo, mikä projektissasi jumittaa, ja lähettää sinulle tarkistuslistani Applen hylkäysten välttämiseen. Sovelluksen rakentamiseen, tilausten kytkemiseen ja julkaisuun [iOS & Android Kit](https://devoria.fr/fi/kits/ios) kulkee neljän vaiheen polun sovellusteni Starter Coden kanssa, omaan tahtiisi.

## Usein kysytyt kysymykset

### Mikä ero on versiolla ja build numberilla App Store Connectissa?

Versio on julkaisusi julkinen numero, kuten 1.4.0. Build number yksilöi tietyn binäärin, joka on lähetetty Applelle tätä versiota varten. Voit lähettää samalle versiolle useita buildeja, kullakin oma numeronsa.

### Pitääkö buildinumeroa muuttaa jokaisessa latauksessa?

Kyllä, saman version sisällä. Apple hylkää toisen latauksen samalla version ja buildinumeron parilla, ja tämä on virhe ITMS-90189. EAS:llä `autoIncrement` hoitaa sen jokaisessa tuotantobuildissa.

### Pitääkö buildinumeron alkaa ykkösestä jokaisessa versiossa?

Se ei ole pakollista. iPhonella Apple hyväksyy pienemmän numeron uudelle versiolle, koska vain parin on oltava yksilöllinen. Aina kasvavaa laskuria on silti helpompi seurata.

### Miten build number vaihdetaan App Store Connectissa?

Jo lähetetyn buildin numeroa ei voi muuttaa. Voit sen sijaan vaihtaa versioosi liitetyn buildin sivun Build-osiosta, kunhan versio ei ole tarkastuksessa. Uutta numeroa varten tee uusi build.

### Miksi buildini ei näy App Store Connectissa?

Useimmiten sitä käsitellään vielä tai se odottaa salausilmoitustasi. Tarkista myös, että sen versio vastaa sivusi versiota. Jos käsittely kestää yli 24 tuntia, Apple pyytää avaamaan tiketin.


## Projektisi

[Review Kit](https://devoria.fr/fi/kits/app-review): App Store -tarkastuksen tarkistuslistani, korjatut Applen hylkäykseni, Google Playn lista ja kolme Claude Code -skilliä. 49 €.

[iOS & Android Kit](https://devoria.fr/fi/kits/ios): Tee iPhone- ja Android-sovelluksesi Claude Codella: sovellusteni pohjakoodi, polku kauppoihin asti ja kaikki kitit. 99 €.

[Diagnoosi: mikä erottaa sinut omasta iPhone-sovelluksestasi](https://devoria.fr/fi/diagnostic): 7 kysymystä, 60 sekuntia: tiedät, mikä oikeasti estää sinua julkaisemasta iPhone-sovellustasi, saat 4 vaiheen polkusi ja sinulle sopivan kitin.