Mobiele Apps

Apps die mensen op hun telefoon houden

Cross-platform als uitgangspunt, native waar het zich echt terugverdient — en eerst een eerlijk antwoord op de vraag of u wel een app nodig heeft.

Begin bij de vraag of u een app nodig heeft

Het nuttigste wat wij aan het begin van een mobiel project kunnen doen, is het ter discussie stellen. Een app is een tweede product om te ontwerpen, publiceren, langs review te loodsen, bij te werken en te ondersteunen — op twee platformen, blijvend. Die kosten lonen wanneer de app ze rechtvaardigt, en zijn weggegooid wanneer een goede mobiele website hetzelfde had gedaan.

Een app verdient haar plek wanneer mensen vaak terugkomen, wanneer de telefoon zelf nodig is — meldingen, camera, locatie, codes scannen, echt gebruik zonder verbinding — of wanneer de app het product is en niet de etalage. Is het doel gevonden worden, uitleggen wat u doet en aanvragen binnenhalen, dan is een website de betere besteding, en dat zeggen wij dan ook.

Is een app wel de juiste keuze, dan volgt de vraag hoe u hem bouwt. Voor de meeste zakelijke apps luidt dat antwoord cross-platform: één codebase voor iOS en Android, doorgaans een derde tot de helft goedkoper dan hetzelfde twee keer bouwen. Native loont in specifieke gevallen, en wij zeggen het wanneer het uwe daarbij hoort.

Hoe wij bouwen

Cross-platform apps (React Native en Flutter)

Eén codebase, beide platformen. Voor de overgrote meerderheid van zakelijke apps is het prestatieverschil met native zo klein dat gebruikers het nooit merken, terwijl de besparing op bouw en onderhoud aanzienlijk en blijvend is.

Wij kiezen standaard React Native, omdat het kennis en vaak code deelt met een React-webstack — wat over vijf jaar zwaarder weegt dan welke benchmark ook. Flutter is de betere keuze wanneer de interface zélf het product is: veel animatie, een tot op de pixel identiek ontwerpsysteem op beide platformen.

  • Eén codebase voor iOS en Android
  • React Native standaard, Flutter waar de interface het product is
  • Gedeelde kennis met de webstack
  • Eén update bereikt beide platformen

Native iOS en Android

Swift en Kotlin, per platform gebouwd. Dat kost meer om te maken en ongeveer het dubbele om te onderhouden, dus er moet een reden zijn die verder gaat dan voorkeur.

Die redenen bestaan: grafisch zware of 3D-interfaces, augmented reality of computer vision op het toestel, een platform-API nodig hebben op de dag dat die verschijnt, of producten waarbij latency de kern is — professionele camera- en audiogereedschappen. Hoort u daarbij, dan zeggen wij dat.

  • Swift voor iOS, Kotlin voor Android
  • Volledige toegang tot platform-API's vanaf dag één
  • De juiste keuze voor graphics, AR en kritieke latency
  • Wij benoemen de hogere bouw- en onderhoudskosten eerlijk

Wanneer een webapplicatie het betere antwoord is

Native is niet langer het uitgangspunt. Een progressieve webapp wordt gevonden via zoekmachines, opent vanuit een link, vraagt geen installatie, ontloopt de storecommissie en werkt bij op het moment dat u publiceert.

Er wordt wel iets ingeleverd: diepe hardwaretoegang, achtergrondtaken, en meldingen blijven op iOS beperkter dan op Android. Een veelgehoorde goede uitkomst is allebei: een webapp voor bereik en een kleine native app voor wie hem dagelijks gebruikt.

  • Vindbaar in zoekmachines, zonder installatie
  • Geen storecommissie of wachttijd voor review
  • Werkt bij op het moment van publiceren
  • Combineert goed met een gerichte native app

Offline-first en realtime

Telefoons verliezen bereik. Een app die verbinding veronderstelt faalt precies daar waar buitendienstteams werken: kelders, magazijnen, buitengebied, onderweg. Offline-first betekent dat de app bruikbaar blijft en bijwerkt zodra de verbinding terug is.

Het lastige is die verzoening, niet het cachen: bepalen wat er gebeurt als twee mensen offline hetzelfde record hebben gewijzigd. Wij leggen die regel samen met u vast, in plaats van de laatste schrijfactie stilzwijgend te laten winnen.

  • Bruikbaar zonder verbinding
  • Synchronisatie- en conflictregels vooraf afgesproken
  • Realtime updates waar die ertoe doen
  • Meldingen die de aandacht van mensen respecteren

Lancering in de stores en wat daarna komt

De App Store en Google Play binnenkomen is een proces met eigen regels: reviewrichtlijnen, privacyverklaringen, formulieren voor gegevensveiligheid, leeftijdsclassificatie, testversies voor uw team.

En daarna gaat het door. Apple en Google brengen jaarlijks nieuwe systeemversies uit en verhogen periodiek de minimumeisen, dus een app die ongemoeid blijft wordt op den duur niet meer geaccepteerd. Onderhoud is niet optioneel, en wij noemen de kosten voordat u zich vastlegt.

  • Indiening bij App Store en Google Play
  • Privacy- en gegevensveiligheidsverklaringen
  • Testversies voor het team vóór publicatie
  • Systeem- en SDK-updates na de lancering

Heeft uw bedrijf een app nodig?

De eerlijke versie. Veel bedrijven die ons om een app vragen zijn beter geholpen met iets anders, en dat nu ontdekken is goedkoper.

Een app is gerechtvaardigd wanneer

  • Mensen hem vaak gebruiken — wekelijks of dagelijks
  • De telefoon nodig is: meldingen, camera, locatie, scannen, sensoren
  • Hij zonder verbinding moet werken en later moet synchroniseren
  • De app het product is, en geen etalage ervan
  • U op het startscherm moet staan om de gewoonte vast te houden

Een website is de betere besteding wanneer

  • Het doel is gevonden worden, uitleggen en aanvragen binnenhalen
  • Mensen hem een of twee keer per jaar zouden gebruiken
  • De inhoud voortdurend verandert en zoekverkeer telt
  • Er geen budget is voor onderhoud na de lancering
  • De voornaamste reden is dat concurrenten er een hebben

Hoe wij werken

Kortere rondes dan bij web, omdat de store-review tussen u en uw gebruikers staat.

  1. 01

    Afbakening

    Wij bepalen waar de app voor dient, wie hem gebruikt en wat de eerste versie echt moet kunnen. Wat kan wachten, wacht: een kleinere eerste versie bereikt eerder echte gebruikers.

  2. 02

    Ontwerp

    Schermen en flows getoetst als klikbaar prototype, met respect voor de conventies van elk platform in plaats van één ontwerp op beide te forceren.

  3. 03

    Bouw en test

    Regelmatige testversies op uw eigen toestellen, niet alleen in een simulator, zodat u de app gebruikt op de telefoon die u werkelijk bij u draagt.

  4. 04

    Lancering en onderhoud

    Wij verzorgen indiening en review, en houden de app actueel terwijl iOS en Android eronder doorontwikkelen.

Technologie

Wij kiezen de techniek op basis van de app en niet andersom, en blijven bij breed toegepaste gereedschappen zodat de app onderhoudbaar blijft voor elk bekwaam team.

Cross-platform

React NativeFlutterTypeScript

Native

SwiftKotlin

Backend

FirebaseAWS AmplifyREST API'sPushmeldingen

Waar een app zich meestal terugverdient

Situaties waarin de telefoon iets toevoegt wat een website niet kan. Dit zijn illustratieve voorbeelden van het soort werk dat wij doen.

Buitendienstteams

Monteurs die werk, foto's en handtekeningen ter plaatse vastleggen, offline doorwerken en synchroniseren zodra er weer bereik is.

Companion-app voor klanten

Een app waarmee bestaande klanten orders, afspraken of leveringen volgen, waarbij een melding een reeks e-mails vervangt.

Afspraken en loyaliteit

Bedrijven waar mensen vaak terugkomen, en waar een pictogram op het startscherm en een herinnering meer waard zijn dan nog een browsertabblad.

Scannen en voorraad

Voorraad, activa of tickets gecontroleerd met de telefooncamera, waar het alternatief speciale hardware of papier is.

Veelgestelde vragen

Wat kost een mobiele app?

De scope bepaalt het, niet het platform: hoeveel schermen, hoeveel backend, hoeveel koppelingen. Cross-platform komt doorgaans ruim onder het twee keer native bouwen van dezelfde app, en dat is de voornaamste reden dat het ons uitgangspunt is. Wij bakenen eerst af en noemen daarna een reëel bedrag, in plaats van te ramen voordat wij de app begrijpen.

Cross-platform of native?

Cross-platform voor de meeste zakelijke apps — gebruikers merken het verschil niet en u halveert het onderhoud op termijn. Native wanneer de app grafisch zwaar is, leunt op augmented reality of vision op het toestel, gloednieuwe platform-API's nodig heeft, of wanneer latency het product is. Wij zeggen eerlijk aan welke kant uw geval valt.

Hebben wij een app nodig of volstaat een website?

Vaak volstaat een website. Zouden mensen een of twee keer per jaar langskomen, of is het doel gevonden worden en uitleggen wat u doet, dan is een goede mobiele website de betere investering. Een app is gerechtvaardigd door herhaald gebruik, de hardware van de telefoon, echt offline gebruik, of doordat de app zelf het product is.

Hoe lang duurt het?

Een gerichte eerste versie kost doorgaans enkele maanden, plus de store-review. Wij houden die eerste versie bewust klein, omdat echte gebruikers op echte telefoons meer vertellen over wat u daarna moet bouwen dan nog een maand plannen.

Van wie zijn de app en de code?

Van u. De code, de data en de storevermeldingen zijn eigendom van uw bedrijf. Wij publiceren onder uw ontwikkelaarsaccounts en niet onder de onze, zodat u nooit buitengesloten raakt van uw eigen app.

Wat kost onderhoud na de lancering?

Mobiel kent een basislast die web niet heeft: iOS en Android verschijnen jaarlijks en verhogen periodiek de minimumeisen, dus een app die ongemoeid blijft wordt uiteindelijk niet meer geaccepteerd. Wij spreken de onderhoudsafspraak vóór de lancering af, zodat het een bekende kostenpost is en geen verrassing.

Verwante diensten

Diensten die vaak deel uitmaken van hetzelfde project.

Denkt u aan een app?

Vertel ons wat hij zou doen en wie hem zou gebruiken. U krijgt een eerlijk antwoord of een app de juiste stap is en wat het bouwen ervan zou vergen.