Apple nekar onödiga appar: svaret är inte att lägga veckor på dem

Den 9 juni 2026 skärpte Apple sina granskningsregler för att sålla bort appar ”utan värde”. Många läste in ett enkelt budskap: du måste nu lägga veckor på en app för att den ska godkännas. Det stämmer inte. Apple mäter inte hur mycket tid du lägger ner. Apple tittar på om appen förtjänar att finnas.

Vad Apple ändrade den 9 juni 2026

Den viktigaste ändringen rör guideline 4.3(b). Apple lägger till en mening utan minsta tvetydighet:

Apple namnger till och med de kategorier som inte längre godkänns utan en verkligt annorlunda upplevelse: dejting, ficklampa, ljudeffekter, bakgrundsbilder, enkel timer, spådom. Appar med fisljud, rapljud, Kama Sutra eller dryckesspel placerar Apple i facket ”mediokra, låg kvalitet eller utan ansträngning”.

Kriteriet är inte tiden du lägger ner

Det är den poäng som de flesta kommentarer missar. Apple nekar inte en app för att den gjordes snabbt. Apple nekar den för att den inte tillför något. Ännu en klon blir nekad även om den kostade dig tre veckor. En fokuserad app, med ett verkligt skäl att finnas, byggd på fyra dagar, går igenom.

Värde är alltså ingen fråga om timmar. Du kan lägga en månad på att finslipa en idé som ingen bryr sig om, eller leverera något på några dagar som löser ett verkligt problem. Apple vill se det andra.

Klausulen som verkligen ändrar spelplanen

Den viktigaste skärpningen ligger inte i nekandet vid inträdet, utan i vad som händer efteråt. Apple ger sig nu rätten att ta bort appar som redan är publicerade:

En app kan alltså godkännas, ligga kvar, och sedan försvinna i brist på användare. Och en utvecklare som radar upp intetsägande appar riskerar sitt konto. Att lägga sex veckor på att polera en app i tomma intet, utan att någonsin möta riktiga användare, blir det sämsta tänkbara vadet.

Därför är en MVP på några dagar rätt svar

Om Apple belönar nytta och verklig användning är logiken att snabbt leverera en version som gör en sak bra, lägga den i händerna på riktiga användare, och sedan iterera. Inte att finslipa den i veckor innan man ens vet om någon vill ha den.

En bra MVP vilar på en tydlig kärna:

• En huvudfunktion som verkligen fungerar, inte en attrapp
• Riktiga native-funktioner, sådana som en webbsida inpackad i en webview inte kan erbjuda
• En ren inställningsvy, med integritet och hantering av notiser
• Ett sätt att mäta om folk kommer tillbaka, för att avgöra vad som ska byggas härnäst

Den kärnan byggs på några dagar när man vet vart man är på väg. Resten, sekundära funktioner och gränsfall, kommer efteråt, när appen har bevisat att någon bryr sig.

Snabb för att erfaren, inte snabb för att slarvig

Det finns en nyans att inte missa. ”Att leverera på några dagar” är inte samma sak som ”att slarva”. Apparna som Apple rensar ut just nu är just de som producerats snabbt och utan hantverkskunnande, ofta genererade med verktyg för vibe coding. Snabbheten räddar dem inte, deras brist på värde fäller dem.

Skillnaden ligger i erfarenheten. Efter arton år med apputveckling vet man vad som klarar granskningen och vad som blir nekat. Man vet vilka native-funktioner en granskare förväntar sig, var guideline 4.2 sätter stopp, varför en förklädd webbapp aldrig håller i längden. Man slösar ingen tid på att återupptäcka de reglerna genom att samla på sig nekanden. Man bygger appen rätt på första försöket.

Det är det som är att leverera snabbt utan att leverera dåligt. Man skär bort slöseriet, inte de väsentliga funktionerna. Kärnan är aldrig förhandlingsbar. Det man tar bort är veckorna man lagt på att finslipa det som ingen behöver.