Swift Connection 2025

Dev, cloud & sécu6–7 octobre 2025Paris, Théâtre de Paris9e édition (ex-FrenchKit)

Site officiel (nouvel onglet) ↗Programme (nouvel onglet) ↗Chaîne YouTube (nouvel onglet) ↗Synthèse de octobre 2025 →

Conférence iOS / Swift en anglais, 1,5 jour (lundi 6 octobre après-midi, mardi 7 octobre) au Théâtre de Paris (15 rue Blanche, Paris 9e) : 22 sessions (talks de 35 min, lightning talks de 15 min, keynote de clôture de Peter Steinberger), 3 « classrooms » gratuites de 75 min (30 places) et une soirée. Sponsors : Guardsquare (gold), Coyote et leboncoin (silver). Organisée par Tech Connection, avec un Speaker Inclusion Programme.

Swift Connection 2025 s'est jouée entre deux nouveautés d'Apple décortiquées (Liquid Glass, Foundation Models) et l'irruption du développement agentique jusque dans la keynote de clôture, avec en fil rouge un conseil très pragmatique : s'appuyer d'abord sur ce que la plateforme fournit (composants natifs, accessibilité, SDK) avant de réinventer.

15 sessions résumées · 15 vidéos · mise à jour le mardi 29 septembre 2026 · synthèse à compléter

Sources lues et limites de cette synthèse

Corpus : Programme officiel (site 2025.swiftconnection.io), 22 vidéos officielles de la chaîne YouTube Tech Connection (publiées le 23/10/2025) dont 11 transcripts lus (keynote de clôture et talks les plus vus), le compte-rendu du blog Ippon (15/10/2025, 4 auteurs, 7 talks), ~10 posts Mastodon (#SwiftConnection, 3 au 13/10/2025) et un post LinkedIn de RATP Smart Systems. 9 recherches web.

Limites : Corpus lu à J+1 an, mais très peu de retours participants publics : l'essentiel des résumés vient des transcripts (ce qui a été dit sur scène) et d'un seul blog d'ESN. Les retours Mastodon sont brefs et viennent en partie de speakers ou de l'équipe (signalés). Aucun post LinkedIn individuel ni thread X/Bluesky n'a pu être lu (X fermé sans compte, recherche Bluesky non accessible) ; le chiffre de 450 participants (« biggest conference ever ») n'apparaît que dans un extrait de résultat de recherche attribué aux organisateurs, non vérifié à la source. Les compteurs de vues YouTube (8 200 pour Steinberger, 2 900 pour Ricouard, 2 000 pour Rambo, au 29/09/2026) servent d'indicateur d'intérêt, pas de retour.

Synthèse globale

1. Les agents de code entrent par la grande porte, keynote comprise

L'IA n'était pas le thème affiché, mais elle a encadré la deuxième journée : live coding sans ouvrir Xcode avec Cursor, Claude Code et XcodeBuildMCP le matin (Ricouard), keynote de clôture de Peter Steinberger l'après-midi, et une classroom « Create Your Own Agent in 75 Minutes ». Les deux speakers tracent la même ligne de partage : le vibe coding pour explorer, l'ingénierie agentique (contexte écrit, contraintes, relecture, tests) pour un code qu'on maintient. Côté audience, ce sont de loin les vidéos les plus regardées (~8 200 et ~2 900 vues), et le blog Ippon en tire la conclusion qu'il faut vite maîtriser ces outils (Vincent Blanchet). L'IA apparaît aussi côté produit, en version on-device, gratuite et privée avec Foundation Models (Logan), un sujet jugé prometteur mais encore montré sur des cas simples (Dylan Le Hir, Ippon).

2. Liquid Glass, de l'API publique au Core Animation privé

Deux talks enchaînés le lundi ont couvert iOS 26 à deux niveaux. Mikaela Caron a fait le tour des nouveaux modificateurs SwiftUI en conseillant de passer d'abord par les composants système et de rester prudent, l'API ayant bougé à chaque bêta. Gui Rambo a ensuite démonté l'effet : backdrop layers, filtres privés, signed distance fields, une dizaine de couches pour un simple toggle. Tous deux reconnaissent d'emblée la controverse sur la lisibilité ; Rambo en fait un argument pour comprendre ce qu'on utilise. C'est l'un des talks cités parmi les préférés sur Mastodon (@tuparev).

3. « Utilisez ce qu'Apple vous donne »

Un conseil revient dans des talks très différents : partir de la plateforme avant de construire. Pour l'accessibilité, composant natif, puis natif personnalisé, puis custom en dernier recours, avec accessibilityRepresentation comme passerelle (Freiband). Pour les composants SwiftUI, copier les patterns d'Apple : environnement, modificateurs, préférences, « readers » (Durand). Pour Liquid Glass, s'inspirer des apps d'Apple (Caron). Pour Linux, le Static Linux SDK et le framework Containerization plutôt que Docker (Krzyzanowski). Même la critique d'Error par Cihat Gündüz se conclut sur un package pensé pour devenir, un jour, une proposition au langage.

4. Industrialiser : tests, CI et sécurité du binaire

Une série de talks plus « usine logicielle » a complété le programme : selective testing et modularisation pour diviser le temps de CI par deux (Gerasymenko, qui note au passage que la modularisation aide aussi l'IA à raisonner) ; ce que le bundle livré expose vraiment et comment on l'altère (Hopstock, Guardsquare) ; une gestion d'erreurs qui sert à la fois l'utilisateur et le debug (Gündüz). Swift Testing et les régressions d'analytics figuraient aussi au programme, sans retour trouvé.

5. Le design et l'humain comme contrepoint

Plusieurs sessions ont décalé le regard vers l'utilisateur et le speaker : habitudes saines contre dark patterns (Tamia James), interfaces « post-écran » et confiance (Maxim Cramer, qui a poussé Dan Perocheau à réfléchir au « pourquoi » plutôt qu'au « comment »), deux façons de préparer un talk (Holtz et Brass). Ces talks se répondent : Freiband reprend Don Norman après Cramer, Caron renvoie la salle vers la designer Tamia James. Le compte-rendu Ippon, écrit par quatre développeurs, retient justement ces talks non techniques parmi les plus marquants.

6. La vie de l'événement

Format ramassé (un après-midi et une journée) dans un théâtre dont le lieu a frappé (« The venue […] is sick! », Cihat Gündüz, speaker), classrooms gratuites en petit groupe, soirée le lundi. Le Speaker Inclusion Programme se voit dans les retours : Ellen Shapiro, de l'équipe, salue les speakers débutants qui ont « absolutely kill[ed] it », et Manuel Kehl raconte avoir fini ses slides dans le train pour son premier talk. Toutes les vidéos ont été mises en ligne 16 jours après l'événement. La présence est attestée par des équipes d'entreprises (six développeurs de RATP Smart Systems, quatre d'Ippon).

7. Tensions et biais du corpus

  • Swift contre l'efficacité des agents : Steinberger explique, « hérésie » assumée, avoir construit son app iOS en React Native et son app Mac en Tauri, parce que l'écosystème et les données d'entraînement comptent plus que le langage. Ricouard reconnaît que le debug reste meilleur dans Xcode et que les modèles maîtrisent mal les API récentes.
  • Liquid Glass reste discuté (lisibilité, API instable) même chez ceux qui l'expliquent.
  • Le sponsor sur scène : le talk sécurité vient du sponsor gold, et ses parades renvoient à son offre.
  • Biais : un seul compte-rendu détaillé (une ESN), des posts Mastodon brefs et souvent écrits par des speakers ou l'équipe, aucun retour LinkedIn individuel lu. Les résumés reposent surtout sur les transcripts, donc sur ce qui a été dit sur scène plus que sur ce qu'en a retenu la salle.

Actions concrètes citées

  1. Adopter Liquid Glass d'abord par les composants système (barres, toolbars, recherche) en compilant avec Xcode 26 ; ne personnaliser qu'avec parcimonie, l'API ayant changé à chaque bêta (Caron).
  2. Pour l'accessibilité, suivre l'ordre : composant Apple, puis composant Apple personnalisé, puis composant 100 % custom ; accessibilityRepresentation permet de garder un visuel maison avec le comportement VoiceOver d'un contrôle natif (Freiband).
  3. Tester les modèles on-device (Foundation Models) pour les petites tâches : gratuits, privés, hors ligne ; structurer la sortie avec @Generable et dire explicitement au modèle d'utiliser ses outils (Logan).
  4. Avec un agent de code, écrire les contraintes du projet (version minimale d'iOS, conventions, docs de frameworks) dans des fichiers Markdown de contexte, et limiter les MCP qui saturent la fenêtre de contexte (Ricouard, Steinberger).
  5. Modulariser l'app pour pouvoir ne lancer que les tests impactés : ~50 % de temps de CI en moins avec un outil open source de selective testing (Gerasymenko).
  6. Savoir ce que contient réellement le bundle livré (métadonnées Objective-C/Swift, Info.plist, profil de signature) et définir son modèle d'attaquant avant d'ajouter des protections (Hopstock).
  7. Lancer des erreurs pour signaler une hypothèse non tenue, avec un message utilisateur explicite et un contexte de chaîne d'erreurs pour le debug, plutôt que retourner nil (Gündüz).
  8. Concevoir les composants SwiftUI comme Apple : options via modificateurs et environnement, sorties via préférences, et regarder d'abord le site d'appel (Durand).

Session par session

Lundi 6 octobre

Conférence▶ vidéo

The Science of Habit-Forming Apps: Designing for Engagement

Tamia James — Women In Design (co-chair), UX designer

Retours : Dylan Le Hir (blog Ippon)

  • Distinction entre dark patterns (paiements imposés, renouvellements automatiques, désabonnement volontairement compliqué) et engagement sain, présentée à travers le Hook Model de Nir Eyal : déclencheur, action, récompense, investissement.
  • Exemples cités : les notifications de Duolingo qui entretiennent les séries, le système de récompense d'Instagram.
  • Message : créer des habitudes positives qui respectent l'utilisateur plutôt que d'exploiter ses faiblesses, en mariant technique et psychologie.
  • Retour (Ippon) : pédagogie très claire, mais la typologie des dark patterns n'est qu'effleurée.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Hello Foundation Models

Alex Logan — Applause

Retours : Dylan Le Hir (blog Ippon)

  • Sur scène : un projet de coach de course à pied IA, abandonné car trop cher en appels OpenAI, relancé en deux minutes avec Foundation Models. Le framework est gratuit, privé par défaut, hors ligne et rapide sur un iPhone récent.
  • Le minimum : une LanguageModelSession avec des instructions, plus vérifier la disponibilité (Apple Intelligence activée, modèle téléchargé). Réponses en streaming, guided generation avec @Generable et @Guide (aussi simple qu'un Codable), et tools pour brancher le modèle sur des API.
  • Piège relevé : sans consigne explicite d'utiliser un tool, le modèle invente (des pilotes de F1 retraités donnés en tête du championnat).
  • Q&A : fixer la température pour stabiliser les réponses, générer en anglais puis passer par le framework Translation, contourner les guardrails trop sensibles (une recommandation du Moulin Rouge censurée).
  • Retour (Ippon) : sujet entièrement nouveau et potentiel immense, mais démo basique ; on aurait aimé des cas d'usage plus professionnels.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo

Designing for the Post-Screen Era

Maxim Cramer — MENNENIA

Retours : Dan Perocheau (blog Ippon), Ben Freiband (référence dans son talk, speaker)

  • Les interfaces de l'ère « post-écran » dépassent l'écran visible : le vrai défi n'est pas la sophistication technique mais des systèmes compréhensibles et dignes de confiance, qui savent s'effacer.
  • Référence à Don Norman : si une porte a besoin d'un panneau Pousser/Tirer, le design a échoué. L'IA doit devenir un partenaire adaptatif et conscient du contexte.
  • Contre-exemple cité : un iPhone qui détecte une séance de vélo et demande une validation par hochement de tête, dangereux et hors contexte.
  • Retour (Ippon) : talk jugé clair, structuré et riche en exemples, qui a poussé un développeur plutôt tourné vers le « comment » à réfléchir au « pourquoi » ; questions ouvertes sur l'éthique, le contrôle utilisateur et le rôle des App Intents. Ben Freiband a repris la référence à Don Norman le lendemain.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

The Technical Side of Liquid Glass

Mikaela Caron — développeuse iOS indépendante, Swift Ecosystem Workgroup

  • Sur scène : Liquid Glass reçoit des avis partagés ; la clé UIDesignRequiresCompatibility permet de le désactiver, mais la doc la présente comme temporaire.
  • Le plus simple : les composants système. Barres, sheets, popovers et contrôles reçoivent Liquid Glass dès la compilation avec Xcode 26 ; c'est la navigation qui porte le verre, pas le contenu.
  • Tour des nouvelles API : backgroundExtensionEffect, tabBarMinimizeBehavior(.onScrollDown), tabViewBottomAccessory, ToolbarSpacer, sharedBackgroundVisibility(.hidden) (utilisé quasi uniquement dans Livres), recherche désormais en bas sur iPhone, rôles de bouton (.confirm, .cancel, .close), styles .glass et .glassProminent, GlassEffectContainer, glassEffectID, .interactive().
  • Conseil pragmatique : l'API a changé à chaque bêta, donc désactiver ou n'activer que les toolbars, le signal le plus visible d'une app « à jour ». Pour garder d'anciennes versions d'iOS, un modificateur de compatibilité, au risque de casser l'identité des vues et les animations.
  • Fil rouge humoristique : « demandez à Tamia » (la designer du talk précédent) ; pour des exemples, copier les apps d'Apple.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Inside Liquid Glass: How iOS 26 Synthesizes Refractive UI

Gui Rambo — développeur Mac/iOS (AirBuddy, VirtualBuddy), chercheur en sécurité

Retours : @tuparev (Mastodon, un de ses talks préférés)

  • Sur scène : Liquid Glass comme prétexte pour parler de Core Animation, et de ses API privées (à but pédagogique, pas à utiliser). Rambo admet d'emblée la controverse sur la lisibilité.
  • Briques anciennes : CABackdropLayer (échantillonne ce qui est derrière, base des flous depuis iOS 7), CAFilter (filtres temps réel sur GPU), CAPortalLayer (copie d'un calque ailleurs).
  • Nouveau dans iOS 26 : les signed distance fields (SDF) via CASDFLayer et CASDFElementLayer, qui génèrent une carte de normales ; le filtre glass background (une cinquantaine de paramètres) produit la réfraction, le lissage donne l'effet « blobby » de fusion.
  • Démontage du bouton toggle : déplacement, réfraction, flou, voile, ombre teintée, filtre glass foreground (aberration chromatique), reflet spéculaire et bord sombre. Liquid Glass n'est pas un effet mais un empilement.
  • Q&A : les ingénieurs d'Apple passent surtout par une API SwiftUI privée ; reproduire l'effet sous iOS 26 est possible avec un shader Metal ; coût en performance et batterie supérieur au flou « frosted » classique.
  • Rendu vidéo 4K des arborescences de calques réalisé avec un outillage maison. Un des talks les plus vus de l'édition (~2 000 vues).
Voir sur YouTube (nouvel onglet) ↗

Lightning talk▶ vidéo

Live Activities - Notifications That Users Actually Enjoy

Maxime de Chalendar — Yubo

Retours : Vincent Blanchet (blog Ippon)

  • Les Live Activities sont sous-exploitées : elles conviennent à toute fonctionnalité temporelle ou événementielle, pas seulement au VTC ou à la livraison.
  • Architecture : ActivityKit gère la logique et le cycle de vie, WidgetKit le rendu ; extension possible à l'Apple Watch.
  • Exemples créatifs cités : Lumy (cycle solaire), Flighty (vols en temps réel), Pixel Pals (compagnon dans la Dynamic Island), Tinder (compte à rebours des boosts).
  • Retour (Ippon) : talk techniquement solide et sans excès ; barrière d'entrée faible, gain UX élevé, et un avantage concurrentiel tant que peu d'apps s'en servent. Recommandation : auditer ses apps pour y trouver des cas d'usage.
Voir sur YouTube (nouvel onglet) ↗

Lightning talk▶ vidéo + transcript

Swift on Linux on Mac

Marcin Krzyzanowski — créateur de CryptoSwift, Notepad.exe

Retours : @tuparev (Mastodon, un de ses talks préférés)

  • Sur scène : un atelier de deux heures condensé en dix minutes. Comment écrire du Swift sur Mac et le faire tourner sous Linux sans Docker, sans SSH.
  • Le compilateur est le même, seul le SDK change ; SwiftPM fait le gros du travail. Le Static Linux SDK produit sur Mac un binaire ELF autonome qui tourne sur n'importe quelle distribution.
  • Pour l'exécuter : le framework Containerization d'Apple (open source, en Swift), images OCI, une micro-VM par conteneur qui démarre en moins d'une seconde, sans démon, gratuit (contre Docker Desktop, gourmand et parfois payant).
  • Démo dans son éditeur Notepad.exe, code Mac et Linux côte à côte. Q&A : debug via LLDB distant ; compiler et tester sur Mac ne suffit pas, car Foundation et le runtime diffèrent sous Linux.
Voir sur YouTube (nouvel onglet) ↗

Mardi 7 octobre

Conférence▶ vidéo + transcript

Building iOS Apps Without Xcode, Using Cursor, Claude Code and XcodeBuildMCP

Thomas Ricouard — Medium

Retours : Vincent Blanchet (blog Ippon)

  • Sur scène : live coding d'une app compteur sans ouvrir Xcode. Cursor (extension SweetPad pour builder et lancer, complétion « tab »), Claude Code branché sur XcodeBuildMCP qui crée le projet, lance le simulateur, tape sur les boutons et prend des captures pour vérifier son travail.
  • Enchaînement : correction d'un bug de persistance (UserDefaults), puis simplification demandée vers @AppStorage, embellissement « laisse parler ta créativité » (dégradés, confettis), refonte avec un onglet Charts.
  • Distinction assumée : le vibe coding pour explorer des idées, l'assistant guidé (contraintes, relecture) pour un code qu'on maintiendra dix ans.
  • Q&A : écrire dans un fichier de contexte (CLAUDE.md) la version minimale d'iOS, car les modèles sont plus à l'aise avec les anciennes API ; des fichiers Markdown par framework (Swift Testing…) ; le debug reste meilleur dans Xcode ; passer aux groupes basés sur les dossiers pour éviter de casser le .pbxproj. Chez Medium, l'app historique reste surtout travaillée dans Xcode, une nouvelle app est outillée « agents » dès le départ.
  • Retour (Ippon) : un live coding dynamique et risqué qui montre clairement la puissance des outils ; il faut vite les maîtriser, car ils changent la vitesse de développement. Deuxième vidéo la plus vue (~2 900 vues).
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

What Really Happens to Your iOS App During Compilation - and What It Exposes

Samuel Hopstock — Guardsquare

  • Sur scène : on protège jalousement le code source, mais personne ne sait ce que contient le bundle livré. Tour du contenu : Info.plist (indices comme NSAllowsArbitraryLoads, URL schemes), embedded.mobileprovision, frameworks, binaire Mach-O et ses segments.
  • Les dSYM restent privés, mais les métadonnées Objective-C et Swift sont dans le binaire (noms de classes, propriétés, sélecteurs), indispensables au runtime et lisibles avec ipsw.
  • Techniques d'altération : hooking via la GOT, inline hooking (type Frida), swizzling Objective-C, reconditionnement de l'IPA puis re-signature (apps « premium » crackées, YouTube sans pub).
  • Parades : contrôles d'intégrité et de signature discrets et imbriqués, monitoring plutôt que crash systématique, et surtout du code sûr : suivre OWASP MASVS/MASTG (plus adaptés au mobile que le Top 10 web), intégrer l'analyse en CI.
  • À noter : talk du sponsor gold (Guardsquare) ; les parades renvoient à son offre.
Voir sur YouTube (nouvel onglet) ↗

Lightning talk▶ vidéo + transcript

Streamlining iOS Development with Selective Testing

Mike Gerasymenko — Delivery Hero

  • Sur scène : un talk refusé au moins cinq fois ailleurs, accepté ici en format court. Principe : à partir du diff git et de la structure du projet (pbxproj, Package.swift), ne lancer que les tests des modules impactés.
  • Outil open source XcodeSelectiveTesting : ~50 % de temps de CI en moins chez Delivery Hero ; XCTest, UI tests, Swift Testing, projets Xcode, SPM, Linux.
  • Effets de bord : la couverture de code devient trompeuse (à mesurer par module) et des tests flaky peuvent passer entre les mailles.
  • Alternative : Tuist (payant, cache de résultats côté serveur) : de 30 à 8 minutes par PR. Prérequis commun : la modularisation, qui aide aussi l'IA à raisonner sur un contexte réduit. Q&A : un mode « turbo » qui ignore les dépendants.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo

A Talk... Two Ways

Josh Holtz — RevenueCat, fastlane, Zach Brass — UnderdogDevs

Retours : Dan Perocheau (blog Ippon)

  • Un talk « méta » sur la manière de présenter : sur-préparation méthodique (script mémorisé, pauses planifiées, Zach) contre spontanéité (slides de dernière minute, improvisation, Josh).
  • Dispositif : chacun présente les slides de l'autre dans le style opposé, ce qui révèle les forces de chaque approche. Pas de bonne méthode unique : rythme, intention envers le public et connexion comptent plus que le format.
  • Retour (Ippon) : peu de Swift, mais une valeur pédagogique qui s'applique aux présentations internes comme aux conférences ; la complicité des deux speakers a tenu l'attention. Ben Freiband y fait référence dans son propre talk.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

What People Get Wrong with Accessibility

Ben Freiband — Duo Security (Duo Mobile), CommunityKit

Retours : Olivier Geffroy (blog Ippon)

  • Sur scène : REX d'une petite équipe iOS (Duo Mobile, ~4,85 M d'utilisateurs mensuels, clients publics et académiques exigeants). Une app accessible n'est pas seulement une app où l'on peut agir, mais où l'on découvre ce qu'on peut faire : affordances et signifiants (Don Norman), valables pour tous.
  • Stratégie en trois temps : composant Apple, sinon composant Apple personnalisé, et seulement ensuite du 100 % custom.
  • Démo VoiceOver sur une fausse « Apple Store » (de pommes) : GroupBox au lieu d'un titre marqué à la main ; accessibilityRepresentation pour donner à des boutons en forme de pomme le comportement d'un Stepper natif ; accessibilityHidden pour l'image décorative ; accessibilityLabel pour neutraliser les emojis. Mention de l'European Accessibility Act.
  • Retour (Ippon) : accessibilité et utilisabilité vont de pair ; l'accessibilité est présentée comme un prolongement de la clarté du design, pas comme un coût.
Voir sur YouTube (nouvel onglet) ↗

Lightning talk▶ vidéo + transcript

Crafting Reusable SwiftUI Components the Same Way Apple Does!

Thomas Durand — développeur indépendant (ButtonKit)

Retours : @tuparev (Mastodon, un de ses talks préférés)

  • Sur scène : leçons tirées de ButtonKit (boutons asynchrones avec chargement, erreurs et progression). Partir du site d'appel et minimiser entrées et sorties d'un composant.
  • Entrées optionnelles : pas une cascade de paramètres par défaut, mais l'environnement exposé par un modificateur de vue, comme les API d'Apple. Pour un contrôle, un Binding, et respecter controlSize ou disabled.
  • Sorties en lecture seule : un callback sous forme de modificateur, implémenté par PreferenceKey (l'environnement écraserait les modificateurs empilés), puis un « reader » à la manière de GeometryReader.
  • Q&A : tester son API en la poussant dans des usages improbables (recréer le bouton de téléchargement de l'App Store avec ButtonKit).
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Better Error Handling in Swift: From Obj-C Legacy to Swift 6 Power

Cihat Gündüz — développeur indépendant (TranslateKit, ErrorKit)

Retours : @tuparev (Mastodon, un de ses talks préférés)

  • Sur scène : try? et return nil, c'est de l'« error ignoring » ; print(error), de l'« error debugging ». Il faut lancer une erreur dès qu'une hypothèse ne tient pas.
  • Critique du protocole Error (vide, localizedDescription qui n'appelle pas la surcharge, héritage NSError) et de LocalizedError (quatre propriétés optionnelles ambiguës).
  • Proposition : un protocole Throwable avec un userFriendlyMessage obligatoire. Les typed throws de Swift 6 permettent un switch exhaustif mais mènent à l'« error nesting hell » ; un protocole Catching (cas caught) et une errorChainDescription restituent la chaîne d'appels.
  • Le tout dans le package open source ErrorKit (MIT) : mapping de messages système cryptiques, types d'erreurs prêts à l'emploi, compositeur de mail SwiftUI avec pièces jointes de logs. Rappel : rendre les messages d'erreur sélectionnables.
  • Q&A : partir d'un package pour prouver l'idée avant un pitch sur les forums Swift.
Voir sur YouTube (nouvel onglet) ↗

Keynote▶ vidéo + transcript

You Can Just Do Things

Peter Steinberger — fondateur de PSPDFKit

  • Sur scène : keynote de clôture sans code, venue « réveiller » une communauté iOS encore sceptique face à l'IA. Récit personnel : burn-out après la vente de PSPDFKit (2021), puis l'étincelle retrouvée en avril 2025 grâce aux agents de code.
  • Constats chiffrés (repris de sources tierces) : progression de SWE-bench Verified (de ~20 % à 82 % dans l'année), baisse du prix des tokens, un quart de la promo W25 de Y Combinator avec 95 % de code généré, une étude sur 300 développeurs (-31 % de temps de revue de PR). Lecture assumée d'une possible bulle d'investissements circulaires, sans que cela change la donne.
  • « Vibe coding » est devenu pour lui presque une insulte : il préfère « agentic engineering », une compétence qui s'apprend comme la salle de sport ; il faut encore lire le code, debugger et penser l'architecture.
  • Conseils : nouveau contexte par tâche, demander des tests dans le contexte construit, se méfier des MCP (celui de GitHub coûterait ~50 000 tokens), Markdown dans git pour la doc. Son projet : 300 000 lignes, 99,8 % générées.
  • Moment « hérétique » assumé devant une conférence Swift : son app iOS est en Expo / React Native, son app Mac en Tauri ; le langage compte moins que l'écosystème et les données d'entraînement. Il évoque aussi le côté addictif (« crack cocaine », son projet VibeTunnel arrêté pour cette raison).
  • Appel final : lancer un side project avec un agent, et pour les dirigeants rendre l'usage de l'IA obligatoire (exemple de Shopify). Vidéo de loin la plus vue de l'édition (~8 200 vues).
Voir sur YouTube (nouvel onglet) ↗

Sessions sans retour trouvé (8)

  • How to Approach Approachable Concurrency (Matt Massicotte ; vidéo yyEWFcHRykA, transcript non récupéré)
  • The Wonderful World of Private APIs (Quentin Fasquel, Luni ;vidéo K-Q52-S-r8w)
  • Defence Against the Analytics Regressions (Oleksii Kirizii, Bikemap ;vidéo NbN3wFG2Tfo)
  • To Test Is to Doubt? Swift Testing as an Alternative to XCTest (Emma Gaubert ; vidéo 9KLoeQKyU7I)
  • When iOS Talks Back: Speaking and Listening Without Chaos (Montana Braswell ; vidéo o5fDwUs9j_8)
  • SwiftUI Apps That Effortlessly Scale from Your Smallest to Your Biggest Screen (Manuel Kehl ; premier talk du speaker ; vidéo P4ojd6U__DQ)
  • Slide Into visionOS (Juan Moya ; vidéo N05WEfGPp3M)
  • Classrooms : Understanding Isolation (Matt Massicotte), Foundation Models Framework (Alex Logan), Create Your Own Agent in 75 Minutes (Peter Steinberger)

Sources