Apple avviser unyttige apper: svaret er ikke å bruke uker på dem

9. juni 2026 strammet Apple inn godkjenningsreglene for å luke ut apper «uten verdi». Mange leste det som et enkelt budskap: fra nå av må du bruke uker på en app for at den skal bli godtatt. Det stemmer ikke. Apple måler ikke tiden du bruker. De ser på om appen fortjener å eksistere.

Det Apple endret 9. juni 2026

Hovedendringen gjelder guideline 4.3(b). Apple legger til en setning uten rom for tvil:

Apple navngir til og med kategoriene som ikke lenger godtas uten en reelt annerledes opplevelse: dating, lommelykt, lydeffekter, bakgrunnsbilder, enkel nedtelling, spådom. Apper med prompelyder, rap, Kama Sutra eller drikkeleker plasserer de i kategorien «middelmådige, av lav kvalitet eller uten innsats».

Kriteriet er ikke tiden du bruker

Dette er poenget de fleste kommentarene bommer på. Apple avviser ikke en app fordi den ble laget raskt. De avviser den fordi den ikke tilfører noe. Enda en klone blir refusert, selv om den kostet deg tre uker. En målrettet app, med en reell grunn til å eksistere, bygget på fire dager, består.

Verdi handler altså ikke om timer. Du kan bruke en måned på å finpusse en idé ingen bryr seg om, eller levere på noen få dager noe som løser et virkelig problem. Apple vil se det siste.

Klausulen som virkelig endrer spillet

Den viktigste innstrammingen er ikke avvisningen ved inngangen, men det som skjer etterpå. Apple gir seg nå rett til å fjerne apper som allerede er publisert:

En app kan altså bli godtatt, ligge ute, og deretter forsvinne fordi den mangler brukere. Og en utvikler som spyr ut apper uten verdi risikerer kontoen sin. Å bruke seks uker på å polere en app i det tomme rom, uten å noen gang konfrontere den med ekte brukere, blir det verste veddemålet du kan ta.

Derfor er et MVP på noen få dager riktig svar

Hvis Apple belønner nytte og reell bruk, er logikken å levere raskt en versjon som gjør én ting godt, gi den til ekte brukere, og deretter iterere. Ikke å finpusse den i ukevis før du engang vet om noen vil ha den.

Et godt MVP hviler på en klar kjerne:

• En hovedfunksjon som faktisk virker, ikke en attrapp
• Ekte native funksjoner, de en enkel nettside pakket inn i en webview ikke kan tilby
• En ryddig innstillingsskjerm, med personvern og håndtering av varsler
• Nok måling til å se om folk kommer tilbake, så du kan avgjøre hva du bygger videre

Denne kjernen bygges på noen få dager når du vet hvor du skal. Resten, sekundære funksjoner og grensetilfeller, kommer etterpå, når appen har bevist at den interesserer noen.

Rask fordi erfaren, ikke rask fordi slurvete

Det er en nyanse du ikke må gå glipp av. «Levere på noen få dager» er ikke det samme som «slurve». Appene Apple luker ut akkurat nå er nettopp de som ble produsert raskt og uten håndverk, ofte generert med vibe coding-verktøy. Farten redder dem ikke, mangelen på verdi feller dem.

Forskjellen ligger i erfaringen. Etter atten år med apputvikling vet man hva som består godkjenningen og hva som blir refusert. Man vet hvilke native funksjoner en reviewer forventer, hvor guideline 4.2 skjærer seg, hvorfor en forkledd web-app aldri holder over tid. Man kaster ikke bort tid på å gjenoppdage disse reglene ved å pådra seg avvisninger. Man bygger appen riktig med én gang.

Det er dette som er å levere raskt uten å levere dårlig. Man kutter sløsingen, ikke de essensielle funksjonene. Kjernen er aldri opp til forhandling. Det man fjerner, er ukene brukt på å finpusse det ingen trenger.