Reason for App Store Rejection? [solved]

[Jellobus]

Hi All,

I have searched the common reasons for iOS app store rejection. so I like to double check my implementation before I submit my app to apple.

"Don't abuse the iOS file system. Since iOS 5.1, Apple doesn't allow apps to save data to the device that normally gets backed up by iCloud (without the user's permission). Instead, save this data to the device's cache. You can use Local Storage (which uses the cache), but just be aware that anything saved here may be overwritten."

The app will save a file in the device. It work flawlessly. but will it be a reason for rejection?

I use script something like,

Code: Select all

set the Text1 of stack "specialFolderPath("documents")/data.db" to fld "data"
save stack "specialFolderPath("documents")/data.db"

[jmburnod]

Hi,
In this post http://forums.livecode.com/viewtopic.php?f=7&t=26784
Klaus said

please keep in mind that Apple stirctly forbids downloading "code"
and stacks are considered code by Apple unfortunately.

Maybe Apple consider that create a stack is like downloading code ?

Best regards
Jean-Marc

[dave.kilroy]

Hi @Jellobus

In your first line of code are you trying to set the "Text1" custom property of a stack (however this stack is called "data.db") to the contents of fld "data"? If so then does this really work? I've never heard of a stack with a ".db" file extension ... Same thing for your second line of code - are you trying to save the stack file in the documents folder? In which case could it be the ".db" extension that is causing problems.

Saving files, even binary files, to specialFolderPath("documents") should be fine so I don't think there should be any sandboxing/security issues - downloading files that Apple thinks might be 'executable' during a version update is another thing, Apple doesn't like that at all.

I'm guessing you are using a stackfile which you keep in the documents folder as a data store, this is a very common thing to do and should work fine - I'm also guessing that when you debug it on the device (using lots of 'answer' commands) you'll find the problem - but that ".db" file extension does worry me...

Code: Select all

set the Text1 of stack "specialFolderPath("documents")/data.db" to fld "data"
save stack "specialFolderPath("documents")/data.db"

EDIT

Just reread your original query which was about App Store Rejection - apologies, I'm now going to assume that those lines of code do work...

It is strange they are objecting to what you have saved in your documents folder - maybe their reviewer also didn't like the ".db" file extension But files in that folder can indeed be backed up by iTunes. If you were to instead move to specialFolderPath("cache") everything should still work for you with the exception that files would not be backed up by iTunes - doing this would be one way of keeping them happy (as long as it didn't mess up some other part of your app). I think there is also a 'flag' you can set with individual files that marks them to iTunes as ones that shouldn't be backed up - at the moment I can't remember what it was, if I do I'll make another edit here - but for a quick fix I'd keep their reviewer happy and move your stuff to "cache"

[Jellobus]

Hi Jean and Dave,

I hope I don't have to change script but I will definitely change all scripts if I have to.
The main stack creates data.db when it launches and this data.db stack is used for saving any info a user wants to keep. (e.g. journals, game scores, etc) The stack "data.db" is created with this simple code below

Code: Select all

create stack "data.db"

then, all info from the main stack is saved as properties of the stack "data.db" when the session is finished. No download involved in this mechanism, only many texts are saved as properties of the data.db. Does Apple really consider it as downloading? Simply, putting .txt file in the document folder can be used instead of this. Should I replace it with .txt instead?

Thanks a lot in advance!

Louis

[dave.kilroy]

Hi both

Couple of things, you don't want to treat specialFolderPath() as text so I'm guessing in your actual app you don't have it inside quotes

Code: Select all

set the Text1 of stack "specialFolderPath("documents")/data.db" to fld "data"
save stack "specialFolderPath("documents")/data.db"

Secondly when I tried to save a stack with a ".db" file extension OS X thought it was a sqlite database (BTW I'm amazed it worked at all without the ".livecode" extension)

Thirdly in my tests I couldn't get a stack to save unless I used the "as <path-to-filename>" syntax - do you do something similar in your app?:

Code: Select all

     put specialFolderPath("documents") & slash & "data.db" into tPath
     save stack "data.db" as tPath
     if there is a file tPath then answer "yep"
     else answer "nope"

And fourthly - saving files to 'documents' in iOS should be fine and not seen as downloading as it is taking place within the app's sandbox.

As to what you should do - it seems you have an app store reviewer who wants you to change something - so change the file extension, file type (e.g. a .txt file) or file location - if it was me I would try changing the file extension first, file location second and the file type third (but I don't know your situation obviously)

Let us know how you get on...

Dave

PS: I tested this on El Cap, LC 8.0.0(dp16), Xcode 7.2.1, iOS 9..3.1

[Jellobus]

Hi Dave,

I haven't submit the app yet. No one asked me to change the script. I am just too worry about the rejection from Apple and want to fix as much as I can before submitting it. Are you sure that this script is fine to implement into the app? should I still need to change file extension and location??
or am I too chicken?

Cheers,

Louis

[dave.kilroy]

Aha so you haven't submitted the app yet!!!!

My only comment on your code (which has taught me a lot in creation and saving of stacks) is, if you are going to create a stack and then in the next line make it invisible, you might be better off to lock the screen and then later unlock it so that there is no chance of a flicker, alternatively you could:

Code: Select all

create invisible stack "data.db"

And apart from that the only thing that gives me the collywobbles is the ".db" in the name (remember how my operating system here thought the "data.db" stack was a sqlite database)

But seeing as you haven't yet submitted the app then you should be ok - when I submit apps I just about always have sqlite dbs in "documents" which get written to by the app. When uploading to iTunesConnect you'll be using a tool within Xcode called the 'Application Loader' and this carries out quite a few checks before uploading.

Your app will probably fly through despite my worrying about ".db"

BTW you might find this website of interest while waiting for your app review to complete (current wait time is 4 days) http://appreviewtimes.com

Kind regards

Dave

PS: filling out all the bits for the app on iTunesConnect is a big pain, give yourself time to complete all the bits - it is better than it used to be but is still tricky

[Jellobus]

Hi Dave,

Yes, "create invisible stack" code is more efficient. I will definitely use it. I am really glad that we all learn each other.
Thanks a lot for your advice!

Cheers,

Louis

[dave.kilroy]

Hi Louis - yaas this forum is all about learning from each other - good luck with the submission!

[jacque]

(BTW I'm amazed it worked at all without the ".livecode" extension)

LC doesn't care about extensions, the stack can have any extension or none at all. Extensions are just to allow the OS to make file associations. When LC opens a stack it doesn't use the extension to determine the validity, it reads the file format.

I have frequently invented my own extensions for stacks in certain projects. If you don't associate them with your app in the OS they won't open by double clicking but LC opens them fine from within the IDE or a script.

[dave.kilroy]

Ah yes it's starting to come back to me now - I remember once working with another developer who give stacks he was using as data containers a file extension that related to the project name - and the client was pleased...