How to approach 'caching' in iOS development with Swift

You are on the right track with considering CoreData and NSCache.

There will be tradeoffs. In reducing your network activity, you will be looking to utilize device memory and/or the file system. Usage of any of these resources should be carefully considered. All of the options below are viable and it may be worthwhile to do some measuring with instruments to see the impact of each approach.

On paper here is how I would weigh them given your requirements.

NSCache

Pros

  • Simple API, low effort to implement
  • Easy to reason about

Cons

  • If the data that you need is no longer cached then you will have to fire another network request. That said, you could implement the NSCacheDelegate and respond when an “object is about to be evicted or removed from the cache.” see NSCacheDelegate

Core Data

Pros

  • Can be used as an in-memory store (not just for persisting data to disk)
  • Can scale to accommodate more complex data modelling, querying and storage requirements
  • Has Xcode tooling support

Cons

  • Initially it would require more effort to implement than the other options
  • As mentioned by Duncan C, there is a learning curve
  • Adds another abstraction that may require more thought down the road than either the NSCache or plist

File System (plist or some other format)

Pros

  • Low effort to implement
  • Easy to reason about

Cons

  • Introduces file system I/O operations. From a performance standpoint this is not desirable if there are other options.
  • Doesn’t easily scale (if your needs change)

What you've shown is an array of dictionaries.

If the data you are caching doesn't change that much, and when it changes the whole thing changes then you don't really need an SQL database.

You could simply save your array to a plist file using the NSArray method func write(toFile:atomically:)

If you write the array to the documents directory then it won't go away. If you write it to the caches directory then it could be flushed at a later time.

It has the advantage of being dirt-simple. It has the disadvantage that it doesn't lend itself to updating some contents and not others. You save the whole thing, and then you load the whole thing. Loading the whole thing into memory is not a big deal for 10,000 text-only records. If it's 250 bytes each, that's a little less than 2.5 MB - quite reasonable.

Core Data is very powerful, but also very complex, and has a steep learning curve. It takes a while to wrap your head around how to use it.