App-Store-Ablehnung
Eine 2.5.4-Ablehnung bedeutet, dass deine App einen Background Mode wie Audio oder Location updates deklariert und der Reviewer keine Funktion gefunden hat, die ihn braucht. Entweder entfernst du den Mode, oder du sorgst dafür, dass die Funktion funktioniert und leicht zu testen ist. Bei Web-Wrapper-Apps dauert die Lösung meist zehn Minuten in Xcode, plus einen Bugfix in deinem Audioplayer.
Ab $109 einmalig pro Plattform, oder unser Team erledigt alles ab $698.
Guideline 2.5.4 erlaubt Multitasking-Apps, Hintergrunddienste nur für ihren vorgesehenen Zweck zu nutzen: VoIP, Audiowiedergabe, Standort, Abschluss von Aufgaben, lokale Benachrichtigungen und Ähnliches. Apple vergleicht den Eintrag UIBackgroundModes in deiner Info.plist (in Xcode: die Capability Background Modes unter Signing & Capabilities) mit dem, was die App tut. Ein deklarierter, aber ungenutzter Mode führt zur Ablehnung. Ein Mode, der für etwas anderes genutzt wird, etwa für stilles Audio, das die App am Leben hält, ist noch schlimmer.
Die benachbarte Regel 2.5.1 behandelt Berechtigungen und Zwecktexte; darum kümmert sich unser Guide zu ungenutzten Berechtigungen. Auf dieser Seite geht es um die Background Modes selbst.
Die Formulierung ist konkret: Die App deklariert in UIBackgroundModes die Unterstützung für einen Mode (audio, location, voip, fetch oder processing), aber der Reviewer hat keine Funktion gefunden, die ihn erfordert, oder konnte die Funktion nicht dazu bringen, im Hintergrund weiterzulaufen. Du sollst entweder die Funktion ergänzen oder den Key entfernen. Beim Standort ergänzt die Nachricht oft, dass die App klar machen muss, warum sie den Standort braucht, während sie nicht in Gebrauch ist.
| Background Mode (Bezeichnung in Xcode) | Legitime Nutzung in einer WebViewGold-App | Was der Reviewer prüft | Entfernen, wenn |
|---|---|---|---|
| Audio, AirPlay, and Picture in Picture | Podcast, Radio, Musik, Hörbuch oder Meditationsaudio über die HTML Background Audio API; Bild-in-Bild-Video über startnativevideo:// | Startet die Wiedergabe, verlässt die App, sperrt das Handy, hört zu | Die App hat nur kurze Sounds, eingebettete YouTube-Videos oder gar kein Audio |
| Location updates | Lauf- oder Radtracking, Tracking von Lieferfahrern, Check-ins an Einsatzorten, mit backgroundlocation auf true | Sucht eine Funktion, die den Standort bei geschlossener App braucht, und liest den Zwecktext | Du brauchst den Standort nur bei geöffneter App ("in meiner Nähe", Filialfinder) |
| Remote notifications | Push über OneSignal, Firebase oder Pushwoosh | Dass es Push gibt | Du nutzt überhaupt keinen Push |
| Background fetch, Background processing | Selten nötig; die Doku erwähnt Background Processing nur für manche Setups mit Standort im Hintergrund | Welche Aufgabe im Hintergrund läuft | Keine Funktion plant Arbeit im Hintergrund |
| Voice over IP | Native Telefonie-Apps auf Basis von CallKit, keine Web-Apps mit WebRTC-Anrufen | Ob Anrufe bei geschlossener App ankommen | Fast immer, bei einer Web-Wrapper-App |
Großartige Möglichkeit, eine Web-App in eine native App zu verwandeln! Schnelle Umsetzung und ein toller Weg, Apps in die App Stores zu bringen, ohne eine komplett native App entwickeln zu müssen!
Mach das zuerst in Xcode; die meisten 2.5.4-Ablehnungen sind damit schon erledigt.
Wähle das WebViewGold-Target, suche die Capability Background Modes und notiere jedes angehakte Kästchen. Öffne dann die Info.plist und sieh dir "Required background modes" (UIBackgroundModes) an; dort sollten dieselben Einträge stehen.
Audio braucht einen Player, der bei gesperrtem Handy weiterspielt. Location updates braucht backgroundlocation und eine Funktion, die den Standort nutzt. Remote notifications braucht einen Push-Anbieter. Alles ohne Funktion fliegt raus.
Nimm die Häkchen heraus oder lösche die Capability, wenn nichts übrig bleibt. Push- und Standort-Tutorials hinterlassen manchmal zusätzliche Häkchen; das ist die häufigste Ursache einer unerklärlichen 2.5.4-Ablehnung.
Ohne Location updates löschst du auch die Usage Description für "Always" und behältst nur "When In Use", wenn deine Web-App die Geolocation-API noch aufruft. Die Tracking Usage Description behältst du in jedem Fall; die WebViewGold-Doku kennzeichnet sie als Pflicht.
Capabilities stecken in der Binary, das braucht also immer einen neuen Upload. Liste die entfernten Modes in deiner Antwort im Resolution Center auf.
Eine Audio-App ist einer der stärksten Fälle für eine Web-Wrapper-App: Die Inhalte liegen auf deinem Server, und die native Hülle ergänzt die Wiedergabe im Hintergrund. Die HTML Background Audio API (mit kurzem Einrichtungsvideo in der Doku) lässt HTML-Audio weiterspielen, wenn Nutzer die App wechseln oder den Bildschirm sperren. Genau das testet der Reviewer, also muss der Player in deiner Web-App mitspielen.
Drei Bugs in der Web-App verursachen die meisten Audio-Ablehnungen: Der Player pausiert sich bei visibilitychange oder pagehide selbst; eine Single-Page-App entfernt die Player-Komponente bei jedem Routenwechsel, sodass Navigieren den Ton stoppt; oder die Wiedergabe hängt von Autoplay statt von einem Tippen ab. Behebe sie in der Web-App (Code unten) und teste auf einem echten Gerät, mit einer vollen Minute gesperrtem Bildschirm.
Die HTML Background Audio API ist für iOS dokumentiert. Für Video spielt die Native Video API einen Stream im Systemplayer mit Bild-in-Bild ab, was ebenfalls den Mode Audio, AirPlay, and Picture in Picture voraussetzt. Auch das Android-Projekt hat einen nativen Videoplayer mit Bild-in-Bild.
Typische Korrekturen für einen Player in React, Vue oder reinem JavaScript. Halte für die ganze Session ein einziges Audio-Element am Leben.
// 1) Entferne automatisches Pausieren wie dieses aus deiner Player-Komponente:
// document.addEventListener("visibilitychange", () => { if (document.hidden) audio.pause(); });
// 2) Halte EIN Audio-Element außerhalb deiner Routen (z. B. im Root-Layout)
const audio = document.getElementById("global-player"); // <audio id="global-player" preload="none">
// 3) Starte die Wiedergabe per Tippen, nie per Autoplay
playButton.addEventListener("click", () => {
audio.src = episode.url; // direkte MP3-, AAC- oder HLS-URL
audio.play();
});
// 4) Optional: Metadaten für den Sperrbildschirm (im eigenen Build testen; die Unterstützung hängt von der iOS-Version ab)
if ("mediaSession" in navigator) {
navigator.mediaSession.metadata = new MediaMetadata({
title: episode.title,
artist: show.name,
artwork: [{ src: show.cover, sizes: "512x512", type: "image/png" }]
});
}Standort im Hintergrund geht durch, wenn Nutzer klar davon profitieren, während die App geschlossen ist: einen Lauf aufzeichnen, die Position eines Fahrers mit wartenden Kunden teilen, einchecken, wenn ein Techniker am Einsatzort ankommt. In WebViewGold setzt du backgroundlocation in Config.swift auf true und fügst unter Background Modes Location updates hinzu. Je nach Web-App brauchst du außerdem Background Processing, mit deiner Bundle ID unter "Permitted background task scheduler identifiers" in der Info.plist. Die Geolocation-Doku weist darauf hin, dass das im Review eine klare Begründung braucht.
Reviewer können während des Reviews nicht joggen gehen, also mach die Funktion sichtbar: ein ausdrücklicher Button "Tracking starten", eine Anzeige, solange das Tracking läuft, ein Stopp-Button und eine kurze Bildschirmaufnahme in den Review-Notizen, die zeigt, wie Punkte ankommen, während die App im Hintergrund ist. Erkläre in deiner eigenen Oberfläche, bevor der Systemdialog erscheint, warum die App den Standort bei geschlossener App braucht, und verwende dieselben Worte im Zwecktext. Teste es selbst auf einem echten Gerät und prüfe auf deinem Server, dass die Punkte ankommen.
Wenn du nur eine "In meiner Nähe"-Suche brauchst, verzichte ganz auf den Standort im Hintergrund; die Berechtigung "Beim Verwenden der App" deckt das ab. Die Feature-Seite zur Geolocation zeigt das Setup im Vordergrund.
Entweder hast du den Mode entfernt, oder du erklärst, wie man ihn testet. Mische beides nicht für denselben Mode. Die Vorlage bleibt auf Englisch, weil App Review Englisch liest.
Hello App Review team, Thank you for reviewing [App name] [version] ([build]). [Option A: mode removed] We removed the [audio / location / fetch / processing / voip] background mode. It was declared by mistake and no feature depends on it. The new build [number] declares only: [remaining modes, e.g. remote-notification for push notifications]. [Option B: mode in use] The app uses the [audio] background mode for [continuous podcast playback]. To test: 1. Log in with the demo account from App Review Information. 2. Open [Library] and tap Play on any episode. 3. Lock the device or switch to another app. Playback continues. [Location: 1. Tap Start tracking on the [Track] tab. 2. Put the app in the background. 3. The route keeps recording. A screen recording is attached to the review notes.] Best regards, [Name], [email], [phone]
UIBackgroundModes in der Info.plist stimmt mit der Capability überein, ohne Überbleibsel.backgroundlocation auf true, einer Start- und Stopp-Steuerung und einem Zwecktext, der die Funktion nennt.Benachrichtigungen stellt iOS zu, egal ob deine App läuft oder nicht. Der Mode Remote notifications erlaubt es, die App im Hintergrund aufzuwecken, und Push-Anbieter wie OneSignal bitten dich, ihn bei der Einrichtung zu aktivieren. Behalte ihn, wenn Push aktiv ist; entferne ihn, wenn du keinen Push nutzt.
Nur wenn das Video oder sein Ton weiterlaufen soll, während die App im Hintergrund ist, oder wenn du Bild-in-Bild nutzt. Ein Video, das stoppt, wenn der Nutzer die App verlässt, braucht keinen Background Mode.
Nein. Den Audio-Mode für etwas anderes als hörbare Wiedergabe zu nutzen ist genau das, was 2.5.4 verbietet, und Reviewer werten es als Missbrauch. Hol Nutzer stattdessen mit Push-Benachrichtigungen zurück.
Nicht als Review-Richtlinie, aber Android hat eigene Hürden: Standort im Hintergrund braucht eine separate Berechtigung und eine Erklärung in der Play Console, und Foreground Services müssen ihren Typ deklarieren. Das Prinzip ist dasselbe: Deklariere nur, was eine sichtbare Funktion braucht.
Nur die Funktion, die davon abhing. Hat keine Funktion den Mode genutzt, merkt es niemand. Ergänzt du später Background Audio oder Tracking, füge den Mode in diesem Update wieder hinzu und beschreibe ihn in den Review-Notizen.
Gleiches Ergebnis, unterschiedlich viel Arbeit auf deiner Seite. Alle drei kommen mit Genehmigungsgarantie und 24/7 Support von echten Menschen.
$109 pro Plattform, einmalig
Die WebViewGold-Lizenz: ein fertiges Xcode- oder Android-Studio-Projekt. URL einfügen, Name und Icon setzen, Features einschalten, bauen und einreichen. Kostenlose Updates für immer.
Pakete auf der Hauptseite ansehen$349 pro Lizenz, einmaliges Add-on
Kein Mac, kein Xcode, kein Android Studio: Du konfigurierst im Browser, wir bauen beide Apps in der Cloud und übergeben sie an App Store Connect und die Play Console.
So funktioniert der Cloud Builder Kostenlose Demo ausprobieren$698 pro Plattform $798
Schick uns deine URL und dein Icon. Unser Team konfiguriert, baut und liefert deine App innerhalb von 72 Stunden, White-Label, inklusive Quellprojekten. Beide Plattformen für $1,158.
Full-Service-Details Powered by
Winter-Sale-Preise gültig bis 31. Dezember 2026.
App Store & Google Play Genehmigungsgarantie – oder Geld zurück innerhalb von 14 Tagen
Lieber abgeben? Full Service: Wir konfigurieren, bauen und liefern innerhalb von 72 Stunden, ab $698 pro Plattform. Fragen? Chatte mit uns – 24/7.
Erstattungen erfolgen zu den in unseren FAQ genannten Bedingungen: eine nicht inhaltsbedingte Ablehnung durch Apple und/oder Google, geltend gemacht innerhalb von 14 Tagen nach dem Kauf.