Applicazioni per telefono, costruite in modo che la logica possa essere verificata senza telefono.

No. Nessuna delle nostre applicazioni è nell’App Store o in Google Play, ed è corretto chiedere questo per prima cosa. Quello che possiamo mostrare: cinque target di applicazione definiti nello stesso progetto, dei quali quattro per iPhone e uno per macOS, che compilano e si installano sul simulatore, più la suite di logica di 160 verifiche, eseguita su richiesta davanti a Lei. Il blocco alla pubblicazione è `DEVELOPMENT_TEAM` vuoto nella configurazione del progetto, cioè l’assenza di un identificatore di team dell’Apple Developer Program. Su Mac esiste un’identità di firma valida, di tipo sviluppo — sufficiente per l’installazione su dispositivo proprio, non per lo store.

Da nulla, se chiede una prova di pubblicazione — non ne abbiamo una e non la inventiamo. Quello che può verificare è il resto della catena: codice che compila, test che passano, file di privacy presenti, permessi dichiarati, icone e versioni configurate. Il passo che manca è un’iscrizione pagata a un programma Apple, fatta sulla società che possiede l’applicazione. In un progetto di cliente, quell’account è del cliente e si apre all’inizio, proprio per non far sì che sia lui il passo che sorprende qualcuno alla fine.

Dipende dai sensori. Se l’app legge movimento, salute, Bluetooth o fotocamera in tempo reale, nativa — quelle interfacce sono della piattaforma e qualsiasi livello intermedio aggiunge ritardo e nuovi modi di rompersi. Se l’app è essenzialmente moduli, calcoli e schermate di risultato, un solo codice copre iOS, Android e browser da un unico repository. Abbiamo entrambe le varianti nel portafoglio e le scegliamo con un argomento scritto, non per impostazione predefinita.

Tramite il codice comune, sì: lo stesso progetto Expo produce build per Android, con l’icona adattiva e la variante monocromatica richiesta dal sistema, già configurate. Android nativo, in Kotlin, non è nel nostro portafoglio — se un progetto lo richiede, lo diciamo prima, non dopo la firma.

Dal fatto che il nucleo non dipende dallo schermo. I file di analisi si compilano separatamente, con il compilatore Swift, e vengono eseguiti come programma su Mac. L’attuale suite ha 160 verifiche in 16 fasi ed è eseguita in pochi secondi. Ciò che non si può verificare così — come si percepisce una vibrazione, come appare una schermata su un telefono specifico, come si comportano gli auricolari quando escono da un orecchio — si testa sul dispositivo, e si dice chiaramente qual è quale.

Solo se li approva, tipo per tipo, nella schermata Apple, e solo quelli dichiarati. Nel codice la politica è esplicita per ogni tipo di dato: alcuni restano solo sul telefono, altri si leggono da HealthKit, altri possono essere riscritti come allenamento o come sessione di rilassamento. Non si fa diagnosi e i dati non arrivano a noi.

Rimangono sul telefono. Nell’app iOS di riferimento del nostro portfolio non esiste alcuna chiamata di rete — la ricerca di `URLSession` nei sorgenti di quel target restituisce zero risultati. La cronologia viene scritta in un file locale e può essere eliminata dall’app. Quando un progetto ha bisogno di un server, lo costruiamo, ma non lo inseriamo per riflesso.

Si comincia con una verifica di compatibilità, non con un’offerta: quale versione della piattaforma punta, quali dipendenze ha e quali di esse sono ancora mantenute, se il build si riproduce su una macchina pulita, chi possiede l’account sviluppatore e le chiavi. Ci sono progetti in cui la risposta onesta è che riscrivere il nucleo costa meno che mantenerlo.

Su macOS, sì, e dallo stesso nucleo: nel nostro repository principale il target macOS riusa quindici file di logica dall’app per iPhone, come sorgenti condivisi. Windows non è nel portafoglio.