10 Consejos a la hora de crear tus apps iOS

Xojo es un entorno de desarrollo termendamente útil, rápido y práctico a la hora de llevar a buen puerto tu próximo proyecto de app para iOS. En este artículo te ofrecemos una serie de sugerencias prácticas.

1. Define tu idea

Si eres capaz de resumir en una simple frase para qué servirá tu app… tendrás una buena parte del camino recorrido. Cuanto más escueta sea dicha frase, más definido estará el objetivo de tu app.

Aunque parezca una nimiedad, este simple hecho significará que tendrás más claros tus objetivos a la hora de realizar el diseño de las pantallas y la navegación entre las mismas, lo que también repercutirá a la hora de estructurar los componentes de código.

Adicionalmente, es breve frase será ideal para utilizarla en el campo de Descripción Breve correspondiente al registro de la app en la App Store Connect.

Reduce las características a implementar a aquellas que supongan el verdadero core de la aplicación y que definirán lo que será el Producto Mínimo Viable (o MVP, Minimum Viable Product, por sus siglas en ingles). Indudablemente, a medida que avances en la implementación de la app te asaltarán las ganas de añadir más prestaciones. No las implementes, anótalas y déjalas en reposo para implementarlas en futuras versiones, atendiendo también al feedback o comentarios recibidos por parte de los usuarios iniciales de tu app.

2. Elige la(s) plataforma(s)

Si bien Xojo permite que el diseño de las pantallas y código funcione tanto sobre dispositivos iPhone como iPad, no todas las aplicaciones tienen por qué dirigirse obligatoriamente a ambas plataformas. Céntrate en los dispositivos que mejor se adecuen al tipo de uso al que va dirigida tu app.

Por ejemplo, por regla general los usuarios de iPhone suelen hacer interacciones rápidas para completar una determinada tarea o acción; mientras que las apps dirigidas al iPad suelen conllevar un uso más afín al que podría realizarse en un portátil, donde el usuario suele pasar más tiempo enfocado en una determinada app.

En cada nuevo proyecto para iOS, Xojo incluye por omisión un layout específico tanto para iPhone como para iPad. Si encuentras preferible que tu app funcione sólo en una de estas plataformas, define a “None” el valor de Default iPhone Layout o Default iPad Layout desde el Panel Inspector para el elemento App.

También has de tomar una decisión sobre la versión mínima de iOS que soportará tu app. Actualmente el IDE de Xojo establece iOS 14.0 como la versión mínima para todo nuevo proyecto, si bien en el momento de escribir este artículo más de un 60% de los usuarios ya tienen instalado iOS 18+ en sus dispositivos.

3. Prototipado

El IDE de Xojo es tan intuitivo, y el ciclo de diseño / prueba tan sencillo y rápido que la mayoría de las ocasiones te sentirás tentado de comenzar a diseñar las pantallas e implementar la funcionalidad y navegación entre ellas desde el principio. Si se trata de una pequeña utilidad… ¡perfecto! pero en aquellas apps que, aun siendo sencillas, ofrecen más funcionalidad, siempre resulta conveniente darse algo de tiempo y tirar de alguna herramienta para crear mockups, como puedan ser Figma o MockUp para macOS y iOS.

Otra opción que también suele dar muy buenos resultados son un simple lapicero y un block de papel.

En definitiva, es una cuestión que siempre va en gustos o con lo que te sientas más cómodo a la hora de reflejar las ideas de una forma ordenada y bien pensada.

Adicionalmente, si se trata de tus primeros pasos en el desarrollo de apps para iOS, siempre es recomendable echar un vistazo a la Human Interface Guidelines publicada por Apple, de modo que sigas las recomendaciones indicadas para que tu app comparta los mismos patrones y paradigmas que un usuario espera encontrar en cualquier app diseñada para iOS. Por ejemplo, un buen sitio por el que empezar podría ser Designing for iOS.

Cuando comiences a diseñar tus pantallas en el Editor de Diseño de Xojo, recuerda que además de definir las relaciones entre controles mediante el Panel Inspector, obtendrás un mayor control mediante la clase iOSLayoutConstraint en tiempo de ejecución y reaccionando a los diferentes cambios de orientación del dispositivo. En este sentido la flexibilidad a será absoluta a la hora de reorganizar la disposición de los controles en la pantalla, tanto en su posición como en su tamaño y la relación que mantendrán unos sobre otros.

4. Base de datos

Es rara una app que no “descanse” sobre una base de datos. En iOS, la mejor opción para guardar datos de forma local es el uso de SQLiteDatabase, y la mejor ubicación en la que puedes guardar dicho archivo será en la carpeta obtenida a partir de SpecialFolder.Documents. Por supuesto, también podrás comunicarte con bases de datos remotas de forma directa o bien a través de una API, si tu app así lo requiere.

Sea cual sea el modo de hacerlo, y especialmente si vas a utilizar una base de datos local (SQLite), te recomiendo que siempre añadas en la base de datos una tabla de “Metadatos” en la que, entre otras cosas, te permita conocer cuál es la versión o estructura de la base de datos que se está utilizando en un momento dado. También es recomendable que crees tu propia clase de SQLiteDatabase y que mantengas en ella todos los métodos relacionados con las consultas o escrituras sobre la base de datos.

¿Por qué estas dos recomendaciones? A buen seguro que inicialmente tus ideas estarán bien claras sobre como ha de ser el esquema de la base de datos y la relación existente entre las diferentes tablas y campos; pero a medida que tu app evolucione con nuevas versiones es probable que alguna de las nuevas características llegue a impactar tarde o temprano en el esquema de la base de datos. Manteniendo una tabla de metadatos siempre sabrás qué versión está instalada en el dispositivo del usuario, y podrás reaccionar en consecuencia desde el código de la nueva versión (añadiendo nuevas tablas, campos, etc.)

5. Recursos Gráficos

Cuando se trata el uso de imágenes para botones, barra de navegación mediante pestañas (en el caso de que tu App vaya a utilizarlo), o los iconos añadidos en las filas de la tabla tu mejor amigo será el método compartido Picture.SystemImage en combinación con los glifos o símbolos gráficos que puedes consultar mediante la app de macOS SF Symbols. Estos glifos escalan bien a cualquier tamaño, ofreciendo siempre la mejor resolución y además permiten la asignación de diferentes colores para cuando la app funcione en modo claro u oscuro. Eso sí, asegúrate de que los símbolos elegidos estén disponibles para la versión mínima de iOS sobre la que tienes previsto ejecutar tu app.

En el resto de los casos en los que no sea posible recurrir a los símbolos de SF Symbols, añade nuevos items de Imagen a tu proyecto Xojo para iOS y añade las imágenes para cada una de las resoluciones requeridas, de forma que se vean nítidamente en los diferentes tamaños de pantalla (y densidades de punto) utilizados en iOS.

¡No te olvides de la tipografía! Por omisión todos los controles añadidos en el Editor de Diseño (o mediante código) utilizarán por omisión la fuente del sistema en su peso Regular y con un tamaño de 17 puntos; pero siempre es bueno darle a tus apps algo de personalidad y hacer uso del resto de las tipografías (y pesos de fuente) instalados en los dispositivos iOS. Eso sí, es aconsejable no utilizar más de dos tipografías diferentes.

Utiliza la tipografía para definir la jerarquía en la información mostrada. Por ejemplo, puedes utilizar diferentes pesos de una misma tipografía así como tamaños de fuente distintos. Ahora bien, recuerda que el tamaño de fuente mínimo recomendado es de 11 puntos.

En este sentido, cuando pruebes la app en cualquiera de los Simuladores recuerda ajustar el tamaño de la ventana del simulador al tamaño físico del dispositivo (Simulator > Window > Physical Size), de lo contrario podrías obtener una idea distorsionada sobre la legibilidad de los textos cuando tu app se instale sobre un dispositivo real.

6. Localización… y accesibilidad

Nada te impide publicar una app en un único idioma, ya sea el que utilices de forma nativa o, como mínimo, en Inglés; pero lo que resulta cierto es que la localización (proporcionar tu app lista para funcionar en el idioma del usuario del dispositivo) es un factor determinante a la hora de incrementar, hasta en 128x, las descargas de tu app.

Si sigues la ruta de localizar tu app (y deberías), ¡empieza a hacerlo lo antes posible! dado que esto podría afectar algunas cuestiones sobre el diseño de tu app. Añade un módulo a tu proyecto iOS en Xojo y añade tantas constantes como textos vayas a utilizar en tu app. No te olvides de activar el interruptor “Localized” en cada nueva constante de tipo String añadida al módulo y provee los textos equivalentes por cada idioma que vayas a soportar.

Si tienes dudas sobre las localizaciones que deberías proporcionar en tu app, esta sería una buena guía:

Como Mínimo:

• Inglés

Localizaciones adicionales (por importancia):

• Chino
• Español
• Alemán
• Francés
• Japonés
• Italiano
• Portugués
• Ruso
• Coreano

No tienes por qué proporcionar todas las localizaciones en tu primera versión. Al estar incorporadas en un módulo, podrás ir añadiendo entradas de idioma adicionales por cada nueva cadena de texto en subsiguientes versiones de la app.

Eso sí, asegúrate de que las localizaciones son correctas en cada nuevo idioma soportado… y no las literales (y muchas veces erróneas) que podrías obtener utilizando servicios de traducción como Google Transtlator.

Esto mismo aplica también en los textos de Accesibilidad que proporciones en los controles que soportan dicha capacidad.

Y si quieres mejorar aun más la experiencia de los usuarios (y atraer más descargas de tu app), recuerda que la App Store Connect te permite crear páginas específicas por cada uno de los idiomas soportados… lo que también implica que deberías de crear las capturas de pantalla localizadas para cada una de las páginas, junto con las descripciones y resto de textos que se mostrarán en la App Store.

7. Pruebas

El IDE de Xojo cubre todas las opciones que requieras utilizar a la hora de probar tu app, tanto desde el punto de vista del diseño y experiencia del usuario como desde la funcionalidad.

Simuladores

Utiliza los Simuladores durante todas las fases del proyecto. Son especialmente útiles a la hora de comprobar cómo se verán los diseños de las pantallas de la app al ejecutarse sobre dispositivos con diferentes tamaños de pantalla y también en todas las orientaciones de pantalla soportados (Panel Inspector de los elementos iPhone Layout y/o iPad Layout). También son muy convenientes para comprobar las localizaciones, dado que puedes instalar todos los idiomas soportados y cambiar entre ellos de forma más rápida y conveniente en comparación con hacer la misma operación sobre un dispositivo físico.

Los simuladores también serán convenientes para realizar las capturas de pantalla que utilices en la composición de las imágenes añadidas al registro de la app en la App Store Connect.

Ejecutar en Dispositivo (Debug)

No importa cuan buena sea la experiencia cuando pruebes tu app en los simuladores, en este caso seguirás utilizando el dispositivo apuntador y, seguramente, el teclado de tu Mac para realizar la entrada de datos.

Utiliza la opción que permite depurar tu aplicación sobre un dispositivo físico para obtener una mejor visión sobre los aspectos relacionados con la usabilidad, navegación e introducción de datos; aparte de que los dispositivos físicos son la única opción real a la hora de probar ciertas características disponibles únicamente en el hardware.

Copiar a Dispositivo

Las dos opciones anteriores comparten una limitación: son excelentes para detectar los fallos del código y corregirlos, pero eso significa que tu app sigue “atada” al IDE de Xojo. Es decir, tan pronto como detengas la ejecución de la app desde el depurador… no podrás ejecutarla de forma independiente en el dispositivo o en el Simulador.

Cuando ya hayas finalizado de corregir los fallos de código y también en el diseño de la app, deberás continuar con las pruebas… en el mundo real. Esto significa compilar la app (Build) y utilizar Xcode para copiar el bundle resultante a cualquiera de los dispositivos físicos que vayas a utilizar para realizar las pruebas.

Una vez que la tengas sobre el dispositivo ya podrás utilizar tu app tal y como harías con cualquier otra, y al hacerlo probablemente te surjan algunas optimizaciones especialmente en el área de diseño y usabilidad.

TestFlight

Todo lo anterior se basa en pruebas que podrían calificarse como “internas”, pero ya en las fases finales de desarrollo es hora de poner la app en manos de tantas personas o testeadores como te sea posible. Esto enriquecerá el feedback recibido.

Para ello, sólo has de Publicar la app desde el IDE de Xojo a la App Store Connect y asegurarte de crear un grupo de “External Testing” en el apartado TestFlight. Son varias las opciones proporcionadas para añadir testers externo, si bien la que encuentro personalmente más conveniente es la de crear un enlace público que puedas compartir para que se añadan como probadores tantas personas como hayas establecido a la hora de crear el enlace.

De igual modo, recuerda que puedes añadir tantas builds como precises por cada nueva versión de la app que quieras probar a través de TestFlight. Todo lo que has de hacer es activar la opción Auto Increment Version en el Panel Inspector correspondiente a Build Settings > Shared.

Un consejo es añadir la entrada ITSAppUsesNonExemptEncryption con el valor booleano False en Build Settings > iOS > Property List > Edit. De esta forma no tendrás que confirmar manualmente que tu app no hace uso de funciones de encriptación (si es el caso) por cada nueva compilación que subas a la App Store Connect.

8. Publicación

El IDE de Xojo hace que resulte realmente sencillo publicar o “subir” tu app a la App Store Connect como paso previo a su revisión y publicación en la App Store. Probablemente en la parte en la que deberás de invertir más tiempo sea la correspondiente a preparar los textos promocionales que has de añadir en el registro de la app que hayas creado en la App Store Connect, así como los materiales gráficos y una buena selección de las palabras clave (amén del resto de campos que has de añadir).

Y si decides crear páginas específicas por cada uno de los idiomas seleccionados… el tiempo invertido se multiplicará por la cantidad de localizaciones ofrecidas por tu app.

Más allá de los textos y elementos gráficos, en los que deberías de invertir la pausa y cariño necesarios, asegúrate de seleccionar la Build correcta a enviar para su revisión y publicación en la App Store.

9. Marketing

Algo que deberías de ir haciendo de forma simultánea es la preparación de los materiales relacionados para dar a conocer tu app al mundo.

Si bien no es necesario crear un sitio Web específico por cada una de tus apps publicadas, sí que es recomendable a la hora de incrementar el ránking en cuanto a las búsquedas y, por tanto, su visibilidad. Además también podrás utilizarlo para proporcionar materiales adicionales sobre el funcionamiento de tu app, desde tutoriales a pequeños consejos y trucos o bien un área específica de soporte.

También es conveniente crear un canal de YouTube en el cual subir vídeos, así como cuentas en redes sociales (como X) donde puedas ir publicando detalles sobre tu app con cierta frecuencia.

Por supuesto, no dudes en dar a conocer tu app en foros y grupos específicos sobre el público objetivo al que se encuentra dirigida tu app, incluyendo como no el propio Showcase.

Además de ello, saca provecho de las herramientas de márketing proporcionadas por Apple. Estas te permitirán crear contenidos promocionales, enlaces y también códigos QR apuntando a la descarga de tu app y que podrás utilizar en tu sitio web o bien en las redes sociales a la hora de promocionar tu app.

10. Los siguientes pasos…

Una vez tu app esté disponible en la App Store, muy probablemente irás recibiendo comentarios y retroalimentación por parte de tus usuarios. Adicionalmente, y muy probablemente, también debas de corregir algún que otro fallo que se haya escapado durante la fase de pruebas. Esto significa que probablemente debas de trabajar en dos versiones de tu producto a partir de ese momento:

• La versión pública, disponible en la App Store.
• La siguiente versión mayor en la que se implementen nuevas características significativas.

Para ello resulta casi imprescindible que guardes tus proyectos iOS de Xojo en formato texto, además de que utilices el sistema de versionado de código que encuentres más de tu agrado. Esto te permitirá mantener ambas (o más) ramas del mismo proyecto e ir trabajando en cada una de ellas a medida que lo precises, aparte de otras muchas ventajas.

En conclusión

Incluso las apps de iOS más “sencillas” requieren una buena cantidad de tiempo y esfuerzo, si bien gracias a Xojo ambos aspectos se ven reducidos de forma muy notable.

¿Cuáles son tus estrategias y consejos que desees compartir? No lo dudes y compártelo con todos en el Foro de Xojo.