Brad Brighton

That should go without saying. But, just to be safe, I logged out and logged back in. Still no updates available on my account page. HOWEVER, the app store *did* allow me to install upgrades from the individual product pages. So stupid. Anyway, thanks for the help.

Silly questions but the first things to check: are you (1) sure you're logged in at all at the App Store (it's been known to log people out and it not be obvious) and (2) logged in as the Apple ID under which the purchase has been made?

To get this out of the way, I do NOT work for Serif nor am I an apologist.
I'm going to dive in on this part only because it may be useful for any non-developers reading, either for this specific topic or generally.
App Store versions (both Microsoft and Apple) of any app are NOT identical to self-distributed versions of those same apps in two critical ways:
There is extra code involved to support the delivery of the app (security & receipt checking, etc) through the respective app store as well as potentially dealing with the environmental differences because of delivery method (see the next point). The "rules" of what an App Store version of an app can do by default are increasingly different than what a self-distributed app may do, predominantly centered around asset and resource access security. "What can you open?", "Where can you save?", "How do you talk to other apps?", "What hoops do you have to jump through to achieve a particular action?", etc. Neither of these is meant to be a "get out of jail free" card for Serif should there be bugs or uncaught misbehaviors due to restriction cases that weren't clear. However, the nature of software development is that the results are imperfect and the more variations there are of an environment, the more likely there will be errors that are only discovered "in the field". Serif, I'm certain, tests for as many of these as reasonable and when something breaks or is missed, works diligently to identify, isolate, and correct those issues.
Add in the nature of App Store business agreements (which effectively are determined by MS and Apple, NOT Serif) and it's understandable that some audiences may feel slighted when there are issues. It's unfortunate, both that those feelings are incurred and that the remedies are fewer for Serif when working with the App Stores but that's the state of the situation in cases like these.

To get this out of the way, I do NOT work for Serif nor am I an apologist.
I'm going to dive in on this part only because it may be useful for any non-developers reading, either for this specific topic or generally.
App Store versions (both Microsoft and Apple) of any app are NOT identical to self-distributed versions of those same apps in two critical ways:
There is extra code involved to support the delivery of the app (security & receipt checking, etc) through the respective app store as well as potentially dealing with the environmental differences because of delivery method (see the next point). The "rules" of what an App Store version of an app can do by default are increasingly different than what a self-distributed app may do, predominantly centered around asset and resource access security. "What can you open?", "Where can you save?", "How do you talk to other apps?", "What hoops do you have to jump through to achieve a particular action?", etc. Neither of these is meant to be a "get out of jail free" card for Serif should there be bugs or uncaught misbehaviors due to restriction cases that weren't clear. However, the nature of software development is that the results are imperfect and the more variations there are of an environment, the more likely there will be errors that are only discovered "in the field". Serif, I'm certain, tests for as many of these as reasonable and when something breaks or is missed, works diligently to identify, isolate, and correct those issues.
Add in the nature of App Store business agreements (which effectively are determined by MS and Apple, NOT Serif) and it's understandable that some audiences may feel slighted when there are issues. It's unfortunate, both that those feelings are incurred and that the remedies are fewer for Serif when working with the App Stores but that's the state of the situation in cases like these.

To get this out of the way, I do NOT work for Serif nor am I an apologist.
I'm going to dive in on this part only because it may be useful for any non-developers reading, either for this specific topic or generally.
App Store versions (both Microsoft and Apple) of any app are NOT identical to self-distributed versions of those same apps in two critical ways:
There is extra code involved to support the delivery of the app (security & receipt checking, etc) through the respective app store as well as potentially dealing with the environmental differences because of delivery method (see the next point). The "rules" of what an App Store version of an app can do by default are increasingly different than what a self-distributed app may do, predominantly centered around asset and resource access security. "What can you open?", "Where can you save?", "How do you talk to other apps?", "What hoops do you have to jump through to achieve a particular action?", etc. Neither of these is meant to be a "get out of jail free" card for Serif should there be bugs or uncaught misbehaviors due to restriction cases that weren't clear. However, the nature of software development is that the results are imperfect and the more variations there are of an environment, the more likely there will be errors that are only discovered "in the field". Serif, I'm certain, tests for as many of these as reasonable and when something breaks or is missed, works diligently to identify, isolate, and correct those issues.
Add in the nature of App Store business agreements (which effectively are determined by MS and Apple, NOT Serif) and it's understandable that some audiences may feel slighted when there are issues. It's unfortunate, both that those feelings are incurred and that the remedies are fewer for Serif when working with the App Stores but that's the state of the situation in cases like these.

Forgive me, @LionelD, but I'm still unclear. It now sounds like you're looking for an alternative to the native afphoto storage format, but one that preserves all your edits in a granular way. 
Is that actually the case? And if so, what is it that makes the Affinity native files unsuitable for your needs?

Serif will have to speak to whether the existing license can be converted or a refund issued...
To the original goal, Serif sales can walk you though a process to get a redemption code that can be used with the Affinity Store account. A quick check suggests that 13 is the minimum age for that, though it's not explicitly stated. (13 is a "magic age" on the internet below which reputable sites do not collect information or (in many cases) even allow usage).

Yep, a thanks from me too, would explain why it’s hit and miss depending on what I’m clicking on and I’m on a 9.7 inch iPad, so I’m guessing that’s why the small profile thumbnails are being cut off at the end of the list of threads.

Thank you, @Brad Brighton, for your „once again“. Now I see, what you mean!
So the reason for this behaviour is not, that iPads now request the desktop site/breakpoint, but the fact, that mobile Safari now tries to visualize hover effects.

Once again, this is an Apple change for Safari on iPadOS. While the previous link was a user responding to a different post in a different forum, here it is "from the horse's mouth" as it were, from Apple's WWDC19 session on "Desktop-class Browsing on iPad"
(from the transcript of session 203 - https://developer.apple.com/videos/play/wwdc2019/203/?time=1377)
"The user can tap a second time if they wanted to click." 
While anything is possible about future changes, this is a definitive statement from Apple: if you're using the "desktop class browsing" on iPadOS 13+ and the website implements hover and link on the same element, you're going to have to tap twice.

Once again, this is an Apple change for Safari on iPadOS. While the previous link was a user responding to a different post in a different forum, here it is "from the horse's mouth" as it were, from Apple's WWDC19 session on "Desktop-class Browsing on iPad"
(from the transcript of session 203 - https://developer.apple.com/videos/play/wwdc2019/203/?time=1377)
"The user can tap a second time if they wanted to click." 
While anything is possible about future changes, this is a definitive statement from Apple: if you're using the "desktop class browsing" on iPadOS 13+ and the website implements hover and link on the same element, you're going to have to tap twice.

Another FWIW since this topic of UI consistency, however inappropriate for this part of the forum, is getting interesting:
Hover over the thread link in "Browse" gets the thread summary. Hovering over the thread link in "Activity" does not, in macOS Safari 13.0 (on Mojave).
EDIT: And that makes a curious (if geeky) sort of sense because in "Activity" it's not a thread link, per-se, it's a post link.
Hover over user links and avatars gets the summary in either location.

Since I don't have an iPad running this yet, I couldn't confirm but I did find an explicit reference to this behavior footprint:
From https://www.macrumors.com/2019/06/06/safari-on-ipados-optimized-for-desktop-websites/

Since I don't have an iPad running this yet, I couldn't confirm but I did find an explicit reference to this behavior footprint:
From https://www.macrumors.com/2019/06/06/safari-on-ipados-optimized-for-desktop-websites/

FWIW, Safari on iPadOS did change to specifically become more "desktop browser"ish so some behaviors I'm sure changed. 
https://www.macworld.com/article/3403436/safari-on-ipados-13-the-best-new-features.html#toc-1

Hi Stephen,
Very true Stephen, I grant you the embedded world of software development is very different; the metal is very close at hand and true in my day job I am nearly as busy with the concerns of the hardware as much as software design, implementation and testing. I have no wish to argue one business model is better than another on the strength of my personal knowledge and experience or in fact if there is a best, correct or better way of doing business at all. The commercial choices of a business are the just that, their choice.  From a customers' perspective we too have choice, well at least realistically the choices that are presented to us including the walking away choice.
It is a very good point that many subscription services, just for an example Microsoft Office 365, allow the use of their software on different platforms for the same licence. However the Adobe's and Microsoft's of this world do have a massive advantage and that is sheer size of financial power and number of employees.
I suppose it comes down to what customers want in the end, this customer is personally happy with the Affinity software licensing scheme, however I do concede licensing is a tricky balance in the world of software.
I just see that the hardware platform, especially for high work load specifications for example working with lots of large RAW files and even larger Tiff files, can be very expensive and the relative cost of Affinity software is small in comparison. If Affinity software was in the multiple hundreds of pounds/dollars I might possibly feel entitled to a more open licensing regime.
Regards
Reggie

<eyeroll> If we're going to down the silly analogy road, Serif's position is more like "You bought this to read on Kindle, if you want to read it on Apple Books you need to buy it again," than it is about the different Kindle devices.
I can appreciate that some people may get surprised by the "license per platform model" and may even hate (intentionally strong word chosen) such a model but even in a perfect development world, it takes different resources to create and maintain a substantial part of the application on each platform. All the math in the world that may be in common code everywhere the Affinity apps reside doesn't make it appear magically through a user interface. It doesn't make it magically compatible (and accurate) with different versions of Windows, macOS, and iPadOS (nee iOS).
A for-profit entity has a choice of spreading those development costs across all platforms (making each one more expensive to subsidize the others) or to allow (for some part) each platform to earn its own keep. Both approaches have pros and cons and when there's an uproar over having to deal with separate licenses at a cumulative cost that still is less than that of the competition, that uproar can arguably be likened to whining more than constructive market and user feedback.
If you don't want to support Serif's business model, make your voice heard to them then go spend a greater amount money on the competition, if that's what you need to do. Serif's value proposition is not misleading nor is it out of place in the market.

<eyeroll> If we're going to down the silly analogy road, Serif's position is more like "You bought this to read on Kindle, if you want to read it on Apple Books you need to buy it again," than it is about the different Kindle devices.
I can appreciate that some people may get surprised by the "license per platform model" and may even hate (intentionally strong word chosen) such a model but even in a perfect development world, it takes different resources to create and maintain a substantial part of the application on each platform. All the math in the world that may be in common code everywhere the Affinity apps reside doesn't make it appear magically through a user interface. It doesn't make it magically compatible (and accurate) with different versions of Windows, macOS, and iPadOS (nee iOS).
A for-profit entity has a choice of spreading those development costs across all platforms (making each one more expensive to subsidize the others) or to allow (for some part) each platform to earn its own keep. Both approaches have pros and cons and when there's an uproar over having to deal with separate licenses at a cumulative cost that still is less than that of the competition, that uproar can arguably be likened to whining more than constructive market and user feedback.
If you don't want to support Serif's business model, make your voice heard to them then go spend a greater amount money on the competition, if that's what you need to do. Serif's value proposition is not misleading nor is it out of place in the market.

<eyeroll> If we're going to down the silly analogy road, Serif's position is more like "You bought this to read on Kindle, if you want to read it on Apple Books you need to buy it again," than it is about the different Kindle devices.
I can appreciate that some people may get surprised by the "license per platform model" and may even hate (intentionally strong word chosen) such a model but even in a perfect development world, it takes different resources to create and maintain a substantial part of the application on each platform. All the math in the world that may be in common code everywhere the Affinity apps reside doesn't make it appear magically through a user interface. It doesn't make it magically compatible (and accurate) with different versions of Windows, macOS, and iPadOS (nee iOS).
A for-profit entity has a choice of spreading those development costs across all platforms (making each one more expensive to subsidize the others) or to allow (for some part) each platform to earn its own keep. Both approaches have pros and cons and when there's an uproar over having to deal with separate licenses at a cumulative cost that still is less than that of the competition, that uproar can arguably be likened to whining more than constructive market and user feedback.
If you don't want to support Serif's business model, make your voice heard to them then go spend a greater amount money on the competition, if that's what you need to do. Serif's value proposition is not misleading nor is it out of place in the market.

While this is technically true (the development distribution certs expire annually), if you've developed the app in the first place (or are enough of a developer to side-load someone else's app by building it in Xcode and installing it on your device), the reality is that you're talking about 10 seconds of effort each year to "renew the cert and rebuild", especially with the automatic certificate management that removes much of the former pain-and-suffering that used to be there. If that's enough of a detriment/annoyance to prevent such a path, ok.
(NOTE: If you're thinking about the 90-day expirations of TestFlight builds, that would not apply to you as a developer and devices registered as development devices -- that's for "external" testing and yes, the requirements there are, among other reasons, to prevent circumvention of the App Store. If you're thinking about Enterprise Distribution, some big names recently were caught abusing this program but it's yet another way to get apps into the hands of users in a defined environment without "going public" through the App Store.)
On the primary topic of building a for-profit app for Android, the business cases are really difficult to make in general; in specific there may be niches, but issues surrounding willingness to purchase, piracy, security, fragmentation, and privacy all are predominantly negative in the Android world vs iOS. I have multiple apps in the App Store and never-say-never but there's currently no compelling reason to invest the development effort on that platform and I've been watching for at least one business for almost 5 years; the landscape simply hasn't changed enough to make it worthwhile.

From the App Store.  Understand the reasoning, will be on the look out!

While this is technically true (the development distribution certs expire annually), if you've developed the app in the first place (or are enough of a developer to side-load someone else's app by building it in Xcode and installing it on your device), the reality is that you're talking about 10 seconds of effort each year to "renew the cert and rebuild", especially with the automatic certificate management that removes much of the former pain-and-suffering that used to be there. If that's enough of a detriment/annoyance to prevent such a path, ok.
(NOTE: If you're thinking about the 90-day expirations of TestFlight builds, that would not apply to you as a developer and devices registered as development devices -- that's for "external" testing and yes, the requirements there are, among other reasons, to prevent circumvention of the App Store. If you're thinking about Enterprise Distribution, some big names recently were caught abusing this program but it's yet another way to get apps into the hands of users in a defined environment without "going public" through the App Store.)
On the primary topic of building a for-profit app for Android, the business cases are really difficult to make in general; in specific there may be niches, but issues surrounding willingness to purchase, piracy, security, fragmentation, and privacy all are predominantly negative in the Android world vs iOS. I have multiple apps in the App Store and never-say-never but there's currently no compelling reason to invest the development effort on that platform and I've been watching for at least one business for almost 5 years; the landscape simply hasn't changed enough to make it worthwhile.

@Patrick Connor, thanks for looking out for the people who have not yet gained the institutional knowledge of those who have been here forever!
My only comment does echo some of the others though; since you appear to have control over the styling of the abbreviations, perhaps use multiple styles simultaneously to negate the link-similar behavior? strong+em maybe or give the span an enclosing border instead of just below/underscore?
It won't bother me if you don't. If the options are keeping it as it is or ditching it, keep it; the benefit even as it is will be outweigh any inconvenience. However, if you can tidy it up just a bit more, I think it would further amplify your intent.
Or, I guess you could turn it into an actual link, no? Point them to a page listing the abbreviations so that if someone is curious enough to click (which should also satisfy the "no tooltips on my browser" crowd) they can learn about all the different approaches to these names.

I like the idea, but AFAIK I have no control over the styling, though I think it may be tweakable in the theme files (css and html here be dragons). I will see if anyone knows more than me about this.

@Patrick Connor, thanks for looking out for the people who have not yet gained the institutional knowledge of those who have been here forever!
My only comment does echo some of the others though; since you appear to have control over the styling of the abbreviations, perhaps use multiple styles simultaneously to negate the link-similar behavior? strong+em maybe or give the span an enclosing border instead of just below/underscore?
It won't bother me if you don't. If the options are keeping it as it is or ditching it, keep it; the benefit even as it is will be outweigh any inconvenience. However, if you can tidy it up just a bit more, I think it would further amplify your intent.
Or, I guess you could turn it into an actual link, no? Point them to a page listing the abbreviations so that if someone is curious enough to click (which should also satisfy the "no tooltips on my browser" crowd) they can learn about all the different approaches to these names.