I believe the most sustainable and fair payment model is paid app at version X, which will get bugfixes indefinitely (or for a long time at least), but no new features. Later a new paid version comes out that will contain the new features, but that way existing users that find the previous version they paid for enough can continue to use it, yet the developer gets a steady stream of money as presumably many of the users will buy the newer version.
See the Reeder app for an example.
Though this doesn’t work where service fees are part of the equation, perhaps the best way to handle that would be passing the cost down to users through an optional subscription.
You're describing the way software used to be sold, and that worked fine since really there was very little that needed to be patched over time. It wasn't connected to anything. There was no internet and barely a network. It ran on one specific OS/version that was expected to remain static over years. And app compatibility largely fell on the OS vendor anyway. If your app broke with a new version it was their fault.
Things have changed now.
"paid app at version X, which will get bugfixes indefinitely" - Would you continue maintaining some old version of an app you wrote three years ago that nobody buys anymore? I certainly hope not.
There are different levels to maintaining. I would definitely try to support it to the max for an overlapping window with the new version (like a year?) and in a much lower-level mode after that. I don’t think software should break all that much once it was that battle-tested, but sure enough it can happen. After a time I would probably only care about personal emails notifying me of a bug, and if it is a quick-enough change, maybe will do it.
See the Reeder app for an example.
Though this doesn’t work where service fees are part of the equation, perhaps the best way to handle that would be passing the cost down to users through an optional subscription.