App rejected from App Store

I’ve put together an app and submitted it to the App store (for initial beta testing). It got rejected, the reasons given were:

We discovered that your app contains hidden features.

This app supports the downloading of assets and execution of non-native code.


During review, your app installed or launched executable code, which is not not permitted on the App Store.

This app supports the downloading of assets and execution of non-native code.

In short, it doesn’t. It’s an app for drawing Celtic Knots. The only interaction with anything outside the app is that it can save a picture to the camera roll. So I suspect that something triggered that warning. My question is, what do I do now?

My options are, as far as I can tell:

  1. Figure out what triggered the warning and remove it, resubmitting the app.
  2. Submit an appeal, explaining that it doesn’t download assets or execute non-native code.
  3. Forget the whole deal.

Clearly, people do successfully submit Codea-made apps to the app store so there must be a way round this. Can anyone help me from their experience?

@LoopSpace You said you can save a picture to the camera roll. How are you doing that. Maybe that’s what they think is launched executable code. I’ve never submitted anything to Apple so I don’t know what’s all involved. When you submit something, how much information do you have to supply. Do you list what the program is supposed to do and a test plan explaining how to run the code. Or does Apple just start running the code looking for anything strange.

The code for saving a picture to the camera roll was based on @tnlogy’s Image Tools add-on (original post here). That uses standard APIs so I don’t think that can be what they’ve flagged.

You have to list special stuff, so if you have user accounts or link to an external system (sort of like facebook might) then you have to declare that and provide testing accounts. But there’s none of that in my app, so I think that Apple just start running the code.

@LoopSpace Maybe when whoever at Apple tests code and they’re not sure about something, they pick what they think is the closest reason and reject it. Is there any way to ask Apple for a specific reason why they think something is wrong and what they’re looking at.

You can submit an appeal, but I wanted to know if anyone here had any experience first just in case I’ve overlooked something obvious.

@LoopSpace I would say that @Simeon or @John would be the best to respond to this with as many times they submitted something to Apple.

Not speaking from experience but I would definitely seek clarification from them. Explain that the only thing you could see might be an issue is saving to the camera roll. It might be that the original add on code (which appears to be 5 years old) may no longer be compliant with the latest guidelines?

@LoopSpace I got a similar rejection a couple of years ago when an app failed while testing, and displayed the Codea screen, as in console and error message on left. Once I fixed the bug (I forgot to add a permission to his a web service when compiling) I didn’t get the rejection again.

@Mark, thanks for that. I think that the Codea screen does flash up at rhe start - should I move displayMode outside setup? - so that might be it.

(Maybe the exported runtime should handle errors a bit differently and never risk showing the console.)

@LoopSpace We’ll have to look into this. I would suggest asking for more information. They may be referring to the fact that Codea apps are executing interpreted code that is initially copied from the app bundle into documents. They relaxed this restriction on coding apps, but perhaps it’s causing a false positive in their automated tests.

Okay, so I’ve shifted the displayMode line to outside setup. When testing on the simulator then the default Codea screen - with parameter and output space - no longer shows. If this gets rejected then I’ll ask for more clarification.

A bit of searching online does show that Apple are clamping down on app template systems. Do we know anything about how the impact of that on Codea?

Well, it would appear that it was the flash of the Codea console that was the issue as the second build (with displayMode out of setup) has passed beta review and is ready for testflight.

Anyone want to test? DM me your emails.

It’s a fairly simple app for designing Celtic Knots. I wrote it a few years ago, but thanks to a bit of enthusiasm from a friend I decided to polish it up for publication.

@John Maybe the runtime for export should default to displayMode(FULLSCREEN_NO_BUTTONS) as the console looks like it shouldn’t be accessible at all in an app.

Thanks to everyone for their suggestions, and particularly to @Mark for the correct diagnosis.