I have an app that includes the original version number in analytics that it sends me. I'm getting this by decoding the receipt in the app, not using AppTransaction. Examples of the version numbers that I get are 4.4.1622388619, 1.2.2 and 2.4. This is an old app. At some point, I started using timestamps as build numbers - hence the 1622388619. At other times I had three-level version numbers, i.e. 1.2.2 is the second bug-fix update for version 1.2. The missing part of the puzzle is what values these versions of the app had in which keys in their info.plists. Looking at just the current version of the app, I have CFBundleShortVersionString = 4.11 and CFBundleVersion = 4.11.1718374078. I believe these are manually set in the info.plist, rather than letting xcode populate them from other fields in the build settings (it's an old app, that's how it used to work). This reports the full 4.11.1718374078 in its analytics. So I guess that the "original version number" that you get from AppTransaction will be the same as the CFBundleVersion in your info.plist - whatever that is. You are probably letting xcode create this field, so check what is actually present in the info.plist in your final app. If I were you, I'd parse the string from the AppTransaction. If it has one component, assume it's a build number; if 2, assume it's a short version number; if 3, assume its version number plus build. (Etc.) Then determine whether it's "new" or "old" based on whatever you have. If you're using revision control versions or checksums, timestamps, or a global counter for your build numbers, this shouldn't be too difficult. It's more problematic if you have incrementing build numbers that you reset for each release. Note there is also the original purchase date, which could be easier to use. (I understand this is different on macOS.)

You may find it in some ARM architecture specs, if you’re lucky.

App Review has some idiotic bit of artificial stoopidity that scans your app for the string “ir” and if it finds it, rejects the app for being associated with evil Iran. The only way to fix this is to remove that text. My guess is that you are using some sort of 3rd-party app builder, right? If that’s true, ask them about the problem - you won’t be the first, it might even be a FAQ. If not, come back here and maybe someone will have some suggestions about how to track down, and rename, the offending code. Rest of the world, watch out. Right now I think just about anywhere - Mexico, Canada! - could find itself on the US sanctions list and subject to this sort of treatment.

Very mysterious.

I'm glad you got it fixed. I think it probably comes down to your account being "Lendable" and the app store metadata description mentioning "Zable" and Apple not (initially) being able to tie those together. It's quite possible that the issue will recur. There's not much you can do about that, unfortunately. Opaque, non-specific replies from Apple without any possibility of elaboration are to be expected.

I don't know what they require, but can you clarify Which domains are in the app description etc? Is that zable or lendable? Which domains are shown in the app itself? Is your developer account name Zable or Lendable? You might also consider removing the "privacy protection" on your domain registrations, so that whois queries return something resembling your correct physical address. I don't think Apple will be using that but it could be considered good practice anyway.

Could anyone clarify why Apple Reviewers, when rejecting the app under Guideline 4.3(a) - Design - Spam, do not provide any specific details? Because they don't have to. Your relationship with Apple is governed by the developer agreement that you signed. It says what you and Apple have to do. There is nothing in there that says that Apple has to provide any reasoning for their rejections. See section 6.9.

I don’t think that being free will result in rejection. You may, however, find that they consider all new dating apps to be “spam”. I say that based on the number of forum posts from people who report “spam” rejections.

Does it depend on your locale?

Promillewert Is it the ‰ of alcohol in the blood that you are referring to? Or is it something completely different? (I know that gradients on railways are expressed in ‰, for example.) If you are trying to create a blood-alcohol estimation app, I suspect that that is banned.

Can you not just photoshop it?

2024-05 surely?

There was someone posting a few days ago who had been waiting for 3 months. Scroll through the forum and see what you think. 36 hours, at the weekend, seems fine to me.

Are you saying the implementation of SIMD3 is not a collection or struct of three separate values? No, I'm not saying that; the Swift SIMD type is certainly just a struct of regular floats. I believe the corresponding GPU arithmetic is too. But by the time these values have gone through all of your transform matrices, and in particular perspective devision, every value could have had some sort of influence on every other. However, as I said, "there could be other issues involved". Keep debugging.

Yes, floating point values get less precise the larger they are. If that is a complete surprise to you, read something about floating point. Whether that explains what you’re seeing or not, I don’t know. There could be other issues involved.