Respuesta breve
Primero comprueba que el producto necesita una app y no una web móvil: la justifican las notificaciones, el uso sin conexión, los sensores o la tienda. Después elige cómo construirla (nativa, multiplataforma o con un constructor sin código), reduce la primera versión a un usuario y un escenario, prueba un prototipo navegable, planifica el servidor, abre las cuentas de desarrollador a tu nombre y reserva tiempo para la revisión y las actualizaciones.
Comprueba primero si la idea necesita de verdad una app
Quien busca cómo crear una app suele haber decidido ya que la respuesta es una app. Esa decisión merece una hora más, porque la web ha aprendido mucho. MDN, la referencia de Mozilla para desarrolladores web, describe una aplicación web progresiva como una hecha con tecnologías web que se comporta como una app específica de plataforma. Según su descripción, puede instalarse, funcionar sin conexión y mostrar notificaciones del sistema, todo con un solo código.
Una app de plataforma, en la lista de MDN, tiene por naturaleza integración con el sistema operativo, acceso a la cámara, el GPS o el acelerómetro y distribución en la tienda. En un iPhone el límite se nota enseguida: el equipo de WebKit escribió en febrero de 2023 que las push web llegaron con iOS 16.4, para las apps web que el usuario ha añadido a la pantalla de inicio. Si el producto vive de avisos diarios, sensores o presencia en la tienda, haz una app. Si la gente lo abre dos veces al año, una web móvil le sirve mejor.
Tres formas de construirla: nativa, multiplataforma o constructor sin código
Una app nativa se escribe por separado para cada plataforma con las herramientas de su dueño: un proyecto para iPhone y otro para Android. Pagas dos bases de código y obtienes el acceso más completo a cada sistema. La segunda forma es un solo código para ambos. El sitio de Flutter describe un framework para crear aplicaciones compiladas de forma nativa a partir de una única base de código; el de React Native dice: escrito en JavaScript, renderizado con código nativo. Un solo equipo cuesta menos, pero una función nueva de la plataforma puede llegarte más tarde.
La tercera forma es un constructor sin código: montas pantallas con bloques ya hechos y el servicio genera la app. Es la vía más rápida hacia algo que un cliente pueda tocar, y una manera sensata de probar la demanda. La directriz 4.2.6 de las App Review Guidelines de Apple dice que las apps creadas a partir de una plantilla comercializada o de un servicio de generación de apps serán rechazadas salvo que las envíe directamente el proveedor del contenido. Por eso la app se publica desde tu propia cuenta de desarrollador, no desde la del constructor.
La primera versión: un usuario y un escenario de principio a fin
La primera versión no es una copia pequeña del sueño. Es una persona que hace una sola cosa desde la primera pantalla hasta el resultado: una clienta reserva un corte de pelo, un repartidor cierra una entrega, un padre paga una clase. Escribe ese escenario como una secuencia de pantallas y tacha todo aquello sin lo cual la persona puede vivir un mes. Lo que queda es el camino más corto entre abrir la app y el resultado.
Las tiendas premian esa disciplina. La página de Apple sobre App Review dice que, de media, más del 40 % de las incidencias sin resolver se refieren a la directriz 2.1, App Completeness, que abarca cierres inesperados, contenido de relleno e información incompleta. Una primera versión estrecha tiene menos rincones a medio hacer. También llega antes a personas reales, y su comportamiento en la primera semana responde preguntas que ninguna reunión de planificación resuelve.
Diseño antes que código: prototipo navegable y normas de interfaz de cada plataforma
El código es el lugar más caro para cambiar de opinión. Por eso el escenario se convierte primero en pantallas sencillas, y las pantallas en un prototipo navegable: una maqueta que se abre en el teléfono y se puede tocar. Dáselo a cinco personas que se parezcan a tu usuario y observa dónde se detienen. Un tropiezo encontrado aquí cuesta una hora de diseño; el mismo tropiezo después del lanzamiento cuesta una ronda de desarrollo y otra revisión en la tienda.
Las dos plataformas publican cómo deben verse y comportarse sus apps. Las Human Interface Guidelines de Apple se presentan como orientación y buenas prácticas para diseñar una gran experiencia en cualquier plataforma de la marca. La documentación de Android para desarrolladores presenta Material Design 3 como un sistema abierto y adaptable de pautas, componentes y herramientas. Pregunta al diseñador qué componentes estándar usa la app, porque cada control hecho a medida supone más diseño, más código y una cosa más que el usuario debe aprender.
El servidor que nadie ve: cuentas, datos, pagos y notificaciones
Lo que el usuario tiene en la mano es la mitad del producto. La otra mitad vive en un servidor: clientes, calendario, pedidos y un panel de administración para tu equipo. Cuando un presupuesto parezca sorprendentemente bajo, comprueba si incluye esta parte. Las cuentas también traen reglas: la directriz 5.1.1 de las normas de revisión de Apple dice que una app que permite crear cuentas debe ofrecer además su eliminación dentro de la app, y que toda app debe enlazar su política de privacidad. Lo que exige tu ley sobre datos personales es una pregunta para un abogado.
Los pagos se dividen en dos. Según la directriz 3.1.1 de Apple, desbloquear funciones o contenido dentro de la app exige la compra integrada; según la 3.1.3(e), los bienes físicos y los servicios que se consumen fuera de ella se cobran con otros métodos. La política de pagos de Google Play traza una línea parecida. Por eso un estudio de yoga con clases en sala y un servicio de lecciones en vídeo construyen cobros distintos. Las notificaciones también tienen regla: la directriz 4.5.4 solo admite promociones por push cuando el cliente las ha aceptado expresamente.
Publicación: cuentas de desarrollador, prueba cerrada de Google y revisión de las tiendas
Para publicar necesitas una cuenta de desarrollador en cada tienda, y debe ser tuya, no del proveedor. La página de inscripción de Apple fija el Apple Developer Program en 99 dólares estadounidenses por año de membresía. La ayuda de Google Play Console, consultada en octubre de 2026, indica una tarifa única de 25 dólares estadounidenses. Una cuenta personal creada después del 13 de noviembre de 2023 debe además realizar una prueba cerrada con al menos 12 probadores durante 14 días seguidos antes de solicitar el acceso a producción. Ambas compañías cambian estas condiciones: abre las páginas el día en que te registres.
Después llega la revisión. Apple afirma que App Review suele resolver al menos la mitad de los envíos en menos de 24 horas y el 90 % en menos de 48. Google advierte de que en ciertas cuentas de desarrollador la revisión puede tardar hasta siete días, o más en casos excepcionales. Un rechazo no es una sentencia: Apple indica la directriz que no se cumplió y permite responder o apelar, y Google deja corregir y volver a enviar. Planifica el lanzamiento con una semana de margen.
La vida tras el lanzamiento: actualizaciones del sistema, informes de fallos, reseñas y soporte
Una app no se termina el día del lanzamiento: las plataformas se mueven. La ayuda de Google Play sobre el nivel de API objetivo dice que desde el 31 de agosto de 2026 las apps nuevas y las actualizaciones deben apuntar a Android 16. La lista de requisitos de Apple dice que desde el 28 de abril de 2026 las apps subidas a App Store Connect deben compilarse con Xcode 26 o posterior. Las cifras serán otras el año que viene; el patrón, no. Cada año, más o menos, alguien debe recompilar y reenviar la app aunque en tu negocio no cambie nada.
La calidad también te la miden. La documentación de Android describe Android vitals, métricas de calidad recogidas en los dispositivos de los usuarios, y fija un umbral del 1,09 % para la tasa de fallos percibidos por el usuario. Por encima, Google Play puede reducir la visibilidad de la app y mostrar una advertencia en su ficha de la tienda. Las reseñas son públicas: Apple señala que, cuando el desarrollador responde, quien escribió la reseña recibe un aviso y puede actualizarla. Reserva presupuesto para alguien que lea los informes de fallos y conteste a los usuarios cada semana.
Qué preparar antes de encargar una app y cómo elegir el primer alcance
Antes de encargarla, pon cuatro cosas por escrito. El usuario y el único escenario de la primera versión, descrito por pasos. La respuesta a la pregunta de web o app, con su motivo: notificaciones, uso sin conexión, un sensor, la tienda. La lista de lo que ocurre en el servidor, desde las cuentas y los pagos hasta el panel de administración. Y los nombres que figuran en las cuentas de desarrollador. Con esa hoja cualquier proveedor puede dar una estimación comparable, y tú ves cuál la ha leído de verdad.
Hacerlo por tu cuenta es realista cuando la tarea es probar la demanda con un constructor sin código o una web móvil. Encargarlo tiene sentido cuando la app maneja dinero o datos personales, debe funcionar en las dos plataformas o cuando nadie de tu lado puede hacerse cargo de las actualizaciones anuales. VITON13 Studio es uno de los sitios que asumen este trabajo; los freelances y los equipos propios son otros. Elijas lo que elijas, la pregunta de cómo crear una app se hace mucho más pequeña cuando el primer escenario cabe en una página.
Lista práctica
- Escribe el único escenario de la primera versión como una lista numerada de pantallas.
- Decide entre una web móvil y una app, y anota el motivo de esa elección.
- Abre las cuentas de desarrollador de Apple y Google a tu nombre o al de tu empresa.
- Enumera lo que debe hacer el servidor: cuentas, datos, pagos, notificaciones y panel de administración.
- Deja por escrito quién recompila la app cuando Android e iOS cambian sus requisitos.
Preguntas frecuentes
¿Puedo crear una app si no sé programar?
Sí, de dos maneras. Con un constructor sin código montas tú una app sencilla, suficiente para probar la demanda. Para todo lo que lleve pagos, datos personales o dos plataformas contratas a quien programa, y tu trabajo pasa a ser el escenario, el contenido y las decisiones. En ambos casos las cuentas de desarrollador deben estar a tu nombre.
¿Cuánto tarda la revisión de una app nueva en las tiendas?
Apple afirma que App Review suele atender al menos la mitad de los envíos en menos de 24 horas y el 90 % en menos de 48. Google dice que algunas cuentas reciben una revisión más larga, de hasta siete días o más en casos excepcionales. Una cuenta personal nueva de Google Play debe terminar antes su prueba cerrada de 14 días, y la ayuda de Play Console indica que la revisión de la solicitud de acceso a producción suele tardar siete días o menos.
¿Basta una aplicación web progresiva en lugar de una app en las tiendas?
A menudo sí, para una primera versión. MDN describe apps web que se instalan, funcionan sin conexión y envían notificaciones con un solo código. Los límites aparecen en el iPhone, donde las push web exigen que el usuario añada antes la app web a la pantalla de inicio, y en el descubrimiento: quien busca en una tienda no encuentra un producto que no figura allí.
¿A nombre de quién van las cuentas de desarrollador: del fundador o del proveedor?
Del fundador o de su empresa. La página de inscripción de Apple dice que el nombre de la cuenta se muestra como vendedor en la tienda, y quien tiene la cuenta controla cada actualización. Una organización debe ser una entidad legal con número D-U-N-S y un sitio web en funcionamiento, así que empieza ese trámite antes del desarrollo y no en la semana del lanzamiento.
¿Por qué una app terminada necesita actualizaciones todos los años?
Porque las plataformas se mueven. Google Play exige que las apps nuevas y las actualizaciones apunten a una versión reciente de Android, y Apple exige compilaciones hechas con una versión reciente de sus herramientas. Suma la corrección de fallos y las respuestas a las reseñas, y el mantenimiento pasa a ser una línea fija del plan en vez de una sorpresa del segundo año.