26 - Tendances et avenir du mobile

Objectifs pédagogiques

À la fin de ce chapitre, vous serez capable de :

1. Comprendre Kotlin Multiplatform (KMP) et son rôle stratégique
2. Maîtriser les évolutions de Swift 6 (concurrence stricte)
3. Expliquer l'Edge AI sur device (Core ML, TensorFlow Lite, ML Kit)
4. Intégrer les LLM (Gemini, modèles on-device) dans une app mobile
5. Évaluer Jetpack Compose Multiplatform pour le partage d'UI
6. Identifier les opportunités : wearables, foldables, automotive, spatial computing

Plan du chapitre

Fichiers du chapitre

Prérequis

• Maîtrise des fondamentaux (chapitres 02 à 18)
• Curiosité technique : ce chapitre explore le futur proche du mobile

Temps estimé

• Lecture du cours : 3 h
• Projets d'exploration (KMP, ML Kit, Compose Multiplatform) : 10 h

---

Section 1 — Kotlin Multiplatform (KMP)

1.1 Qu'est-ce que KMP ?

KMP est la technologie de JetBrains (supportée par Google) qui permet de partager du code Kotlin entre plateformes : Android, iOS, desktop, web. Le code partagé compile en bytecode JVM pour Android et en code natif (via Kotlin/Native) pour iOS.

Ce que l'on partage : logique métier, modèles, repository, use cases, sérialisation, réseau. Ce que l'on ne partage pas : l'UI (au sens large) et les API spécifiques (caméra, Keychain vs Keystore).

1.2 Architecture KMP typique

shared/
  commonMain/            — code commun (Kotlin)
    domain/              — entités, use cases
    data/                — repository, API
    networking/          — Ktor client
    platform/            — expect/actual
  androidMain/           — implémentation Android (actual)
  iosMain/               — implémentation iOS (actual)

Le pattern expect/actual permet de déclarer une API commune (expect fun getSecureStorage()) et de fournir l'implémentation par plateforme (actual).

1.3 Quand adopter KMP ?

1.4 Écosystème

• Ktor Client : HTTP multiplateforme.
• kotlinx.serialization : JSON multiplateforme.
• SQLDelight : persistance multiplateforme (SQL).
• kotlinx.coroutines : coroutines partagées.
• Compose Multiplatform : l'UI partagée (section 5).

1.5 Limites et points de vigilance

• Coût d'outillage (Gradle, Xcode intégration).
• Les API expect/actual demandent une discipline d'équipe.
• Le débogage iOS depuis Kotlin/Native est moins mature.
• Swift/Objective-C interop : les types Kotlin non triviales (sealed, generics) ont des traductions Swift parfois lourdes.

1.6 Exemple minimal

// commonMain
class Greeting { fun greet(): String = "Hello from KMP" }

// expect/actual
expect fun platformName(): String
// androidMain
actual fun platformName(): String = "Android"
// iosMain
actual fun platformName(): String = "iOS"

---

Section 2 — Swift 6

2.1 Les objectifs de Swift 6

Swift 6 (2025) finalise le langage de concurrence stricte : la sécurité de la concurrence devient un objectif de compilation, pas une bonne pratique. L'objectif : « des programmes sûrs par construction ».

2.2 Concurrence stricte : les changements clés

1. Isolation stricte : les types partagés doivent être Sendable pour traverser les frontières d'isolation.
2. Région-based isolation (optionnel) : le compilateur comprend les régions mémoire, réduit les copies.
3. nonisolated et @MainActor explicites : le modèle d'isolation devient visible.
4. Migration par module : les projets peuvent migrer module par module (Swift 5 mode).
5. Concurrency checking activé par défaut : les data races sont des erreurs de compilation.

2.3 Ce que ça change pour les développeurs

2.4 Exemple typique

@MainActor
final class ProfileViewModel {
    private(set) var profile: Profile?

    func load() async {
        let profile = await service.fetchProfile()   // actor safe
        self.profile = profile
    }
}

2.5 Swift 6 et SwiftUI

• @Observable remplace ObservableObject/@Published pour un suivi plus fin.
• Le modèle d'observation « trait-based » réduit les re-rendus inutiles.
• @Entry permet d'injecter des valeurs dans l'environnement.
• Le PreviewModifier améliore les préviews avec données de test.

2.6 Stratégie d'adoption

1. Compilez vos projets en Swift 6 mode pour lister les erreurs de concurrence.
2. Corrigez module par module (les types partagés → Sendable, UI → @MainActor).
3. Utilisez les actor pour les états partagés, jamais les globals mutables.

---

Section 3 — Edge AI on-device

3.1 Pourquoi l'AI sur l'appareil ?

• Confidentialité : les données ne quittent pas le device (RGPD friendly).
• Latence : pas de réseau pour une inférence.
• Disponibilité : fonctionne hors-ligne.
• Coût : zéro coût serveur par requête.

3.2 Les trois frameworks principaux

Core ML (Apple)

• Modèles convertis au format .mlmodel (ou .mlpackage).
• Entraînement : Create ML (no-code), ou conversion depuis PyTorch/TensorFlow.
• Évaluation ultra-optimisée (Neural Engine, GPU, CPU selon le modèle).
• MLModel / MLModelConfiguration, prédiction via prediction(from:) async.

TensorFlow Lite (TFLite) — Android et multiplateforme

• Modèles .tflite convertis depuis TensorFlow/Keras.
• Délégués GPU, NNAPI, Hexagon pour l'accélération.
• Interop avec Java/Kotlin, C++ (via l'API native).

ML Kit (Google)

• API de haut niveau pour les tâches courantes : vision (barcode, text, face), langue (traduction, smart reply), objets.
• On-device par défaut, cloud en option.
• Démarrage rapide : peu de code pour des fonctionnalités utiles.

3.3 Cas d'usage classiques

3.4 Pipeline d'une app Edge AI

1. Acquisition (caméra, micro, entrée utilisateur)
2. Prétraitement (redimensionnement, normalisation)
3. Inférence (Core ML / TFLite / ML Kit)
4. Post-traitement (seuils, mapping des classes)
5. Présentation + actions

Performance : visez < 100 ms par inférence pour une expérience fluide. Mesurez sur device réel (Neural Engine vs GPU vs CPU).

3.5 Bonnes pratiques

• Quantification : Int8/FP16 réduisent la taille (jusqu'à 4×) pour ~1 % de perte.
• Batching : regroupez les inférences pour amortir les coûts.
• Déploiement à chaud : téléchargez les modèles à la demande (Core ML config, ML Kit download).
• Fallback cloud : pour les modèles trop lourds, avec respect de la vie privée.

---

Section 4 — Gemini et intégration LLM

4.1 Les LLM dans le mobile : les approches

4.2 Gemini Nano et AI Core

• Gemini Nano : le modèle de Google optimisé pour les appareils Android (Pixel, Samsung).
• AI Core : le service système qui gère l'exécution du modèle.
• AICore APIs : intégration de haut niveau pour les tâches courantes (résumé, rewrite, smart reply) via Android AICore APIs (ML Kit).

4.3 Intégration classique avec l'API Gemini (Android/iOS)

1. Clé API / OAuth dans le backend (jamais dans l'app).
2. SDK (Google AI client SDK) ou HTTP : POST /v1beta/models/gemini-2.x:generateContent.
3. Stream des réponses (SSE) pour l'UX conversationnelle.
4. Gérer : rate limits, retries, erreurs, token budgets.

Sécurité : la clé API ne doit jamais être embarquée dans l'app (extractible). Passez par un serveur mandataire.

4.4 Design d'une expérience LLM

1. Prompt system : définir le rôle, le ton, les limites.
2. Grounding : donner le contexte métier (données de l'app).
3. Streaming : afficher les tokens au fur et à mesure.
4. Limites : bloquer les prompts hors-périmètre (filtering).
5. Fallback : si le LLM échoue, offrir une réponse locale.
6. Coût : cache, résumés, taille des prompts maîtrisée.

4.5 Évaluation

• Latence perçue (TTFT : time to first token).
• Qualité (échantillons évalués manuellement).
• Coût par session (budget).
• Erreurs/refus (hallucinations, contenu bloqué).

---

Section 5 — Jetpack Compose Multiplatform

5.1 Qu'est-ce que CMP ?

Compose Multiplatform est le portage de Jetpack Compose à d'autres plateformes : iOS, desktop (JVM), web. Le même code Compose peut dessiner l'UI sur Android et iOS, avec des points d'intégration natifs.

5.2 Architecture d'une app CMP

composeApp/
  commonMain/            — UI Compose partagée
    App.kt               — composables
  androidMain/           — activité hôte
  iosMain/               — host (UIViewController)

Côté iOS, le composable est exposé via un UIViewControllerRepresentable ; côté Android, via une ComponentActivity.

5.3 Forces

• UI 100 % partagée : cohérence visuelle parfaite entre plateformes.
• Kotlin partout : même langage pour l'UI et la logique.
• Écosystème Compose : Material 3, navigation, animations.

5.4 Limites (à évaluer)

• Les bibliothèques UI natives (Cupertino, intégrations spécifiques) restent à réécrire.
• Les performances iOS sont encore en évolution (génération de code, Skiko).
• Le rendu ne suit pas les conventions natives iOS par défaut (il faut les implémenter).

5.5 Stratégie

---

Section 6 — Wearables

6.1 L'écosystème

6.2 Conception pour un petit écran

1. Glanceable : informations en 2-3 secondes.
2. Actions courtes : tap, swipe, pas de textes longs.
3. Complications : widgets sur le cadran (données utiles d'un coup d'œil).
4. Synergie phone/watch : l'app phone fait le gros, la watch affiche.
5. Batterie : les capteurs (HR) consomment ; batchez et réduisez la fréquence.

6.3 Compose pour Wear OS

• Scaffold adapté (TimeText, PositionedIndicator).
• Navigation par SwipeDismissableNavHost.
• MaterialTheme spécifique wear.
• Tiles : UI de type carte sans app ouverte.

6.4 watchOS SwiftUI

• WKApplication / WKInterfaceController (legacy) vs SwiftUI.
• ComplicationController pour les complications.
• HealthKit pour la santé ; WCSession pour la communication phone/watch.
• Watch faces avec widgets (SwiftUI WidgetKit).

---

Section 7 — Foldables et écrans adaptatifs

7.1 Les facteurs de forme

7.2 Les défis techniques

1. Configuration changes : le pliage change la taille → recréation d'activité. Utilisez android:configChanges avec précaution, ou mieux : des layouts adaptatifs robustes.
2. Resizable : même hors foldables, le mode fenêtré multi-tâches impose des layouts adaptatifs.
3. Hinge : éviter les éléments dans la charnière (zone d'occlusion).
4. Orientation : portrait/paysage sur 2 panneaux → qualifiers sw600dp, resizable.

7.3 Outils et bonnes pratiques

• WindowManager / Jetpack Window : currentWindowMetrics pour les tailles réelles.
• Breakpoints : compact (0-599dp), medium (600-839dp), expanded (840dp+).
• Compose : BoxWithConstraints pour les layout adaptatifs ; Material3 adaptive components (NavigationSuites).
• Canary Checks (Play Console) : tests sur foldables virtuels.
• Testez sur émulateur foldable (configurations plié/déplié).

7.4 iOS : vision générale

Sur iPadOS, le multitâching (Split View, Stage Manager) impose la même discipline de layouts adaptatifs. size classes et UISplitViewController restent les outils clés ; SwiftUI gère ces cas avec des vues conditionnelles par horizontalSizeClass.

---

Section 8 — Automotive

8.1 Les plateformes

8.2 Règles de design embarqué (sécurité routière)

1. Minimum tap : réduire les interactions.
2. Pas de texte long : lecture en mouvement interdite.
3. Conseils audios : répondre par la voix quand possible.
4. Templates imposés : Android Auto/CarPlay imposent des modèles de vues certifiés.

8.3 Intégration pour un développeur mobile

• Android Auto : configurer les « template categories » (Navigation, Media, Communication) dans le manifeste.
• CarPlay : CarPlayAppDelegate avec CPTemplateApplicationSceneDelegate.
• AAOS : l'app tourne directement sur l'unité centrale (nouveaux APIs : Car App Library).
• Digital Key : NFC/UWB pour ouvrir/démarrer la voiture depuis le téléphone.

8.4 Opportunités

• Vente de véhicules + apps companion (état, contrôle à distance).
• Navigation enrichie (EV routing pour véhicules électriques).
• Infotainment personnalisé.

---

Section 9 — Spatial computing (Vision Pro / visionOS)

9.1 Le paradigme

visionOS (Apple Vision Pro, 2024) introduit le spatial computing : pas un VR casque fermé, mais un système qui mélange le monde physique et les fenêtres 3D. Les apps s'organisent en windows, volumes et spaces.

9.2 Concepts clés visionOS

9.3 Développer pour visionOS

• SwiftUI est le framework de choix ; UIKit est bridé.
• RealityKit pour le 3D : modèles .usdz, matériaux physiquement réalistes.
• ARKit (sur le device) : tracking du monde, occlusion, plane detection.
• Gestes : regard (eye tracking), pincement, mains, voix.
• Conception : ne pas surcharger, respecter la profondeur, penser à la fatigue.

9.4 Impact sur le métier mobile

• Nouvelles compétences : 3D, spatial UX, capteurs.
• Nouveaux cas d'usage : éducation, santé, retail (essayage), collaboration.
• Les fondamentaux (Swift, SwiftUI, architecture) restent la base : visionOS est une extension, pas une rupture.

9.5 La concurrence

---

Section 10 — Comment se positionner

10.1 Les compétences de demain

10.2 Stratégie d'apprentissage

1. Maîtrisez les fondamentaux (chapitres 02-18) : ils ne changent pas.
2. Choisissez UNE tendance à explorer en profondeur (projet de 2-3 mois).
3. Apprenez la logique de la veille (chapitre 22) pour suivre le rythme.
4. Gardez du temps pour les fondamentaux : les tendances passent, les bases restent.

10.3 Projets d'exploration suggérés

10.4 Ce qui ne change pas

• L'expérience utilisateur et l'accessibilité.
• L'architecture, les tests, la qualité.
• La sécurité et la vie privée (RGPD).
• La performance et l'observabilité.

---

Synthèse

Pour aller plus loin

1. Choisissez une tendance et réalisez le projet d'exploration associé.
2. Suivez les conférences du chapitre 22 (Google I/O, WWDC) pour les annonces à jour.
3. Relisez ce chapitre chaque année : les tendances évoluent vite.