Arenaways: l'app per iOS e Android
Case study
- Il mio ruolo
- Ho progettato e sviluppato l'app e, nel backend, la registrazione dei dispositivi e l'invio delle notifiche push. Ho impostato test, CI e build automatiche con EAS.
- Durata
- Da aprile 2026, in corso
Il problema
Arenaways aveva già un sito con prenotazione e treni in tempo reale. Ai passeggeri mancava qualcosa da tenere in tasca: un'app con le stesse funzioni, gli avvisi sulla propria linea senza dover controllare il sito e i contenuti che il team pubblica dal backoffice. I dati dei treni arrivano da RFI e cambiano di minuto in minuto, in viaggio la connessione va e viene, e il pagamento doveva restare sul checkout di Turnit, senza un secondo motore di vendita da mantenere.
Cosa ho fatto e perché
- Biglietti senza un secondo motore di vendita: tratta, data e passeggeri si scelgono nell'app, poi il checkout di Turnit si apre già compilato nel browser integrato. Accanto all'acquisto ci sono le informazioni su tariffe, abbonamenti e Carta BIP.
- Treni in tempo reale: ricerca per numero o per tratta sui dati di RFI, con fermate, orari, ritardi, binari, ultimo rilevamento, bus sostitutivi e soppressioni. Le tratte della linea e le ultime ricerche sono a un tocco, e un treno o una tratta si condividono con un link.
- Cache sì, orari vecchi no: news, pagine e stazioni restano sul telefono per 24 ore e si leggono anche senza rete. I dati dei treni non vengono mai salvati, così riaprendo l'app non compaiono ritardi di ore prima. Quando la connessione torna, le richieste ripartono da sole.
- Notifiche push per linea: l'utente sceglie le linee da seguire e il backend manda l'avviso solo a quei dispositivi, al massimo una volta ogni 15 minuti per lo stesso avviso, ed elimina i token non più validi. Le preferenze si cambiano solo con un segreto legato al dispositivo. Toccando la notifica si apre la schermata giusta, dopo il controllo del contenuto.
- Un link, la stessa schermata: i link del sito a treni, tratte, news e posizioni aperte aprono l'app sulla stessa pagina, su iOS e su Android. Dentro l'app, i link nei testi verso pagine che l'app ha già restano nell'app invece di aprire il browser.
- Contenuti dal backoffice: news, offerte, posizioni aperte e assistenza sono quelli del sito, scritti una volta sola. Il backend può anche chiedere di aggiornare l'app quando una versione è troppo vecchia.
- Release ripetibili: TypeScript strict, 283 test con Jest e CI su ogni pull request. Pubblicare una release su GitHub avvia le build con EAS e l'invio a TestFlight e Google Play. Errori e crash arrivano su Sentry.
Risultati
- iOS + Androidun solo codice, su App Store e Google Play
- 283test automatici, eseguiti a ogni pull request
- 15 minal massimo una notifica per avviso, solo a chi segue la linea
- 24 hdi news e pagine leggibili anche senza rete
- 0versioni da pubblicare per cambiare news, offerte e assistenza
- 1 releasesu GitHub avvia build e invio a TestFlight e Google Play
Stack in evidenza
- Expo SDK 54
- React Native
- Expo Router
- TypeScript
- TanStack Query
- NativeWind
- expo-notifications + Expo Push
- EAS Build e Submit
- Jest
- Sentry
Hai un progetto simile? Parliamone.
ScrivimiChi viaggia con Arenaways apre l'app, sceglie tratta, data e passeggeri e compra il biglietto. Segue il treno fermata per fermata, con ritardi, binari e ultimo rilevamento, e riceve una notifica quando c'è un avviso sulla linea che ha scelto. News, offerte, posizioni aperte e pagine di assistenza arrivano dal backoffice di Arenaways e sono gli stessi contenuti del sito: per cambiarli non serve pubblicare una nuova versione.
Cosa porto a un'agenzia o a una PMI da questo progetto
- Un'app React Native portata dalla prima build agli store e mantenuta con release regolari.
- Dati in tempo reale trattati con cura: la cache tiene i contenuti, mai gli orari dei treni.
- Notifiche push che non diventano rumore: solo per le linee scelte, con un limite di frequenza lato server.
Realizzato per Arenaways in collaborazione con DVC Consulting