App-utvikler i 2026: velg riktig løsning, unngå dyre feil og behold kontrollen

En god app-utvikler hjelper deg først å avgjøre om du trenger en app. Mange bedrifter klarer seg med en nettapp. Velger du app, må utviklerkontoene stå i bedriftens navn. Du må også budsjettere for årlige oppdateringer, fordi Google Play krever API-nivå 36 fra 31. august 2026. Apper som bruker internett, må dessuten oppfylle norske krav til universell utforming.

Hva gjør en app-utvikler, og trenger du egentlig en app?

En god app-utvikler gjør mer enn å skrive kode. Utvikleren finner ut om problemet ditt krever en app i App Store og Google Play, eller om en nettløsning holder. For de fleste småbedrifter er svaret en nettløsning. En app er riktig når kundene skal bruke den ofte, når du trenger push-varsler eller tilgang til kamera, GPS, Bluetooth eller frakoblet bruk, eller når appen er selve produktet.

Apputvikling består av mye mer enn selve byggingen. Du trenger kartlegging og design, et baksystem (server, database og innlogging) og integrasjoner mot for eksempel kassasystem, CRM eller betaling. Etterpå kommer publisering i appbutikkene og vedlikehold hvert år. Det vi ser oftest, er at bedrifter budsjetterer for byggingen, men glemmer at en app aldri blir «ferdig». Både Apple og Google endrer kravene jevnlig, og en app som ikke oppdateres, blir etter hvert usynlig eller kan ikke lenger få oppdateringer.

Et viktig poeng mange overser: Innhold som ligger inne i en app, blir ikke indeksert av Google og vises ikke i AI-svarene øverst i søkeresultatet. Skal kunder finne deg via Googles AI-oversikter og AI-søk, er det nettsiden som gjør jobben. En app skal derfor komme i tillegg til nettsiden, ikke erstatte den.

Native app, kryssplattform eller nettapp – hva bør du velge?

Velg nettapp (PWA) hvis du vil teste en idé billig. Velg kryssplattform (Flutter eller React Native) hvis appen skal ligge i appbutikkene med én felles kodebase. Velg native app (Swift for iOS, Kotlin for Android) bare når ytelse eller dyp tilgang til maskinvaren er avgjørende. Valget påvirker pris, utviklingstid og hvor mange utviklere du må ha i mange år framover.

Vi anbefaler å starte med en webapplikasjon hvis du er usikker på om kundene vil bruke løsningen. Da tester du behovet uten å vente på godkjenning i appbutikkene. Mange behov som virker som app-behov, for eksempel timebestilling, løses dessuten bedre med et ferdig bookingsystem som du kobler på nettsiden. Native app er riktig for et lite mindretall av prosjektene. Vi mener du bør kreve en skriftlig begrunnelse hvis en leverandør foreslår to native kodebaser til en vanlig bedriftsapp.

Hva koster det å utvikle en app i 2026?

Det finnes ingen seriøs fastpris for apputvikling. Kostnaden avgjøres av hvor mange plattformer du bygger for, hvor mye av baksystemet som lages fra bunnen, hvor mange integrasjoner du trenger og hvor grundig du designer og tester. Avgiftene til plattformene er derimot faste og lave. Det som koster, er utviklingstimene og driften i årene etter lansering.

Medlemskapet hos Apple koster 99 USD per år. Det er ikke en kostnad du kan droppe: lar du medlemskapet løpe ut, blir appene dine fjernet fra salg i App Store. Når du sammenligner tilbud, bør du derfor regne ut totalkostnaden for tre år, ikke bare prisen for utviklingen. En leverandør med lav pris på bygging og høy timepris for vedlikehold blir ofte den dyreste til slutt.

Her er en regel som kan spare deg for mye penger: Selger du fysiske varer eller tjenester som brukes utenfor appen, for eksempel mat, timer eller billetter, kan du ta betalt med egne løsninger. Da slipper du provisjonen til Apple og Google. Bruker du Vipps for bedrifter, skal du integrere mot ePayment-API-et. Det gamle eCom-API-et er avviklet og skal ikke brukes i nye prosjekter. Digitalt innhold og abonnement som brukes inne i appen, må normalt selges med kjøp i appen, og da tar appbutikkene provisjon.

Hvilke krav må appen oppfylle i Norge?

En norsk bedriftsapp må oppfylle fire typer krav: universell utforming, personvern, Googles krav til API-nivå og Apples regler for kontoer og gjennomgang. Har du ikke tenkt på disse fra starten, kan det gi forsinket lansering, avvisning i appbutikken eller pålegg fra tilsynet.

Universell utforming gjelder også apper

Uu-tilsynet skriver at apper omfattes av kravene til universell utforming hvis de trenger tilkobling til internett minst én gang etter nedlasting. Det gjelder nesten alle bedriftsapper. Ifølge tilsynet er seks av kravene unntatt for apper, og private virksomheter må oppfylle 29 minstekrav i WCAG. Kravene gjelder både private og offentlige virksomheter. Les mer om kravene i guiden vår om universell utforming. Skriv inn i kontrakten at leverandøren skal teste mot disse kravene underveis, ikke bare rett før lansering.

Personvern og samtykke

Apple krever at du oppgir hvilke data appen samler inn (personvernetiketten i App Store). Google krever det samme i skjemaet om datasikkerhet i Play Console. Begge krever lenke til en personvernerklæring. Den vanligste feilen er at analyse- og annonseverktøy som er bygget inn i appen, sender data før brukeren har samtykket. Samtykkereglene i ekomloven og GDPR gjelder for lagring av og tilgang til informasjon på telefonen, akkurat som for informasjonskapsler på nettsider.

Googles krav til API-nivå – nytt fra 31. august 2026

Fra 31. august 2026 må nye apper og oppdateringer bygges for Android 16 (API-nivå 36) for å kunne sendes inn til Google Play. Apper som allerede er publisert, må minst bygges for Android 15 (API-nivå 35). Ellers blir de ikke tilgjengelige for nye brukere med nyere Android-versjoner. Fristen flyttes hvert år, og derfor er årlig vedlikehold et krav, ikke noe du kan velge bort.

Testkravet for nye Google-kontoer

Personlige utviklerkontoer som er opprettet etter 13. november 2023, må gjennomføre en lukket test med minst 12 testere som har vært med sammenhengende i 14 dager før de får publisere. Kravet gjelder ikke organisasjonskontoer. Det er en grunn til å registrere kontoen i bedriftens navn fra dag én. Hvis du likevel må bruke en personlig konto, bør du rekruttere flere enn 12 testere. Faller noen fra, kan du havne under grensen, og da gjelder ikke de 14 dagene lenger som sammenhengende.

Slik går du fram når du skal utvikle en app

Gå gjennom stegene i denne rekkefølgen. De første fire koster lite eller ingenting, men de bestemmer hvor mye resten koster.

• 1. Formuler ett problem appen skal løse og ett måltall, for eksempel antall gjenbestillinger per måned. Klarer du ikke det, er du ikke klar for å bestille.
• 2. Bestill D-U-N-S-nummer til bedriften. Det er gratis, men kan ta litt tid. Både Apple og Google bruker det når de verifiserer organisasjonskontoer.
• 3. Opprett Apple Developer-kontoen og Google Play-kontoen som organisasjon, i bedriftens navn og med en felles e-postadresse som ikke er knyttet til én ansatt. Gi byrået tilgang som teammedlem.
• 4. Lag en klikkbar prototype og test den med 5–10 ekte kunder før det skrives kode.
• 5. Be om tilbud med samme kravspesifikasjon fra minst to leverandører. Krev at drift og vedlikehold i tre år er priset.
• 6. Skriv inn i kontrakten at du eier kildekoden, at den ligger i et kodelager du kontrollerer, og at leverandøren følger kravene til universell utforming.
• 7. Bygg en første versjon med bare kjernefunksjonene, sett opp måling med samtykke, og lanser.
• 8. Legg inn en fast oppdatering i året i budsjettet, knyttet til nye krav til API-nivå hos Google og nye iOS-versjoner.

Apputvikling i Oslo – spiller det noen rolle hvor app-utvikleren sitter?

Det betyr mindre enn mange tror. Det som avgjør om prosjektet lykkes, er at leverandøren kan norske krav, skriver kontrakter etter norsk rett og har folk du kan møte i workshops. Om app-utviklerne sitter i Oslo, Bergen eller Trondheim, betyr lite. Kartlegging og brukertester er nyttigst ansikt til ansikt. Resten av arbeidet foregår uansett i digitale verktøy.

Leter du etter apputvikling i Oslo, bør du stille de samme spørsmålene som til alle andre leverandører. Hvem eier koden og kontoene? Hvem gjør selve utviklingen, og er noe satt ut til underleverandører? Hva koster vedlikeholdet per år? Kan de vise apper de fortsatt drifter etter mer enn to år? Et byrå som ikke vil svare konkret på det siste spørsmålet, har sannsynligvis ikke erfaring med drift over tid. Box holder til i Bergen og jobber med kunder i hele landet.

Når en app ikke er riktig løsning

En app er feil valg når kundene bruker deg sjeldnere enn én gang i måneden, når alt innholdet egentlig er informasjon, eller når hovedgrunnen er at konkurrenten har en app. Få kunder laster ned en app for å bruke den én gang, og innholdet blir ikke synlig i søk.

• Du har ikke budsjett til vedlikehold hvert år. En app som ikke oppdateres, faller ut av Google Play for nye brukere.
• Behovet er intern arbeidsflyt. Da er en nettløsning, en integrasjon eller automatisering med KI ofte bedre og billigere.
• Du vil samle kundedata og følge opp kunder. Et CRM-system som HubSpot koblet til nettsiden gir mer for pengene enn en egen app.
• Du vil først og fremst bli funnet av nye kunder. Det skjer på nettsiden og i søk, ikke i App Store.

Vi fraråder også å utvikle en app for å «digitalisere» en prosess som ennå ikke er kartlagt. Begynn med prosessen, slik vi beskriver i artikkelen om hva digitalisering betyr i praksis, og vurder app når du vet hva som skal forenkles.

Hvilke fallgruver er vanligst i app-prosjekter?

De dyreste feilene handler sjelden om koden. De handler om eierskap, måling og planlegging som ikke ble avklart før kontrakten ble signert.

• Kontoene står i feil navn. Utviklerkontoene er registrert på byrået eller på en ansatt som slutter. Da mister du kontrollen over appen.
• Kildekoden ligger bare hos leverandøren. Uten eget kodelager står du uten noe hvis leverandøren går konkurs.
• Ingen plan for API-kravene. Google flytter kravet hvert år, og en glemt oppdatering gjør appen usynlig for nye brukere med nyere telefoner.
• Måling uten samtykke, eller ingen måling i det hele tatt. Da vet du ikke om appen gir noe tilbake, eller du bryter reglene.
• For mange funksjoner i første versjon. Det forsinker lanseringen og gjør hver oppdatering dyrere.

Måling er et punkt vi ser feile overalt, ikke bare i apper. Kampanjer som skal skaffe nedlastinger, er avhengige av at hendelsene faktisk registreres riktig.

Da Box gjennomgikk sporingsoppsett hos nye kunder, hadde 8 av 10 kontoer feil i konverteringssporingen — dobbelttelling, manglende hendelser eller samtykkeoppsett som blokkerte data.

Vårt råd er å definere de viktigste hendelsene i appen, som registrering, kjøp og booking, allerede i kravspesifikasjonen. Da må leverandøren levere målingen som en del av produktet, ikke som noe som legges til etterpå.

Hva kan AI gjøre i apputvikling i 2026?

AI kutter tid på repeterende koding, testing og prototyper, men erstatter ikke arkitektur, sikkerhet og kvalitetskontroll. Verktøy som lovable kan lage en fungerende prototype på noen timer. Det er nyttig for å teste en idé, men ikke det samme som en app som tåler ekte brukere, betalinger og persondata.

Vi ville ikke sendt kode som er generert av AI, ut i produksjon uten at et menneske har gått gjennom den. Det gjelder særlig innlogging, betaling og behandling av personopplysninger. Inne i selve appen er det mest vanlige å bruke AI til kundestøtte. Vurderer du det, kan du lese om hva som fungerer i en chatbot for norske bedrifter. Bruker appen AI til å ta beslutninger om personer, må du også følge med på hvordan EUs AI-forordning blir innført i Norge. Vær kritisk til leverandører som kaller alt «AI-drevet» uten å forklare hvilken modell som brukes, hvor dataene behandles og hva det koster per bruker.

Lurer du på om ideen din bør bli en app, en nettløsning eller noe helt annet, kan du ta en uforpliktende prat med Box sin avdeling for teknologi og AI. Vi sier fra hvis vi mener du er bedre tjent med noe annet enn en app. Se også hvordan Box jobber med nettsider.