Vedo due ovvi approcci all'architettura per un'app iOS che ha bisogno di parlare con un server per fare il suo lavoro.
Fai finta di essere un browser web
In base a questo approccio, l'app recupera una porzione di dati (in genere JSON) dal server in risposta a un'azione dell'utente (navigando verso un nuovo controller di visualizzazione, toccando un "Aggiornamento", qualunque cosa), attiva uno spinner o altro indicatore di avanzamento, quindi aggiorna la vista al completamento della richiesta. Le classi "modello" sono mappate direttamente dal JSON in arrivo e possibilmente anche immutabili, e gettate via quando l'utente si sposta dallo schermo che sono state recuperate per popolare.
Sotto la versione "pura" di questo approccio imposti le intestazioni appropriate sul server e lasci che NSURLSession e gli amici gestiscano il caching.
Funziona bene se si può presumere che l'utente abbia una connettività di rete veloce a bassa latenza e in genere legge i dati dal server e non scrive.
Sync
Con l'approccio "sincronizzazione", l'app mantiene un archivio di dati di base locale di oggetti modello da visualizzare all'utente. Si aggiorna in risposta all'azione dell'utente o periodicamente e aggiorna l'interfaccia utente (tramite KVO o simile) quando il modello cambia. Quando l'utente modifica il modello, queste modifiche vengono inviate al server in modo asincrono; ci deve essere un meccanismo per risolvere i conflitti.
Questo approccio è più adatto quando l'app ha bisogno di funzionare offline o in contesti di rete ad alta latenza / lenta, o dove l'utente sta scrivendo molti dati e devono vedere i cambiamenti del modello senza attendere un round-trip del server.
C'è una terza via di mezzo? Cosa succede se ho un'app che è principalmente ma non sempre legge, ma dove ci sono scritture l'utente dovrebbe vedere immediatamente quegli aggiornamenti riflessi nell'interfaccia utente. L'app dovrebbe essere utilizzabile in situazioni di rete scarsa o inesistente (mostrando i dati precedentemente memorizzati nella cache fino a quando una richiesta al server non ha il tempo di rispondere).
Posso ottenere il meglio da entrambi i mondi senza andare a pieno Core-Data-with-sync (che sembra pesante e difficile da correggere) ma senza implementare inavvertitamente un clone buggato e incompleto di Core Data?