Apps til iPhone og iPad

iOS er styresystemet på iPhone, og iOS-app-udvikling er det håndværk, der skaber de apps, folk henter i App Store. Arbejdet dækker brugerfladen, logikken bag den, kommunikationen med en server og selve udgivelsen, hvor Apple gennemgår appen, før den bliver tilgængelig. iPad kører iPadOS, som bygger på samme grundlag, så en app kan som regel laves til begge fra samme kode.

Apples værktøjer er Xcode som udviklingsmiljø, Swift som programmeringssprog og SwiftUI til brugerfladen. Med dem følger appen automatisk de konventioner, brugerne kender fra resten af telefonen: knapper, navigation, skrifttyper og bevægelser opfører sig, som de forventer. Det er en stor del af grunden til, at native apps føles rigtige i hånden.

En iOS-app består sjældent kun af det, man ser på skærmen. Bag den ligger typisk login, en database, push-beskeder og måske betaling, og hver del skal fungere, når forbindelsen er dårlig, batteriet er lavt, eller brugeren skifter app midt i et flow. Det er den del, der skiller en app, der holder til hverdagen, fra en demo.

Jeg har udviklet software siden 2010 og skriver selv koden i de projekter, jeg tager. Du taler med den person, der bygger appen, og ikke med en projektleder imellem.

Native betyder, at appen er bygget specifikt til iOS i Swift. Cross-platform betyder, at én kodebase, for eksempel i React Native eller Flutter, bliver til apps på både iPhone og Android. Begge veje er fornuftige, og valget afhænger af, hvem appen er til, og hvad den skal kunne.

Native er det stærke valg, når brugerne primært har iPhone, når appen skal bruge telefonens funktioner som kamera, placering, widgets eller Apple Pay, og når den skal føles helt som en del af iOS. Nye funktioner fra Apple kan tages i brug, så snart de bliver frigivet, uden at vente på, at et cross-platform-værktøj følger med.

Cross-platform giver mening, når appen skal på iPhone og Android fra dag ét med samme budget, og når den mest viser data fra en server. Prisen er et ekstra lag mellem appen og telefonen, som kan drille, når appen skal noget, værktøjet ikke understøtter.

Jeg bygger native til iOS. Skal I have Android med fra start, siger jeg det ærligt, hvis en cross-platform-løsning passer bedre til jeres situation. Mange starter med iPhone, lærer af brugerne og bygger Android-versionen bagefter, når de ved, hvad appen skal kunne.

Det første skridt er at afgrænse første version. De fleste idéer indeholder flere funktioner, end der er brug for på dag ét, og en app, der gør én ting godt, kommer hurtigere i hænderne på brugerne end en, der gør ti ting halvt. Vi skriver ned, hvad første version skal kunne, og lige så vigtigt, hvad den ikke skal.

Derefter bygger jeg appen i bidder. Hver bid bliver sendt til TestFlight, Apples system til testversioner, så du og et par udvalgte brugere kan installere den på jeres egne telefoner. Feedback fra rigtige telefoner fanger ting, en skærm på et møde aldrig viser.

Når appen er klar, skal den igennem Apples gennemgang. Apple tjekker blandt andet, at appen virker, at den beskriver sine data ærligt, og at den overholder reglerne for køb i appen. Jeg forbereder App Store-siden, privatlivsoplysningerne og en testbruger til gennemgangen, så appen ikke bliver afvist på formalia.

Efter lanceringen kommer der en ny iOS-version hvert år, og Apple kræver løbende, at apps bliver bygget med nyere værktøjer. En app skal derfor vedligeholdes, også selvom den ikke får nye funktioner. Det tager vi med i planen fra start.