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.

I've not yet had a reply (other than the autoreply) from the reportphishing email, does anyone know if that address does anything? My feeling is that "Corinna" and her colleagues are AI chatbots. No human could look at that email and think it's a hoax. It even has a valid Apple DKIM signature. Maybe if I now click "Very dissatisfied" in the "We'd love to hear how it went" Apple Support survey email, that will feed back into the AI and the next "Corine" will be better than this one. martax, I also use iTMS Transporter to upload. For some time my feeling has been that that tool is deprecated for app-related uploads, and its main users are music, video and ebook publishers. Although the XML app metadata format is still documented, it's difficult to find links to it from any of the App Store documentation. The best documentation remains a presentation at WWDC 2013. If you ask Apple about it, they get confused with the newer Transporter app and the App Store JSON API.

The Wikipedia "list of iOS and iPadOS devices" page has a good table showing when each device was introduced, what the newest iOS version it can run is, and when it stopped getting updates. Personally I prefer to develop using relatively old devices. My rationale is that if my app runs fast enough on an old device, then it will certainly run fast enough on a new device. You can also acquire used iPhones with cosmetic damage for good prices. Collecting screenshots / videos for the App Store is something to think about. Generally, the App Store will allow you to submit screenshots from larger-screen devices and it will scale them down - but not the other way around. This isn't a huge problem if your app runs OK on the simulator as you can submit screenshots from that, but if you app doesn't run on the simulator for some reason, then that may force you to buy particular (expensive) devices. (Note one alternative to the simulator is the AWS Device Farm.) Regarding "how to learn", I don't have any particular up-to-date recommendations but you might like to mention what sort of apps you are developing and which languages/technologies you are currently using on Android, and whether you hope to port those apps or create entirely new things. There are almost as many approaches as there are developers...

shravan, are you familiar with "universal links" as an alternative to URL schemes?

Thanks for your post monokakido. Did they say anything interesting, except confirming that they had sent the message?

I see that Apple's only contribution to this thread has been to delete the posts that they don't like!

I've finally had a confirmation from Apple that the email is genuine. No prospect of my feedback even reaching the person who decided to do this, I guess, let alone resulting in a reconsideration or delay. I've been an iOS developer since 2008 and I have been through this before. The lesson is "don't rely on Apple technologies, they can withdraw them at any time". Do everything yourself using components that you control. It's worth it in the long term.

I am restoring the purchases whenever the user log in the app Don't do that, App Review will reject it (if they find it). Restore Purchases should always be initiated by the user pressing a button.

No, there is no way to bill a variable amount at the end of the month. That's assuming that IAP applies, i.e. the product is consumed in the app.

Dear Jason, Thank you for confirming that the email was genuine. Can you explain why such a short notice period has been chosen for the removal of this feature? Of course features are sometimes removed, but I can really never think of a case where there has been so little notice - just five weeks, or only three weeks if you start counting at then point when Apple stopped telling me that the email was a hoax. I had to double-check what year it is when I read "April 2022". ODR content will ... have a similar level of security as other Apple-hosted content. But not the same level of security as SKDownloads, which are restricted to users who have purchased the corresponding IAP. Here is a quote from the StoreKit documentation: Most apps should use Apple-hosted content for downloaded files. You create an Apple-hosted content bundle using the In-App Purchase Content target in Xcode and submit it to App Store Connect. (snip) Note Alternatively, you can use On-Demand Resources (ODR) for more flexibility in downloading data in your app. ODR is an Apple-hosted service you can use to store in-app purchase data for the user to download content once you've verified the user's purchase using the app receipt. The advantage of this alternative over SKDownload is that ODR doesn't require you to call to restore transactions and authenticate the user to download content hosted on Apple's server. My emphasis. You claim it is an advantage that ODR does not require authentication. What The????? If you need technical advice implementing ODR, you can submit a Technical Support Incident. Developer Technical Support does not assist with the implementation of anti-piracy / digital rights management features. (Unless that has changed. Please let us know if that policy has changed recently.)