ImageCreator Is Deprecated: What Breaks in iOS 27

Apple published a deprecation notice today that needs attention before fall: the ImageCreator class, Image Playground’s API for generating images programmatically without UI, “is being discontinued and will no longer work in iOS 27, iPadOS 27, macOS 27, and visionOS 27 or later.”¹ The notice is unusually concrete about how the breakage unfolds. During the beta OS releases, code using ImageCreator still compiles with Xcode warnings, but apps “will not function in TestFlight builds and will cause a runtime error.”¹ At the public OS releases, the code stops compiling entirely.¹ An API that shipped in iOS 18.4 is gone one major version later, and the WWDC session that explains why also walks the migration path.

The deprecation announcement at 4:34 in session 375.

TL;DR

• Apple is discontinuing ImageCreator, the programmatic image-generation API in the Image Playground framework. It stops working in iOS 27, iPadOS 27, macOS 27, and visionOS 27.¹ Apple’s documentation marks the deprecation at 27.0 on five platforms, including Mac Catalyst.²
• The breakage is staged: beta releases compile with warnings but fail at runtime in TestFlight; public releases refuse to compile.¹ Apple’s instruction is to migrate “before the public release.”¹
• The reason is architectural. Image Playground’s models moved to Private Cloud Compute this year, and as the session puts it, “Moving the models to Private Cloud Compute also meant rethinking the API.”³
• The replacement is the system UI: the imagePlaygroundSheet SwiftUI modifier, or ImagePlaygroundViewController for UIKit and AppKit apps.³ Apple’s alternative suggestion is blunt: integrate “another image generation service of your choice.”¹
• The new sheet is more capable than the old one: photorealistic styles, seeding with concepts, drawings, and source images, size and style configuration, and an opt-in externalProvider style that surfaces a third-party provider like ChatGPT.³

What Apple announced, precisely

The June 11 notice on Apple’s developer news feed lays out a two-stage timeline.¹ In the beta OS releases, your code continues to compile, Xcode starts emitting warnings, and apps that call ImageCreator hit a runtime error in TestFlight builds. In the public OS releases, code that references the class no longer compiles, and any feature built on it stops working for users. Apple’s action item names the deadline: update your implementation “before the public release of iOS 27, iPadOS 27, macOS 27, and visionOS 27.”¹

The documentation tells the same story in API-reference form. ImageCreator arrived in iOS and iPadOS 18.4, macOS 15.4, and visionOS 2.4, and every platform row now carries a 27.0 deprecation, with Mac Catalyst joining the four platforms the news post names.² The class abstract describes exactly what is being lost: it “generates images programmatically from the description and style information you specify.”² There is no programmatic replacement. Apps that generated images headlessly, without presenting UI, have no direct equivalent in the framework.

For developers who already moved off the class, the notice closes the loop: “No further action is required.”¹

Why: the models moved to Private Cloud Compute

Session 375, “Create high quality images using Image Playground,” states the reason on the record. Image Playground was rebuilt this year around more powerful image models that produce “high quality images in virtually any style, even photorealistic ones,” and those models run on Private Cloud Compute, Apple’s privacy-preserving cloud infrastructure, rather than on device.³ Then the session connects the dots: “Moving the models to Private Cloud Compute also meant rethinking the API. ImageCreator, the non-UI API for generating images directly in your code, is deprecated.”³

The economics explain the design choice. Image Playground now has a usage limit “because it relies on powerful server models,” with increased access available through most iCloud+ subscription plans.³ The system manages those limits on the user’s behalf, and the session is explicit that the developer never builds usage-related UI.³ A headless API that apps could call in a loop sits awkwardly inside that model; a system-presented sheet the user drives does not. Whatever the internal reasoning, the shipped result is that image generation in the framework now goes through the system experience.

A side effect worth naming: ImageCreator ran the generation on device, while the new experience runs on Private Cloud Compute with the session’s assurance that “your data is never stored or shared, even with Apple.”³ Apps with a hard on-device requirement for image generation are the ones the framework no longer serves.

The migration: one view modifier

For SwiftUI apps, adoption of the replacement is small. The session’s demo app attaches .imagePlaygroundSheet to a button with a binding to a @State boolean; when the binding flips to true, the sheet appears, and the completion closure receives a URL to the generated file.³ The URL points to a temporary location inside the app container, so the session warns to save it elsewhere before the session ends.³ UIKit and AppKit apps get the same experience through ImagePlaygroundViewController, setting concepts and options as properties and receiving the result through a delegate method.³

What the sheet loses in programmability it partially recovers in seeding. ImagePlaygroundConcept carries app context into the sheet: text wraps a direct description, extracted takes longer text and lets the system pull out the relevant ideas, and drawing accepts a PKDrawing from PencilKit as a visual suggestion.³ A sourceImage parameter seeds the sheet with any SwiftUI Image as inspiration.³ ImagePlaygroundOptions and ImagePlaygroundStyle configure the rest: a closest(to:) size request maps any CGSize to the nearest supported resolution and aspect ratio, and the generation style takes a default plus an allowed list, locking the picker to a single style when the list has one entry.³

Two newer capabilities sweeten the trade. The externalProvider style is an opt-in entry that surfaces whatever third-party provider the user configured in Settings, ChatGPT for example, with the system handling setup when no provider exists.³ And the emoji style fires a separate completion that hands back an NSAdaptiveImageGlyph, embeddable inline with text like an emoji.³

Availability handling stays simple: the supportsImageGeneration environment value returns true only when the device has the capability, the language and region are supported, and the user has image generation enabled, so a single conditional covers the fallback path.³

The decision for affected apps

The notice gives two migration options and the session supplies the judgment material. Apps whose image generation was a user-facing creative feature should take the sheet: the new models are stronger than what ImageCreator called, the seeding API carries app context in, and the system absorbs usage limits, style pickers, and people-personalization for free.³ Apps that depended on headless generation, producing images in a background flow with no user interaction, have no path inside the framework; for them Apple’s second option, integrating “another image generation service of your choice,” is the honest answer.¹

The deprecation also fits a pattern this cycle. Apple marked MXMetricManager deprecated at 27.0 the same week it shipped the replacement reporting APIs, covered in MetricKit’s iOS 27 state reporting. The platform is pruning APIs one cycle after their replacements land, and the beta period is the migration window.

FAQ

When exactly does ImageCreator stop working?

In stages.¹ During the iOS 27, iPadOS 27, macOS 27, and visionOS 27 betas, code compiles with Xcode warnings, but TestFlight builds hit a runtime error. At the public releases this fall, the code no longer compiles and the features stop working for users. Apple’s documentation marks the deprecation at 27.0 across iOS, iPadOS, macOS, Mac Catalyst, and visionOS.²

Why did Apple remove programmatic image generation?

The session ties it to the architecture change: Image Playground’s models moved to Private Cloud Compute, and “moving the models to Private Cloud Compute also meant rethinking the API.”³ The new system manages server-model usage limits on the user’s behalf, with increased access through iCloud+ plans, a model that fits a user-driven sheet better than a headless API.³

What replaces it?

The system UI: the imagePlaygroundSheet modifier in SwiftUI or ImagePlaygroundViewController in UIKit and AppKit.³ You can seed it with text concepts, extracted text, PencilKit drawings, and a source image, and configure size, styles, and personalization. For headless generation, Apple’s stated alternative is a third-party image generation service.¹

Is anything generated still on device?

The session describes the new image generation as running on Private Cloud Compute, with the assurance that data “is never stored or shared, even with Apple.”³ Apps requiring strictly on-device image generation no longer have a framework path for it.

The Private Cloud Compute shift driving the change is the same one reshaping the text side of Apple Intelligence, covered in Foundation Models and Private Cloud Compute. For the other deprecation Apple shipped this cycle alongside a replacement, see MetricKit’s iOS 27 state reporting. The full series hub is the Apple Ecosystem Series.

References