We will not create paid apps. Nor in-app purchases, right? Do we need to sign the Paid Apps Agreement? I don't think so. Why do you have any doubt?

Quinn, can you remind me why this has to be a class method, rather than just a global function?

We even had an online meeting with the Apple team, who suggested that we review and revise the app to ensure compliance before resubmitting it. Following their advice, we made several updates to DreamGF to align with the App Store's guidelines. Let this be a warning to others: these "discuss your problem on the phone with an App Review representative" sessions are often not helpful in practice; you do what they suggest but still get rejected (or in your case worse). More generally, be aware that Apple terminate vast numbers of accounts - 428,000 in 2022, according to their own press release. I find this terrifying. The lesson is to make sure that you're not entirely dependent on Apple for success, i.e. don't get locked in to making Apple-only products using Apple-only technologies that you can't quickly port to other platforms if that becomes necessary.

No chance. Just do what they say.

not to do what you describe “Write a short Swift function that calls StoreKit, and call that from objC”. Maybe you know about some documentation describing how to do this? Just write a swift function (you’ve already done that, or start again with hello_world) and look at the generated bridging header; that will show the syntax of the objC call. (With some obfuscation probably). Things to note: There is the @objc annotation. async functions need the withCompletionHndler stuff mentioned earlier. I recall having to write a class with a single static method, rather than a function. I don’t recall the details.

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.

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.

Should I be concerned Quite possibly, yes!

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.)

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

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.

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.

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

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???

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?