Puck

Yes, I already knew this procedure ... tried it yesterday on my old iMac (with Mac OS High Sierra). This caused the download to stop, my computer froze and could no longer be started. The recovery took about 10 hours. Well, I don't blame Serif for this. Probably something deep inside the computer is wrong. But the issue of updates is done for me for now.

(DE) Normalerweise ist das eine gute Sache wenn man verschiedene CPU-Architekturen mit ein- und derselben Software-Release via FAT-/Universal binaries bedienen kann, sofern man die unbenötigte Architektur dann zur Platzersparnis explizit entfernen (strip'pen) kann. Das funktionierte damals schon zu NeXTstep/OpenStep Zeiten problemlos. - Bei Apple wird dies aktuell auch ein Thema sein, insbesondere dann bei sehr grossen Software-Distributionen.
(EN) Usually this is a good thing if you can operate different CPU architectures with one and the same software release via FAT/Universal binaries, as long as you can then explicitly remove (strip/lipo) the unneeded architecture in order to save storage space. That worked without any problems even in the old NeXTstep/OpenStep times. - At Apple this will be for sure also an issue at the moment, especially with very large software distributions.

Ich hatte via dem System und der App Store app die beiden Updates für (APh & ADe v1.8.6) auf meinem MacBook Pro (OS Mojave) angezeigt bekommen und konnte dort problemlos die Updates einspielen lassen. - Auf meinem asbach alten iMac Rechner (El Capitan da Hardware zu alt), wurden mir diese auch als verfügbare Updates angezeigt. Habe sie dort aber noch nicht installiert, da ich erstmal sehen muß ob ich diese unter El Capitan dann grössenmässig abspecken kann (sprich die ARM architectur binaries rausschmeißen kann um Platz zu sparen).
 

Updating etc. worked without problems here. - Bigger file size differences will be now due to BIG BINARY installer files, aka supporting now Big Sure and thus two different hardware CPUs (Intel x64, Apple M1/ARM chipset) in code.
Further it's generally always a good idea to be not among the early adopters when Apple officially releases new OS versions, since net traffic is known to be always pretty huge then on Apple's servers and services (MAS etc.), which affects their whole ecosystem bandwidth during that times.
See also:
 

Hey Chris, me neither. Not in 1.8.4 nor in Beta 1.9.0.199

thx for this new feature to create a brsuh from a selection. But, this brush will allways be an "image brush" - if i change the brush-color it dosent effect the brush. Is this behavior  a "feuture or bug? I would like to decide if i want this brush as a pixel- or as a instensive-brush. Any possible to change this?

Hello, a suggestion that has been on my mind for a long time: it would be really nice if one could sort the brush categories in the brush palette afterwards. That one can sort the brushes within a category is good so far. Please go one step further and make it possible to sort the categories itself. Maybe this is already possible and I just haven't found it yet.
Cheers, Puck

This is an occasional problem that’s been around for quite some time now and reported. There are a couple of other threads on the forums about it.
But as it only sometimes happens, with as yet no consistent recipe of steps that can make it happen, I can’t help but feel it’s going to be one of those minor bugs that will be with us for some time to come still.

Seems like the same issue as here
Some filters affect pixels that are OUTSIDE of the mask, attached to filter.
there is test file to check

Thanks for the file Puck. I will check this out.

Of course. It's my pleasure.
Snake_and_background.afphoto.zip

see also here: https://forum.affinity.serif.com/index.php?/topic/123578-problem-with-disappearing-layers-in-photo-184/&tab=comments#comment-675961
Same bug, I guess.

Hi Gabe, this bug still exist in APhoto Beta 1.9.0.196 (But I did not want to open a new thread because of that!)
Cheers, Puck

Hi Puck,
Yes, this wasn't fixed yet for this (1.9.x) build. Currently all Affinity Beta apps are affected (on macOS Mojave only). I've bumped the report.

Yep—same thing. Fascinating that I haven't seen this before and then I see it twice in a week. Thanks for the nudge  

see also here: https://forum.affinity.serif.com/index.php?/topic/123578-problem-with-disappearing-layers-in-photo-184/&tab=comments#comment-675961
Same bug, I guess.

Oh, indeed. Sorry, Chris, wrong example on my part. But the bug that Mark describes also happens to me from time to time. The next time it happens I will make a screenshot.

sorry about the confusion. Indeed I use only Mac and reposted this without looking at its location in the forum.

Well, @srg does seem to be a Mac user, and @Chris B’s question about what happens if you “double click” a layer (which you can’t do on iPad) was accepted without comment. So I don’t think you have anything to apologize for!

you are lucky

I'm getting it on Mojave - I first noticed it locking in the down position when a Designer document was using most of my system memory and went into beachball, so thought it was a one off, but I've just had a look in Pub, and as above, when zooming in and out it has the bug and sometimes locks in the lower position - no big deal
Screen_Recording_2020-08-11_at_19_20_25.mov

Checking again on the Mojave work machine. I can replicate the jumpy controls when Saving.
 
Screen_Recording_2020-08-18_at_4_49.22_PM.mov

Thanks! Some of the developers have seen this. I think they'll take a look into it! 

I see this behavior too. Mostly between the opening and closing of dialog boxes: Open, Save, Place, etc.

Hey Chris, they bounce a few times, yes. Then they stand still.
BTW ... it also happens in Publisher 1.8.4 and Designer 1.8.4