CHI...
Alcuni nostri clienti sono aziende che forniscono servizi tecnologici come lo sviluppo software, l’automazione, l’elettronica e la consulenza ingegneristica di alto livello che vogliono fornire nuovi strumenti nel mondo delle app.
Altri clienti sono invece legati al mondo della pubblicità e della grafica e, per svariati motivi, si trovano a voler realizzare contenuti digitali anche sulle app.
I settori dei clienti per cui abbiamo lavorato li puoi trovare qui
DOVE...
COSA...
Abbiamo realizzato app di vari settori, come puoi vedere qui.
Se hai dubbi sul realizzare un’app nativa o cross-platform leggi anche queste domande.
In caso contrario affianchiamo il cliente nella fase di progettazione del proprio reparto grafico, fornendo l’esperienza maturata in questi anni
COME...
App native / Cross-platform
Le app iOS (Apple) native vengono sviluppate con XCode (o AppCode) in linguaggio Swift (fino agli anni scorsi sviluppavamo con Objective-C)
Le app Android native vengono sviluppate con AndroidStudio in linguaggio Kotlin o Java
Esistono diversi strumenti per realizzare app cross-platform divisi essenzialmente tra “web”, “ibridi” e “nativi”. Noi sviluppiamo “app cross-platform” in modo nativo con l’utilizzo del framework di Facebook React Native o con il toolkit di Google Flutter.
- Utilizzo diretto di tutte le funzionalità (sia hardware che grafiche) messe a disposizione dalla piattaforma
- Possibilità di sfruttare al massimo tutte le risorse native per lo sviluppo e il debugging
- Raggiungibilità massima delle performance
- Nessun limite se non quelli legati al dispositivo stesso
Contro
- Sviluppo da zero per ciascuna piattaforma
- Impossibilità di condividere il codice tra le piattaforme
- Manutenzione diversa per ciascuna piattaforma
- Sviluppo delle funzionalità principali unico per le varie piattaforme
- Manutenzioni di un codice unico
- Tempo di sviluppo su più piattaforme ridotto
Contro
- Limiti di sviluppo dati dal minimo comun denominatore dei limiti delle varie piattaforme
- Performance limitate rispetto alle app native
- Aggiunta di un “livello di astrazione” che complica il debugging e il controllo dell’hardware dei dispositivi
- Necessità di sviluppo dedicato per ciascuna piattaforma per alcuni aspetti specifici
Per un’app che ha necessità di performance avanzate o dell’utilizzo a basso livello di determinate risorse hardware sarà più sensato rivolgersi ad un’app nativa. Oppure, se si sta pensando di realizzare un’app per un unico sistema operativo perché verrà fornita insieme all’hardware (si pensi alle app intra-aziendali, per esempio)
Diversamente, per app che fanno uso di funzionalità “standard” come le foto, i contenuti multimediali comuni e la necessità di aver il prima possibile l’app su più piattaforme, avrà sicuramente più senso proporre la realizzazione di un’app cross-platform
È uso comune considerare il costo di un’app cross-platform come la metà dello sviluppo di due app native. Dalla nostra esperienza possiamo dirvi che non sarà mai così in quanto, seppur si riesca a “risparmiare tempo” sviluppando alcune parti di codice condiviso per più piattaforme, sarà sempre necessario eseguire dei test e dei funzionamenti differenti tra le piattaforme.
Metodologie di pagamento
Nel caso sia stato preventivato un progetto con un costo totale solitamente verranno concordati un pagamento di anticipo alla firma del contratto, dei pagamenti intermedi di stato avanzamento lavori che possono coincidere con i rilasci intermedi delle versioni di prova delle app e un pagamento di saldo finale.
Nel caso sia stato considerata più adeguata una metodologia Agile/Scrum i pagamenti avverranno a seguito del termine di ciascuno Sprint
Lavoro per un cliente terzo
Ci teniamo quanto possibile a partecipare alla progettazione fin dagli inizi, per portare la nostra esperienza a beneficio del prodotto finale fin dai suoi primi passi.
Pubblicazione delle app
È poi possibile distribuire le app direttamente a degli utenti specifici, ma ci sono delle limitazioni diverse in base alla piattaforma.
Per le app iOS è possibile:
   - Rilasciare le app a utenti specifici per un periodo di tempo limitato come “beta testing”
   - Rilasciare le app all’interno della propria azienda con un account di tipo enterprise
Per le app Android è possibile:
   - Rilasciare le app agli utenti in maniera diretta
Sarà quindi necessario fornire una descrizione dell’app, degli screenshot accattivanti e un profilo di prezzo per poter inviare l’app.
Su AppStore di Apple avverrà una “review” dell’app da parte di un team che controlla che l’app soddisfi le guidelines dello store a seguito della quale l’app potrà essere pubblicata. Queste review possono durare da alcuni giorni a qualche settiamana in modo diverso in base ai periodi dell’anno.
Su PlayStore di Google l’app verrà controllata da sistemi automatici che ne controlleranno la non-malevolezza e verrà pubblicata a breve. Queste aziende eseguono dei controlli “spot” delle app per controllare che esse non esulino dai Termini e Condizioni dello store, condizione che porta alla rimozione delle app dallo stesso.
Per l’account di Apple AppStore c’è un costo annuale diverso se si vuole rilasciare le app nello store “pubblico” (99$) o in un proprio store “Enterprise”(299$).
Nel caso di PlayStore di Google c’è un costo una-tantum (25$) per l’apertura dell’account di pubblicazione.
È conveniente iniziare questo processo di “apertura” degli account sulle varie piattaforme molto prima che si abbia bisogno di pubblicare l’app in quanto a volte questo richiede più tempo di quanto si pensi.
Qualora il cliente non volesse espressamente aprire degli account per la pubblicazione si potrà considerare di pubblicare le vostre app tramite gli account di Tiknil.
Facciamo presente che in tutti gli store al di sotto del nome dell’app viene presentato il nome dell’account di chi l’ha pubblicata.
Realizzazione delle app
Quello che proponiamo solitamente sono due approcci, per progetti e team con necessità differenti:
- Waterfall
- Agile/scrum
Il primo consiste nell’analizzare e progettare all’inizio tutto lo sviluppo e realizzare completamente l’app, avviamo dei beta-test solo al termine di tutto lo sviluppo. E’ utile per progetti molto bene definiti o con app gemelle già esistenti o per progetti abbastanza “piccoli”.
Il secondo invece consiste nell’analizzare e progettare “a grandi linee” il progetto nella fase iniziale, ma suddividendone poi in piccoli passi la progettazione-sviluppo-testing specifico, così da realizzare in continuazione dei prototipi che il cliente può vedere, valutare e così pianificare i prossimi passi
Consigliamo sempre ai nostri clienti di dargli l’ importanza che merita per raccogliere preziosi feedback per il successo dell’app.
Esso è chiamato “beta” in quanto l’”alpha” testing è quello che viene effettuato dal team che sviluppa il software stesso in base alle proprie conoscenze e metodologie di utilizzo.
Essa viene implementata sicuramente con la traduzione dei testi, ma anche con la formattazione delle date e degli orari, le unità di misura iniziali, la direzione della lettura del testo e così via.
Questi acquisti sono per lo più riferiti ai “digital-goods”, ovvero ai prodotti digitali legati all’uso dell’app stessa.
Se invece si sta parlando di pagamenti di beni fisici o di servizi erogati “fuori” dall’app è possibile usufruire di diverse modalità di pagamento. Ci sono i sistemi di pagamento legati alla piattaforma specifica (Apple Pay e Google Pay) ma è possibile anche l’integrazione di pagamento tramite carte di credito, PayPal o altri servizi similari.
- Advertisement: solitamente utilizzato dalle app gratuite, il modello di business legato alla pubblicità (banner e video) è sfruttato dalle app che hanno un pubblico ampio e un’uso frequente
- Freemium: app con funzionalità ridotte in versione free e complete in quella a pagamento
- Paid: app a pagamento
- Transactional: app che forniscono la possibilità di pagare per prodotti o servizi e trattengono una fee per ogni transazione
- In-app purchases: app che permettono l’acquisto in-app di funzionalità o digital-goods all’interno dell’app stessa
Manutenzione ed assistenza
- Manutenzione correttiva
- Manutenzione adattiva
Per manutenzione correttiva intendiamo la risoluzione dei bug, termine generico che può indicare un malfunzionamento del sofware in base a condizioni non previste o non identificate durante lo sviluppo e i test.
Per manutenzione adattiva si intende la gestione delle modifiche al software dovute per mantenerne il corretto funzionamento all’aggiornamento dell’ambiente (sistemi operativi, hardware, API di terze parti, etc.).