The Mac App Store doesn’t support paid upgrades. Neither does the iOS App Store. This is a problem.

I’d certainly like to see paid upgrades in Apple’s app stores, but it would be even better if Apple took this opportunity to implement a solution that’s smarter than the “upgrade” process that most software has been using for years.

Traditionally, most paid upgrade processes deceive the customer. The process is designed to make the customer feel like they have literally “upgraded” their application, when it actually has been replaced. When you buy Adobe CS6, the installation process will “upgrade” CS5. In reality, it will throw it in the trash and put CS6 in its place.

For many customers this deceptive upgrade song-and-dance fits with what they think is happening – that some parts of the application, but not other parts, are being replaced. And this then fits in with the idea of reduced pricing for owners of the current software: “I’ve already paid for 100 percent of the current application, so if this upgrade is only replacing 50 percent of it, then I should only pay for the 50 percent being replaced.”

This, however, is often not accurate. If you get down to the actual code level who knows how much of the code is new. It could be all new. It could be half new. Or it could be that only 5 or 10 percent is new. Ultimately the relationship between the old and new application on the code level is immaterial to the pricing.

So what is upgrade pricing really? It’s a loyalty discount. So why not acknowledge it for what it is and make it work like a loyalty program?

The Mac App Store already has everything in place to create “loyalty pricing”, namely, a complete history of your purchases. Apple could create an API whereby developers define the criteria for discounts, and Apple merely executes them. Developers would not need to have any access to customer purchase data for this to work.

This solution would actually solve more than just the bland version 1 to version 2 upgrade scenario. It would also address pricing “suites” of apps. With the right API hooks, Adobe, for example, could charge less for Illustrator if you already bought Photoshop. This would approximate the bundle pricing that larger software makers often offer. It could even cut across the iOS/Mac divide, letting the customer purchase, for example, Byword on the Mac App Store at a reduced price if Byword on the iOS store was already purchased, and vice versa. This approach would dovetail nicely with Apple’s iCloud push, which encourages buying different versions (iPhone, iPad, and Mac) of the same application.

Loyalty pricing would keep the simplicity of Apple’s model of buying whole applications, but would allow software makers to reward their loyal customers through reduced pricing. It would also have the benefit of allowing customers to continue using their old applications while they tried out the new one because the old version would be removed at the customer’s discretion.

For this to work well there is one more tweak Apple should make to their stores. Currently there is no way for developers to provide updates to an application without it also being listed on the store (and therefore shown in search results and elsewhere). Apple should allow developers to “delist” applications while still being able to provide updates to them. This would remove the confusion of having multiple versions of the same product listed in the store.

Part of the appeal of the Mac App Store, and part of the reason developers are willing to give Apple a 30 percent cut of their revenue, is that Apple does a lot of the hard work of running a store for them. A loyalty pricing mechanism would be one more way for Apple to make that 30 percent cut make sense.