Is there an Official approach to App data creep?

[Affinity Rat]

It is well know that the iPad has problems releasing memory, and this leads to the app occupying huge amounts of iPad storage.

1. So is there an official technique or workaround for this problem?

Right now I have no files in the gallery, those that were there, were saved and moved. I moved all my afphoto files to a new folder in a different location. The system show 30gb in use by the app. I offloaded the app and reinstalled but that didnt change much, if anything regarding app usage. In the past it has occupied >100gb of storage.

2. Does the app maintain unsaved versions of files that are shown in the system storage? in the sandbox?

3. If so how can I save them since I dont know where they are? Hidden in the sandbox! 

4. If I delete these files from system storage, and reinstall, I assume those files in the sandbox are lost, how can I prevent this.

5. How to save file outside the sandbox, is that possible?

This is such a common problem Affinity should publish a workaround or a way to resolve this persistent pernicious problem.

 

 

 

 

 

[walt.farrell]

1 hour ago, Affinity Rat said:

2. Does the app maintain unsaved versions of files that are shown in the system storage? in the sandbox?

You said you cleared "the gallery" (presumably Live Docs in V2), so there shouldn't be anything. The sandbox is the gallery/Live Docs.

1 hour ago, Affinity Rat said:

5. How to save file outside the sandbox, is that possible?

Save from the Sandbox. Make sure you're not saving to one of the automatically created folders with the application name in "on my iPad".

Question for you: do you also have the desktop version of the application? Do you have the same Assets, Brushes, Styles, etc. installed on both the iPad and the desktop? If so, you can examine the .propcol files on the desktop and add their sizes. It is likely they will take the same amount of storage on your iPad.

[Affinity Rat]

4 hours ago, walt.farrell said:

You said you cleared "the gallery" (presumably Live Docs in V2), so there shouldn't be anything. The sandbox is the gallery/Live Docs.

While I have V2 I primarily use V1 because I hate the UI on V2. I presume you are implying that V1 and V2 implement the sandbox differently.

It would seem that I incorrectly assumed they ie V1 and V2 were the same with regard to sandbox storage.

I also have the desktop version but find the iPad easier to do artistic graphics and more comfortable to use in a comfortable chair while sitting for hours.

I dont do much customization, ie assets, brushes etc so that is not an issue for me, and those can be exported anyway.

[Affinity Rat]

So does V2 suffer from App storage creep?

 

[walt.farrell]

12 minutes ago, Affinity Rat said:

While I have V2 I primarily use V1 because I hate the UI on V2. I presume you are implying that V1 and V2 implement the sandbox differently.

It would seem that I incorrectly assumed they ie V1 and V2 were the same with regard to sandbox storage.

No, I think they are the same.

Live Docs is, I think, the V2 term for what we call the Sandbox in V1.

[walt.farrell]

11 minutes ago, Affinity Rat said:

 

dupe

 

You should be able to Hide such a post using the ... icon on the upper-right of the post, by the way.

[Affinity Rat]

So I have no files in the Sandbox, but the system storage show 30gb of files, can I safely delete them without loosing anything, delete the app and reinstall? 

I have no idea where they are unless I search the iPad for each, none are in the default Apho directory.

[Affinity Rat]

Searching for a file the system storage says is contained in the Apho app, cant be found, but I find the iPad file manager search flaky, it often doesn't find files I know are there, so I dont trust it.

 

 

 

 

[Affinity Rat]

So if V1 and V2 implement storage in the same way, and that the iPads problem in releasing memory/storage is well known, it behooves Affinity to recognize the problem and apprise users of a workaround, otherwise people will naturally assume Affinity at fault. The fallout will effect the most significant user base, ie those professionals that choose Affinity over Adobe.

[walt.farrell]

The workaround is Save all the files from the Sandbox (Live Docs) in a location that is not in one of the automatically-created folders, then delete the application, and reinstall.

But as I hinted earlier, not all of the storage is user files. Some is the application code, some is the application data, including all the Assets, Brushes, Styles, etc. As a user you cannot see these files on the iPad, but you can on the desktop.

If I had everything installed in Photo 2 on the iPad that I have installed in the desktop version, that would be about 11 GB of storage. So if you also have the desktop applications, it is worth looking at what you have installed in the application on the iPad, and seeing how much space that takes up on the desktop.

[Affinity Rat]

Just reloaded Apho 1, open a file, and imported 1 asset file 436mb.

Closed the opened file without saving and look in system for data in app, after loading one single 436mb asset file, the data now loaded into the app at 9 gb.

Hmm so assets explode once loaded, deleted the catagory and size now down to 8.1 gb with no files in sandbox, just residual assets.

After a couple of minutes at the ipad system storage page for Apho hung apparently iPad busy shuffling memory, after reboot the storage footprint decreased from 8.1gb to 3.1 mb.

So this may explain why, my storage footprint so large.

Lesson learned export assets then load when needed and delete category after usage.

 

[Affinity Rat]

 

Tried this exercise again, it appears that the iPad must reboot to reclaim the memory, after deleting a category of assets.

Since even large asset files ~1gb load quite quickly, they should be linked or loaded on demand and never enter the sandbox, sure its a bit slower but would have of smaller impact on overall ipad performance.

Even closing the app could delete the all asset categories and reload when app started up again, not leaving a permanent dent in system resources that users may be unaware of.