On-Demand Resources: Upload-Limit 2027 – was tun? 2026

Apple setzt den Beginn der Uploadbeschränkung für bestimmte On-Demand-Resources-Uploads auf Anfang 2027; einen konkreten Kalendertag nennt die App-Store-Connect-Mitteilung zu On-Demand Resources nicht. Das ist keine sofortige Abschaltung aller bestehenden Apps: Neue Apps und Apps, die ODR zuvor nicht verwendet haben, sollten ihre Uploads rechtzeitig von ODR-Inhalten bereinigen. Bereits nutzende Projekte können weiterlaufen, sollten aber jetzt die Migration auf Background Assets bewerten und mit Xcode sowie dem tatsächlichen Releaseablauf testen.

Dieser Leitfaden ist für iOS- und Spieleentwickler gedacht, die feststellen müssen, ob ihr Projekt von der Uploadregel betroffen ist.
Er hilft Ressourcenverantwortlichen, Tags, Downloadlogik und Verfügbarkeitsannahmen neu zu ordnen.
CI- und Release-Teams erhalten einen Prüfpfad für lokale Tests und die anschließende Veröffentlichung.

Die Begriffe nicht vermischen: Uploadregel, Abkündigung und Laufzeit

Die Änderungen betreffen drei unterschiedliche Fragen. Wenn wir sie in einem Ticket zu „ODR wird abgeschaltet“ zusammenfassen, verlieren wir genau die Information, die für die Releaseentscheidung nötig ist.

Apple kündigt eine Uploadbeschränkung ab Anfang 2027 an. Sie betrifft Uploads neuer Apps sowie Apps, die ODR zuvor nicht eingesetzt haben, sofern diese Uploads ODR-Inhalte enthalten. Ein bestimmter Stichtag ist in der Mitteilung nicht genannt. Daher sollten Sie weder einen exakten Einreichungstermin erfinden noch die Regel so behandeln, als gelte sie bereits für jede vorhandene App.

Davon zu trennen ist die technische Abkündigung von On-Demand Resources. Apple empfiehlt die Migration zu Background Assets und bezeichnet ODR ab iOS 27, iPadOS 27, tvOS 27 und visionOS 27 als veraltet. Veraltet bedeutet nicht automatisch, dass jede veröffentlichte App am selben Tag nicht mehr startet oder vorhandene Ressourcen verliert. Apple erklärt, dass Apps, die ODR bereits verwenden, kurzfristig weiterlaufen können. Das ist jedoch kein Versprechen für dauerhafte Unterstützung oder für neue Uploads.

Für eine Einreichungsentscheidung ist die offizielle Beschreibung der ODR-Uploadregeln maßgeblich. Für die technische Bestandsaufnahme prüfen Sie zusätzlich die Dokumentation zu NSBundleResourceRequest. Damit bleibt in Ihrem Änderungsprotokoll erkennbar, ob Sie eine Uploadvorgabe, eine API-Abkündigung oder ein konkretes Laufzeitrisiko behandeln.

Wichtig für den Releaseplan: Verwenden Sie „Anfang 2027“ als von Apple genannte Zeitangabe. Setzen Sie keinen eigenen Kalendertag als vermeintlich offiziellen Stichtag ein. Prüfen Sie die Mitteilung erneut, bevor Sie eine Einreichung freigeben.

Betroffenheit im Projekt und im Archiv feststellen

Der Projektname oder die Erinnerung des Teams reichen nicht aus, um die Uploadregel einzuordnen. ODR kann in einer älteren App oder einem Teilziel weiter vorhanden sein, obwohl die aktuelle Entwicklung kaum noch daran arbeitet. Umgekehrt ist ein sichtbarer Verweis im Quellcode allein noch kein Beleg, dass der einzureichende Build ODR-Inhalte enthält.

Prüfen Sie deshalb getrennt: die historische Nutzung in veröffentlichten Versionen, die aktuelle Projektkonfiguration und das konkrete Archiv. Besonders bei Spielen sollten Sie außerdem feststellen, ob Inhalte erst nach der Installation geladen werden und welche Spielzustände einen Download voraussetzen. Diese Trennung verhindert, dass ein erfolgreiches lokales Build irrtümlich als Nachweis für die Uploadberechtigung gilt.

Gehen Sie die Prüfung in dieser Reihenfolge durch:

1. Historie dokumentieren. Erfassen Sie, ob und wann veröffentlichte Versionen ODR verwendet haben. Nutzen Sie Releaseunterlagen und archivierte Projektstände, nicht nur mündliche Auskünfte.
2. Targets und Konfigurationen durchsuchen. Prüfen Sie App-Targets, Erweiterungen und gegebenenfalls separate Spielziele auf ODR-Einstellungen sowie auf zugehörige Tags und Ressourcen.
3. Aufrufstellen auffinden. Suchen Sie nach NSBundleResourceRequest und erfassen Sie, wo eine Anfrage gestartet, beendet oder als fehlgeschlagen behandelt wird. Notieren Sie den jeweiligen Bildschirm, Spielabschnitt oder Funktionsablauf.
4. Einreichungsarchiv kontrollieren. Verifizieren Sie, ob das Archiv tatsächlich ODR-bezogene Inhalte enthält. Lassen Sie den Befund vom Releaseverantwortlichen festhalten, statt aus dem Vorhandensein alter Quelldateien auf den Uploadinhalt zu schließen.
5. Projektstatus zuordnen. Entscheiden Sie anhand der Apple-Mitteilung, ob es sich um eine neue, bislang ODR-freie App oder um eine App mit tatsächlicher ODR-Nutzung handelt. Wenn die Historie unklar ist, behandeln Sie sie als offene Releasefrage.
6. Nächste Aktion festlegen. Bei einer neuen oder bislang ODR-freien App entfernen Sie ODR-Inhalte aus dem geplanten Upload. Bei einer bestehenden ODR-App dokumentieren Sie zunächst die Migration und die weiterhin erforderlichen Tests.

Der letzte Punkt ist für Teams mit mehreren Branches wichtig. Ein Migrationsbranch kann ODR bereits entfernt haben, während ein Wartungsbranch oder eine alte Releasekonfiguration noch Ressourcen enthält. Geben Sie deshalb nicht nur den Hauptbranch frei. Binden Sie den Archivbefund an den konkreten Build und die konkrete Einreichung.

Migration als Architekturarbeit planen

Background Assets sind kein Schalter, der alte ODR-Tags automatisch in ein neues Format umwandelt. Das alte Modell kann Ressourcenanforderungen und deren Lebenszyklus in Code und Nutzerführung eingebettet haben. Eine erfolgreiche Migration beginnt daher mit der Frage, wann eine Ressource gebraucht wird und welche Funktion verfügbar bleiben muss, wenn sie noch nicht lokal vorliegt.

Die Anleitung zum Erstellen verwalteter Asset Packs beschreibt einen möglichen Zielpfad mit Managed Background Assets. Für Apple-gehostete Packs müssen Sie außerdem die Downloadkonfiguration und den Uploadprozess berücksichtigen. Falls Ihr Team Ressourcen selbst bereitstellt, gelten stattdessen die Anforderungen an ein selbst gehostetes Background-Assets-Projekt. Wählen Sie nicht allein danach, welcher Weg weniger Änderungen im ersten Pull Request verspricht: Entscheidend ist, wer Bereitstellung, Verfügbarkeit und Fehleranalyse verantwortet.

Verwenden Sie für jedes Tag eine Migrationsnotiz mit vier Angaben: Inhalt, auslösende Nutzeraktion, Zeitpunkt der benötigten Verfügbarkeit und Verhalten bei ausbleibendem Download. Erst danach ordnen Sie Inhalte Asset Packs und einer Strategie zu. Zwei ODR-Tags müssen nicht zwingend zwei Packs ergeben. Umgekehrt kann ein altes Tag mehrere fachlich unterschiedliche Ressourcen zusammengefasst haben, die künftig zu unterschiedlichen Zeitpunkten verfügbar sein sollen.

Auch NSBundleResourceRequest lässt sich nicht einfach durch einen gleichnamigen oder ähnlich wirkenden Aufruf ersetzen. Die API-Dokumentation zu NSBundleResourceRequest hilft, die vorhandene Implementierung zu inventarisieren. Sie ersetzt nicht die neue Architekturentscheidung. Überarbeiten Sie insbesondere Code, der implizit annimmt, dass eine Ressource nach einer Anfrage sofort verfügbar ist oder dauerhaft auf dem Gerät bleibt.

Prüfen Sie für jede Ressourcengruppe folgende Punkte:

• Nutzungszeitpunkt: Muss der Inhalt beim App-Start verfügbar sein, erst nach einer Aktion oder nur in einem bestimmten Spielabschnitt?
• Lokaler Verfügbarkeitsnachweis: Welche Bedingung bestätigt im Code, dass die Ressource wirklich verwendet werden kann?
• Nutzerführung: Was sieht die Person, während ein Download aussteht oder fehlschlägt?
• Wiederaufnahme: Kann der Ablauf nach einem Abbruch fortgesetzt werden, ohne einen beschädigten oder unvollständigen Zustand zu verwenden?
• Aufbewahrung und Bereinigung: Welche Inhalte müssen erneut verfügbar sein, und welche dürfen entfernt werden?
• Versionierung: Wie stellen Sie sicher, dass App-Code und ausgelieferte Packs zueinander passen?

Diese Prüfung ist keine reine Umbennung von APIs. Sie verändert, wann Inhalte verfügbar sind und wie die App mit einem nicht abgeschlossenen Download umgeht. Verknüpfen Sie darum die Migration mit UI- und Gameplay-Tests. Wenn eine Ressource für einen kritischen Ablauf gebraucht wird, darf die Oberfläche nicht allein aufgrund eines gestarteten Downloads in den nächsten Zustand wechseln.

Asset-Packs, Hosting und Veröffentlichung getrennt abnehmen

Ein Ressourcenpaket kann lokal korrekt erstellt sein und trotzdem in der späteren Verteilung fehlen oder nicht zum App-Build passen. Trennen Sie daher die Prüfung des Pack-Inhalts, den Upload beziehungsweise das Hosting und die Verteilung an Testende. Wer Managed Background Assets nutzt, muss den von Apple beschriebenen Upload für Apple-gehostete Asset Packs einplanen. Für die Testverteilung ist die Anleitung zum Testen Apple-gehosteter Asset Packs mit TestFlight relevant.

Bevor Sie reale Verteilungstests starten, testen Sie die Ressourcenlogik mit dem lokalen Mock-Server, der mit Xcode bereitgestellt wird. Apple beschreibt die Einrichtung und Verwendung in der Anleitung zum lokalen Testen von Asset Packs. Damit können Sie den lokalen Ablauf für Asset Packs prüfen, ohne daraus eine Aussage über die spätere Freigabe abzuleiten.

Wir empfehlen eine gestufte Abnahme:

1. Pack-Erstellung: Prüfen Sie, dass erwartete Inhalte in den vorgesehenen Asset Packs liegen und keine alten ODR-Ressourcen versehentlich zusätzlich im Archiv verbleiben.
2. Lokaler Download: Testen Sie mit dem Mock-Server den vorgesehenen Downloadweg und die Prüfung der lokalen Verfügbarkeit.
3. Fehlerpfade: Unterbrechen oder verweigern Sie im Testablauf einen Download. Die App muss einen verständlichen Zustand zeigen und darf nicht so tun, als seien die Ressourcen bereits bereit.
4. Build-Zuordnung: Kontrollieren Sie, dass App-Version und Ressourcenpakete zur selben geplanten Veröffentlichung gehören.
5. Projektverteilung: Testen Sie mit dem tatsächlichen Verteilungsweg des Projekts, einschließlich des vorgesehenen Beta-Prozesses bei Apple-gehosteten Packs.
6. Freigabeprotokoll: Halten Sie fest, welcher Build, welches Pack und welcher Testweg geprüft wurden. Vermerken Sie getrennt, ob der lokale Mock-Test, die Projektverteilung und die abschließende Veröffentlichung erfolgreich waren.

Ein bestandener Mock-Test ist kein Nachweis einer erfolgreichen App-Store-Prüfung. Er validiert einen lokalen Testablauf. Die anschließende Veröffentlichung hängt zusätzlich von Upload, Zuordnung, Verteilung und den geltenden Einreichungsregeln ab. Diese Unterschiede sollten im Releaseprotokoll sichtbar bleiben, damit ein lokales „grün“ nicht als Freigabe für den Store missverstanden wird.

Checkliste für die nächste Releaseentscheidung

• [ ] Ist dokumentiert, ob eine bereits veröffentlichte Version ODR tatsächlich verwendet hat?
• [ ] Sind ODR-Einstellungen und Ressourcen in allen relevanten Targets erfasst?
• [ ] Sind Aufrufstellen von NSBundleResourceRequest den betroffenen Funktionen zugeordnet?
• [ ] Ist der Inhalt des konkreten Einreichungsarchivs kontrolliert?
• [ ] Ist geklärt, ob die App nach Apples Mitteilung zur Gruppe der neuen oder bisher ODR-freien Apps gehört?
• [ ] Sind Ressourcenbedarf, lokale Verfügbarkeit und Fehlerverhalten für jedes Asset Pack festgelegt?
• [ ] Ist begründet, ob Managed oder selbst gehostete Background Assets zum Betrieb des Teams passen?
• [ ] Wurden lokaler Mock-Test, Projektverteilung und Store-Einreichung als getrennte Prüfschritte protokolliert?
• [ ] Wurde Apples Mitteilung vor der Einreichung auf einen aktualisierten Termin oder eine geänderte Regel geprüft?

Wenn die Projektgeschichte nicht belegbar ist, geben Sie die Einreichung nicht auf Basis einer Annahme frei. Klären Sie den Status anhand archivierter Releases und des tatsächlichen Uploads. Für neue Projekte ist es meist einfacher, ODR gar nicht erst als neue Abhängigkeit einzuführen, als eine vermeidbare Migration später in einen kritischen Release zu legen.

Häufige Fragen zur ODR-Migration

Ab wann können bestimmte Apps keine On-Demand Resources mehr hochladen?

Apple nennt Anfang 2027 als Beginn der Uploadbeschränkung, aber keinen konkreten Kalendertag. Betroffen sind neue Apps und Apps, die ODR zuvor nicht verwendet haben, wenn ihr Upload ODR-Inhalte enthält. Prüfen Sie die verlinkte Apple-Mitteilung vor Ihrer Einreichung erneut. Tragen Sie keinen selbst angenommenen Stichtag als offizielles Veröffentlichungsdatum in den Releaseplan ein.

Muss eine veröffentlichte App mit On-Demand Resources sofort migriert werden?

Nein. Apple unterscheidet die Uploadbeschränkung von der Abkündigung der Technologie und erklärt, dass bereits ODR nutzende Apps kurzfristig weiterlaufen können. Das ist keine Zusage für unbegrenzte Unterstützung. Erfassen Sie vorhandene Tags, Downloads und Fehlerszenarien, planen Sie eine Migration und testen Sie sie mit den tatsächlichen Releasewegen Ihrer App.

Können Background Assets NSBundleResourceRequest direkt ersetzen?

Nein, eine Eins-zu-eins-Ersetzung ist nicht vorauszusetzen. ODR-Tags und NSBundleResourceRequest bilden ein anderes Ressourcenmodell als Asset Packs und deren Downloadstrategien. Legen Sie zuerst fest, wann und wie lange jede Ressource verfügbar sein muss. Übertragen Sie diese Anforderungen anschließend auf die Pack-Struktur und die passende Managed- oder selbst gehostete Bereitstellung.

Wie testen Sie Background-Assets-Asset-Packs lokal mit Xcode?

Erstellen Sie die Asset Packs nach der vorgesehenen Apple-Anleitung und verwenden Sie den mit Xcode bereitgestellten lokalen Mock-Server. Prüfen Sie Download, Verfügbarkeitsstatus und Fehlerverhalten. Ein erfolgreicher lokaler Test bestätigt nicht die App-Store-Freigabe. Führen Sie zusätzlich den Upload- und Verteilungsprozess aus, den Ihr Projekt für den späteren Release verwendet.

Nächster Schritt: Testumgebung passend zum Releasebedarf wählen

Wenn ODR bereits tief in Oberfläche, Spielablauf oder Downloadfehlerbehandlung eingebunden ist, behandeln Sie Background Assets als Architekturmigration und nicht als reinen Build-Fix. Ein bestehender Mac kann dafür genügen, wenn er für Xcode-Tests und Releaseprüfungen zuverlässig verfügbar ist. Ein geteilter oder stark ausgelasteter Rechner kann dagegen Engpässe verursachen: Builds warten auf freie Zeit, Testumgebungen konkurrieren miteinander und Releaseprüfungen hängen an einem einzelnen Gerät.

Für kurze Migrationsarbeiten oder wiederholbare CI-Prüfungen kann ein gemieteter Mac eine Alternative zum sofortigen Hardwarekauf sein. Er ersetzt keine sorgfältige Prüfung von Datenschutz, Zugriffskontrolle und Datenstandort; Teams sollten diese Anforderungen vorab klären. Wenn Sie dafür eine separate macOS-Umgebung benötigen, können Sie die Remote-Mac-Umgebung von metalvnc prüfen, sich im Hilfebereich über den Zugriff informieren und die Mietoptionen mit der geplanten Testdauer vergleichen. Für dauerhaft hohe Last oder benötigte physische Schnittstellen kann ein eigener Mac die passendere Lösung sein.

Häufig gestellte Fragen