Image Playground API : SwiftUI Sheet, Image Creator programmatique et contrôle du style

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

Le billet examine l’API à la lumière de la documentation d’Apple. Le cadre de réflexion 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 unique).

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 retourne une AsyncSequence de résultats ImageCreator.CreatedImage³.
• ImagePlaygroundConcept porte l’entrée que le modèle utilise : 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 quels cas l’appareil prend en charge.
• .imagePlaygroundPersonalizationPolicy(_:) accepte .automatic, .enabled ou .disabled. .imagePlaygroundGenerationStyle(_:in:) prend un style préféré et une liste de styles autorisés. Utilisez ces modificateurs pour les contextes sensibles à la confidentialité ou verrouillés sur le plan esthétique.

Les deux voies : Sheet ou programmatique

Le choix entre les deux voies d’intégration tient à savoir qui contrôle l’itération.

L’intégration via la feuille remet à l’utilisateur l’interface complète de génération d’images du système. L’utilisateur saisit des prompts, choisit des variations 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 cette voie lorsque :

• L’utilisateur a une intention créative que l’application ne peut pas entièrement prédire.
• L’interaction fait partie d’un workflow 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 reçoit des images en retour, sans afficher l’interface système. Utilisez cette voie lorsque :

• La génération fait partie d’un parcours non interactif (un avatar généré par le système, un actif déterministe pour une fiche recette, une illustration unique).
• L’application a une exigence esthétique spécifique (toujours en style illustration, toujours une seule image).
• L’utilisateur ne doit pas voir l’itération ; ce qui l’intéresse, c’est le résultat.

Les deux voies partagent le même 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 est livré sous plusieurs variantes surchargées sur View. La forme canonique à 5 paramètres prend un concept de départ, une référence d’image source optionnelle, 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 standard d’Apple pour Image Playground (prompts, sélecteur de style, grille de variations, bouton « Done »). Le rôle de l’application est de fournir le prompt initial et de recevoir le résultat. L’annulation déclenche la closure dédiée onCancellation plutôt qu’une URL nulle dans la complétion ; l’URL passée à onCompletion est non optionnelle.

Pour les applications qui souhaitent des concepts de départ plus riches qu’une simple chaîne, des surcharges sœurs acceptent directement un [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.

Variantes d’ImagePlaygroundConcept

Apple livre 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 un indice structurel.

.extracted(from:title:). 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 utilise une analyse sur l’appareil pour dériver de la référence un concept adapté à 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 spécifique 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 optionnelle.

ImageCreator : la voie programmatique

ImageCreator est l’API programmatique pour les applications qui souhaitent une génération 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:) retourne une AsyncSequence de résultats ImageCreator.CreatedImage. Le modèle de streaming asynchrone permet aux applications d’afficher 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 retourner moins selon la politique ou l’état de l’appareil.

La voie programmatique est disponible à partir d’iOS 18.4+ et nécessite 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 exception) signale que la génération est indisponible sur l’appareil courant ; les applications se rabattent alors sur une voie non générative (bibliothèque d’actifs, image téléversée par l’utilisateur, etc.).

Variantes d’ImagePlaygroundStyle

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

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

Les applications qui souhaitent une esthétique cohérente sur l’ensemble des images générées (chaque avatar en style .animation, chaque fiche recette en style .illustration) verrouillent le style dans leurs appels de génération ; les applications qui veulent exposer le choix présentent un sélecteur de style qui mappe vers 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 (autoriser explicitement) ou .disabled (interdire 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 confidentialité (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é est celui par défaut. Utilisez ce modificateur lorsque l’esthétique de l’application impose de contraindre ou de verrouiller les styles disponibles.

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

Échecs courants

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

Appeler ImageCreator() sans capturer l’erreur de l’initialiseur. Sur les appareils non compatibles avec Apple Intelligence, le créateur lève une exception à l’initialisation. Les applications qui n’utilisent pas try et ne capturent pas l’erreur exposent un message confus à l’utilisateur. Solution : encapsuler ImageCreator() dans un try, inspecter availableStyles et fournir une voie de repli en cas d’échec (afficher un placeholder, inviter l’utilisateur à activer Apple Intelligence dans les Réglages, ou masquer entièrement la fonctionnalité).

Mauvais appariement entre la voie d’intégration et le cas d’usage. Un générateur d’avatar de profil qui utilise ImageCreator produit un avatar unique que l’utilisateur ne peut pas affiner ; un générateur d’avatar à coup unique qui utilise la feuille ajoute de la friction. Faites correspondre la voie aux attentes de l’utilisateur : s’il veut itérer, c’est la feuille ; s’il veut un résultat, c’est le programmatique.

Ignorer le plancher de politique du système. Les applications qui tentent de contourner les paramètres système d’Apple Intelligence (par exemple, générer des images dans un contexte que l’utilisateur a globalement désactivé) se heurtent à des erreurs de politique. Solution : respecter la configuration système ; faire remonter des erreurs explicites lorsqu’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. Feuille pour l’itération créative ; programmatique pour la génération unique dans des parcours non interactifs. Le coût d’un mauvais choix est une friction UX bien réelle.

2. Contraignez délibérément le style et la personnalisation. Une application de messagerie qui veut un style d’avatar cohérent passe un seul style autorisé à .imagePlaygroundGenerationStyle(_:in:). Une application de journal personnel axée sur la confidentialité définit .imagePlaygroundPersonalizationPolicy(.disabled). Les valeurs par défaut sont permissives (.automatic) ; des contraintes délibérées font ressentir la fonctionnalité comme intentionnelle.

3. Vérifiez toujours availableStyles d’ImageCreator() (ou capturez l’erreur de l’initialiseur) et prévoyez un repli. Apple Intelligence requiert un matériel spécifique (iPhone 15 Pro et ultérieurs, Mac Apple Silicon) ainsi qu’une activation par l’utilisateur. Les applications qui dépendent d’Image Playground sans vérifications de disponibilité échouent de manière déroutante sur les anciens appareils et sur ceux où Apple Intelligence est désactivé.

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

FAQ

Dois-je gérer le cas où Apple Intelligence n’est pas disponible ?

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

Puis-je personnaliser l’interface utilisateur 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.

Que deviennent les 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 lorsque l’utilisateur ferme sans choisir. Les données d’image temporaires sont nettoyées par le système ; les applications qui souhaitent conserver une image doivent la sauvegarder dans leur propre stockage à l’intérieur du gestionnaire de complétion.

Comment Image Playground interagit-il avec les autorisations photo ?

La feuille ne nécessite pas en elle-même l’accès à la photothèque. Si l’utilisateur référence sa photothèque depuis la feuille (en parcourant pour choisir une image comme concept), la feuille gère l’invite d’autorisation en interne. Les applications n’ont pas besoin de demander l’autorisation photo 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 pour la génération. Les applications qui veulent générer des images en arrière-plan doivent garder leur application au premier plan (ou dans un type de session qui autorise l’exécution continue, comme une session d’entraînement traitée dans watchOS workout lifecycle).

Quel est le rapport avec l’LLM Foundation Models ?

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

Références