My App gets rejected / Guideline 5.6 / Can't reproduce bug

You should submit a DTS ticket to help find out why the dialog is being displayed.

Oh I didn't know that existed. I definitely will do so. Do you think they will be able to help even though I can't myself reproduce the bug?

Edit: also, we use a nocode software to develop our games (Buildbox). Does it make sense to request code support if we can't touch the code (outside of Xcode) ourselves?

We tested in the mean time even more devices, namely a iPhone 7 running iOS 12.1.4 and a iPhone XR running iOS 12.1.4 as well. The bug doesn't occur on any of those.

We also submitted a new build, this time with Xcode 10.3. Maybe Xcode 11 is somehow clashing with our development software (Buildbox) since before we never had issues.

In that case, I'm certain that they will not be able to help. DTS offers "code-level" support. But if you are relying on some 3rd party tool that insulates you from the code, then you have no code that Apple can help with. Furthermore, this is virtually certain to be a bug in BuildBox.

I suggest that you reject the build you just submitted and contact BuildBox. Even though you appear to be honest, you are also mimicing the behaviour of scammers. There is a possibility that repeated efforts to submit this app could cause Apple to kick you out of the developer program altogether.

Is there any chance your code, as run by App Review, might be executing the following commands:

restoreCompletedTransactions

SKReceiptRefreshRequest

They will generate a request to sign in.

Thanks for your reply.

I'm not sure, but this is something I can ask directly to Buildbox itself. Or is this something I would see in Xcode log?

And are you saying - in case it executes these commands - this is something that only would occur for the review team in their 'review' mode? And basically be 'invisible' for anyone else (hence it's not happening on our own devices)?

I note from the Buildbox their website:

"Coins are more than just a way to keep score, in Buildbox. ........We’ve also included advanced power-ups, continue and checkpoint system with in-app purchase options."

Who knows what "Buildbox" has put in the code? They may well be checking the user's receipt to see if there are any purchases - just in case. Perhaps the receipt looks different on App Review's devices and Buildbox decides it needs to refresh their receipt but not yours.

> this is something I can ask directly to Buildbox itself.

Yes, stop now and do that. They might not yet be aware and thank you for the heads up.

At the same time, search that project for both restoreCompletedTransactions & SKReceiptRefreshRequest so that you can be aware as the conversation with both bbox & app review goes forwards.

And to cover all bases, you might want to start looking for an alternative to bbox that allows you to continue in the store should they prove to be a dead end.

And I agree w/John that DTS needs a project that replicates the issue vs. a 3rd party app generator, however, you might want to file a bug via the reporter link below just to see what comes back.

Good luck.

We talked to Apple support directly yesterday by phone and they told us that it's best to wait out the last submission (still waiting for review).

Since we removed the IAPs completely from our last two submissions in the dashboard there shouldn't be any prompting related to it. Even if there is code left. I'm not sure if that is correct or not, but in the last submission we also removed the IAP capability in Xcode itself.

We did in the meantime as well a Testflight build and tested on several devices with the help of fellow developers and not in one case we were able to reproduce the issue. According to Apple documents, a Testflight should be 100% identical to what the reviewer tests. Is that correct? If so, the only thing left is some setting on the reviewer's device that might somehow trigger the behavior. But either way, it's completely weird that it does so.

Regarding Buildbox, we have used it for many games and never had problems. Including the version we currently use for development we have used it previously for other releases too. The only thing that changed is that with this submission we used Xcode 11 for the first time. Our last submission is with Xcode 10.3 so if the combination with Buildbox would trigger some sort of clashing that last build shouldn't have that issue either.

Support also suggested to file a DTS since at least they should be able to reproduce the issue, so this would be one step closer to resolve the issue (with or without Buildbox support). I think that is a good idea so we will do this too.

We appreciate the help from all of you and will update here if we have any news. Thanks a lot.

Shouldn't be a Testflight build be exactly the same what the reviewer tests/sees?

Source: https://developer.apple.com/library/archive/qa/qa1764/_index.html

>The only thing that changed is that with this submission we used Xcode 11 for the first time. Our last submission is with Xcode 10.3 so if the combination with Buildbox would trigger some sort of clashing that last build shouldn't have that issue either.

If you are still using a 'combination' of bbox and Xcode, what does that mean? Does it mean you generate an ipa outside of Xcode, then sideload that into Xcode, and use Xcode to upload to the store? Do you have a full native standalone Xcode project or not?

I would not assume there is any way to guarantee you can reproduce Apple's environment.

I also don't agree with what Developer support told you. You aren't getting normal rejections, you are getting "code of conduct" attention that "may result in the termination of your Apple Developer Program account". I don't know if Developer support knows your status or not. When you are a bit player in a big ecosystem like this, it is easy to just be unlucky one day and get caught up in something you never intended. This is a quantitative world, not a qualitative one. It is like someone who gets wrongly convicted of a crime when they did nothing wrong. Maybe they were at the wrong place at the word time. They might get exonerated, or ultimately found innocent. But it can take years and easily bankrupt them.

Generally speaking, you want to stay in the automated flow. If you ever fall out of that, you'll need a human to fix it. That could take months. This isn't fair, but you don't have be fair when there is such a huge discrepanacy between parties.

At this point, it certainly looks like there is a problem with BuildBox, Xcode 11, and app review. Your developer account is already halfway out the door. You have another app waiting for review and you have no idea what it is going to do when app review sees it. It sounds to me like only the safe option is to reject the app, rebuild it on 10.3 or whatever you know works, and resubmit it with detailed notes, including a reference to your DTS ticket where you are still working on the Xcode 11 issues. (Again, I think that is a waste of time because it is a BuildBox problem, but oh well.) You can expect an extra long review time in any case. But I think this course of action would reduce your risk of rejection and ejection from the Developer program. What's really at risk here? How much does your company, app, and job depend on your Apple Developer program membership?

>Is there a way to 'hide' code from Xcode? Like encrypted or something so it wouldn't be found when searching thep project?

Yes, it can be done. And doing so might cause your "5.6" rejection. Note that when you 'search' the project you do not search the frameworks.

> Since we removed the IAPs completely from our last two submissions in the dashboard there shouldn't be any prompting related to it. Even if there is code left. I'm not sure if that is correct or not,

That is not correct. Removing the IAPs from App Store Connect does not prevent the app from attempting to restoreCompletedTransactions or restore the receipt - that generates an immediate log-in request from StoreKit.

> but in the last submission we also removed the IAP capability in Xcode itself.

If this means that in your earlier submission you had StoreKit then it is very possible that BuildBox (or you, accidentally) may have called restore or referesh. I think if you eliminate any link to the StoreKit framework you are ok. I do not know if BuildBox might have StoreKit API by a different name in its bundle that you are including. Again, a simple search does not search the code in a framework.

> According to Apple documents, a Testflight should be 100% identical to what the reviewer tests. Is that correct?

It is not identical but it is similar. (Unless 'should be' is advice from Apple regarding the structure of the builds not an implication that the testing process is identical.) App Review is testing a build that is signed with your production certificate. Testflight is testing a build that is signed with your developer certificate. Therefore, for example, Testflight hits the sandbox environment naturally. App Review does something special so that their build also hits the sandbox environment even though it initially is aims at the production environment. But a developer can easily detect they are under review and alter the program to 'fool' App Review - again risking being thrown into "5.6" territory. (This is actually quite reasonable if, for example, you want App Review to test all levels of a game without needing to spend 3 years mastering it.) Perhaps your friends at BuildBox are doing something that looks like that to App Review.

Thanks for the reply. The last submission is actually exactly that. A build with Xcode 10.3 that until now has always worked and never triggered such a behavior.

We are still waiting for the review and submitted yesterday more information and asked as well for more detailed explanation on how to reproduce the issue on our side.

And yes, as you say, we actually do depend 100% on Apple's platform and membership with our business which is exactly why we are not able to sleep anymore for over a week now. We hope that we are doing everything correctly and really are trying to resolve the issue. I don't think that at this point we really can do more than that and hopefully Apple sees that too.

The other option would be to forget about the game completely and remove it from the store. But this would be -from our side- the very last option to consider as we really like it and worked hard on it to get it to where it is right now. Feedback has been great from early tests and we also have prepared a user acquisition strategy that we would like to put into reality. We also prefer to find and work on a solution rather than just step back. This way we learn and move forward.

It's such a difficult situation tbh.

OK. That's all you can do. You can expect your review to take an extra-long time unfortunately.

I'm sure this is a BuildBox problem. They are the people you should be complaining to. You should also be taking steps to eliminate your dependence on them.

Here's the problem. When you have such a hard dependency on a 3rd party, you aren't using Xcode anymore, you are using BuildBox-Xcode. You don't have the freedom to update Xcode, iOS, macOS, or any other 3rd party software you have until you get BuildBox's official authorization. Someone has to test all of this. I can guarantee that BuildBox is not going to test until everything is in released state. You are welcome to be the first to beta test if you want. It's your company. You can bet it all on Buildbox if you want. Have you even contacted them yet?