Rogelio Nava hizo en Toluca una app para llevar la tanda de su cuadra: quién ya puso lo de la semana, a quién le toca el número siguiente, cuánto falta para cerrar la vuelta. La probó tres semanas en su propio teléfono, sobre el escritorio, y nunca perdió una palomita. La primera semana que estuvo pública, el reclamo que llegó una y otra vez fue que se le olvidaban los pagos marcados.
Su teléfono estaba conectado a la corriente y con la pantalla prendida. Los de las señoras de la tanda estaban en una bolsa, con 3 GB de memoria y catorce aplicaciones abiertas, recibiendo llamadas.
Ahí está toda la diferencia entre este tema y el que tiene al lado. Una página web se pide y se entrega. Una app se instala en un aparato al que le falta pila, le falta atención y tiene permiso de apagarla sin avisarle, y los cinco temas de abajo son consecuencia de eso.
Lo que el escritorio nunca enseña
Las dos plataformas tratan una app en segundo plano como memoria que se puede recuperar. El sistema mata la app en segundo plano y la app tiene que reconstruirse con lo que guardó. No pausada, ni suspendida de una manera que sobreviva: terminada, con su memoria devuelta al sistema, y vuelta a lanzar después en la pantalla que ella misma diga que estaba. Si la app no dejó escrito qué pagos venían palomeados, esos pagos no existieron.
La reparación de Rogelio fueron once líneas: escribir el estado de la tanda en el almacén de claves y valores del aparato en el momento en que cambia, leerlo de vuelta al arrancar, y tratar la copia en memoria como un caché de eso y no como la verdad. La regla se extiende a cualquier dato que una app sostenga. Lo que no quedó escrito se pierde la primera vez que alguien contesta una llamada.
Esto es invisible en las pruebas por una razón mecánica: un teléfono conectado a una laptop con un depurador corriendo está explícitamente protegido de ese comportamiento. La plataforma no recupera una app que le están pidiendo inspeccionar, así que el arreglo de desarrollo suprime justo la falla que el aparato está diseñado para producir.
Y de este lado del mapa el asunto pega más fuerte, porque el teléfono de quien programa casi siempre es más nuevo que el de quien usa. Un aparato con 3 o 4 GB de memoria recupera una app en segundo plano muchísimo antes que uno de gama alta, así que la falla es rara sobre el escritorio y constante en la bolsa. El parque de teléfonos de este mercado es en su enorme mayoría de gama media y baja, y probar únicamente en el propio equipo es probar en el percentil equivocado.
Dos números que deciden un acomodo
Un puntero sobre un escritorio es un píxel y un dedo no lo es. 44 puntos en iOS y 48 píxeles independientes de densidad en Android es el piso de un objetivo tocable, y los dos números son la guía publicada de cada plataforma, no el gusto de alguien. No son medidas en píxeles. Un punto y un píxel independiente de densidad son unidades que conservan el mismo tamaño físico en pantallas de distinta nitidez, que es la razón entera de que existan, y un acomodo escrito en píxeles crudos es un acomodo que se encoge justo en los teléfonos más caros.
Los renglones de la lista de Rogelio medían 32 puntos, porque así se veía bien en el tamaño que le mostraba su herramienta de diseño. En un teléfono, uno de cada seis toques caía en el renglón vecino, y las señoras que le atinaban al vecino no reportaron un error. Reportaron que la app marcaba pagos que no eran, que es la forma en que llegan casi todas estas fallas y la razón de que el diseño para el teléfono sea un tema y no una nota al pie.
Escribirla una vez o dos veces, y quién decide de verdad
La pregunta que domina el tema es si se escribe una vez o dos. Es una pregunta real con una respuesta real, y la respuesta depende de cuánto del aparato toca la app. Una que muestra listas, formularios y texto se escribe una vez y se manda a las dos tiendas a un costo muy cercano a la mitad. Una construida alrededor de la cámara, de la ubicación en segundo plano, de un widget en la pantalla de inicio o de cualquier cosa que la plataforma sacó el otoño pasado, no: un código y dos tiendas, y la novedad de la plataforma llega tarde, porque el puente hacia ella lo tiene que escribir alguien después de que la plataforma la publica.
La app de Rogelio son listas y una suma, así que la respuesta compartida de multiplataforma era la correcta para él. Habría sido la equivocada para una app que despierta sola cuando llega el día de pago, y esa equivocación no se habría visto hasta el cuarto mes.
Una versión
La compilación es la primera de cinco puertas y la única hecha de código
El ancho de cada banda es la cuenta de Rogelio para su primera versión, escalada a cien, así que la caída es el dato: la pérdida más grande está entre instalada y abierta por segunda vez.
- Compila en la máquinaLa puerta en la que termina todo tutorial, y la más barata de las cinco100
- Pasa la revisiónRechazada una vez por un permiso pedido en la puerta, y eso costó cuatro días71
- Alguien la encuentra en la tiendaUna ficha es un resultado de búsqueda antes de ser una app34
- Se instalaDonde casi toda medición se detiene, y donde todavía no ha pasado nada19
- Se abre una segunda vezEl primer número honesto, y el que la tanda olvidada estaba destruyendo6
Son los números de una app chica en su primera versión llevados a cien, no una cifra del sector. La forma es la afirmación: cuatro de las cinco puertas se cruzan después de que el código está terminado.
La fila que no es código, y lo que cuesta formarse en ella
Publicar una app no es desplegar. Hay una revisión, es una fila, y la fila tiene una forma que conviene conocer antes de la primera entrega y no después. Un rechazo devuelve la app al final de la fila de revisión, así que el costo de una entrega descuidada se mide en días y no en los diez minutos que toma corregir lo que estuviera mal. Los rechazos comunes no son sutiles: falta la declaración de privacidad, hay un acceso por el que el revisor no puede pasar, o la app pide un permiso que nunca se ve usar.
Los números de su primera versión, llevados a cien, dicen dónde se pierde de verdad una publicación. De 100 compilaciones que corrieron en su propia máquina, 71 pasaron la revisión, 34 fueron encontradas por alguien buscando en la tienda, 19 quedaron instaladas y 6 se abrieron una segunda vez. Cuatro de esas cinco puertas se cruzan después de que el código está terminado, y la caída más grande es la última.
Formarse en esa fila cuesta dinero, y aquí conviene decir las cifras porque llegan en dólares y ninguna guía en español las pone junta. En 2026, Apple cobra USD 99 al año por la cuenta de desarrollador y Google USD 25 una sola vez. La de Google se paga y se olvida; la de Apple se renueva o la app desaparece de la tienda. A ambas hay que sumarles el IVA de servicios digitales del exterior, 16% en México y 19% en Colombia, y el tipo de cambio del día. Ninguna de las dos está bloqueada ni pide nada que una tarjeta de la región no tenga.
El costo grande no es la cuenta. Xcode corre solamente en macOS, así que compilar para iOS obliga a comprar un equipo, y ese equipo se cotiza en dólares. Es una decisión de hardware tomada por una herramienta de software, y conviene enterarse antes de empezar y no en el mes ocho.
Dónde se atora, y qué abrir en 2026
El atasco es la segunda plataforma, y es un problema de dinero disfrazado de problema técnico. Alguien publica en Android, que es la enorme mayoría de los teléfonos de este mercado, consigue usuarios, y descubre que el gasto está del otro lado, en la minoría que no lo es. Llegar ahí significa el equipo, la cuenta anual y un segundo juego de convenciones de plataforma, y eso no se resuelve estudiando un fin de semana. Es el punto en que un proyecto de rato libre se convierte en un presupuesto o se detiene.
Android Studio compila para Android en los tres sistemas de escritorio, es gratis y reemplazó a Eclipse con el complemento de Android, que es lo que siguen mostrando los tutoriales anteriores a 2015 más o menos. Xcode también es gratis; lo que no es gratis es la máquina que lo corre y la cuenta que publica.
Para el camino compartido, Flutter y React Native son las dos opciones serias y se dividen por lo que uno ya sabe: React Native si el equipo escribe JavaScript, y Flutter si no lo escribe y prefiere aprender una sola cosa que se comporte igual en las dos plataformas. Las dos reemplazaron a la generación anterior de herramientas, que metía un sitio web adentro de una cáscara de app, un enfoque que a veces sigue siendo correcto y que la gente alcanza a sentir. Las dos son gratis y de código abierto, y ninguna tiene traba de descarga desde México ni desde Colombia.
Hay un renglón más que en este mercado pesa y en la edición en inglés no aparece: el tamaño de la instalación. En un teléfono de 64 GB que ya vive lleno, una app de 90 MB se desinstala para hacerle espacio a un video, y eso ocurre en la puerta cinco del embudo, después de todo el trabajo. Medir el tamaño del paquete es tan parte del oficio como medir el arranque.
Lo que nada de esto resuelve es cómo se paga la app a sí misma, que cambia el diseño de la cosa y no solamente su facturación, y es la discusión de la monetización de una app. Se parece a la misma pregunta hecha del lado del navegador en el desarrollo web, y lo que decide cuál de las dos abrir primero es dónde tiene que correr el código, que es el reparto de programación.