Guideline 4.2 Minimum Functionality: appen ble avvist

Guideline 4.2, «Minimum Functionality», avviser apper som ikke gir noe mer enn et nettsted, eller som gir for lite til at noen beholder dem. Løsningen er ikke å stable native funksjoner oppå hverandre. Du setter én i sentrum av bruken, og så forteller du revieweren hvor den finnes. Rettelsen krever nesten alltid en ny build.

Jeg publiserer mine egne iOS-apper: Solys, TradaZen og Nolera ligger på App Store. Denne guiden bygger på Apples offisielle tekst, lest 15. oktober 2026, og på 4.2-avvisninger som utviklere har delt på Apples forum. Appene som nevnes som avvist lenger ned, er eksempler. Vil du ha oversikten over alle avvisningsgrunnene, les heller hvorfor Apple avviser en app.

Hva sier guideline 4.2?

4.2 står i seksjon 4, «Design», i App Review Guidelines. Den første setningen setter kriteriet: «Your app should include features, content, and UI that elevate it beyond a repackaged website.» Med andre ord må appen din ha funksjoner, innhold og et grensesnitt som løfter den over et nettsted som bare er pakket inn på nytt.

Teksten legger til to ting. En app som ikke er spesielt nyttig, unik eller «app-like», hører ikke hjemme på App Store. Og en app som verken gir varig underholdning eller tilstrekkelig nytte, kan bli avvist. 4.2 vurderer altså to ting: forskjellen fra nettet, og hvor mye verdi appen gir.

Underreglene meldingen kan vise til

Underregel	Hva Apple krever	Typisk avvisning
4.2	Gå lenger enn et nettsted	Nettsted vist i en WebView
4.2.1	En ekte opplevelse i utvidet virkelighet	En 3D-modell plassert i AR-visningen
4.2.2	Ikke bare markedsføring eller lenker	Reklameapp, aggregator, lenker
4.2.3	En selvstendig app, tydelige nedlastinger	App som krever en annen app
4.2.6	Ingen app laget fra en kommersiell mal	Mal sendt inn av en leverandør

Tre presiseringer. 4.2.2 gjør et unntak for kataloger: «Other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links.» En produktkatalog kan altså gå gjennom. En reklamebrosjyre kan ikke.

4.2.3 har to ledd. Ledd (i) krever at appen fungerer alene, uten at man må installere en annen app. Ledd (ii) krever at appen, hvis den må laste ned ressurser ved første oppstart, oppgir størrelsen på nedlastingen og ber om samtykke først.

4.2.6, om kommersielle maler og tjenester som genererer apper, går jeg gjennom i guiden til guideline 4.3, fordi den henger sammen med regelen mot spam.

De to vanligste 4.2-meldingene

Apples melding starter med overskriften «Guideline 4.2 - Design - Minimum Functionality». Resten sier hvilket av de to problemene revieweren har sett. Her er to formuleringer som utviklere har delt på Apples forum. De er noen år gamle: den nøyaktige teksten kan ha endret seg, men ikke de to kategoriene.

Appen ligner et nettsted. «Your app provides a limited user experience as it is not sufficiently different from a mobile browsing experience.» Denne meldingen, delt på Apples forum, inneholder en avgjørende setning: «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 tynn. «We found that the usefulness of your app is limited by the minimal amount of content or features it includes.» Denne andre meldingen ber deg revurdere konseptet, og innrømmer at ingen tallfestet regel definerer hva som er nyttig eller underholdende.

Å legge til varsler, posisjon og en deleknapp på et innpakket nettsted holder ikke: det har Apple skrevet i sine egne avvisninger.

Fire typiske tilfeller av 4.2-avvisning

De fire tilfellene under er konstruerte eksempler for å illustrere regelen, ikke ekte apper.

Det innpakkede nettstedet

Eksempel: en treningsklubb viser mobilnettstedet sitt i en WebView, med en native fanelinje på toppen. Timeplanen, bookingen og kontoen er nettsider. Revieweren ser det samme som Safari ville vist. Apple sier det på sin App Review-side: et nettsted servert i en iOS-app, nettinnhold som ikke er tilpasset iOS, eller begrensede nettinteraksjoner gir ikke en app av god kvalitet.

Det jeg ville gjort: bygge skjermene for hovedhandlingen på nytt i native, her timeplanen og bookingen. Så legge til det nettstedet ikke kan: en påminnelse før økten, timeplanen tilgjengelig uten nett, neste økt i en widget.

Den altfor enkle appen

Eksempel: en app som viser ett sitat om dagen, og ingenting mer. Du har sett alt på ti sekunder. 4.2 snakker om «lasting entertainment value or adequate utility»: en verdi som varer, eller tilstrekkelig nytte. For å rette det, gi hovedhandlingen mer dybde, ikke flere skjermer rundt den. Her: en historikk, favoritter, en påminnelse på valgt tidspunkt, en widget på Hjem-skjermen.

Den AI-genererte appen uten noe native

Eksempel: et tekstfelt, en knapp, et AI-svar vist som ren tekst. Apple vurderer ikke verktøyet, men det som dukker opp på skjermen til revieweren. Hvis opplevelsen får plass på en nettside, er det stor sjanse for at 4.2 slår til.

Jeg går gjennom hva AI gjør bra og hva den bommer på i lage en app med AI. Formatet hver generator lager, webapp eller mobilprosjekt, sammenlignes i Lovable, Rork eller FlutterFlow.

Skallet som venter på innhold

Eksempel: en markedsplass uten annonser, en tom katalog, en feed som viser «Kommer snart». Revieweren åpner en app som ikke har noe å vise. Dette tilfellet treffer også 2.1, som avviser plassholderinnhold: se guiden til guideline 2.1. Send inn appen når den har ekte innhold, eller legg ved en demokonto som allerede er fylt opp.

Testen jeg gjør: «Og i Safari?»

Før jeg sender inn, spør jeg meg selv om et nettsted kunne gitt samme hovedfunksjon. Hvis ja, er appen utsatt for 4.2. Her er skjemaet mitt for å vurdere en native funksjon. En funksjon teller når den tjener hovedhandlingen, ikke når den pynter.

Funksjon	Den teller når...	Den holder ikke når...
Varsler	De gir informasjon brukeren venter på	De bare videresender artiklene dine
Offline	Hovedinnholdet fortsatt kan brukes	Bare en feilskjerm vises
Widget	Den viser data som tilhører personen	Den viser logoen din
Deling	Man sender innhold inn i appen din	Den bare deler en lenke
Kamera, sensorer	De er en del av hovedhandlingen	De åpner nettstedet ditt
Lokale data	Appen regner, sorterer og husker	Alt lever på en nettside

Apples anbefalinger peker samme vei. En widget viser aktuelt innhold som kan leses med et raskt blikk. Et varsel gir nyttig informasjon med få ord, og skal ikke brukes til å dytte folk mot en oppgave i appen.

Det appene mine gjør som et nettsted ikke kan

Jeg designer hver app rundt en hovedfunksjon som ikke finnes i en nettleser, eller en verdi som får folk til å komme tilbake.

• Solys er en vekkerklokke. Alarmen går via AlarmKit, alarmtjenesten i iOS 26: den går gjennom lydløs modus, akkurat som Apples egen vekkerklokke. For å slå den av må du vinne et minispill, og appene du har valgt, forblir satt på pause etter at du har våknet. Ingen nettside får en iPhone til å ringe i lydløs modus.
• TradaZen er en tradingsimulator: en ekte graf på en ekte dato, en beslutning, lys som avsløres, rangerte dueller og en rang som stiger. Her er det ikke en native funksjon som bærer appen. Det er den varige underholdningsverdien 4.2 snakker om.
• Nolera er en garderobeapp: du tar bilde av klærne dine, appen klipper dem ut og sorterer dem, og foreslår et antrekk hver morgen. Kameraet er en del av hovedhandlingen. Det er ikke en bonus.

4.2 krever ikke en liste med native funksjoner: den krever en grunn til å installere appen i stedet for å åpne et nettsted.

Rette en 4.2-avvisning, steg for steg

1. Finn kategorien. Nettsurfing: det er det innpakkede nettstedet. Minimalt innhold eller få funksjoner: det er den tynne appen. 4.2.3: avhengighet av en annen app eller en nedlasting som ikke er varslet.
2. Endre produktet, ikke formuleringen. Et svar som argumenterer uten å endre noe, har ingen grunn til å overbevise. Bygg skjermene for hovedhandlingen på nytt i native, eller legg til dybden som mangler.
3. Planlegg en ny build. Årsaken ligger i appen: en fjernoppdatering holder ikke. Hver innsending går gjennom køen på nytt, se behandlingstiden på App Store.
4. Skriv review-notater som veileder. Apple ber deg, på siden om informasjon for en fullstendig review, beskrive konseptet, funksjonene og målgruppen. For en oppdatering: hva som er endret, og hvor det finnes.
5. Klag bare hvis revieweren har oversett noe. Hvis den native funksjonen din allerede fantes, men ikke ble sett, svar i App Store Connect med en kort video. En klage til App Review Board er berettiget når appen din er blitt misforstått, ikke når den er tynn.

Malen for notater jeg ville brukt, på engelsk, til å 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 bare det som finnes i builden du sender inn. En funksjon du har lovet, men som ikke er å finne, vil gi deg en ny avvisning, denne gangen etter 2.1.

Sjekklisten for 4.2 før innsending

• Du kan si med én setning hva appen din gjør som et nettsted ikke kan.
• Skjermene for hovedhandlingen er native, ikke nettsider.
• Hver native funksjon tjener hovedhandlingen, og revieweren støter på den på under to minutter.
• Appen har ekte innhold fra første oppstart, eller en fylt demokonto.
• Appen fungerer alene, uten at en annen app må installeres.
• En stor nedlasting ved første oppstart oppgir størrelsen og ber om samtykke.
• Review-notatene beskriver konseptet, målgruppen og hvor hver funksjon ligger.
• Hvis ideen din ligger nær grensen, har du testet den før du begynte å kode, med en godt avgrenset MVP for iOS-app.

Kom gjennom 4.2 allerede ved neste innsending

Hvis appen din nettopp er avvist etter 4.2, hjelper Apple Review Kit deg med å finne regelen det vises til og hva den krever, med maler for notater til testeren. Hvis du fortsatt bygger, starter løpet i iOS Kit med hovedfunksjonen før første kodelinje. Vil du ha et menneskelig blikk, book en time med meg. Hele fremgangsmåten finner du på siden app avvist av Apple.

Hvis du forbereder din første lansering, ta den gratis diagnosen: den setter stegene i riktig rekkefølge og sender deg sjekklisten min mot avvisning fra Apple. Forsiden viser hvordan du kan lage en mobilapp som er tenkt for review fra starten.

Ingen kan garantere at Apple godkjenner appen din. Jeg kan hjelpe deg med å gi den en grunn til å finnes på App Store.

Ofte stilte spørsmål

Hva betyr «Guideline 4.2 - Design - Minimum Functionality»?

Det er overskriften på avvisningen for minimal funksjonalitet. Apple mener at appen din ligner for mye på et nettsted, eller at den har for lite innhold eller for få funksjoner. Samme overskrift kan vise til en underregel: «Guideline 4.2.2» for en reklameapp eller en lenkeliste, 4.2.3 for en app som er avhengig av en annen app.

Blir en app i WebView alltid avvist?

Nei. Regelen gjelder nettstedet som er pakket inn i en app, ikke teknologien. Revieweren vurderer hovedopplevelsen: hvis skjermene er nettsider som gjør det samme som Safari, er risikoen høy. En hjelpeside som åpnes i nettleseren, er ikke problemet.

Holder det å legge til push-varsler for å komme gjennom 4.2?

Nei. I en avvisningsmelding delt på sitt eget forum skriver Apple at varsler, posisjon og deling ikke er nok til å gjøre opplevelsen rik nok. Et varsel teller når det tjener hovedfunksjonen, som en alarm eller en påminnelse personen selv har valgt.

Hva er forskjellen mellom guideline 4.2 og 4.3?

4.2 vurderer appen din alene: gir den nok sammenlignet med et nettsted? 4.3 sammenligner den med andre: er den en kopi, en variant eller enda en app i en mettet kategori? Samme app kan få begge, men de rettes ikke på samme måte.

Trenger jeg en ny build etter en 4.2-avvisning?

Nesten alltid, siden årsaken ligger i selve appen. Eneste unntak: revieweren fant ikke en funksjon som allerede fantes. Da svarer du i App Store Connect med presise notater og en kort video, uten å endre builden.