There is one group that must be benefit from the Apple Rejection economy and that is therapists. I can tell you that being on the other end of Apple rejection process causes great angst, concern and stress. When dealing with stress, you attempt to understand it and face it head on as a way of containing it. In some ways, stress is the feeling of being out of control and typically mechanisms which help you gain control are ways in which you can control stress.

We have recently had a few apps built on Titanium get rejected by Apple. While App rejections are an everyday occurrence in the Apple Rejection economy, we’ve been under a lot of pressure in the past week because of two particularly troublesome rejections — the use of Unicode and the use of the C sprintf function. But let me focus on the most worrisome to us, the use of sprintf. Yep, that’s right. Good ‘ole sprintf. Before I explain, let me digress into how Titanium works as a primer.

Titanium takes your Javascript Titanium API code usage and builds what we call an inverse symbol dependency matrix. Simply put it allows us to resolve all the APIs being used into a set of native symbols (slightly different between platforms, but in iPhone this is a object file). These symbols boil down to compile code that only matches the code your application needs and only those dependencies that you’re using in your application. Once we do this, we generate a bunch of Objective-C code from your code, take those symbols and then shove them into GCC to have him produce the final native application — as if you could have hand written the Objective-C code yourself… But highly optimized. Got it?

So, we’ve had a generic piece of code – and I’ll paste the exact line below – in Titanium for almost 8 months now. Unchanged.

Yesterday afternoon, Apple notified us (through someone submitting an app) that the following two APIs were private and could not be used:


__strcpy_chk
__sprintf_chk


Hrm. Obvious that it’s related to sprintf and strcpy. Both built-in C APIs as part of the standard language. OK, fair enough but I wasn’t aware of us using that code anywhere in our code and certainly not in any third-party code we include. A quick grep of our source code didn’t reveal anything obvious. My first step was simply comment out all references of sprintf in our code – a total of about 10 locations. On rebuild, I verified that the symbol was no longer present with a simple nm -a command against the compile application. WTF? OK, fine. I uncommented the first usage of sprintf and recompiled. Symbols not present. Huh? OK, i’m just not doing something right. Let me try another… After the 6th uncomment, I hit the mark. The following line of code causes GCC to generate 2 the “private APIs”.

sprintf(temp, "%02X, a);

Yes, folks, that’s right. What seems to be different between this sprintf and the others are the usage of the X (hex) format specifier and the precision (02). It seems by looking at Apple’s own Darwin Source Code for this function that this piece of code (contained in Libc, BTW) simply is a bounds safety check. Also, let me reiterate, GCC itself generated the use of this symbol, not Titanium.

My therapist tells me to take a deep breath, relax, visualize the problem being resolved.

Wait! I’m not writing that code, they are. Hrm…

OK, so I’m going to give Apple the benefit of the doubt because I’m an Apple n00b and I really believe that they have a pretty tough job and that they’re trying to do their best to keep out bad and harmful code from the sea of thousands of submissions per week they’re receiving. I’m also assuming that this latest set is probably related to upgrades in their scanners related to the impending iPad release or it’s related to our usage of the latest 3.2 SDK. They’re simply just a little overzealous on trying to separate the wheat from the chaff. Unfortunately, we (and more importantly, you) are a little bit caught in the cross hairs. And, I apologize.

So, here’s what we’re trying to do to at least do our part in helping make this a little less stressful for you.

1/ We’ve opened a Radar issue with Apple (#7793724) on this specific issue to at least see if they can fix this specific issue.

2/ We’ve resolved the problem by simply not using sprintf in this case. We’ll likely remove all usages of sprintf in favor of the usage of NSString’s built-in format method just to be overly cautious.

3/ We’ve setup a new email alias (appsupport@appcelerator.com) for you to notify us as soon as you see anything like this or any other rejection in the future. Please email us ASAP with your rejection information from Apple so we can help understand the issue. This email is available to everyone – regardless of if you’re a community, premium or otherwise. We take these submissions seriously and we want to help you resolve these issues as fast as possible. This alias will go straight into my email as well as Nolan Wright (our beloved CTO and co-founder) and several others. If you’re a premium customer, you can also open a high-priority ticket, too.

While we take every attempt humanly possible to follow Apple’s Developer guidelines, issues like these are part of the Apple Rejection economy. We know it will get better as Apple continues to improve their process, their communication level and their speed around app submissions. In the meantime, we’re committed to helping you get through this process as painless as practically possible under the circumstances.