{
"cli": {
"version": ">= 5.0.0"
},
"build": {
"production": {
"ios": {
"distribution": "store"
},
"android": {
"buildType": "app-bundle"
}
}
}
}Să fim sinceri, gestionarea certificatelor iOS a fost mereu cea mai detestată parte din viața unui dev de mobile. În 2026, cu Expo EAS (Expo Application Services), lucrurile s-au simplificat enorm, dar tot trebuie să știi exact unde să apeși ca să nu te blochezi în portalul Apple Developer. Săptămâna trecută am urcat o aplicație de ride-sharing pentru un client local și am rezolvat tot ce ține de semnarea codului în mai puțin de 15 minute, fără să deschid Xcode pe mașina mea locală.
Ce ai nevoie înainte să începi
Nu te apuca de build până nu ai bifat trei chestii esențiale. Ai nevoie de un cont de Apple Developer activ (da, ăla de 99 de dolari pe an), un cont de Expo și CLI-ul EAS instalat global.
Am văzut mulți colegi la început de drum care încearcă să ruleze build-ul având doar rol de 'Developer' în echipa de Apple. Nu merge așa. Ca EAS să poată genera certificatele în numele tău prin API, ai nevoie de rol de 'Account Holder' sau 'Admin'. Altfel, procesul va crăpa cu o eroare de permisiuni fix când îți e lumea mai dragă.
Configurația simplă din eas.json
Înainte de a rula comanda de build, trebuie să ai definit profilul de producție în rădăcina proiectului. EAS are nevoie să știe că vrei un binar gata de trimis în magazin, nu un build de test intern.
Am definit în config-ul meu un profil curat pentru producție, cu modul de distribuție setat corect. Acest fișier spune serviciului EAS cum să ambaleze aplicația înainte ca Apple să o ia la puricat.
Comanda care face toată magia
După ce ai configurat fișierul, tot ce trebuie să faci este să deschizi terminalul și să pornești build-ul.
Când rulezi comanda, CLI-ul te va întreba politicos: 'Do you want Expo to handle your credentials?'. Răspunsul tău trebuie să fie un 'Yes' hotărât. De aici, EAS se conectează securizat la contul tău Apple și generează automat tot ce ai nevoie: un Distribution Certificate nou, un App ID unic în portalul Apple și un Provisioning Profile asociat.
Totuși, există un trade-off important aici. Abordarea auto-manage este genială pentru 95% din proiecte și îți salvează cel puțin 30% din timpul de deployment pe care l-ai pierde manual în Xcode. Însă, dacă lucrezi într-o companie mare, cu politici stricte de securitate unde nu ai voie să partajezi cheile API ale contului de Apple Developer, va trebui să refuzi generarea automată. În acel scenariu, ești obligat să generezi manual certificatele .p12 și profilele de provizionare și să le încarci în EAS folosind comanda eas credentials.
Verificarea finală în App Store Connect
După ce procesul de build de pe serverele Expo s-a finalizat cu succes (durează de obicei între 8 și 12 minute), poți trimite binarul direct în magazin folosind comanda eas submit --platform ios.
Intri în consola App Store Connect și vei vedea build-ul procesându-se direct în secțiunea TestFlight. Nu ai avut nevoie de un Mac ultra-performant pentru compilare, nu te-ai lovit de erori de Keychain local și nu a trebuit să te asiguri manual că profilele de provizionare sunt sincronizate corect.
Voi cum vă urcați aplicațiile iOS acum? Mai folosește cineva arhivarea clasică din Xcode sau ați trecut complet pe fluxuri automate de tip EAS?