Kotlin Multiplateforme pour Agents IA : Avantages, Inconvénients et Pièges de Publication
Développer deux applications avec Kotlin Multiplateforme (KMP) pendant six mois a révélé des enseignements clés : réutilisation de code entre Android, iOS, Web, Desktop et backend. Le code partagé des agents s'intégrait avec des bibliothèques comme koog, mcp-sdk et cactus pour des modèles locaux. L'expérience pratique a mis en lumière l'équilibre entre l'écosystème robuste de la JVM et les obstacles spécifiques aux plateformes.
Avantages Clés de KMP
KMP centralise la logique métier des agents, réduisant drastiquement la duplication. L'écosystème JVM offre des SDK pour les fournisseurs de LLM, tandis que Compose Multiplateforme simplifie l'UI avec rechargement à chaud. Les builds natifs Android exploitent Skia pour iOS, bien que Desktop repose sur des wrappers JAR.
Avantages principaux :
- Réutilisation de code agnostique sur 4+ cibles.
- Écosystème JVM riche pour agents et modèles.
- Kotlin stable avec rétrocompatibilité.
- Compose avec glitches UI minimes.
Limites Évidentes
Le support multiplateforme exige expect/actual pour le code spécifique. Les apps Desktop gonflent à cause des dépendances JVM et Swing, le Web reste en bêta avec bugs de bibliothèques et problèmes SEO. Le débogage iOS semble basique, l'interop Swift traîne derrière la JVM. L'UI Desktop paraît souvent dépareillée.
Défis Cachés de Développement
Les builds de release macOS prennent des semaines : deux ID d'apps (JRE et app), trois clés de signature, configs séparées pour app stores et DMG avec notarisation (15+ min par itération). Les bibliothèques natives compliquent tout — ressources dans JAR avant signature, exclusions ProGuard, compatibilité Catalina (63 % des users). TestFlight requiert JDK 18+, plus builds séparés aarch64/x86_64.
Étapes typiques de release :
- Générer clés pour stores et distribution directe.
- Intégrer ressources natives dans JAR.
- Gérer obfuscation ProGuard.
- Notarisation et débogage (5+ itérations).
- Tests sur macOS legacy.
Manque d'experts seniors KMP : le marché favorise les devs mono-plateforme. Tâches spécifiques (certificats gov iOS vs Android) exigent expertise pointue. Les LLM peinent sur cas limites.
Conflits de Bibliothèques et Sur-ingénierie
Bibliothèques alpha comme kotlinx-datetime déclenchent clashes de versions : koog tire des deps incompatibles depuis septembre. Web manque Dispatchers.IO, forçant branches dans code partagé. Déléguer logique JVM pour Android/Desktop/backend allonge compilation mais duplique réflexion.
Choix malins :
- Code partagé JVM : compromis sur réflexion.
- Loggers : équilibre logback et defaults sensés.
- Tests : mock context Android, ajouter Desktop pour vitesse.
Xcode empire la douleur : lancements lents, autocomplétion laggy, crashes aléatoires. Seulement 6,1 % des devs Stack Overflow 2025 tolèrent ça.
Construire Agents IA Sans Frameworks
Abandonné langchain4j (gonflé, obsolète) et koog (alpha, deps excessives comme simpleOpenAIExecutor). Implémentation custom : graphe de nœuds avec callbacks de transition, classification, RAG, gestion erreurs. Gains : contrôle total, deps minimales, pas de bloat OpenTelemetry.
Graphes d'agents visualisables pour debug, persistance machine d'état manuelle pour résilience. Tests ciblent code partagé avec mocks plateforme.
Tester le Code des Agents
Tests sur iOS/Android avec mock context. Desktop accélère CI. Problèmes : compilations longues, Dispatchers plateforme-dépendants. Meilleure pratique : tests unitaires JVM, tests d'intégration spécifiques.
Enseignements clés :
- Releases macOS exigent semaines pour clés, notarisation, ProGuard.
- Conflits versions bibliothèques alpha (kotlinx-datetime) cassent builds.
- Agents custom surpassent frameworks pour LLM niche (comme GigaChat).
- Seniors KMP rares ; compétences plateforme essentielles.
- Xcode bottleneck dev iOS.
Verdict global : KMP rentable pour agents IA avec backends JVM, mais releases et iOS/Web demandent expertise sérieuse.
— Editorial Team
Aucun commentaire pour le moment.