06 Servicio
Apps para iPhone y iPad que pasan la revisión de Apple a la primera.
Aplicaciones iOS listas para el App Store. La guía de revisión de Apple, las etiquetas de privacidad y las pruebas con usuarios reales corren por nuestra cuenta.
Empecemos por lo que conviene no construir
Si lo que necesitás es un portal de clientes, un catálogo o un formulario para consultar y cargar datos, lo más probable es que no te haga falta una app de iPhone. Una web que se instala —una PWA— cubre ese caso, se actualiza sin pasar por ninguna revisión y no te ata a una cuota anual.
Vale una advertencia honesta que casi nadie hace: en iOS las PWA tienen menos permisos que en Android y las notificaciones push funcionan sólo si el usuario agregó el ícono a la pantalla de inicio. Si las notificaciones son el corazón de lo que querés hacer, ahí sí la app nativa deja de ser una preferencia y pasa a ser la respuesta. Igual que si necesitás cámara a fondo, Bluetooth, o estar en el App Store porque es donde tus usuarios buscan.
La revisión de Apple, que es la parte que asusta
Toda app que entra al App Store la mira una persona. Esa revisión es el motivo por el que publicar en iOS se percibe como difícil, y la percepción no es injusta: un rechazo no es un mensaje de error, es un texto que hay que interpretar, corregir y volver a mandar, y cada vuelta come días.
La buena noticia es que los motivos de rechazo se repiten y son evitables si se diseñan bien desde el principio. Los que más aparecen:
- La app se cae o tiene funciones a medio terminar. Apple prueba a mano: un botón que no hace nada se ve.
- Es un envoltorio de un sitio web y no aporta nada propio del teléfono. Este es el rechazo clásico de quien quiso ahorrar empaquetando la web.
- Pide registro o datos personales sin necesidad real, o permite crear cuenta pero no borrarla desde la misma app.
- Cobra contenido digital por fuera del sistema de pagos de Apple, cuando ese contenido no está exento.
- Los textos de los permisos —ubicación, cámara, contactos— no explican con claridad para qué se usan.
- Las capturas o la descripción prometen algo que la app no hace, o muestran pantallas que ya no existen.
Nuestro trabajo acá es leer la guía de revisión mientras se diseña la app y no después de que la rechazaron: cuando llega la entrega, la política de privacidad, las etiquetas de datos, el borrado de cuenta y los textos de permisos ya están resueltos. No podemos prometer que Apple nunca va a objetar nada —nadie puede, y el que lo promete te está mintiendo—, pero sí que el camino de vuelta lo manejamos nosotros y está contemplado en el plazo.
TestFlight: probar con gente antes de publicar
Antes de mandar nada al App Store, la app va a TestFlight, el sistema de Apple para repartir versiones de prueba. Se instala en los teléfonos de tu equipo y de un grupo de clientes sin pasar por la tienda, y con eso aparecen dos clases de hallazgo que no salen de ninguna otra forma.
La primera son los errores de manos ajenas: la app anda perfecto con quien la escribió y se rompe con quien toca en otro orden, tiene el teléfono en otro idioma o nunca le dio permiso a la cámara. La segunda es más valiosa y más incómoda: la pantalla que a vos te parecía evidente, para otro no lo es. Es información barata ahora y carísima después.
Las versiones de TestFlight caducan a los 90 días, así que es un paso previo y no un reemplazo de la publicación. Pero es el paso que más rechazos evita, porque a la revisión de Apple no llega la primera compilación que funciona: llega una versión que ya usaron personas de verdad.
Qué construimos
Apps de operación y de producto: portales para equipos en la calle, herramientas internas, la versión iPhone de un sistema que ya existe, y productos digitales donde la app es el negocio y no un accesorio. También la versión iPad cuando el trabajo se hace sentado y la pantalla grande cambia el diseño —un mostrador, una obra, un consultorio—, que no es "la misma app más grande" sino otra disposición de la misma información.
Lo que cuesta tener una app en el App Store
Dos cosas que conviene saber antes de empezar y no a mitad de camino. La primera es la membresía: no se paga una vez, se paga todos los años, y si dejás de pagarla la app sale del App Store aunque siga instalada en los teléfonos que ya la tienen. La segunda es la Mac: las herramientas de Apple para compilar y firmar sólo corren en macOS. La ponemos nosotros, así que para vos no cambia nada hoy, pero sí importa si en algún momento querés mover el proyecto a un equipo interno.
El Apple Developer Program cuesta USD 99 por año. Al momento de escribir esto, la membresía se renueva anualmente y la app deja de estar disponible si la renovación no se paga. La cuenta se abre a nombre de tu empresa: la app, las reseñas y los usuarios son tuyos, no de quien la programó.
Con qué está hecho
Swift cuando la app es sólo para iPhone o busca la última gota de fluidez y de integración con el sistema. React Native cuando también hay versión Android en el plan, porque comparte la mayor parte del código y hace que una función nueva se escriba una vez en vez de dos.
La decisión sale de una pregunta que conviene contestar el primer día: ¿esta app va a tener que existir también en Android? Si la respuesta es sí, decirlo tarde es lo que obliga a empezar de nuevo.
Preguntas frecuentes
¿Cómo se publica una app en el App Store?
Hacen falta cuatro cosas: una membresía del Apple Developer Program (USD 99 por año, al momento de escribir esto), una Mac para compilar y firmar el paquete, una ficha completa en App Store Connect —capturas por cada tamaño de pantalla, descripción, ícono, política de privacidad y las etiquetas de privacidad que declaran qué datos recolecta la app— y pasar la revisión humana de Apple. Apple no publica plazos garantizados, pero para una app que cumple las normas la revisión suele resolverse en uno o dos días hábiles; lo que estira el calendario no es la espera sino el ida y vuelta cuando hay un rechazo. Por eso conviene mandar a revisión una app que ya fue probada con usuarios reales en TestFlight, y no la primera compilación que anda.
¿Por qué Apple rechaza apps y cómo se evita?
Los motivos que más se repiten son previsibles y casi todos se resuelven antes de mandar nada. Apple rechaza apps que se caen o tienen funciones a medio terminar; apps que son un envoltorio de un sitio web sin nada propio del teléfono; apps que piden registro o datos personales sin necesidad real, o que no ofrecen forma de borrar la cuenta desde la misma app cuando permiten crearla; apps que cobran contenido digital por fuera del sistema de pagos de Apple; apps con permisos —ubicación, cámara, contactos— cuyo texto explicativo no dice con claridad para qué se usan; y apps con capturas o descripción que no coinciden con lo que la app hace. La forma de evitarlo es leer la guía de revisión durante el diseño y no después, y llegar a la entrega con la política de privacidad, las etiquetas de datos y el borrado de cuenta ya resueltos. De eso nos ocupamos nosotros.
¿Qué es TestFlight y para qué sirve?
Es el sistema oficial de Apple para repartir versiones de prueba antes de publicar. Instalás la app en los teléfonos de gente real —tu equipo, un grupo de clientes— sin pasar por el App Store, con hasta 100 probadores internos y hasta 10.000 externos una vez que la compilación pasa una revisión de beta más liviana que la de publicación. Sirve para dos cosas distintas: encontrar los errores que sólo aparecen en manos ajenas, y descubrir que una pantalla que te parecía obvia no se entiende. Cada versión de prueba caduca a los 90 días, así que no reemplaza a la publicación: es el paso de antes. Trabajamos así siempre, porque corregir algo en TestFlight sale infinitamente más barato que corregirlo con la app publicada y una reseña de una estrella arriba.
¿Cuánto cuesta mantener una app para iPhone por año?
Hay tres costos distintos y conviene no mezclarlos. El primero es la membresía del Apple Developer Program: USD 99 por año, y si dejás de pagarla la app desaparece del App Store, aunque siga instalada en los teléfonos que ya la tienen. El segundo es el servidor y los servicios donde viven los datos, que depende de cuánta gente la use. El tercero es el mantenimiento del código: Apple saca una versión nueva de iOS todos los años y de tanto en tanto cambia requisitos —una versión mínima de las herramientas de compilación, un permiso nuevo, una regla de privacidad—, así que una app que no se toca durante dos años termina necesitando trabajo aunque nadie le haya pedido una función nueva. Lo presupuestamos aparte y por escrito, para que no aparezca como sorpresa.
¿Se puede hacer una app de iPhone sin tener una Mac?
Para desarrollarla podés usar cualquier computadora, pero para compilar, firmar y subir la app al App Store hace falta macOS. No es una preferencia: las herramientas de Apple sólo corren ahí. Las salidas son alquilar un servicio de compilación en la nube, que funciona bien pero agrega un costo mensual y complica la depuración, o tener una Mac. Para vos como cliente esto es indistinto —la Mac la ponemos nosotros—, pero sí importa si en algún momento querés llevarte el proyecto a un equipo interno: ese equipo va a necesitar al menos una Mac y la membresía a nombre de tu empresa. Lo aclaramos antes para que no sea un descubrimiento incómodo más adelante.
¿Esto es lo que necesitás?
El primer paso es una reunión de una hora y un documento: qué duele, qué se puede automatizar y qué conviene no construir. Sin costo y sin compromiso.