Tabla de contenidos
El iceberg del desarrollo de apps
¿Alguna vez has intentado desarrollar una aplicación móvil?
Flutter, React Native, juegos para móvil con Unity o Unreal Engine, Android Studio, Xcode, Cordova o .NET. No importa qué framework utilices para crear tus apps, todos ellos comparten una serie de problemas inherentes a las plataformas móviles con los que seguramente ya te has enfrentado.
El desarrollo de aplicaciones móviles es un iceberg del que sólo es visible la parte más superficial, que es escribir el código fuente en una de las tecnologías que acabamos de mencionar.
Pero, ¿cuáles son las dificultades que oculta el desarrollo móvil bajo el nivel del mar? ¿Por qué se retrasa tanto el lanzamiento de aplicaciones móviles aun cuando el código está ya terminado? ¿Están las élites de la humanidad conspirando para que no termines tu aplicación de botones con sonidos en Android Studio?
Soy Carlos Sala, desarrollador de software, y el desarrollo de aplicaciones móviles es un infierno.
Las dependencias: el castillo de naipes
Cada día, las herramientas con las que los programadores creamos las aplicaciones para móvil son más potentes. Es decir, con menos conocimientos y esfuerzo podemos construir aplicaciones más complejas.
Los equipos de Flutter, React Native y el resto de frameworks, desarrollan una API de funcionalidades reutilizables para que la gente como tú y yo hagamos uso de ellas en nuestras aplicaciones. Pero, ¿sabías que estos frameworks dependen a su vez de otras muchas librerías de código escrito por otros desarrolladores?
La fragilidad de las dependencias
Cuando las dependencias que utilizamos en nuestros proyectos también tienen dependencias, las posibilidades de que algo salga mal se multiplican.
Gráficamente, podemos representar la cadena de dependencias de nuestra aplicación como un castillo de naipes, donde cada carta es una librería de código y cada nivel depende de todos los inferiores para funcionar correctamente.
Por ejemplo, si utilizamos React Native y Expo para construir nuestra aplicación, que es el stack que más me gusta a mí, los niveles del castillo de dependencias se corresponden con lo siguiente:
- En el nivel superior del castillo se encuentra el código fuente de nuestro proyecto. Es decir, todo el código que escribamos en React Native: componentes, estilos, llamadas HTTP, gestor de estado de la aplicación o los módulos nativos que hemos creado.
- En el nivel dos desde arriba, encontramos el código de todas las dependencias que instalemos en nuestro proyecto, entre las que se incluyen React Native, Expo o librerías de google como AdMob para mostrar anuncios o Firebase para añadir funcionalidades en la nube a nuestra app sin tener que montar un backend.
- Y por último, la base del castillo de naipes se corresponde con las dependencias del nivel anterior. Está formado por todas las librerías de las que dependen las dependencias que hayas instalado en el proyecto.
Si esto te ha parecido enrevesado, lamento informarte de que este ejemplo de tres niveles no es más que una simplificación del castillo que realmente forman las dependencias de una aplicación. Porque, ¿quién ha dicho que las dependencias de las dependencias no puedan tener dependencias?
Dependencias nativas del sistema operativo
Todo lo anterior que hemos dicho es cierto, pero hasta ahora habíamos obviado que cuando hablamos de desarrollar una aplicación móvil, nos referimos tanto a su versión para Android como para iOS.
Cada uno de los kits de desarrollo o SDKs de estos sistemas operativos es en sí mismo un castillo de dependencias como el que acabamos de construir. Por lo que, por debajo de nuestra aplicación, no solo hay más niveles de dependencias, si no que en realidad hay 2 castillos diferentes, uno para Android y otro para iOS.
La jerarquía de dependencias a nivel del sistema operativo estaría formada, obviando algunos detalles, por:
- El nivel superior, que sería la base del castillo de nuestra aplicación, es decir, el framework de desarrollo que estemos utilizando.
- Justo por debajo, tenemos la API del sistema operativo, los SDK de desarrollo de Android e iOS para mostrar la splash screen, enviar notificaciones, abrir otras aplicaciones, etc.
- En la base de este castillo, se encuentran el lenguaje de programación nativo de cada sistema operativo y todas sus librerías. Que serían Java para Android y Swift para iOS.
Al ponerlo todo junto, podemos observar el monstruo de dependencias que nuestra aplicación necesita para funcionar.
Si utilizas otro framework podrías tener más niveles de dependencias todavía. O si trabajas directamente en Java y Swift con los SDK de los sistemas operativos, puedes eliminar los tres primeros niveles del castillo.
En cualquier caso, que el código de todos los niveles funcione correctamente y sea compatible entre sí, sabiendo que cada librería ha sido escrita por un programador diferente, es lo más parecido a un milagro que verás en tu vida.
Así que no te sorprendas cuando, después de programar tu aplicación, vayas a compilarla y obtengas alguno de los infames errores de compilación de Android o iOS. Y ya te adelanto que esto no te va a pasar sólo una vez.
Testing: probando aplicaciones móviles
Después de decenas de experimentos combinando diferentes versiones de las librerías, se hace el silencio en la grada y el balón entra en la portería: la aplicación ha compilado sin errores.
En este punto, aunque podemos celebrar brevemente que ya tenemos una primera versión lista, todavía queda un largo camino hasta que podamos lanzar nuestra app. Y el siguiente paso es probar que todo funciona tal y como lo hemos programado.
¿Por qué es tan difícil probar una app móvil?
En la programación web, probar la página que estamos desarrollando sólo en nuestro ordenador y decir que funciona es un deporte de riesgo. Pero cuando estamos desarrollando para móvil, no probar nuestra aplicación compilada tanto en Android como en iOS, en diferentes versiones del sistema operativo y en tantos dispositivos como sea posible, es una muerte garantizada.
Durante el desarrollo de tu app, cuando tengas que probar una parte del código, te verás tentado a utilizar un emulador en tu ordenador por pereza a conectar un dispositivo Android y otro iOS. Así como a sólo probar la versión de desarrollo, para no tener que esperar a que la aplicación se compile.
Si tomas estos atajos para ahorrar tiempo, también tienes que saber que algunas de las librerías que exponen APIs nativas de móvil tienen bifurcaciones en el código para utilizar mocks cuando la aplicación no se ejecuta en un dispositivo real o la versión de la app es de desarrollo.
Por lo que, la única forma de garantizar que el código va a funcionar correctamente, en la versión que subamos a las tiendas de aplicaciones, es probarlo en un dispositivo real. Y, lógicamente, tanto en Android como en iOS, porque el código nativo subyacente a nuestra aplicación es diferente para cada sistema operativo.
¿En cuántos dispositivos tengo que probar mi aplicación?
Pero no cometas el error de pensar que porque en tus dispositivos hayas pasado las pruebas, puedes garantizar que la aplicación no va a tener errores.
Cada dispositivo móvil tiene una versión del sistema operativo específica. Esta versión instalada en el dispositivo se utilizará como dependencia en nuestra aplicación y por lo tanto ésta podría funcionar con normalidad sobre iOS 17, pero fallar cuando se ejecuta en iOS 15. Además, dependiendo de la versión mínima que hayas configurado para tu aplicación, habrá dispositivos en los que ni siquiera puedas instalarla.
Como guinda del pastel, cada dispositivo móvil o tablet, tiene unas características de pantalla diferentes, como el aspect ratio o si incluyen el notch en la pantalla. Así que, tendrás que probar que la interfaz se adapta a diferentes medidas de pantalla y que sigue siendo igual de usable.
Posiblemente te estés preguntando cómo vas a probar tu aplicación en todos los dispositivos que existen. Y efectivamente es imposible. Pero procura, al menos, instalarla en las dos últimas versiones de Android e iOS y en un móvil y una tablet, para descartar los errores que tienen más posibilidades de aparecer.
Distribución: subir la app a las tiendas de aplicaciones
Recapitulemos. Hemos programado la aplicación en nuestro framework favorito, hemos compilado una primera versión de producción y la hemos probado en varios dispositivos Android e iOS. ¿Ya hemos terminado, no?
Pues querido amigo, lamento comunicarte que todavía te queda un paso más: subirla a las tiendas de aplicaciones. Y para sorpresa de nadie, esto también es un infierno.
La ficha de la aplicación
El proceso de subida de una aplicación, a Google Play o App Store, tiene más que ver con burocracia y marketing que con programación.
Si aún no tienes cuenta de desarrollador en Google Play y App Store, tendrás que crearte una y pagar las tasas de la licencia que a día de hoy son: un pago único de 25$ para la de Google Play y 100$ cada año en App Store.
Cuando hayas pasado por caja, podrás crear la ficha de tu aplicación en cada una de las stores y empezar a rellenar toda la información obligatoria:
- El título de la aplicación, con treinta caracteres como máximo.
- Una descripción breve, pero con gancho.
- Una descripción completa en la que hables más en detalle de todas las funcionalidades de la aplicación.
- Por supuesto, un icono que invite a los usuarios a descargar y usar tu aplicación cuando lo vean.
- Capturas de pantalla de las diferentes vistas de la app. Este paso es relativamente sencillo en Android, pero especialmente doloroso en iOS, porque te obligan a subir capturas diferentes para cada aspect ratio de los dispositivos de Apple y son unos cuantos. Así que te toca abrir el Xcode, instalar los emuladores de un dispositivo de cada tamaño e ir haciendo las capturas de pantalla.
Adicionalmente, los campos de texto y las capturas de pantalla tendrás que rellenarlas una vez por cada idioma que añadas a la ficha de tu aplicación y si quieres ponerle un precio a tu aplicación, tendrás que configurar cuánto va a ser en cada país y completar la información fiscal de tu empresa.
Así que sumándolo todo y siendo optimista, tardarás al menos dos días en tener las cuentas de desarrollador y las fichas de las aplicaciones lo suficientemente decentes para que alguien quiera descargarlas.
La revisión de la aplicación
Por supuesto, el botón para enviar a revisión la aplicación seguirá deshabilitado.
Ya que todavía te faltan por rellenar los cuestionarios sobre el contenido de la aplicación para que puedan clasificarla y solicitar los permisos necesarios a los usuarios: como la ubicación, si recoges y compartes datos de los dispositivos, etc.
Después de esto, por fin podrás enviar esta primera versión de la aplicación a revisión.
Antiguamente, el proceso de revisión de App Store tenía la fama de ser más estricto y largo, porque se revisaba a mano por trabajadores de Apple, mientras que el de Google Play era automático. Pero hoy en día, ambos procesos son manuales y de hecho el de Google Play suele tardar más en revisarse. Así que ahora te toca esperar aproximadamente una semana para recibir una respuesta.
Tras una larga semana de espera, recibirás una de esas hostias con la mano abierta que se oyen a kilómetros de distancia: tu aplicación ha sido rechazada.
Si es la primera vez que subes una aplicación a las stores, te alegrará saber que todos hemos pasado por esto. El proceso de revisión de las aplicaciones es muy meticuloso, ya que cada día se suben miles de nuevas aplicaciones y tienen que filtrar tantas como puedan. Recibirás un email detallado con todo lo que tienes que modificar, o el motivo por el que la aplicación no ha superado la revisión, pero lo más común es que sea porque estás solicitando un permiso al usuario que no has marcado en el formulario del contenido de la aplicación.
Cuando hayas hecho los cambios necesarios, por mínimos que sean, adivina qué: tendrás que compilar una versión de tu aplicación, subirla a las tiendas de aplicaciones, enviar de nuevo a revisión y esperar otra semanita.
En este bucle temporal, te quedarás atrapado hasta que después de semanas o meses, finalmente te llegue el email con la confirmación de que la app ha sido aceptada y ya está disponible para el público.
Y ahora, mucha suerte intentando conseguir usuarios para la aplicación o juego que hayas hecho.
La competitividad del mercado de apps para móvil
¿Recuerdas las pruebas intensivas de las que hemos hablado o la ficha de las tiendas de aplicaciones que hay que rellenar para subir tu aplicación? Obviamente tenían un sentido, que es desarrollar un producto lo más atractivo posible para que la gente lo quiera usar.
No hay nada peor para un programador que, después de haber puesto el esfuerzo en desarrollar un proyecto, nadie quiera usarlo. Y esto es lo más habitual cuando desarrollas para móvil.
Al haber tantas aplicaciones en las tiendas, la mayoría de ellas permanecen en el fondo de las búsquedas, sin que ningún usuario las descargue. Tanto si es un juego como una app, es importante que tengas un plan para pasar por encima de la competencia y atraer tráfico a tu aplicación. Ya sea posicionarla en los resultados de búsqueda para alguna palabra clave popular, pagando campañas de anuncios o a través de redes sociales.
Lo que está claro es que por arte de magia no vas a conseguir un millón de descargas. Tendrás que competir con miles de desarrolladores con más experiencia que tú, así que espero que te gusten los retos difíciles.
¿Merece la pena desarrollar aplicaciones móviles?
Si me preguntas si merece la pena desarrollar aplicaciones móviles yo te diría que sí. De hecho, a mí es la plataforma que más me gusta para desarrollar videojuegos en Unity o apps de utilidades con React Native, porque ¿quién no tiene hoy en día el teléfono en las manos todo el día?
El proceso desde que empiezas a programar la aplicación hasta que finalmente está publicada está lleno de dificultades y es bastante desesperante. Así que cuando estés planificando el proyecto, ten en cuenta todo el tiempo ajeno a la programación que vas a necesitar para resolver conflictos, compilar la aplicación, hacer pruebas o el marketing de la aplicación.
Por otro lado, la competencia es bastante alta, pero es que no se me ocurre ningún área de negocio que no esté saturada hoy en día. Si haces el estudio de mercado previo, y desarrollas y promocionas un buen producto al público adecuado, puedes conseguir tu trozo del pastel.
¿Qué otros dolores habéis tenido al desarrollar vuestra app? ¿Me he olvidado de algún punto importante?
De nuevo, soy Carlos Sala, desarrollador de software, y ¡nos vemos pronto!
