Genmoji und NSAdaptiveImageGlyph: Wie Apps benutzergenerierte Inline-Emojis darstellen

Genmoji ist der benutzerseitige Name für die Funktion zur Erstellung benutzerdefinierter Emojis von Apple Intelligence: Der Benutzer gibt eine Beschreibung ein, das System generiert ein eingebettetes emoji-ähnliches Bild, und das Ergebnis erscheint im Text neben Unicode-Emojis. Die entwicklerseitige Schnittstelle ist NSAdaptiveImageGlyph, eine ab iOS 18 verfügbare Klasse, die adaptive Inline-Bilder in attribuiertem Text repräsentiert¹. Genmoji ist eine Quelle von NSAdaptiveImageGlyph-Instanzen; Apps, die attribuierten Text verarbeiten, müssen diese Klasse unterstützen, um Genmoji (und alle künftigen Inhalte mit adaptiven Bildglyphen, die Apple einführt) anzuzeigen.

Der Beitrag geht das API anhand der Apple-Dokumentation durch. Die Perspektive lautet: „Was muss eine bestehende textverarbeitende App tun, um Genmoji korrekt anzuzeigen”, denn die meisten Apps, die benutzerseitig eingegebenen Text in einer UITextView entgegennehmen, müssen sich für adaptive Bildglyphen entscheiden, damit das Genmoji des Benutzers überhaupt gerendert wird, und auf der Persistenzseite gibt es Serialisierungsimplikationen, die häufig übersehen werden.

TL;DR

• NSAdaptiveImageGlyph (iOS 18+) ist ein Datentyp, der ein adaptives Bild zusammen mit identifizierenden Metadaten kapselt. Genmoji-Eingaben über die Systemtastatur kommen als NSAdaptiveImageGlyph-Instanzen an, die in attribuierten Text eingebettet sind².
• supportsAdaptiveImageGlyph ist im UITextInput-Protokoll deklariert; UITextView entspricht diesem Protokoll, daher lässt sich die Eigenschaft als textView.supportsAdaptiveImageGlyph = true setzen. Der Standardwert ist false; ohne dieses Opt-in wird vom Benutzer eingegebenes Genmoji nicht gerendert.
• Adaptive Bildglyphen erfordern TextKit 2. Apps, die noch TextKit 1 verwenden, rendern NSAdaptiveImageGlyph nicht korrekt. Neue Apps mit Ziel-iOS 18+ sollten standardmäßig TextKit 2 nutzen.
• NSAttributedString transportiert adaptive Bildglyphen über das Attribut NSAttributedString.Key.adaptiveImageGlyph. Der Initialisierer NSAttributedString(adaptiveImageGlyph:attributes:) erzeugt einen attribuierten String, der eine einzelne Glyphe enthält³.
• Persistenz und Round-Trip erfordern Sorgfalt. Reine Textspeicherung entfernt Genmoji vollständig; Rich-Text-Formate (RTFD, Markdown mit Erweiterungen, HTML mit eingebetteten Bilddaten) erhalten sie.

Was NSAdaptiveImageGlyph enthält

Eine NSAdaptiveImageGlyph-Instanz ist ein Datencontainer mit vier identifizierenden Eigenschaften²:

• imageContent: Data. Die eigentlichen Bilddaten, im durch contentType deklarierten Format.
• contentIdentifier: String. Ein eindeutiger Bezeichner für die Glypheninstanz. Wird zur Deduplizierung und für das systeminterne Caching verwendet.
• contentDescription: String. Alternativtext, der die Glyphe beschreibt. Apps, die Barrierefreiheits-Labels darstellen oder Glyphen an Empfänger senden, die keine Glyphen unterstützen, verwenden diesen.
• contentType: UTType. Eine klassenweite Typeigenschaft, die das von Apple für adaptive Glyphen verwendete Bildformat (eine HEIC-Variante) zur Verfügung stellt. Apps, die serialisieren, prüfen diese Eigenschaft, um eine formatabhängige Verarbeitung zu steuern.

Die Daten umfassen für ein Standard-Genmoji typischerweise mehrere Dutzend Kilobyte. Mehrere Größen werden mithilfe der adaptiven Bildfunktionen von HEIC in derselben Bilddatei kodiert; das System wählt je nach Renderkontext die passende Größe aus.

Adaptive Bildglyphen in UITextView aktivieren

Das Opt-in besteht aus einer einzigen Eigenschaft¹:

import UIKit

let textView = UITextView()
textView.supportsAdaptiveImageGlyph = true
// Also requires TextKit 2 (default on UITextView for iOS 16+
// when constructed via Interface Builder or modern initializer)

Ohne supportsAdaptiveImageGlyph = true erscheint vom Benutzer eingegebenes Genmoji als Platzhalterzeichen (das System kann die Glyphe nicht rendern). Das Setzen der Eigenschaft aktiviert sowohl das Rendering als auch den „Genmoji”-Tab der Systemtastatur, sodass der Benutzer eigene Genmoji innerhalb der Textansicht erstellen kann.

Die nativen SwiftUI-Komponenten TextField und TextEditor bieten derzeit keinen supportsAdaptiveImageGlyph-Modifier. SwiftUI-Apps, die Rendering adaptiver Bildglyphen benötigen, kapseln eine UITextView in einer UIViewRepresentable und setzen supportsAdaptiveImageGlyph = true an der zugrunde liegenden View. Community-Wrapper wie GlyphMeThat stellen diese Brücke bereits fertig zur Verfügung.

TextKit 2 ist tragend

NSAdaptiveImageGlyph setzt die Layoutarchitektur von TextKit 2 voraus⁴. TextKit 1 (die ältere Text-Engine, die mit dem ursprünglichen Modell aus NSTextStorage/NSLayoutManager/NSTextContainer ausgeliefert wurde) rendert adaptive Bildglyphen nicht korrekt; die Glyphe erscheint als generischer Platzhalter oder wird gar nicht angeordnet.

Apps befinden sich in einem von drei Zuständen:

Neue Apps unter iOS 18+. Standardmäßig TextKit 2. Eine UITextView, die über Interface Builder oder init(frame:textContainer:) initialisiert wird, verwendet ab iOS 16+ standardmäßig TextKit 2. Neuer Code erhält das ohne Zusatzaufwand.

Bestehende Apps, die noch TextKit 1 verwenden. Eine Migration ist erforderlich. Die Migration auf TextKit 2 ist nicht trivial für Apps, die NSLayoutManager ableiten, layoutbezogene Delegate-Methoden überschreiben oder das ältere NSTextStorage direkt verwenden. Apples TextKit-Migrationsleitfaden beschreibt den Weg; bei Apps mit einfacher UITextView-Nutzung läuft die Migration weitgehend automatisch ab.

Hybride Apps. Manche Apps binden WKWebView für die HTML-Bearbeitung neben UITextView für die einfache Bearbeitung ein. WKWebView verarbeitet adaptive Bildglyphen über seinen eigenen Renderingpfad (nicht TextKit), sodass eine hybride App eine Oberfläche haben kann, die Genmoji unterstützt, und eine andere, die sie verwirft. Dokumentieren Sie das Verhalten; Benutzer bemerken, wenn ein Editor benutzerdefinierte Emojis unterstützt und der andere sie entfernt.

Integration mit NSAttributedString

Adaptive Bildglyphen fließen über das Attribut NSAttributedString.Key.adaptiveImageGlyph durch attribuierte Strings³:

import UIKit

// Construct an attributed string containing a single adaptive image glyph
let glyph: NSAdaptiveImageGlyph = ...
let attrString = NSAttributedString(
    adaptiveImageGlyph: glyph,
    attributes: [
        .font: UIFont.systemFont(ofSize: 17)
    ]
)

// Concatenate with surrounding text
let composed = NSMutableAttributedString(string: "Look at this ")
composed.append(attrString)
composed.append(NSAttributedString(string: " I just made!"))

Das Muster lässt sich kombinieren: eine Glyphe innerhalb von Text innerhalb von weiterem Text. Das System übernimmt das Layout (einschließlich der adaptiven Größenanpassung der Glyphe an die Schriftart des umgebenden Textes) automatisch.

Beim Lesen liefert das Iterieren über das Attribut .adaptiveImageGlyph eines NSAttributedString die NSAdaptiveImageGlyph-Instanzen an den Positionen, an denen sie auftreten:

attributedString.enumerateAttribute(
    .adaptiveImageGlyph,
    in: NSRange(location: 0, length: attributedString.length)
) { value, range, _ in
    if let glyph = value as? NSAdaptiveImageGlyph {
        // process glyph + range
    }
}

Apps, die Text filtern, transformieren oder persistieren, nutzen diese Aufzählung, um Glyphen zu finden und zu entscheiden, was mit ihnen geschehen soll.

Persistenz und Serialisierung

Reine Textspeicherung (ein String, eine UTF-8-Datei) bewahrt adaptive Bildglyphen nicht. Das Unicode-Platzhalterzeichen, das die Glyphe in attribuiertem Text repräsentiert, wird als U+FFFC (Object Replacement) oder gar nicht serialisiert, und die eigentlichen Glyphendaten gehen verloren.

Für eine Round-Trip-fähige Persistenz benötigen Apps ein Rich-Text-Format⁵:

RTFD. Apples Rich-Text-und-Anhänge-Format. Round-Trip-fähig für adaptive Bildglyphen. Wird von Notizen, Mail (beim Versenden von Rich-Inhalten) und TextEdit verwendet. Das Format ist umfangreich (ein Verzeichnisbündel mit Anhängen), aber verlustfrei.

HTML mit eingebetteten Bildern. Webfreundlich. Glyphen werden als <img>-Tags mit base64-kodierten Daten-URIs serialisiert. Größere Datenmengen, funktioniert aber bei den meisten Empfängern, die Rich-Text verarbeiten können.

Markdown mit Erweiterungen. Standard-Markdown bietet keine Syntax für adaptive Bildglyphen, aber erweiterte Dialekte (CommonMark mit Anhangsunterstützung, Apples eigenes erweitertes Markdown) können sie transportieren. Dokumentieren Sie die Dialektanforderung für jede markdownbasierte Persistenz.

Apps, die Text über das Netzwerk versenden (Chat, E-Mail, Social Media), müssen sich entscheiden: Glyphen Ende-zu-Ende erhalten (funktioniert nur, wenn sowohl Sender als auch Empfänger iOS 18+ verwenden und der Transport Rich-Text unterstützt), Glyphen entfernen und durch Ersatztext (contentDescription) ersetzen oder die Glyphe als Systembild rendern und das Bild einbetten. Die richtige Wahl hängt vom Publikum und der Plattform ab.

Häufige Fehler

Drei Muster aus Genmoji-Integrationsprotokollen:

supportsAdaptiveImageGlyph = true vergessen. Der häufigste Fehler. Die Textansicht rendert Unicode-Emojis korrekt, aber Genmoji erscheint als Platzhalterzeichen. Lösung: Setzen Sie die Eigenschaft auf true in jeder UITextView/NSTextView, die benutzerseitig eingegebenen Text annimmt. Verwenden Sie in SwiftUI den Modifier .supportsAdaptiveImageGlyph(true).

Reine Textpersistenz entfernt Glyphen. Speichert man den Inhalt der Textansicht als text (einfacher String), gehen Genmoji verloren. Der Benutzer gibt ein benutzerdefiniertes Emoji ein, sieht es in der Textansicht, speichert das Dokument, öffnet es erneut – das Emoji ist verschwunden. Lösung: Persistieren Sie als attributedText mit einem Rich-Text-Format, das adaptive Bildglyphen unterstützt (RTFD, HTML, ein eigenes Format mit Anhangs-Seitenkanal).

Netzwerkübertragung verwirft Glyphen stillschweigend. Eine Messaging-App, die ausgehende Nachrichten als reinen Text serialisiert, entfernt Genmoji beim Versand. Der Empfänger sieht ein Platzhalterzeichen oder Leerraum. Lösung: Senden Sie entweder Rich-Inhalte (und stellen Sie sicher, dass der Empfänger diese unterstützt) oder ersetzen Sie für Empfänger reinen Texts den Inhalt durch contentDescription und fügen Sie die Bilddaten als separaten Anhang bei.

Was dieses Muster für iOS-18+-Apps bedeutet

Drei Erkenntnisse.

1. Setzen Sie supportsAdaptiveImageGlyph = true an jeder Texteingabe. Apps, die benutzerseitig eingegebenen Text annehmen, sollten standardmäßig adaptive Bildglyphen aktivieren. Diese eine Eigenschaft entscheidet zwischen funktionierendem Genmoji und kaputtem Genmoji.

2. Migrieren Sie auf TextKit 2, falls Sie noch TextKit 1 verwenden. TextKit 1 befindet sich im Wartungsmodus. Neue Funktionen aus der iOS-26-Ära (adaptive Bildglyphen, Inline-Umformulierung der Writing Tools, Liquid-Glass-Textrendering) setzen alle TextKit 2 voraus. Der Migrationsaufwand ist real, aber die Alternative bedeutet, in einer veralteten Text-Engine auszuliefern.

3. Wählen Sie Ihr Persistenzformat mit Blick auf adaptive Bildglyphen. RTFD für native iOS-Speicherung; HTML mit eingebetteten Bildern für webkompatible Speicherung; ein eigenes Binärformat mit Anhangs-Seitenkanal für leistungskritische Apps. Reiner Text ist die falsche Standardwahl für Apps, in denen Benutzer Genmoji eingeben werden.

Der vollständige Apple-Ecosystem-Cluster: typisierte App Intents; MCP-Server; die Routing-Frage; Foundation Models; die Unterscheidung LLM Laufzeit vs. Tooling; drei Oberflächen; das Single-Source-of-Truth-Muster; zwei MCP-Server; Hooks für die Apple-Entwicklung; Live Activities; die watchOS-Laufzeit; SwiftUI-Interna; RealityKits räumliches mentales Modell; SwiftData-Schemadisziplin; Liquid-Glass-Muster; Multi-Plattform-Auslieferung; die Plattformmatrix; Vision-Framework; Symbol Effects; Core-ML-Inferenz; Writing Tools API; Swift Testing; Privacy Manifest; Barrierefreiheit als Plattform; SF-Pro-Typografie; visionOS-Raummuster; Speech-Framework; SwiftData-Migrationen; tvOS Focus Engine; @Observable-Interna; SwiftUI Layout-Protokoll; eigene SF-Symbole; AVFoundation HDR; watchOS-Workout-Lebenszyklus; App Intents 2.0 in iOS 26; Image Playground API; worüber ich nicht schreiben werde. Der Hub befindet sich unter Apple Ecosystem Series. Für einen breiteren Kontext zu iOS mit AI-Agenten siehe den iOS Agent Development Guide.

FAQ

Bekommt meine App Genmoji „kostenlos”, wenn ich einfach UITextView verwende?

Nicht ganz. Der Standardwert von UITextView.supportsAdaptiveImageGlyph ist false. Apps müssen sich explizit anmelden, indem sie die Eigenschaft auf true setzen. Sobald aktiviert, erscheint der Genmoji-Tab der Systemtastatur für den Benutzer, und eingefügte Genmoji werden korrekt gerendert. Ohne Opt-in erscheinen anderswo eingegebene und in die Textansicht eingefügte Genmoji als Platzhalterzeichen.

Muss ich Apple Intelligence aktiviert haben, um Genmoji zu testen?

Für die vollständige Genmoji-Erstellung ja. Der benutzerseitige Genmoji-Erstellungsfluss erfordert Apple-Intelligence-fähige Hardware (iPhone 15 Pro und neuer, Macs mit M-Chip) mit iOS 18+ und aktiviertem Apple Intelligence. Für Entwicklungstests des NSAdaptiveImageGlyph-Renderings können Sie Test-Glypheninstanzen programmatisch mit Beispielbilddaten konstruieren und das Rendering der Textansicht auf jedem iOS-18+-Gerät oder Simulator überprüfen.

Was passiert mit einem Genmoji, wenn ich es an jemanden mit iOS 17 sende?

Ohne Rich-Text-Transport, der die Glyphe erhält, sieht der Empfänger den contentDescription (Alternativtext) oder ein Platzhalterzeichen. Moderne Messaging-Frameworks (Apples Nachrichten-App, aktuelle Versionen von Mail-Clients) regeln den Fallback automatisch; eigene Protokolle benötigen eine explizite Behandlung.

Kann ich NSAdaptiveImageGlyph-Instanzen programmatisch erzeugen?

Ja. Der öffentliche Initialisierer ist init(imageContent: Data) und nimmt vorab kodierte HEIC-Daten für adaptive Bilder entgegen. contentDescription, contentIdentifier und contentType werden aus den kodierten Daten gelesen, statt als separate Argumente übergeben zu werden; Apps, die benutzerdefinierte adaptive Bildglyphen erstellen, bereiten den HEIC-Payload mit eingebetteten Metadaten vor und konstruieren die Glyphe anschließend aus diesen Daten. Die WWDC-2024-Session 10220 („Bring expression to your app with Genmoji”) behandelt den vollständigen Erstellungsfluss.

Wie wirkt sich das auf Writing Tools aus?

Writing Tools (siehe Writing Tools API) erhalten adaptive Bildglyphen in ihren Umformulierungsergebnissen. Ein Benutzer, der Text mit Genmoji auswählt und Writing Tools zur Umformulierung auffordert, erhält eine Umformulierung, die das Genmoji an semantisch passenden Positionen erhält. Apps, die über UIWritingToolsCoordinator an Writing Tools teilnehmen, müssen die NSAdaptiveImageGlyph-Instanzen korrekt durch ihre eigene Textspeicherung hindurchschleifen.

Was ist der Unterschied zwischen NSAdaptiveImageGlyph und NSTextAttachment?

NSTextAttachment ist das ältere, allgemeinere Anhangssystem für eingebettete Nicht-Text-Inhalte (Bilder, Dateien, eigene Zeichnungen) in attribuiertem Text. NSAdaptiveImageGlyph ist die iOS-18-Spezialisierung für emoji-ähnliche Inline-Bilder, die sich an die Schriftmerkmale des umgebenden Textes anpassen. Beide werden über Attribute des attribuierten Strings angefügt, verwenden aber unterschiedliche Schlüssel (.attachment vs. .adaptiveImageGlyph) und unterschiedliche Renderingpfade (TextKit 1 + TextKit 2 vs. nur TextKit 2). Neuer Code, der Genmoji-artige Inhalte ins Auge fasst, verwendet NSAdaptiveImageGlyph.

Quellen