Publicar una actualització iOS: llançament progressiu

Per publicar una actualització iOS, crees una nova versió a App Store Connect, amb un número més alt. Hi adjuntes un nou build, escrius el text de «Novetats» i l'envies a App Review. Cada nova versió torna a passar per la revisió d'Apple, encara que sigui una simple correcció. Abans d'enviar-la, tries com sortirà un cop aprovada: a mà, de seguida, no abans d'una data concreta, o en llançament progressiu en 7 dies.

El llançament progressiu només afecta les actualitzacions automàtiques: l'1 % d'aquests usuaris el primer dia, tots el setè. El pots posar en pausa fins a 30 dies en total, o acabar-lo de cop. Aquesta guia segueix les pàgines d'ajuda d'Apple, revisades el 3 de novembre de 2026.

Publico les actualitzacions de les meves apps iOS amb Expo i EAS, entre elles Solys, TradaZen i Nolera. Els casos que cito més avall surten d'aquests llançaments.

Publicar una actualització iOS: els passos en ordre

L'ajuda d'App Store Connect sobre les noves versions dona aquest recorregut:

1. A Apps, tria la teva app i fes clic al botó + al costat de la plataforma.
2. Introdueix un número de versió més alt que l'anterior i fes clic a Create.
3. Revisa les metadades: les de la versió publicada es copien automàticament.
4. Envia un nou build, amb el número de build incrementat.
5. Prova aquest build a TestFlight, afegeix-lo a la versió i envia-la a App Review.

Dues condicions abans de començar. La versió publicada ha d'estar en estat Ready for Distribution. I necessites un d'aquests rols: Account Holder, Admin, App Manager o Marketing.

No hi ha marxa enrere. Apple ho escriu a la mateixa pàgina: si una versió dona problemes, no pots tornar a l'anterior. Has de crear i enviar una nova versió.

Número de versió i número de build

La versió és el número que els teus clients veuen a la fitxa. El build identifica cada enviament. La parella versió i build ha de ser única: les regles i els errors associats són a versió i número de build.

La meva convenció, que no és cap regla d'Apple: l'últim dígit puja per a una correcció, de 1.4.0 a 1.4.1. El del mig puja per a una funció nova, de 1.4.1 a 1.5.0. El número de build, en canvi, només puja, d'una versió a l'altra. Amb Expo, la versió viu a app.json i EAS pot incrementar el build a cada compilació de producció. La configuració és a publicar una app Expo amb EAS.

El text de «Novetats»: què exigeix Apple

La pàgina d'informació de la versió descriu el camp What's New in This Version:

• 4.000 caràcters com a màxim.
• No existeix per a la primera versió, obligatori per a totes les següents.
• Traduïble a cada idioma de la teva fitxa.

La norma 2.3.12 de les App Review Guidelines hi afegeix un requisit: descriure clarament les funcions noves i els canvis del producte. Una fórmula genèrica n'hi ha prou per a simples correccions d'errors, de seguretat o de rendiment. Un canvi important s'ha de llistar. Per tant, «Correccions d'errors i millores» no n'hi ha prou per a una versió que canvia la teva subscripció o la pantalla principal.

Apple també aconsella, a la seva pàgina sobre les valoracions, indicar a les notes els problemes corregits que alguns clients havien descrit a les seves ressenyes.

Aquí tens tres plantilles per adaptar, una per tipus de versió.

Per a una correcció:

Correccions i estabilitat.
- [Funció]: s'ha corregit [el que no funcionava].
- [Pantalla] carrega més ràpid.
Gràcies a tothom qui ens ho va avisar.

Per a una funció nova:

Nou: [la funció, en cinc paraules].
[El que ara pots fer, en una frase.]
On trobar-la: [pestanya] > [botó].

També en aquesta versió:
- [Millora visible].
- Correccions d'errors.

Per a un recorregut que canvia:

[Pantalla o recorregut] canvia.
- Què canvia per a tu: [efecte concret].
- Què conserves: [dades, ajustos, compra].
Alguna pregunta? [Ajustos] > [Ajuda].

L'última línia de la plantilla de correcció només val si algú ha avisat de debò del problema. No escriguis mai una novetat que no sigui al build: la norma 2.3 demana metadades fidels a l'app.

Llançament manual, automàtic o en una data

L'ajuda sobre les opcions de llançament en proposa tres:

Opció	Després de l'aprovació d'Apple
Manual	Estat Pending Developer Release, publiques quan vulguis
Automàtica	La versió surt tan bon punt s'aprova
Automàtica, no abans del...	Espera la data escollida i després surt sola

En llançament manual, obres la versió en estat Pending Developer Release, fas clic a Release This Version i confirmes. Apple avisa que pot trigar fins a 24 hores a aparèixer a l'App Store. Un missatge a la pàgina de la versió ofereix Cancel This Release per cancel·lar-la. Si la versió es queda més de 30 dies en espera, Apple t'envia un recordatori per correu.

El llançament manual serveix per triar el moment, per exemple per publicar el dia d'un anunci. Solys 2.0.0, que incloïa una nova versió de la subscripció anual, va entrar a revisió a finals de setembre de 2026 en llançament manual.

Per a una versió de rutina, deixo el llançament automàtic. Nolera 1.0.2, acceptada el 12 d'octubre de 2026, va aparèixer a l'App Store menys d'un minut després del correu d'Apple, segons l'API pública de cerca d'iTunes. És una sola observació: calcula amb marge.

El llançament progressiu en 7 dies

L'ajuda d'Apple sobre el llançament progressiu dona el calendari exacte:

Dia	Percentatge d'usuaris
1	1 %
2	2 %
3	5 %
4	10 %
5	20 %
6	50 %
7	100 %

L'actualització s'envia a una mostra aleatòria dels usuaris que tenen activades les actualitzacions automàtiques, en dispositius compatibles. No se'ls avisa que en formen part.

El llançament progressiu només frena les actualitzacions automàtiques. Apple precisa que qualsevol persona pot descarregar la nova versió des de l'App Store, en qualsevol moment. Algú que instal·la la teva app, o que toca «Update» a la teva fitxa, la pot tenir des del primer dia. No és una prova amb l'1 % dels teus usuaris: és un fre per a la resta.

Per activar-lo, obre la versió, baixa fins a la secció Phased Release for Automatic Updates, marca «Release update over a 7-day period using phased release» i desa. Cal el rol Account Holder, Admin o App Manager. L'opció està disponible fins a l'estat Pending Developer Release: encara el pots activar després de l'aprovació d'Apple, mentre la versió esperi el teu llançament manual.

Un cop aprovada la versió, el seu estat Ready for Distribution porta la menció «Phased Release». Al final dels 7 dies, els Admin i App Manager de l'app reben una notificació.

Pausa, represa i llançament per a tothom

• Pausa: fins a 30 dies en total, en tantes vegades com vulguis. Una pausa de 10 dies en deixa 20 per a les següents.
• Represa: el llançament continua des del dia on l'havies aturat.
• Llançament per a tothom: el botó Release to All Users, a dalt a la dreta de la versió, envia l'actualització a tots els dispositius amb actualització automàtica.
• Retirada de la venda: atura el llançament definitivament, també si la teva inscripció al programa de desenvolupadors caduca. Si l'app torna a estar a la venda, la versió queda disponible per a tothom de cop.

Després del llançament per a tothom, ja no es pot ajustar res, segons la taula de propietats editables.

Nolera 1.0.2 va sortir sense llançament progressiu. Així és com el faria servir durant la setmana:

El que veus	El que fas	El que passa
Tancaments inesperats o ressenyes alarmants	Pausa	Les actualitzacions automàtiques s'aturen
La correcció està llesta	Nova versió	Torna a revisió, amb el seu propi llançament
Res d'estrany després de 3 o 4 dies	Release to All Users	Tothom la rep
Esperes una resposta d'Apple	Pausa, 30 dies en total	Es reprèn des del dia on t'havies aturat

Durant una pausa, les descàrregues manuals continuen. Marca el llançament progressiu per a qualsevol versió que toqui el pagament o el primer inici: és on un error surt més car, i no podràs tornar enrere.

Quan la correcció és urgent: la revisió accelerada

Apple permet demanar una revisió accelerada. Està reservada a urgències reals: un error crític per corregir, o un llançament lligat a un esdeveniment.

1. Primer envia la teva versió. Descriu l'error al camp Notes per al revisor.
2. Omple el formulari de sol·licitud de revisió accelerada i tria la teva app i la seva plataforma.
3. Apple accelera la revisió segons la seva disponibilitat. No hi ha res garantit.

Per a un esdeveniment, indica a les notes la data i la teva relació amb l'esdeveniment. Els terminis habituals són a el termini de validació de l'App Store.

Què torna a passar per revisió, i què no

Canvi	Què cal
Codi natiu, permisos, versió de l'SDK	Nou build, nova versió, revisió completa
Captures, descripció, paraules clau, novetats	Una nova versió, revisades amb ella
Text promocional	Res: canvia sense nou enviament
Pausa, represa, llançament per a tothom	Res: són ajustos de llançament
Capçalera de fitxa iOS 27	Sola a Asset Library, o amb una versió
Correcció JavaScript, amb Expo	Es pot fer una actualització remota

El text promocional canvia sense nou enviament, segons la pàgina d'informació de la versió. Amb Expo, una actualització remota canvia el JavaScript, els textos i les imatges sense passar per l'App Store. La documentació d'Expo hi posa dos límits: el codi natiu, els permisos i la versió de l'SDK exigeixen un nou binari, i les actualitzacions han de respectar les normes de l'App Store.

El meu cas: una correcció remota que el revisor no va veure mai

El setembre de 2026, un build de Nolera esperava la revisió. Havia corregit un error de la pantalla d'escaneig i havia publicat la correcció com a actualització remota durant l'espera. Tot i així, el build va ser rebutjat, per aquest error ja corregit.

L'explicació és a la documentació d'expo-updates: per defecte, l'app descarrega l'actualització en obrir-se i l'aplica a la següent obertura. El revisor instal·la l'app, l'obre una vegada i prova el codi inclòs al build. La mateixa regla val per als teus usuaris nous: la seva primera sessió funciona amb el codi del build.

Des de llavors, qualsevol canvi de la pantalla d'inici, del paywall o de la funció principal va en un nou build. L'actualització remota només serveix per a qui ja té l'app.

Posar la valoració a zero amb una versió

Cada nova versió ofereix l'opció Reset rating when this version is released. Segons l'ajuda d'Apple sobre el restabliment, s'aplica a tots els països, conserva les ressenyes escrites i no es pot desfer després del llançament. Apple aconsella fer-la servir amb moderació, perquè una fitxa amb poques valoracions pot desanimar.

La check-list abans d'enviar la teva actualització

• El número de versió és més alt i el build està incrementat.
• El build està provat a TestFlight, en un iPhone petit i en iPad si la teva app hi funciona.
• Les novetats estan escrites en cada idioma, i els canvis importants estan llistats.
• Les captures mostren la interfície actual si ha canviat.
• Les notes per al revisor diuen què ha canviat i on trobar-ho.
• L'opció de llançament està triada: manual si has de complir una data.
• El llançament progressiu està marcat si la versió toca el pagament o el primer inici.
• Saps si una possible correcció pot sortir en remot o si caldrà un build.

Superar la revisió a cada actualització

Cada actualització torna a passar per App Review, i un rebuig bloqueja la teva correcció. El Review Kit reuneix la meva checklist abans de l'enviament, els meus rebutjos corregits i dues skills de Claude Code que revisen el teu projecte i la teva fitxa, i preparen la teva resposta si Apple rebutja l'app. El recorregut complet és a la pàgina publicar una aplicació a l'App Store.

Si prepares el teu primer llançament, fes el teu diagnòstic gratuït: posa els passos en ordre i t'envia la meva checklist antirebuig d'Apple.

Preguntes freqüents

Quant dura el llançament progressiu a l'App Store?

Set dies: l'1 % dels usuaris amb actualització automàtica el primer dia, després el 2, el 5, el 10, el 20 i el 50 %, i el 100 % el setè. El pots posar en pausa fins a 30 dies en total, o acabar-lo en qualsevol moment amb Release to All Users.

Una actualització d'una app iOS torna a passar per la revisió d'Apple?

Sí. Cada nova versió, amb el seu build i les seves metadades, passa per App Review. El text promocional i els ajustos de llançament, en canvi, es poden modificar sense nou enviament.

Es pot tornar a la versió anterior d'una app a l'App Store?

No. Cal crear una nova versió, amb la correcció, i enviar-la a revisió. Per això són útils el llançament progressiu i la seva pausa.

Els usuaris nous reben l'actualització durant el llançament progressiu?

Sí, si descarreguen l'app des de l'App Store. El llançament progressiu només regula les actualitzacions automàtiques: qualsevol persona pot descarregar la nova versió en qualsevol moment.

Es pot activar el llançament progressiu després de l'aprovació d'Apple?

Sí, mentre la versió estigui en estat Pending Developer Release, és a dir, en llançament manual i encara no publicada. Un cop la versió ha sortit, ja és tard per a aquesta versió.

Què cal posar a les notes de versió d'una actualització?

Les funcions noves i els canvis importants, llistats clarament: és la norma 2.3.12. Per a una simple correcció d'errors, de seguretat o de rendiment, n'hi ha prou amb una fórmula genèrica. El camp accepta 4.000 caràcters i es tradueix a cada idioma.