Thank YOU for taking the time to watch it. I hope you’re enjoy it
An excellent question you bring to us today!
And the answer can be one of the following:
- It’s up to you
- It depends, and
- Whatever you think is best
The reason for that is that there really isn’t an Apple guideline or specific pattern we are to follow, which pretty much leaves it up to us. Let’s, however, break it down a little bit to see when different scenarios might make more sense.
First, whatever approach we take I might go through the route of either creating a
MigrationService class/object, or some sort of extension or wrapper around my model data store or model to actually handle going from one model to the other.
Second, whether you migrate all documents up front or on-demand might come down to: “How many documents does a user have, how large are they, and how long might a migration take?”. If we are talking about 1,000 documents each with a size of 1MB, that’s quite a bit of data to churn through, almost 1GB, and, on an older device like an iPhone 6s or 7, could take a considerable amount of time.
Sticking to this same idea, what are the chances that a user will need to see all 1,000 the next time they open the app? Pretty slim I’d be willing to guess, which makes this a perfect candidate to do it on-demand. I have 1,000 reminder lists (or files/documents in my app sandbox) and I decide to view 5 today. Each time I open one, we spend a few seconds doing the migration to the new model for this file, and voila!
From a user experience perspective you end up with just a few seconds of waiting once per document, no major loading on initial launch after an update, and no need to do it all upfront.
The alternative to this approach would be to do them all up-front the next time you launch the app after an update. When could this be appropriate? Maybe the user just has 10 reminder documents that are 100KB each. Even on an older device doing this migration would take a second or two at most, and you get it out of the door with relative ease.
Finally, still on the second point, there could be scenarios where you need to do this up-front, perhaps from a security perspective, perhaps because you do background processing on these documents or may modify them even without user input (thus needing them up-to-date), or something along those lines.
Third, think about data integrity, and always ensure that whatever approach you take does not put your user data at risk. Any approach with a good user experience is acceptable, even if it takes a little bit of loading time with a spinner or activity indicator on-screen. What is NOT acceptable is losing a user’s data, because they’ll lose trust in your product, and may not come back or recommend it.
The fourth and final point is to maybe incorporate some of these questions when coming to the decision-making process:
- How many files and what average file size can we expect to work with?
- Do users, or us as developers, need everything migrated/converted up-front or can it be done on-demand?
- How time consuming is this going to be? What would the user experience look like in either scenario?
- How do we ensure the user’s data is never at risk?
With those, you can make an informed decision.
One final note I’ll add is that you cannot count on iOS calling your app to run a background process after an app update, on a regular interval, or for sure before the user launches the app the next time. If you code it in a way where the migration will only take place when iOS calls your app for some background task, then you may end up frustrated because it did not happen when you wanted/expected it to.
These are some things I can think of to ensure the decision-making process goes well while also ultimately keeping our focus on the users, and their experience with your app
I hope this helps, and feel free to ask any further questions or follow ups you may think of.
Thanks again for the time and the excellent question!