R C-R

Since I have always used the thumbnail CMD-Click method, I never would have noticed it even if it was a menu item in some older version.

Just curious but was this ever a menu item in AD's Pixel Persona?

Keyboard shortcuts are (for the most part) grouped in the same way they appear in menus, so since the zoom options appear in the View > Zoom menu, if you set the second popup in keyboard prefs to "View" (as @v_kyr suggested) you should see the shortcuts assigned to the zoom options.

I'm not really sure about that one but it seems unlikely that it has anything directly to do with sandboxing.

Maybe I have misunderstood what is wanted but on my Mac I can just CMD-click on as many items in the Layers panel as I want to select them.

All of the zoom shortcuts @v_kyr shows should work if you first click in the preview window to make sure it has the focus of the UI.

No problems here running Catalina & MAS versions of AD & AP & the Affinity Store version of APub.

Other than issues with a few Photoshop plugins for AP there are no issues due to sandboxing I am aware of. And frankly, the goal should be to deal with that issue in some way that does not make the MAS version of AP in any way any less capable than the Affinity Store one. I don't buy the explanation that this is something Serif can do nothing about. If it is simply due to a missing entitlement declaration then adding it should resolve the issue. Why would anybody want any of the betas to operate differently from any of the retail versions? What is the point of beta testing if the final release candidate differs in any way from the retail GM version?

I don't see the need for any extra code beyond the entitlements they already must set in the MAS versions, nor any reason to remove them from any Mac version, be it a beta or Affinity Store retail version. From what I can tell, Apple has made this very simple to do. That's the point -- make them all the same so there is no need to run different betas or worry about bugs that appear due to differences in the entitlements or associated code of the two store versions.

Nope. Developers must sandbox an app to sell it in the MAS, but it is the developers that have to do that, not Apple. This is explained in several of the links I posted earlier, but it starts with enabling the entitlement for sandboxing.

James Pond was a frequent contributor to the Apple Support forums, every regular's "go to" authority for all things related to Time Machine. There is that, but it is also possible for problems like with the file system or with some third party add-ons not fully compatible with the OS to corrupt or delete files inside app packages, which the backups would inherit.

As I said, there is no reason I can see for not sandboxing the betas. Particularly in the early versions, they are the ones most likely to have serious bugs so it would be prudent to use the entitlements Apple's sandboxing provides to limit how much damage they can do. Besides, as it is now with both sandboxed & non-sandboxed versions of these apps, in effect there are six retail Mac versions for the developers to maintain, plus three betas for us to test. Doesn't it make the most sense that if we are to test the betas we should be testing versions that are as similar to the final release candidates as possible, regardless of which store they will eventually come from?

For this to work, all the files in the app package backup must be present & undamaged. Since there are hundred of individual files in these packages, it is possible that either an error in the backup process or backing up an already damaged app package will cause the restore to fail.

You are right about that, but there is nothing Serif can do about it. If you have been keeping Time Machine backups that include the Applications folder, you should be able to use that to restore earlier versions of each of the apps, which should include a _MASReceipt folder with the receipt file in it. I have never tried that but from what I have read in the forum, this works for some users. It may be necessary also to restore the appropriate ~/Library/Containers folder from the same backup set because otherwise some of the files & data the newer folder contains may not work with the older app version.

Have you ever explicitly told any Affinity app to access any of its *.propcol files, its temp folder, or its autosave folder? I don't know about on Windows but on Macs there are several other files in ~/Library/Application Support that these apps write to, some infrequently but others often. It doesn't matter if it is due to a bug in the app, a corrupted/damaged app file, or a malware infection, if a non-sandboxed app starts writing instead to some other user domain location, there is nothing to prevent that from happening. I cannot think of any compelling reason why at the least the Mac beta apps are not sandboxed. It does not seem like it would be that difficult to grant them only the entitlements they each need. Sandboxing all of them, beta & retail alike, would provide consistency across the whole Mac range, so if nothing else that should make it easier to identify & eliminate any sandbox-related issues that would cause problems with the MAS versions. I realize the Affinity apps are somewhat unique due to the common document file format across the 3 apps but other MAS apps seem to have no problems with the sandboxing requirements Apple requires, so why can't the Affinity ones as well?