La scelta del linguaggio per un'app iOS influisce sul preventivo dell'agenzia e sui costi di manutenzione?

Avete definito chiaramente cosa farà di preciso l'applicazione? Ci saranno scansioni di codici a barre via Bluetooth, tracciamento GPS in tempo reale in background o animazioni complesse della fotocamera? Se ci sono solo operazioni standard su database come elenco prodotti, conferma ordini e invio di notifiche, forse non vale la pena spendere quei 110.000 TL di differenza per il native. Ma se c'è un'integrazione hardware pesante, il cross-platform vi costerà molto di più in seguito.

L'anno scorso abbiamo fatto sviluppare un'app per gli ordini simile. Abbiamo speso 180.000 TL scegliendo il cross-platform e per il primo anno è andato tutto liscio. Tuttavia, dopo un aggiornamento del sistema operativo, il modulo di scansione dei codici a barre con la fotocamera ha smesso di funzionare. L'agenzia ci ha detto che la libreria open source utilizzata non veniva più aggiornata e che dovevano riscrivere il modulo da zero, chiedendoci un extra di 45.000 TL. Più della metà del risparmio iniziale è andata in fumo per un singolo fix.

Sul mercato l'idea che "se è native è per forza solido" viene un po' sopravvalutata. Oggi anche molte schermate di app bancarie e di grandi e-commerce girano su soluzioni cross-platform o interfacce web-based. Più che il linguaggio usato dall'agenzia, conta quanto il team sia senior su quel linguaggio. Un'app nativa scritta con una pessima architettura genera molti più costi di manutenzione rispetto a un cross-platform ben strutturato.

Dal punto di vista tecnico, l'aspetto fondamentale a cui fare attenzione è la gestione delle dipendenze. Nei linguaggi cross-platform c'è un livello bridge tra il core dell'applicazione e il sistema operativo. Questo livello può causare ritardi a ogni major update del sistema operativo. Chiedete all'agenzia quanti plugin di terze parti utilizzeranno al di fuori dei package manager ufficiali. Più alto è il numero di plugin esterni, più lieviteranno i costi di aggiornamento futuri.

Clausole da far inserire nel capitolato prima di sedersi al tavolo con l'agenzia: 1) Verificare che il codice sorgente sia scritto secondo gli standard di clean architecture e che la documentazione interna al codice sia completa. 2) Rendere obbligatorio l'uso di una versione del linguaggio aggiornata e con supporto a lungo termine (LTS). 3) Alla consegna del progetto, fornire l'elenco completo di licenze e versioni di tutte le librerie esterne. 4) Predisporre una guida passo-passo per l'installazione, affinché un altro team possa rimettere in piedi il progetto qualora l'agenzia dovesse interrompere il supporto.

ci siamo trovati nello stesso identico dilemma.. ma poi quando abbiamo cercato programmatori freelance abbiamo notto questo: la maggior parte di chi sviluppa in hybrid è nuova sul mercato e conosce entrambe le piattaforme a metà. quando le cose si sono messe male siamo stati costretti a passare al native... se il budget lo permette e l'obiettivo è solo ios, andare direttamente sul nativo fatto bene ti fa dormire sonni tranquilli.

Nel valutare le offerte non dovreste considerare l'ambito del contratto di manutenzione e assistenza come una cosa separata dal linguaggio del progetto. A prescindere dal linguaggio di programmazione, una clausola di SLA ben definita nel contratto e il blocco del canone di manutenzione mensile tuteleranno la vostra azienda in caso di cambi di sviluppatori o di aggiornamenti di versione. Assicuratevi assolutamente di inserire a contratto anche il trasferimento incondizionato della proprietà del codice.

Due anni fa abbiamo scelto la via più economica per un'app simile dedicata alla vendita all'ingrosso. Ci siamo detti: tanto è solo un catalogo semplice con la schermata degli ordini. L'agenzia ha completato il lavoro, ce l'ha consegnato e dopo otto mesi ha chiuso i battenti. Abbiamo portato i codici a un altro programmatore. Il ragazzo ha aperto il progetto e ha detto che era stato scritto con una versione vecchissima di un framework non più supportato, e che facevamo prima a riscriverlo da zero che a sistemarlo. Quel giorno abbiamo capito che non bisogna valutare solo il linguaggio, ma la sostenibilità che c'è dietro.

Corretto. Le credenziali di accesso devono essere create a nome dell'azienda, non con account personali.

Le soluzioni che funzionano su piccola scala crollano quando si cresce, l'ho imparato tardi. Se scrivete qui il risultato, sarà utile anche ad altri.

Grazie mille, era la risposta che cercavo. Quando decidiamo senza misurare, finiamo sempre nello stesso punto.

Spero che le sia utile.

ha ragione.

Ha ragione. Nei sistemi ereditati, la cosa più costosa sono le dipendenze sconosciute.

Confermato dall'esperienza.

Approfondisco l'aspetto tecnico. Se cerchi di cambiare tutto insieme, niente si stabilizza.

Gran parte del tempo perso si accumula nelle pratiche in attesa di approvazione. Io seguirei questa strada.

può approfondire un po'? onestamente il fatto che tutti facciano una cosa non significa che sia qeulla giusta.

buon lavoro.

Può approfondire un po'? L'offerta più economica è spesso quella meno ponderata.

Questa è la mia opinione non la scrivo come verità assoluta.

Parlo dal lato opposto io sono dalla parte dei fornitori. onestamente chiunque abbia fretta su linguaggio app ios si blocca nello stesso punto.

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

Non ho alcuna esperienza in materia di linguaggio app ios, quindi chiedo. Cercare di farlo da soli è la strada più costosa.

C'è un punto che mi incuriosisce. Introdurre un processo per le richieste di modifica non rallenta il lavoro, lo accelera.

Questa è la mia opinione, non la scrivo come verità assoluta.