IMI

R2. Requisitos específicos iOS

R2.1. Compatibilidad

Se entiende por compatibilidad no sólo que la aplicación se pueda instalar, sino que las funcionalidades principales de la aplicación se ejecutan correctamente y sin presentar errores. En caso de que una funcionalidad secundaria no funcione correctamente en un conjunto de dispositivos, esta funcionalidad no deberá mostrarse en estos dispositivos.

• R2.1.1. Las aplicaciones iOS para móvil deben ser compatibles con las últimas versiones de iOS, siguiendo la política de soporte de Apple. En concreto, deben cumplirse los siguientes requisitos:
  • El desarrollo debe ser compatible con iOS 17 o versiones superiores. También deberá ser compatible con las últimas versiones iOS que Apple tenga publicadas o en Beta.
  • No se publicarán apps compatibles con versiones iOS 15 o inferiores.
  • En caso de utilizar SWIFT tendrá que ser la última versión.
  • La aplicación no debe tener ningún error, ni problema funcional o de visualización, en modo oscuro.
• R2.1.2. Las aplicaciones han de ser compatibles y adaptarse de forma 100% automática a cualquier tamaño de dispositivo.
• R2.1.3. En el momento de publicación, el código de la aplicación se compilará y se subirá a App Store mediante la última versión disponible de XCode, así como con la última versión del SDK disponible, por lo tanto, el código debe ser compatible con estas versiones.
• R2.1.4. El framework de desarrollo del Ayuntamiento es Flutter, y por tanto el IDE oficial para compilar es Xcode. Si el proveedor desarrolla con otros IDE como Titanium, PhoneGap, ... El proveedor deberá proporcionar este código para XCode. En caso de no ser posible, se deberá informar y solicitar la autorización al OSAM previamente al inicio del desarrollo.​​​​​​

R2.2. Metainformación del proyecto XCode

• En iOS el bundleid de la aplicación debe ser: cat.bcn.nombre-aplicación
• En iOS es necesario que la app tenga registrado un URL Scheme, para poder ser abierta remotamente desde otra app. La URL Scheme de la aplicación deberá seguir el patrón que marca el BundleID.
• Como nomenclatura del campo Bundle Version del archivo Info.plist, se utilizará la fecha de entrega en formato numérico y inverso (yyyymmddhh).
• No será válido dejar la configuración predeterminada de Universal si una aplicación es sólo compatible para iPhone o para iPad.
• Cuando se genera un proyecto nuevo, se deberá marcar la opción correcta de "supported destinations" en la información general del proyecto en XCode.
• Para todas las apps que utilicen localización, la geolocalización se limitará a la opción WhenInUse, es decir, sólo cuando la app esté en uso (foreground). En el archivo Info.plist del proyecto habrá que añadir la entrada NSLocationWhenInUseUsageDescription especificando un mensaje de alerta de utilización de este permiso, porque el sistema lo muestre. En el caso de que la app sea multi-idioma, se deberá indicar la variable y poner los strings los ficheros InfoPlist.strings del proyecto.
• Los proyectos deben venir sin certificados seleccionados (utilizar los genéricos).

R2.3. Estándares de desarrollo

• R2.3.1. Se debe garantizar las guidelines de desarrollo y calidad especificadas por la Apple Store vigentes en el momento de la publicación Las guidelines se pueden encontrar en guidelines Apple. También es necesario revisar las nuevas noticies de Apple, ya que pueden contener avisos importantes y acciones obligatorias relacionadas con las Apps. El enlace últimas noticias Apple.
  • Recomendamos no superar los límites establecidos por Apple para la descarga de la app a través de la red de datos móviles. En caso de superarla será necesario proporcionar una justificación
• La splashscreen deberá usar los storyboards de Xcode.
• R2.3.2. También se deben seguir los estándares de desarrollo expuestos por la OSAM:
  • Si el código del proyecto tiene dependencias con otros proyectos, es necesario que estos otros estén incluidos dentro del proyecto principal como librerías. De esta manera evitamos posibles errores en acciones manuales de compilación y referencia. En cualquier caso, se recomienda la utilización del gestor de dependencias CocoaPods. Si se utiliza CocoaPods, se deben añadir los binarios de las librerías que se especifiquen en el Podfile.
    • Si el proyecto usa CocoaPods, ha de usar la última versión estable de éste. Y las versiones de los Pods incluidos en éste han de ser fijas (no utilizar “~>”) para que la validación que nos da el proveedor sea real.
  • En el caso de que la OSAM necesite una licencia para la compilación de los proyectos con el Framework multiplataforma (Titanim, Phonegap, …) esta será facilitada por el cliente o proveedor.

R2.4. Política de privacidad de la app

• R2.4.1. De acuerdo a los requerimientos sobre privacidad de los datos de Apple a partir de la versión 14.5 de iOS, todas aquellas aplicaciones que utilicen datos de la persona usuaria para hacer tracking (rastreo) es necesario que pidan el permiso explícito de esta a través del framework AppTrackingTransparency. Si no da permiso para habilitar el tracking, la app no debería recoger estos datos y, en concreto, en el caso del identificador de publicidad que proporciona el propio sistema operativo, este vendrá con valor 0 y no se podrá utilizar.
• Con el fin de decidir si es necesario o no utilizar este framework, para publicar cualquier versión, es necesario rellenar un formulario de privacidad de la app, donde se define qué datos personales se recogen y qué uso se hace de los mismos. Este formulario debe rellenarse una sola vez para cada app y habrá que contactar con la OSAM para hacerlo. Para cada tipo de dato que se seleccione, se indicará cómo se utilizan los datos obtenidos por esta app.
• Para consultar la definición de tracking, ejemplos, los diferentes tipos de datos que hay que declarar y otras consideraciones se pueden consultar aquí.