Izdelava aplikacij za iOS in Android, nativnih ali večplatformskih. Izbiro utemeljimo, ne privzamemo.
Pri mobilni aplikaciji zaslon ni najtežji del. Težje je to, da operacijski sistem vašo aplikacijo obravnava kot gosta: omejuje ji delo v ozadju, uporabnik lahko zavrne poziv za dovoljenje, pregled v trgovini pa lahko različico zavrne iz razloga, ki ga ne pojasni do konca. S tem računamo od začetka in ne iščemo obvozov.
Za kaj gre
Prva prava odločitev pri izdelavi mobilne aplikacije je, ali graditi nativno ali večplatformsko. Utemeljena mora biti s tem, kaj aplikacija dejansko počne, ne privzeta. Swift in SwiftUI na iOS-u ter Kotlin in Jetpack Compose na Androidu dajo poln dostop do platforme: zvok v ozadju, ARKit, namenska naprava Bluetooth, torej stvari, ki jih React Native in Flutter podpirata neenakomerno ali sploh ne. Če so v aplikaciji večinoma obrazci, seznami in tok vsebin, jo z večplatformskim razvojem zgradite enkrat za obe trgovini, in to je prava izbira. Odločitev presojamo po zaslonih, ki se res dotikajo strojne opreme, ne po tem, katero tehnologijo imamo v hiši raje.
Večina tega, kar pregled v trgovini dejansko preverja, nima nobene zveze s tem, ali aplikacija deluje. Applov pregled lahko različico zavrne zaradi manjkajoče oznake zasebnosti, zaradi dovoljenja, ki ga aplikacija zahteva, ne da bi ob tem pojasnila, zakaj, ali zaradi prijavnega zaslona, ki ob prijavi prek zunanjega ponudnika ne ponudi tudi možnosti Sign in with Apple. Nič od tega se ne pokaže na predstavitvi. Ko pišemo opombe za pregled in metapodatke, vemo, na katere od teh ovir so aplikacije že naletele. Oddajo v trgovino obravnavamo kot del razvoja, ne kot formalnost po njem.
Mobilna aplikacija je redko cel sistem. Običajno je terenska polovica nečesa, kar ima še zaledje, skrbniški vmesnik ali oboje, in zanimive napake nastajajo prav na tej meji: konflikt pri sinhronizaciji, ko sta dva človeka brez povezave urejala isti zapis, ali žeton za potisna obvestila, ki zastara, pa tega nihče ne opazi, dokler ne začnejo prihajati zahtevki za podporo. Če zaledja še ni, ga zgradimo v okviru istega sodelovanja. Zato ta stran stoji ob razvoju izdelkov SaaS in integraciji API-jev, ne sama zase.
Kaj dobite
Nativna ali večplatformska izvedba, odločena in zapisana
Swift in Kotlin ali React Native in Flutter, izbrano glede na to, kaj aplikacija res potrebuje od operacijskega sistema, ne po privzetem naboru tehnologij.
Specifikacija API-ja, po kateri je aplikacija zgrajena
Določena zgodaj, ker po njej gradimo obe platformi, pozna sprememba pa pomeni popravke v dveh kodnih bazah namesto v eni.
Delo brez povezave in sinhronizacija za zaslone, ki to potrebujejo
Lokalno shranjevanje, čakalna vrsta za tisto, česar ni bilo mogoče poslati, in pravilo za reševanje konfliktov, ki nobene spremembe ne zavrže na tiho.
Potisna obvestila, ki preživijo zastarel žeton
Povezana APNs in FCM, s ponovno registracijo, ki se sproži, ko žeton poteče, namesto da bi obvestilo šlo v prazno.
Oddaja v App Store in Play Store
Metapodatki, posnetki zaslona in opombe za pregled, pripravljeni zato, da aplikacija pregled prestane že prvič, ne napisani šele po prvi zavrnitvi.
Poročanje o sesutjih in postopek izdaje
Sesutja so v produkciji vidna od prvega dne, gradnja in izdaja pa nista odvisni od prenosnika enega človeka.
Varna hramba žetonov in poverilnic na napravi
Keychain na iOS-u in Keystore na Androidu, da prijavni žeton ne leži v navadnih, nešifriranih nastavitvah.
Predaja izvorne kode in konfiguracije CI
Podpisano izdajno različico lahko pripravite brez nas.
Kdaj je to prava izbira in kdaj ne
Prava izbira
- Aplikacija mora delovati s slabo povezavo ali brez nje: terenski servis, skladišča, ogledi na lokaciji. Delo brez povezave je tu resnična zahteva, ne želja.
- Aplikacija potrebuje zmožnost, do katere v aplikacijo zavita spletna stran ne pride zanesljivo: kamero, Bluetooth, NFC, lokacijo v ozadju.
- Aplikacija je terenska polovica sistema, obstajati pa mora tudi pisarniška stran: nadzorna plošča ali skrbniški vmesnik.
- Potrebujete tako iOS kot Android in želite, da je odločitev med nativnim in večplatformskim razvojem sprejeta enkrat, z razlogi, namesto da se o njej znova razpravlja v vsakem sprintu.
- Aplikacija mora prestati pregled v trgovini App Store ali Play Store in tveganje bi raje prepustili ljudem, ki so to že počeli.
Ni prava izbira
- V resnici potrebujete spletno stran, prilagojeno telefonom. Odzivna stran je narejena v nekaj dneh, ne gre skozi noben pregled v trgovini in se posodobi v trenutku, ko jo objavite. Za vsebino, ki je večinoma besedilo in obrazci, je nativna aplikacija napačno orodje.
- Aplikacija je lupina okoli zaledja, ki še ne obstaja in še nima določenega obsega. Najprej določite obseg zaledja, naj bo to razvoj izdelka SaaS ali integracija. Aplikacija mu sledi.
- Potrebujete eno hitro orodje, ki ga bo peščica zaposlenih uporabljala na svojih telefonih. To je običajno lažja izvedba, bližje internim orodjem kot javni objavi v trgovini.
- Želite igro ali kaj grafično zahtevnega. Mi gradimo poslovne aplikacije. Studio, ki igre dela vsak dan, bo to opravil bolje od nas.
Kako poteka
- 01
Odločitev o platformi
Nativno ali večplatformsko, utemeljeno s tem, kaj mora aplikacija početi, in zapisano, preden se karkoli zgradi.
- 02
Specifikacija API-ja
Določimo jo zgodaj, ker po njej gradimo obe platformi in pozna sprememba pomeni popravke v dveh kodnih bazah namesto v eni.
- 03
Razvoj na pravih napravah
Na napravah z več različicami operacijskega sistema in velikostmi zaslona, ne le v simulatorju, saj se razdrobljenost Androida zares pokaže šele na njih.
- 04
Zaprta beta
TestFlight ali interni testni kanal v trgovini Play Store, s poročanjem o sesutjih, ki deluje, še preden aplikacijo oddamo v trgovino.
- 05
Oddaja in predaja
Vnos v trgovini, izvorna koda in postopek izdaje, da naslednja posodobitev ni odvisna od nas.
Vprašanja, ki jih slišimo
Nativna ali večplatformska aplikacija: kako se odločite?
Po tem, česa se aplikacija dotika. Kamera, zvok v ozadju, namenska naprava Bluetooth ali karkoli drugega, kar se močno naslanja na operacijski sistem, nagne odločitev k nativnemu razvoju. Obrazce, sezname, vsebino in običajno navigacijo zgradimo enkrat v ogrodju React Native ali Flutter, ne da bi se čemu odpovedali. Kateri primer je vaš, povemo, preden pripravimo ponudbo.
Ali zgradite tudi zaledje, s katerim aplikacija komunicira?
Pogosto da, v okviru istega sodelovanja. Če zaledje že obstaja, aplikacijo zgradimo zanj. Če ga ni, gre za razvoj izdelka SaaS ali za interno orodje, odvisno od tega, kdo ga uporablja. Obseg obojega določimo skupaj, da se specifikacija API-ja napiše samo enkrat.
Kaj se zgodi, če App Store zavrne aplikacijo?
Popravimo jo in oddamo znova. Opombe za pregled in metapodatke pišemo tako, da se pogostim razlogom za zavrnitev izognemo že pri prvi oddaji. Če pregledovalec opozori na kaj neobičajnega, imamo postopek, po katerem odgovorimo, dokler je pregled še odprt, namesto da bi čakalno vrsto začeli znova.
Čigav je vnos v trgovini App Store in v Play Console?
Vaš. Privzeto objavljamo pod vašimi razvijalskimi računi. Če računa še nimate, ga pomagamo odpreti, a račun in vnos sta vaša.
Newsletter
Novice iz delavnice
Zapisi o tem, kako načrtujemo, gradimo in dostavljamo programsko opremo. Brez kampanj, brez avtomatiziranih nizov sporočil, odjavite pa se lahko z enim klikom.
Načrtujete izdelavo mobilne aplikacije?
Povejte nam, kaj mora aplikacija početi na telefonu, česar spletna stran ne bi zmogla, in ali zaledje, s katerim komunicira, že obstaja. Sporočilo prebere inženir in vam pove, ali je aplikacija sploh pravi odgovor.