TL;DR. Los pre-pedidos te dejan publicar en App Store Connect la product page de una app todavía no lanzada hasta 180 días antes del release, recoger compromisos de compra y entregar cada pre-pedido como una descarga automática única en el momento en que llega tu fecha de release. Solo funciona para apps que nunca se han lanzado en ese país o región — no puedes poner en pre-pedido una actualización de algo que ya está en vivo. Si estás planeando un lanzamiento, los pre-pedidos concentran tus instalaciones del día uno en un solo momento en lugar de repartirlas a lo largo de la primera semana, que es justo lo contrario de lo que hace el lanzamiento por fases.
La mayoría de los developers indie lanzan una app nueva siempre de la misma forma: enviar, conseguir la aprobación, activar el release, y luego pasar el día de lanzamiento actualizando App Store Connect y esperando que el tráfico de Product Hunt convierta. Los pre-pedidos son el mecanismo que te deja generar demanda antes de que ese día siquiera llegue — y casi nadie fuera de los estudios de gaming los usa.
¿Con cuánta antelación se pueden abrir pre-pedidos en el App Store?
Para una app completamente nueva que nunca se ha lanzado en un país o región determinado, puedes fijar una fecha de release esperada hasta 180 días antes. Si tu app ya está en vivo en al menos otra región y estás abriendo pre-pedidos para una región nueva, esa ventana se extiende a 365 días.
Esto se activa en App Store Connect, en la sección de precios y disponibilidad de la app, antes de que la app haya estado alguna vez en «Lista para la venta» en esa ubicación. Una vez que una app se ha lanzado para descarga en un país o región, queda permanentemente inelegible para pre-pedido ahí — no puedes usar pre-pedidos para una actualización de versión mayor ni para relanzar algo que los usuarios ya pueden descargar.
¿Las descargas de pre-pedido pasan todas a la vez o de forma gradual?
Todas a la vez. En la fecha de release que fijaste, cada cliente que hizo un pre-pedido recibe una notificación y la app se descarga automáticamente en su dispositivo (asumiendo que las descargas automáticas están activadas) — no hay entrega escalonada. Eso es lo opuesto al lanzamiento por fases, que reparte el rollout de una actualización entre los usuarios existentes a lo largo de un calendario de 7 días basado en porcentajes. Los pre-pedidos son un mecanismo para concentrar un primer lanzamiento; el lanzamiento por fases es un mecanismo para reducir el riesgo de uno posterior. No los confundas.
Esa concentración es justamente el punto. Un conjunto de compromisos de pre-pedido que se convierten todos en descargas dentro de las mismas 24 horas produce exactamente el tipo de pico de instalaciones en un solo día que las superficies de descubrimiento del App Store — como «New Apps We Love» — están diseñadas para detectar. Apple no publica la ponderación exacta, pero un lanzamiento repartido de forma tenue a lo largo de una primera semana lenta es una señal materialmente distinta al mismo número total de instalaciones cayendo en un solo día.
¿Qué pasa con la fecha de release si tus planes cambian?
Puedes editarla en cualquier momento antes de que pase en un país o región determinado — no hay límite de cuántas veces. La nueva fecha solo tiene que quedarse dentro de la ventana de elegibilidad original: dentro de los 180 días desde la primera publicación del pre-pedido para un primer lanzamiento, o dentro de los 365 días si una app se está expandiendo a una región nueva. Una vez que la fecha de release pasa en una región, queda bloqueada — ya no puedes moverla ahí, aunque la versión todavía no esté aprobada.
El precio tiene su propia regla durante esta ventana: si bajas el precio después de que alguien ya hizo un pre-pedido, se le cobra el precio más bajo en el release, no el precio que aceptó originalmente. Subir el precio no le cobra más, de forma retroactiva, a los pre-pedidos existentes — solo aplica a los pre-pedidos nuevos hechos después del cambio. A nadie se le cobra nada hasta la fecha de release en sí; un pre-pedido es un compromiso, no una transacción.
Enviar y actualizar tu build durante el periodo de pre-pedido
Tu app igual tiene que pasar App Review antes de que el listado de pre-pedido salga en vivo — no puedes publicar una página de pre-pedido para un build que no ha sido aprobado. Una vez que está en vivo, puedes enviar versiones nuevas durante la ventana de pre-pedido de la misma forma que lo harías para cualquier app ya lanzada: elige release automático, manual o programado. La versión que esté aprobada y liberada cuando llegue la fecha de pre-pedido es la que recibe cada cliente — así que si estás iterando tu build hasta justo antes del lanzamiento, asegúrate de que tu envío final esté liberado (no atascado en «Pending Developer Release») antes de que llegue la fecha de release, o los clientes recibirán un build más viejo del que pretendías.
Dos vacíos de elegibilidad más que vale la pena conocer antes de planear en torno a esto: las compras dentro de la app independientes no se pueden poner en pre-pedido por su cuenta, y los bundles de apps son completamente inelegibles para pre-pedido — un bundle requiere que cada app dentro de él ya esté Lista para la venta en al menos una región.
Antes de configurar un pre-pedido
- Confirma que la app nunca se ha lanzado para descarga en el país o región donde estás abriendo pre-pedidos — esto solo funciona para disponibilidad genuinamente nueva, no para relanzamientos.
- Elige una fecha de release que realmente puedas cumplir. Puedes moverla más adelante dentro de la ventana de elegibilidad, pero una vez que pasa en una región, queda bloqueada.
- Trata el envío final de tu build antes del lanzamiento como una fecha límite dura — configura la opción de release en automático o libérala manualmente con varios días de margen, para que una versión aprobada-pero-no-liberada no le llegue desactualizada a todo el mundo el primer día.
- Si tu subtítulo, campo de keywords o screenshots no están terminados, termínalos antes del envío — salen en vivo con el mismo build que recibe cada cliente de pre-pedido, todos a la vez, sin segunda oportunidad de un rollout lento.