Sådan bygger du en mobilvenlig webapp

En mobilvenlig webapp er et website, der fungerer som en app på en telefon: den passer til den smalle skærm, har store berøringsmål, indlæses hurtigt på mobildata og kan føjes til startskærmen som en progressiv webapp (PWA). For de fleste nye apps er det den praktiske første version — én kodebase, ét link, ingen store-godkendelse. Den har dog reelle grænser, især omkring notifikationer på iPhone og dyb adgang til enheden, og denne guide er ligefrem om, hvornår du har brug for en native app i stedet.

Tre måder at være „på mobil“

En PWA er en responsiv webapp med et par ekstra funktioner, så du behøver ikke vælge mellem de to første. Byg responsivt først, og gør den derefter installerbar. For en dybere sammenligning, se native vs. progressive webapps.

Hvad webapps kan og ikke kan på telefoner

Browsere kan mere, end mange tror:

• Kamera og fotoupload, via almindelige filinput.
• Lokation, med brugerens tilladelse.
• Installation på startskærmen med et ikon og fuldskærmsstart.
• Offlinebrug, ved at cache sider og data med en service worker (et baggrundsscript, browseren kører for dit site).
• Push-notifikationer — med et forbehold på iPhone. Apples WebKit-team siger, at web push kom til iOS og iPadOS 16.4 for webapps føjet til startskærmen. Brugerne skal installere appen først og derefter tillade notifikationer.

Det, hvor native stadig vinder:

• Dybe enhedsfunktioner som baggrundslokation, Bluetooth-tilbehør, sundhedsdata og widgets på startskærmen — understøttelsen i browseren er begrænset eller varierer på tværs af platforme.
• Opdagelse i app-butikken. Hvis folk søger efter dig i butikken, skal du være der.
• Tungt offlinearbejde, som store datasæt, der synkroniseres i baggrunden.
• Ydelseskritisk grafik, som krævende spil.

Hvis ingen af disse er centrale for din app, vil en webapp sandsynligvis tjene dig godt.

Design til telefoner først

Design telefonlayoutet først, og lad det udvide sig til større skærme; det omvendte giver typisk trange telefonskærme.

Layout

• Én kolonne på små skærme. Sidebjælker bliver til en bundbjælke eller en menu.
• Ingen vandret scroll. Brede tabeller bliver til kort, eller de scroller inde i deres egen container.
• Læsbar tekst uden zoom — brødtekst omkring 16 px.

Berøring

• Store tryk-mål. Omkring 44 × 44 pixels er et almindeligt minimum. Lad der være plads mellem dem.
• Primære handlinger inden for tommelfingerens rækkevidde, nær bunden af skærmen på høje telefoner.
• Ingen funktioner, der kun virker ved hover. Tooltips og menuer, der dukker op ved hover, findes ikke på touchskærme.
• Det rigtige tastatur. E-mailfelter skal åbne e-mailtastaturet, telefonfelter talblokken. Bed om de korrekte input-typer.

Hastighed

• Små billeder i fornuftige størrelser, indlæst når de kommer ind i synsfeltet.
• Færre tunge biblioteker. Hvert af dem tilføjer downloadtid på mobildata.
• Skeleton-skærme eller tydelige indlæsningstilstande, så appen aldrig ser frossen ud.

Sikre områder og adresselinjen

På moderne telefoner kan indhold ende under hakket eller hjemmeindikatoren, især i en installeret fuldskærmsapp. Bed om padding for sikre områder. Vær også opmærksom på layouts i fuld højde, der hopper, når browserens adresselinje vises og forsvinder.

At gøre den installerbar (PWA)

For at kunne installeres skal en webapp have:

1. Et web app manifest — en lille fil med appens navn, korte navn, ikoner, temafarve og hvordan den skal åbne (typisk fuld skærm, „standalone“).
2. Ikoner i de størrelser, platformene forventer, inklusive ét der passer til Apple-enheder.
3. HTTPS, som enhver ordentligt hostet app allerede har.
4. En service worker, hvis du vil have offlinestøtte eller push.

Fortæl derefter brugerne, hvordan de installerer. Android-browsere tilbyder typisk en installationsprompt eller et menupunkt; på iPhone er det Del-knappen og derefter „Føj til hjemmeskærm“. En kort „Installér denne app“-note med de trin hjælper meget.

Offline-understøttelse er der, PWA'er bliver komplicerede. At cache appens sider, så den åbner uden forbindelse, er ligetil. At lade folk ændre data offline og synkronisere dem senere er reelt arbejde — bed kun om det, hvis dine brugere virkelig har brug for det.

En første prompt, der virker

Byg en webapp til vores rengøringsteam, så de kan se dagens opgaver og markere dem som udført. Design til telefoner først: én kolonne, store tryk-mål, hovedhandlingsknappen fast nær bunden, ingen kontroller, der kun virker ved hover, ingen vandret scroll, og korrekte tastaturer til telefon- og e-mailfelter. Hver opgave viser adressen (tryk for at åbne i kort), kundens telefonnummer (tryk for at ringe), en tjekliste og en knap „Markér færdig“, der kan tage et foto. Ledere logger ind på en laptop for at tildele opgaver; på en bred skærm vises en tabel i stedet for kort. Gør det til en installerbar PWA med et manifest, ikoner og standalone-visning, og cache app-skallen, så den åbner uden signal. Gem data i en database.

Byggetrin

1. Byg telefonlayoutet først med eksempeldata, og tjek det i en forhåndsvisning i telefonstørrelse.
2. Test på rigtige telefoner — mindst én iPhone og én Android, hvis dine brugere har begge. Emulatorer overser ting som tastaturet på skærmen, der dækker inputfelter.
3. Gå den primære opgave igennem med én tommelfinger. Hvis noget kræver to hænder eller zoom, så ret det.
4. Tilføj manifestet og ikonerne, og installér derefter appen på begge platforme og tjek ikon, navn og splash.
5. Beslut dig for offline. Start med „åbner uden signal og viser en tydelig besked“; tilføj offline-redigering kun, hvis det er nødvendigt.
6. Tjek hastigheden på en langsom forbindelse. Din browsers udviklerværktøjer kan simulere den.
7. Tilføj notifikationer til sidst, hvis overhovedet — og planlæg et e-mail-alternativ til brugere, der ikke installerer.

Almindelige fejl

• Kun at designe på en stor skærm. Tjek hver skærm i telefonbredde, mens du bygger.
• Tabeller der løber ud over kanten. Gør rækker til kort på små skærme.
• Små tryk-mål og links tæt på hinanden.
• Formularer der kæmper med tastaturet — forkerte input-typer, felter skjult bag tastaturet, intet „næste“-flow.
• At antage, at iPhone-push virker i browserfanen. Den kræver, at appen er installeret på startskærmen.
• At love en App Store-app, du ikke kan levere. Hvis butikken betyder noget, så planlæg for den særskilt.
• At pakke et website ind og kalde det en app. Apples App Review Guidelines kræver apps, der går ud over en genpakket hjemmeside; en tynd indpakning risikerer afvisning.

Hvornår du har brug for en native app

Gå native (eller planlæg en native version efter webappen), når:

• Tilstedeværelse i butikken er den måde, kunder finder dig på.
• Du er afhængig af baggrundslokation, Bluetooth, sundhedsdata, widgets eller andre enhedsfunktioner, som browsere ikke tilbyder pålideligt.
• Din app skal fungere fuldt offline i lange perioder.
• Dine brugere forventer det — nogle målgrupper bruger simpelthen ikke noget, der ikke er i butikken.

Udgivelse i butik har sine egne omkostninger og trin. Fra september 2026 koster Apples udviklerprogram 99 US-dollar om året, og en Google Play-udviklerkonto koster en engangsbetaling på 25 US-dollar, ifølge deres egne sider, og hver udgivelse går igennem godkendelse. Mange teams starter med en mobilvenlig webapp for at bevise, at folk vil have produktet, og investerer derefter i native, når de ved det. Sådan bygger du en app med AI dækker den første fase fra start til slut.

Byg det med Mythex

Mythex bygger webapps: du beskriver appen i chatten og tjekker den i den live forhåndsvisning på desktop og i en ramme i telefonstørrelse, du kan ændre størrelsen på. Dokumentationen har en mobilresponsiv prompt til at rette layouts på små skærme. Du kan bede om et PWA-manifest og ikoner ligesom enhver anden funktion og derefter publicere til et offentligt link, der virker på enhver telefon. På Pro kan Mythex også pakke appen ind som en Android- og iPhone-app, sendt til Google Play-intern test og TestFlight. Se AI-webapp-builderen eller gennemse app-skabeloner for at komme i gang. For et konkret eksempel, læs sådan bygger du en habit tracker-app.

Spørgsmål