On-Demand Resources abgekündigt: Müssen Sie 2026 auf iOS 27 migrieren?

Warten Sie nicht auf die formale Entfernung von On-Demand Resources: Ein aktiv gepflegtes Projekt sollte 2026 die Ressourcen inventarisieren und eine Background-Assets-Doppelspur unter iOS 27 testen. Nur Apps ohne kurzfristigen Release und mit geringer Ressourcenabhängigkeit können den Produktionswechsel zunächst verschieben.

Für wen diese Entscheidungshilfe gedacht ist: Sie nutzen On-Demand Resources noch für große Spiellevel, Medien, Machine-Learning-Modelle oder lokalisierte Inhalte und müssen die Auswirkungen der Abkündigung bewerten. Sie pflegen mehrere minimale iOS-Versionen oder veröffentlichen über einen entfernten Mac beziehungsweise eine dauerhaft laufende Build-Maschine. Dann gehören Ressourcenpakete, Signierung, TestFlight und Rollback in dieselbe Abnahme.

Zuletzt aktualisiert am 25.08.2026; der technische Stand wurde anhand der offiziellen Apple-Dokumentation, der App-Store-Connect-Hilfe und der Xcode-27-Release-Notes geprüft.

Die Abkündigung ist ein Planungsrisiko, kein sofortiger Ausfall

Apple bestätigt, dass On-Demand Resources ab iOS 27, iPadOS 27, tvOS 27 und visionOS 27 abgekündigt sind und eine Migration zu Background Assets empfiehlt. Das bedeutet nicht, dass jede bestehende App am Veröffentlichungstag von iOS 27 ausfällt. Bis zum genannten Prüfdatum hat Apple jedoch keinen einheitlichen Termin für die endgültige Entfernung bekanntgegeben. Den Status dokumentiert Apple in den Xcode 27 Release Notes.

Sie sollten deshalb drei Fragen getrennt behandeln:

• Läuft die bestehende App heute noch? Das muss für jede unterstützte Systemversion und jede Ressourcenanforderung geprüft werden.
• Ist On-Demand Resources für ein neues Projekt noch eine vertretbare Wahl? Für ein neues, langfristig gepflegtes Projekt spricht die Abkündigung gegen eine weitere Verankerung in diesem Modell.
• Ist die Unterstützung in einem späteren System garantiert? Nein. Solange kein Entfernungstermin feststeht, ist die Restlaufzeit unbekannt und darf nicht als Zusage interpretiert werden.

Die Entscheidung hängt damit nicht nur vom Framework ab. Ausschlaggebend sind der nächste Release-Termin, die Bedeutung der nachgeladenen Inhalte, der Anteil älterer Systeme, die Testabdeckung und die Möglichkeit, bei einem Fehler auf die bisherige Kette zurückzugehen.

Wichtig: Eine erfolgreiche lokale Installation beweist weder, dass das Asset-Paket korrekt für TestFlight verarbeitet wurde, noch dass ein Nutzerdownload nach einem Abbruch fortgesetzt werden kann. Diese Zustände müssen getrennt nachgewiesen werden.

Ihre erste Einstufung

• Sofort migrieren und parallel testen: Die Ressourcen sind für den ersten Start oder zentrale Funktionen wichtig, die App erhält regelmäßig Updates oder ein Release für iOS 27 steht zeitnah an.
• Doppelspur aufbauen: Die App bleibt aktiv, ältere Installationen benötigen den bisherigen Pfad, und das Team kann den neuen Downloadweg zunächst nur für neuere Systeme oder einen internen Build aktivieren.
• Produktion vorerst nicht umstellen: Es gibt kurzfristig keinen Release, die Ressourcen sind nicht kritisch und die App wird nur eingeschränkt gepflegt. Trotzdem sollten Sie einen Prototypen und einen späteren Prüftermin festlegen.

Mindestversionen bestimmen den kompatiblen Pfad

Background Assets dürfen nicht einfach als universeller Ersatz betrachtet werden. Entscheidend ist, welche API-Funktionen Ihre Zielsysteme unterstützen, welche Funktion erst mit iOS 27 relevant wird und welche Verteilung über App Store Connect für Ihre konkrete Paketart zugelassen ist. Apple dokumentiert die Verwaltung über Managed Asset Packs sowie die Laufzeitsteuerung mit AssetPackManager.

Erstellen Sie vor einer Codeänderung eine Matrix aus:

1. minimaler Deployment-Version Ihres Projekts;
2. aktiv genutzten Systemversionen Ihrer Kunden;
3. Ressourcenpfad der alten App-Version;
4. Ressourcenpfad der neuen App-Version;
5. Rückfallverhalten bei inkompatibler API oder fehlendem Download.

Die aktive Nutzerverteilung darf dabei nicht durch eine allgemeine Marktstatistik ersetzt werden. Wenn ältere Installationen weiterhin einen ODR-Tag anfordern, müssen diese Anfragen funktionieren, solange Sie die entsprechenden Systeme offiziell unterstützen. Ein neuer Background-Assets-Pfad kann daneben eingeführt werden, ohne die alte Kette sofort zu löschen.

Für jede Version sollten Sie zudem klären, ob die Ressourcen bereits im App-Bundle liegen, beim ersten Start geladen werden oder erst nach einer Nutzeraktion benötigt werden. Diese Unterscheidung beeinflusst nicht nur die API-Auswahl, sondern auch die Startfähigkeit ohne Netzwerk, die App-Store-Prüfung und die Größe des initialen Downloads. Die Apple-Dokumentation zu ODR-Größenlimits ist deshalb bei der Bestandsaufnahme weiterhin relevant.

Ressourcen müssen neu klassifiziert werden, statt nur neue Namen zu bekommen

Ein ODR-Tag ist kein direkter Ersatz für ein Background-Assets-Paket. Bei der Migration wird zunächst das Ressourcenmodell neu geordnet. Für jedes Asset sollte eine verantwortliche Person festhalten, wann es benötigt wird, wie lange es lokal verfügbar sein muss und ob ein Fehlschlag die gesamte App unbrauchbar macht.

Verwenden Sie dafür vier Kategorien:

• Initial erforderlich: Inhalte, ohne die der erste nutzbare Bildschirm oder die Kernfunktion nicht funktioniert.
• Frühzeitig vorzuladen: Ressourcen, die nach dem Start sicher benötigt werden, aber nicht in den initialen Installationsumfang gehören.
• Echtzeitabhängig auf Abruf: Inhalte, die erst nach einer konkreten Nutzeraktion geladen werden.
• Optional oder ersetzbar: Inhalte, für die ein lokaler Platzhalter, eine reduzierte Variante oder ein späterer erneuter Versuch möglich ist.

Danach prüfen Sie für jede Kategorie fünf technische Eigenschaften:

• Was löst den Download aus?
• Wo wird der lokale Zustand verwaltet?
• Wie wird eine neue Paketversion erkannt?
• Was passiert nach einem abgebrochenen oder fehlerhaften Download?
• Welche Inhalte dürfen offline weiterverwendet werden?

Die Background-Assets-APIs unterstützen diesen neuen Kontrollpunkt, aber sie nehmen Ihnen die Produktentscheidung nicht ab. Eine App muss wissen, ob sie einen Download erneut versucht, den Nutzer informiert, eine kleinere Alternative verwendet oder die Funktion vorübergehend deaktiviert. Gerade bei Spielen und Medien ist ein halb heruntergeladenes Paket kein normaler Erfolg, sondern ein eigener Zustand.

Behalten Sie außerdem ausführbaren Code strikt von Datenressourcen getrennt. Asset-Pakete sind kein Kanal, um nachträglich Programmcode zu verteilen oder die Signierung der App zu umgehen. Modelle, Audio, Bilder, Leveldaten und Lokalisierungsdateien können Ressourcen sein; neue Logik gehört in einen regulär signierten und geprüften App-Build.

Apple-Hosting und eigenes Hosting verteilen die Verantwortung unterschiedlich

Die Wahl zwischen Apple-Hosted Background Assets und eigener Infrastruktur ist eine Betriebsentscheidung. Apple-Hosting passt häufig zu unabhängigen Entwicklern, die ausschließlich TestFlight und den App Store verwenden und keine zusätzliche CDN- oder Paketverwaltung betreiben wollen. Apple beschreibt den Ablauf für Apple-Hosted Asset Packs sowie die Konfiguration des Downloads in der Dokumentation für Apple-gehostete Pakete.

Keiner der Wege ist pauschal schneller oder stabiler. Bei Apple-Hosting müssen Sie die Paketversionen und App-Versionen sauber koordinieren. Beim eigenen Hosting müssen Sie unter anderem Erreichbarkeit, Zugriffsschutz, Cache-Regeln, Wiederholungen und Rollback selbst betreiben. Prüfen Sie zusätzlich, ob Ressourcen oder Protokolle personenbezogene Daten enthalten; die Zuständigkeit für Datenschutz und DSGVO-Dokumentation verschwindet nicht durch einen externen Verteilungsweg.

Für ein kleines Team ist ein begrenzter Apple-Hosted-Prototyp oft der bessere erste Schritt, sofern die App ohnehin über App Store Connect verteilt wird. Ein vorhandenes CDN kann dagegen sinnvoll bleiben, wenn dieselben Inhalte bereits von mehreren Plattformen genutzt werden. Dokumentieren Sie die Entscheidung gemeinsam mit dem Fallback, statt sie allein nach dem Upload-Komfort zu treffen.

Die Veröffentlichung braucht eine gestufte Abnahme

Teilen Sie die Migration in getrennte Prüfungen. So erkennen Sie, ob ein Fehler aus der Ressourcenlogik, dem Paketupload, der Signierung oder der tatsächlichen Installation stammt.

1. Bestand erfassen: Exportieren Sie eine Liste aller ODR-Tags, Dateien, Größenklassen, Aufrufer und kritischen Nutzerpfade. Markieren Sie Ressourcen, die beim Start, beim Offline-Betrieb oder bei einem Kauf zwingend vorhanden sein müssen.

2. Zielmodell definieren: Ordnen Sie jedes Asset einer Background-Assets-Kategorie zu. Legen Sie Paketbezeichner, Versionen und Platzhalter fest. Verwenden Sie für App ID, Bundle ID, App Group, Ressourcenpaket-ID, Verzeichnisse und API-Zugangsdaten ausschließlich klar erkennbare Platzhalter wie <APP_ID> oder <ASSET_PACK_ID> in internen Beispielen.

3. Lokal testen: Richten Sie einen lokalen Testdienst ein und simulieren Sie Erstdownload, bereits vorhandenen Cache, Paketupdate, fehlende Verbindung und einen Abbruch während der Übertragung. Apple beschreibt dafür das lokale Testen von Asset-Paketen. Der Test gilt erst als bestanden, wenn die App nach einem erneuten Start den korrekten Zustand wiederherstellt.

4. Signierten Build erzeugen: Bauen Sie die App mit der vorgesehenen Xcode-27-Toolchain und prüfen Sie Erweiterungen, Entitlements, Zertifikate und Provisioning Profiles. Ein lokaler Debug-Build ist kein Nachweis für den Releasepfad. Bewahren Sie Buildnummer, Ressourcenpaket-Version und erzeugte Artefakte gemeinsam auf.

5. Paket hochladen und isoliert prüfen: Laden Sie den Build und die Ressourcen nach dem vorgesehenen Apple- oder Hostingprozess hoch. Trennen Sie den Status des App-Builds vom Status des Ressourcenpakets. „Upload erfolgreich“ bedeutet lediglich, dass der Dienst die Artefakte angenommen hat.

6. TestFlight installieren: Installieren Sie eine frische App auf einem Testgerät oder einer klar getrennten Testumgebung. Prüfen Sie Erststart, Hintergrunddownload, App-Neustart, Versionswechsel und die Wiederaufnahme nach einer Unterbrechung. Für Apple-gehostete Pakete beachten Sie die offizielle TestFlight-Prüfung.

7. Rollback ausführen: Simulieren Sie ein fehlerhaftes Paket, eine inkompatible ältere Systemversion und einen fehlgeschlagenen Release. Definieren Sie vorher, ob Sie den App-Build zurücknehmen, das Paket auf eine vorherige Version setzen oder eine Funktion deaktivieren. Ohne dokumentierte Rückfallaktion ist die Migration nicht releasefähig.

Für eine remote betriebene Build-Maschine kommen zusätzliche Abnahmepunkte hinzu. Prüfen Sie, ob die richtige Xcode-Version verfügbar ist, ob Zertifikate und Profile sicher eingebunden werden, ob Kommandozeilen-Builds dieselben Pakete erzeugen wie der lokale Build und ob Logs nach einer getrennten Sitzung erhalten bleiben. Ebenso wichtig ist die Wiederaufnahme eines unterbrochenen Upload- oder TestFlight-Jobs. Informationen zu Mac-Arbeitsumgebungen für Entwicklungs- und Build-Szenarien helfen Ihnen dabei, die Infrastrukturfrage von der eigentlichen Ressourcenmigration zu trennen.

Die Migrationsentscheidung lässt sich an fünf Widerständen festmachen

Bewerten Sie Ihr Projekt nicht nach dem Alter des Codes, sondern nach den Hindernissen, die einen sicheren Wechsel verhindern:

• Kritische Abhängigkeit: Ohne nachgeladene Ressourcen startet die Kernfunktion nicht oder ein zentraler Kaufpfad scheitert.
• Alte Systeme: Ein relevanter Teil Ihrer Installationen kann den neuen Pfad nicht verwenden und benötigt weiterhin ODR.
• Enges Releasefenster: Ein kommender App-Store-Release lässt keine ungetestete Ressourcenarchitektur zu.
• Geringe Automatisierung: Paketversionen, Signierung, Upload und TestFlight werden manuell und ohne Protokollierung durchgeführt.
• Kein Rückfall: Es gibt keinen reproduzierbaren alten Build oder keine Möglichkeit, die neue Ressourcenversion zurückzusetzen.

Je mehr dieser Punkte zutreffen, desto früher sollten Sie mit der Doppelspur beginnen. Ein Projekt mit kritischen Ressourcen und regelmäßigen Releases sollte zuerst einen minimalen Background-Assets-Pfad unter iOS 27 nachweisen und erst danach die Produktionslogik umstellen. Bei geringer Abhängigkeit genügt zunächst ein kleines repräsentatives Paket, das aber denselben Signierungs-, Upload- und Installationsweg durchläuft.

Abnahme-Checkliste für Ihr Team

• [ ] Alle ODR-Tags und ihre tatsächlichen Aufrufer sind inventarisiert.
• [ ] Jede Ressource ist als initial, vorab geladen, echtzeitabhängig oder optional klassifiziert.
• [ ] Minimale Deployment-Version und aktive Systemverteilung sind dokumentiert.
• [ ] Der alte Pfad bleibt für betroffene Installationen funktionsfähig.
• [ ] Ein Background-Assets-Paket wurde lokal mit Fehler- und Offlinefällen getestet.
• [ ] App-Build, Paketversion, Downloadstatus und TestFlight-Status werden getrennt protokolliert.
• [ ] Signierung, Entitlements und Kommandozeilen-Build sind auf der vorgesehenen Build-Maschine geprüft.
• [ ] Ein Rollback mit eindeutigem Auslöser und verantwortlicher Person ist beschrieben.
• [ ] Die Umschaltung in die Produktion erfolgt erst nach einem reproduzierbaren TestFlight-Nachweis.

Wenn Ihre bisherige Lösung ein lokaler Mac oder eine gemeinsam genutzte Build-Maschine ist, entstehen bei der Migration oft drei konkrete Schwächen: Die Umgebung ist nicht dauerhaft verfügbar, mehrere Entwickler überschreiben sich bei Zertifikaten und Artefakten, und ein unterbrochener Upload lässt sich nur schwer reproduzieren. Ein gemieteter Mac von KVMFLUX kann dafür als isolierte Migrations- und Testumgebung dienen, ohne den bestehenden Veröffentlichungsrechner anzutasten. Die verfügbaren KVMFLUX-Mietmodelle sollten Sie dabei gegen Ihre tatsächliche Testdauer, den Bedarf an dauerhaftem Zugriff und die Anforderungen an Datenschutz und Zugriffsrechte prüfen; für einen kurzen Prototypen ist ein eigener Produktionswechsel nicht automatisch wirtschaftlicher.

FAQ zur Migration

Funktionieren On-Demand Resources unter iOS 27 noch?

Apple hat On-Demand Resources ab iOS 27 als abgekündigt bestätigt. Eine einheitliche sofortige Abschaltung wurde bis zum 25.08.2026 jedoch nicht veröffentlicht. Bestehende Apps können kurzfristig weiterhin funktionieren, müssen aber unter iOS 27 und mit ihren realen Ressourcenpfaden getestet werden. Für neue Projekte sollten Sie die Technologie nicht mehr als langfristige Grundlage einplanen.

Wann entfernt Apple On-Demand Resources endgültig?

Ein verbindlicher, allgemeiner Entfernungstermin ist bis zum 25.08.2026 nicht dokumentiert. Deshalb sollten Sie weder ein Datum aus einer Community-Diskussion übernehmen noch die aktuelle Funktionsfähigkeit als langfristige Garantie verstehen. Setzen Sie einen internen Prüfpunkt, verfolgen Sie Apples Dokumentation und behandeln Sie eine spätere Entfernung als Release-Risiko mit vorbereitetem Rückfall.

Was unterscheidet Background Assets von On-Demand Resources?

Die beiden Modelle unterscheiden sich nicht nur durch die Paketbezeichnung. Background Assets verlangen eine eigene Betrachtung von Downloadsteuerung, Paketstatus, Versionierung, Cache und Fehlerwiederholung. Ein ODR-Tag kann daher nicht mechanisch in einen neuen Namen übersetzt werden. Sie müssen die Ressourcenlebenszyklen neu zuordnen und den Nutzerpfad bei Offlinebetrieb oder abgebrochenem Download erneut abnehmen.

Wie bleiben ältere iOS-Versionen kompatibel?

Behalten Sie den bisherigen ODR-Pfad dort, wo die minimale Deployment-Version oder die installierte App-Version ihn weiterhin benötigt. Aktivieren Sie Background Assets zunächst nur für den unterstützten neuen Pfad und prüfen Sie beide Wege mit getrennten Tests. Wichtig sind identische Ressourceninhalte, nachvollziehbare Paketversionen und ein Fallback, der nicht erst bei einem Produktionsfehler erfunden wird.

Ist Xcode 27 zwingend erforderlich?

Für die Ressourceninventur, die Klassifizierung und Teile des Prototyps nicht unbedingt. Für die finale Prüfung von iOS 27, Paketverarbeitung, Signierung und Upload sollten Sie jedoch Xcode 27 einsetzen, wenn diese Toolchain für Ihren Release vorgesehen ist. Testen Sie den tatsächlichen Buildweg auf der später verwendeten Maschine und verlassen Sie sich nicht ausschließlich auf einen lokalen Entwicklungsbuild.

Beginnen Sie nach der Bestandsaufnahme mit einem kleinen, isolierten Background-Assets-Paket und lassen Sie es vollständig durch lokale Tests, signierten Build und TestFlight laufen. Wenn Ihnen kein dauerhaft verfügbarer Test-Mac zur Verfügung steht, kann eine separate KVMFLUX-Umgebung die Migrationsspur aufnehmen, während Ihre bestehende Veröffentlichungsmaschine unverändert bleibt. Den Produktionswechsel sollten Sie erst freigeben, wenn Ressourcenstatus, ältere Systeme und Rollback mit überprüfbaren Artefakten nachgewiesen sind.

Häufige Fragen