En 2023, Apple revisó 1,76 millones de apps para el App Store. Rechazó casi dos tercios por una sola razón: rendimiento. No por diseño deficiente, no por problemas de privacidad. Por rendimiento. Por una app que se congela, que consume batería como si fuera un horno, que tarda cuatro segundos en abrir una pantalla que debería abrir en cero coma algo.
Eso no es un dato estadístico. Es una declaración de intenciones de Apple sobre qué tipo de software quiere en su ecosistema.
Qué significa «calidad» en el desarrollo iOS
La palabra calidad es de esas que todo el mundo usa y nadie define. En el contexto del desarrollo de apps para Apple, calidad tiene una traducción muy concreta: una app de calidad es aquella que hace exactamente lo que promete, sin que el usuario tenga que pensar en cómo hacerlo, y que lo hace igual de bien en un iPhone 16 Pro que en un iPhone 13 Mini con la batería al 20% y cinco apps abiertas en segundo plano.
Me explico: la calidad no es una capa que se añade al final del proceso. No es el momento en el que se «pule» la app antes de enviarla a revisión. Es una decisión que se toma en la primera línea de código y que se refleja en cada decisión de arquitectura, en cada llamada a red, en cada transición de pantalla.
Y aquí está el problema real: nadie te lo dice cuando empiezas. Nadie te advierte de que una arquitectura mal planteada en la primera semana de desarrollo se convierte en deuda técnica que pagarás durante años. Que un hilo principal bloqueado durante 16 milisegundos se nota. Que el usuario no sabe por qué la app «va pesada», pero lo siente, y desinstala.
El 17% que falló por diseño dice más de lo que parece
Volvamos a los datos. Un 17% rechazado por diseño. A primera vista parece poco, pero hay que entender qué significa «rechazado por diseño» en los criterios de Apple: interfaces que no cumplen las Human Interface Guidelines, navegación confusa, elementos que no responden al toque de forma esperada, texto ilegible en condiciones de luz real.
Diseño, en este contexto, no es si los colores son bonitos. Es si la app respeta los modelos mentales del usuario. Si donde el usuario espera un botón, hay un botón. Si el flujo de navegación sigue una lógica que alguien que no ha visto la app nunca pueda entender en menos de diez segundos.
Apple lleva décadas construyendo esas expectativas en sus usuarios. Cuando tu app las rompe, aunque sea ligeramente, el usuario siente que algo está mal aunque no sepa exactamente qué. Y esa sensación es difícil de superar con cualquier cantidad de funcionalidades nuevas.
La cultura de calidad que diferencia el ecosistema Apple
Hay una razón por la que una app bien construida para iOS tarda más en desarrollarse que una equivalente para otras plataformas. No es ineficiencia. Es estándar.
Apple ha creado en sus usuarios una expectativa de pulido que no existe de la misma forma en ningún otro ecosistema. Esa expectativa es simultáneamente la mayor exigencia para el desarrollador y su mayor ventaja competitiva. Porque si consigues construir algo que cumple ese estándar, tienes algo que el usuario va a querer pagar.
En AC Academy llevamos años viendo la diferencia entre desarrolladores que entienden esto desde el principio y los que lo descubren tarde. Los primeros construyen con cuidado desde el primer commit. Los segundos pasan los últimos meses de desarrollo intentando reparar decisiones que tomaron cuando aún no entendían las consecuencias.
La calidad no es el objetivo final del desarrollo. Es la condición de partida.
Qué hacer con esta información
Si estás desarrollando ahora mismo una app o si estás aprendiendo a hacerlo, guarda estos tres principios:
El hilo principal es sagrado. Nunca hagas trabajo pesado en el hilo principal. Cualquier operación que pueda tardar más de unos pocos milisegundos va al fondo, en concurrencia. Si aún no dominas async/await en Swift, eso es lo primero que tienes que resolver.
Mide antes de optimizar. Instruments existe para algo. Usa el Time Profiler antes de decidir que algo «va lento». El cuello de botella casi nunca está donde crees que está.
El diseño no empieza en Figma. Empieza en las Human Interface Guidelines de Apple. Son públicas, están actualizadas y son el documento más valioso que un desarrollador iOS puede leer antes de abrir Figma.
El 64% de los rechazos por rendimiento no es un problema de habilidad técnica. Es un problema de cultura. Y la cultura se construye desde el primer día.
