Skal du lage en app som skal fungere på både iPhone og Android, er det første valget teknisk, men konsekvensene er økonomiske. Velger du å bygge to separate apper, eller én kodebase som dekker begge? Svaret påvirker prisen, tiden det tar, og hvor mye du må bruke på vedlikehold i årene etterpå.
Her er hvordan vi tenker om det, og hvordan et appprosjekt faktisk forløper fra idé til lansering.
Native, kryssplattform eller webapp
En native app er skrevet spesielt for én plattform, i Swift for iOS og Kotlin for Android. Det gir best mulig ytelse og full tilgang til alt telefonen kan, og nye funksjoner i operativsystemet er tilgjengelige fra dag én. Ulempen er at du bygger og vedlikeholder to apper. Hver endring må gjøres to ganger, og over tid er det der kostnaden ligger.
Kryssplattform betyr at du skriver koden én gang og kjører den begge steder. React Native er det vi bruker mest. Du deler det aller meste av koden, og de delene som må være plattformspesifikke kan fortsatt skrives native der det trengs. For de fleste forretningsapper er forskjellen i opplevd ytelse liten, mens forskjellen i kostnad er betydelig. Det er derfor dette er standardvalget vårt med mindre noe taler imot.
En webapp er ikke en app i det hele tatt, men en nettside bygget for å oppleves som en. Den slipper app-butikkene, kan oppdateres når som helst, og fungerer på alt som har nettleser. Til gjengjeld får du ikke plass i App Store, begrenset tilgang til maskinvare, og push-varsler som fungerer ujevnt. Skal løsningen brukes på kontoret eller i nettleseren uansett, er dette ofte det rimeligste og raskeste alternativet. Vi har skrevet mer om avveiningen i native, hybrid eller webapp.
Når native faktisk er nødvendig
Det finnes tilfeller der kryssplattform ikke holder, og de er greie å kjenne igjen på forhånd.
Apper som behandler video eller lyd i sanntid, tunge spill, eller løsninger som bruker avansert kamerabehandling og maskinlæring på enheten, drar reell nytte av native. Det samme gjelder hvis appen er helt avhengig av en ny plattformfunksjon som nettopp er lansert, eller hvis den skal ha omfattende integrasjon med klokke, widgets og andre deler av økosystemet.
For en app som viser data, tar imot innspill fra brukeren, sender det til en server og varsler når noe skjer, som er den store majoriteten av forretningsapper, er kryssplattform riktig valg.
Slik forløper et prosjekt
Vi starter med å forstå hva appen skal løse og for hvem. Det høres selvsagt ut, men det er her de dyre feilene gjøres. En app som bygges på antakelser om hvordan brukerne jobber, må ofte bygges om når den møter virkeligheten.
Deretter lager vi en klikkbar prototype. Den ser ut som den ferdige appen og kan navigeres, men har ingenting bak seg. Her avgjøres struktur, navigasjon og design, og endringer koster minutter framfor dager. Prototypen er også det du kan vise fram internt eller til investorer før noe er bygget. Du kan lese mer om hvordan vi jobber med prototyper.
Så bygger vi, og vi bygger i den rekkefølgen som gir deg noe brukbart tidligst mulig. Målet for første versjon er ikke å ha alt, men å ha nok til at appen kan tas i bruk av ekte brukere. Det er først da du lærer hva som faktisk trengs videre. Denne tilnærmingen er kjernen i MVP-tankegangen.
Testing skjer underveis, ikke som en fase på slutten. Lansering i App Store og Google Play håndterer vi, inkludert kontoene, butikkoppføringene og Apples vurderingsprosess, som er det leddet som oftest overrasker folk med hvor lang tid det kan ta.
Det som kommer etter lansering
En app er ikke ferdig når den er publisert. Apple og Google slipper nye versjoner av operativsystemene hvert år, og begge krever jevnlig at apper bygges mot nyere versjoner for å få bli værende i butikken. En app som ikke røres på to år, slutter etter hvert å fungere.
Dette er den delen av kostnaden folk glemmer når de budsjetterer. Regn med en løpende post til vedlikehold, ikke bare en engangssum til utvikling. Til gjengjeld er det også her du får mest igjen for pengene, fordi du nå endrer basert på hva brukerne faktisk gjør framfor hva dere trodde de ville gjøre.
Sikkerhet er ikke noe du legger på til slutt
Behandler appen personopplysninger, gjelder personvernforordningen, og da må sikkerhet inn i arkitekturen fra start. I praksis betyr det kryptert overføring, gjennomtenkt håndtering av innlogging og tokens, og at sensitive data ikke lagres lokalt på telefonen uten grunn.
Begge app-butikkene krever dessuten at du er åpen om hvilke data du samler inn. Apple krever en utfylt personvernetikett, og mangelfulle svar er en vanlig årsak til at apper blir avvist ved innsending.
Hva koster det?
Det avhenger nesten utelukkende av omfang, ikke av timepris. En fokusert første versjon med innlogging, noen skjermbilder og en kobling mot et eksisterende system er et helt annet prosjekt enn en plattform med betaling, sanntidsdata og administrasjonsgrensesnitt.
Du får et grovt estimat for ditt eget prosjekt i priskalkulatoren, og en mer utfyllende gjennomgang i artikkelen om hva apputvikling koster i Norge.
Vil du diskutere ideen din med noen som har bygget dette før? Se hva vi gjør innen apputvikling, eller ta kontakt for en uforpliktende prat.