Hvordan lage en app: de 4 stegene du må følge

Hvordan lager man en app? Det finnes fire måter å gjøre det på: et verktøy uten kode, AI som skriver koden for deg, kode du lærer selv, eller en leverandør. Uansett hvilken måte du velger, går veien gjennom de samme fire stegene: velge en app som kan tjene penger, bygge hovedfunksjonen, koble på betaling, og så publisere og bli funnet. I den rekkefølgen, og med én regel som binder dem sammen: hvert steg ender med noe konkret, testet på en ekte telefon.

De fleste første apper dør verken av tekniske problemer eller av budsjettet. De dør i uklarhet: ingen vet hva «ferdig» betyr, funksjonene hoper seg opp, og seks måneder senere ligger det fortsatt ingenting på App Store. Dette er metoden jeg bruker på mine egne iOS-apper, blant annet Solys (en vekkerklokke med minispill) og TradaZen (en tradingsimulator), begge på App Store. Jeg har finpusset den etter avvisninger fra Apple på Solys, Clic og Nolera. Eksemplene mine kommer altså fra iPhone. Når Google Play fungerer annerledes, sier jeg ifra.

Hvilke måter finnes det for å lage en app?

Før stegene må du ta én beslutning: hvordan skal du bygge? Det finnes fire måter, og ingen av dem er best for alle.

Måte	For hvilket prosjekt	Hva du betaler	Begrensningen
Et verktøy uten kode (Bubble, FlutterFlow, Glide)	Katalog, skjema, prototyp, internt verktøy	Abonnementet på verktøyet, så lenge appen finnes	Appen lever hos verktøyet, og ikke alle publiserer i butikkene
AI som skriver koden (Claude Code, Codex, Cursor)	Din egen app, publisert i butikkene, uten at du kan kode fra før	Abonnementet på AI-en og avgiftene til butikkene	Koden er din, men det er du som må teste den
Lære å kode (Swift, Kotlin, React Native)	Du vil ha full kontroll eller gjøre det til et yrke	Først og fremst tid	Den lengste veien før første publisering
En leverandør (frilanser eller byrå)	Et verktøy for virksomheten din, når du mangler tid	Utviklertid: en dagspris ganget med antall dager	Hver endring koster; sjekk hvem som eier kontoen og koden

Verktøyet uten kode (no-code). Du setter sammen appen med musa, uten å skrive en eneste linje. Det går raskt for en katalog, et skjema eller et internt verktøy. Før du binder deg, sjekk at verktøyet faktisk publiserer i butikkene. Bubble forklarer hvordan du publiserer på App Store og Google Play, og FlutterFlow tilbyr det fra og med det betalte Basic-abonnementet. Glide, derimot, sier at appene deres er webapper, og at direkte publisering på App Store eller Google Play ikke støttes. Begrensningene, sak for sak, finner du i lage en app uten å kode.

AI som skriver koden. Du beskriver hva du vil ha, og en assistent som Claude Code, Codex eller Cursor skriver ekte kode, i et standardformat du kan ta med deg videre. Det kalles vibe coding. Det er slik jeg lager appene mine. Baksiden: AI-en tar feil med stor selvsikkerhet, og det er du som må teste. For å velge verktøy, les hvilken AI du bør bruke for å lage en app. Vil du lære det med en fast ramme, finnes kurset i vibe coding.

Lære å kode. Dette er veien for dem som vil ha full kontroll eller gjøre det til et yrke. Veiledningene fra Apple og Expo er gratis. Løpet finner du i lære å lage en app.

Leverandøren. En frilanser eller et byrå bygger appen for deg. Det er riktig valg når appen er et verktøy for virksomheten din og du mangler tid. Du betaler for utviklertid, og hver endring koster også. Be skriftlig om nøyaktig omfang, hvem som eier Apple-kontoen og koden, og hva som skjer hvis Apple avviser appen. Spørsmålene du bør stille står i få utviklet en app.

Det finnes en femte vei, som ligger mellom de andre: bygge selv, men fra et ferdig grunnlag. Det er prinsippet bak kittet mitt for å lage en mobilapp uten å starte fra null, iOS Kit: startkoden fra appene mine og et løp i fire steg som du følger i ditt eget tempo.

Hvordan bestemme deg? Tre spørsmål er nok:

1. Må appen ligge på App Store eller Google Play? Hvis ja, dropp verktøyene som bare lager webapper.
2. Skal den selge et abonnement? Regel 3.1.1 i App Review Guidelines krever, med noen unntak, Apples kjøp i appen for å låse opp funksjoner i en app. Sjekk hvordan byggemåten din håndterer det før du begynner.
3. Har du mest tid, eller mest budsjett? Tid: bygg den selv, med AI. Budsjett og ingen tid: få den utviklet.

Native app, webapp eller kryssplattform: hva bør du velge?

Den andre beslutningen er enklere enn den ser ut: hvilken type app?

• Den native appen installeres fra en butikk og har tilgang til telefonens funksjoner: varsler, kamera, kjøp i appen. Den skrives i språket til hver plattform (Swift for iPhone, Kotlin for Android) og krever ett prosjekt per plattform.
• Webappen (PWA) er en nettside som oppfører seg som en app. Den går ikke gjennom noen butikk: ingen gjennomgang å vente på, men ingen vil finne den på App Store. Og det holder ikke å pakke inn en nettside i en app: Apples regel 4.2 krever at en app går lenger enn en innpakket nettside.
• Kryssplattform-appen bruker ett enkelt prosjekt til å lage både iPhone-appen og Android-appen. Expo oppsummerer det slik: ett enkelt JavaScript- eller TypeScript-prosjekt som kjører native på brukernes enheter, Android, iOS og web.

For en første app anbefaler jeg kryssplattform, med React Native og Expo. Du har bare én kodebase å vedlikeholde, og kompileringen skjer på Mac-er som Expo drifter: du kan publisere en iOS-app uten Mac.

iOS eller Android først? Én kodebase betyr ikke én lansering: hver butikk har sin egen side, sine egne regler og sin egen gjennomgang. Start med én plattform. Hvis appen din selger et abonnement, anbefaler jeg iPhone. Tallene og motargumentene står i iOS- eller Android-app: hvilken bør du starte med.

Hvorfor kommer så mange apper aldri ut på App Store?

Tre årsaker går nesten alltid igjen:

• En for stor første versjon. Tolv halvferdige funksjoner i stedet for én som er ferdig.
• Betaling som tenkes på til slutt. Inntektsmodellen endrer strukturen i appen: legger du den til i etterkant, må du bygge om.
• Publisering sett på som en formalitet. Apples gjennomgang, produktsiden, personvernet: det er et eget steg, med egne feller, helt ned til ikonet som avvises med ITMS-90717.

Metoden nedenfor tar for seg disse tre årsakene, ett steg om gangen.

Steg 1: hvordan velge en appidé som kan tjene penger?

Før du skriver en eneste kodelinje, svar skriftlig på tre spørsmål.

For hvem? En bestemt person, med et problem som går igjen. «Folk som sliter med å stå opp» er mer nyttig enn «alle».

Hva gjør appen, i én setning? Trenger du to setninger, er første versjon for stor. De andre funksjonene får vente til ekte brukere ber om dem.

Hvordan tjener den penger? Abonnement, engangskjøp, reklame: bestem deg nå. For en app som brukes jevnlig er abonnement ofte det mest logiske. For et verktøy man bruker av og til, kan engangskjøp forsvares. Den fullstendige sammenligningen står i abonnement eller engangskjøp for en iOS-app.

For å sjekke at en idé interesserer noen før du bruker uker på den, kjør den gjennom de 5 testene i finne en appidé. Og for å skrive den ned holder det med én side: malen står i kravspesifikasjon for en mobilapp.

Ved slutten av dette steget skal du også ha satt opp det tekniske grunnlaget. For en nybegynner er det React Native med Expo, av grunnene nevnt over. Siden React Native og Expo for en mobilapp går nærmere inn på det valget. Avgrensningen av første versjon forklares på siden MVP for en iOS-app.

En god første versjon gjør én ting bemerkelsesverdig godt, ikke tolv ting middels.

Steg 2: hvordan bygge kjernen i appen din?

Bygg bare hovedfunksjonen, og test den på din egen iPhone så fort som mulig. Ikke på skjermbilder, og ikke bare i simulatoren.

Noen regler som har spart meg for mye frem og tilbake:

• Test på den minste og den største skjermen. Min første avvisning fra Apple på Solys skyldtes en velkomstdemo som var umulig å vinne i et vindu mindre enn det på telefonene mine: reviewer testet på en iPad, der iPhone-appen kjører i kompatibilitetsmodus.
• Planlegg for feil. Nettet borte, tillatelse avslått, tom skjerm: hvert tilfelle fortjener en tydelig melding.
• Bruk AI, men les over. Claude eller Cursor skriver raskt, og tar feil med stor selvsikkerhet om Apples regler. Fellene er listet opp i lage en iOS-app med AI.

Dette steget er ferdig når eksterne testere bruker appen via TestFlight, Apples betaverktøy. Alt forklares i TestFlight: teste iPhone-appen din.

Steg 3: hvordan koble på betaling i en iOS-app?

Dette er steget de fleste nybegynnere utsetter, og det er det som avgjør om appen kan tjene noe.

Onboardingen. De første skjermene skal vise verdien av appen før de ber om noe som helst: en vurdering, en tillatelse eller en betaling. Det er også dette Apple sjekker: min andre avvisning på Solys (guideline 5.6.3) skyldtes en forespørsel om vurdering plassert midt i onboardingen.

Paywallen. Abonnementsskjermen må tydelig vise pris, varighet, eventuell prøveperiode og en knapp for å gjenopprette kjøp. De klassiske feilene står i iOS-paywall: 7 nybegynnerfeil.

Abonnementene. Produktene opprettes i App Store Connect. Jeg bruker RevenueCat til å håndtere tilgangsrettigheter, gjenoppretting og oppfølging av inntektene. Siden abonnementer i appen på iOS beskriver hele jobben.

Målingene. Uten målinger vet du ikke hvor folk gir opp. Jeg bruker PostHog til å følge brukerreisen (åpning, fullført onboarding, visning av paywall, kjøp) og Sentry for krasj.

Steg 4: hvordan publisere appen din og bli funnet?

App Store-siden. Navn, undertittel, nøkkelord, skjermbilder, beskrivelse. Det er dette som avgjør om noen laster ned, og om App Store viser deg i søkeresultatene. Siden ASO for App Store forklarer hvordan du jobber med den.

Personvernet. Erklæringene om datainnsamling må stemme med det appen faktisk gjør, og personvernerklæringen din på nett må være oppdatert. Det var nettopp dette som ga Clic en 5.1.1-avvisning.

Innsending til gjennomgang. Legg ved en demokonto hvis appen krever innlogging, og forklar hva reviewer skal teste. Apple sier at de gjennomgår 90 % av innsendingene på under 48 timer. Det er avvisningene som virkelig forlenger tidsplanen. Tidsbruken er beskrevet i behandlingstid på App Store, og hele prosessen på siden publisere en app på App Store.

Og på Google Play? Veien er den samme, med ett ekstra steg. For en personlig konto opprettet etter 13. november 2023 krever Google en lukket test med minst 12 påmeldte testere i 14 dager på rad før lansering i produksjon.

De første brukerne. En publisert app er ikke en app som blir funnet. Snakk om appen der publikummet ditt allerede er, og se på tallene for produktsiden fra første uke.

Hva koster det å lage en app?

Bygger du den selv, er de obligatoriske kostnadene lave. Her er prisene som sto på de offisielle sidene 2. oktober 2026. Tilbudene endrer seg, så sjekk dem før du setter i gang.

Post	Oppgitt pris	Når du betaler
Apple Developer-konto	99 $ per år	For TestFlight og for å publisere
Google Play-konto	25 $, én gang	Når kontoen opprettes
Kompilering og innsending (Expo EAS)	0 $ opptil 15 iOS-builds og 15 Android-builds per måned, deretter 19 $ per måned	Når du kompilerer ofte
Database og kontoer (Supabase)	0 $ opptil 500 MB og 50 000 aktive brukere per måned, deretter fra 25 $ per måned	Når appen vokser
Abonnementer (RevenueCat)	0 $ opptil 2 500 $ i sporet inntekt per måned, deretter 1 %	Når appen selger
Apples provisjon	15 % med Small Business Program, ellers 30 %	På hvert salg gjennom App Store

To presiseringer. Apple-kontoen til 99 $ trenger du ikke for å begynne å kode, bare for TestFlight og publisering: stegene står i Apple-utviklerkonto: pris og registrering. Og påmelding til Small Business Program skjer ikke automatisk: du må søke om det.

Får du appen utviklet, betaler du for utviklertid: en dagspris ganget med et antall dager. Ingen seriøse tall kan gis uten å kjenne omfanget. Kostnadene, gratisnivåene og utgiftene nesten ingen nevner, står i detalj i hva koster en app.

Den største posten står ikke på noen faktura: tiden din.

Hvor lang tid tar det fra idé til App Store?

Det finnes ingen ærlig tidsangivelse uten å kjenne appen og utgangspunktet ditt. Det som er sikkert, er at hvert steg må ha en synlig slutt:

1. Idé: én setning, ett publikum, én inntektsmodell, det tekniske grunnlaget satt opp.
2. Bygging: hovedfunksjonen brukt av testere via TestFlight.
3. Betaling: et vellykket testkjøp, gjenoppretting inkludert.
4. Publisering: appen sendt til Apple, komplett produktside, aldersgrense inkludert.

Har et steg ingen synlig slutt, er det et tegn på at første versjon er for stor.

Et reelt referansepunkt, som verken er et gjennomsnitt eller fulltid: på TradaZen gikk det 26 kalenderdager fra første commit til publisering på App Store. Detaljene står i hvor lang tid tar det å lage en app.

Og etter publiseringen?

En publisert app er en begynnelse. De første bruksmålingene forteller nesten alltid noe ingen hadde forutsett: en skjerm der alle gir opp, en paywall ingen ser, en funksjon folk bruker på en annen måte. Neste versjon bestemmes ut fra disse tallene, ikke ut fra magefølelsen du hadde i starten.

Ofte stilte spørsmål

Er det mulig å lage en app gratis?

Ja, for det meste. Du kan kode, teste på telefonen og kompilere appen uten å betale noe, takket være gratisnivåene i verktøyene. Publisering koster derimot penger: 99 $ per år hos Apple, 25 $ én gang hos Google. Detaljene står i lage en app gratis.

Hva koster det å lage en app?

Bygger du den selv, er de obligatoriske kostnadene bare utviklerkontoene: 99 $ per år for Apple, 25 $ én gang for Google. Verktøyene har gratisnivåer for å komme i gang. Får du den utviklet, betaler du for utviklertid, og prisen avhenger av omfanget.

Hvordan lager man en app på en enkel måte?

Det enkleste er ikke et verktøy, men en bitte liten første versjon: én funksjon, ferdig. For en katalog eller et skjema holder et verktøy uten kode. For en app du skal publisere og selge, skriver AI koden, så lenge du tester hvert steg på en ekte telefon.

Hva er den beste programvaren for å lage en mobilapp?

Det finnes ingen beste programvare i absolutt forstand. For å sette sammen uten kode kan Bubble eller FlutterFlow publisere i butikkene. For å la AI skrive koden brukes Claude Code, Codex eller Cursor sammen med React Native og Expo. Riktig valg avhenger av to ting: om appen skal ligge i butikkene, og om den skal selge et abonnement. Sammenligningen av generatorene står i Lovable, Rork, FlutterFlow.

Kan man lage en app alene, uten å kunne kode?

Ja. Jeg publiserer mine egne apper med React Native, Expo og AI, og hvert steg i denne guiden kan gjøres alene. Det du bør vite: AI skriver koden, men det er du som sjekker. Det kommer alltid et punkt der du må forstå litt av det den har skrevet, særlig for betaling og Apples gjennomgang.

Er det lønnsomt å lage en app?

Ingen kan garantere deg det. Inntekten avhenger ikke av antall nedlastinger, men av hvor mange som betaler og hva som er igjen etter Apples provisjon. Hva som påvirker resultatet, forklares i hvor mye tjener en app.

Hvor lang tid tar det å lage en app?

Det finnes ingen universell tid: alt avhenger av hvor stor første versjon er og hvor mye tid du bruker på den hver uke. Mitt reelle referansepunkt: 26 kalenderdager fra første commit til publisering av TradaZen på App Store.

Hvordan lager man en app til iPhone?

De 4 stegene er de samme, med tre verktøy som er spesifikke for Apple: Apple Developer-kontoen, TestFlight for testerne og App Store Connect for produktsiden og innsending til gjennomgang. Hele løpet står på siden lage en iPhone-app.

Følg denne metoden med iOS Kit

Disse 4 stegene er nøyaktig de samme som i løpet i iOS Kit: velge appen som kan tjene penger, bygge kjernen, koble på pengene, publisere og bli funnet. Du følger dem i ditt eget tempo, med startkoden fra appene mine og Claude Code-skills for hvert steg.

Du kan også følge metoden alene, med guidene det lenkes til i denne artikkelen. Vet du ikke hvilket steg du er på? Den gratis diagnosen viser deg hvor du står, sier hvilket steg du bør ta tak i først, og sender deg sjekklisten min mot avvisninger fra Apple. Ingen kan garantere deg godkjenning fra Apple eller en inntekt. Det metoden garanterer, er at du til enhver tid vet hva som gjenstår.