Mobiilisovellus vai web-sovellus: kumpi sopii yrityksellesi?
Sovellusprojektin ensimmäinen kysymys on yleensä tämä: mobiilisovellus, web-sovellus vai molemmat? Valinta sitoo budjetin, aikataulun ja sen, keitä sovellus ylipäätään tavoittaa. Väärä valinta huomataan vasta kun raha on käytetty.
Lyhyt vastaus. Web-sovellus riittää useimmille yrityksille. Se on halvempi, nopeampi julkaista ja tavoittaa kaikki laitteet yhdellä toteutuksella. Natiivi mobiilisovellus kannattaa, kun sovellus tarvitsee laiteominaisuuksia, toimii ilman verkkoyhteyttä tai on päivittäisen käytön työkalu. Jos tarvitset sovelluskauppanäkyvyyden pienemmällä budjetilla, React Native on väliratkaisu.
Mitä eroa vaihtoehdoilla on
Natiivi mobiilisovellus rakennetaan alustan omilla työkaluilla: iOS:lle Swiftillä ja SwiftUI:lla, Androidille Kotlinilla. Käyttäjä lataa sen sovelluskaupasta ja asentaa laitteelleen. Sovellus pääsee käsiksi kaikkeen mihin laite pystyy.
Web-sovellus toimii selaimessa. Ei asennusta, ei sovelluskauppaa, ei erillistä versiota jokaiselle käyttöjärjestelmälle. Osoite riittää. Nykyaikaisella toteutuksella (React, Next.js) käyttökokemus on lähellä natiivia, ja sisältö löytyy hakukoneista.
Hybridi on väliratkaisu. React Native tuottaa yhdestä koodipohjasta sovellukset molempiin kauppoihin. Progressive Web App eli PWA on web-sovellus, jonka voi asentaa laitteen kotinäytölle.
Milloin natiivi mobiilisovellus kannattaa
Natiivi on oikea valinta, kun jokin näistä pätee:
- Sovelluksen pitää toimia ilman verkkoa. Kenttätyö, varastokirjanpito, kartat, mittaukset. Web-sovellus saadaan toimimaan offline-tilassa, mutta natiivissa se on lähtökohta eikä lisätyö.
- Laiteominaisuudet ovat sovelluksen ydin. Kamera skannaukseen, GPS taustaseurantaan, Bluetooth laiteyhteyksiin, biometrinen tunnistus, NFC. Selain pääsee osaan näistä, mutta rajoitetusti ja epäyhtenäisesti eri laitteilla.
- Suorituskyky ratkaisee. Pelit, reaaliaikainen video, raskas grafiikka, jatkuva anturidata.
- Käyttö on päivittäistä. Kun käyttäjä avaa sovelluksen useita kertoja päivässä, kotinäytön kuvake ja sekunnin käynnistysaika alkavat merkitä.
- Sovelluskauppa on jakelukanava. Kuluttajatuotteissa App Store ja Google Play tuovat löydettävyyttä, jota verkkosivu ei tuo.
Hinta on natiivin selkein haittapuoli. iOS ja Android ovat eri alustoja, eri kielillä ja eri julkaisuprosesseilla. Kahden alustan kattaminen tarkoittaa käytännössä kahta toteutusta ja kahta ylläpidettävää koodipohjaa.
Milloin web-sovellus riittää
Web-sovellus on oletusvalinta yrityskäyttöön. Se sopii, kun:
- Käyttäjät ovat eri laitteilla. Windows-työasema, Mac, iPad, Android-puhelin. Yksi toteutus kattaa kaikki.
- Sisällön pitää löytyä hausta. Sovelluskaupan sisältö ei näy Googlessa eikä kielimallien vastauksissa. Verkkosivu näkyy.
- Julkaisusykli on tiheä. Korjaus menee tuotantoon minuuteissa ja näkyy kaikille käyttäjille heti. Sovelluskauppa vaatii arvioinnin joka kerta, ja käyttäjä päivittää sovelluksen omaan tahtiinsa.
- Budjetti on rajallinen. Yksi koodipohja, yksi julkaisuputki, yksi testattava kokonaisuus.
- Käyttö on satunnaista. Harvoin käytettyä sovellusta ei asenneta. Se poistetaan tai unohdetaan.
Hallintapaneelit, asiakasportaalit, SaaS-palvelut, varausjärjestelmät ja sisältöpohjaiset palvelut kuuluvat lähes poikkeuksetta tähän ryhmään.
Hybridit: React Native ja PWA
React Native tuottaa yhdestä JavaScript-koodipohjasta sovellukset sekä App Storeen että Google Playhin. Käyttöliittymä rakentuu alustan omista komponenteista, joten tuntuma on lähellä natiivia. Säästö syntyy siitä, että logiikka kirjoitetaan kerran. Raskaimmissa grafiikka- ja anturitehtävissä natiivi on yhä edellä.
Progressive Web App on web-sovellus, jonka käyttäjä lisää kotinäytölle. Se avautuu omassa ikkunassaan ilman selaimen osoiterivia, toimii offline-tilassa ja voi lähettää push-ilmoituksia.
PWA:n kohdalla kannattaa tuntea iPhonen todellisuus ennen kuin sen varaan rakentaa:
- Apple toi web-push-ilmoitukset iOS 16.4 -versiossa maaliskuussa 2023. Sitä ennen niitä ei ollut lainkaan.
- Ilmoitukset toimivat vain, jos käyttäjä on lisännyt sivuston kotinäytölle Safarin jakovalikosta. Selaimen välilehti ei riitä.
- Safari ei näytä automaattista asennuskehotetta niin kuin Chrome Androidilla. Käyttäjän pitää tietää toiminto ennalta, avata jakovalikko ja etsiä sieltä Lisää Koti-valikkoon. Suuri osa ei tee sitä.
- Hiljaista taustapäivitystä ei ole. Sisältöä ei voi päivittää ilmoituksella käyttäjän huomaamatta.
PWA toimii, kun käyttäjät ovat sitoutuneita ja heille voi kertoa asennustavan. Laajan kuluttajayleisön tavoittamiseen se on epävarma kanava iOS:llä.
Mitä kumpikin maksaa Suomessa
Karkeat hintatasot, kun toteuttajana on suomalainen kumppani:
- Web-sovelluksen MVP: 5 000–20 000 euroa
- Keskikokoinen sovellus: 20 000–80 000 euroa
- Kehittäjän tuntihinta: 90–150 euroa (alv 0 %), pienemmillä toimijoilla 70–100 euroa
Natiivi kahdelle alustalle nostaa kehityskustannuksen helposti lähelle kaksinkertaista, koska työ tehdään kahteen kertaan. React Native leikkaa tästä ison osan. Tarkempi erittely projektityypeittäin löytyy artikkelista ohjelmistokehityksen kustannukset Suomessa 2026.
Sovelluskauppojen omat maksut jäävät usein huomaamatta budjetissa:
- Apple Developer Program: 99 Yhdysvaltain dollaria vuodessa, toistuva. Ilman voimassa olevaa jäsenyyttä sovellus poistuu App Storesta.
- Google Play: 25 Yhdysvaltain dollaria kertamaksuna kehittäjätilistä.
Summat ovat pieniä suhteessa kehitystyöhön. Applen maksun toistuvuus kannattaa silti muistaa: se on kiinteä vuosikulu niin kauan kuin sovellus on kaupassa.
Julkaisun jälkeen alkaa ylläpito
Kehityskustannus on kertaluonteinen. Ylläpito ei ole, ja tässä alustat eroavat selvästi.
Sovelluskauppa arvioi jokaisen version. Apple kertoo arvioivansa noin 90 prosenttia lähetyksistä alle vuorokaudessa. Se on keskiarvo eikä lupaus: ensimmäinen julkaisu, arkaluonteisia rajapintoja käyttävä sovellus tai puutteellisilla tiedoilla lähetetty versio voi jäädä jonoon päiviksi. Kiireellistä korjausta ei saa käyttäjille ohi arviointiprosessin.
Käyttöjärjestelmät päivittyvät vuosittain. Uusi iOS- tai Android-versio voi rikkoa toiminnallisuutta, muuttaa käyttöliittymän ulkoasua tai vaatia uuden käännösversion kehitystyökaluista. Mobiilisovellus vaatii siis ylläpitoa silloinkin, kun siihen ei lisätä mitään uutta.
Web-sovelluksessa julkaisu menee suoraan tuotantoon. Kaikki käyttävät samaa versiota, eikä vanhoja versioita tarvitse tukea.
Saavutettavuusvaatimukset koskevat molempia
Alustavalinta ei ole tie ulos lainsäädännöstä. Digipalvelulaki kattaa sekä verkkosivustot että mobiilisovellukset.
Esteettömyysdirektiivistä tulevia vaatimuksia on sovellettu kuluttajille myytäviin digipalveluihin 28.6.2025 alkaen. Ne koskevat yritystä, jolla on vähintään 10 työntekijää tai vähintään 2 miljoonan euron liikevaihto tai taseen loppusumma. Mikroyritykset jäävät ulkopuolelle.
Verkkokauppa on määritelty laajasti. Palvelun ei tarvitse käsitellä maksuja kuuluakseen soveltamisalaan – esimerkiksi kuluttajille suunnattu ajanvarauspalvelu lasketaan mukaan.
Tekninen vaatimustaso tulee standardista EN 301 549, joka nojaa WCAG 2.1 -ohjeiston A- ja AA-tason kriteereihin. Käytännössä tämä tarkoittaa riittäviä kontrasteja, näppäimistöllä toimivaa käyttöliittymää, ruudunlukijalle ymmärrettävää rakennetta, selkeitä virheilmoituksia ja lomakkeita, joissa kentät on merkitty oikein.
Natiivisovelluksessa työ tehdään alustan omilla rajapinnoilla, iOS:llä VoiceOverille ja Androidilla TalkBackille. Webissä se tehdään semanttisella HTML:llä ja WCAG:n mukaan. Kummallakin puolella saavutettavuus on halpaa suunnitteluvaiheessa ja kallista jälkikäteen. Se kannattaa ottaa mukaan määrittelyyn, ei korjauslistalle.
Viisi kysymystä, jotka ratkaisevat valinnan
Käy nämä läpi ennen kuin pyydät tarjouksia:
- Toimiiko sovellus ilman verkkoyhteyttä? Jos kyllä ja se on pakollista, natiivi.
- Tarvitseeko se kameraa, GPS:ää, Bluetoothia tai biometriikkaa ydintoimintoonsa? Jos kyllä, natiivi tai React Native.
- Pitääkö sisällön löytyä Googlesta tai kielimallien vastauksista? Jos kyllä, web.
- Kuinka usein käyttäjä avaa sovelluksen? Päivittäin puoltaa mobiilia, kerran kuussa puoltaa webiä.
- Riittääkö budjetti kahteen toteutukseen? Jos ei, valitse yksi alusta ja tee se kunnolla.
Yleisin toimiva järjestys on aloittaa webillä, todentaa idea oikeilla käyttäjillä ja rakentaa mobiilisovellus vasta kun tiedetään, mitä sen pitää tehdä. Kun tarjouspyyntö on ajankohtainen, tarjouspyynnön laatimisen opas auttaa rajaamaan sen niin, että vertailukelpoisia vastauksia tulee.
Usein kysytyt kysymykset
Kumpi on halvempi, mobiilisovellus vai web-sovellus?
Web-sovellus on lähes aina halvempi, koska yksi koodipohja riittää kaikille laitteille. Natiivi kahdelle alustalle tarkoittaa kahta erillistä toteutusta. Suomessa web-sovelluksen MVP asettuu tyypillisesti 5 000–20 000 euron haarukkaan.
Voiko web-sovelluksen julkaista sovelluskaupassa?
Pelkkää verkkosivua ei voi. Jos sovelluskauppanäkyvyys on tavoite, vaihtoehtoja on kaksi: natiivi toteutus tai React Nativen kaltainen hybridi. PWA asennetaan selaimesta kotinäytölle, eikä se näy sovelluskaupan hauissa.
Toimivatko push-ilmoitukset web-sovelluksessa iPhonella?
Toimivat, mutta vain kotinäytölle asennetussa PWA:ssa. Apple toi tuen iOS 16.4 -versiossa maaliskuussa 2023. Selaimen välilehdellä auki oleva sivusto ei voi lähettää ilmoituksia.
Koskeeko saavutettavuuslaki mobiilisovelluksia?
Koskee. Digipalvelulaki kattaa sekä verkkosivustot että mobiilisovellukset, ja esteettömyysdirektiivin vaatimuksia on sovellettu 28.6.2025 alkaen vähintään 10 työntekijän tai 2 miljoonan euron yrityksiin. Alustavalinta ei poista velvoitetta.
Kannattaako aloittaa webillä vai mobiililla?
Useimmiten webillä. Se on nopeampi ja halvempi rakentaa, julkaisu ei odota sovelluskaupan arviointia ja korjaukset näkyvät heti. Poikkeus on sovellus, joka ei toimi lainkaan ilman laiteominaisuuksia tai offline-käyttöä.
Yhteenveto
Yhtä oikeaa vastausta ei ole. Käyttäjien laitteet, sovelluksen vaatimukset ja budjetti ratkaisevat. Kysy kumppanilta aina perustelut alustavalinnalle – ja jos perusteluna on pelkkä teknologiamieltymys, kysy uudelleen.
Mietityttääkö oikea alusta? Kerro mitä sovelluksen pitäisi tehdä, niin käydään vaihtoehdot läpi.
[email protected]