9

I've been going through all of the Apple documents and videos related to creating watchOS apps, complications and the like. Carefully studying the flow of updating data and the user interface - yet there's one thing I didn't manage to figure out.

In all of the related videos and documents, it is explained that once a URLSession download task ends, the app should update it's data model and request the system to schedule a snapshot update.

My question is this: where should the data model be stored/persisted? Is it even necessary? Should I use Core Data? An in-memory singleton object? SQLite? UserDefaults? A simple JSON file? What is the preferred way of keeping your data model when writing apps for watchOS?

I am looking to store an array of very simple objects (e.g. a list of contacts, where each contact has a name, an address and a phone number, all of them represented as String objects)

Here's a link to the WWDC 2016 session named "Keeping Your Watch App Up to Date" that explains most of the tasks and best practices I've mentioned - WWDC 2016: Keeping Your Watch App Up to Date

Itamar
  • 1,290
  • 1
  • 18
  • 29
  • Are you looking to create an independent watch app, or a watch app that has a companion iPhone app? – battlmonstr Jun 04 '19 at 20:26
  • A watch app that has a companion iPhone app, but the data I would like to persist is being used to populate the timeline of the watch app's complication – Itamar Jun 04 '19 at 23:05

1 Answers1

6

It is typically best practice to be storing persistent data for watchOS in the cloud or on a companion iPhone app. My guess is that what your source refers to by 'data model' is the data in active storage, i.e. when the app is open. You shouldn't be storing redundant data locally if you don't need to, esp. not for watchOS.

All that being said, watchOS does have access to CoreData and NSCoding methods. I'm not sure about NSUserDefaults - but I wouldn't use that anyway for data storage. (This is a general principle for iOS as well: CoreData is used for data, and UserDefaults for user preferences.) Here is a similar thread explaining how that's done.

But I would highly recommend finding an alternative before storing data on the watch - there just isn't a whole lot of persistent storage space available on there.

EDIT: Check out Apple's WatchKit docs for more details on your options.

jake
  • 1,226
  • 8
  • 14
  • Where would you recommend storing information used to populate a complication's timeline? Is that even necessary or is it something being handled by the system? – Itamar Jun 04 '19 at 23:04
  • 1
    It depends. You could generate complication data on your companion iPhone app and send it to the watch with the WatchConnectivity framework. But according to the docs [you are only allowed to make up to 50 of these transfers per day](https://developer.apple.com/library/archive/documentation/General/Conceptual/WatchKitProgrammingGuide/ManagingComplications.html). Also, if you don't want your watch app to be dependent on your companion app to function, I would recommend using URLSession and either a private server or the CloudKit API for storage. (Edit: added a link above) – jake Jun 04 '19 at 23:31
  • I agree about everything, if this is a companion, this should be just for a cache, and not the source of truth (use another source of truth and sync with it). I'd warn about CoreData. If you can avoid that beast, it is better to not use it. It depends on the data structure and size. If the data size is not in megabytes range, the structure is relatively simple, and it is mostly read-only, it is fine to use something simpler like a simple JSON file or a plist file. – battlmonstr Jun 05 '19 at 08:03
  • I eventually settled on using a simple temporary JSON file, just so the extension's complication data source will be able to access data fetched using a background URLSession... After populating the complication timeline the file is being removed - if you have any insights you can share about the process - please do. – Itamar Jun 06 '19 at 08:54