Apple-richtlijn 4.2: Zal ​​Apple een website-app afwijzen? Hoe u een beoordeling kunt doorstaan

Apple kan een website-gebaseerde app afwijzen en "minimale functionaliteit" is de meest voorkomende reden. Richtlijn 4.2 is de regel erachter. Een website-app wordt niet automatisch geweigerd, maar een app die verder niets toevoegt dan een website in een frame loopt wel een reëel risico.

In deze handleiding wordt uitgelegd wat de richtlijn zegt, waar reviewers vaak op letten en hoe u een inzending kunt voorbereiden. Niemand buiten Apple kan goedkeuring beloven, en dit artikel doet dat ook niet. Wat u kunt doen, is de vermijdbare redenen voor afwijzing wegnemen.

Wat Richtlijn 4.2 eigenlijk zegt

In de app-beoordelingsrichtlijnen staat onder 4.2, Minimale functionaliteit:

Uw app moet functies, inhoud en gebruikersinterface bevatten die deze verder tillen dan een opnieuw verpakte website. Als uw app niet bijzonder nuttig, uniek of 'app-achtig' is, hoort deze niet thuis in de App Store.

De woorden die er toe doen zijn 'herverpakte website'. De regel verbiedt geen apps die rond webinhoud zijn gebouwd. Het verbiedt apps die niets bieden wat een website niet al biedt.

Gerelateerde richtlijnen komen ook naar voren in website-app-recensies:

• 4.2.2: Behalve catalogi mogen apps niet in de eerste plaats bestaan ​​uit marketingmateriaal, advertenties, webknipsels, contentaggregators of een verzameling links.
• 4.2.3: De app zou op zichzelf moeten werken zonder dat er een andere app geïnstalleerd hoeft te worden, en elke grote download die nodig is bij de eerste lancering moet worden bekendgemaakt en gevraagd.
• 2.1 (volledigheid van de app): Inzendingen moeten definitieve versies zijn met werkende URL's, zonder tijdelijke inhoud en demo-accountgegevens als de app een login heeft.
• 4.2.6: Apps die zijn gemaakt op basis van een gecommercialiseerde sjabloon of service voor het genereren van apps, worden afgewezen, tenzij ze rechtstreeks worden ingediend door de aanbieder van de app-inhoud.

Lees altijd zelf de actuele tekst, Apple werkt de richtlijnen bij. De officiële bron is de App Store-beoordelingsrichtlijnen.

Zal Apple een website-app afwijzen?

Het hangt af van wat de ingediende app doet. In de praktijk reageren reviewers op een aantal patronen:

• De app opent één URL en ziet er identiek uit als de mobiele website, inclusief navigatie in webstijl.
• Het toont alleen een inlogmuur zonder doorzoekbare inhoud, zodat de recensent niet kan zien wat de app doet.
• Het verbreekt of vertoont fouten zonder verbinding.
• De links springen voortdurend naar de browser.
• Het lijkt op een marketingbrochure voor een bedrijf zonder eigen functie.

Een app die een echte dienst omvat, zoals een winkel, een boekingssysteem, een ledengedeelte of een inhoudsbibliotheek, en deze presenteert met app-achtige navigatie, bevindt zich in een andere positie. Je kunt nog steeds worden afgewezen, aangezien beoordeling een oordeel is, maar je hebt wel iets om op te wijzen.

Waarom een ​​door een service gegenereerde app uw eigen account nodig heeft

Richtlijn 4.2.6 zegt dat apps die zijn gemaakt met een app-generatieservice worden afgewezen, tenzij ze rechtstreeks worden ingediend door de aanbieder van de app-inhoud. Voor een website-eigenaar is de praktische les deze: publiceer onder uw eigen Apple Developer-account, in uw eigen naam of die van uw bedrijf, en zorg ervoor dat de app uw eigen inhoud vertegenwoordigt.

Dit is ook hoe SiteTo.App werkt. Builds worden ondertekend met het Apple Developer-account waarmee u verbinding maakt, en de build wordt afgeleverd bij TestFlight in uw App Store Connect-account. U bent eigenaar van de vermelding en u dient deze in. Zie de Gids voor Apple Developer-accounts voor de opstelling. Geef uw inhoud niet aan een leverancier die voor veel klanten dezelfde shell onder zijn eigen account indient.

Wat zorgt ervoor dat een website-app aanvoelt als een app?

Het doel is niet om functies toe te voegen omwille van het feit. Het is bedoeld om mobiel gebruik beter te maken. Sterke, eerlijke toevoegingen zijn onder meer:

• Native navigatie. Een tabbladbalk of menu dat overeenkomt met hoe mensen zich op een telefoon door uw site verplaatsen, in plaats van een desktopkoptekst die in een klein scherm is geperst.
• Pushmeldingen. Berichten waarvoor gebruikers zich aanmelden, zoals orderupdates, boekingsherinneringen of nieuwe inhoud. In SiteTo.App worden deze ingesteld via Firebase; zie de Firebase-gids.
• Diepe links. Links vanuit meldingen of e-mail die het rechterscherm in de app openen.
• Een ontworpen lanceringservaring. Een pictogram, een opstartscherm en een duidelijke laad- en foutstatus.
• Inheemse overdrachten. Delen, bestandsuploads, cameratoegang of downloads die correct werken op het apparaat.

Voeg geen gimmick toe, zoals een zaklampschakelaar. Het gaat niet in op richtlijn 4.2, en reviewers prikken er doorheen.

Een checklist vóór indiening

Werk dit door voordat u uploadt:

1. Test de hele reis op een echte iPhone. Installeer via TestFlight, niet alleen een simulator. Open de app koud, doorloop het inloggen, navigeer verschillende niveaus diep en gebruik het teruggebaar.
2. Test zonder verbinding. Schakel de vliegtuigmodus in en open de app. U zou een duidelijke boodschap moeten zien, geen blanco pagina.
3. Controleer elke externe link. Bepaal met opzet welke links in de app blijven en welke de browser openen.
4. Problemen met de lay-out van de website oplossen. Responsproblemen, kleine tikdoelen en pop-ups die alleen op het bureaublad verschijnen, zijn duidelijk zichtbaar in een app.
5. Verwijder tijdelijke inhoud. Richtlijn 2.1 verwacht een eindproduct met werkende ondersteuning en privacy-URL's.
6. Geef demogegevens op. Als inloggen vereist is, voeg dan een account toe dat tijdens de beoordeling blijft werken.
7. Zorg ervoor dat privacyantwoorden accuraat zijn. Ze moeten de hele ervaring beschrijven, inclusief webanalyses en betalingshulpmiddelen die in de app zijn geladen.
8. Schrijf eerlijke screenshots en een beschrijving. Laat de echte app zien en claim geen functies die deze niet heeft.
9. Gebruik beoordelingsnotities. Leg uit wat de app doet, waar de native functies zich bevinden en welke regio- of accountvereisten er zijn.

U kunt uw site aan de hand van veel hiervan controleren met de gereedheidscontrolelijst, en onze publicatiegids bedekt de omliggende winkeltrappen.

Hoe u beoordelingsnotities kunt schrijven die helpen

Recensenten zien veel inzendingen. Een korte, specifieke opmerking helpt hen snel de waarde te vinden. Omslag:

• Waar de app voor is, in één of twee zinnen.
• Hoe u zich kunt aanmelden, met werkende demogegevens.
• Waar u de native functies kunt vinden, bijvoorbeeld 'Meldingen kunnen worden ingeschakeld via het accounttabblad'.
• Alles wat ongebruikelijk is, zoals een functie waarvoor een bepaalde regio of hardware nodig is.

Houd het feitelijk. Vermijd discussies over de richtlijnen in de eerste indiening. Bewaar dat voor een antwoord als je wordt afgewezen.

Als Apple de app afwijst

Een afwijzing is een gesprek, geen definitief oordeel. Apple legt de richtlijn uit die het heeft toegepast in het Resolutiecentrum.

1. Lees het bericht aandachtig. Noteer het richtlijnnummer en eventueel genoemde specifieke schermen of gedragingen.
2. Los het werkelijke probleem op. Als de reden minimale functionaliteit is, verbeter dan wat de app doet in plaats van de beschrijving opnieuw te formuleren.
3. Reageer nauwkeurig. Beschrijf wat er is gewijzigd en waar de recensent dit kan zien.
4. Dien indien nodig een nieuwe build in. Een wijziging in het binaire bestand vereist een nieuwe upload.
5. Alleen in beroep gaan met een zaak. Als u denkt dat de afwijzing een vergissing is, gebruik dan de App Review-bezwaarprocedure en vermeld de feiten.

Omdat een website-gebaseerde app uw site laadt, gebeuren veel oplossingen op de website zelf en verschijnen ze in de app zonder een nieuwe winkelrelease. Native configuratiewijzigingen hebben nog steeds een nieuwe build nodig.

Veelgestelde vragen

Moet een website-app offline werken?

Niet in de regel, maar het zou gracieus moeten mislukken. Een leeg scherm zonder verbinding ziet er onvoltooid uit, en dat heeft invloed op hoe recensenten de app zien.

Wordt een PWA anders behandeld dan andere websites?

Een PWA in een iOS-app is nog steeds webinhoud in een native shell, dus dezelfde richtlijn is van toepassing. Zien hoe u een PWA publiceert in de App Store en Google Play.

Kan ik dezelfde app voor meerdere merken indienen?

Richtlijn 4.2.6 beperkt apps die zijn gemaakt op basis van een sjabloon- of generatieservice en namens klanten worden ingediend. Elk bedrijf moet onder zijn eigen account publiceren.

Moet ik betalen voor een converter om goedgekeurd te worden?

Geen enkel instrument bepaalt de uitkomst. Apple beoordeelt de ingediende app. Betalen voor een build verandert daar niets aan, dus de prijs staat los van de goedkeuring. Zien prijzen.

Volgende stappen

Begin met het testen van uw site als app. Bekijk een voorbeeld van uw website in SiteTo.App, probeer het op je telefoon en merk op wat aanvoelt als een website in plaats van als een app. Corrigeer deze punten en volg vervolgens de handleiding maken en publiceren.