Perché paghiamo il costo nascosto della condivisione del codice tra iOS e Android

Condividi questo articolo:


Gli sviluppatori di Dropbox hanno appena pubblicato un post sul blog sulla loro decisione di abbandonare la condivisione del codice C/C++ tra le loro applicazioni iOS e Android. Pur comprendendo la loro decisione, credo anche che post simili di giganti della tecnologia della Silicon Valley possano a volte costruire scorciatoie imprecise nella testa degli sviluppatori e, di conseguenza, danneggiare la ricchezza dell’ecosistema del codice. Ecco perché vorrei contribuire con un breve pezzo sulla nostra esperienza con una configurazione simile.

In sostanza, la mia intenzione è quella di farvi riflettere su quanto segue:

A volte, condividere un codice C/C+++ tra iOS e Android può essere la scelta migliore.

Condivisione del codice tra le applicazioni iOS e Android

Per chiarire le cose fin dall’inizio: Credo che la decisione di Dropbox di allontanarsi da un codebase condiviso sia stata corretta al 100% e ben argomentata nel loro caso.

Ancora oggi, la gente mi chiede ancora informazioni sullo sviluppo mobile multipiattaforma. Le domande più comuni sono rivolte all’uso di Xamarin in questi giorni. La mia risposta predefinita è sempre la stessa:

"Crea due applicazioni native separate".

L’idea di scrivere la maggior parte del codice una volta sembra molto allettante. Ogni volta che le persone cercano di valutare razionalmente la decisione “cross-platform vs. native” (di solito, questo viene fatto scrivendo in modo drammatico pro e contro sulla lavagna in una stanza piena di persone che davvero non vogliono esserci), lo sviluppo cross-platform appare come l’opzione più intelligente dell’universo. Naturalmente – “si può riutilizzare il modello, scrivere una volta sola la logica di business, il networking e la sicurezza, e scrivere l’interfaccia utente per ogni piattaforma separatamente”.

In pratica, questo non funziona mai. Almeno non per le app pubbliche rivolte agli utenti finali – vedo ancora qualche caso d’uso per le app aziendali interne. Se guardo alle ragioni del fallimento dei progetti multipiattaforma, questa è la breve lista:

Prodotti inferiori.

Non si ha mai davvero il tempo di scrivere un’interfaccia utente ben rifinita una volta scelto Xamarin. In teoria si può, ma non si ha mai tempo. Si inizia a fare delle scorciatoie abbastanza presto. Di conseguenza, la qualità delle app è pessima se paragonata a quella delle app scritte in lingua madre. Inoltre, Apple e Google introducono regolarmente nuove funzionalità di sistema che possono essere sfruttate meglio e più rapidamente attraverso le loro lingue native. Le migliori app spesso adottano le nuove funzionalità del sistema operativo mobile in anticipo, portando velocemente valore agli utenti.
Aspetto HR. Gli sviluppatori di telefonia mobile vogliono scrivere le app in Swift e Kotlin, poiché questi sono i linguaggi di tendenza. Ho scoperto che le uniche persone che sono entusiaste di Xamarin sono gli sviluppatori .NET che vogliono prendersi una pausa dal back-end e scrivere un’app. Queste persone spesso riutilizzano i loro schemi di codifica back-end, rendendo la qualità del prodotto ancora peggiore.
Strumenti e documentazione. Apple e Google hanno reso i loro strumenti di sviluppo i migliori per le loro piattaforme, lavorare con Xamarin IDE non è comune. Inoltre, la documentazione “nativa” è di solito molto migliore, c’è sempre qualcosa che manca nella documentazione del framework multipiattaforma.

Dove la condivisione del codice ha un buon senso

Tuttavia, a volte, ci sono buone ragioni per condividere il codice tra iOS e Android codebase. Nel nostro caso, ad esempio, abbiamo deciso di costruire il nostro SDK di autenticazione mobile di tipo bancario open-source (attualmente protegge circa 0,5 milioni di clienti bancari) proprio in questo modo. Condividiamo il codice C/C+++ tra iOS e Android SDK codebase. Crediamo che questa sia stata la scelta giusta e che il nostro prodotto sia significativamente migliore proprio grazie ad esso.

Ci sono stati diversi motivi per cui abbiamo deciso di andare in questa direzione, e tutti i benefici che abbiamo identificato inizialmente sono ancora validi:

  • Gestione della memoria restrittiva. Abbiamo il controllo assoluto sulla gestione della memoria. Qualsiasi chiave crittografica e i risultati intermedi di un calcolo crittografico vengono cancellati dalla memoria non appena non sono necessari, non quando il sistema decide che non lo sono.
  • Evitare gli errori. Anche un piccolo errore di implementazione nella crittografia può avere conseguenze catastrofiche, e quindi cerchiamo di minimizzare la duplicità del codice di crittografia di base.
  • Ambiente di esecuzione separato. Il materiale crittografico grezzo o i risultati intermedi non lasciano mai il nucleo crittografico di basso livello. Isolando la crittografia in una libreria autonoma collegata dinamicamente, siamo in grado di fornire un ambiente di esecuzione sicuro separato, che migliora la conformità normativa della nostra soluzione (per esempio, vedi PSD2/RTS, Capitolo II, Articolo 9, Paragrafo 3).
  • Prestazioni. Anche se questa non è la ragione più importante, siamo in grado di ottenere una migliore performance nel codice nativo (specialmente sui dispositivi Android più lenti). Questo ci permette di fare più loop in KDF, di utilizzare chiavi più lunghe per la cifratura e la firma, …, di utilizzare algoritmi crittografici migliori, ecc.

Siamo riusciti a gestire relativamente bene i suddetti negativi dello sviluppo multipiattaforma.

Prima di tutto, abbiamo un “vantaggio @hvge”. Juraj è uno dei migliori codificatori di basso livello che la regione CEE possa offrire. Gli è piaciuto molto scrivere il nucleo crittografico C/C+++ e tutto ciò che c’è in giro. Ha preparato tutti gli strumenti e ha scelto un ambiente appropriato per la scrittura del core codebase. I nostri sviluppatori iOS e Android SDK possono quindi utilizzare l’IDE e la documentazione delle rispettive piattaforme native, generalmente non hanno bisogno di toccare il codice C/C+++. Quindi non abbiamo avuto problemi di tooling o documentazione per i bit iOS e Android. E infine, nel nostro caso, il riutilizzo del codice e la scrittura della crittografia in C/C++ rendono il nostro prodotto superiore. Fornisce una migliore sicurezza, una migliore conformità e migliori prestazioni, senza perdere nulla per strada…

Dopo più di 10 anni nell'IT, credo che a volte il modo più comune di fare le cose non debba essere il migliore. Vorrei incoraggiare gli sviluppatori e gli architetti del software a stare attenti e a considerare attentamente le loro scelte tecnologiche, piuttosto che usare "scorciatoie" basate sulla lettura dei titoli degli articoli su Twitter.

Il mondo dell’informatica cambia continuamente, il ritmo è incredibile. Come dice Larry Elison: L’industria IT è l’unico settore che è più orientato alla moda che alla moda femminile. Swift è una lingua vecchia di 5 anni, eppure tutte le nuove app per cellulari sono scritte in essa. Un framework JavaScript che uscirà domani è di solito già obsoleto da quello che uscirà la prossima settimana. Immaginate di usare Python solo un paio di anni fa. Saresti un “accademico stramboide”. E guardatelo ora – è uno dei linguaggi più sexy e la scelta di default per tutto ciò che riguarda l’AI/ML. E potrei continuare…

Forse un giorno lo sviluppo mobile multipiattaforma sarà l’opzione migliore. In ogni caso, ha già molti buoni casi d’uso, anche oggi.


Per ulteriori informazioni visita il sito: immagi.net

Condividi questo articolo: