copy my contribution before I submit it I always remember to do that one millisecond after pressing submit.

I suspect that this library is based on BSD Sockets It uses kqueue: https://github.com/boostorg/asio/blob/develop/include/boost/asio/detail/kqueue_reactor.hpp

Posts like yours are quite frequent on the forum. I don't recall anyone ever reporting that their account was re-instated. You are probably doomed. I find this constantly terrifying. The lesson is, don't rely entirely on Apple for your income. Make sure you have your eggs in more than one basket. Don't spend your time specialising in Apple-specific technologies, but make sure you have technical skills that you can redeploy to other jobs when necessary.

I think you're referring to Boost . B e a s t, right? Is that a profanity in Cupertino? Weird. How exactly does it fail? Do you have other ASIO code in the app, and does that work?

Are you seeing this in development or in production?

Does Apple's app validation team use this network mode to test applications? I very much doubt it. I guess there is some other networking problem.

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?