MAS app updating question

Targets macOS
1

It’s unclear to me how app updating works on the MAS. Here’s my code:

//Mac App Store receipt verification
 // set the AppleRootCertificate
dim f as folderitem
f = App.ExecutableFile.Parent.Parent.Child("Resources").Child("AppleIncRootCertificate.cer")
AppReceiptMBS.setAppleRootCertificate(f)

dim a as new AppReceiptVerificatorMBS

//get the app's "Contents" folder
dim file as folderitem = app.ExecutableFile.Parent.Parent
if file = nil then AppReceiptVerificatorMBS.ExitApp(173)

//check for the app's MAS receipt
file = file.Child("_MASReceipt").Child("receipt") 
if file = nil then AppReceiptVerificatorMBS.ExitApp(173)

//test the app receipt
dim r as AppReceiptMBS = AppReceiptMBS.receiptForFile(file)
if r = nil then AppReceiptVerificatorMBS.ExitApp(173)

//validate the bundle identifier and bundle version
a.bundleIdentifier = "com.randomvideo.arc-x"
a.bundleVersion = "1.0.4"
if a.verifyReceipt(r) then
  // it's a good MAS receipt
else
  AppReceiptVerificatorMBS.ExitApp(173)
end if

The code checks for the bundle version 1.0.4 when it’s validating the MAS receipt. In the future when I release an update, version 1.0.5, will a user who purchased version 1.0.4, or an earlier version, be allowed to download and use the 1.0.5 update? Or should I be checking a more generic bundle version, like “1.x.x” instead of the bundle version of a specific release to insure the user can update any further releases?
Many thanks for any help and Happy 2020!

2

why do you check the version yourself there?

If you don’t set those properties, the plugin reads from the app itself.

So with version 1.0.5 the receipt will have that version number.
Just to makes sure receipt and app belong together.

3

If you’re over-engineering this because you’re foreseeing paid upgrades - that’s not a thing you can do on the Mac App Store.

4

Okay so there’s several problems with this.

  1. The receipt may or may not be against the current version, it may be against the first version that the user downloaded. This particular process has caused developers and user in the past, much frustration.
  2. The App Store doesn’t care about versions, all customers get the latest version. So even when you ship version 10.0 of your app, those that downloaded version 1.0 will get the update. App Store customers do NOT expect to have to pay again.
  3. After a lengthy conversation with an actual human being at Apple last summer, they recommend the use of In-App-Purchase to sell your app, and to sell upgrades. The way you sell upgrades is more akin to feature packs, once a customer has purchased say version 2.0, all that functionality must remain unlocked, but when they upgrade to version 3, 4, or say 5, they unlock additional functions.
  4. Trying to add a “MyApp Version 2.0” to the App Store will most likely trigger the “App Spammer” rule, although plenty of other developers seem to be allowed to do this.
5

@Christian Schmitz
Good to know this. I’lll take the bundleIdentifier and bundleVersion checks out since they’re not necessary. Many thanks for your response, Christian.

6

@Tim Parnell
Thanks, Tim. I was more concerned with the user being able to download and use future versions, but you raise an interesting issue about paid upgrades. I wasn’t aware of the restriction against selling upgrades on the MAS, so thanks for letting me know that. I’ve been selling my apps from my website and am accustomed to charging a fee for major upgrades, so I’ll have to learn the different strategies acceptable on the MAS.
Thanks, again.

7

@Sam Rowlands
Okay so there’s several problems with this.
The receipt may or may not be against the current version, it may be against the first version that the user downloaded. This particular process has caused developers and user in the past, much frustration.
Does eliminating the bundleIdentifier and bundleVersion checks, as Christian mentioned, help at all with this? Or since the checks are done anyway is there still the possibility of a problem for the user?

The App Store doesn’t care about versions, all customers get the latest version. So even when you ship version 10.0 of your app, those that downloaded version 1.0 will get the update. App Store customers do NOT expect to have to pay again.
That’s the clearest explanation of how upgrades work I’ve seen. Thanks for that. I understand now.

After a lengthy conversation with an actual human being at Apple last summer, they recommend the use of In-App-Purchase to sell your app, and to sell upgrades. The way you sell upgrades is more akin to feature packs, once a customer has purchased say version 2.0, all that functionality must remain unlocked, but when they upgrade to version 3, 4, or say 5, they unlock additional functions.
I’m starting to get it. I’ll need to rethink how my app is structured and how to accommodate and market future versions.

Trying to add a “MyApp Version 2.0” to the App Store will most likely trigger the “App Spammer” rule, although plenty of other developers seem to be allowed to do this.
I was thinking this was the approach to use for upgrades, but I obviously need to reconsider. And I haven’t heard of the “App Spammer” rule. So much to learn.
Many thanks, as always, Sam.

8

Just the version check as we cannot guarantee the receipt for be that specific version.

[quote=469886:@Anthony Black]I was thinking this was the approach to use for upgrades, but I obviously need to reconsider. And I haven’t heard of the “App Spammer” rule. So much to learn.
Many thanks, as always, Sam.[/quote]
It’s what happened to me last year when trying to submit a paid update of our latest product. It’s still not on the App Store, because I didn’t like the changes I made to appease the App Store gods and now I am forced to work on a new plan.