I'm from a development team at a large Telecom, I'm migrating an API within an app, the new version of the api will have a completely new model, with a new structure, the data coming from the api is recorded in the coredata and then extracted from this to be displayed by the viewcontroller (cashe), the client asked to do it in stages, and the first stage is to migrate to the next api to deliver value quickly, I am in doubt if I implement the entire model at this first moment, having to change the entire structure that extracts the model from coredata to display, or if I just create a mapping from the new model to the old one (mapping the new values to the old ones), just to record the data, maintaining the structure of extracting data from coredata and display, leaving this to be removed in a next step. Which of the two ways will take more work? Changing the model and also the recording and extracting structure will be much more costly, which will extend the work to unacceptable deadlines? One of the goals is to completely remove the CoreData. I'm in the process of renaming all the fields, changing the model's structure and the model's recording and extraction flows, but I'm thinking that this work will be huge, not having any value delivery in the short term.
How to Migrate iOS Aplication api
It's a bit hard to understand your question. Having it in a long paragraph, without any structure, does not ease reading.
But here your customer is commanding. So you need effectively to build the new user facing API?
the structure is probably this:
_____ __________ ________
| | | | | Core |
user code -------| API | ----- | Model | -------- | Data |
| ___ | |__________| |________|
So if the priority is to five access to the new API, you should just keep all the rest and just create the new API on the old Model, if that's possible. You may have to extend the Model to support some API.
_____ __________ ________
| New | | | | Core |
user code -------| API | ----- | Model | -------- | Data |
| ___ | |__________| |________|
That will be a less risky approach than changing everything at the same time.
Once the New API is in place and stabilised, you may change the Model progressively (no need to change evrything at once). In each step of model rewriting, you could get read of some Core Data parts. But hard to say precisely with the limited info wyou gave.
The new api is already ready, and returns the new model all changed, my concern is to take the path of changing the structure of recording and reading of the coredata, and it is an impossible job to complete, changing the names of the fields everywhere , this counting that I can only test it at the end, which can be complicated later to correct all the errors.
So your initial post was completely misleading.
.
it is an impossible job to complete
Then don't do it !