Slik bygger du en mobilvennlig nettapp

En mobilvennlig nettapp er et nettsted som fungerer som en app på telefonen: den passer den smale skjermen, har store berøringsflater, laster raskt på mobildata, og kan legges til på startskjermen som en progressiv nettapp (PWA). For de fleste nye apper er dette den praktiske første versjonen — én kodebase, én lenke, ingen butikkgodkjenning. Den har likevel reelle begrensninger, særlig rundt varsler på iPhone og dyp tilgang til enheten, og denne guiden er rett på sak om når du trenger en native app i stedet.

Tre måter å være «på mobil»

En PWA er en responsiv nettapp med noen tillegg, så du trenger ikke velge mellom de to første. Bygg responsivt først, og gjør den deretter installerbar. For en dypere sammenligning, se native kontra progressive nettapper.

Hva nettapper kan og ikke kan gjøre på telefoner

Nettlesere kan mer enn mange antar:

• Kamera og bildeopplasting, via vanlige filfelt.
• Posisjon, med brukerens tillatelse.
• Installasjon på startskjermen med ikon og oppstart i fullskjerm.
• Bruk uten nett, ved å mellomlagre sider og data med en service worker (et bakgrunnsskript nettleseren kjører for nettstedet ditt).
• Push-varsler — med en fallgruve på iPhone. Apples WebKit-team sier at web push kom til iOS og iPadOS 16.4 for nettapper lagt til på startskjermen. Brukere må først installere appen, og deretter tillate varsler.

Der native fortsatt vinner:

• Dype enhetsfunksjoner som bakgrunnsposisjon, Bluetooth-tilbehør, helsedata og widgeter på startskjermen — støtten i nettleseren er begrenset eller varierer mellom plattformer.
• Oppdagelse i app-butikken. Hvis folk skal søke etter deg i butikken, må du være der.
• Tungt arbeid uten nett, som store datasett som synkroniseres i bakgrunnen.
• Ytelseskritisk grafikk, som krevende spill.

Hvis ingen av disse er sentrale for appen din, vil en nettapp sannsynligvis fungere godt for deg.

Design for telefoner først

Design telefonlayouten først og la den utvide seg for større skjermer; det omvendte gir vanligvis trange telefonskjermer.

Layout

• En kolonne på små skjermer. Sidepaneler blir en nedre meny eller en hamburgermeny.
• Ingen sideveis scrolling. Brede tabeller blir kort, eller scroller inne i sin egen beholder.
• Lesbar tekst uten å måtte zoome — brødtekst rundt 16 px.

Berøring

• Store trykkflater. Rundt 44 x 44 piksler er et vanlig minimum. La det være plass mellom dem.
• Hovedhandlinger innen rekkevidde for tommelen, nær bunnen av skjermen på høye telefoner.
• Ingen funksjoner som bare finnes ved hover. Verktøytips og menyer som vises ved hover finnes ikke på berøringsskjermer.
• Riktig tastatur. E-postfelt bør åpne e-posttastaturet, telefonfelt tallblokken. Be om riktige inndatatyper.

Hastighet

• Små bilder i fornuftige størrelser, lastet når de kommer inn i synsfeltet.
• Færre tunge biblioteker. Hvert ett legger til nedlastingstid på mobildata.
• Skjelettskjermer eller tydelige lastetilstander, slik at appen aldri ser frosset ut.

Sikre områder og adressefeltet

På moderne telefoner kan innhold havne under hakket eller hjemindikatoren, særlig i en fullskjermsinstallert app. Be om polstring for sikre områder. Se også opp for layouter i full høyde som hopper når adressefeltet i nettleseren dukker opp og forsvinner.

Gjøre den installerbar (PWA)

For å kunne installeres trenger en nettapp:

1. Et manifest for nettapper — en liten fil med appens navn, kortnavn, ikoner, temafarge og hvordan den skal åpnes (vanligvis fullskjerm, «standalone»).
2. Ikoner i størrelsene plattformene forventer, inkludert ett som passer for Apple-enheter.
3. HTTPS, som enhver riktig hostet app allerede har.
4. En service worker hvis du vil ha støtte for bruk uten nett eller push.

Deretter må du fortelle brukerne hvordan de installerer den. Android-nettlesere tilbyr vanligvis en installasjonsforespørsel eller et menyvalg; på iPhone er det Del-knappen, deretter «Legg til på Hjem-skjerm». En kort «Installer denne appen»-merknad med disse stegene hjelper mye.

Bruk uten nett er der PWA-er blir kompliserte. Å mellomlagre appens sider slik at den åpnes uten forbindelse er greit. Å la folk endre data uten nett og synkronisere senere er reelt arbeid — be bare om det hvis brukerne virkelig trenger det.

En første prompt som fungerer

Bygg en nettapp for rengjøringsteamet vårt, for å se dagens oppdrag og merke dem som utført. Design for telefoner først: én kolonne, store trykkflater, hovedknappen festet nær bunnen, ingen kontroller som bare finnes ved hover, ingen sideveis scrolling, og riktige tastaturer for telefon- og e-postfelt. Hvert oppdrag viser adressen (trykk for å åpne i kart), kundens telefonnummer (trykk for å ringe), en sjekkliste og en «Merk som fullført»-knapp som kan ta et bilde. Ledere logger inn på en laptop for å tildele oppdrag; på en bred skjerm vises en tabell i stedet for kort. Gjør den til en installerbar PWA med manifest, ikoner og standalone-visning, og mellomlagre appskjelettet slik at den åpnes uten signal. Lagre data i en database.

Byggesteg

1. Bygg layouten for telefon først, med eksempeldata, og sjekk den i en forhåndsvisning i telefonstørrelse.
2. Test på ekte telefoner — minst én iPhone og én Android hvis brukerne dine har begge. Emulatorer går glipp av ting som at tastaturet på skjermen dekker felt.
3. Gå gjennom hovedoppgaven med én tommel. Hvis noe krever to hender eller zoom, fiks det.
4. Legg til manifest og ikoner, og installer deretter på begge plattformene og sjekk ikon, navn og oppstartsskjerm.
5. Bestem deg for bruk uten nett. Start med «åpnes uten signal og viser en tydelig melding»; legg til redigering uten nett bare hvis det trengs.
6. Sjekk hastigheten på en treg forbindelse. Nettleserens utviklerverktøy kan simulere en.
7. Legg til varsler sist, om i det hele tatt — og planlegg en e-postløsning for brukere som ikke installerer.

Vanlige feil

• Å designe bare på en stor skjerm. Sjekk hver skjerm i telefonbredde underveis.
• Tabeller som flyter over. Gjør rader om til kort på små skjermer.
• Små trykkflater og lenker tett sammen.
• Skjemaer som kjemper mot tastaturet — feil inndatatyper, felt skjult bak tastaturet, ingen «neste»-flyt.
• Å anta at push på iPhone fungerer i en nettleserfane. Det krever at appen er installert på Hjem-skjermen.
• Å love en App Store-app du ikke kan levere. Hvis butikken er viktig, planlegg for den separat.
• Å pakke et nettsted inn og kalle det en app. Apples retningslinjer for App Review ber om apper som går utover et ompakket nettsted; en tynn innpakning risikerer avvisning.

Når du trenger en native app

Gå native (eller planlegg en native versjon etter nettappen) når:

• Tilstedeværelse i butikk er hvordan kundene finner deg.
• Du er avhengig av bakgrunnsposisjon, Bluetooth, helsedata, widgeter eller andre enhetsfunksjoner nettlesere ikke tilbyr pålitelig.
• Appen din må fungere helt uten nett over lengre perioder.
• Brukerne forventer det — noen målgrupper vil ganske enkelt ikke bruke noe som ikke finnes i butikken.

Publisering i butikk har sine egne kostnader og steg. Fra september 2026 koster Apples utviklerprogram 99 amerikanske dollar i året, og en Google Play-utviklerkonto koster en engangsavgift på 25 amerikanske dollar, ifølge deres egne nettsider, og hver utgivelse går gjennom godkjenning. Mange team starter med en mobilvennlig nettapp for å bevise at folk vil ha produktet, og investerer deretter i native når de vet det. Slik bygger du en app med AI dekker den første fasen fra start til slutt.

Å bygge det med Mythex

Mythex bygger nettapper: du beskriver appen i chatten, og sjekker den i live-forhåndsvisningen på desktop og i en ramme i telefonstørrelse du kan endre størrelse på. Dokumentasjonen har en mobilresponsiv prompt for å fikse layouter på små skjermer. Du kan be om et PWA-manifest og ikoner som alle andre funksjoner, og deretter publisere til en offentlig lenke som fungerer på alle telefoner. På Pro kan Mythex også pakke appen som en Android- og iPhone-app, sendt til intern testing i Google Play og TestFlight. Se AI-nettappbyggeren eller bla gjennom app-maler for å starte. For et konkret eksempel, les slik bygger du en vanesporingsapp.

Spørsmål