API Image Playground : feuille SwiftUI, créateur d'images programmatique et contrôle du style

Mise à jour (11 juin 2026) : Apple met fin à ImageCreator, la voie programmatique que couvre cet article. Elle cesse de fonctionner sous iOS 27, iPadOS 27, macOS 27 et visionOS 27. Les API fondées sur la feuille décrites dans le reste de cet article demeurent la voie prise en charge. Lisez l’article complet sur l’abandon pour le calendrier et la migration.

Image Playground d’Apple Intelligence expose deux voies d’intégration aux applications. Le modificateur SwiftUI imagePlaygroundSheet() présente l’interface de génération d’images du système, destinée à l’utilisateur ; le développeur transmet un concept de départ (texte ou image), l’utilisateur itère à l’intérieur de la feuille, et le résultat revient à l’application. L’API ImageCreator exécute le même pipeline de génération de façon programmatique : le développeur fournit un tableau d’objets ImagePlaygroundConcept ainsi qu’un style, et le framework renvoie les images générées sans afficher d’interface¹. Les deux voies répondent à des cas d’usage différents. L’intégration par feuille convient lorsque l’utilisateur doit itérer ; l’intégration programmatique convient lorsque l’application a une demande de génération précise et présente directement le résultat.

Cet article parcourt l’API à la lumière de la documentation d’Apple. Le fil conducteur est « quelle voie d’intégration correspond au modèle mental de l’utilisateur », car choisir la mauvaise voie produit une UX qui retire soit trop de contrôle à l’utilisateur (programmatique alors qu’il voulait itérer), soit trop peu (feuille alors qu’il attendait un résultat en un coup).

TL;DR

• imagePlaygroundSheet(isPresented:concept:sourceImage:onCompletion:onCancellation:) est le modificateur SwiftUI qui présente la feuille système Image Playground. L’utilisateur itère ; l’application reçoit l’URL de l’image choisie via onCompletion (URL non optionnelle) ; l’annulation déclenche onCancellation².
• ImageCreator().images(for: [ImagePlaygroundConcept], style: ImagePlaygroundStyle, limit: Int) est la voie programmatique (iOS 18.4+). La méthode renvoie une AsyncSequence de résultats ImageCreator.CreatedImage³.
• ImagePlaygroundConcept porte l’entrée utilisée par le modèle : descriptions textuelles (.text("a watercolor of a cat")), images sources (.image(...)), dessins (.drawing(...)) ou concepts extraits d’une référence (.extracted(from:title:)).
• ImagePlaygroundStyle choisit l’esthétique visuelle. Les applications interrogent ImageCreator().availableStyles pour découvrir les cas pris en charge par l’appareil.
• .imagePlaygroundPersonalizationPolicy(_:) accepte .automatic, .enabled ou .disabled. .imagePlaygroundGenerationStyle(_:in:) prend un style préféré et une liste de styles autorisés. Utilisez-les dans des contextes sensibles à la vie privée ou verrouillés sur le plan esthétique.

Les deux voies : feuille ou programmatique

Le choix entre les deux voies d’intégration se joue sur la question de savoir qui contrôle l’itération.

L’intégration par feuille confie à l’utilisateur l’interface complète de génération d’images du système. L’utilisateur saisit des prompts, choisit des variantes et sélectionne l’image finale. Le rôle de l’application est de lancer la feuille avec un concept de départ et de recevoir le résultat choisi. Utilisez-la lorsque :

• L’utilisateur a une intention créative que l’application ne peut pas entièrement prévoir.
• L’interaction s’inscrit dans un flux créatif (une application de messagerie, une application de notes, un parcours de personnalisation de profil).
• L’utilisateur s’attend à itérer avant de valider.

L’intégration programmatique donne à l’application un accès direct au modèle. L’application fournit des concepts et récupère des images, sans afficher l’interface système. Utilisez-la lorsque :

• La génération fait partie d’un flux non interactif (un avatar généré par le système, une ressource déterministe pour une fiche de recette, une illustration en un coup).
• L’application a une exigence esthétique précise (toujours le style illustration, toujours une seule image).
• L’utilisateur ne devrait pas voir l’itération ; c’est le résultat qui lui importe.

Les deux voies partagent le modèle sous-jacent et respectent la même configuration Apple Intelligence définie au niveau de l’utilisateur. Le choix relève purement de l’UX.

La feuille SwiftUI

imagePlaygroundSheet se décline en plusieurs variantes surchargées sur View. La forme canonique à 5 paramètres prend un concept de départ, une référence facultative d’image source, plus des gestionnaires de complétion et d’annulation² :

import ImagePlayground
import SwiftUI

struct ProfileEditor: View {
    @State private var showPlayground = false
    @State private var avatarURL: URL?

    var body: some View {
        VStack {
            if let avatarURL {
                AsyncImage(url: avatarURL) { image in
                    image.resizable().scaledToFit()
                } placeholder: {
                    ProgressView()
                }
            }

            Button("Generate Avatar") {
                showPlayground = true
            }
        }
        .imagePlaygroundSheet(
            isPresented: $showPlayground,
            concept: "a friendly cartoon avatar",
            sourceImage: nil,
            onCompletion: { url in
                avatarURL = url
            },
            onCancellation: {
                // user dismissed without choosing
            }
        )
    }
}

L’UX de la feuille est contrôlée par le système. L’utilisateur voit l’interface Image Playground standard d’Apple (prompts, sélecteur de style, grille de variantes, bouton « Done »). Le rôle de l’application est de fournir le prompt de départ et de recevoir le résultat. L’annulation déclenche la closure dédiée onCancellation plutôt qu’une URL nil à la complétion ; l’URL transmise à onCompletion est non optionnelle.

Pour les applications qui souhaitent des concepts de départ plus riches qu’une simple chaîne, des surcharges voisines acceptent directement [ImagePlaygroundConcept]. Plusieurs concepts se composent : le modèle utilise chacun comme contrainte ou signal. L’ordre compte : les concepts textuels établissent le prompt ; les concepts d’image établissent une référence visuelle ; les concepts de dessin établissent un contour.

Les variantes d’ImagePlaygroundConcept

Apple fournit plusieurs constructeurs ImagePlaygroundConcept⁴ :

.text(_:). Une courte description textuelle. Le concept de départ le plus courant.

.image(_:). Une image source (généralement une URL ou un UIImage/NSImage). Le modèle l’utilise comme référence visuelle pour le style ou la composition.

.drawing(_:). Un dessin, généralement issu de PencilKit ou d’une surface de dessin personnalisée. Le modèle interprète les traits comme une indication structurelle.

.extracted(from:title:). Des concepts extraits d’une image analysée. La forme à deux arguments prend une URL source (ou un type d’image) et un title décrivant l’extraction. Le framework recourt à une analyse sur l’appareil pour dériver de la référence un concept propice à la génération.

Les concepts se composent : passer [text, image, extracted] à la feuille ou à ImageCreator permet au modèle de satisfaire plusieurs contraintes. Le bon schéma est « assez précis pour produire une sortie utile, assez souple pour laisser de la marge au modèle » : un ou deux concepts concrets, plus une imagerie de référence facultative.

ImageCreator : la voie programmatique

[Mise à jour : Apple a abandonné ImageCreator à compter du 11 juin 2026 ; consultez l’article sur l’abandon pour le calendrier d’iOS 27 et la marche à suivre pour migrer. La section ci-dessous reste à titre de documentation historique de l’API.]

ImageCreator est l’API programmatique pour les applications qui veulent générer sans interface³ :

import ImagePlayground

do {
    let creator = try ImageCreator()

    // Discover the styles the device supports
    guard let style = creator.availableStyles.first else {
        // Apple Intelligence unavailable on this device
        return
    }

    let stream = creator.images(
        for: [.text("a friendly cartoon avatar")],
        style: style,
        limit: 1
    )

    for try await result in stream {
        // result is an ImageCreator.CreatedImage
        await self.save(result)
    }
} catch {
    // ImageCreator() initializer can throw on unsupported devices
    print("Generation failed: \(error)")
}

La méthode images(for:style:limit:) renvoie une AsyncSequence de résultats ImageCreator.CreatedImage. Le modèle de streaming asynchrone permet aux applications de présenter des résultats partiels (le raffinement progressif du modèle) ou d’attendre l’image finale. Le paramètre limit: plafonne le nombre d’images demandées ; Apple peut en renvoyer moins selon la politique ou l’état de l’appareil.

La voie programmatique nécessite iOS 18.4+ et un appareil compatible Apple Intelligence avec la fonctionnalité activée. Le schéma de vérification de disponibilité : construire ImageCreator à l’intérieur d’un try, puis lire availableStyles. Une collection availableStyles vide (ou un initialiseur qui lève une erreur) signale que la génération est indisponible sur l’appareil courant ; les applications se rabattent sur une voie non générative (bibliothèque de ressources, image téléversée par l’utilisateur, etc.).

Les variantes d’ImagePlaygroundStyle

Le paramètre de style contraint l’esthétique visuelle⁵ :

• .animation. Le style de personnage animé d’Apple (formes arrondies, contours marqués, traits simplifiés). Utile pour les avatars, les mascottes, les illustrations conviviales d’interface.
• .illustration. Un style illustré et plat, à l’esthétique proche du vectoriel. Utile pour les infographies, les fiches de recette, l’imagerie conceptuelle.
• .sketch. Un style de croquis au crayon (ajouté dans des versions ultérieures). Utile pour les applications de prise de notes, le journaling, les esthétiques dessinées à la main.

Les applications qui veulent une esthétique cohérente sur l’ensemble des images générées (chaque avatar en style .animation, chaque fiche de recette en style .illustration) verrouillent le style dans leurs appels de génération ; celles qui veulent exposer le choix présentent un sélecteur de style qui se mappe sur les cas disponibles.

Modificateurs de personnalisation et de politique

Deux modificateurs SwiftUI permettent aux applications de contraindre le comportement d’Image Playground dans leur contexte⁶ :

.imagePlaygroundPersonalizationPolicy(_:). Prend une valeur ImagePlaygroundPersonalizationPolicy : .automatic (valeur par défaut du système), .enabled (autorisation explicite) ou .disabled (interdit au système de référencer du contenu personnel comme les contacts ou les photos). Utilisez .disabled pour les applications dans des contextes sensibles à la vie privée (médical, financier, communication anonyme).

.imagePlaygroundGenerationStyle(_:in:). Prend un style préféré et un tableau de styles autorisés. Le sélecteur de style de l’utilisateur (s’il est visible) est restreint à la liste autorisée, et le style préféré sert de valeur par défaut. Utilisez-le lorsque l’esthétique de l’application impose de restreindre ou de verrouiller les styles disponibles.

Les deux modificateurs respectent la configuration Apple Intelligence du niveau système comme plancher. Les applications ne peuvent pas outrepasser les fonctionnalités que le système a désactivées ; elles peuvent seulement les restreindre davantage.

Défaillances courantes

Trois schémas tirés des journaux d’intégration d’Image Playground :

Appeler ImageCreator() sans intercepter l’erreur de l’initialiseur. Sur les appareils sans Apple Intelligence, le créateur lève une erreur à l’initialisation. Les applications qui n’utilisent pas try et ne l’interceptent pas exposent une erreur déroutante à l’utilisateur. Correctif : enveloppez ImageCreator() dans un try, inspectez availableStyles et prévoyez une voie de repli en cas d’échec (afficher un emplacement réservé, inviter l’utilisateur à activer Apple Intelligence dans les Réglages, ou masquer entièrement la fonctionnalité).

Faire correspondre la mauvaise voie d’intégration au cas d’usage. Un générateur d’avatar de profil qui utilise ImageCreator produit un avatar en un coup que l’utilisateur ne peut pas ajuster ; un générateur d’avatar en un coup qui utilise la feuille ajoute de la friction. Faites correspondre la voie à l’attente de l’utilisateur : s’il veut itérer, la feuille ; s’il veut un résultat, le programmatique.

Ignorer le plancher de politique du système. Les applications qui tentent de contourner les réglages Apple Intelligence du système (par exemple générer des images dans un contexte que l’utilisateur a désactivé globalement) se heurtent à des erreurs de politique. Correctif : respectez la configuration système ; présentez des erreurs explicites lorsque Apple Intelligence est désactivé plutôt qu’un échec silencieux.

Ce que ce schéma signifie pour les applications Apple Intelligence

Trois enseignements.

1. Choisissez la voie d’intégration selon le modèle mental de l’utilisateur. La feuille pour l’itération créative ; le programmatique pour la génération en un coup dans des flux non interactifs. Le coût d’un mauvais choix est une friction UX bien réelle.

2. Contraignez le style et la personnalisation de façon délibérée. Une application de messagerie qui veut un style d’avatar cohérent passe un seul style autorisé à .imagePlaygroundGenerationStyle(_:in:). Une application de journaling axée sur la vie privée définit .imagePlaygroundPersonalizationPolicy(.disabled). Les valeurs par défaut sont permissives (.automatic) ; des contraintes délibérées font paraître la fonctionnalité intentionnelle.

3. Vérifiez toujours availableStyles d’ImageCreator() (ou interceptez l’erreur de l’initialiseur) et prévoyez une voie de repli. Apple Intelligence requiert un matériel précis (iPhone 15 Pro et ultérieurs, Mac à puce M) ainsi qu’une activation par l’utilisateur. Les applications qui dépendent d’Image Playground sans vérification de disponibilité échouent de façon déroutante sur les appareils plus anciens et sur ceux où Apple Intelligence est désactivé.

L’ensemble du cluster Apple Ecosystem : les App Intents typés ; les serveurs MCP ; la question du routage ; les Foundation Models ; la distinction entre LLM d’exécution et LLM d’outillage ; les trois surfaces ; le schéma de la source unique de vérité ; les deux serveurs MCP ; les hooks pour le développement Apple ; les Live Activities ; le runtime watchOS ; les rouages internes de SwiftUI ; le modèle mental spatial de RealityKit ; la discipline de schéma SwiftData ; les schémas Liquid Glass ; le déploiement multiplateforme ; la matrice des plateformes ; le framework Vision ; les Symbol Effects ; l’inférence Core ML ; l’API Writing Tools ; Swift Testing ; le Privacy Manifest ; l’accessibilité en tant que plateforme ; la typographie SF Pro ; les schémas spatiaux visionOS ; le framework Speech ; les migrations SwiftData ; le moteur de focus tvOS ; les rouages internes d’@Observable ; le protocole Layout de SwiftUI ; les SF Symbols personnalisés ; le HDR AVFoundation ; le cycle de vie d’un workout watchOS ; les App Intents 2.0 dans iOS 26 ; ce que je refuse d’écrire. Le hub se trouve à la série Apple Ecosystem. Pour un contexte plus large sur iOS avec les agents IA, consultez le guide de développement d’agents iOS.

FAQ

Dois-je gérer l’indisponibilité d’Apple Intelligence ?

Oui. Image Playground requiert un appareil compatible Apple Intelligence (iPhone 15 Pro et ultérieurs, Mac à puce M) avec la fonctionnalité activée. Sur les appareils non pris en charge, la feuille ne se présente pas et ImageCreator() lève une erreur à l’initialisation. Le schéma de vérification : enveloppez ImageCreator() dans un try et inspectez availableStyles ; une collection vide ou un initialiseur qui lève une erreur signale que la génération est indisponible. Prévoyez une voie de repli non générative pour les utilisateurs non pris en charge.

Puis-je personnaliser l’interface de la feuille ?

Non. La feuille est contrôlée par le système. L’application fournit le concept de départ et reçoit le résultat ; tout ce qui se passe entre les deux relève de l’interface d’Apple. Si vous avez besoin d’une interface personnalisée, utilisez l’API programmatique ImageCreator et construisez votre propre interface d’itération autour d’elle.

Qu’advient-il des images générées lorsque l’utilisateur ferme la feuille ?

La surcharge à 5 paramètres d’imagePlaygroundSheet fournit des closures distinctes onCompletion et onCancellation. onCompletion se déclenche avec une URL non optionnelle lorsque l’utilisateur choisit une image ; onCancellation se déclenche lorsqu’il ferme sans choisir. Les données temporaires de l’image sont nettoyées par le système ; les applications qui veulent conserver une image doivent l’enregistrer dans leur propre stockage au sein du gestionnaire de complétion.

Comment Image Playground interagit-il avec les autorisations d’accès aux photos ?

La feuille ne requiert pas en soi l’accès à la photothèque. Si l’utilisateur référence sa photothèque à l’intérieur de la feuille (en parcourant les images pour en choisir une comme concept), la feuille gère la demande d’autorisation en interne. Les applications n’ont pas besoin de demander l’autorisation d’accès aux photos en amont pour intégrer Image Playground.

Puis-je générer des images en arrière-plan ?

ImageCreator s’exécute au premier plan ; le framework gère les ressources système nécessaires à la génération. Les applications qui veulent générer des images en arrière-plan doivent maintenir leur application au premier plan (ou dans un type de session qui autorise une exécution continue, comme une session de workout abordée dans le cycle de vie d’un workout watchOS).

Quel est le lien avec le LLM Foundation Models ?

Le modèle d’Image Playground est distinct du LLM sur l’appareil de Foundation Models (abordé dans Foundation Models sur l’appareil). Les deux partagent l’infrastructure du framework Apple Intelligence mais utilisent des modèles spécialisés différents. Les applications qui les combinent (des prompts générés par le LLM alimentant la génération d’images) composent les deux API en séquence.

Références