Refus App Store
Un refus 2.5.4 signifie que votre app déclare un mode d'arrière-plan, comme Audio ou Location updates, et que l'examinateur n'a trouvé aucune fonctionnalité qui en a besoin. Soit vous retirez le mode, soit vous faites fonctionner la fonctionnalité et la rendez facile à tester. Pour une app web encapsulée, la correction prend généralement dix minutes dans Xcode, plus un bug à corriger dans votre lecteur audio.
Dès $109 en paiement unique par plateforme, ou notre équipe s'occupe de tout dès $698.
La guideline 2.5.4 autorise les apps multitâches à utiliser les services d'arrière-plan uniquement pour leur usage prévu : VoIP, lecture audio, localisation, achèvement de tâches, notifications locales, etc. Apple compare l'entrée UIBackgroundModes de votre Info.plist (dans Xcode : la capacité Background Modes sous Signing & Capabilities) avec ce que fait l'app. Un mode déclaré mais inutilisé entraîne un refus. Un mode détourné, par exemple pour lire un son silencieux afin de garder l'app active, est encore pire.
La règle voisine 2.5.1 couvre les autorisations et les descriptions d'usage ; notre guide des autorisations inutilisées s'en charge. Cette page porte sur les modes d'arrière-plan eux-mêmes.
La formulation est précise : l'app déclare la prise en charge d'un mode (audio, location, voip, fetch ou processing) dans UIBackgroundModes, mais l'examinateur n'a trouvé aucune fonctionnalité qui l'exige, ou n'a pas réussi à faire fonctionner la fonctionnalité pendant que l'app était en arrière-plan. On vous demande soit d'ajouter la fonctionnalité, soit de retirer la clé. Pour la localisation, la note ajoute souvent que l'app doit expliquer clairement pourquoi elle a besoin de la position quand elle n'est pas utilisée.
| Mode d'arrière-plan (libellé Xcode) | Usage légitime dans une app WebViewGold | Ce que vérifie l'examinateur | Retirez-le si |
|---|---|---|---|
| Audio, AirPlay, and Picture in Picture | Audio de podcast, radio, musique, livre audio ou méditation via la HTML Background Audio API ; vidéo en Picture in Picture via startnativevideo:// | Il lance la lecture, quitte l'app, verrouille le téléphone et écoute | L'app n'a que des sons courts, des vidéos YouTube intégrées ou pas d'audio du tout |
| Location updates | Suivi de course à pied ou de sortie à vélo, suivi de livreurs, pointage sur des chantiers, avec backgroundlocation réglé sur true | Il cherche une fonctionnalité qui a besoin de la position quand l'app est fermée et lit la description d'usage | Vous n'avez besoin de la position que lorsque l'app est ouverte (« près de moi », localisateur de magasins) |
| Remote notifications | Push via OneSignal, Firebase ou Pushwoosh | Que le push existe bien | Vous n'utilisez pas du tout le push |
| Background fetch, Background processing | Rarement nécessaire ; la documentation ne mentionne Background Processing que pour certaines configurations de localisation en arrière-plan | Quelle tâche tourne en arrière-plan | Aucune fonctionnalité ne planifie de travail en arrière-plan |
| Voice over IP | Les apps d'appel natives construites sur CallKit, pas les apps web avec des appels WebRTC | Si les appels arrivent quand l'app est fermée | Presque toujours, dans une app web encapsulée |
Excellente façon de convertir son app web en app native ! Un délai très court, et un super moyen de mettre ses apps dans les stores sans devoir développer une app native complète !
Commencez par Xcode ; la plupart des refus 2.5.4 s'arrêtent là.
Sélectionnez la cible WebViewGold, trouvez la capacité Background Modes et notez chaque case cochée. Ouvrez ensuite Info.plist et regardez « Required background modes » (UIBackgroundModes) : la liste doit contenir les mêmes éléments.
Audio exige un lecteur qui continue de jouer quand le téléphone est verrouillé. Location updates exige backgroundlocation et une fonctionnalité qui l'utilise. Remote notifications exige un fournisseur de push. Tout ce qui ne correspond à aucune fonctionnalité disparaît.
Décochez les cases, ou supprimez la capacité s'il ne reste rien. Les tutoriels sur le push et la localisation laissent parfois des cases cochées en trop : c'est la cause la plus fréquente d'un refus 2.5.4 inexpliqué.
Sans Location updates, supprimez aussi la description d'usage de la localisation « Always » et ne gardez que « When In Use » si votre app web appelle encore l'API de géolocalisation. Gardez dans tous les cas la description d'usage du suivi ; la documentation WebViewGold l'indique comme obligatoire.
Les capacités font partie du binaire : il faut donc toujours un nouvel envoi. Listez les modes retirés dans votre réponse dans le Resolution Center.
Une app audio est l'un des meilleurs cas d'usage pour une app web encapsulée : le contenu vit sur votre serveur et la coque native ajoute la lecture en arrière-plan. La HTML Background Audio API (une courte vidéo de configuration figure dans la documentation) maintient la lecture de l'audio HTML quand l'utilisateur change d'app ou verrouille l'écran. C'est exactement ce que teste l'examinateur : le lecteur de votre app web doit donc jouer le jeu.
Trois bugs d'app web causent la plupart des refus liés à l'audio : le lecteur se met lui-même en pause sur visibilitychange ou pagehide ; une single-page app démonte le composant du lecteur lors des changements de route, si bien que naviguer coupe le son ; ou la lecture dépend de l'autoplay au lieu d'un toucher. Corrigez-les dans l'app web (code ci-dessous) et testez sur un vrai appareil, écran verrouillé pendant une minute entière.
La HTML Background Audio API est documentée pour iOS. Pour la vidéo, la Native Video API lit un flux dans le lecteur système avec Picture in Picture, qui repose lui aussi sur le mode Audio, AirPlay, and Picture in Picture. Le projet Android dispose également d'un lecteur vidéo natif avec Picture in Picture.
Les corrections typiques pour un lecteur React, Vue ou JavaScript pur. Gardez un seul élément audio actif pendant toute la session.
// 1) Supprimez de votre composant de lecteur les mises en pause automatiques comme celle-ci :
// document.addEventListener("visibilitychange", () => { if (document.hidden) audio.pause(); });
// 2) Gardez UN SEUL élément audio en dehors de vos routes (par ex. dans le layout racine)
const audio = document.getElementById("global-player"); // <audio id="global-player" preload="none">
// 3) Lancez la lecture sur un toucher de l'utilisateur, jamais en autoplay
playButton.addEventListener("click", () => {
audio.src = episode.url; // URL MP3, AAC ou HLS directe
audio.play();
});
// 4) Facultatif : métadonnées sur l'écran verrouillé (testez sur votre build ; la prise en charge dépend de la version d'iOS)
if ("mediaSession" in navigator) {
navigator.mediaSession.metadata = new MediaMetadata({
title: episode.title,
artist: show.name,
artwork: [{ src: show.cover, sizes: "512x512", type: "image/png" }]
});
}La localisation en arrière-plan passe quand les utilisateurs en tirent un bénéfice évident pendant que l'app est fermée : enregistrer une course, partager la position d'un livreur avec les clients qui l'attendent, pointer quand un technicien arrive sur un site. Dans WebViewGold, vous réglez backgroundlocation sur true dans Config.swift et ajoutez Location updates sous Background Modes. Selon votre app web, il vous faudra peut-être aussi Background Processing, avec votre bundle ID sous « Permitted background task scheduler identifiers » dans Info.plist. La documentation de géolocalisation rappelle que cela exige une justification claire lors de l'examen.
Les examinateurs ne peuvent pas partir courir pendant l'examen : rendez donc la fonctionnalité visible. Un bouton « Démarrer le suivi » explicite, un indicateur pendant le suivi, un bouton d'arrêt, et un court enregistrement d'écran dans les notes pour l'examen qui montre les points arriver pendant que l'app est en arrière-plan. Expliquez dans votre propre interface, avant l'apparition de la boîte de dialogue système, pourquoi l'app a besoin de la position quand elle est fermée, et reprenez les mêmes mots dans la description d'usage. Testez vous-même sur un vrai appareil et vérifiez sur votre serveur que les points arrivent bien.
Si une recherche « près de moi » est tout ce dont vous avez besoin, renoncez complètement à la localisation en arrière-plan ; l'autorisation When In Use suffit. La page de la fonctionnalité de géolocalisation montre la configuration au premier plan.
Soit vous avez retiré le mode, soit vous expliquez comment le tester. Ne mélangez pas les deux pour un même mode. Le modèle reste en anglais, la langue de travail des examinateurs.
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 dans Info.plist correspond à la capacité, sans restes.backgroundlocation réglé sur true, un bouton de démarrage et d'arrêt et une description d'usage qui nomme la fonctionnalité.Les notifications sont délivrées par iOS, que votre app tourne ou non. Le mode Remote notifications permet de réveiller l'app en arrière-plan, et les fournisseurs de push comme OneSignal vous demandent de l'activer lors de la configuration. Gardez-le si le push est activé ; retirez-le si vous n'utilisez pas le push.
Seulement si la vidéo ou son son doit continuer pendant que l'app est en arrière-plan, ou si vous utilisez Picture in Picture. Une vidéo qui s'arrête quand l'utilisateur quitte l'app n'a besoin d'aucun mode d'arrière-plan.
Non. Utiliser le mode audio pour autre chose qu'une lecture audible est précisément ce qu'interdit la 2.5.4, et les examinateurs le traitent comme un abus. Servez-vous plutôt des notifications push pour faire revenir les utilisateurs.
Pas sous forme de règle d'examen, mais Android a ses propres obstacles : la localisation en arrière-plan exige une autorisation distincte et une déclaration dans la Play Console, et les services de premier plan doivent déclarer leur type. Le principe est le même : ne déclarez que ce dont une fonctionnalité visible a besoin.
Seulement la fonctionnalité qui en dépendait. Si aucune fonctionnalité n'utilisait le mode, personne ne remarque rien. Si vous ajoutez plus tard l'audio en arrière-plan ou le suivi de position, rajoutez le mode dans cette mise à jour et décrivez-le dans les notes pour l'examen.
Même résultat, charge de travail différente de votre côté. Les trois formules incluent la garantie d'approbation et le support humain 24/7.
$109 par plateforme, paiement unique
La licence WebViewGold : un projet Xcode ou Android Studio prêt à l'emploi. Collez votre URL, définissez le nom et l'icône, activez les fonctionnalités, compilez et soumettez. Mises à jour gratuites à vie.
Voir les offres sur la page principale$349 par licence, extension en paiement unique
Ni Mac, ni Xcode, ni Android Studio : configurez dans le navigateur, nous compilons les deux apps dans le cloud et les transmettons à App Store Connect et à la Play Console.
Comment fonctionne le Cloud Builder Essayer la démo gratuite$698 par plateforme $798
Envoyez-nous votre URL et votre icône. Notre équipe configure, compile et livre votre app sous 72 heures, en marque blanche, projets sources inclus. Les deux plateformes pour $1,158.
Détails du Full Service Propulsé par
Prix Soldes d'hiver valables jusqu'au 31 décembre 2026.
Garantie d'approbation App Store & Google Play – ou remboursement sous 14 jours
Vous préférez déléguer ? Full Service : nous configurons, compilons et livrons sous 72 heures, dès $698 par plateforme. Des questions ? Chattez avec nous 24/7.
Les remboursements sont accordés aux conditions indiquées dans notre FAQ : un refus non lié au contenu par Apple et/ou Google, demandé dans les 14 jours suivant l'achat.