Hopp til innhold

Teknologi

Teknologi for apputvikling

Valg av teknologi for apputvikling er ikke et smaksspørsmål. Det avgjør hva appen koster å bygge, hva den koster å vedlikeholde, og hvor lett det er å finne utviklere som kan overta den om fem år. Derfor har vi ingen favoritt. Vi bygger i Swift, Kotlin, Flutter og React Native, og velger etter hva appen faktisk trenger.

Denne siden viser hele tech-stacken vår, fra mobil til backend, hosting og verktøyene rundt. Den er skrevet for dere som skal kjøpe en app, ikke for utviklere, men utviklerne deres kan gjerne lese den også.

01

Slik velger vi teknologi for apputvikling, prosjekt for prosjekt

Valget tas i appavklaringen og begrunnes skriftlig i den tekniske anbefalingen. Fem spørsmål avgjør det meste:

  • 01

    Skal appen ut på både iOS og Android samtidig?

    Hvis svaret er ja, trekker det mot
    Flutter eller React Native (én kodebase)
  • 02

    Trenger appen tunge plattformfunksjoner, som Apple Watch, widgets, NFC eller bakgrunnstjenester?

    Hvis svaret er ja, trekker det mot
    Native Swift eller Kotlin
  • 03

    Har dere allerede et webteam som kan React og TypeScript?

    Hvis svaret er ja, trekker det mot
    React Native
  • 04

    Skal appen kjøre på håndterminaler, nettbrett i felt eller enheter styrt med MDM?

    Hvis svaret er ja, trekker det mot
    Native Kotlin
  • 05

    Trenger appen egentlig en butikk, eller holder det med nettleseren?

    Hvis svaret er ja, trekker det mot
    Webapp eller PWA

Bak dette ligger to observasjoner vi tar på alvor. Erik Wendel i Bekk anslår at man sparer nær 45 % av arbeidet med React Native sammenlignet med to native apper, og han peker på at kvalifiserte iOS- og Android-utviklere er svært vanskelige å finne i Norge. Begge deler taler for kryssplattform i de fleste bedriftsapper, og for native bare når appen trenger det.

02

Mobil: Swift, Kotlin, Flutter og React Native

  • 01Swift og SwiftUIfor native iOS. Apples eget språk og rammeverk, og det vi velger når appen skal bruke Apple-funksjoner fullt ut eller brukerne nesten bare har iPhone. Se iOS-apputvikling.
  • 02Kotlin og Jetpack Composefor native Android. Det vi velger for feltapper på robuste enheter, apper med tunge bakgrunnsjobber og enheter styrt med MDM. Se Android-apputvikling. Da DNB i 2026 søkte apputviklere i Bergen, var kravene nettopp Kotlin, Swift, Jetpack Compose, SwiftUI og Kotlin Multiplatform.
  • 03Flutterfor én kodebase til iOS, Android og web. Et rammeverk med åpen kildekode som kompilerer til native kode på hver plattform, støttet og brukt av Google. Coop Norge skrev om appen sin til Flutter allerede i 2019. Flutter er vårt vanligste valg for bedriftsapper der begge plattformer skal ut samtidig. Se Flutter-utvikling.
  • 04React Native med Expo og TypeScriptfor bedrifter som allerede har et React-miljø. AtB-appen i Trøndelag er bygd i React Native og TypeScript, koden er åpen, og den samme koden brukes av FRAM i Møre og Romsdal, Reis Nordland og Svipper i Troms. Se React Native-utvikling.

Forskjellene mellom de to kryssplattformvalgene er små for de fleste apper, og vi har skrevet dem ut i guiden Flutter eller React Native.

03

Web: React, Next.js og PWA

Når appen ikke trenger en butikk, bygger vi den i React og Next.js med TypeScript. En PWA kan legges på hjemskjermen og fungere delvis uten nett, og den oppdateres uten at brukerne må laste ned noe. Portaler, booking, dashbord og interne verktøy er typiske kandidater. Se webapp og PWA og guiden native, hybrid eller webapp.

04

Backend: Node.js, .NET, PostgreSQL, Supabase og Firebase

Appen er halve produktet. Den andre halvparten er backend: databasen, API-et, innloggingen, push-varslene og adminpanelet.

  • 01

    MVP som skal ut på 2–12 uker

    Vi velger
    Supabase eller Firebase
    Hvorfor
    Database, innlogging, filer og push er ferdig satt opp, og prisen starter lavt
  • 02

    Bedriftsapp med egne datamodeller og integrasjoner

    Vi velger
    Node.js/TypeScript eller .NET med PostgreSQL
    Hvorfor
    Full kontroll, standard verktøy som ethvert utviklingsmiljø i Norge kan overta
  • 03

    Eksisterende .NET-miljø hos kunden

    Vi velger
    .NET
    Hvorfor
    Deres egne utviklere kan vedlikeholde og videreutvikle
  • 04

    Sanntid, chat og posisjonsdeling

    Vi velger
    WebSockets eller Supabase Realtime
    Hvorfor
    Oppdateringer uten at appen må spørre serveren hele tiden

Supabase bygger på PostgreSQL, så en MVP som starter der kan vokse uten at databasen må byttes. Alle API-er dokumenteres med OpenAPI, og dere får dokumentasjonen ved overlevering. Mer om dette under backend, API og integrasjoner.

05

Hosting: datasentre i Norge eller EØS

Persondata i appene vi bygger lagres i datasentre i Norge eller EØS. Vi bruker Azure eller AWS avhengig av hva kunden har fra før, med regioner innenfor EØS. Kontoen står i deres navn, og fakturaen for hosting går direkte til dere. Typisk kostnad er 300–5 000 kr/mnd avhengig av trafikk.

KI-funksjoner følger samme regel: modeller kjøres hos leverandører med datasenter i EU/EØS eller på egen infrastruktur, og kundedata brukes ikke til trening. Se KI i app.

06

Bygging, publisering og oppdateringer

Hver gang en utvikler leverer kode, bygges og testes appen automatisk med GitHub Actions. For React Native-apper bruker vi Expos EAS Build og EAS Submit, som kompilerer, signerer og sender appen til butikkene fra skyen. For Flutter og native apper bruker vi fastlane, en åpen kildekode-plattform for å automatisere utrulling til App Store og Google Play.

Testversjoner går ut til dere hver uke via TestFlight på iOS og lukket testing i Google Play på Android. Publiseringen skjer på deres egne kontoer, som beskrevet under publisering i App Store og Google Play.

07

Testing og overvåking

Vi skriver enhetstester for forretningslogikk og UI-tester for de viktigste flytene. I tillegg testes hver versjon manuelt på ekte enheter, både gamle og nye telefoner, fordi emulatorer skjuler feil i kamera, posisjon og push. Universell utforming testes med VoiceOver og TalkBack der kravet gjelder. Se universell utforming av app.

Etter lansering overvåkes appen med krasjrapportering og analyse av oppetid og ytelse i backend. Dere ser tallene selv, og de danner grunnlaget for rapportene i vedlikeholdsavtalene.

08

Sikkerhet

Sjekklisten vår følger OWASP MASVS, Mobile Application Security Verification Standard, en åpen standard for hva en sikker mobilapp må oppfylle. I praksis betyr det kryptering i transitt og i ro, nøkler i Keychain og Keystore, avhengighetsskanning i hver bygging, og kodegjennomgang før koden slås sammen med hovedgrenen. Detaljene står under app-sikkerhet og personvern.

09

Design: Figma

Alt design gjøres i Figma, fra skisser til klikkbar prototype og designsystem. Dere ser og kommenterer i nettleseren, og filene er deres. Se appdesign og UX.

10

Hva dette betyr for dere

Alle verktøy i denne tech-stacken er enten åpen kildekode eller standardtjenester med vanlige lisenser. Ingen av dem binder dere til oss. Bytter dere leverandør, finner den nye utviklerne som kan Flutter, React Native, Swift og Kotlin, og verktøy de allerede bruker.

Hvilken teknologi appen deres bør bygges i, avgjør vi sammen i en appavklaring, og prisen blir den samme uansett rammeverk innenfor samme omfang. Se priser på apputvikling og prosessen under slik jobber vi.

Neste steg

Usikker på teknologivalget?

Skriv tre setninger om hva appen skal gjøre og hvem som skal bruke den. Vi svarer med en anbefaling om teknologi, et prisspenn og et forslag til neste steg innen én virkedag.

Eller skriv til[email protected]

Kilder