Mobilna aplikacija nastaje u fazama. Prvo se dogovara što mora riješiti, zatim slijede dizajn ekrana i razvoj, a na kraju testiranje na vašem mobitelu i objava na App Storeu i Google Playu. U svakoj fazi postoji odluka koju donosite vi. Objava nije kraj, jer Apple i Google svaku sljedeću verziju pregledavaju iznova.
Prije koda: što aplikacija mora riješiti
Prije prvog retka koda treba znati tko će aplikaciju otvarati, koliko često i što u njoj mora napraviti bez ičije pomoći. O tim odgovorima ovisi i to treba li vam mobilna aplikacija uopće.
Mobilnu aplikaciju vrijedi raditi kad je ljudi otvaraju više puta na dan, često u pokretu, ili kad je aplikacija sama proizvod koji se prodaje kroz App Store i Google Play. Sustav koji se otvara za stolom ili nekoliko puta tjedno često je bolji kao web aplikacija. Jeftiniji je i ne čeka Appleov i Googleov pregled. Tako radi Patrono, naš sustav za ugostiteljstvo: osoblje raspored smjena i checkliste otvara s mobitela u pregledniku, bez instalacije. Ako razgovor završi zaključkom da vam je dovoljna web aplikacija, to je dobar ishod, jer ste uštedjeli prije nego što ste potrošili.
Na početku razjašnjavamo ova pitanja:
- Tko su korisnici: vaši zaposlenici, vaši kupci ili ljudi koji će aplikaciju tek pronaći u storeu.
- Što korisnik mora moći napraviti već kod prvog otvaranja.
- Treba li prijava, plaćanje ili obavijesti koje stižu na zaslon mobitela.
- Na koje se postojeće sustave aplikacija spaja.
- Po čemu ćete znati da aplikacija radi svoj posao.
Prva verzija ne mora imati sve. Bolje je objaviti jezgru koju korisnici stvarno trebaju i dograđivati prema tome kako je koriste, nego mjesecima čekati verziju sa svim idejama s prvog sastanka. Analitika nakon objave pokaže što se koristi, a što ne.
Za novu ideju možemo najprije napraviti klikabilni prototip, odnosno ekrane koje isprobate na mobitelu prije nego što postoji ijedan redak koda. Tako se ideja jeftino provjeri prije početka razvoja.
iOS, Android ili oboje iz jedne baze koda
Ako aplikaciju koriste i vlasnici iPhonea i vlasnici Android mobitela, odgovor je oboje, iz jedne baze koda. Mi to radimo u Flutteru, Googleovom alatu koji iz istog koda proizvodi aplikaciju za obje platforme.
Druga mogućnost je graditi dvaput, posebno za iOS i posebno za Android. Takve se aplikacije zovu nativne (engl. native), jer su pisane za jedan sustav. Korisnik Flutter aplikaciju ne razlikuje od nativne: izgleda i reagira isto, a biometrija i obavijesti rade preko istih sučelja. Razlika je na vašoj strani. Razvoj košta manje nego dvije odvojene aplikacije, nova funkcionalnost stiže na obje platforme istovremeno, a pogreška se ispravlja jednom.
U Flutteru smo izgradili i vlastitu aplikaciju koja je danas objavljena na App Storeu i Google Playu, pa alat poznajemo iz objavljenog proizvoda, a ne iz demo projekata.
Aplikacija samo za Android ima smisla kad unaprijed znate na kojim će uređajima raditi, na primjer kad tvrtka zaposlenicima na terenu daje Android mobitele ili tablete. I tada je Flutter dobar izbor. Kad kasnije zatreba verzija za iPhone, ne piše se nova aplikacija.
Faze: dizajn, razvoj, testiranje, objava
Aplikacija prolazi kroz četiri faze, a ekrane prije razvoja i testnu verziju prije objave odobravate vi.
U dizajnu nastaju ekrani i put korisnika kroz aplikaciju. Sučelje i korisničko iskustvo radimo interno, a za brend i vizualni identitet imamo partnerstvo sa Spiffy Studiom. Programiranje počinje tek kad odobrite ekrane, jer je promjena na crtežu jeftinija od promjene u kodu. Od vas u ovoj fazi trebaju odluke o tome što ide u prvu verziju, a što čeka kasnije.
U razvoju uz ekrane nastaje i sve što aplikacija treba za rad:
- prijava korisnika e-mailom, Google ili Apple računom, po potrebi i biometrijom
- backend, odnosno server s bazom podataka koja se sinkronizira u stvarnom vremenu
- obavijesti koje korisnika vraćaju u aplikaciju
- naplata pretplata kroz App Store i Google Play
- praćenje rušenja i analitika, da se problemi vide prije nego što ih korisnici prijave
U testiranju aplikaciju isprobavate na svom mobitelu, kroz testne verzije koje šaljemo tijekom razvoja. Primjedbe tako ulaze u aplikaciju prije objave, a ne nakon loših recenzija u storeu.
Objavu vodimo mi. Postavljamo developer račune, odnosno račune preko kojih se aplikacija objavljuje, pripremamo opise i snimke ekrana i vodimo aplikaciju kroz Appleov i Googleov pregled. Računi i aplikacija glase na vas. Projekt smatramo isporučenim tek kad aplikaciju korisnici mogu preuzeti.
Aplikacija s korisničkim računima najčešće je gotova za dva do četiri mjeseca razvoja, a tome treba dodati vrijeme za Appleov i Googleov pregled.
App Store i Google Play: pregled svake verzije
Apple i Google pregledavaju svaku verziju aplikacije prije nego što stigne do korisnika, i prvu objavu i svaku kasniju ispravku. Odobrenje jedne verzije ne vrijedi za sljedeću. Recenzent provjerava radi li aplikacija ono što piše u njezinu opisu i može li proći kroz svaki njezin dio.
Zato vrijeme za pregled planiramo u svaki rok, i za veliku novu verziju i za malu ispravku. Ako aplikacija traži prijavu, recenzent dobiva demo račun, a taj račun držimo spremnim za svaku objavu. Mnoga odbijanja rješavaju se upravo time što recenzent vidi ono što treba vidjeti.
Ako aplikacija ipak bude odbijena, ispravimo ono što recenzent traži i pošaljemo novu verziju. Svako odbijanje produžuje rok, pa se priprema isplati.
I pretplate u aplikaciji idu kroz storeove: korisnik plaća računom koji već ima na mobitelu, a App Store ili Google Play vode naplatu i obnove. Stanje pretplate spajamo s backendom, pa aplikacija u svakom trenutku zna tko ima pristup plaćenom dijelu.
Održavanje nakon objave
Aplikaciju treba održavati i kad ne dodajete ništa novo, jer se storeovi mijenjaju oko nje. Apple svake jeseni izdaje novi iOS, a Google redovito podiže tehničke zahtjeve za objavu. Aplikacija koja se ne održava prije ili kasnije prestane prolaziti pregled, čak i za malu ispravku.
Najneugodnije je kad aplikaciju koja dugo nije dirana treba hitno ispraviti. Tada se prvo nadoknađuje sve što je propušteno, a tek onda radi sama ispravka. Redovno održavanje taj posao dijeli na manje dijelove i drži aplikaciju spremnom za objavu.
Kroz ugovorno održavanje pratimo promjene na iOS-u i Androidu, objavljujemo nove verzije na vrijeme i dodajemo funkcionalnosti kako proizvod raste. Izvještaj o svakom rušenju stiže nama, s podatkom na kojem se uređaju i u kojoj verziji dogodilo. Analitika pokazuje koliko se korisnika vraća i gdje odustaju.
Primjeri: Patrono i Staxo
Staxo i Patrono pokazuju dva različita puta do korisnika. Staxo je aplikacija iz storea koja je sama proizvod, a Patrono je sustav koji radi i u pregledniku i kao aplikacija.
Staxo je naša mobilna aplikacija za učenje trgovanja kriptovalutama, s virtualnim portfeljem i stvarnim tržišnim cijenama. Napravljena je u Flutteru, s Firebaseom kao backendom, a pretplate se naplaćuju kroz App Store i Google Play. Uz trgovanje ima tečajeve s kvizovima, razine, lige i ljestvice, pa korisnik ima razlog vratiti se. Aplikacija redovito dobiva nove verzije, uz prilagodbe novim verzijama iOS-a i Androida, pa pregled u storeovima i održavanje poznajemo i s vlasničke strane. Kako je nastala, opisuje case study o Staxu.
Patrono je naš sustav za vođenje restorana i kafića. Radi u pregledniku te kao aplikacija na iOS-u i Androidu, iz istih podataka, pa vlasnik za stolom i osoblje u lokalu gledaju isto stanje. Isti model koristi i Klinika Hub, naš sustav za privatne ordinacije. Više o tome piše u opisu projekta Patrono.
Kad mobilna aplikacija služi ljudima na terenu uz poslovni sustav, gradimo je nad istim podacima, pa se ništa ne upisuje dvaput. O tome više u tekstu što je CRM sustav i kada se isplati CRM po mjeri. Ako još niste sigurni trebate li aplikaciju po mjeri, pogledajte tekst aplikacija po mjeri ili gotov program. Kako radimo, opisuje stranica izrada mobilnih aplikacija, a upit možete poslati kroz obrazac ili nazvati 099 603 7494.