Have any other developers encountered a similar situation, and if so, how did you resolve it? Searching the forum for "spam" will find many similar reports, with very few happy endings.

This stuff is all very complicated and hard to get right. Your code appears to show a single hard-coded key embedded in the app; this is absolutely wrong. Don’t ever try to invent your own encryption scheme. (That doesn’t just mean your own encryption algorithm, but also all the supporting stuff like when you generate keys, how you distribute them etc.) Investigate the state-of-the-art and implement that, carefully. But first, ask yourself what your threat model is. What, exactly, are you trying to prevent by adding encryption to your system?

Yes, those are the options I had in mind. Oh well, worth a try!

Have either of you tried compiling with more fine-grained optimisation settings? In particular, have you tried with -O3 but with vectorisation disabled?

There have been previous threads asking this question, and not much has changed. Of course they aren't easy to find because the forum search is not amazing. You do not need a high-spec machine. It seems to me that the models with minimum storage are now difficult (but not quite impossible?) to use because Xcode is so enormous. (I have an M1 Mac Mini with 256 GB which is permanently 98% full.) Have a look at reconditioned products if you want to save a few $$$.

I thought that XCode was supposed to create this? Yes. If I were you I'd look at the timestamp on that file and see if Xcode has just created an empty file, or whether it has done nothing at all and that file is left over from earlier. And I'd look in the build logs. As you can tell, I'm out of my depth here...

[quote='810291022, Tlaloc, /thread/764537?answerId=810291022#810291022, /profile/Tlaloc'] The name-Swift.h header doesn't have a declaration for the verification function. What's wrong? [/quote] What did you declare in your Swift file? (Post the code.) What do you see in the generated header?

VAT?

No, endecotp, I can check what it's running on at run-time but that's not the problem. You can't build the project using AppTransaction unless you target at least 13. Ah yes; sorry, I was forgetting the difference between the min-version and the max-version. I forget the exact terminology. You need to “target” ( if that’s the right term) a newer version that has the Swift AppTransaction support and set the oldest supported version to the older version without AppTransaction that you still want to support. And there are some conversations about @available on these forums but not in the developer documentation. LMGTFY: https://developer.apple.com/documentation/xcode/running-code-on-a-specific-version Also if you target something like 10.15 you will get a whole bunch of compiler warnings about the security functions in your verification code being deprecated. It is possible to silence specific warnings for specific files. Either do that, or just ignore them. [MyAppTransaction checkReceiptWithCompletionHandler:^(NSString * _Nonnull status) { NSLog(@"status: %@", status); }]; Won't build - unknown object MyAppTransaction. Maybe some guidance about what to put in the bridging header would help? YOU don‘t put anything in the bridging header - it gets created for you. It ought to have a readable objC declaration of MyAppTransaction; if it doesn’t, something has gone wrong, likely related to how you added that to the project etc. Having only done this once, last year I think, I have no idea of the exact steps needed.

Also the undocumented API @available doesn't look usable because it checks the environment at runtime. What I would need would be conditional compilation, right? No. You need to check at runtime. Your aim is a single executable that will run in both older and newer OS versions. It needs to check at runtime and use either the old method or the new method, as approprite. I’m sure @available is documented somewhere, keep searching.

Right, if you need to support older OS versions you need a runtime check to determine which method to use. Do this (in objC) using if @available.

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.