Autoupdate on iOS are getting app rejected

[James Love]

Just got rejected again by Apple with all of these workarounds in place! Ouch!

[James Love]

Deon,

I am with you, this is crazy. Can't claim to support Apple Apps if this many work arounds is required to make it even functional.

APPERY - Please fix this asap, not being able to release app is costing me money and making me look bad.

Thank you!

James

[James Love]

And I love your system otherwise! I want to build more apps, but if I can't get this resolved I will look for a new platform!

[Illya Stepanov]

Hi Deon, James

We don't like such errors too, but Apple can reject any binary that they considered as inappropriate for their rules. Could you please help us understand the matter of rejection from the Apple side, by providing us full message from them. And also let us know if you're using Appery.io Auto-update feature enabled with your binary packages.

[Lyndon Main]

Since the original poster hasn't updated I will on mine.

I just got a rejection:

2.23 Details On launch and content download, your app stores 26.55MB on the user's iCloud, which does not comply with the iOS Data Storage

Created using appery, then exported to xcode and built there due to current binary build issues. No other changes.

Using auto-update on iOS in ionic app.

I have ZERO experience with xcode. I have sent my project to someone who has some experience to see if they can assist, however any input from the appery dev team would be greatly appreciated. I'm also willing to ask Apple any relevant questions in the rejection conversation if there is a need.

EDIT: Apologies full conversational text:
From Apple
2.23 - Apps must follow the iOS Data Storage Guidelines or they will be rejected
2.23 Details

On launch and content download, your app stores 26.55MB on the user's iCloud, which does not comply with the iOS Data Storage Guidelines.

Next Steps

Please verify that only the content that the user creates using your app, e.g., documents, new files, edits, etc. is backed up by iCloud as required by the iOS Data Storage Guidelines. Also, check that any temporary files used by your app are only stored in the /tmp directory; please remember to remove or delete the files stored in this location when it is determined they are no longer needed.

Data that can be recreated but must persist for proper functioning of your app - or because users expect it to be available for offline use - should be marked with the "do not back up" attribute. For NSURL objects, add the NSURLIsExcludedFromBackupKey attribute to prevent the corresponding file from being backed up. For CFURLRef objects, use the corresponding kCRUFLIsExcludedFromBackupKey attribute.

Resources

To check how much data your app is storing:

Code: Select all

 - Install and launch your app 
 - Go to Settings  iCloud  Storage  Manage Storage 
 - Select your device 
 - If necessary, tap "Show all apps" 
 - Check your app's storage 

For additional information on preventing files from being backed up to iCloud and iTunes, see Technical Q&A 1719: How do I prevent files from being backed up to iCloud and iTunes.

If you have difficulty reproducing a reported issue, please try testing the workflow described in Technical Q&A QA1764: How to reproduce bugs reported against App Store submissions.

If you have code-level questions after utilizing the above resources, you may wish to consult with Apple Developer Technical Support. When the DTS engineer follows up with you, please be ready to provide:

• complete details of your rejection issue(s)
• screenshots
• steps to reproduce the issue(s)
• symbolicated crash logs - if your issue results in a crash log

[Lyndon Main]

A little bit of a further update... when I originally submitted the app and tested it it was 'up to date'.

I noticed that the code that sets the NSURLIsExcludedFromBackupKey to true is called by the setupAssetsWithData function in WebProjectSetupHelper.m

I put a stop on that line, and it never got hit.

To test a hunch I pushed a small app update using auto-update, sure enough it ran through a download and then called that function (which returned success for what it is worth).

So I'm wondering (and as stated I have ZERO idea about ios, objective C or xcode) whether on first install this parameter is not being set but if there is a push update then it is? Is it possible that testing of the fix was done in a scenario where there was a pushed update?

I have no idea if this actually resolves my problem as I do not know enough to test if it is still suffering from the same system that the reviewer found...

[Lyndon Main]

Further update...

I tested this theory further by messaging Apple in the app rejection thread, stating the perceived problem and asking for them to re-test now that I had pushed an update. Whilst I got no specific feedback to confirm the problem had gone away I did wake up to find the app approved and in the app store.

This would suggest I may have been right with my analysis that the issue here lies with an install package with auto-update turned on but no new update pushed since submission.

Appery folk - Can you investigat and confim this? If so we need a fix for that scenario.

[Galyna Abramovych]

Hello Lyndon,

Thank you so much for your investigation and sharing the results with us.
We are working on this issue but it looks like this would take some time.
Anyway, we will respond to you as soon as we have any news.

[sean foley]

Thank you Lyndon! - your post was incredibly helpful. I followed up on your assertion and was able to resolve our own roadblock regarding iOS Data Storage.

Best,
Sean

[roh]

We had the same issue and were able to provide a link to this page to Apple and got approved in 11 hrs and 33 mins. App is now available in the store!
https://fnd.io/#/us/ios-universal-app...

Thank you so much!