Hi autoliv, thanks for your reply. Is there something particular in TPInAppReceipt that you think is relevant to iOS apps running on Arm Macs? Have you run that code in an iOS app running on an Arm Mac and found that it validates the receipt correctly? I have looked at its Validation.swift and it seems to have the same logic that I am currently using. I don't see anything that specifically handles an iOS app running on Arm macOS.

If I understand correctly, currently the App Store Connect API for in-app purchases is read-only. I guess it may gain features to add/modify IAPs eventually. In the meantime, the older XML "Transporter" tool still exists. I don't think this is actually deprecated, but the documentation is very difficult to find. I believe it is mainly used by people who upload music and video to the iTunes store. If your app has a catalogue of dozens or hundreds of IAPs, Transporter is the best tool. Note that it is Java, so you can run it on your Linux cloud instance if that is useful to you. See WWDC 2013, session 306: https://developer.apple.com/videos/play/wwdc2013/306/ That refers to a WWDC 2012 presentation.

Hi tikhop, thanks for replying. I've opened a developer technical support request about this. The initial reply was that I need to use the MAC address when an iOS app runs on macOS. They sent some code for getting the MAC address, which is a bit more involved than what you're using in TPInAppReceipt. Specifically, I think it is trying to get the correct MAC address on Macs that don't have wired ethernet, or where the wired ethernet is via a USB dongle. The logic is: try en0 if it's built-in, else try en1, else try en0, else fail. Of course, this code isn't feasible because the calls to get the MAC address use the private IOKit so they would not pass app review. But I hacked it to run locally - and it doesn't work. So I got back to developer technical support, and I think that they finally read my question properly, and they said: "I don't think it's clear whether a StoreKit app which implemets local receipt validation can work on an M1 system", and told me to "file a bug". I have tried to understand where the identifierForVendor might be stored for iOS apps on macOS, but I've not found anything yet. I suspect there is a plist or a db or something somewhere. Perhaps I could somehow trace inside UIDevice.identifierForVendor and see what it reads? Anyway, for the time being I've disabled my app from the Mac app store - which is unfortunate, because apart from this it works remarkably well. My guess is that it might start working in a macOS update. Or maybe an App Store change is needed to change the receipt. I would be interested to hear if anyone else has tried to do this! Surely I can't be the only one?

You need to contact a Developer Support human, who I think will be able to do this for you. I converted a sole-trader account to a limited-company account and it was not complicated, but it did require human intervention from Apple.

I've seen various confused states for downloads, but my impression is that they don't affect end users, i.e. they only affect development devices. Do you believe your end users are affected by these issues? What I find is that I can get into a state where transactions have not been finished for some reason, and when the app restarts Store Kit sends me updatedTransactions: with state Purchased or Restored. I then call startDownloads, but I never get an updatedDownloads with state Finished (possibly no updatedDownloads at all?). Since I wait for the download to finish before finishing the transaction, the same thing happens when the app next starts. But as I say, I've not seen any evidence that this affects end users. I will have a look at the download progress and see if it is 1.0 in this case. (My downloads are very small.) So do you find that the download's contentURL is valid even though the state is not finished? I have also worried about whether I should be deleting the files referred to by the download's contentURL after I have processed them. What do you do? I worry that Store Kit may not know that I have deleted them if I restoreTransactions and do the download again, and it may think it has a cached copy of the download to give me, but it doesn't because I deleted it. I asked Developer Technical Support about this last year but my question didn't reach anyone who understood it. iOS or macOS BTW? The above is all on iOS.

Alen, thanks for your post. The receipt / sandboxReceipt difference is interesting. I've not tried to understand how the test user sandbox things work in this case. It's one more thing that can go wrong! Regarding whether it should be running the identifierForVendor or the MAC address code - we simply don't know what Apple expect us to do, but the MAC address code requires private frameworks on iOS, and neither correctly validates the receipt in my experience. Alen, can you hack your code to use the known MAC address of your Mac, and see if it validates? (I predict not.) My bug report got a response from Apple; it's the usual "do you have a sample project that demonstrates the problem?" reply. Do any of you have something simple we could send? Thanks.

tikhop, I've emailed you the Mac MAC-address code that Apple Developer Support sent me. You might like to incorporate it into TPInAppReceipt.

No. They happen automatically, if the threshold is met. Note they will sometimes send payments below the threshold, I think once per year.

Alen, you are seeing the same behaviour as me; neither the identiferForVendor nor the MAC address validates the receipt. I think the whole MAC address thing is a distraction. People only mention it because they don't understand the question. People read the question and think I'm asking how to make my iOS receipt validation code work when recompiled for macOS, to which the answer is "you need to use the MAC address instead of identifierForVendor". But what I'm actually asking is how to make my iOS receipt validation work when the iOS app is run on an Arm Mac. identifierForVendor does return a plausible-looking random value when my iOS app runs on my Mac - it just fails to validate the receipt. I think it's quite likely that this is just a bug and it will just start working after a macOS update - is anyone here running the macOS betas? Maybe I should try to work out where the identifierForVendor comes from. If they are distinct per-app (I've not checked), there may be a database or plist or something where there are stored. Of course the people who best understand how this works are the people trying to crack our apps.....

It's really quite amazing that Apple are removing this (for new content) with so little notice. The email suggests using "on-demand resources", but as far as I can tell that is in now way tied to in-app purchases, so it does not provide any sort of security. (Is that correct?) Basically we have one month to design, implement, test and deploy our alternative solutions. I'm sure the pirates are rubbing their hands with glee, looking forward to all the insecure alternatives that we hurriedly cobble together.

With hindsight, I guess the absence of SKDownload in StoreKit 2 should have been a warning to us that SKDownload was in danger. Apple have announced that new SKDownloads are not possible from April.

Just ask Google what UTI stands for. Ha ha, only joking, Google will tell you that UTI is "urinary tract infection". Note to everyone: if you're going to invent a new TLA, Google it first! In Apple-land, UTI is "Uniform Type Identifier". Googling that, or searching developer.apple.com, should find all the info you need.

martax, I think you're being very optimistic to think this doesn't affect you. You should perhaps use one of your DTS support cases to get confirmation. I'm pretty certain this refers to the SKDownload system. acelani74, yes you will now need to host your content on your own server. In my experience there are some very easy ways to do this, e.g. AWS S3 - but they can be expensive. I spend a lot of time investigating cheaper alternatives, which all have disadvantages - they can be less reliable, or more difficult to use, or slower. It's a difficult balancing act. BUT what you also need to do is to secure your content. The SKDownload system has that huge advantage that Apple ensure that the downloads are only available when the corresponding IAP has been purchased. Replicating that security is the challenge here. You can send the app receipt to your server and have it verify that before serving the content, but (a) that requires much more complex server infrastructure than just an S3 bucket, and (b) by itself it doesn't guard against replay attacks, i.e. pirates share the receipt from one legitimate purchase with all the pirated copies. The App Attest system provides a way to guard against that, but its problem is that it is not available when your iOS app runs on an M1 Mac.

I sent a message to Apple to say "it's not acceptable to remove this functionality with so little notice, please consider extending the deprecation period to e.g. five years". And I just got a reply. The support person questions whether the email that I received was actually sent by Apple. They claim that any changes would be posted at developer.apple.com/news or developer.apple.com/in-app-purchase , which this isn't. I must say it's a very elaborate hoax, if that's what it is. Or, Apple Developer Support is being even less useful than usual!

Wow, really amazing. A "senior advisor" at Apple Developer Program Support has now told me that the mail that I (and martax) received is not from Apple. They tell me I need to report it to reportphishing at apple.com! Here's the email. What do you think? Which is more likely, (a) Apple really are withdrawing a feature that I rely on in my app with only 1 month's notice, or (b) Apple can't distinguish between a hoax phishing email and something they sent themselves? If there are any Apple people reading this, I would appreciate your thoughts on whether this is legitimate or not. Here's the email: Dear Philip, Thank you for reaching out to us. My name is Corinna, and I am a senior Advisor with Apple Developer Program Support. Your request was given to me for further review, and it will be my pleasure to take ownership of your case. I understand that you received an email that you believe was sent by Apple, stating that we would imply changes to hosting non-consumable in-app purchases. When reviewing the email that you kindly forwarded, I found that the email address is not from Apple. Please review the following article and report the email to reportphishing AT apple.com. Recognize and avoid phishing messages, phony support calls, and other scams [snip] Wishing you a lovely afternoon. Kind regards, Corinna Apple Inc.