Introducción 

La presente guia pretende ser un conjunto de buenas prácticas para el desarrollo de aplicaciones móviles iOS que formarán parte del ecosistema del proyecto mSSPA.

Los componentes del proyecto mSSPA, a su vez, se basan en el resto de normativas definidas en la STIC, como por ejemplo, la de arquitectura y desarrollo para los componentes de backend, o la de interoperabilidad para la necesidad de consumo y definición de servicios que utiliza cada App.

A continuación se listan los enlaces a los distintos apartados ya existentes y disponibles públicamente en UNIFICA, para facilitar el acceso directo a los mismos:

Información sobre arquitectura y normativa de desarrollo: Arquitectura

Información sobre interoperabilidad: Interoperabilidad

Información sobre normativa de calidad: Calidad

Información sobre integración con las herramientas de gestión TIC: Herramienta de gestión TIC - Servicios CGES

Versión mínima del SO.

Se establece la versión mínima del SO en donde se podrá ejecutar cualquier aplicación del ecosistema del proyecto mSSPA. Para el caso de iOS las nuevas versiones de los SO suelen tener una adopción bastante alta, y pocas semanas después, la adopción de la última versión del SO suele rondar el 90%. Teniendo en cuenta esto, con soportar la versión más reciente del SO y la predecesora, se asegura una cobertura de casi el 100% de los usuarios. Actualmente, las versión requerida para instalar cualquier aplicación del ecosistema mSSPA será iOS 12.

Entornos y Versiones

Disponer de entornos de desarrollo separados en las distintas fases del ciclo de vida del software evita datos incongruentes o erróneos en entornos productivos. Para los proyectos de aplicaciones iOS se contará con dos entornos de trabajo distintos, uno para la fase de desarrollo al que llamamos entorno PRE y otro para la fase de producción al que llamaremos entorno PRO.

Del mismo modo se diferencian las versiones de compilación. De esta forma, como mínimo, se dispondrá de una versión de compilación de “debug” y otra “release”. También se pueden establecer opciones de configuración distintas para cada uno de los modos de compilación, tales como la ofuscación de código.

Para ello, la app iOS hará uso de las herramientas del propio proyecto iOS para la diferenciación de recursos y configuración a través del fichero de configuración Info.plist. Así se definirán tres esquemas distintos, Debug PRE, Debug PRO y Release. Estos esquemas definen valores distintos para aquellas variables contenidas en el Info.plist, tales como la URL de acceso a la API.

En este sentido, será la versión “release” la que se seleccionará cuando se quiera crear una versión funcional de la aplicación, que esté lista para la subida a la tienda de aplicaciones. Esto será de obligado cumplimiento para las aplicaciones iOS.

Lenguaje de programación 

El desarrollo de aplicaciones móviles iOS estará basado en código Swift, normalmente actualizado a la última versión estable de dicho lenguaje de programación. Swift es un lenguaje de programación de reciente creación diseñado por Apple. Es un lenguaje funcional con una sintaxis simple y muy eficiente, y rápido en cuando a rendimiento se refiere.

Arquitectura

Con objeto de garantizar la robustez, calidad y mantenibilidad de la aplicación, así como una buena estructura del código de la aplicación, es muy importante definir una buena arquitectura. En este apartado se describe la arquitectura adoptada para las aplicaciones iOS.

Clean Architecture

La arquitectura a usar por la apps iOS será Clean Architecture, una arquitectura de uso extendido en el desarrollo nativo de aplicaciones móviles. Entre las ventajas de usar Clean Architecture podemos citar:

• Separación del código en capas independientes con responsabilidades bien definidas para cada una de las capas.
• Mayor nivel de abstracción.
• Código desacoplado.
• Facilita el uso de tests.

Clean Architecture

Clean Architecture

Patrón de Diseño – MVP

Uso del patrón de diseño MVP (Model View Presenter). Patrón de diseño muy utilizado en el sector del desarrollo móvil nativo. Dicho patrón separa la capa de la vista o presentación con la capa de negocio, haciendo de esta manera el código más robusto, mantenible y testeable. 

Model View Presenter

Patrón de Diseño - Repository

Una de las ventajas de tener el código de la app iOS separado en capas es la independencia de cada una de las capas en cuanto a responsabilidades. En este sentido, en la capa de acceso a datos haremos uso del patrón de diseño Repository. Este patrón nos permite separar la fuente de datos del resto de partes de la aplicación permitiendo en caso necesario interactuar con una o varias fuentes de datos distintas e incluso cambiar la fuente de datos utilizada por la aplicación.

Componentes y Tecnologías

A continuación se describen los componentes y tecnologías más relevantes incluidas en el desarrollo de apps iOS.

Eventos – Rx (RxSwift)

La gestión de eventos y tareas es vital para la usabilidad y fluidez de una aplicación iOS. Está totalmente desaconsejado realizar operaciones costosas a nivel computacional en el hilo principal de la aplicación, ya que si este tipo de operaciones las hacemos en el hilo principal dejaremos la interfaz de usuario congelada hasta que la operación termine, bloqueando al usuario incluso a poder navegar a otras vistas o realizar otra acción. Para evitar bloquear la interfaz de usuario, se hará uso de ReactiveX (RXSwift) como API para la gestión de eventos, tales como el manejo de peticiones al servidor de soporte de la aplicación, almacenado de datos en preferencias de usuario, lectura de configuración por defecto, etc.

Red – Alamofire

Alamofire es una librería de comunicación que se usa para encapsular las peticiones HTTP a nivel de red. Esta librería facilita la comunicación con el servidor de soporte correspondiente vía API, modelando las peticiones y las respuestas para cada uno de los servicios expuestos y utilizados en la app.

Firebase

Firebase es un conjunto de herramientas y servicios proporcionadas por Google que facilitan ciertas tareas de análisis, configuración, comunicación entre otras para con las distintas aplicaciones móviles que lo integren. De todos los servicios que ofrecen, los mínimos que deben integrarse dentro de las apps iOS son los siguientes:

• Analytics: Es importante conocer el uso que un usuario hace de cualquier aplicación una vez la app ha sido liberada. Es interesante medir tiempos de sesión, uso de ciertas funcionalidades, etc. En este sentido, mientras más datos se conozcan sobre el uso de la aplicación más argumentos de decisión se tendrán para actuar en consecuencia. Analytics permite definir tanto eventos como propiedades de los usuarios que formarán parte de las estadísticas de uso de la aplicación.
• Crashlytics: Al igual que el apartado anterior, es de vital importancia conocer los errores de la aplicación en tiempo real. Crashlytics proporciona información sobre los errores que se han producido en la ejecución de la aplicación por parte de los usuarios, aportando información técnica muy valiosa que permite disponer de una traza de en dónde y qué ha provocado el error, permitiendo así solventar esos posibles errores en el menor tiempo posible.
• Remote Config: Cambiar el comportamiento de la aplicación en tiempo real es útil debido a que permite redirigir el flujo de comportamiento de los usuarios dentro de la aplicación de forma transparente y rápida en función de determinados parámetros, tales como versión del SO, localización, audiencias, etc.
• Cloud Messaging: Aunque las notificaciones push son el objetivo de otro hito dentro del proyecto mSSPA (Servidor de Notificaciones), una app iOS contará con una gestión mínima de notificaciones push, es decir, la app será capaz de recibir y mostrar notificaciones push cuando se esté ejecutando en segundo plano y queramos establecer un canal de comunicación con el usuario de la aplicación.

WebViews

Por motivos de seguridad es desaconsejable el uso de WebViews para mostrar cualquier contenido web de terceros dentro de la aplicación. Partiendo de esa premisa, hay veces en las que es útil cargar contenido web dentro de la aplicación. 

Las aplicaciones iOS controlarán esta integración para hacerlo de forma segura y minimizando el impacto de la misma. En este sentido se adoptan las siguientes medidas entre otras:

• Sólo se permite la carga de contenido web que provengan de servidores de confianza y securizados.
• Se deberá deshabilitar por defecto poder cargar el contenido JavaScript asociado al HTML de la web que se quiere cargar dentro del WebView.
• El WebView no tendrá acceso a ningún recurso de la aplicación.
• La aplicación no cacheará ningún dato proporcionado por la WebView

Integración con MAG (Mobile API Gateway)

Las aplicaciones iOS incorporarán la última versión del SDK para CA Mobile API Gateway para poder aprovechar las funcionalidades que dicha plataforma proporciona.

Funcionalidades

En este apartado se describen las funcionalidades mínimas comunes para todas las aplicaciones Android que formarán parte del ecosistema del proyecto mSSPA. 

Versiones

Tal y como se ha detallado en apartados anteriores, se contará con dos versiones distintas, la versión “debug” y la versión “reléase”, además de contar también con dos entornos de desarrollo distintos, PRE y PRO. 

Con el objetivo de poder diferenciar claramente el contexto en el que se está ejecutando la app se debe diferenciar el nombre de la aplicación, así como su nombre de paquete, incluyendo el sufijo “DEV”, permitiendo en este sentido incluso poder instalar ambas versiones (“debug” y “reléase”) de la app en el mismo dispositivo.

Menú lateral

Las aplicaciones iOS incluirán un menú lateral con accesos directos a distintas secciones de la aplicación.

Además de accesos directos a secciones, el menú lateral deberá de informar de la versión de la aplicación que se está ejecutando, además del entorno de desarrollo. Para ello, en caso de que la aplicación se esté ejecutando en el entorno de desarrollo de PRE se incluirá un texto indicativo a la versión de la aplicación.

Login

Desde las aplicaciones iOS podremos autenticar al usuario contra los sistemas de información del SAS de forma que tras la autenticación obtengamos un token de acceso para sucesivas llamadas a dichos sistemas. 

Para este propósito las apps se integrará con el nuevo sistema de login basado en WebView a través del producto de mSSPA denominado "Web de Opciones de Autenticación", que actualmente contiene como opciones de login Certificado Digital, Cl@ve, WebMovil SSPA (login con QR) y DMSAS (login profesional).

Esta integración se llevará a cabo haciendo uso de la API y servicios expuestos a través de CA para la posterior obtención del token de acceso para sucesivas peticiones para la obtención de datos.

Deeplinking

Las aplicaciones pertenecientes al proyecto mSSPA deben tener la capacidad de abrirse desde enlaces externos desde otras aplicaciones tales como el gestor de correo o otra aplicación del proyecto mSSPA. 

Se debe establecer, de forma clara, las urls que las aplicaciones iOS sabrá interpretar como links externos para poder abrir la aplicación o la sección correspondiente en cada momento.

Logger – SwiftLog

Con el objetivo de poder conocer los eventos y las posibles anomalías que pudiesen suceder, se propondrá un sistema de Logger para identificar claramente qué y dónde se ha producido el evento o anomalía. 

Así mismo se deberá evitar escribir mensajes en los logs en las versiones de las aplicaciones que se publiquen en el Store ya que estos datos sólo son útiles durante el desarrollo de la aplicación. Además, también se evitará la escritura de datos confidenciales del usuario.

Ocultar información en segundo plano

Debido a la confidencialidad de la información con las que las aplicaciones del proyecto mSSPA trabajarán, es de debido cumplimiento que las aplicaciones oculten la información mostrada cuando dichas aplicaciones pasen a segundo plano. 

Evitar capturas de pantalla

Al igual que el apartado anterior las aplicaciones del proyecto mSSPA no permitirán que se puedan realizar capturas de pantalla para evitar así filtrar información confidencial del usuario.

Autenticación biométrica

Cada vez son más los dispositivos con capacidades biométricas integradas, como lector de huella o reconocimiento facial.

Las aplicaciones iOS dispondrá de autenticación biométrica siempre y cuando el dispositivo lo permita. Este método de autenticación sentará las bases para que futuras funcionalidades puedan hacer uso de la autenticación biométrica en caso de ser requerida.

Seguridad

La seguridad es un aspecto clave debido a la sensibilidad de los datos a tratar en las aplicaciones del proyecto mSSPA. En este sentido se establecen una serie de medidas mínimas de seguridad tales como:

Comunicación segura

Cualquier comunicación con el servidor vía API deberá ser una comunicación segura bajo protocolo HTTPS. 

Dispositivos rooteados

Las apps iOS harán las comprobaciones pertinentes para detectar si el dispositivo sobre el que se ejecutan ha sido “rooteado” o no. Un dispositivo “rooteado” es un dispositivo en el que el usuario tiene control total sobre los privilegios de todas las aplicaciones y procesos que se ejecutan en el mismo, por lo que podría tener acceso a los datos sensibles del usuario.

Ofuscación de código

Se establecerán medidas para la correcta ofuscación del código base de la app iOS siguiendo las directrices que marca la propia plataforma iOS.

Accesibilidad

Cualquier app iOS seguirá unas pautas de implementación de capacidades de accesibilidad para hacerla usable a personas con algún tipo de limitación, ya sea auditiva o visual. Para ello, deberá seguir la normativa que provee la Oficina de Calidad.

Internacionalización

Aunque el ámbito de las aplicaciones del proyecto mSSPA está claramente definido a la Comunidad Autónoma de Andalucía, además del castellano, las apps iOS también soportarán el inglés como idioma principal de la aplicación, facilitando con esto su integración con proyectos internacionales.

Tests

Por otro lado, la estabilidad y calidad del código es una pieza fundamental dentro de cualquier proyecto software que se desarrolle.

Para garantizar la robustez y calidad del código, se establecen test (unitarios, funcionales o de integración) en las distintas capas de la arquitectura de la aplicación que sean capaces de garantizar un buen porcentaje de cobertura de código.

Inicio

Repositorio documental