Affinity Rat

Yes, they are completely separate.
That, too, though you can register an iPad app with the Affinity Store after you install it from the App Store.
You could assign the same email and password to both, but they are separate and if you change one it won't affect the other.

On Mac there's FileJuicer which "juices" files for any embedded objects. I just tested it on a few *.afassets files and it works in some instances, but apparently only if the asset contains a bitmap layer of sorts. 

Or perhaps the Python script that @v_kyr provided? 
Would also probably only work for assets containing normal images, if at all.
 

thankyou affinity rat

On Desktop, unticking (unchecking) “Matte Edges” in the Refine Selection dialog might get you what you want, up to a point, unless I’ve misunderstood your requirements. (You can check the edge more easily if you switch to the “Black and White” preview.)
I don’t know if this facility is available on iPad, or where it is if it is, but this might help you to find it.

EDIT: I just noticed the OP is a Windows user, but I'll leave the macOS related stuff here because I think there is something similar to wired memory in Windows.
The only memory that can't be cached to disk is the wired memory the macOS system needs to operate -- more about that & memory usage in general can be found in this Apple article, including a bit about why memory remains cached to improve performance, & why you can't force the system to use less memory than it needs.
As I understand it, the RAM limit in the Affinity apps is provided to be able to 'tune' the app to use less memory that it otherwise might when a user is running the Affinity app plus other memory-hungry apps simultaneously, thus potentially reducing disk thrashing. But it may have other uses as well, because it is sometimes suggested that reducing it from the default has helped prevent certain odd behaviors, instabilities, & maybe even some obscure causes of crashes.

Thanx Walt, the OCL was enabled, but I only have 4gb video ram, but I was unaware there were also ram constraints, it was set to 8gb, upping to 28gb fixed the problem at least with a 760mb asset file.

If you have Hardware Acceleration (OpenCL) enabled in Preferences/Performance, does turning it off help?

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.

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.
 

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.
 

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.

It's hard to be certain without seeing the same information you are referring to, but these files may contain 'Live Docs' that have not yet been manually saved to your iPad, alongside application data, such as saved Presets, Assets, Brushes etc.
'Safely Deleted' is somewhat of a personal user choice in this regard - the app will likely continue to function correctly if you were to delete these files, but you may lose these documents and custom data, as outlined above. We don't directly recommend deleting these files unless absolutely necessary, as the data will be unrecoverable after deletion.
I'm unsure what you mean by 'Affinity Photo app directory' - if you are referring to the Affinity Photo folder created on your iPad by the app, then yes the app saves temporary documents, autosave files and user data outside of this 'Affinity Photo' folder, but this is still contained within the 'Sandbox' of the Affinity app.
These additional locations that the Affinity iPad apps can access/save to, outside of the 'Affinity Photo' folder within Files are not something that a user can typically access on iPad, as Apple choose to keep this section of the OS locked down. As above we don't recommend deleting or interfering with this data manually.

If you are trying to reduce storage use, then once you have Saved a file that is in Live Docs, you should Close it so it is removed from Live Docs.Then you will have only the one copy of that file on your iPad.

Hey @Affinity Rat, yes, it is generally expected: the RAW file will be a greyscale 14-bit bitmap (so only contains one channel), and potentially will also have lossless or lossy compression depending on your camera settings.
Once the RAW data is debayered to a full colour image and mapped to a colour space, the resulting .afphoto file will be (by default) a 16-bit per channel RGBA document, which is where the file size increase comes from. Adding more bitmap layer work will of course increase this.
If file sizes are a concern, you could try using the RAW Layer (Linked) option on the Output dropbox when developing your RAW files. This will reduce the file size significantly (typically under 1MB until you start to add more layer work). Do be aware, however, that every subsequent load of the .afphoto file will then require access to the original RAW file so it can be 're-developed'.
Hope that helps!

Thanks Walt, some of these digital asset management suggestions were relevant to my inquiry.

Depends on what you mean by file management. 
There have been a number of discussions on this topic over the years. Try this forum search, for examples: https://forum.affinity.serif.com/index.php?/search/&q="best dam"&search_and_or=and
 

As far as I'm aware there isn't really anything that can be done to prevent this I'm afraid as its a bug with how iOS releases space. The following forum post explains this in more detail and contains a few work arounds that you might want to try.
Thanks
C

Well said.
😊

Ok thanks Walt,
I yes the Navigator Studio, I was expecting it in the Transform Studio, but silly me this is not a transform.

I'm not sure which meaning of "determine" you intend.
If you mean that you want to set the zoom level, you can do that using the Zoom Tool (Context Toolbar) or the Navigator panel.
If you mean that you want to figure out what the current zoom level is, you can do that using either of those methods, or by looking at the tab for the active document, which also contains the zoom level.

That quote was from the link you provided. 🙂

As long as the Surface Pro has an i5 or i7 CPU with a minimum of 8Gb of RAM then it can run the Affinity 1 and 2 programs with the same performance as an equivalate laptop , I have run all of the Affinity programs on a Surface Pro 3 and 4 with an i7 and 8Gb of RAM.
Please be aware that a Surface Pro X will not run the Affinity programs as this is an ARM64 based CPU and does not natively support x64 programs

Yes that was happening to me.
Its now apparent that there was both a hardware and software issue, with the behavior I was seeing. 
In my case because of the hardware problem not allowing me to move the layer, I then clicked on another studio thereby triggering this event.
Good to get the bottom of this issue.
regards
Mr Knowsomethingall

Ps having problem uploading some files to website, site returns an error. Will restart iPad and try again.
ok success after restart, it (ipad) wouldnt allow me to upload png(by upload I mean I could select it, then click Open to send to website but nothing sent) from files but would allow jpeg. Created jpeg added to ipad photo library and tried upload and website gave an error saying contact support.
In addition after copying text from system info ie Model number website or ipad wouldnt paste into this post, but would paste to ipad Notes. Image below contains the text I attempted to post but wouldnt paste here.
After restart can also now paste text. ie MPF22LL/A and upload png no problem.
 

 

Actually, in further testing I have been able to find a trigger for this issue - though I'm not sure if this is slightly different from the steps you're taking.
If you open the Layers Studio and tap and hold on a layer to move it, you will see that layer now 'follows' your finger, provided you keep your tap held down on the screen.
Once you have a layer selected, if you open any other Studio you will then find this layer 'sticks' on screen and persists until you restart the app.
RPReplay_Final1685019433.MP4
I'm getting this logged with the dev team now, to be resolved ASAP.