Can we make CloudKit only app

Hello,


I have been getting rejected about 8 times on an app that requires CloudKit.

It's just a simple recipe app that posts recipes on CloudKit. Because it was getting rejected saying it needs to have some kind of feature even without CloudKit, I've added local storage option too. But now I've gotten rejected because they said interaction between the CloudKit storage option and local storage option is buggy. I gave up on this app 3 times in the past 6 months, but I keep coming back to this because I just want it on the AppStore since I've put fair amount of work to it.


How are people making use of CloudKit in their apps?

Answered by gomfucius in 612133022
I never released my Recipe app that I mentioned in the initial post, but after 4 years, I'm back again with a new and completely different app and this time I didn't have to provide default data for everything. I just have better error handling and first time user experience than the Recipe app I created 4 years ago. I'm not sure if Apple's guideline changed.

Perhaps it is just for the private data that they require some use outside of CloudKit. My own app uses the public database for its storage of map data and could not run without connecting to CloudKit at least once. That could also be it. Save the recieps locally and sync them to CloudKit when it is available. That way your app can run when it is not connected to CloudKit.

We ran into this rejected too and wound up having to provide default data for everything. I know, it seems weird to have this wealth of data out there on iCloud and everything seems to be leading to cloud based data, but (apparently) it's gotta run for those hold-outs that don't want to use it. You might actually have to provide some recepies in your bundle and update them to your local storage from CloudKit.

The scheme that I used is to always refer to local storage for any views and run the update process as a background operation. The update process overwrites/adds to the local storage so it's available on the next read. It simplifies the code not having to worry about which source you're using at the time. This also covers the 'occasionally connected' scenario. If you allow the end user to write to the data then you'll need to make sure you don't overwrite something they changed. Perhaps store their notes in separate annotation file(s).


HTH,

Mike

I got similar rejection lately because of adopting CloudKit. It's really a very frustrating experience. I highly doubt CloudKit not works very well in review's configuration. That could be the reason why local pre-compiled data is necessary. I saw a developer had similar experience on Stackoverflow too. It's interesting that he got an approval later automatically according to its comment.

http://stackoverflow.com/questions/31401610/cloudkit-not-work-when-apple-review

Accepted Answer
I never released my Recipe app that I mentioned in the initial post, but after 4 years, I'm back again with a new and completely different app and this time I didn't have to provide default data for everything. I just have better error handling and first time user experience than the Recipe app I created 4 years ago. I'm not sure if Apple's guideline changed.
It is a general rule that apps must have some features even when networking (and hence CloudKit) is unavailable. The "features" can be as simple as showing some information when users interact with your app, but you can follow up with App Review to get the final answer.
Getting rejection because of something "buggy" probably means you need to figure out the buggy thing and fix it.
Can we make CloudKit only app
 
 
Q