pualv

and it would also be really useful if (in all apps on desktop as well):
A: the selected brush in the list stayed highlighted as long as it is being used and
B: there was a reset button to go back to the brushes original settings.

I love Affinity Photo and Designer on the iPad. It's amazing how well things are designed and thought out. There's just one area that I really struggle with and it's managing brushes. It's just not easy to organize large collections of brushes. I can't reorder brushes based on how I use them. Moving a brush to a category just puts it at the bottom and then I'm stuck scrolling to the bottom to find that category. Or I have to create a new category and very carefully add each brush in the order I want (and if I mess up I have to delete it and start over). Managing brushes just seems very unintuitive at the moment.

I have queried it but I think whole pixels would be better—especially for the Pixel Brush Tool. I've checked PS and they do 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 15, 20, 25, 30, 35, 40, 45, 50, 60, 70 etc. 
I'll go over your side notes as a few of them piqued my interest. 

This sounds so much like a preference in the making...
 
From one perspective, using percentages for this makes a lot of sense and is fairly straightforward compared to using some kind of stepping function.  For vector work you *might* get away with this much of the time.
 
From another, however, the use of fractional pixel sizes for a raster brush is indeed rather strange, and simply trying to round this is kind of sloppy...
 
Assume for a moment that you round up when increasing the brush size and down when decreasing.  Starting from a 1px brush you wind up with:
 
1 * 1.15 = 1.15 -> 2
2 * 1.15 = 2.3 -> 3
3 * 1.15 = 3.45 -> 4
4 * 1.15 = 4.6 -> 5
5 * 1.15 = 5.75 -> 6
6 * 1.15 = 6.9 -> 7
7 * 1.15 = 8.05 -> 9
9 * 1.15 = 10.35 -> 11
11 * 1.15 = 12.65 -> 13
etc...
 
continuing with that pattern: 15, 18, 21, 25, 29, 34, 40, 47, 55, 64, ...
 
 
If we then match this going downward by always rounding down, then starting with a brush size of 309 (which is reached by the above pattern after a while), you get:
 
309 * 0.85 = 262.65 -> 262
262 * 0.85 = 222.7 -> 222
222 * 0.85 = 188.7 -> 188
 
and continuing: 159, 135, 114, 96, 81, 68, 57, 48, 40, ...
 
 
Note that the pattern coming downward does not match the numbers from the pattern going up.  That means that implementing such a scheme will lead to brush sizes that cannot be returned to by "going the other way".
 
NOTE: 40 -> 47 -> 55, but 55 -> 46 -> 39
 
Simple rounding won't work with the smaller sizes because 1 * 1.15 = 1.15 which would round back down to 1 and the size would never change.
Simple rounding on the way down won't work either (2 * 0.85 = 1.7 -> 2).
 
 
I would be ok with the pattern of jumps if it were consistent in both directions, but the fact that going up a size and going down a size don't match is something I find rather...  not to be liked?

When using the brush tool in Affinity apps I always get very odd brush size increments when using the square bracket ( [ ] ) keys to change the brush size. 
 
If I use a 10px brush and use "]" to size it up one increment, it doesn't go to the expected 15px, but rather to 11,5 px. 
And then, if I press the "[" key to size the brush back down to 10px from 11,5px, it randomly ends up at 9,8px (?).
Pressing "]" three times from 9px results in 9px, 10,4px, 11,9px, and 13,7px, instead of the expected 9px, 10px, 15px, and 20px values.
I find this a bit strange, as I feel that decimal pixel values for brush sizes make little to no difference, and it's just generally odd that using the square brackets to change brush sizes doesn't just use rounded increments - I hate mentioning Photoshop as a reference example, but if if ain't broke...
 
For instance, using the brackets between the values 1px and 10px should only change the brush size in increments of 1px (1,2,3,4,5px...), anything between 10px and 50px should change in increments of 5px (10, 15, 20, 25, 30px...), anything between 50px and 100px should change in increments of 10px (50, 60, 70, 80, 90px...), anything between 100px and 200px should change in increments of 25px (100, 125, 150, 200px), then 50px, and anything above 300px should change in increments of 100px every time you press the square bracket(s). 

Is there a significance to these weird, decimal pixel increment values?
If so, is there a way to change it back to something more normal/user friendly?

Part of my workflow for doing flat fills on comics and the like is to do a magic-wand selection and then to consistently grow my selection by a fixed amount to "bleed" into the line art, usually by 3 px or so. Every time I open the 'grow / shrink' menu it's reset back to 0, however. I would love a way to always grow by the same amount, either by defining a macro that does it by a specific amount or by having the last amount stay active in the dialog box which comes up.
Additionally, it would be nice if I could use the tab key or similar to change the focus within the dialog box; currently tab just toggles the UI visibility.

I'd second (or third) this request, certainly for book covers and tri-fold leaflets etc. Currently setting up a book cover/jacket or tri-fold leaflet artwork as a single page means
a) no crop marks on the exported PDF indicating the spine width or fold marks for a tri-fold and
b) a lot of manual adjustment of the page elements should there be a need to change the spine width
Would be 'nice' to have the functionality of ID in this respect with the ability to have unlimited pages in a spread but certainly three pages for book covers with the ability to adjust the width of the centre page independently of the front and back cover to accommodate changes in spine width which then includes the addition of crop/fold marks for the spine in addition to the crop marks for the front and back covers.
I suspect this is going to be a heavily requested feature...

That's a big miss for me - I often design exhibition panels where I need to put maybe 7 or 8 panels side by side; I need to save the whole thing as a spread for client to visualise it, but then save pdfs as separate panels to send to print. Indesign currently copes fine with this. I realise I can use Designer for that with Artboards, but the image placement controls, Resource Manager and text controls already make Publisher a more attractive prospect for this sort of work - but not if limited to 2-page spreads.

I believe everybody was focused on the iPad app for the last few months (congrats on that!), so here is a quick bump so you don't forget about us.
This bug has been around for almost 2 years and is increasingly annoying to deal with.
I've shared the steps to reproduce it here:
Cheers!

Hello all,
 
I use FVR to browse my images, it is fast, reliable and I like it.
 
With that in mind when I have opened a number of images in AF how do I go about using Batch Processes on them? The ADD button opens the 'Finder' but does not show the files already open in AF.
 
I realise I can choose from the finder by using the file names shown in AF but this seems counterintuitive and convoluted when my chosen images are already open IN AF.
 
I regularly want to export jpg (small and basic) for my wife's use on the internet and my own postings and basic batch/macros are all that is needed.
 
This oddity is my only question on this process.
 
Regards.   Sharkey 

Hello,
Would it be possible to add the option for a keyboard shortcut to toggle the brush stabiliser on and off?
Thanks for your consideration!

Is there any way to add a shortcut for "Close Curve" as well? It doesn't appear in the list of available keyboard shortcuts.

An option to have the frame fitted to the image and an option to resize the frame without resizing the image.

Set up a grid so that it has a gutter (screen is filled with separate squares rather than a grid).
Snap only works on top side of each square or right edge of each square. Does not snap to bottom or left edge of each square as expected.

You can do this by SHIFT+clicking on the little triangle in the lower right half of a text frame. This adds as many linked text frames and fills them with text you import.
But at looking again at your question: you want to create 100 pages with empty linked text frames in advance and fill them later with text? I think it does not work that way.
d.

I agree with the original post. To me master objects should be editable on the page. The master is there to maintain position and box content style. Having the content of the master pages fixed limits their use.
The ability to edit the master page objects on the content page which then changes the master page is confusing. I suppose you could just lock it. Just as I suppose you could set up your page and duplicate as Wim suggests. But these seem like workarounds because the master page doesn't do what you'd expect it to.
Related (though perhaps could do with a new post) – what about setting up master pages with linked text boxes? What if you want to create a booklet of 100 pages where each page contains an identical text box linked to the next page? As far as I can see this would involve setting up a page, creating 99 duplicates and then linking each text box manually. No one's going to do that.

I'm creating a document that will have around a hundred pages with very similar layout, but different content. 
There is a large title at the top of the page, with a subtitle below in smaller text, then three tables of the same size but different content on each page. 
First I thought I should create all of these elements on a Master Page and then edit them on each page, but the changes I make apply to every page using that master.
I tried creating the elements on a normal page and duplicating the whole page, but when I modify the next page it also applies those changes to the original page.
Am I missing something? How is the best way for me to create a large number of pages with the same style of text and tables, but be able to edit the content on each page individually?

Set up a grid so that it has a gutter (screen is filled with separate squares rather than a grid).
Snap only works on top side of each square or right edge of each square. Does not snap to bottom or left edge of each square as expected.