Currently, my app offers a free version in which only two items can be created. After reaching this limit, users are prompted to purchase a subscription. The logic for triggering the subscription view relies on checking the count of items.
However, this approach encounters difficulties when combined with iCloud Core Data.
One requirement is that user accounts cannot be created, so the item count cannot be stored on my server.
I’ve considered several alternatives:
- Disabling item creation until iCloud syncing is complete. While it may be possible to listen to iCloud events, this might not provide the best user experience.
- Storing the item count in
UserDefaults
, but this would not synchronize with iCloud. - Using
NSUbiquitousKeyValueStore
, which is a key-value data structure that utilizes iCloud. However, I’m unsure about the speed of data fetching from this storage type and whether it’s suitable for my use case. - Completely disabling iCloud for non-subscribers, though this is an extreme solution I’d prefer to avoid for now.
- Considering
NSPersistentHistoryTrackingKey
andNSPersistentStoreRemoteChangeNotificationPostOptionKey
. With this approach, when the app is installed, if any items are already created before iCloud syncing, I can delete the existing local data upon receiving the persistence notification and replace it with the data from iCloud.
Has anyone encountered a similar challenge?
Items cannot be created if the item limit is reached, taking into consideration that data is stored in iCloud. This requirement must also cover the edge case where the app is reinstalled.