I think that in this case you must have a global QAppleLogActuvity object, and its destructor is being run when your exception leaves main(). If that didn’t exist, you might get a stack trace for an unhandled exception at the point of the throw. I have a vague recollection that you may be able to disable running destructors for global objects at program termination with a build setting. That may or may not help. I’ve never got this to work in a useful way. What is your policy on use of exceptions? I suggest not using them unless you are actually going to catch them. For unrecoverable fatal errors that “shouldn’t happen”, use assert().

Does your organisation also make/sell the IoT device? What sort of organisation is it? Here's a scenario where you may not be a trader: the IoT device is made by someone else, and your organisation is an open-source project that makes an unofficial app to control that product. If the open-source project is just a group of volunteers with no business structure, then you might qualify as not being a trader. In just about every other situation, you are a trader.

If you think it's a one-person job, you are already way out of your depth. I’m a one-person business, and I’ve done all this - app receipt validation, DeviceCheck, App Attest, etc. You could do it if you wanted. I would still caution that you need to balance the costs, including the costs of false positives, against the benefits. The whole point of my post is to get feedback from Apple Feedback from Apple is quite rare on this forum. More likely, you’ll just have to listen to other developers sharing their experience.

If you want to do business in Europe and the UK, and you want a backend service that stores information about your customers, then you are legally obligated to comply with the GDPR Not quite; it’s only an issue if it’s personal information that you store. App receipts do not include personally-identifying information. You can do that without any great concerns. Even working by yourself, you do have the option of getting legal advice. Or maybe taking a course. You're making disparaging assumptions about my abilities I’m sorry that it sounded like that but I had guessed that you were avoiding doing receipt validation because it seemed too complex, rather than due to your legal concerns. The idea that I should simply tolerate pirates to ensure the app's reputation on the store is just bizarre to me. Everything that I wrote is based on my own, recent, experience (though with iOS apps, rather than Mac apps, which does make a difference). This is a judgement you have to make based on your own priorities. The idea that people who are willing to pay for your software, won't download it for free, given half the chance, is naive. The type of app you choose to work on is a factor. I recall a great Dilbert where he has a chart that says poor/rich on one axis and stupid/intelligent on the other. He’s pointing at the chart saying “we’ll be targeting this market segment”. If your app mainly appeals to smart kids with not much cash, you’ll get a higher piracy rate than if you take Dilbert’s approach.

As an indy developer, it's prohibitive to start developing backend receipt validation services. Why do you say that? Do you think it will take too long to learn the required technologies? Or maybe you think the cost of server infrastructure will be unaffordable? Why specifically does it matter that you are an “indy developer”? You do have DeviceCheck on Mac (though not App Attest, IIRC). I wouldn’t say it is easier to use than receipt validation. Beware of the danger of false positives. If someone pays for your app and then for some reason your code decides they’re a pirate, they will write a 0-star review and your sales will fall. How many blocked pirates are worth one bad review? Bad reviews can be catastrophic, and generally pirates would not have paid for your app anyway.

Apple went through my code with a fine tooth comb No they didn’t. Is the the handling of our home network credentials also heavily scrutinised before thing are allowed on the Apple Store? No. home security products If you mean cameras, there’s a lot more than your WiFi password to worry about, i.e. it’s a camera.

So that means that only users of iPhone 8+ or earlier will see those screenshots. BUT, since the app required iOS 17+, they can't run the app. The app store won’t let you buy apps that the device won’t run. I think no-one will see these screenshots. Has anyone tried just uploading a single blank image of the right dimensions?

I've been bitten by the case of HTTP headers changing in the past. I think I had a header name containing an acronym embedded in a phrase, which I was sending as Total-USA-Population: 42, but it arrived at the server as Total-Usa-Population: 42. I forget where the transformation happened. Always check HTTP header names case-insensitively!

My app has only received around 500 impression over 4 or 5 days. How can I fix that? Bid more for your search ads.

just trying to prevent any unexpected bugs happening later on. Don't waste your time on this; I bet you have other code that is a million times more likely to fail.

I really want to know the time estimate to setup and XCode project, considering project as an average case Somewhere between 30 minutes and 15 years.

what should i do ? Give up. Apple don't want your app on their store, because it is related to their competitor's products.

I have already provided a comprehensive description during submission on how to access the In-App Purchase (IAP) as text and video. Borrow someone's 90-year-old aunty, and see if they can successfully follow your instructions for finding the IAPs. Watch carefully what they do, and update your instructions / video as necessary. If that doesn't work, add a lot of tracking to your app so that it tells you what App Review actually do (if anything). Don't expect them to provide any more details about how far they get, etc.

I posted something similar here: https://developer.apple.com/forums/thread/749462 In my case, the phone number is redirected; I think Apple's bot gets confused by the two levels of ring tone and hangs up too soon. You could file a bug, ha ha. Mine was closed with "too little information to diagnose". Is there anything else that I can do here? The easiest solution is probably to buy a "burner phone", use it once for this verification, and then dispose of it. I'm going to wait before doing that, in case they fix it. It may also be that they remove the requirement to disclose a phone number. I think that's less likely to apply in your case if you do literally have a head office with a receptionist, but for all the one-guy-in-his-garage businesses that literally don't have a business phone number, Apple's interpretation of the rules could change. Please let us know what happens in your case.

Using a third-party service I can see the list of keywords that are associated with my app. Can you? Really? How do you think they get that info?