Eu vejo duas abordagens óbvias para a arquitetura de um aplicativo para iOS que precisa falar com um servidor para fazer seu trabalho.
Finja ser um navegador da web
Sob essa abordagem, o aplicativo busca um bloco de dados (geralmente JSON) do servidor em resposta a uma ação do usuário (navegando para um novo controlador de visualização, tocando em uma "Atualização", o que for), coloca um spinner ou algum outro indicador de progresso e atualiza a visualização quando a solicitação é concluída. As classes "model" são mapeadas diretamente a partir do JSON de entrada e, possivelmente, até mesmo imutáveis, e descartadas quando o usuário sai da tela que foi buscada para preencher.
Na versão "pura" dessa abordagem, você define os cabeçalhos apropriados no servidor e deixa que a NSURLSession e os amigos gerenciem o armazenamento em cache.
Isso funciona bem se você puder assumir que o usuário tem conectividade de rede rápida e de baixa latência e, na maioria das vezes, está lendo dados do servidor e não está escrevendo.
Sincronização
Com a abordagem de "sincronização", o aplicativo mantém um armazenamento de dados do núcleo local de objetos de modelo para exibir ao usuário. Ele atualiza isso em resposta à ação do usuário ou periodicamente e atualiza a interface do usuário (via KVO ou similar) quando o modelo é alterado. Quando o usuário modifica o modelo, essas alterações são enviadas ao servidor de forma assíncrona; deve haver um mecanismo para resolver conflitos.
Essa abordagem é mais adequada quando o aplicativo precisa funcionar off-line ou em contextos de alta latência / rede lenta, ou onde o usuário está gravando muitos dados e precisa ver as alterações no modelo sem esperar pela devolução do servidor.
Existe um terceiro caminho intermediário? E se eu tiver um aplicativo que seja principalmente , mas nem sempre seja lido, mas onde houver gravações, o usuário deverá ver essas atualizações refletidas na IU imediatamente. O aplicativo deve ser utilizável em situações de pouca / nenhuma rede (mostrando todos os dados armazenados anteriormente em cache até que uma solicitação ao servidor tenha tempo de responder).
Posso obter o melhor dos dois mundos sem ter o Core-Data-with-sync completo (que parece pesado e difícil de acertar), mas sem implementar inadvertidamente um clone com bugs e incompletos do Core Data?