Swift Connection 2024

Dev, cloud & sécu23–24 septembre 2024Paris, Théâtre de Paris8e édition (ex-FrenchKit)

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

Conférence iOS / Swift en anglais, 1,5 jour (lundi 23 septembre après-midi, mardi 24 septembre) au Théâtre de Paris (15 rue Blanche, Paris 9e), premier passage dans ce lieu annoncé comme doublant la capacité d'accueil. 21 sessions au programme (talks de 35 min, lightning talks de 15 min) et une soirée le 23 au soir. Sponsors : Runway et Codemagic (gold), Genius Scan SDK et RocketSim (silver), Kodeco (média). Organisée par La Tech Connection, avec un Speaker Inclusion Programme.

Swift Connection 2024, première édition au Théâtre de Paris, a surtout parlé d'artisanat Swift au quotidien (performance, debugging, tests, tooling, architecture) avec en toile de fond Swift 6 et la concurrence stricte, tandis que l'IA d'Apple (Apple Intelligence, complétion prédictive de Xcode 16) était regardée avec curiosité mais prudence.

14 sessions résumées · 13 vidéos · mise à jour le vendredi 9 octobre 2026 · synthèse à compléter

Sources lues et limites de cette synthèse

Corpus : Programme officiel (2024.swiftconnection.io), 20 vidéos de la playlist YouTube Tech Connection (publiées le 05/11/2024, une le 16/12/2024, une vidéo privée) dont 13 transcripts lus, 7 posts Mastodon #SwiftConnection (23 au 29/09/2024, dont 4 de speakers), les weeknotes de Chris Eidhof (speaker) et les slides d'Ellen Shapiro sur Speaker Deck. 7 recherches web.

Limites : Corpus lu à J+2 ans, avec presque aucun retour participant public : l'essentiel des résumés décrit ce qui a été dit sur scène (transcripts), pas sa réception. Les rares retours viennent de Mastodon, souvent de speakers (signalés). Aucun post LinkedIn ni compte-rendu de blog trouvé ; deux talks du programme (Bas Broek, Muralidharan Kathiresan) n'ont pas de vidéo publique. Les compteurs de vues YouTube (3 900 pour Sundell, 3 100 pour Eidhof, 1 700 pour Van Voorden au 09/10/2026) indiquent un intérêt, pas un retour.

Synthèse globale

1. Une édition d'artisanat plus que de nouveautés

La majorité des talks filmés portent sur le métier au quotidien plutôt que sur les annonces de WWDC 2024 : performance (Sundell, Van Voorden), debugging (Napier), tests (Vogel), outillage en Swift (Rolnik), architecture d'écrans complexes (Sabaliauskas). Même le talk le plus « WWDC » regarde en arrière : Ellen Shapiro revisite iOS 16, parce que la plupart des apps ne peuvent adopter une API que deux ans après son annonce. Le fil commun, porté à la fois par Sundell, Napier et Van Voorden : mesurer plutôt que supposer, sur device et en release.

2. Swift 6 et la concurrence en toile de fond

Swift 6, livré avec Xcode 16 sorti la semaine précédente (Pradeilles), traverse le premier jour : un talk dédié (Kathiresan, non filmé), des questions du public à Sundell sur les vérifications de concurrence stricte, et Napier qui ouvre en notant qu'« on a beaucoup appris sur Swift 6 » dans la journée. Le message convergent : le compilateur élimine les data races, pas les race conditions (réentrance des actors chez Sundell, Task.sleep aléatoire après chaque await chez Napier). Sundell avoue avoir d'abord détesté ces vérifications sur de gros projets et compare la transition à celle des optionnels.

3. L'IA d'Apple regardée avec curiosité et prudence

Deux talks seulement sur l'IA, aux tonalités différentes. Etienne Vautherin décortique la manière dont les apps exposent domaines, schémas et entités à Apple Intelligence, tout en rappelant qu'elle n'était pas disponible en Europe. Vincent Pradeilles teste la complétion prédictive de Xcode 16 face à Copilot et la trouve « quelques années en retard », limitée au fichier courant et trop crédible visuellement pour les juniors. Leah Vogel juge de son côté que l'IA pour écrire des tests « demande encore beaucoup de supervision ». Swift Assist, annoncé à WWDC, n'était pas encore disponible.

4. Plateformes : l'unification promise reste partielle

Plusieurs talks montrent que « tout Swift » ne veut pas dire « même code partout ». Lena Stöxen abandonne son rêve d'une base de code unique iPad et Vision Pro : RealityKit est unifié, ARKit non. Ellen Shapiro décrit TextKit 2 comme une source de friction (quatre types de range) devenue pourtant nécessaire pour Apple Intelligence. À l'inverse, Swift sort de l'app : serveur (Swift OpenAPI Generator avec Hummingbird chez Timirah James), outillage en CI Linux (Rolnik), Embedded Swift (Bariaux, non transcrit).

5. La vie de l'événement

Première édition au Théâtre de Paris, annoncé comme doublant la capacité ; un speaker parle de 400 personnes dans la salle (Sabaliauskas, Mastodon). Les retours publics saluent l'organisation (« fantastic job, great talks, great people », Tuparev) et le plaisir de voir « la moitié de ma timeline en vrai » (Pakk'). Le moment le plus commenté est la présentation de Chris Eidhof, faite avec un logiciel maison qui simule la frappe puis affiche une vraie vue SwiftUI interactive (Ellen Shapiro). Le format mêle talks de 35 minutes et lightning talks de 15 minutes, chaque session étant suivie d'un Q&A animé par l'équipe avec des questions du public.

6. Limites du corpus

Cette synthèse s'appuie presque entièrement sur 13 transcripts : elle dit ce qui a été présenté, très peu comment cela a été reçu. Les retours participants se limitent à sept posts Mastodon, dont plusieurs de speakers, et aucun post LinkedIn ni compte-rendu de blog n'a été trouvé. Sept sessions, dont six lightning talks filmés, ne sont pas documentées.

Actions concrètes citées

  1. Écrire du code « rapide par défaut » : connaître la complexité de ses algorithmes, préférer une fonction à une propriété calculée coûteuse, choisir l'algorithme adapté au site d'appel (contains plutôt que filter), paralléliser avec async let, et toujours mesurer sur device en release (Sundell).
  2. Face à un bug dur, passer en mode science : tenir un journal, relire vraiment le rapport de bug, réduire le problème dans une petite app de test, et ne pas masquer un index hors limites par un guard (Napier).
  3. Pour débusquer les race conditions avec la concurrence Swift, insérer un Task.sleep aléatoire juste après chaque await et tester avec Network Link Conditioner à 100 % de perte de paquets (Napier).
  4. Générer le code réseau client et serveur depuis un document OpenAPI avec Swift OpenAPI Generator : le contrat reste synchronisé et le compilateur signale toute évolution de l'API (James).
  5. Ne pas faire confiance par défaut à la complétion prédictive de Xcode 16 : utile pour les mocks et les modèles simples, mais plus lente et moins bonne que Copilot, et limitée au fichier courant ; prévenir les juniors (Pradeilles).
  6. Utiliser Swift plutôt que Bash ou Ruby pour l'outillage d'une équipe iOS, avec Swift Argument Parser et des templates Stencil, puis l'exécuter en CI sur Linux (Rolnik).
  7. Pour un écran complexe, une architecture en plugins (registre, fabriques, décodage délégué) permet d'ajouter une section sans toucher l'existant, à condition de garder le cœur minuscule et de limiter la communication entre plugins (Sabaliauskas).
  8. Avant de migrer vers TextKit 2, avoir des tests couvrant toute la logique de texte ; la migration reste nécessaire pour profiter pleinement d'Apple Intelligence (Shapiro).
  9. Pour publier une première app : viser un MVP minuscule, se fixer une date butoir et construire en public pour trouver aide et testeurs (Lewis).

Session par session

Lundi 23 septembre

Conférence▶ vidéo + transcript

Streamline Your Workflow with Swift OpenAPI Generator

Timirah James — Apple (Worldwide Developer Relations)

Retours : Pit Schrader (Mastodon)

  • Premier talk de la conférence. Constat : avec URLSession, le développeur doit écrire et maintenir à la main chaque requête et garder le contrat client/serveur synchronisé, un travail répétitif et source d'erreurs.
  • OpenAPI décrit l'API (YAML ou JSON) comme un contrat ; Swift OpenAPI Generator est un plugin de package qui génère au build le code réseau client et serveur, sans le committer.
  • Démo en direct : une app de vote sur la prochaine couleur de cheveux de la speakeuse (Memoji), avec un serveur Hummingbird et un client iOS (transport URLSession). Ajout d'une opération dans le document : le compilateur signale immédiatement le handler manquant, ce qui garde toute l'équipe alignée sur l'évolution de l'API.
  • La salle a voté en direct ; résultat : blond.
  • Retour (Pit Schrader) : « Nice explanation of OpenAPI to generate code for both server and client ».
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

A practical guide to Swift performance

John Sundell

  • Objectif : écrire du code « fast by default » plutôt que de traiter la performance seulement quand un problème survient. Distinguer code synchrone (vitesse brute, complexité) et asynchrone (orchestration des tâches).
  • Synchrone : filtrer avant de trier ou mapper ; transformer une propriété calculée coûteuse en fonction pour rendre le coût visible (un accès répété dans une boucle donnait du O(n²), 150 fois plus lent sur 1 000 éléments) ; créer des API adaptées aux sites d'appel (contains au lieu de filter(...).isEmpty).
  • Cache : utile mais « double tranchant » (mémoire, données périmées, bugs difficiles à reproduire avec un cache chaud) ; alternatives comme le précalcul.
  • Asynchrone : remplacer des await séquentiels indépendants par des async let (jusqu'à 3 fois plus rapide) ; sortir du main actor les traitements O(n) avec une tâche détachée, en annulant la tâche précédente pour éviter les races.
  • Toujours mesurer sur device et en release, pas dans le simulateur en debug.
  • Q&A : pas d'optimisation prématurée si on optimise juste avant la PR ; sur les vérifications de Swift 6, il dit les avoir d'abord détestées sur de gros projets mais garder l'esprit ouvert, et rappelle que les race conditions (réentrance des actors) restent possibles.
Voir sur YouTube (nouvel onglet) ↗

Conférence

Building an Accessibility Culture, One Step at a Time

Bas Broek — WeTransfer

Retours : Robin Kanatzar (Mastodon)

  • Talk sur la construction d'une culture de l'accessibilité dans une équipe, pas de vidéo publique trouvée (une vidéo de la playlist est privée).
  • Seul retour lu, bref : « Great talk by @bas at #SwiftConnection about building a culture of #Accessibility » (Robin Kanatzar).

Conférence▶ vidéo + transcript

From Dread to Delight: Why You Should Embrace Writing Tests (Even If You Hate It)

Leah Vogel — Chegg

  • Talk sur le pourquoi des tests, pas le comment, construit sur son parcours : un premier test écrit avec son lead pour une emoji qui « pop » (un emoji seul compte deux caractères en Objective-C), puis l'évangélisation des tests chez OrCam (mock d'un manager Bluetooth via un protocole, Bluetooth n'étant pas testable en simulateur).
  • Trois raisons : craftsmanship (le test force à mieux découper le code), fiabilité (refactorer et livrer avec moins d'anxiété) et ownership (« un chef qui ne goûte pas sa cuisine »).
  • Préférence pour beaucoup de tests d'intégration, entre la pyramide classique et l'approche tout end-to-end. Commencer par le code partagé et le plus utilisé.
  • Mises en garde : ne pas inciter au nombre de tests ; on peut se passer de tests pour un A/B test court ou un POC jetable, mais un POC parti en production sans aucun test leur a valu un incident.
  • Swift Testing jugé prometteur ; l'IA pour écrire des tests « demande encore beaucoup de supervision ».
  • Lors du sondage à main levée, la majorité de la salle disait déjà écrire des tests.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Zen and the Science of Debugging

Rob Napier

  • Dernier talk du premier jour. Thèse : programmer est un art, débugger est une science. La première étape est d'accepter qu'on ne sait pas ce que fait le programme, et de « renoncer à l'espoir » de trouver tout de suite.
  • En amont : lire ses logs quand tout va bien pour savoir à quoi ressemble la normale (il y a trouvé des requêtes dupliquées et une base migrée deux fois).
  • Méthode : tenir un journal (setup, device, OS de chaque essai), relire vraiment le rapport de bug, vérifier qu'on exécute bien le code modifié (un fatalError volontaire), bissecter dans le temps (git bisect) et dans l'espace en supprimant du code ou via une petite app de test, sans perdre de temps sur un framework de test.
  • Race conditions : lancer la fonction dans une dizaine de tâches en parallèle, ajouter un Task.sleep aléatoire après chaque await, dégrader le réseau (Network Link Conditioner à 100 % de perte).
  • Mise en garde : ne pas masquer un index hors limites par un guard ; ces « whiskey fixes » doivent au minimum être documentés et signés dans le code.
  • Q&A : sa pire chasse, six mois pour une faute de casse dans le nom d'une bibliothèque sur un disque sensible à la casse ; des stack traces « impossibles » signalent souvent une corruption mémoire, en Swift en général un accès concurrent.
Voir sur YouTube (nouvel onglet) ↗

Mardi 24 septembre

Lightning talk▶ vidéo + transcript

5 Tips to Ship

Danielle Lewis

  • Ouverture du deuxième jour. Parcours : premières lignes de Swift en juin 2023 après l'annonce du Vision Pro, huit apps publiées sur les App Stores iOS et visionOS depuis.
  • Cinq conseils : l'app n'a pas besoin d'être grande (un minuteur visionOS codé et soumis en une journée) ; construire ce qui vous passionne (une app de revues pour ses collègues de dispensaire) ; le code n'a pas besoin d'être public, un portfolio App Store vaut un portfolio GitHub ; se fixer une date butoir pour tenir le MVP ; s'appuyer sur la communauté.
  • Q&A : face à la frustration, accepter de demander de l'aide publiquement ; entendre des développeurs expérimentés dire qu'ils bloquent aussi aide contre le syndrome de l'imposteur.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

How Apple Intelligence infuses and distills its models into the app

Etienne Vautherin

  • Explication du modèle d'intégration d'Apple Intelligence côté app : des domaines (13 annoncés, 30 prévus) et des schémas que l'app implémente via des intents et entités App Intents annotés par macro (exemple : ouvrir une photo dans le domaine Photos, créer un brouillon dans le domaine Mail), stockés dans l'« App Intent toolbox ».
  • Le langage naturel est transformé en intent conceptuel par des modèles plus petits spécialisés par domaine (contrainte du on-device), puis rapproché des intents exposés par les apps.
  • Côté architecture : partager les actions entre la vue et l'intent, et accéder au modèle via les dépendances App Intents quand l'intent tourne en arrière-plan sans UI.
  • L'index sémantique se nourrit des entités indexées (IndexedEntity, attributs Core Spotlight) et de la recherche in-app.
  • Limite rappelée : Apple Intelligence n'était pas disponible en Europe à l'époque ; la démonstration s'appuyait sur une métaphore de « jouets pour bébé » et une nouvelle bêta sortie la veille.
  • Q&A : écrire du déclaratif et laisser le système composer, comme avec SwiftUI ; entre deux apps mail, le choix dépendrait de l'usage et de l'index.
Voir sur YouTube (nouvel onglet) ↗

Lightning talk▶ vidéo + transcript

AI in Xcode: is it better than the competitors?

Vincent Pradeilles — PhotoRoom

  • Swift Assist n'étant toujours pas disponible, comparaison de la complétion prédictive de Xcode 16 (locale, Apple Silicon) avec GitHub Copilot (cloud, via VS Code) sur cinq cas.
  • Modèle de données et mocks : résultats comparables, Xcode plus lent et sans indicateur de chargement. Appel d'API : les deux proposent un completion handler plutôt que async/await ; Xcode fait à peine mieux avec Result. Corps d'une vue : Copilot raisonne sur plusieurs fichiers, Xcode seulement sur le fichier courant et produit du code qui ne compile pas.
  • Verdict : prédictions égales ou moins bonnes que Copilot, plus lentes, mais utiles sans effort ; « si seulement 20 % sont bonnes, c'est quand même un gain ».
  • Mise en garde : l'intégration visuelle dans Xcode rend les suggestions plus crédibles qu'elles ne le méritent, à expliquer aux juniors. Cursor présenté comme un aperçu de ce que pourrait être Swift Assist.
  • Q&A : impression d'un outil arrivé « quelques années en retard » sur la concurrence.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Managing Complex Screens with Plug-in Architecture

Darius Sabaliauskas — Vinted

Retours : Darius Sabaliauskas (Mastodon, speaker)

  • Architecture en plugins (micro-kernel, d'Unix à Eclipse) appliquée à un écran de checkout UIKit : un cœur minimal, un registre d'identifiants et de fabriques, chaque section étant un plugin (view controller enfant) ajouté sans modifier l'existant (principe ouvert/fermé).
  • Astuce : redécouper la réponse JSON en morceaux bruts confiés à chaque plugin, ce qui améliore la tolérance aux erreurs (une section cassée n'empêche pas d'afficher les autres).
  • Limites : le cœur doit être conçu en amont car le changer casse les contrats ; la communication entre plugins est le point douloureux (validation par protocole ségrégé, événements publiés et consommés, garder le bouton de paiement hors plugins).
  • Q&A : SwiftUI ne change pas le raisonnement architectural ; sur une grosse base, on ne réécrit pas pour le plaisir.
  • Retour du speaker sur Mastodon : premier talk devant 400 personnes, et le travail de ne pas écouter son « critique intérieur ».
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

SwiftUI Animations

Chris Eidhof

Retours : Ellen Shapiro (Mastodon, speaker), Chris Eidhof (weeknotes, speaker)

  • Quatre exemples de complexité croissante autour d'un cœur : animation de base (trim + .animation(value:)), phase animator, keyframe animator, puis particules faites main avec Canvas et TimelineView.
  • Explication de ce qui se passe sous le capot : SwiftUI interpole entre deux états de l'arbre de vues ; un outil maison façon « Instruments du futur » montrait la transaction descendre l'arbre jusqu'au modificateur animé.
  • Conseils : ne rien faire de coûteux dans les closures appelées à chaque frame ; withAnimation pour piloter de l'extérieur, .animation pour l'intégrer à un composant ; le modificateur speed casse la fusion des vélocités et rend les animations interrompues saccadées.
  • Retour : le logiciel de présentation écrit par Eidhof, qui simule la frappe puis affiche une vraie vue SwiftUI interactive, a laissé « les autres speakers bouche bée » et « impressionné le public » (Ellen Shapiro, speaker). Eidhof dit que l'essai s'est bien passé malgré un incident technique signalé par un spectateur.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Swift-CowBox: Easy Copy-on-Write Semantics for Swift Structs

Rick Van Voorden

  • Rappel : les structs ont une sémantique de valeur mais copient toutes leurs données ; une struct de 80 octets copiée n fois coûte un ordre de grandeur de mémoire de plus qu'une classe.
  • Le copy-on-write manuel (classe de stockage privée, isKnownUniquelyReferenced) fonctionne mais génère beaucoup de boilerplate risqué, souvent laissé en TODO.
  • Swift-CowBox (open source) génère ce code via des macros (@CowBox, @CowBoxMutating), y compris les conformances Equatable, Hashable, Codable, sans changer les sites d'appel.
  • Étude de cas sur l'app exemple Food Truck d'Apple avec 24 000 commandes : -31 % de commits Core Animation, -18 % de hangs, -38 % de mémoire totale.
  • Limites présentées honnêtement : temps de compilation (swift-syntax), coût d'allocation sur le tas, inutile pour de petites structs peu copiées, risque de « quadratiques accidentels ». Conseil : mesurer avant et après.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Dub Dub Time Machine

Ellen Shapiro — Pixite

Retours : Ellen Shapiro (Mastodon, speaker)

  • Point de départ : la plupart des apps doivent supporter deux versions d'iOS en arrière, donc on oublie les nouveautés de WWDC avant de pouvoir les utiliser. Le talk revisite ce qu'apporte iOS 16 comme version minimale.
  • SwiftUI : NavigationStack / NavigationSplitView et navigation programmatique, AnyLayout plutôt que AnyView, UIHostingConfiguration pour les cellules UIKit, Swift Charts (sans camembert avant iOS 17), sheets à détentes, sélection de dates multiples.
  • TextKit 2 : vrais avantages (séparation stockage/affichage, gestion des emoji et idéogrammes), mais quatre types de range à jongler ; à n'adopter que sur une app neuve, une logique simple ou déjà très bien testée, et nécessaire pour Apple Intelligence.
  • Aussi : DataScannerViewController, Transferable, Regex Builder, WeatherKit (attention au coût au-delà de 500 000 appels par mois).
  • La speakeuse a dépassé son temps et n'a pas pu faire de Q&A ; elle a publié ses slides et proposé de répondre sur Mastodon.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Mastering Swift for Scripting & Tooling

Natan Rolnik — monday.com

  • Pourquoi Swift pour l'outillage : dans une équipe iOS, tout le monde connaît Swift, alors que chacun a son langage de script préféré ; plus le compilateur, Foundation, les property wrappers et l'écosystème de packages.
  • Live coding 1 : un script qui appose un badge sur l'icône d'une build bêta (AppKit), avec readLine puis CommandLine.arguments.
  • Live coding 2 : un CLI avec Swift Argument Parser et Stencil qui génère des structs d'événements analytics à partir d'un tableau Markdown, puis une GitHub Action sur Linux qui régénère et commit le code quand le fichier change.
  • Sondage en salle : la plupart automatisent déjà des tâches, peu ont essayé Swift côté serveur.
  • Q&A : ne pas migrer tout fastlane de Ruby vers Swift, plutôt appeler des scripts Swift depuis fastlane.
Voir sur YouTube (nouvel onglet) ↗

Conférence▶ vidéo + transcript

Everything's Cooler in Space

Lena Stöxen — Volkswagen Véhicules Utilitaires (étudiante)

  • Récit d'une tentative de porter une app de réalité augmentée iPad (Swift Student Challenge, trois fois lauréate) vers le Vision Pro avec une seule base de code, sans posséder de Vision Pro.
  • Constats : UIKit et ARView d'un côté, SwiftUI et RealityView de l'autre ; les anchors ARKit diffèrent et ne sont pas compatibles entre iPad et Vision Pro. RealityKit est unifié, pas ARKit.
  • Options : #if par plateforme, ou les AnchorEntity de RealityKit, testables dans le simulateur mais moins précises et sans classification.
  • Explication pédagogique de l'Entity Component System de RealityKit : entités, composants porteurs d'état, systèmes qui agissent à chaque frame (donc rien de coûteux).
  • Conclusion : rêve multiplateforme abandonné, deux bases de code recommandées car interactions et ancrages sont trop différents ; la RA reste un bon démarreur de créativité.
Voir sur YouTube (nouvel onglet) ↗

Sessions sans retour trouvé (7)

  • Data? Data! It's everywhere! (Nicolas Zinovieff, lightning, vidéo f_4JQIuTqRg non transcrite)
  • Swift 6 + Concurrency = Peace (Muralidharan Kathiresan, pas de vidéo publique trouvée)
  • Unifying form validation with TCA (Anthony Chanliau Merle, AVIV Group, lightning, vidéo RrBxRX_SEsQ non transcrite)
  • KMP: A Hands-On Perspective (Melisa De la Garza, lightning, vidéo 0AvHyr6e0_s non transcrite)
  • Zoom transitions: A comprehensive guide (Douglas Hill, PSPDFKit, lightning, vidéo qA69uZDd53Q non transcrite)
  • Parsing the real intent behind user input (Nathan Manceaux-Panot, lightning, vidéo riK8aL_yZGw non transcrite)
  • Blink them to death using Embedded Swift (Eric Bariaux, Nelcea, lightning, vidéo 61A46nZmCLE non transcrite)

Sources