L'agenzia propone "Flutter sia per iOS che per Android": questa scelta mi vincolerà in futuro?

Con gli aggiornamenti di iOS, anche se raramente, possono verificarsi piccoli disallineamenti grafici quando cambiano il motore di rendering o i componenti di sistema. Fate inserire assolutamente nel preventivo una clausola di supporto per gli aggiornamenti di compatibilità per almeno 1 anno a ogni major release di iOS.

L'anno scorso abbiamo lanciato la nostra app per la logistica con Flutter. Invece di pagare due team nativi separati, abbiamo speso 210.000 TL con una sola squadra. Oggi abbiamo 12.000 utenti attivi e su tutti i feedback solo 2 segnalavano rallentamenti dell'interfaccia, tra l'altro su dispositivi vecchi.

Molte agenzie vendono il 'codice unico per due piattaforme' per abbattere i costi, ma poi ignorano totalmente le linee guida di iOS. Se l'app aperta su iPhone sembra un'applicazione Android gli utenti Apple vi riempiranno subito di recensioni negative.

Chiedete all'agenzia almeno tre app sviluppate in Flutter che hanno già pubblicato sull'App Store. Scaricatele sul vostro iPhone e testate di persona la fluidità dello scroll i tempi di reazione all'apertura/chiusura della tastiera e le animazioni di transizione.

I vostri tecnici sul campo dovranno lavorare offline? Avete chiesto come gestiranno il salvataggio dei dati sul dispositivo e la logica di sincronizzazione? Di solito il vero collo di bottiglia non è l'interfaccia ma la sincronizzazione del database locale.

noi la usiamo da due anni e zero problemi. se andavamo sul nativo il budget minimo raddoppiava, all'inizio nn serve proprio.

PS: è stato chiesto qui sotto, ho scritto la risposta nel secondo messaggio.

Se in futuro doveste passare al nativo non vorrà dire che l'app ha fallito, anzi: significherà che il business è cresciuto parecchio. cioè quando arriverà quel momento avrete comunque le risorse per finanziare il nuovo codice, per ora puntate sul time-to-market.

Passando al nativo butti via il codice dell'interfaccia, ma l'architettura backend resta intatta; 280.000 TL sono un budget di test più che ragionevole per questo rischio.

Parlo dal lato opposto, io sono dalla parte dei fornitori. La risposta varia molto in base al settore, non esiste una regola generale.

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

concordo pienamente ma boh ogni punto non scritto è un punto che in futuro le due parti ricorderanno diversamente.

è tutot scusate se mi sono dilungato.

Ci proverò.

Avete ragione, sono passato anch'io per la stessa strada. Il calendario dei pagamenti va legato alle fasi del lavoro, non alle date.

Se il contratto non specifica la proprietà del codice, al momento di andarsene non hai potere contrattuale. Io seguirei questa strada.

C'è una trappola qui, non posso non segnalarla. L'errore commesso da sviluppo ios con flutter è generalmente reversibile ma costoso.

In generale è corretto, ma manca un pezzo. Se è la prima volta, inizia in piccolo, il ridimensionamento viene dopo.

Io seguirei questa strada.

Sono d'accordo, anzi vorrei sottolinearlo. Cercare di farlo da soli è la strada più costosa.

Confermato dall'esperienza.

A me è successo l'esatto contrario per questo scrivo. boh se è la prima volta inizia in piccolo, il ridimensionamento viene dopo.

L'offerta più economica è spesso quella meno ponderata.

Ho vissuto la stessa cosa... cioè non abbiate paura di chiedere chi non chiede paga sempre di più.

Quando prendete una decisione, scrivete anche lo scenario peggiore, non solo quello migliore. È tutto, scusate se mi sono dilungato.

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

Se lo scope cresce, devono crescere o i tempi o il budget. Non c'è una terza opzione. Io seguirei questa strada.