Desenvolupament d'aplicacions mòbils

Elaboració pròpia: la font és de pagament i no es reprodueix

Sense esquema, expressament

Enunciat oficial. Desenvolupament d'Aplicacions Mòbils. (APPS).

1. Tipus d'aplicació mòbil

Abans de començar un projecte cal escollir el tipus d'aplicació, en comparació amb les alternatives, segons els criteris principals que segueixen la taula.

PWA: és la tendència recent de les aplicacions web que aprofiten funcions modernes del navegador per oferir experiències semblants a les de les aplicacions natives; així es coneixen les aplicacions web progressives.

Desavantatge clau de les WebApps davant les natives (pregunta literal): l'accés limitat a les funcionalitats i al maquinari del dispositiu —càmera, GPS d'alta precisió, biometria, NFC (Near Field Communication), Bluetooth, notificacions natives, treball en segon pla— i el rendiment i l'experiència d'usuari inferiors, especialment en interaccions gràfiques intensives.

Criteris de decisió: pressupost i equip disponible, necessitat d'accés al maquinari, exigència de rendiment, previsió de vida de l'aplicació, necessitat de funcionament fora de línia, i estratègia de distribució. Exemple: una app només per a Android que, accedint al micròfon del telèfon, ha de mesurar els decibels i dona prioritat al rendiment per proporcionar una experiència ràpida i bona és un cas clar de nativa: la tecnologia amb l'accés més directe al maquinari.

1.1 Llenguatges de programació

Compilats (C, Java, Swift): el codi font es tradueix sencer a codi màquina abans d'executar-se. Interpretats (Python, JavaScript): un intèrpret llegeix i executa el codi font línia a línia en temps d'execució, sense fase de compilació prèvia; és l'avantatge principal dels interpretats respecte als compilats —a canvi solen ser més lents en execució.

Els llenguatges que es fan servir depenen de la plataforma; el llenguatge tradicionalment més utilitzat a Android va ser Java, encara que avui Kotlin és el recomanat:

2. Cicle de vida i metodologia

Metodologia àgil aplicada a les APP — la característica que la defineix principalment: el desenvolupament es fa en iteracions curtes que lliuren versions funcionals i utilitzables de l'aplicació de manera freqüent, incorporant la retroalimentació de l'usuari a cada cicle i acceptant els canvis de requisits. Això encaixa especialment bé amb el mòbil, on el retorn d'ús real (analítica, valoracions a les botigues, proves A/B) és immediat i abundant.

Fases: descobriment i definició de l'usuari → disseny UX/UI i prototipatge → desenvolupament iteratiu → proves → publicació → analítica i evolució.

Disseny mòbil: els conceptes clau per millorar l'experiència de les persones usuàries són la usabilitat —facilitat d'ús, navegació clara, poques passes per completar una tasca— i l'accessibilitat, i cal prioritzar-les per davant de l'acumulació de funcions o de l'estètica per si sola. mobile first, disseny responsiu i adaptatiu, guies de plataforma (Material Design d'Android, Human Interface Guidelines d'Apple), accessibilitat (WCAG (Web Content Accessibility Guidelines) 2.1 AA, lectors de pantalla VoiceOver i TalkBack, mida de text dinàmica, contrast), i suport de mode fosc i d'orientacions.

Proves: unitàries, d'interfície (Espresso, XCUITest, Appium), en dispositius reals i granges de dispositius (Firebase Test Lab, BrowserStack), i distribució beta (TestFlight, Google Play Internal Testing, Firebase App Distribution).

Publicació: App Store i Google Play, amb els seus processos de revisió, requisits de privadesa (privacy nutrition labels, formulari de seguretat de dades), signatura de l'aplicació i gestió de versions. Per a distribució interna: MDM (Mobile Device Management)/UEM (Unified Endpoint Management) i botigues corporatives → tema 52.

CI/CD mòbil: compilació automàtica, signatura, distribució i publicació (Fastlane, Bitrise, GitHub Actions) → tema 41.

3. Arquitectura i interoperabilitat

Aspecte fonamental per garantir la interoperabilitat d'una APP empresarial o municipal amb altres sistemes: exposar i consumir les dades mitjançant API estàndard, obertes i ben documentades —típicament REST (REpresentational State Transfer, transferència d'estat representacional) amb JSON (JavaScript Object Notation) i especificació OpenAPI—, amb formats de dades i vocabularis estàndard i amb un mecanisme d'autenticació i autorització també estàndard (OAuth 2.0 / OpenID Connect). L'aplicació mòbil ha de ser un client prim sobre serveis reutilitzables, no una integració punt a punt amb la base de dades de cada sistema.

Elements de l'arquitectura:

• BFF (Backend for Frontend) o API Gateway que agrega i adapta els serveis del rerefons per al consum mòbil → tema 48.
• Patrons d'arquitectura de l'aplicació: MVC (Model-View-Controller), MVP (Model-View-Presenter), MVVM (Model-View-ViewModel), MVI, Clean Architecture.
• Sincronització i mode fora de línia: cau local (SQLite, Room, Core Data), cua d'operacions pendents, resolució de conflictes i sincronització diferencial.
• Notificacions push: FCM (Firebase Cloud Messaging) i APNs (Apple Push Notification service).
• Emmagatzematge segur: Keychain a iOS i Keystore/EncryptedSharedPreferences a Android; mai credencials en clar ni a SharedPreferences/UserDefaults.
• Analítica i estabilitat: Firebase Analytics, Crashlytics, esdeveniments de negoci — sempre amb consentiment i base de licitud.

4. Seguretat mòbil

OWASP (Open Web Application Security Project) Mobile Top 10 (2024): ús indegut de credencials · cadena de subministrament insegura · autenticació i autorització insegures · validació d'entrada i sortida insuficient · comunicació insegura · controls de privadesa inadequats · proteccions binàries insuficients · configuració incorrecta de seguretat · emmagatzematge de dades insegur · criptografia insuficient.

Mesures:

• TLS (Transport Layer Security, seguretat de la capa de transport) obligatori amb certificat fixat (certificate pinning) per als serveis crítics; bloqueig de tràfic en clar (ATS, App Transport Security, a iOS, network security config a Android).
• Autenticació: OAuth 2.0 + PKCE (Proof Key for Code Exchange) i OpenID Connect; mai guardar contrasenyes al dispositiu; ús de biometria com a segon factor local. El detall d'aquests mecanismes és a gestió d'identitats.
• Emmagatzematge: xifratge del contingut sensible i ús dels magatzems segurs del sistema.
• Ofuscació del codi i detecció de root / jailbreak i d'entorns manipulats.
• Gestió de permisos amb el principi de mínim privilegi i explicació del propòsit a l'usuari.
• Protecció de dades: base de licitud per a cada tractament, consentiment granular per a analítica i publicitat, transparència sobre els identificadors i les transferències internacionals (RGPD). Al sector públic, també l'ENS i la categorització del sistema.
• Actualització: mecanisme per forçar l'actualització quan hi ha una vulnerabilitat crítica.

5. Aplicacions mòbils al sector públic

Requisits específics:

• Accessibilitat obligatòria: el RD (Reial Decret) 1112/2018 cobreix explícitament les aplicacions per a dispositius mòbils del sector públic — WCAG 2.1 nivell AA, declaració d'accessibilitat publicada i mecanisme de comunicació per a queixes.
• Identificació i signatura: integració amb Cl@ve, idCAT Mòbil i certificats; les operacions que requereixen signatura han de complir la Llei 39/2015, art. 10.
• Notificacions: les push no substitueixen la notificació administrativa; les notificacions fefaents van per la seu i per e-NOTUM → tema 4.
• Multilingüisme: català i castellà com a mínim (EAC, art. 6 i Reglament d'ús de la llengua catalana).
• Neutralitat tecnològica: no es pot obligar el ciutadà a tenir un dispositiu o sistema operatiu concret; sempre hi ha d'haver alternativa web.
• Programari lliure i codi obert com a preferència (Mesura de digitalització oberta), amb reversibilitat i propietat del codi al plec.
• Reutilització (Llei 40/2015, art. 158): consultar el directori d'aplicacions abans de desenvolupar.
• Bretxa digital: l'app és un canal addicional, mai l'únic.

Exemples municipals: Barcelona a la butxaca, apps de mobilitat i aparcament, Decidim (participació), i les apps de la Generalitat i de l'AOC (Administració Oberta de Catalunya).

6. Desplegament massiu a l'organització

Quan l'app és per als empleats i cal desplegar-la a tots els dispositius, la via correcta és el MDM/UEM: Microsoft Intune, Jamf, Workspace ONE, SOTI MobiControl. Permet distribució silenciosa, configuració remota, botiga corporativa, contenidorització del perfil de treball, polítiques de compliment i esborrat remot selectiu. → tema 52.

Programes de les plataformes: Apple Business Manager / Volume Purchase Program i Android Enterprise / Managed Google Play per a la distribució privada d'aplicacions.

Claus d'examen

• El desavantatge de la WebApp és el maquinari, no la connexió. Entre les opcions «requereix connexió constant», «no s'actualitza automàticament» i «no funciona en diverses plataformes», la correcta és sempre l'accés limitat a càmera, GPS (Global Positioning System, sistema de posicionament global) i altres funcions del dispositiu (TS-TIC 2023 pràctica, s4 p. 7).
• PWA no és «aplicació web-nativa» ni «híbrida». Una app web que fa servir funcions modernes del navegador (service worker, manifest) per semblar-se a una nativa és una PWA; la híbrida, en canvi, va empaquetada dins d'un contenidor natiu (TS-TIC 2018 específic, p. 8).
• Interpretats vs. compilats: l'avantatge és no requerir compilació, no ser «més eficients», «més fàcils de mantenir» ni «més segurs» — les tres distraccions habituals (TS-TIC 2023 pràctica, s4 p. 8).
• Un sol sistema operatiu + accés directe a un sensor + rendiment prioritari = nativa, encara que hi hagi pressió per usar una eina cross-platform (TS-TIC 2021 pràctica, s4 p. 9).
• La usabilitat i l'accessibilitat, no els colors ni el nombre de funcions, són el que millora l'experiència d'usuari (TS-TIC 2025 pràctica, s3 p. 2).

Per recordar

• Nativa = millor rendiment i accés complet al maquinari, una base de codi per plataforma. WebApp = una sola base de codi però accés limitat al maquinari i rendiment i UX inferiors.
• Multiplataforma (Flutter, React Native, MAUI) = una base de codi amb rendiment gairebé natiu.
• La metodologia àgil al mòbil es caracteritza per iteracions curtes amb lliuraments funcionals freqüents i retroalimentació contínua de l'usuari.
• La interoperabilitat es garanteix amb API estàndard obertes i documentades (REST/JSON, OpenAPI) i OAuth 2.0 / OIDC (OpenID Connect), no amb integracions punt a punt.
• Mai credencials en clar al dispositiu: Keychain i Keystore; TLS amb pinning; OAuth 2.0 + PKCE.
• El RD 1112/2018 cobreix explícitament les apps mòbils del sector públic: WCAG 2.1 AA, declaració d'accessibilitat i mecanisme de comunicació.
• El desplegament massiu corporatiu es fa amb MDM/UEM, no per botiga pública.