En virksomhet som vil nå flest mulig brukere, bør kanskje starte med Android. En amerikansk tjeneste kan derimot tape kunder hvis den undervurderer iOS. Begge påstandene kan være riktige, og nettopp derfor blir jakten på «den beste apputvikleren» ofte for enkel.
Valget bør begynne med brukerne, ikke med utviklernes favorittspråk eller hvilken telefon ledelsen har på skrivebordet. Globalt sto Android for omtrent 67,99 prosent av mobil webtrafikk i mai 2026, mens iOS sto for rundt 32,01 prosent. For en internasjonal app er det vanskelig å overse Android. I USA var bildet motsatt i juni samme år: Android hadde 41,62 prosent, noe som betyr at iOS var den største plattformen der.
Det er et konkret eksempel på hvorfor markedet må kartlegges før stillingsannonsen skrives. En app for et globalt publikum trenger kanskje solid Android-kompetanse først. En tjeneste rettet mot amerikanske forbrukere, særlig i segmenter der iPhone står sterkt, kan ha mer å hente på en utvikler med dyp iOS-erfaring. En prosentandel forteller likevel ikke alt. Betalingsvilje, demografi, maskinvare, nettdekning og hvilke funksjoner brukerne faktisk benytter, kan være viktigere enn den samlede markedsandelen.
Se etter plattformkunnskap som er fersk nok
En utvikler som kan «iOS» eller «Android», er ikke nødvendigvis oppdatert på dagens krav. På iOS-siden bør kandidaten beherske Xcode 26, Swift 6.2 og iOS 26 SDK. Fra 28. april 2026 krever Apple Xcode 26 eller nyere for nye opplastinger. Det gjør verktøykjeden til mer enn en teknisk detalj: En utvikler som ikke følger med på slike endringer, kan forsinke lanseringen eller oppdage kompatibilitetsproblemer for sent.
For Android bør kandidaten kunne arbeide med Android 16 og API-nivå 36. Fra 31. august 2026 må nye apper og oppdateringer i Google Play rette seg mot API 36 eller høyere. Spør derfor ikke bare hvor mange år personen har jobbet med plattformen. Be heller om en konkret forklaring på hvordan vedkommende håndterer nye SDK-krav, bakoverkompatibilitet, tillatelser, testing på ulike enheter og endringer i appbutikkene.
Det er ofte i slike svar forskjellen mellom erfaring og rutine blir synlig. En utvikler kan ha bygget mange apper, men likevel være vant til en eldre arbeidsmåte. Det er litt som å ansette en erfaren bilmekaniker som helst vil reparere dagens biler med verktøy fra forrige tiår.
Språket på CV-en sier mindre enn arbeidsprøven
Kotlin er et naturlig krav i mange Android-prosjekter, mens Swift står sentralt på iOS. Likevel er det risikabelt å bruke programmeringsspråket som et raskt filter. I en stor utviklerundersøkelse fra 2025 oppga 10,8 prosent at de brukte Kotlin, 5,9 prosent Dart og 5,4 prosent Swift. Tallene beskriver ikke kvalitet, og de sier heller ikke hvor dyktig en bestemt kandidat er.
En kort arbeidsprøve kan gi mer informasjon enn en side med teknologier. Be kandidaten skissere hvordan en app skal hente data når forbindelsen er ustabil, hvordan en innlogging skal beskyttes, eller hvordan en funksjon skal testes før lansering. Da ser du om personen tenker på feilhåndtering, personvern, ytelse og brukeropplevelse – ikke bare på hvordan skjermbildet skal se ut.
Porteføljen bør også undersøkes med en viss skepsis. Hva gjorde utvikleren selv? Hvilke deler ble levert av et team? Ble appen vedlikeholdt etter lansering? En app som fungerer i en demonstrasjon, er ikke det samme som en app som tåler tusenvis av brukere, appoppdateringer og uforutsigbare nettverk.
Når ett team skal bygge begge appene
Cross-platform-utvikling kan være fornuftig når produktet skal lanseres på iOS og Android samtidig, og når funksjonene i hovedsak er like. React Native er nå en aktuell kandidat for slike team og ble i april 2026 vurdert som et anbefalt standardvalg for cross-platform mobilutvikling i en bred teknologivurdering.
Det betyr ikke at React Native automatisk er riktig. Komplekse animasjoner, avanserte kamera- og Bluetooth-funksjoner, krevende bakgrunnsprosesser eller svært plattformspesifikk design kan gjøre native-utvikling mer hensiktsmessig. Et team som lover én kodebase, lav kostnad og identisk opplevelse overalt, bør derfor få flere oppfølgingsspørsmål. Besparelsen kan forsvinne hvis utviklerne stadig må skrive egne native-løsninger for å håndtere forskjeller mellom plattformene.
En god cross-platform-utvikler bør forstå både rammeverket og plattformene under. Ellers blir teamet stående fast når en feil bare oppstår på bestemte iPhone-modeller eller Android-enheter. Da hjelper det lite at den første prototypen ble ferdig på rekordtid.
Vurder samarbeidet, ikke bare koden
Apputvikling er sjelden en oppgave som kan isoleres fra resten av virksomheten. Utvikleren må kunne stille ubehagelige spørsmål om uklare krav, oppdage at en ønsket funksjon skaper personvernproblemer og forklare tekniske kompromisser uten å gjemme seg bak fagspråk.
I intervjuet kan du derfor gi kandidaten et ufullstendig produktforslag. Se hva personen spør om før løsningen begynner å ta form. Hvem er brukeren? Hva skjer uten nett? Hvilke data lagres? Hva må være klart ved første lansering, og hva kan vente? En kandidat som bare begynner å snakke om rammeverk, har kanskje hørt mer etter teknologien enn etter problemet.
For små selskaper er det ofte klokere å ansette én erfaren utvikler som kan ta tekniske beslutninger og samarbeide tett med design og produkt, enn flere billige ressurser som bare utfører oppgaver. For større team kan spesialisering være nødvendig, men da må ansvaret mellom iOS, Android, backend, testing og produktledelse være tydelig.
Be om realistiske estimater. Spør hva som kan gå galt. Finn ut hvordan kandidaten følger opp en app etter lansering, når krasjrapporter, dårlige anmeldelser og nye operativsystemversjoner begynner å dukke opp. Det er i denne fasen mange prosjekter blir dyrere enn planlagt – ikke fordi utviklerne mangler talent, men fordi ingen tok ansvar for alt som skjer etter at appen først ble godkjent.