Guideline 4.2 Minimum Functionality: app afvist af Apple

Guideline 4.2, "Minimum Functionality", afviser en app, der ikke giver mere end en hjemmeside, eller som giver for lidt til, at man beholder den. Løsningen er ikke at stable native funktioner oven på hinanden: Det er at sætte én i centrum af brugen og så fortælle revieweren, hvor den er. Rettelsen kræver næsten altid et nyt build.

Jeg udgiver mine egne iOS-apps: Solys, TradaZen og Nolera ligger på App Store. Guiden bygger på Apples officielle tekst, læst den 15. oktober 2026, og på 4.2-afvisninger, som udviklere har delt på Apples forum. De afviste apps længere nede er eksempler. Vil du have overblikket over alle afvisningsgrunde, så læs hellere hvorfor Apple afviser en app.

Hvad siger guideline 4.2?

4.2 står i afsnit 4, "Design", i App Review Guidelines. Første sætning fastlægger kriteriet: "Your app should include features, content, and UI that elevate it beyond a repackaged website." Med andre ord skal din app have funktioner, indhold og en brugerflade, der løfter den over en hjemmeside, der bare er pakket ind i en æske.

Teksten tilføjer to ting. En app, der ikke er rigtig nyttig, unik eller "app-like", hører ikke hjemme på App Store. Og en app, der hverken giver varig underholdning eller tilstrækkelig nytte, kan blive afvist. 4.2 bedømmer altså to ting: forskellen fra nettet og mængden af værdi.

De underregler, beskeden kan henvise til

Underregel	Hvad Apple kræver	Den typiske afvisning
4.2	Gå videre end en hjemmeside	Hjemmeside vist i en WebView
4.2.1	En ægte oplevelse i augmented reality	En 3D-model sat ind i AR-visningen
4.2.2	Ikke kun markedsføring eller links	Udstillingsapp, aggregator, links
4.2.3	En selvstændig app, tydelige downloads	App, der kræver en anden app
4.2.6	Ingen app lavet ud fra en kommerciel skabelon	Skabelon indsendt af en leverandør

Tre præciseringer. 4.2.2 gør en undtagelse for kataloger: "Other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links." Et produktkatalog kan altså godt gå igennem. En reklamebrochure kan ikke.

4.2.3 har to punkter. Punkt (i) kræver, at appen virker alene, uden at man skal installere en anden app. Punkt (ii) kræver, at hvis appen skal downloade ressourcer ved første start, skal den oplyse downloadets størrelse og bede om accept først.

4.2.6, om kommercielle skabeloner og app-genereringstjenester, gennemgås i guiden til guideline 4.3, fordi den hænger sammen med anti-spam-reglen.

De to mest almindelige 4.2-beskeder

Apples besked starter med overskriften "Guideline 4.2 - Design - Minimum Functionality". Resten fortæller, hvilket af de to problemer revieweren har set. Her er to formuleringer, som udviklere har delt på Apples forum. De er nogle år gamle: Den præcise tekst kan have ændret sig, de to typer har ikke.

Appen ligner en hjemmeside. "Your app provides a limited user experience as it is not sufficiently different from a mobile browsing experience." Denne besked, delt på Apples forum, indeholder en afgørende sætning: "Including iOS features such as push notifications, Core Location, and sharing do not provide a robust enough experience to be appropriate for the App Store."

Appen er for tynd. "We found that the usefulness of your app is limited by the minimal amount of content or features it includes." Denne anden besked beder dig gentænke konceptet og indrømmer, at ingen målbar regel definerer, hvad der er nyttigt eller underholdende.

Det er ikke nok at tilføje notifikationer, lokalitet og en deleknap til en indpakket hjemmeside: Det har Apple selv skrevet i sine afvisninger.

Fire typiske 4.2-afvisninger

De fire tilfælde nedenfor er konstruerede eksempler, der skal illustrere reglen, ikke rigtige apps.

Den indpakkede hjemmeside

Eksempel: En sportsklub viser sin mobilside i en WebView med en native fanelinje ovenpå. Holdplan, booking og konto er websider. Revieweren ser det samme, som Safari ville vise. Apple siger det på sin App Review-side: En hjemmeside serveret i en iOS-app, webindhold, der ikke er tilpasset iOS, eller begrænsede webinteraktioner giver ikke en app af høj kvalitet.

Det ville jeg gøre: genopbygge skærmene til hovedhandlingen native, her holdplan og booking. Og så tilføje det, hjemmesiden ikke kan: en påmindelse før træningen, holdplanen tilgængelig uden netværk, næste træning i en widget.

Den alt for simple app

Eksempel: en app, der viser ét citat om dagen og intet andet. Man er færdig med den på ti sekunder. 4.2 taler om "lasting entertainment value or adequate utility": en værdi, der varer, eller tilstrækkelig nytte. For at rette det skal du give hovedhandlingen mere dybde, ikke lægge flere skærme rundt om den. Her: en historik, favoritter, en påmindelse på et valgt tidspunkt, en widget på hjemmeskærmen.

Den AI-genererede app uden noget native

Eksempel: et tekstfelt, en knap og et AI-svar vist som ren tekst. Apple bedømmer ikke værktøjet, men det, der lander på reviewerens skærm. Hvis oplevelsen kan være på en webside, er der god chance for, at 4.2 rammer.

Jeg gennemgår, hvad AI gør godt, og hvad den misser, i lav en app med AI. Formatet, hver generator laver, webapp eller mobilprojekt, sammenlignes i Lovable, Rork eller FlutterFlow.

Skallen, der venter på indhold

Eksempel: en markedsplads uden annoncer, et tomt katalog, et feed med "Kommer snart". Revieweren åbner en app, der intet har at vise. Det rammer også 2.1, som afviser midlertidigt indhold: se guiden til guideline 2.1. Send appen, når den har rigtigt indhold, eller giv en demokonto, der allerede er fyldt ud.

Min test: "Og i Safari?"

Før jeg sender, spørger jeg mig selv, om en hjemmeside kunne give den samme hovedfunktion. Hvis ja, er appen i fare for 4.2. Her er mit skema til at vurdere en native funktion. En funktion tæller, når den tjener hovedhandlingen, ikke når den pynter.

Funktion	Den tæller, når...	Den er ikke nok, når...
Notifikationer	De giver en information, man venter på	De videresender dine artikler
Offline	Hovedindholdet kan stadig bruges	Der kun vises en fejlskærm
Widget	Den viser data, der er personens egne	Den viser dit logo
Deling	Man sender indhold ind i din app	Den kun deler et link
Kamera, sensorer	De er en del af hovedhandlingen	De åbner din hjemmeside
Lokale data	Appen regner, sorterer og husker	Alt ligger på en webside

Apples anbefalinger peger samme vej. En widget viser aktuelt indhold, der kan læses med et hurtigt blik. En notifikation giver nyttig information med få ord og skal ikke bruges til at skubbe folk mod en opgave i appen.

Det, mine apps gør, som en hjemmeside ikke kan

Jeg designer hver app omkring en hovedfunktion, der ikke findes i en browser, eller en værdi, der får folk til at komme tilbage.

• Solys er et vækkeur. Alarmen går gennem AlarmKit, alarmtjenesten i iOS 26: Den trænger igennem lydløs tilstand ligesom Apples eget vækkeur. For at slukke den skal du vinde et minispil, og de valgte apps forbliver sat på pause efter vækning. Ingen webside kan få en iPhone til at ringe i lydløs.
• TradaZen er en tradingsimulator: en rigtig graf på en rigtig dato, en beslutning, lys der afsløres, rangerede dueller og en rang, der stiger. Her er det ikke en native funktion, der bærer appen. Det er den varige underholdningsværdi, som 4.2 taler om.
• Nolera er en garderobe: Du fotograferer dit tøj, appen fritlægger og sorterer det og foreslår et outfit hver morgen. Kameraet er en del af hovedhandlingen. Det er ikke en bonus.

4.2 kræver ikke en liste af native funktioner: Den kræver en grund til at installere appen i stedet for at åbne en hjemmeside.

Sådan retter du en 4.2-afvisning, trin for trin

1. Find typen. Webbrowsing: Det er den indpakkede hjemmeside. Minimalt indhold eller få funktioner: Det er den for tynde app. 4.2.3: afhængighed af en anden app eller et download, der ikke er oplyst.
2. Ændr produktet, ikke formuleringen. Et svar, der argumenterer uden at ændre noget, har ingen grund til at overbevise. Genopbyg skærmene til hovedhandlingen native, eller tilføj den dybde, der mangler.
3. Regn med et nyt build. Årsagen ligger i appen: En fjernopdatering er ikke nok. Hver indsendelse går gennem køen igen, se App Stores godkendelsestid.
4. Skriv review-noter, der guider. Apple beder på sin side om oplysninger til et komplet review om, at du beskriver konceptet, funktionerne og målgruppen. Ved en opdatering: hvad der er ændret, og hvor det findes.
5. Anke kun, hvis revieweren har overset noget. Hvis din native funktion allerede fandtes, men ikke blev set, så svar i App Store Connect med en kort video. En anke til App Review Board giver mening, når din app er blevet misforstået, ikke når den er tynd.

Den skabelon til noter, jeg ville bruge, på engelsk, til at tilpasse:

Hello App Review team,

Thank you for your feedback regarding Guideline 4.2.

What changed in build [X]:
- [Main feature] is now fully native: [what the user does].
- [Native feature]: [what it brings]. Where: [screen > button].
- [Second native feature]: [what it brings]. Where: [screen].
- Web content is limited to [legal pages, help].

How to test in two minutes:
1. Launch the app and [main action].
2. Turn on Airplane mode: [content] stays available.
3. Add the widget from the Home Screen: it shows [data].

Best regards,
[Your name]

Skriv kun det, der findes i det indsendte build. En funktion, der er nævnt, men ikke kan findes, vil give dig en ny afvisning, denne gang under 2.1.

4.2-tjeklisten før indsendelse

• Du kan sige med én sætning, hvad din app gør, som en hjemmeside ikke kan.
• Skærmene til hovedhandlingen er native, ikke websider.
• Hver native funktion tjener hovedhandlingen, og revieweren støder på den inden for to minutter.
• Appen har rigtigt indhold fra første start, eller en udfyldt demokonto.
• Appen virker alene, uden en anden app, der skal installeres.
• Et stort download ved første start oplyser sin størrelse og beder om accept.
• Review-noterne beskriver konceptet, målgruppen og hvor hver funktion findes.
• Hvis din idé ligger tæt på grænsen, har du testet den, før du kodede, med en velafgrænset MVP til en iOS-app.

Kom igennem 4.2 ved din næste indsendelse

Hvis din app lige er blevet afvist under 4.2, hjælper Apple Review Kit dig med at finde den nævnte regel og hvad den kræver, med skabeloner til noter til testeren. Hvis du stadig bygger, starter forløbet i iOS Kit med hovedfunktionen, før den første kodelinje. Vil du have et menneskeligt blik på det, så book en time med mig. Hele fremgangsmåden står på siden app afvist af Apple.

Hvis du forbereder din første udgivelse, så tag din gratis diagnose: Den sætter trinene i rækkefølge og sender dig min tjekliste mod afvisning fra Apple. Forsiden viser, hvordan du laver en mobilapp, der er tænkt til review fra start.

Ingen kan garantere, at Apple godkender din app. Jeg kan hjælpe dig med at give den en grund til at eksistere på App Store.

Ofte stillede spørgsmål

Hvad betyder "Guideline 4.2 - Design - Minimum Functionality"?

Det er overskriften på afvisningen for minimal funktionalitet. Apple vurderer, at din app ligner en hjemmeside for meget, eller at den har for lidt indhold eller for få funktioner. Den samme overskrift kan pege på en underregel: "Guideline 4.2.2" for en udstillingsapp eller en liste af links, 4.2.3 for en app, der afhænger af en anden app.

Bliver en app i WebView altid afvist?

Nej. Reglen går efter hjemmesiden pakket ind i en app, ikke efter teknologien. Revieweren bedømmer hovedoplevelsen: Hvis dens skærme er websider, der gør det samme som Safari, er risikoen høj. En hjælpeside, der åbnes i browseren, er ikke problemet.

Er det nok at tilføje push-notifikationer for at komme igennem 4.2?

Nej. I en afvisningsbesked delt på sit forum skriver Apple, at notifikationer, lokalitet og deling ikke er nok til at gøre oplevelsen rig nok. En notifikation tæller, når den tjener hovedfunktionen, som en alarm eller en påmindelse, personen selv har valgt.

Hvad er forskellen på guideline 4.2 og 4.3?

4.2 bedømmer din app alene: Giver den nok i forhold til en hjemmeside? 4.3 sammenligner den med andre: Er den en kopi, en variant eller endnu en app i en mættet kategori? Den samme app kan få begge, men de rettes ikke på samme måde.

Skal der et nyt build til efter en 4.2-afvisning?

Næsten altid, fordi årsagen ligger i selve appen. Eneste undtagelse: Revieweren fandt ikke en funktion, der allerede fandtes. I så fald svarer du i App Store Connect med præcise noter og en kort video uden at ændre buildet.