Ensuring an app looks and feels the same across various distributions seems quite challenging when it’s not only different flavours of the OS but also different desktop environments.
At the same time, the OS flavours don’t seem to offer a unified way for handling payments, subscriptions and in-app purchases which is a significant burden to implement from scratch by every app developer.
Because a Linux distributions are used all over the world. Stripe and PayPal are good, but insufficient as a choice - one can't be expected to pick SDKs that work equally well in all regions, preferring local payment options, registering with local tax authorities etc.
Also, Stripe and PayPal don't offer tools to check if an app is running with a valid license/subscription, it's not pirated etc. (the equivalent of the App Store receipt signature).
The "feel" of the app is identical across distributions because the app controls everything inside its window and the look only varies slightly in terms of colorscheme and window decoration if that.
There is absolutely no legit purpose for in app purchases on a desktop OS. Its not hard to pay for substantial software suites and most of what would be an app on platforms which at one point would have had an anemic browser experience is simply a website on platforms where fast cpus and 14-28" screens are normal.
Nobody needs a bunch of adware apps you can pay $3 to decrapify or games that are a slog if you don't buy fake potions for real money.
There are enough good free basic apps for virtually any use case and the more complex use cases need up front investment and users not in app purchases.
You can't stop people from making crap apps, they exist even today.
> The "feel" of the app is identical across distributions because the app controls everything inside its window
To make an app feel at home, it needs to "blend" with the rest of the OS. To achieve this, one can use OS-components to build an interface. Just a simple example, GTK apps are so different from KDE apps in their look and feel - you can always tell if an app is native GNOME or KDE app. Now consider all the other desktop environments - it's just way too many to account for in one's code and testing.
Then comes the question of system integrations - how do you offer a unified photo picker experience, how do you ensure you always ask for the right permission to access the camera, the clipboard or network APIs - all these should be provided from the OS so they don't confuse the user and prevent abuse by naughty apps.
> no legit purpose for in app purchases on a desktop OS
I strongly disagree - what if you want to offer a "try before you buy", or you'd allow users to purchase additional content/credits for a service bundled with your app? What if you want to adapt your pricing for a specific event or holiday period...etc, the sheer scope of possibilities is not practical to include in one comment.
> how do you offer a unified photo picker experience, how do you ensure you always ask for the right permission to access the camera, the clipboard or network APIs
TLDR: Release GTK/QT apps with menubars and xdg-desktop-portal on flathub and use stripe to impliment any and all desirable business models. You can do this today and your app wont look any more out of place than the browsers and office suites. IAP are the STDs of business models.
> You can't stop people from making crap apps, they exist even today.
The particular crapware that exists on Android is notably absent from built in software management GUIs so it looks like you CAN do this.
> To make an app feel at home, it needs to "blend" with the rest of the OS
68% of desktops are GTK based, 26% are KDE which themes GTK apps the same as KDE apps. Superficially apps blend well. Looking deeper you will notice many similarities. Many common shortcuts and the same, common UI paradigms, idioms. Look a little closer and you'll note differences especially gnome with its client side decorations which cram a toolbar + window controls into a single line with extra spacing, QT apps with the more traditional menubars and certain shortcuts in common. Then there are incredibly common apps that are obviously not fully consistent with any, firefox, chrome, gimp, libreoffice, thunderbird.
What one ought to realize shortly is that there is no singular Linux desktop to blend into and it works fine as is.
If you make a GTK app with a traditional menubar you will look reasonably at home on virtually all desktops. At least as at home as most of the most popular apps listed above.
> Then comes the question of system integrations - how do you offer a unified photo picker experience
xdg-desktop-portal
>how do you ensure you always ask for the right permission to access the camera, the clipboard or network APIs
In native apps none of this is controlled at all. Don't install things you think might look at you through the camera and upload your nudes to the cloud. In flatpak the permission to do so is front loaded into the permissions required by the app. Don't install things that require camera and network permission if you think they might upload your nudes to the cloud. Flatseal provides a way to modify this permission after the fact if you want to install something and modify what permissions it gets.
> I strongly disagree - what if you want to offer a "try before you buy",
The most obious thing to do is time or feature limit your usage and "unlock" your app by opening a url and handling payment on your website with stripe and then having the user copy a code and or open a link to communicate it to the app. This is relatively easy AND lets you keep 100% of the money and no capricious app store rejection can keep your users from using your app. If you for any reason were ever to have a challenge distributing your work on the official source both flatpak and traditional package management has the concept of multiple sources. Customer adds your source and your apps and official apps are displayed in the same integrated app store interface.
Flathub is supposed to introduce one off paid apps/subscriptions. I'm not clear what the progress on that feature is. I do not believe there is any plans for in app purchases however. Probably because 99.9% of the use case is dominated by porn, shitty games, and adware. Asking why non-gross environments don't impliment IAP is like going to the whore house and shouting "where all the gonorrhea at!"
It is better from the user perspective if payments/subscriptions are either managed on the website for the service or better yet one a singular store interface where customers can make an intelligent decision rather than having the dev low ball them and them ride the sunk cost fallacy and FOMO to a fuckin payday.
At the same time, the OS flavours don’t seem to offer a unified way for handling payments, subscriptions and in-app purchases which is a significant burden to implement from scratch by every app developer.