Quali API/librerie iOS e Android usano aziende come Smule per creare app musicali?

Versione breve: Perché sviluppare per Android fa schifo. Ho appena implementato una funzione in un'app sia per iOS che per Android. Su iOS, mi ci sono volute 23 righe di codice e pochi minuti. Su Android, mi ci sono volute 567 righe di codice e 3 giorni.

Versione lunga: In primo luogo, lasciatemi dire che le altre risposte che parlano di quanto poco denaro ci sia in Android sono almeno parzialmente vere, ma (per me personalmente) non è così terribile come lo fanno sembrare. Faccio una quantità non banale di soldi dalle mie applicazioni Android, ma ne faccio più del doppio con le mie applicazioni iOS.

Ma veniamo al punto principale... Android fa schifo. So che questo suona come un argomento religioso, ma abbiate pazienza.

Per essere chiari, come utente Android, probabilmente non sperimenterete mai nulla che vi faccia pensare che Android faccia schifo. Tuttavia, essere uno sviluppatore Android è miserabile perché il sottostante AndroidOS è di generazioni indietro rispetto a iOS.

Apple lavora diligentemente per far sì che iOS FUNZIONI molto bene E sia bello allo stesso tempo. Molti dei pezzi di caramelle visive che Apple include in iOS aiutano effettivamente l'usabilità, non sono solo per mostrare. Comunicano sottilmente informazioni all'utente in modo che l'utente capisca cosa sta accadendo e perché le cose stanno accadendo.

Tuttavia, Google si è concentrata principalmente sul far funzionare le basi di Android perché apprezzava l'idea dell'espressione individuale da parte degli sviluppatori, al contrario di Apple che voleva che le applicazioni avessero un look and feel coerente. (Il problema è che la stragrande maggioranza degli sviluppatori non sono addestrati in usabilità o design grafico e quindi le loro applicazioni avevano un aspetto rozzo e funzionavano in modo rozzo. Intorno al periodo di Android 4.x Google ha capito di avere un vero problema perché non ci sono due applicazioni Android che funzionano allo stesso modo perché ogni sviluppatore ha un approccio diverso. Hanno iniziato a cercare di standardizzare l'UI e hanno preso alcuni dei loro grafici per cercare di rendere gli elementi visivi più belli. Non era comunque un granché.

Ecco un esempio specifico della differenza di sforzo dal punto di vista dello sviluppatore. Ho una funzione in una delle mie applicazioni iOS e volevo assicurarmi che questa funzione fosse anche nella versione Android.

La funzione consiste nel toccare+tenere premuto su un elemento in un elenco/tabella e poi trascinarlo verso l'alto o verso il basso per riordinare gli elementi nella tabella (drag and drop). In iOS, questo mi ha richiesto solo 23 righe di codice perché essenzialmente tutto è già integrato nel sistema iOS sottostante. L'oggetto UITableView (gli elenchi a scorrimento che vedete ovunque in iOS) sa già come rispondere al tap+hold e sa già come animare lo spostamento della riga mentre trascinate il dito... e già applica una bella ombra in basso mentre trascinate la riga... e sa già come animare le altre righe della tabella affinché si spostino mentre trascinate questa riga, ecc. Ha anche già dei ganci integrati in modo che il sistema possa chiedere al mio codice: L'utente deve poter trascinare questa riga? L'utente può far cadere questa riga tra x e y? e mi dirà L'utente ha appena trascinato e fatto cadere questa riga in questa nuova posizione, il che permette al mio codice di rispondere a quell'evento.

Ecco perché il mio codice iOS è lungo solo 23 righe. Tutto quello che devo fare è scrivere il codice che dice quali righe sono trascinabili e poi rispondere al loro abbandono della riga in modo da poter aggiornare i dati sottostanti. Ho implementato questa funzione in pochi minuti su iOS.

Ma Android non fa nulla di tutto ciò, ed è per questo che il mio codice Android è lungo 567 righe e mi ci sono voluti 3 giorni per farlo funzionare. Per fortuna, in questo caso particolare, non ho dovuto scrivere tutto quel codice da solo perché TANTI altri sviluppatori Android si sono lamentati della mancanza di questa caratteristica incredibilmente basilare. In risposta, Google aveva pubblicato del "codice di esempio" che mostrava come creare manualmente una forma rudimentale del trascinamento. Naturalmente, quel codice non era aggiornato perché era stato scritto per Android 4 e non funzionava per Android 5, 6, o 7 (7.x è la versione attuale al momento in cui scriviamo).

E il loro codice di esempio non prevedeva alcuna funzione per controllare se certe righe nell'elenco/tabella dovessero poter essere trascinate. Non includeva alcun controllo se una riga dovesse essere lasciata cadere in una certa posizione. Non includeva la possibilità di impostare un callback in modo che il vostro codice potesse rispondere al riordino. Ho dovuto prendere tutto il loro codice rudimentale e pieno di bug e cercare di migliorarlo in modo che facesse di più della versione per bambini dell'asilo della funzione.

Questo significava che ho speso più giorni per produrre una funzione che non funziona nemmeno bene o sembra buona come la funzione che già esiste in iOS e mi ha preso solo pochi minuti. Ho fatto uno screenshot del codice di entrambi e li ho messi fianco a fianco in modo da poterlo usare per spiegare la differenza. (vedi sotto. Lo screenshot include i commenti nel codice, ma non ho contato i commenti nel mio conteggio delle linee.)

Quando ho un cliente che vuole la sua app sia su iOS che su Android, gli dico che la versione per Android richiederà 4 volte più tempo per essere prodotta e sarà solo circa l'80% più buona. Quando faccio il preventivo, determino quanto ci vorrà per produrre l'app per iOS e poi moltiplico quel numero per 2,5 per coprire la versione per Android... il che non paga - veramente - tutto il mio tempo sulla versione per Android, ma far pagare 4 volte la somma sembra ridicolo per loro perché non sanno com'è.