the app will not install on iPhone running iOS 18.1.1 IOS 18.2 is still in beta. App Review will reject apps that require a beta version of the OS. Your simplest option is to wait until 18.2 is released before submitting. If you don’t want to do that, your app needs to run on 18.1; can it function usefully without the 18.2-specific features?

Submit something that you think is reasonable and see if they reject it. Beware of situations where the iOS-reported location has low accuracy, e.g. a non-GPS iPad.

Most often this is because the review bot has found the words “Android” or “windows” in the app description, screenshots, etc.

It does rely on people actually searching for something related to your app. I have one app where there has been one install in the last 3 months. Generally, if you think you'll make $x from each person who buys your app, then ads will cost $x+1. They are only useful if you want to gain users irrespective of the cost, for some reason. The bottom line is, find other ways to promote your app.

I think I'm doing it right: mirror the data into an array twice the size of the original, pass that in as the real part, pass zeroes in as the imaginary part, then take the real result. According to Wikipedia: https://en.wikipedia.org/wiki/Discrete_cosine_transform#Formal_definition ”This transform is exactly equivalent .. to a DFT of 4N real inputs of even symmetry where the even-indexed elements are zero. … DCT-II transformation is also possible using 2N signal followed by a multiplication by half shift” What is the “multiplication by half shift” that they refer to? Is that what you’re missing? Have you tried the version with 4N inputs to the DFT?

OK. I read "always allow" as perhaps meaning that you were not actually validating sandbox receipts. It looks like you're doing it right. Sorry, I don't have any particular insight into your problem.

Possibly related? : https://developer.apple.com/forums/thread/766718 https://developer.apple.com/forums/thread/766030

our server side validation followed the guidance to always allow sandbox receipts What do you mean by "always allow sandbox receipts"? I hope you don't mean that when you receipt a sandbox receipt, you always just accept the request? The page you linked to says: "call the production URL https://buy.itunes.apple.com/verifyReceipt first and proceed to verify with the sandbox URL if you receive a 21007 status code." What exactly are you doing?

Your question seems related to a consumer feature and is better suited for the Apple Support Communities Dear Apple Bot, Please just delete the spam, rather than redirecting it to another forum. (I note that the bot reply got an upvote, I guess from the spammer.Does the bot algorithm learn from upvotes? That’s not going to work, is it?!)

No.

The structs aren't modified while being read, shouldn't a class and a struct behave the same in this situation? No. I think the problem occurs earlier than you think. In Swift, structs have mutable value semantics and classes have reference semantics. What happens in your code is that: var array2 = [CustomType](repeating:CustomType(), count:numElements) This has created a single instance of CustomType which every element of array2 now refers to. You can probably work out the rest. When you set e.g. array2[index].x = sin(rads) you have updated the x property of that single object, which you'll now see when you read from array2[another_index]. Call it "spooky action at a distance". On the other hand, when you do array1[index] = CustomType(....) you have created a new instance that is not shared. This is one of those things that is almost cultural and gets embedded in how developers think. In languages like Java that have primarily reference semantics it all seems totally natural once you've been doing it for a few years. But if you're used to value-semantic languages then this is something you'll constantly be tripping over if you have to move to the "other side". Generally, use structs for everything. Only use a class if you have a very good reason to do so.

(Post replies, not comments.) I use public key pinning in my clients to make it hard to drop mitmproxy in front of the app to harvest tokens, but perhaps they have worked around this. No, what I mean is, if I, an attacker, have my own trivial app, and I collect tokens that my users send to my server (no MITM needed). Then I send those tokens to your app's API. Have you ever attempted to decipher the format of the tokens? I spent a few minutes trying to work out if they could be cbor or asn.1 or something, but reverse-engineering isn't really my thing.

Are the tokens all different? Something I have wondered about is whether the DeviceCheck token is actually tied to your app or developer account. What happens if I get a pile of tokens from users of my app, and use them in fake requests to your server pretending to be from your app? Have you also used AppAttest? Based on my experience, I'd say you shouldn't expect to get any useful help from DTS (nor Feedback Assistant, nor anyone else at Apple) for problems like this. If they do have a weakness, they probably already know about it and they aren't going to discuss it with you.

Try changing the class to a struct.

I do not know where to start in finding the database for the current users If the Flutter docs don’t tell you where it is, use the “download app container” function in the Devices and Simulators window, and look for it. reading the data Google “swift sqlite” will find StackOverflow posts and github projects describing how to access sqlite databases from Swift. and inserting into the SwiftData schema. Someone else can comment on that; I don’t know much about SwiftData.