Bit Dissapointed

Please include the option to update all 3 programs at once so we don't have to load each one and update separately.
If a user owns Publisher, I assume it can see the file paths for the Designer and Photo installs.
The updater should check each program's version and make sure D and P are at least the same version as A
 

Programmers surely do that, but in a modern (year 2000+) development workflow, it is the specialists in user interfaces who make the decisions. If one is struggling, then such specialists are missing.
In a development team comprising a usability expert and a code developer, their roles would typically be divided as follows:
Usability Expert:
User Experience Design: The usability expert focuses on the design of the user interface, ensuring it is intuitive, easy to use, and meets the needs of the users. User Research: Conducts research to understand the needs, behaviors, and motivations of the users. This can include methods like surveys, interviews, and usability testing. Interface Design: They create wireframes, mockups, and prototypes of the user interface, considering factors like layout, color schemes, and user flow. Usability Testing: Conducts tests to evaluate how easily users can navigate the product and complete tasks. They identify pain points and areas for improvement. Accessibility: Ensures that the product is accessible to users with disabilities, adhering to relevant guidelines and best practices. Code Developer:
Programming: The primary role of the code developer is to write the code that makes the software function. This includes front-end (user interface), back-end (server, database), or full-stack (both) development. Implementation of Design: Translates the designs and prototypes provided by the usability expert into functional code. Testing and Debugging: Performs technical testing to ensure the code works as intended, identifies bugs or issues, and fixes them. Performance Optimization: Works on optimizing the code for better performance, ensuring that the application runs smoothly and efficiently. Technical Problem Solving: Addresses any technical challenges or limitations that arise in the development process, finding solutions that align with the project's goals. Both roles are crucial for the development of a user-friendly and functional product. The usability expert ensures that the product is designed with the end-user in mind, while the code developer brings these designs to life through programming. Their collaboration is key to creating a successful software product.
There are so many feedback comments about usability deficiencies here in the forum that the above tells a story in itself.
From my own career, I can reveal that if there is one thing that keeps projects going, ensures quality, steers clear of disasters, and secures satisfied customers, it's the specialists!

Programmers surely do that, but in a modern (year 2000+) development workflow, it is the specialists in user interfaces who make the decisions. If one is struggling, then such specialists are missing.
In a development team comprising a usability expert and a code developer, their roles would typically be divided as follows:
Usability Expert:
User Experience Design: The usability expert focuses on the design of the user interface, ensuring it is intuitive, easy to use, and meets the needs of the users. User Research: Conducts research to understand the needs, behaviors, and motivations of the users. This can include methods like surveys, interviews, and usability testing. Interface Design: They create wireframes, mockups, and prototypes of the user interface, considering factors like layout, color schemes, and user flow. Usability Testing: Conducts tests to evaluate how easily users can navigate the product and complete tasks. They identify pain points and areas for improvement. Accessibility: Ensures that the product is accessible to users with disabilities, adhering to relevant guidelines and best practices. Code Developer:
Programming: The primary role of the code developer is to write the code that makes the software function. This includes front-end (user interface), back-end (server, database), or full-stack (both) development. Implementation of Design: Translates the designs and prototypes provided by the usability expert into functional code. Testing and Debugging: Performs technical testing to ensure the code works as intended, identifies bugs or issues, and fixes them. Performance Optimization: Works on optimizing the code for better performance, ensuring that the application runs smoothly and efficiently. Technical Problem Solving: Addresses any technical challenges or limitations that arise in the development process, finding solutions that align with the project's goals. Both roles are crucial for the development of a user-friendly and functional product. The usability expert ensures that the product is designed with the end-user in mind, while the code developer brings these designs to life through programming. Their collaboration is key to creating a successful software product.
There are so many feedback comments about usability deficiencies here in the forum that the above tells a story in itself.
From my own career, I can reveal that if there is one thing that keeps projects going, ensures quality, steers clear of disasters, and secures satisfied customers, it's the specialists!

I’ve found Photo 2’s user interface to stretch the practicality of the iPadPro to the point of breaking in the use of parameter sliders.
Way too many multi-use sliders just bury me when trying to work at a creative speed. Not only are the controls multi-use but even that differs from tool to tool.
Are the controls there? yes.
Are they logically applied? I would argue no.
One parameter per control, arrayed in a single row - say, 7 horizontally spaced vertical sliders (or the opposite) - would bring much-needed sight memory to the interface. 
Same topic, the scaling of some parameters is virtually impossible to set to common values by slider alone, which is a big slowdown. E.g., line thickness when using many tools is logically going to be in the small numbers, yet the slider for it is on a linear scale making sensible line width settings impossible to make without keyboard entry.

Programmers surely do that, but in a modern (year 2000+) development workflow, it is the specialists in user interfaces who make the decisions. If one is struggling, then such specialists are missing.
In a development team comprising a usability expert and a code developer, their roles would typically be divided as follows:
Usability Expert:
User Experience Design: The usability expert focuses on the design of the user interface, ensuring it is intuitive, easy to use, and meets the needs of the users. User Research: Conducts research to understand the needs, behaviors, and motivations of the users. This can include methods like surveys, interviews, and usability testing. Interface Design: They create wireframes, mockups, and prototypes of the user interface, considering factors like layout, color schemes, and user flow. Usability Testing: Conducts tests to evaluate how easily users can navigate the product and complete tasks. They identify pain points and areas for improvement. Accessibility: Ensures that the product is accessible to users with disabilities, adhering to relevant guidelines and best practices. Code Developer:
Programming: The primary role of the code developer is to write the code that makes the software function. This includes front-end (user interface), back-end (server, database), or full-stack (both) development. Implementation of Design: Translates the designs and prototypes provided by the usability expert into functional code. Testing and Debugging: Performs technical testing to ensure the code works as intended, identifies bugs or issues, and fixes them. Performance Optimization: Works on optimizing the code for better performance, ensuring that the application runs smoothly and efficiently. Technical Problem Solving: Addresses any technical challenges or limitations that arise in the development process, finding solutions that align with the project's goals. Both roles are crucial for the development of a user-friendly and functional product. The usability expert ensures that the product is designed with the end-user in mind, while the code developer brings these designs to life through programming. Their collaboration is key to creating a successful software product.
There are so many feedback comments about usability deficiencies here in the forum that the above tells a story in itself.
From my own career, I can reveal that if there is one thing that keeps projects going, ensures quality, steers clear of disasters, and secures satisfied customers, it's the specialists!

I do welcome this change, but it really strikes me as a hidden feature, and although I don’t know what to suggest that would make it discoverable, it does merit some consideration. In this case, this new feature relies on two different pieces of knowledge that unless one has been informed about outside of the software (and can remember when it is needed!) there is no way to discover it by usage of the software except by sheer accident:
1. That there is such a thing as a “key object” and how to designate it.
2. That designating a key object changes the behavior of the distribute options (spacing horizontally and vertically).
I don’t think that including it in the software manual is sufficient. To give an example, I read this thread yesterday. Today I decided to try it out in the beta, but I could not figure out how to do it even though I read the thread yesterday. It was not until I went back and read again that I was able to identify what steps I had missed. If that happened with just one thread in the space of one day, what about those few people who actually do read through the manual entirely? When they read about such a feature that is a little bit on the niche side, will they remember that it even exists when it may be many weeks later before the opportunity for its use presents itself?
I did not even know that “key object” existed in 2.3. As a follower of betas, I probably read about it when it was new, but clearly it didn’t stick because I did not then have a use for it. And although there have been occasioned since where I would have found it useful in my work, it was as good as non-existent to me because I did not know it existed and therefore I did not go looking for it.
It may be that there is no way to make it more discoverable, and I certainly don’t mean that the feature should be removed if so.
Now that I do know that there is such a thing as a key object, I recommend that the concept should work not only for alignment, but also for transform operations, as I would use it for that as well. That is a separate feature request from this feature, so I don’t mean to derail the discussion, but I do bring it up because if a procedure is used more broadly throughout the software, it becomes somewhat less hidden, and that is at least a partial solution to discoverability.

this is a great feature but any reason why this is not extended to "insert inside the selection" ?

Yes, I thought you feared the risk some users may inadvertently create russian-doll layer structures, but I think there is definitely value in being able to lock this button too. As Bit Arts mentioned in his/her post, I also find myself repeating an insert into clipping mask action several times and locking this button would definitely help.
I recorded this small video as an example. Note that on last step I forgot to click insert inside and got my shortcut action sequence wrong. But you should get the point
lock insert inside use case.mov

Dear @Ash,
Thank you for the update addressing several requested features. I have some feedback. It seems that some assumptions are based rather theoretically on the notion that your customers follow very uniform workflows, such as top-down approaches. While I utilise the entire range of insertion targets, it's not done mechanically or consistently in consecutive steps. For me, it's not a (semi)permanent setting, but more like an ad hoc setting that I need to use maybe 10-20-30 times in a row.
If I were German, I might describe my method as "An auf hinter in neben über unter vor zwischen" 🙂
Having the 'insert inside' as a permanent option for a while is not at all pointless. True, it could become a bit recursive like digging a well if one is working on the same object, but that's not necessarily the case. In my work, I would enable it because the next round of additions to an illustration involves inserting inside a variety of different objects. A permanent setting would allow me to start grouping such actions and organise my workflows into themed steps, rather than jerkily changing the insert target each time. It's quite disruptive.
So the lack of alt-clicking on insert inside is actually blocking me from working my way. When you have to actively click alt+icon to activate insert inside as a permanent setting, you can assume we know what we're doing. 🙂
This leads me to the iPad, where the insertion target is hidden away in the edit menu and not readily accessible from the toolbar, probably based on the assumption you described. I had a feeling it would end up there because the assumption is that it's seldom used. But for me, that's not the case, so its location in the edit menu is incredibly inconvenient.
Moving on to the tablet interface, it's a bit of an issue in itself to talk about keyboard shortcuts on a tablet. 🙂 In general, the Affinity tablet interface leans (too) heavily on desktop logic, especially with this horseshoe of toolbars and associated keyboard shortcuts ad libitum. It's necessary to have these, but the primary assumption should be that the customer doesn't have a keyboard on an iPad, and tablet UI logic must be smartest. The Command Controller is just a software implementation of four physical keys. The journey into a top menu with submenus is very desktop-like and quite slow. I'm really missing local and dynamic choices, where one can quickly select functions with a finger or pen, and where the dynamics mean the interface folds away and doesn't obstruct, leaving screen space for work.
There are plenty of great apps out there to draw inspiration from for methodology.
Thanks for reading this far. 🙂

Thanks for this one - it's a REAL treat for those of us working with hierarchies of objects.
But there doesn't seem to be a way to do this on the iPad? 😞

You summed it up perfectly. Professional type requires typographic quotes, straight quotes are amateurish. Designer should set professional type.
Because I'm drawing thousands of tiny text frames and I can't switch to Publisher each time I type a few words into each frame, just in case I might type a straight quote.
It's just like the frequent requests for Find and Replace in Designer. If my Designer document has 1,000 tiny text objects and then I want to change the one with ABC to DEF, how am I supposed to find ABC? Switch to Publisher just to use Find?

Fantastic feature. Though, one thing I am not a fan of is that the checkbox for maintaining aspect ratio is greyed out and unusable unless you click the coloured buttons. I just want to have the option to have this on by default when I open the panel without the extra clicking every time.
Also, the panel could be designed like the Move Data Entry panel by being active while doing other changes. For instance, I tried alt+L clicking another object to make it a key object to change which object affected rotations, but that also applied the match rotation I did with this new feature at the same time. It would be nice if it only applied when I tell it to while making edits like it was done with Move Data Entry.
Another thing that would be appreciated is having a regular floating panel version of Alignment. As of now you need to click the button at the top of the toolbar to use or open the Layer menu. Having a floating panel version and the ability to make a shortcut for it would be a solid quality of life change to go along with this improved feature set.

Panel background seems dark compared to other panels in the Light Theme. "Scope" label is in white, on light grey in the Light Theme. There is no way to rename a Query. Could the Layer Type be collapsible? Takes a lot of space if you aren't using the options. No confirmation for deleting Queries.

Apps: All
Platforms: Windows, macOS and iPad
While transforming any object with the move tool (whether resizing, rotating, skewing or moving) you can now hold space to temporarily toggle Lock Children on or off (to achieve the opposite behaviour of what you currently have set in the context toolbar).

Apps: All
Platforms: macOS, Windows and iPad
When in move tool double clicking a vector object takes you into node tool. It has been suggested that a double click on an object while in node tool should do the reverse and take you back into move tool (you could previously double click on the canvas / not over an object to return to move tool but this both loses your selection as well as not being possible if you are zoomed in). This has now been implemented in 2.4.

Dear @Ash,
Thank you for the update addressing several requested features. I have some feedback. It seems that some assumptions are based rather theoretically on the notion that your customers follow very uniform workflows, such as top-down approaches. While I utilise the entire range of insertion targets, it's not done mechanically or consistently in consecutive steps. For me, it's not a (semi)permanent setting, but more like an ad hoc setting that I need to use maybe 10-20-30 times in a row.
If I were German, I might describe my method as "An auf hinter in neben über unter vor zwischen" 🙂
Having the 'insert inside' as a permanent option for a while is not at all pointless. True, it could become a bit recursive like digging a well if one is working on the same object, but that's not necessarily the case. In my work, I would enable it because the next round of additions to an illustration involves inserting inside a variety of different objects. A permanent setting would allow me to start grouping such actions and organise my workflows into themed steps, rather than jerkily changing the insert target each time. It's quite disruptive.
So the lack of alt-clicking on insert inside is actually blocking me from working my way. When you have to actively click alt+icon to activate insert inside as a permanent setting, you can assume we know what we're doing. 🙂
This leads me to the iPad, where the insertion target is hidden away in the edit menu and not readily accessible from the toolbar, probably based on the assumption you described. I had a feeling it would end up there because the assumption is that it's seldom used. But for me, that's not the case, so its location in the edit menu is incredibly inconvenient.
Moving on to the tablet interface, it's a bit of an issue in itself to talk about keyboard shortcuts on a tablet. 🙂 In general, the Affinity tablet interface leans (too) heavily on desktop logic, especially with this horseshoe of toolbars and associated keyboard shortcuts ad libitum. It's necessary to have these, but the primary assumption should be that the customer doesn't have a keyboard on an iPad, and tablet UI logic must be smartest. The Command Controller is just a software implementation of four physical keys. The journey into a top menu with submenus is very desktop-like and quite slow. I'm really missing local and dynamic choices, where one can quickly select functions with a finger or pen, and where the dynamics mean the interface folds away and doesn't obstruct, leaving screen space for work.
There are plenty of great apps out there to draw inspiration from for methodology.
Thanks for reading this far. 🙂

F hell mate... I feel like I am taking crazy pills when I read this forum sometimes... What is this, kindergarten? "I need to press alt? Ow no! not possible to remember!". 😶 
Dont ever try to use some 3D software if this is too much for you to remember. Sorry to be harsh but that sort of things are taking me by surprise. So maybe they should stop adding new functionalities because you know - new things to remember... "Oof" indeed.
BTW - great option indeed.

See this on Windows, using Designer 2.4 first beta.
Create and group three rectangle shapes Group (I used right click menu) Ungroup (used right click menu) Designer disappears instantly

Since the last beta update when I use my knife tool to cut a few lines and then use the node tool and switch back to knife tool it crashes program on the computer so I have to restart affinity designer again. It only started with the latest update 

I have just read the links above you supplied.  I can't see any commercial SW company distributing using flatpak. 
It raises a LOT of security issues and requires a lot of work to maintain. The security issues are not one a SW company would want to take responsibility for.
In addition, I can't see Flatpak covering all Linux distributions. In which case, you are better off selecting a mainstream Linux and only supporting that.
However, for a fraction of the 4% of the desktop market, it is not worth it.

As you can see in many walks of life, a small, but vocal, group of evangelists tend to drown out the 90% majority who are quietly getting on with it.
It is the same with Linux.  A small number making a lot of noise.  

+1

Yes please. A great idea. Very useful.

Yes please
 

SO glad some people have work-arounds that work for them. Please consider (for example) a professional magazine with a feature article that runs a little long on pages 11-13 and then there's some text continued on page 85.

Figuring out where to break the text on each page of a larger document, making sure that it's not awkward or hyphenated when possible, etc. is all part of the job of layout, and it can't be done in Word or Google Docs.  

Now, a late correction from a fact-check or by-line came in, so everything reflows. How are you looking at page 13 and 85 at the same time to look at how to re-split this article and fit it on the required pages. And the deadline is in under 1 hour to get it to press. Your boss is breathing down your neck. Either you — or the app you're using — are the bottleneck.

Are you going to put it back into Word or Google Docs and then bring it back into Publisher, now the story re-flows, you have to apply style sheets again, check the run-around for pull-quotes, add column and page breaks all over, check for hyphenation problems — basically re-do all the work you've already put in all over again (and have it proofed & approved by someone else). Or can you open it up in Story mode, add the needed text, make the corrections, and then check how it's rendered on the 4 pages in question and make tweaks for the final flow so you can get this document out to press…

And this is a realistic situation.

Now the talk goes back to the lighter usage scenarios, but I'm thinking of a story editor for the heavier ones. Think more complex documents, think workplaces, think larger productions of all kinds.
A story editor is not a word processor. It's a text customization functionality for the process that follows once a layouter has the texts. Of course, most texts, especially larger ones, will start their life in a word processor, but there is so much more work to be done in programs like InDesign, where adapting and troubleshooting the text is clumsy and time-consuming in layout mode, and where a story editor is the professional, focused work tool.
The light usage scenarios are well supported in Publisher 2.1 - I look forward to more for the professionals. For example, cross references are sorely missed and finally within reach.