Il nostro sviluppatore consiglia Kotlin per l'app Android: è la scelta giusta?

Da un punto di vista tecnico, anche Kotlin ormai offre soluzioni moderne per la condivisione del codice multipiattaforma. Si possono scrivere la logica di business, le chiamate di rete e i modelli di database in un unico linguaggio, mantenendo le interfacce native. Il tuo sviluppatore intendeva questo o ha proposto una struttura pura solo per Android? È un dettaglio che dovresti chiarire.

Nel mercato di New York, la stragrande maggioranza del target sport e fitness usa iPhone. Spendere 22.000 dollari solo per Android e lanciare senza iOS sarebbe un suicidio commerciale. Invece di dimezzare il budget, ti conviene accordarti con uno sviluppatore che lavora su un unico codebase per uscire su entrambi gli store con la stessa cifra.

Noi abbiamo rilasciato un'app di prenotazione simile con un framework multipiattaforma e un solo sviluppatore in 4 mesi, spendendo in totale 18.000 dollari per essere sia su Android che su iOS. È online da due anni e il costo di manutenzione mensile non supera i 1.500 dollari di supporto per un singolo dev. Se fossimo partiti con due linguaggi nativi separati, ci sarebbe costato almeno 3.500 dollari al mese.

lo sviluppatore sta palesemente cercando di venderti il linguaggio che conosce e con cui si trova comodo. puntare per forza sul nativo per un'app di prenotazioni è un lusso inutile. fate un unico codebase per entrambe le piattaforme e via non buttate soldi.

Nella vostra app ci saranno funzionalità molto legate all'hardware come l'integrazione con smartwatch streaming video in diretta o il conteggio delle ripetizioni tramite l'accelerometro del telefono? Se la risposta è no e si tratta solo di calendari elenchi e schermate di pagamento, con quale necessità tecnica il vostro sviluppatore ha motivato la scelta del linguaggio nativo?

Prima di buttarvi a capofitto sulle proposte multipiattaforma, tenete a mente anche questo: con gli aggiornamenti dei sistemi operativi le librerie ibride a volte tardano ad aggiornarsi e i plugin di terze parti possono dare errori. Tuttavia, per un'app di prenotazioni fitness questi problemi sono decisamente un rischio minore rispetto all'impatto economico di sviluppare in due linguaggi nativi diversi.

Da founder capisco benissimo che tu voglia fidarti della guida del tuo sviluppatore... Ma le scelte tecniche non devono tenere in ostaggio il modello di business. Parlagli chiaramente: chiedigli "Non ho né i soldi né il tempo per due app separate possiamo lanciare questo prodotto su entrambi gli store con un solo codice?". Se non accetta cercati qualcuno con esperienza su piattaforme cross-platform.

In sintesi la situazione è chiara: Kotlin è il miglior linguaggio nativo per Android, ma per una startup di prenotazioni con funzioni standard come la vostra non ha senso escludere iOS e raddoppiare i costi. In una fase iniziale, un unico codebase è sempre la scelta commerciale più corretta.

Ho vissuto la stessa cosa. Introdurre un processo per le richieste di modifica non rallenta il lavoro, lo accelera.

Io seguirei questa strada.

Preso nota, grazie. Gran parte del tempo perso si accumula nelle pratiche in attesa di approvazione.

Io seguirei questa strada.

Grazie mille, mi è stato molto utile. Prendere appunti per due settimane dà risultati migliori rispetto a una stima di sei mesi.

Confermato dall'esperienza.

Ho vissuto la stessa cosa due anni fa. Ogni punto non scritto è un punto che in futuro le due parti ricorderanno diversamente.

Le decisioni affrettate diventano decisioni da correggere sei mesi dopo.

La discussione si è dispersa, la riassumo. I primi tre mesi vanno bene, i problemi emergono al quarto mese.

Spero che le sia utile.

A me è successo l'esatto contrario, per questo scrivo. L'errore commesso da linguaggio sviluppo app android è generalmente reversibile ma costoso.

Sono curioso di sapere se qualcuno lo fa in modo diverso.

Breve riassunto per i nuovi arrivati: La risposta varia molto in base al settore non esiste una regola generale.

Correggetemi se sbaglio.

c'è una pate che non ho capito poi ogni "ci pensiamo dopo" in riunione significa lavoro non preventivato.

le credenziali di accesso devono essere create a nome dell'azienda non con account personali. boh spero che le sia utile.

Grazie per averlo scritto, è proprio così. Il codice senza documentazione di installazione non è tuo, anche se ce l'hai in mano.

È tutto, scusate se mi sono dilungato.

Riassumo l'argomento perché sono state date diverse risposte. Nei sistemi ereditati, la cosa più costosa sono le dipendenze sconosciute.

Se avete domande, scrivete, rispondo per quanto possibile.