Guideline 4.2 Minimum Functionality: appen avvisad

Guideline 4.2, ”Minimum Functionality”, avvisar en app som inte erbjuder något mer än en webbplats, eller för lite för att man ska behålla den. Lösningen är inte att stapla native-funktioner på varandra, utan att placera en av dem i centrum av användningen och sedan tala om för granskaren var den finns. Rättningen kräver nästan alltid en ny build.

Jag publicerar mina egna iOS-appar: Solys, TradaZen och Nolera finns på App Store. Den här guiden bygger på Apples officiella text, läst den 15 oktober 2026, och på 4.2-avslag som utvecklare har publicerat på Apples forum. De avvisade apparna som nämns längre ner är exempel. Vill du ha helhetsbilden av alla avslagsorsaker läser du hellre varför Apple avvisar en app.

Vad säger guideline 4.2?

4.2 finns i avsnitt 4, ”Design”, i App Review Guidelines. Den första meningen sätter kriteriet: ”Your app should include features, content, and UI that elevate it beyond a repackaged website.” Din app måste alltså erbjuda funktioner, innehåll och ett gränssnitt som lyfter den över en webbplats som bara har packats om.

Texten lägger till två idéer. En app som inte är verkligt användbar, unik eller ”app-like” hör inte hemma på App Store. Och en app som varken ger varaktig underhållning eller tillräcklig nytta kan avvisas. 4.2 bedömer alltså två saker: skillnaden mot webben och mängden värde.

Underreglerna som meddelandet kan hänvisa till

Underregel	Vad Apple kräver	Typiskt avslag
4.2	Gå längre än en webbplats	Webbplats som visas i en WebView
4.2.1	En riktig upplevelse i förstärkt verklighet	En 3D-modell utplacerad i AR-vyn
4.2.2	Inte bara marknadsföring eller länkar	Skyltfönsterapp, aggregator, länkar
4.2.3	En fristående app, tydliga nedladdningar	App som kräver en annan app
4.2.6	Ingen app byggd på en kommersiell mall	Mall som skickats in av en leverantör

Tre förtydliganden. 4.2.2 gör ett undantag för kataloger: ”Other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links.” En produktkatalog kan alltså gå igenom. En reklambroschyr gör det inte.

4.2.3 har två punkter. (i) kräver att appen fungerar på egen hand, utan att man installerar en annan app. (ii) kräver att appen, om den måste ladda ner resurser vid första starten, anger nedladdningens storlek och ber om godkännande först.

4.2.6, om kommersiella mallar och tjänster som genererar appar, går jag igenom i guiden om guideline 4.3, eftersom den hänger ihop med spamregeln.

De två vanligaste 4.2-meddelandena

Apples meddelande börjar med rubriken ”Guideline 4.2 - Design - Minimum Functionality”. Resten säger vilket av de två problemen granskaren har sett. Här är två formuleringar som utvecklare har publicerat på Apples forum. De är några år gamla: den exakta texten kan ha ändrats, men inte de två kategorierna.

Appen ser ut som en webbplats. ”Your app provides a limited user experience as it is not sufficiently different from a mobile browsing experience.” Det här meddelandet, publicerat på Apples forum, innehåller en avgörande mening: ”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 är för tunn. ”We found that the usefulness of your app is limited by the minimal amount of content or features it includes.” Det här andra meddelandet ber dig se över konceptet och medger att ingen siffersatt regel definierar vad som är användbart eller underhållande.

Att lägga till notiser, platstjänster och en delningsknapp på en inkapslad webbplats räcker inte: Apple har skrivit det i sina egna avslag.

Fyra typiska fall av 4.2-avslag

De fyra fallen nedan är påhittade exempel som illustrerar regeln, inte riktiga appar.

Den inkapslade webbplatsen

Exempel: en idrottsklubb visar sin mobilsajt i en WebView, med en native-flikrad ovanpå. Schemat, bokningen och kontot är webbsidor. Granskaren hittar samma sak som Safari skulle visa. Apple skriver det på sin App Review-sida: en webbplats som serveras i en iOS-app, webbinnehåll som inte är anpassat för iOS eller begränsade webbinteraktioner gör ingen kvalitetsapp.

Vad jag skulle göra: bygga om skärmarna för huvudfunktionen native, här schemat och bokningen. Sedan lägga till det webbplatsen inte klarar: en påminnelse före passet, schemat tillgängligt utan nät, nästa pass i en widget.

Den alltför enkla appen

Exempel: en app som visar ett citat om dagen, och inget annat. Man har sett allt på tio sekunder. 4.2 talar om ”lasting entertainment value or adequate utility”: ett värde som består, eller tillräcklig nytta. För att rätta till det, ge huvudfunktionen mer djup i stället för att lägga till skärmar runt den. Här: en historik, favoriter, en påminnelse vid vald tid, en widget på hemskärmen.

Den AI-genererade appen utan något native

Exempel: ett textfält, en knapp, ett AI-svar som visas som ren text. Apple bedömer inte verktyget, utan det som hamnar på granskarens skärm. Om upplevelsen ryms på en webbsida är risken stor att 4.2 slår till.

Jag går igenom vad AI gör bra och vad den missar i skapa en app med AI. Formatet som varje generator levererar, webbapp eller mobilprojekt, jämförs i Lovable, Rork eller FlutterFlow.

Skalet som väntar på innehåll

Exempel: en marknadsplats utan annonser, en tom katalog, ett flöde som visar ”Kommer snart”. Granskaren öppnar en app som inte har något att visa. Det här fallet rör också 2.1, som avvisar provisoriskt innehåll: se guiden om guideline 2.1. Skicka in appen när den har riktigt innehåll, eller bifoga ett demokonto som redan är ifyllt.

Testet jag gör: ”Och i Safari?”

Innan jag skickar in frågar jag mig om en webbplats skulle kunna erbjuda samma huvudfunktion. Om svaret är ja är appen sårbar för 4.2. Här är min mall för att bedöma en native-funktion. En funktion räknas när den tjänar huvudfunktionen, inte när den bara är dekoration.

Funktion	Den räknas när...	Den räcker inte när...
Notiser	De ger information man väntar på	De bara vidarebefordrar dina artiklar
Offline	Huvudinnehållet går att använda	Bara en felskärm visas
Widget	Den visar data som är personlig	Den visar din logga
Delning	Man skickar innehåll till din app	Den bara delar en länk
Kamera, sensorer	De är en del av huvudfunktionen	De öppnar din webbplats
Lokal data	Appen räknar, sorterar och minns	Allt bor på en webbsida

Apples rekommendationer pekar åt samma håll. En widget visar aktuellt innehåll som går att läsa med en snabb blick. En notis ger användbar information med få ord och ska inte användas för att knuffa folk mot en uppgift i appen.

Det mina appar gör som en webbplats inte gör

Jag bygger varje app kring en huvudfunktion som inte finns i en webbläsare, eller kring ett värde som får folk att komma tillbaka.

• Solys är en väckarklocka. Larmet går via AlarmKit, larmtjänsten i iOS 26: det tränger igenom ljudlöst läge, precis som Apples egen väckarklocka. För att stänga av det måste du vinna ett minispel, och de appar du valt förblir pausade efter att du vaknat. Ingen webbsida kan få en iPhone i ljudlöst läge att ringa.
• TradaZen är en tradingsimulator: ett riktigt diagram vid ett riktigt datum, ett beslut, ljus som avslöjas, rankade dueller och en rang som stiger. Här är det inte en native-funktion som bär appen. Det är det varaktiga underhållningsvärde som 4.2 talar om.
• Nolera är en garderob: du fotar dina kläder, appen frilägger och sorterar dem och föreslår sedan en outfit varje morgon. Kameran är en del av huvudfunktionen. Den är ingen bonus.

4.2 kräver ingen lista med native-funktioner: den kräver ett skäl att installera appen i stället för att öppna en webbplats.

Rätta till ett 4.2-avslag, steg för steg

1. Identifiera kategorin. Webbsurfning: det är den inkapslade webbplatsen. Minimalt innehåll eller minimala funktioner: det är den för tunna appen. 4.2.3: ett beroende av en annan app eller en nedladdning som inte annonserats.
2. Ändra produkten, inte formuleringen. Ett svar som argumenterar utan att ändra något har ingen anledning att övertyga. Bygg om huvudfunktionens skärmar native, eller lägg till det djup som saknas.
3. Räkna med en ny build. Orsaken finns i appen: en fjärruppdatering räcker inte. Varje inskick går genom kön igen, se App Stores granskningstid.
4. Skriv granskningsanteckningar som vägleder. Apple ber dig, på sin sida om information för en fullständig granskning, att beskriva konceptet, funktionerna och målgruppen. För en uppdatering: vad som har ändrats och var man hittar det.
5. Överklaga bara om granskaren missade något. Om din native-funktion redan fanns men inte sågs, svara i App Store Connect med en kort video. En överklagan till App Review Board är motiverad när din app har missförståtts, inte när den är tunn.

Mallen för anteckningar som jag skulle använda, på engelska, att anpassa:

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 bara det som finns i den build du skickar in. En utlovad funktion som inte går att hitta skulle ge dig ett nytt avslag, den här gången enligt 2.1.

Checklistan för 4.2 före inskick

• Du kan säga i en mening vad din app gör som en webbplats inte gör.
• Huvudfunktionens skärmar är native, inte webbsidor.
• Varje native-funktion tjänar huvudfunktionen, och granskaren stöter på den inom två minuter.
• Appen har riktigt innehåll från första starten, eller ett ifyllt demokonto.
• Appen fungerar på egen hand, utan någon annan app att installera.
• En stor nedladdning vid första starten anger sin storlek och ber om godkännande.
• Granskningsanteckningarna beskriver konceptet, målgruppen och var varje funktion finns.
• Om din idé ligger nära gränsen har du testat den innan du kodade, med en väl avgränsad MVP för en iOS-app.

Klara 4.2 redan vid nästa inskick

Om din app just har avvisats enligt 4.2 hjälper Apple Review Kit dig att hitta regeln som nämns och vad den kräver, med mallar för anteckningar till testaren. Om du fortfarande bygger utgår iOS Kit från huvudfunktionen innan första kodraden. Vill du ha ett mänskligt öga, boka en timme med mig. Hela arbetssättet finns på sidan app avvisad av Apple.

Om du förbereder din första lansering, gör din gratis diagnos: den sätter stegen i rätt ordning och skickar dig min checklista mot Apple-avslag. Startsidan visar hur du skapar en mobilapp som är tänkt för granskningen från början.

Ingen kan garantera att Apple godkänner din app. Jag kan hjälpa dig att ge den ett skäl att finnas på App Store.

Vanliga frågor

Vad betyder ”Guideline 4.2 - Design - Minimum Functionality”?

Det är rubriken för avslag på grund av minimal funktionalitet. Apple bedömer att din app liknar en webbplats för mycket, eller att den erbjuder för lite innehåll eller för få funktioner. Samma rubrik kan gälla en underregel: ”Guideline 4.2.2” för en skyltfönsterapp eller en länklista, 4.2.3 för en app som är beroende av en annan app.

Avvisas en app i WebView alltid?

Nej. Regeln riktar sig mot webbplatsen som lagts i en app, inte mot tekniken. Granskaren bedömer huvudupplevelsen: om dess skärmar är webbsidor som gör samma sak som Safari är risken hög. En hjälpsida som öppnas i webbläsaren är inte problemet.

Räcker det att lägga till push-notiser för att klara 4.2?

Nej. I ett avslagsmeddelande som publicerats på Apples forum skriver Apple att notiser, platstjänster och delning inte räcker för att göra upplevelsen tillräckligt rik. En notis räknas när den tjänar huvudfunktionen, som ett larm eller en påminnelse som personen själv har valt.

Vad är skillnaden mellan guideline 4.2 och 4.3?

4.2 bedömer din app för sig: ger den tillräckligt jämfört med en webbplats? 4.3 jämför den med andra: är den en kopia, en variant eller ännu en app i en mättad kategori? Samma app kan drabbas av båda, men de rättas inte till på samma sätt.

Behövs en ny build efter ett 4.2-avslag?

Nästan alltid, eftersom orsaken finns i själva appen. Enda undantaget: granskaren hittade inte en funktion som redan fanns. Svara i så fall i App Store Connect med tydliga anteckningar och en kort video, utan att ändra builden.