App Store rejection update - PLEASE RESPOND!

[Death Mountain Crater]

I sent through a message several days ago which has yet to be
responded to or posted.

I have an application which has been rejected due to "data storage
issues" - issues that are not related to anything i have personally
written in the app and are caused by misuse of the /Documents
directory in apps that use iOS5.

I would appreciate the slightest response - or just pass my message
through to the group so anyone who may have had the issue can answer.

[Dmitry Soldatenkov]

Please send me full Apple reject message.

--
You received this message because you are subscribed to the Google Groups "rhomobile" group.
To post to this group, send email to rhom...@googlegroups.com.
To unsubscribe from this group, send email to rhomobile+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rhomobile?hl=en.

--

Best regards,
  Dmitry A. Soldatenkov
  E-mail: dmi...@rhomobile.com
  Skype: soldatenkoff

[Death Mountain Crater]

Rejected Jan 16, 2012 10:13 AM
Reasons for Rejection:
2.23 Apps must follow the iOS Data Storage Guidelines or they will be
rejected
Jan 16, 2012 10:13 AM. From Apple.
2.23

We found that your app does not follow the iOS Data Storage
Guidelines, which is not in compliance with the App Store Review
Guidelines.

In particular, we found that the app is storing too much data, which
is not user-generated and can be recreated, in the incorrect location.

The iOS Data Storage Guidelines specify:

"1. Only documents and other data that is user-generated, or that
cannot otherwise be recreated by your application, should be stored in
the /Documents directory and will be automatically backed up by
iCloud.

2. Data that can be downloaded again or regenerated should be stored
in the /Library/Caches directory. Examples of files you should put in
the Caches directory include database cache files and downloadable
content, such as that used by magazine, newspaper, and map
applications.

3. Data that is used only temporarily should be stored in the /tmp
directory. Although these files are not backed up to iCloud, remember
to delete those files when you are done with them so that they do not
continue to consume space on the user’s device.

4. Use the "do not back up" attribute for specifying files that should
remain on device, even in low storage situations. Use this attribute
with data that can be recreated but needs to persist even in low
storage situations for proper functioning of your app or because
customers expect it to be available during offline use. This attribute
works on marked files regardless of what directory they are in,
including the Documents directory. These files will not be purged and
will not be included in the user's iCloud or iTunes backup. Because
these files do use on-device storage space, your app is responsible
for monitoring and purging these files periodically."

For example, only content that the user creates using your app, e.g.,
documents, new files, edits, etc., may be stored in the /Documents
directory - and backed up by iCloud.

Temporary files used by your app should only be stored in the /tmp
directory; please remember to delete the files stored in this location
when the user exits the app.

Data that can be recreated but must persist for proper functioning of
your app - or because customers expect it to be available for offline
use - should be marked with the "do not back up" attribute. For more
information, please see Technical Q&A 1719: How do I prevent files
from being backed up to iCloud and iTunes?.

It would be appropriate to revise your app to meet the requirements of
the iOS Data Storage Guidelines.

For discrete code-level questions, you may wish to consult with Apple
Developer Technical Support. Please be sure to include any
symbolicated crash logs, screenshots, or steps to reproduce the issues
when you submit your request. For information on how to symbolicate
and read a crash log, please see Tech Note TN2151 Understanding and
Analyzing iPhone OS Application Crash Reports.

[Death Mountain Crater]

I should note that this is a stock rhomobile app using the RHOM
database to store daily data for a yearly calendar. nothing special.
no cached or downloaded files - everything is included in the initial
bundle

[Jon Tara]

Well, that sucks... It would seem we need two databases, then, if we are using the database as a cache.

If the database is encrypted, how would they know what is in it? But of course if it seems too large given the app functionality, then perhaps they will question it.

I can't seem to see the content of the sandbox on my device. Organizer is showing the Documents directory empty? But I look in the simulator directories, and I am able to see the files there. I do see the database there under Documents/db.

One additional thing that could be a problem is that there are symbolic links in the Documents directory to the application bundle app, public, lib directories. I gather from the above that iCloud will back these up (is is not smart enough to ignore symbolic links?), and that is going to violate the guidelines. At minimum, these will need the Do Not Backup attribute. It would be better if they don't need to be there at all.

[Jon Tara]

Oops, it's not such an easy fix to simply use the Do Not Backup attribute. That will only work if your app's minimum version requirement is 5.01:

Important The new "do not back up" attribute will only be used by iOS 5.0.1 or later. On iOS 5.0 and earlier, applications will need to store their data in <Application_Home>/Library/Caches to avoid having it backed up. Since this attribute is ignored on older systems, you will need to insure your app complies with the iOS Data Storage Guidelines on all versions of iOS that your application supports.

[Adrian]

I think your application conflicts with: 

2. Data that can be downloaded again or regenerated should be stored 

in the /Library/Caches directory. Examples of files you should put in

the Caches directory include database cache files and downloadable

content, such as that used by magazine, newspaper, and map applications.

The problem is, that you are storing data, which can be downloaded again when need. Either you find a method to write the data into the proper storage (this might also be a Rhodes problem) or remove the "caching" functionality from your app.

A possible workaround might be, that the requested data could be cached automagically from the local browser. But I don't know if this might work.

[Mark]

 

But i think your application confilcts with :

 

1. Only documents and other data that is user-generated, or that
cannot otherwise be recreated by your application, should be stored in
the /Documents directory and will be automatically backed up by
iCloud.

 

because you are not downloading any file and not storing any other file anywhere. but you are storing the database on daily basis for end year report or calendar. And our DB folder is exists in  "Application HOME/Documents/db". so, we can't store any file or data in this folder.

 

i am also stuck same place.

 

is there any fix for this.

[Death Mountain Crater]

Yeah - thats the sticky thing. it's a pre-filled database with no
user input so it's not like i can just "redownload it".

I am ok with regenerating it if it gets deleted from cache, though
thats kind of ridiculous since the info in the database *is* the
application and pre-filling it from a dump takes ~45 seconds or more
on the fastest iOS device.

Also note that i rewote some of the Rhodes gem to instead store
everything in /Library/Private Documents and flagging it "do not back
up" -- but that was also rejected by the App Store because the "do not
back up" flag is only available on 5.0.1.

[Raúl Alejandro Véjar Llugany]

Maybe flagging those objects as "set :partition, :app" or ":local" should put those DBs outside the documents folder...

--
You received this message because you are subscribed to the Google Groups "rhomobile" group.

[evgeny vovchenko]

we are working on this issue

 

---

[Dmitry Soldatenkov]

Hi,

ticket: https://www.pivotaltracker.com/story/show/23623001

Now we working for redesign our folder structure on iOS platform.

[Jon Tara]

Can the OP tell me the size of the database, and confirm that this is essentially "read-only" data? That is, this data is initially created for the user and either downloaded or included in the build. I'm guessing that Apple just hasn't noticed until a large database came along.

+1 on Raul's suggestion. I don't know if SQLite supports partitioning data into different locations.

- The best solution would be one that allows each table to specified to go into either documents, cache, or tmp. To further future-proof it, it would be good to also be able to specify the path explicitly.

- If that's not possible, then some way to create separate databases in different locations, which would be limiting vs. a partitioned database.

- The least favorable solution would be to simply move the database to cache, or allow it to be placed in either cache or documents. I note that RhoConnect users shouldn't need their database in documents, since their data is backed-up by RhoConnect.

Just did a little checking, and SQLite doesn't support partitioning per se. It stores the entire database in a single file. But it does have ATTACH and DETACH SQL command that allow cross-database queries.

I also did a bit of poking around to see under what circumstances the /Library/Caches directory might be cleared. The only situation I have come across is on a full system restore. iTunes removes the content of this directory during a full system restore. But it definitely will happen in that circumstance.  So, at application startup, I think you need to check to see if files are missing from there and re-create them.

[Raúl Alejandro Véjar Llugany]

The partition flag is already creating 3 different database files (I'm sure because I use this to deploy prepopulated application data as well), the issue is that all 3 are being left in the documents folder when packaged...

You can also check this partitioning happening through rhosimulator

--
You received this message because you are subscribed to the Google Groups "rhomobile" group.

To view this discussion on the web visit https://groups.google.com/d/msg/rhomobile/-/j727KZH0Ah4J.

[Jon Tara]

Ah, I hadn't noticed that Rhom already supports partitioning the database into separate files. It's a bit buried in the docs. ;)

[Death Mountain Crater]

Jon:  the db is 3MB and is indeed read only.

On Wed, Jan 18, 2012 at 1:29 PM, Jon Tara <jtara-g...@spamex.com> wrote:

--
You received this message because you are subscribed to the Google Groups "rhomobile" group.

To view this discussion on the web visit https://groups.google.com/d/msg/rhomobile/-/j727KZH0Ah4J.

[Nick]

Are all Rhomobile apps affected or only the ones that store app
generated data?

On Jan 18, 4:51 pm, Death Mountain Crater <pixelatedzomb...@gmail.com>
wrote:

> Jon:  the db is 3MB and is indeed read only.
>

[Raúl Alejandro Véjar Llugany]

It seems the problem is there for all apps, but specially for those that have pre-loaded databases packaged with them. Apple just started now enforcing this policy...

[HAYAKAWA Takashi]

i received the same rejection for my app that has no pre-load db.

2012/1/20 Raúl Alejandro Véjar Llugany <raul....@gmail.com>:

--
HAYAKAWA Takashi 早川　卓
mailto:haya...@ackcell.com
http://www.ackcell.com

[Nick]

I got one update accepted on January 11th 2012. Hopefully my next one
won't be blocked.

On Jan 19, 5:08 pm, Raúl Alejandro Véjar Llugany

[Dmitry Soldatenkov]

Hi,

We commit fix for that issue (to Master version):

https://github.com/rhomobile/rhodes/commit/8ddf6abefc123bac0f12b86b56b62870c228936e

But we still continue testing it in different situations.

Now all files except database placed in /Library/Private Documents/     - in this folder files do not removed during clean but also files from this folder do not bakup in iCloud etc.

Database still stay in Documents - in Documents files bakup in iCloud etc.

Also few very small support files also placed in Documents (we use it for control version of application etc.)

Database files will change by user interaction - this files is must be bakup etc.

You can send to Apple this explanation if your application will rejected by topic issue.

Also now you can get the Documents folder root ("user path") for save any other files (if they should be bakup - not temporary and other data).

Example :

       fileNameW = File.join(Rho::RhoApplication::get_user_path(), 'tempfile.txt')

       f = File.new(fileNameW, 'w+')

       f.write('my own file !')

       f.close  

Application root now in  /Library/Private Documents/

You should change your application code only if you work with files directly and that files should be bakup - now you should work with that files in "user" folder.

If you working only with databases - you should not make any change sin your application code.

[Jerrod Blavos]

Much appreciated!  I will resubmit and let everyone know what happens.

[Nick]

Is this available in the rhodes pre release gem or do we have to
download master?

On Jan 19, 9:36 pm, Jerrod Blavos <pixelatedzomb...@gmail.com> wrote:
> Much appreciated!  I will resubmit and let everyone know what happens.
>
> On Jan 19, 2012, at 9:32 PM, Dmitry Soldatenkov wrote:
>
>
>
>
>
>
>
> > Hi,
>
> > We commit fix for that issue (to Master version):

> >https://github.com/rhomobile/rhodes/commit/8ddf6abefc123bac0f12b86b56...

>
> > But we still continue testing it in different situations.
>
> > Now all files except database placed in /Library/Private Documents/     - in this folder files do not removed during clean but also files from this folder do not bakup in iCloud etc.
>
> > Database still stay in Documents - in Documents files bakup in iCloud etc.
>
> > Also few very small support files also placed in Documents (we use it for control version of application etc.)
>
> > Database files will change by user interaction - this files is must be bakup etc.
> > You can send to Apple this explanation if your application will rejected by topic issue.
>
> > Also now you can get the Documents folder root ("user path") for save any other files (if they should be bakup - not temporary and other data).
> > Example :
> >        fileNameW = File.join(Rho::RhoApplication::get_user_path(), 'tempfile.txt')
> >        f = File.new(fileNameW, 'w+')
> >        f.write('my own file !')
> >        f.close
>
> > Application root now in  /Library/Private Documents/
>
> > You should change your application code only if you work with files directly and that files should be bakup - now you should work with that files in "user" folder.
> > If you working only with databases - you should not make any change sin your application code.
>

> > For more options, visit this group athttp://groups.google.com/group/rhomobile?hl=en.

>
> > --
>
> > Best regards,
> >   Dmitry A. Soldatenkov

> >   E-mail: dmit...@rhomobile.com

[evgeny vovchenko]

you have to clone master:
http://docs.rhomobile.com/rhodes/build#setting-up-rhodes-source-code

-----Original Message-----
From: rhom...@googlegroups.com [mailto:rhom...@googlegroups.com] On

[Raúl Alejandro Véjar Llugany]

Does this affect updates to existing applications? In other words, if I publish an update with this change will the existing app loose any data or already downloaded files?

[Dmitry Soldatenkov]

Hi,

All previous databases will stay with upgrade (except preloaded bases contain in application bundle).

If you make any files in application root etc. They will stay too, but now you should use user_path for access to this files (they still stay in Documents/apps folder)

2012/1/23 Raúl Alejandro Véjar Llugany <raul....@gmail.com>

  E-mail: dmi...@rhomobile.com
  Skype: soldatenkoff

[Raúl Alejandro Véjar Llugany]

1) By "except preloaded bases contain in application bundle", do you mean that if my app contained a preloaded database this existing database will not be accesible once the update is installed?

2) So my understanding is that any existing files will not be moved by the update process but now they should be located by using Rho::RhoApplication::get_user_path(). Newly downladed files can be put in either place depending on the nature of the file (temporary/cache/user data vs permanent files) Is this correct?

[Mark]

Hi Dmitry Soldatenkov,

 

 

i follow all your instrsuctions like :

 

1. Take clone from master branch of rhodes.

2. Use user_path for application root.

3. Store all downloadable data in "/Library/Private Documents/"

4. There are no database activities.

 

 

After all above steps, i re-submitted my application in Apple Store and i got rejection from Apple with same error message.

 

Can you please give me direction to resolve this issue.

 

Please refer to attach file for message details.

 

 

[evgeny vovchenko]

Did you modify application build.yml sdk path? To point to rhodes master folder?

 

---

--

You received this message because you are subscribed to the Google Groups "rhomobile" group.

To view this discussion on the web visit https://groups.google.com/d/msg/rhomobile/-/nyavjtrTXqwJ.

[evgeny vovchenko]

Do you have preloaded database?

 

---

--

You received this message because you are subscribed to the Google Groups "rhomobile" group.

To view this discussion on the web visit https://groups.google.com/d/msg/rhomobile/-/ZCew2QCShqIJ.

[Mukesh Kumar]

Nope, I don’t have any DB activity even never change anything in Controller’s Class file. I am storing all files in ApplicationHOME/Library/Private Documents/.

But I got rejection from Apple.

 

Thanks & Regards,

Mukesh Kumar

Ativio India

+91-9971082803

*:muk...@ativio.com

www.ativio.com

Don’t Print Untill Its Necessary, Save Paper   

[Mukesh Kumar]

Nope, I didn’t change in build.yml because I am already using Rhodes version 3.3.1.

 

I just replace the files in platform, lib and spec directory as well as Rakefile  as instructed on following link

 

https://github.com/rhomobile/rhodes/commit/8ddf6abefc123bac0f12b86b56b62870c228936e

 

what I am thinking is, as per their instruction number 2. We have to store data only in /Library/Caches/ directory if we download something from server.

 

2. Data that can be downloaded again or regenerated should be stored in the /Library/Caches directory. Examples of files you should put in the Caches directory include database cache files and downloadable content, such as that used by magazine, newspaper, and map applications.

 

 

I also tried to store downloaded image files in /Library/Caches directory but I don’t know why my application is not able to access the files from Caches directory. This is same issue which I was facing when our root folder was in /Documents/ directory and I want to access the files from /Library/ directory. But after the master branch update that issue is resolved and I can access the files from /Library/ directory.

 

So, I just want to know. Is this the scope accessibility issue. Because when I check  that “is file exists” then it returns “TRUE” for same value and If I used that value to display the images in application then it shows image not found.

 

Can anyone help me for this.

 

 

Thanks & Regards,

Mukesh Kumar

Ativio India

+91-9971082803

*:muk...@ativio.com

www.ativio.com

Don’t Print Untill Its Necessary, Save Paper   

 

From: rhom...@googlegroups.com [mailto:rhom...@googlegroups.com] On Behalf Of evgeny vovchenko

Sent: Wednesday, January 25, 2012 12:46 PM
To: rhom...@googlegroups.com

[evgeny vovchenko]

after cloen rhodes master

you should modify build.yml:

sdk: <rhodes_folder>

 

---

[Mukesh Kumar]

But I saw all files are properly replaced and now creation of application’s data location had been changed from “/Documents/”  to “/Library/Private Documents/”. And most important “user_path” function is also working as per Dmitry’s email.

[evgeny vovchenko]

clean emulator. run application and see what inside Documents folder

[Mukesh Kumar]

I have done that lots of time. There is following chart of files and directory.

 

/Documents

hash

name

apps/

db / syncdbuser.sqlite

         syncdbuser.sqlite.version

        db-files/

        syncdb_java.triggers

       syncdb.schema

       syncdb.triggers

rhologpath.txt

[Jon Tara]

I really think we are going to need to be able to split the database so that we can store some tables in one place and some in the other, not all in one place. We need to be able to store them on a table-by-table basis in either /Documents, /Documents/Private, or /Library/Caches.

Apple just started enforcing this because this only became an issue starting with iOS 5..0.1.

I shouldn't have to say that this threatens Rhodes' viability, and should be given top priority.

[Dmitry Soldatenkov]

Hi,

After inner discuss we decide move all files except databases into /Library/Caches folder because we can easy restore that files in runtime on application start.

Databases still stay in /Documents folder the same with old version of Rhodes based application (in this case you will not lost data during upgrade old application).

Also if you want make any your files - just make it in "user" folder - the user folder placed in /Documents folder and will bakup with databases too.

If you make files in application root in your old application - now that files can be read in "user" folder.

Example :

fileNameW = File.join(Rho::RhoApplication::get_user_path(), 'tempfile.txt')

f = File.new(fileNameW, 'w+')

f.write('my own file !')

f.close  

Now when application start first time only database files created in /Document folder because this files is changed by any user database working - please write about it to Apple if they reject you application again.

Please try resubmit your application and write us about result.Use Master version of Rhodes for it.

Thank you. 

--
You received this message because you are subscribed to the Google Groups "rhomobile" group.

To view this discussion on the web visit https://groups.google.com/d/msg/rhomobile/-/z0PkELFBabMJ.

To post to this group, send email to rhom...@googlegroups.com.
To unsubscribe from this group, send email to rhomobile+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rhomobile?hl=en.

--

[Oli]

just pulled the latest master from git and tried creating a folder
with the following command:
File.join(Rho::RhoApplication::get_user_path() + 'loaded_files',
'tempfile.txt')

but the device log returns:
Net| pullFile: cannot create file :/var/mobile/Applications/BDE2095A-
BF9D-4619-BEE0-7FBD58EEB25F/Documents/apps/loaded_files/7486530027.txt

what am i missing?

On Jan 25, 2:10 pm, Dmitry Soldatenkov <dmit...@rhomobile.com> wrote:
> Hi,
>
> After inner discuss we decide move all files except databases into
> /Library/Caches folder because we can easy restore that files in runtime on
> application start.
> Databases still stay in /Documents folder the same with old version of
> Rhodes based application (in this case you will not lost data during
> upgrade old application).
> Also if you want make any your files - just make it in "user" folder - the
> user folder placed in /Documents folder and will bakup with databases too.
> If you make files in application root in your old application - now that
> files can be read in "user" folder.
>
> Example :
>
> fileNameW = File.join(Rho::RhoApplication::get_user_path(), 'tempfile.txt')
> f = File.new(fileNameW, 'w+')
> f.write('my own file !')
> f.close
>
> Now when application start first time only database files created in
> /Document folder because this files is changed by any user database working
> - please write about it to Apple if they reject you application again.
>
> Please try resubmit your application and write us about result.Use Master
> version of Rhodes for it.
>
> Thank you.
>

> On Wed, Jan 25, 2012 at 8:30 PM, Jon Tara <jtara-google...@spamex.com>wrote:
>
>
>
>
>
>
>
>
>
> > I really think we are going to need to be able to split the database so
> > that we can store some tables in one place and some in the other, not all
> > in one place. We need to be able to store them on a table-by-table basis in
> > either /Documents, /Documents/Private, or /Library/Caches.
>
> > Apple just started enforcing this because this only became an issue
> > starting with iOS 5..0.1.
>
> > I shouldn't have to say that this threatens Rhodes' viability, and should
> > be given top priority.
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "rhomobile" group.
> > To view this discussion on the web visit
> >https://groups.google.com/d/msg/rhomobile/-/z0PkELFBabMJ.
>
> > To post to this group, send email to rhom...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > rhomobile+...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/rhomobile?hl=en.
>
> --
>
> Best regards,
>   Dmitry A. Soldatenkov

>   E-mail: dmit...@rhomobile.com
>   Skype: soldatenkoff

[Dmitry Soldatenkov]

Hi,

You should make a folder before make a file inside that folder.

This is workable code :

        Dir.mkdir(File.join(Rho::RhoApplication::get_user_path(),'loaded_files'))

        fileNameW = File.join(Rho::RhoApplication::get_user_path(),'loaded_files','tempfile.txt')

f = File.new(fileNameW, 'w+')

f.write('my own file !')

f.close  

  E-mail: dmi...@rhomobile.com
  Skype: soldatenkoff

[Jon Tara]

Databases still stay in /Documents folder the same with old version of Rhodes

This might be a solution for the one application in question here, but this does not provide a generalized solution. It will be impossible for Rhodes users to comply with the requirements and still use the database. If we have, for example, data that can be refreshed from our server, it should be stored in cache. That means either we have to modify Rhodes to move the database to cache, or else store the data in our own files, not in the database, thus losing database functionality.

Moving the database to cache would comply with the requirement, but then what if we also have data that is user-generated? Now I can't use the database to store that, because it might be lost. An inelegant solution would be to periodically archive it to /Documents.

I have an app coming up that stores both reference data and user data, and it is going to be sensitive to approval time. I will not be able to comply with the requirement. I do not want to rely on Apple not noticing. I want to know that I have complied and be able to tell Apple with a straight face that I have complied if questioned. I also cannot have the risk of the app being pulled later if Apple notices.

Please give us a solution that lets us split the database into at least two places, preferably three. I understand that RhoMobile sells a database synchronization solution, and might be reluctant now to let us split it so that data can be backed-up by iCloud. But at least give us the ability to split some tables in /Documents/Private and some tables in /Library/Caches. But it would be best if we can also target /Documents and have iCloud backup. I doubt anyone is using RhoConnect solely for backup reasons. They are using it to connect to Enterprise data sources.

[Raúl Alejandro Véjar Llugany]

+ 1 to Jon's suggestion, I also believe it is more aligned with what Apple is requesting. To add to this I believe the existing database partitioning could be used to create this separation as they already follow a similar model:

 

User, Local: user data

App: static data

 

Cached data is outside this classification but my feeling is that it should be an extra flag that can indicate where to store the app partition

Also, please take into account how a new version of an app with rhodes using this schema will affect 'updating' an existing app in the device

--

You received this message because you are subscribed to the Google Groups "rhomobile" group.

To view this discussion on the web visit https://groups.google.com/d/msg/rhomobile/-/LgaefXIeRoUJ.

[Dmitry Soldatenkov]

What the problem in store database in Documents ? It is user modified files and can contain user entered data.

Just try send to Apple description about it is not read-only database but live database where user store his data.

I think Apple just make simple check - see any files after first start application (before user enter any data), but I see in Internet info about - if you send yo Apple description about that files they pass your application.

General our application not required full time connect to server. In this case user can modify database and quit from application. And after some time make sync. In that time data must be stored in Documents, because this is user data and it must not be cleared instead of files in Caches.

2012/1/26 Raúl Alejandro Véjar Llugany <raul....@gmail.com>

[Raúl Alejandro Véjar Llugany]

The fact that Rhodes allows to modify these files doesn't mean that they are purpossed for that. We are talking here about static/cached databases that are packaged with the app / downloaded from the server; things that are designed to be static throught the app's cycle, not modified by the user.

 

You could argue the same thing about any file in the documents folder, I can always 'potentially' modify it so it doesn't qualify as cached...

 

I think the point Apple is trying to make here is that our Rhodes apps are too fat on the Documents folder and all that is being backup by iTunes so we should partition our app's data according to it's volatility. We could potentially make it past the Appstore check, but they do have a point in that they are providing a mechanism to take care of this and we are ignoring it by lumping all our data as 'user data'

[Jon Tara]

What the problem in store database in Documents ? It is user modified files and can contain user entered data.

You are making assumptions about what developers will put in the database. I might want to cache data that can be easily restored from a server, but store it in the database for quick local access, and want to use the database because it is convenient and allows me to do relational operations, filtering, etc.

Imagine a game. You might store object geometry, scoring criteria, etc. etc. in the database for easy retrieval, but this is not stuff that needs to be backed-up in the cloud. It is not static data, because it might be periodically refreshed. And it could be quite large. In this case, this should be stored in /Documents/Private. You do not want to lose it because it is extensive, essential, and it would be very inconvenient to the user if it had to be re-downloaded. But there is no need to back it up.

An app for reading Wikipedia might cache recently-read pages in the database. This can be easily recreated. It does not have to be backed-up. This probably should be stored in /Library/Caches. It is not essential, but it could be extensive. It would be a minor inconvenience if it were lost. It would simply slow-down access to already-read articles.

And, clearly, many apps have a need for storing user-generated data in a database, and you might want this backed-up. This should go in /Documents.

Any app might combine all three types of data in the database.

Apple has clearly communicated that going forward they want app authors to sort their data this way in their apps.

Just try send to Apple description about it is not read-only database but live database where user store his data.

I think Apple just make simple check

That would not be complying with the spirit of the requirement. As a professional, I could not in good conscious represent to a client that I have complied with the App Store requirements. I would have to use some other product besides Rhodes, or else design my own database implementation. The app would always have hanging over it the potential for rejection. Apple has a history of rejecting already-accepted apps well after their intial acceptance once they discover that the app is not complying with their requirements. 

[Dmitry Soldatenkov]

What do you think about simple functionality for set database attribute in run-time - "read-only"/"read-write" - we can just set/remove Apple's special attribute "do not bakup" for database files.

Apple write about - you can have not user created files in Documents, but application should marked it by "do not bakup" attribute.

--

You received this message because you are subscribed to the Google Groups "rhomobile" group.

To view this discussion on the web visit https://groups.google.com/d/msg/rhomobile/-/8RdUCNJS4esJ.

To post to this group, send email to rhom...@googlegroups.com.
To unsubscribe from this group, send email to rhomobile+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rhomobile?hl=en.

[Jon Tara]

What do you think about simple functionality for set database attribute in run-time - "read-only"/"read-write"

Not sure what you mean. Can you clarify? I wouldn't want the database to be literally read-only.

we can just set/remove Apple's special attribute "do not bakup" for database files. Apple write about - you can have not user created files in Documents, but application should marked it by "do not bakup" attribute.

The app would have to have minimum version requirement of 5.01, then, because if installed on earlier version, "do not backup" is not available before 5.01. That might be ok in a year. :(

[Death Mountain Crater]

Ok - so my last revision was approved and went live last night.  I ended up getting through just by moving everything to the /Library/Private Documents directory and marking it as do not backup - but as we've said in the thread  my app was a special case in that the data was intended to be completely read only and didn't need to be backed up.

[Mukesh Kumar]

Hi,

 

It means now all files will be stored in /Library/Caches/Private Documents folder instead of /Library/Private Documents ?

 

Can you send me the link of your committed branch of master. And which path we will get when we will use get_user_path() function ?

 

After these all above changes, should I re-submitted my app ?  I don’t want one more rejections history from Apple. Now client is on High Peak of temper.

 

From: rhom...@googlegroups.com [mailto:rhom...@googlegroups.com] On Behalf Of Dmitry Soldatenkov

Sent: Thursday, January 26, 2012 4:49 AM
To: rhom...@googlegroups.com

[Mukesh Kumar]

Hi everybody,

 

Finally my App got Approved from Apple. Thanks  thanks a lot to all of you….

 

 

From: rhom...@googlegroups.com [mailto:rhom...@googlegroups.com] On Behalf Of Death Mountain Crater

Sent: Friday, January 27, 2012 3:24 AM
To: rhom...@googlegroups.com

--

You received this message because you are subscribed to the Google Groups "rhomobile" group.

[buck nasti]

Was this issue ever resolved?  

My app was just rejected for the same reason.  I've pasted Apple rejection notice below.  I am prepopulating the db when the app initially launches and then downloading some images to this path Rho::RhoApplication::get_base_app_path().  Should I be using a user_path instead for images.  Please help.

2.23

Additionally, we found that your app does not follow the iOS Data Storage Guidelines, which is required per the App Store Review Guidelines.

In particular, we found that on launch and/or content download, your app stores 2.6 MB. To check how much data your app is storing:

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

The iOS Data Storage Guidelines indicate that only content that the user creates using your app, e.g., documents, new files, edits, etc., should be backed up by iCloud. 

Temporary files used by your app should only be stored in the /tmp directory; please remember to delete the files stored in this location when the user exits the app.

Data that can be recreated but must persist for proper functioning of your app - or because customers 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 kCFURLIsExcludedFromBackupKey attribute. 

[buck nasti]

Rhodes currently stores its db in the /Documents directory which violates apple guidelines.  Below is my conversation with apple support.  Looks like I will need to manually move my db.  Anyone else run into this issue with Apple?

> 2) App violates storage guidelines.
>    I am using the Rhodes framework and my db is prepopulated the first
> time it is launched and used to store important user data and preferences
> that will need to be backedup along with app.  I am storing the db in
> /Documents.  Every app built with the Rhodes framework stores the db here.
>  I've had 6 updates successfully accepted without a problem.  I do not see
> why now I am violating a storage guideline.

The general guideline is that only user data should be backed up.  This does
NOT include initial data included with the application.  There are two general
approaches to resolving this:

-If at all possible, separate your app and user data.  This solve the
immediate problem, simplifies future updates, and makes sure that only app
data is getting backed up.  Your app data can be left in your bundle, or
copied and excluded manually.

-If that is not possible, then you will need to exclude your entire data from
the backup until such time as the user actually modifies it.  

In both cases, my recommendation is that you leave your data file read-only
inside your app bundle until changes are made.  At that point, you can copy
the relevant data from your bundle into "Documents", and then proceed
normally.  If for some reason that won't work, then you'll need to manually
exclude the data from the backup.  QA 1719 has the full details of what you
need to do on each version of iOS:

[Jon Tara]

The database really needs to be split in two, so that you can use it both to store user data and as an application cache. There needs to be some way to designate which database a particular table is stored in.

I think in any individual case, though, it depends on how you are using the database. If you really are using it only for user data and settings, then you need to explain that, hey, it's a database, and as a database it necessarily carries some overhead in the form of metadata, and they need to get over it.

It is going to be hard to argue with them, though, because it seems (and is) obvious that there can't possibly be anything in the database the first time the application starts-up that is unique to the specific user.

[buck nasti]

This has been their argument.  The fact that the user hasn't made any changes to the db when it initially loads, makes them consider it not to be user data.  When the user does make changes to the db, they suggested moving it to /Documents.

This seems like a very poor solution.

--
You received this message because you are subscribed to the Google Groups "rhomobile" group.

To view this discussion on the web visit https://groups.google.com/d/msg/rhomobile/-/TDd2939yA7gJ.

[Jon Tara]

Will they object if the database is initially empty? Just don't pre-populate it. Populate it over the air.

Tell them that there is some minimal overhead, and that it does contain data that must be backed-up. The data that must be backed-up is a flag indicating that the app is newly-download, and configuration by the user is required. ;)

[Jon Tara]

It is rather disturbing that Motorola seems unconcerned about these kinds of issues.

On one hand, it's understandable that the focus of RhoMobile has always been primarily on Enterprise apps, that do not have to conform to App Store rules, and iOS is but one of the platforms supported.

On the other hand, I would think that the ability to submit App Store apps would be an important consideration. Enterprises do not create apps only to be used within their own organization. Sometimes they interface with suppliers, customers, etc. and this might be done in the form of App Store apps.

I would think this would be even more-so after the Motorola acquisition, since now they support specific, unique Motorola devices. Anyone uses these devices in a scenario needed an App Store app have few other choices to support app development.

As another example, stating at this point - after the public release of iOS 6 - that it will now be another 2-3 weeks before we will have support for device orientation restored is a very weak showing. Betas have been available to developers for months.

I think they are shooting themselves in the foot, and driving business away from device sales. I hope that RhoMobile does not become a liability for Motorola.

FWIW, I have nothing but respect for the RhoMobile developers. I am sure that they are working hard to remedy a difficult situation. I only hope that management has set the proper priorities.

[buck nasti]

I agree Jon.  This seems like more of a rhodes platform issue rather then something every rhodes developer should be solving.

I believe a solution would be to start the db in the Cache directory and then move it to /Documents the first time it has a write operation. This seems to be the issue apple has with the db's default location currently.  They only want files in the /Documents folder that store data the user has input.

I'll have to look into the rhodes code to see if the db path is hardcode and if changing this path will break other dependencies.

Thoughts on this approach?

--
You received this message because you are subscribed to the Google Groups "rhomobile" group.

To view this discussion on the web visit https://groups.google.com/d/msg/rhomobile/-/uxybYxGq-MsJ.

[Jon Tara]

That is only a partial fix, though. It would be good for your immediate problem.

The more general issue is separating user-generate data from data is is simply cached for performance or offline-accessibility reasons. Apple does not want to be storing stuff on their servers that can be re-downloaded from elsewhere.

This is hard to prove one way or the other, so you might slip through one time and not the next. But we all know it isn't conformant with the requirement.

The database needs to be split. Period.

[buck nasti]

Looks like you can actually change the location of the db at compile time which helps if you have a 100% read only db.  

docs.rhomobile.com/rhodes/device-caps#file-system-access

Scroll down to the end of the section and you can see some info on IOS storage options.

From what I gather, you can set the root path to not be in /Documents along with the db.  This would allow your db to not be backed up by default.

I think whats missing is being able to change the db location at runtime.  If this is possible at least its a workable solution to get around apples storage policy.  Do you see any way of changing the db location at runtime?

It does not solve the greater issue you bring up Jon, which should be addressed as well.

--
You received this message because you are subscribed to the Google Groups "rhomobile" group.

To view this discussion on the web visit https://groups.google.com/d/msg/rhomobile/-/WBgWd051IcEJ.

[DR_GEWA]

Dear All, 

I have faced the same problem yesterday with my application where I have a .sqlite file downloaded from my server to the Application's User Folder where CURL of the app has write permission.

Do you have idea if I can download file of database to  /Library/Caches  and if I can read it from there????

On Tuesday, 17 January 2012 16:58:32 UTC+3, Death Mountain Crater wrote:

I sent through a message several days ago which has yet to be
responded to or posted.

I have an application which has been rejected due to "data storage
issues" - issues that are not related to anything i have personally
written in the app and are caused by misuse of the /Documents
directory in apps that use iOS5.

I would appreciate the slightest response - or just pass my message
through to the group so anyone who may have had the issue can answer.

[Dmitry Soldatenkov]

If you store downloaded file into User folder (this folder is used for backup) - set special attribute to your file by 

System.set_do_not_bakup_attribute(filepath, value)

value = 1 for set attribute, 0 for remove