Generally this should work. I don’t see any clues in your post about why it isn’t working for you, unfortunately. Keep trying!

So just get rid of the screenshots displaying the functionality? Get rid of the prices. Blank them out, or blur them, or something. Maybe removing the $ symbol would be sufficient? (Yes, I know that they aren't the price of the app. But the app review bot doesn't know that, and you have no realistic way of explaining that to it.) This is V2 of my app, and V1 screenshots are virtually identical. However, this was never a problem. Past performance is not a guide to the future. I had screenshots that included the word "free" for many years but they were eventually rejected. I think they must have added OCR to the screenshot review bot at some point.

Are you sure that iTMSTransporter is still supported for this? I had to stop using it, and use the App Store Connect API instead, when they removed IAP support a few years ago. If iTMSTransporter is still supported "in theory" for app metadata updates, it still wouldn't surprise me if it is not well maintained in practice.

Is there a way for us to stop the auto renewal? No. (Well, maybe if they send you their Apple ID password etc...)

Have you looked at the generated assembler? How are you measuring the performance? My last attempt at writing NEON code was also disappointing. Looking at the generated code, in my case it was clear that the NEON version had a significant overhead before and after the NEON instructions to move the data to and from the vector registers; on the other hand, the non-NEON version was better optimised and actually managed to use some vector instructions. In your case of 64-bit elements the best possible speedup is 2X, while with 32-bit elements (e.g. floats) the best-possible is 4X, and with bytes it is 16X. Based on my experience, I wouldn't try to use NEON in order to get only a max 2X improvement - but I probably would consider it to get a 16X improvement. 4X is borderline. Is this code for a board game?

Have you looked at the generated assembler? no, how to do ? I have to Google it every time I need to do it. You'll find Stack Overflow answers for ancient versions of xCode, and things have changed a bit. I think the key is the menu item "Product" -> "Perform Action" -> "Assemble (filename)". Or, if it's a small self-contained file, compile it on the command line with clang -S. 2X will very cool.. The point is that 2X is the limit on how much performance improvement you will get from vectorisation. In reality it will be lower. Most likely there are other things you can do with better results. Does the algorithm have the right complexity order? What does the profiler tell you?

CoreLocation will correct received/perceived coordinates to known roads and paths When you say “correct”, you mean the opposite. - as @Toldy’s example perfectly demonstrates. based on the activityType. .fitness is one of the activity types that will use corrected coordinates. Really?? It always used to be that “fitness” was the one mode that did not snap the locations to where Apple thinks the paths are. Has this changed at some point???

I've had a reply to my bug report (9 months later) saying "this is currently expected".

they are not compatible with Sequoia 1.15.1. Don't use that, then. It's still a beta; don't expect things to work with it. Stick with 15.0 (or 14.x) for now.

Don't read the reviews; for reasons like the one you describe, reading your own app's App Store reviews will drive you MAD. If you really feel that you need to know what people are saying about your app, pay someone else to do it for you and write a summary. I'm not joking; this is serious advice, based on 15 years publishing apps and trying to stay sane.

This is what you need to do: Update the app's binary to include the following required information: A functional link to the Terms of Use (EULA) A functional link to the privacy policy Update the app's metadata to include the following required information: A functional link to the Terms of Use (EULA). If you are using the standard Apple Terms of Use (EULA), include a link to the Terms of Use in the App Description. If you are using a custom EULA, add it in App Store Connect. A functional link to the privacy policy

But I can't call it from Objective C. What happens when you try, using the ...withCompletionHandler syntax? (I have a very vague recollection of having to make something that could have been a function a static class method instead, possibly related to this.)

Should I be concerned Quite possibly, yes!

So do I have to do this now (today October 16, 2024) to prevent my apps from being removed from the EU App Store (or do I have until February 17, 2025)? Like it says, from today you must submit the info with any new apps or updates. Otherwise, you have till February. Like it says.

It doesn't matter how I try to use AppTransaction because XCode doesn't recognize Swift ketwords of types. Since no-one else is replying, I’m going to try and help - but beware, I don’t think I know much more than you. So: In an earlier post you showed your Swift checkReceipt function. But I don’t really understand what fails to work now. You just said ”I can’t call it from objC”. Can you show your objC code that tries to call that Swift function, and the error message that you get when you try to compile it? Is there some (undocumented?) trick to get XCode to recognize the Store Kit types? I wouldn’t try to call StoreKit’s Swift functions directly from objC. Write a short Swift function that calls StoreKit, and call that from objC - exactly as you showed above, but return a bool that the objC tests.