We appreciate your interest in participating in the forums! Last time we discussed this, we were told that there are no Apple "bots" on the forum and these messages are written by actual human Apple employees. I don't believe that There is no way that Apple could possibly employ someone who reads that obviously-spam message and thinks, "this needs to be on the Apple Support forum". No, impossible. So, I'm going to downvote the obvious bot message. Let's see what happens.

What's the customer experience for those with the old app? It's a completely different app.

What sort of in-app purchase is this? Subscription / consumable / non-consumable… Why do they believe they’ve been charged twice? (Ask them to send a copy of the receipt that Apple sent them, or a screenshot of their purchase history.)

I could access it on a phone where I am connected with an Icloud account in the developper list of the apple development account. I'm not sure what you mean by "in the developer list". The account needs to be a sandbox account. Just using your real Apple account, which is the one that is associated with your developer account, is not sufficient. (If I understand correctly.)

the IP address mentioned in Developer forum post 17.188.143.34:443 is not the one which responds to api.sandbox.push.apple.com:443 address Right. It's a test server, set up temporarily so that you can check that you have done your certificate replacement correctly. Quoting the linked post: We have setup a test server at 17.188.143.34:443 that you can use to try and send pushes to test whether your new root certificate is correctly installed. I think the IP address you've given is probably for the live server.

I guess that the char* that you get from xpc_dictionary_get_string points inside the dictionary, and not to a copy. I.e. the bytes are freed when the dictionary is destroyed.

Never. Or as close to Never as makes no difference.

I reported this bug one year ago in https://developer.apple.com/forums/thread/746406 That's not a bug report, it's a developer forum post. Have you actually submitted a bug report?

There are lots of reports of rejections for "spam" here on the forum, but we rarely or never get to the bottom of what Apple does or doesn't currently allow. You are wise to be cautious.

why is apple won’t adding Just-In-Time compiler to ”Emulators” in the app store. And/or hypervisor for newer devices Because emulators would allow users to run arbitrary code that they download not from the app store, bypassing Apple’s commission.

If you don’t have C++ code in your project, none of this matters. For a new project, I suggest choosing C++23. Choose the GNU option only if you know you’ll be using GNU extensions. Choose an older version only if you know you have code written to an older spec and you know it had problems with newer language variants. Note this isn’t choosing a newer or older version of the compiler - rather, it’s telling the current compiler to support a different variant of the language. It turns features on and off. I think the default is an old version in order that old code doesn’t suddenly stop compiling when you update Xcode. I disagree with the suggestion that this is the best choice for a new project. Set it to the current version when you start a new project; when you get a new compiler that supports a newer version, consider whether to increase it or not.

Were using Linking.openURL(‘items-apps://apps.apple.com/account/subscriptions’); In that case, try changing to use the thing I linked to or similar. (There are different versions for UIKit and SwiftUI, IIRC.)

Are you using this:? https://developer.apple.com/documentation/storekit/appstore/showmanagesubscriptions(in:subscriptiongroupid:)/ If not, what exactly are you doing?

The clue is in the name, isn’t it? I would not expect a “local identifier” to be valid on a different device. The change on iOS update seems less reasonable.

is there a way to create a Date constant from year, month and day? No, because the bizarrely-named Date type isn’t a date, it’s a time-point. Everywhere that I use Date in my code there’s a comment saying “actually a DateTime”. If you want to represent a date (only), don’t use Date. I suggest writing your own type that contains either year-month-day fields or a Julian Day Number. I'm used to Python which has both naive and aware (of time zone) date time values. Does Swift have a naive date time concept? There is also DateComponents. You’ll probably get frustrated by not having exactly the combination of features that you want, and unless you are constantly passing these things to and from Apple APIs, you’ll end up writing your own replacement.