You are only sending the receipt when you believe that a purchase has been made, right? Do you know if the problem is permanent or transient? If the user can try again and then it works then it is less serious. Have you actually looked at the raw receipt content to see if it contains any IAPs? Possible causes include: Your bug. Apple’s bug. User has hacked the app. This is difficult to debug unless you are in contact with one of the end users who is affected. Consider adding something to the app encouraging users to get in touch when this happens. You can then ask them, for example, “what is unusual about you? did the payment go through? is your device hacked? are you running an iOS app on a Mac, or some other unusual setup?”. In my experience, a small number of users will fail verification (specifically in my case, AppAttest and DeviceCheck) with no good reason. (I.e. I believe it is Apple’s bug). You should consider whether receipt validation etc. is actually worthwhile, compared to just trusting that the app is not hacked. I.e. is the cost of providing your paid content to users with hacked devices who have not paid more or less than the losses you suffer when a genuine user is declined and writes a 0-star review.

Try character 2007, “figure space”. Alternatively: I can use fixed width fonts (like Menlo), but I've not found one that fits (the zero is barred, which is not looking great in the app) It may be possible to change that; fonts often contain glyph variants such as different shapes of ‘a’ or ‘7’. (I think the Notes app uses the ‘a’ variant). Note these are not different unicode code points. Sorry, I forget how to do this with UIFont.

The deprecated APIs still work so you could just continue to use them for the time being. Otherwise, you will need to learn enough Swift to implement this part of your app using it. Combining the two languages in one app is not hugely difficult. How complex it is will depend on how much StoreKit functionality you need.

@IBOutlet weak var navigationBar: UINavigationBar! Good, I'm glad you found it! My practice has always been to use a different capitalisation/punctuation style than Apple, to avoid this. For example in this case I would have called it navigation_bar. This has been a reliable way to avoid problems.

found one result in but couldn't find any details about location or file that generated this Post some more info about what you found and someone might be able to help you work back to the responsible source file or library. Some possibly-related threads: https://developer.apple.com/forums/thread/733475 https://developer.apple.com/forums/thread/748621

I guess I am failing to understand. There seem to be two issues; which do you not understand? Is it this: Please note that although App Review Guideline 3.1.2 requires an app to make subscription content available to all the supported devices owned by a single user, it is not appropriate to force user registration to meet this requirement; such user registration must be optional.. Or this: Accurate Metadata We noticed your free download app requires users to subscribe prior to accessing content or features, but this requirement is not clearly specified in your app description.

figure.stand and figure.stand.dress (The latter is iOS 18 +, surprisingly. There is also figure.stand.dress.line.vertical.figure)

Just FYI: // C++ function to return the number of elements in a C array. Usage: // sometype X[231]; // assert(elemsof(X)==231); template <typename T, size_t N> constexpr inline size_t elemsof(const T (&) [N]) { return N; }

sizeof(x) returns the size of x in bytes, not the number of elements in the array.

have a global state signalling "receipt was verified" and unless that is true, bock all UI actions the user might want to perform in a purchased app. Right, consider the app "unverified" until the await has returned.

What I want to do is verify that the app was actually purchased through the app store and not just copied over from another computer. Disclaimer: I know more about iOS than macOS. Do you believe that your developer build should fail to run if copied to another computer? I'm not sure about that. I would hope what you are doing would correctly identify app store builds that have been copied. I don't know how you would actually test that though, at least not until it has been published on the store.

Or is that video from 2021 is just too old and not up to date anymore? Correct. At that time, there was no AppTransaction. I believe that what you are doing is correct. (Maybe you should also look at some properties of the verified receipt object?) I’m unsure what exactly your problem is. You seem to think that verification should fail in development, or that it should succeed only after an App Store login dialog. I’m not sure why you think that. If you think that only because that’s what happened in the old system - well, that was the old system.

if they can’t tell you how to generate it, they are not worth doing business with.

It’s not a “Linux signal handler”. “POSIX” or “Unix” might be a better description, though they are also defined in the C spec. The first thing I’d do is look at the generated assembler. Does it optimise-away the 5/0 ?

Your question seems related to a consumer feature No it isn’t, it’s just spam.