{
"build": {
"production": {
"distribution": "store",
"ios": {
"appleTeamId": "AB12345XYZ",
"bundleIdentifier": "com.community.myapp"
},
"env": {
"APP_VARIANT": "production"
}
}
}
}Să fim sinceri, cine a încercat să publice o aplicație pe iOS acum 5-6 ani știe ce înseamnă iadul certificatelor. Generai CSR-ul în Keychain Access, îl urcai la Apple, descărcai certificatul, făceai provisioning profile-ul, te rugai să nu expire. În 2026, dacă încă faci asta manual, ori ești masochist, ori lucrezi într-o corporație cu reguli de securitate din epoca de piatră.
Am avut recent un proiect pentru un client (un MVP rapid, cam 12k useri estimați în prima lună) și am decis să merg 100% pe fluxul de auto-managed oferit de Expo. Am salvat cam 3 ore de configurări și înjurături doar din treaba asta. Dacă ești la prima lansare, iată exact ce trebuie să faci ca să nu stai să cauți pe Stack Overflow la 2 dimineața.
Pregătirea terenului (și portofelului)
Înainte de orice comandă în terminal, trebuie să ai contul de Apple Developer activ. Costă tot 99$/an, Apple nu s-a lăsat înduplecat nici în 2026. Fără el, nu poți genera nimic. După ce ai contul, asigură-te că ai eas-cli instalat la ultima versiune.
Trade-off-ul sincer? Dacă lași Expo să gestioneze tot, ei îți țin cheile private în cloud-ul lor. Pentru 99% din proiecte e perfect. Dacă lucrezi la o aplicație bancară sau ceva ultra-critic unde cheia privată trebuie să stea într-un seif fizic, atunci fluxul ăsta nu e pentru tine. Dar pentru restul lumii, e mană cerească.
Configurarea care contează
Rulezi eas build:configure. Aici se creează eas.json. Partea importantă în 2026 este să ai distribution: "store" în profilul de producție. Am văzut mulți care uită asta și se miră de ce build-ul lor nu e acceptat în TestFlight.
Când dai prima dată eas build --platform ios, EAS o să te întrebe: "Do you want Expo to handle your credentials?". Răspunsul este un „DA” hotărât. O să îți ceară logarea în contul de Apple (folosește un App-Specific Password dacă ai 2FA, și sigur ai). Din momentul ăla, Expo face tot: creează Bundle ID-ul, generează Distribution Certificate și face Provisioning Profile-ul.
Chestii de care te lovești sigur
Chiar dacă totul e „auto”, sunt două locuri unde se rupe filmul:
- Privacy Manifests: Din 2024-2025, Apple a devenit obsedat de ele. Dacă folosești librării care accesează disk-ul sau camera, trebuie să le declari în
app.json. Altfel, build-ul trece, dar primești un mail sec de rejection în 5 minute. - Bundle Identifier: Verifică de zece ori să fie unic. Dacă l-ai „ars” cu un test anterior, EAS o să dea eroare că nu poate crea unul nou cu același nume.
La proiectul de care ziceam, am scos un build de producție gata de TestFlight în fix 14 minute. Înainte, doar până se pupau certificatele în Xcode pierdem jumătate de zi.
De ce ai alege să NU faci asta?
Există un singur scenariu nasol: când echipa ta crește și ai nevoie să semnezi aplicații local, pe mai multe mașini, fără să treci prin EAS. În cazul ăla, va trebui să descarci manual ce a generat Expo (eas credentials) și să le imporți în Xcode-ul fiecărui dev. E un pic de overhead, dar tot e mai bine decât să le generezi de la zero.
Tu cum preferi să gestionezi semnarea? Te bazezi pe norul lor sau încă mai ai folderul ăla „SECRET_KEYS_DONT_DELETE” pe un stick USB?