“Layout” keyword and Apple app analysis

Illustration with connected people ,futuristic technology concept

Update: 2:42pm 11/13/11
Our new approach to working around the Apple scanning process is now available in all release branches on our continuous integration server. You may resubmit your applications using this build, as we believe this should address the issue – however, we are still in the process of testing this fix ourselves with a submitted app to verify that applications will no longer be flagged for “private API” usage.

Update 6:11pm 11/12/11:
We are aware that our first attempt at a fix did not succeed in addressing this issue. We have another attempt which we are going to test internally to see if it manages to avoid Apple’s ‘private API’ scanning. We apologize for this inconvenience, and it is most definitely our top priority to address this issue as soon as possible.

Original Post:
Recently, we have had some reports from the community about feedback from Apple that their recently submitted applications have contained the use of a private API, which is only identified as “layout”. While no Titanium applications make use of private APIs, we suspect that Apple has made changes to their application analysis tools which mistakenly flag this property in some Titanium applications.

To work around this flaw in Apple’s processing logic, we are making a new build available which avoids use of the “layout” keyword in Titanium’s own implementation logic. We are in the process of verifying this fix in the Apple App Store as we speak. To install and use this special build yourself, you can download and install it via the brief instructions below.

While in this instance the error is with Apple’s own processing logic, we want to make sure your app store submission process is as smooth as possible. If you have any additional questions or feedback on this issue, please contact me directly (kwhinnery at appcelerator dot com) and I will be happy to assist you.

To get the latest 1.7.x build, go here.



  1. I just submitted an app today that was built against 1.7.6.v20111110182257 (from the builds link above) and I still received a warning from Application Loader:

    “The app references non-public selectors in Payload/MyApp.app/MyApp: layout”

    I still continued the submission, so fingers crossed.

  2. Just encountered a app rejection with the reason that I was using a private api.

    What best to do? Resubmit with the new 1.7.6? Or appeal to the rejection? And how are we sure the 1.7.6 will not give the same result?


  3. Submitted an app that was previously rejected with this issue today after rebuilding it with this fix. There were no validation issues. It is now in review.

  4. It seems as though the hot fix isn’t working, according to the latest post on the forum. Hope the Appcelerator team will keep us posted on the latest developments – pretty nervy with a crucial app update in the pipeline.

  5. We’re aware that the last hotfix didn’t solve the problem, and we have another (possible) fix in the pipeline; pull request #684 on github. I’m trying to see if we can certify this fix internally before releasing to the public, meaning turnaround may be longer.

  6. Please publish asap an updated build with the 2nd fix in the continous build.

    My app got rejected with your latest fix 🙁

    Thx in advance.

  7. When does the Appcelerator Team expect to have a fix for this layout issue? I understand that they are working on a NEW fix. Anyway we could combine forces and maybe help out to fix it? Like many we have a critical update in the pipeline and we need this fixed asap … please let us know what’s going on

    Thank you

  8. We now have a new possible fix in the pipeline. This one avoids ALL mentions of layout in the code, whether as a string, setter, or name of a data structure. You may get this fix off of the continuous integration linked above by Kevin:


    The githashes for the builds containing this fix are:

    1_7_X (stable): r334fb360
    1_8_X (last known good Android): r188b5bb
    master (v8 preview): r29bf06da

    Follow his instructions above from the blog post to install the appropriate version for your development needs, and please keep reporting back to us if any apps are rejected with this latest fix… because they shouldn’t be.

  9. While uploading 8 hours ago I got the layout warning.. I was using the latest build!

    I am using two animated views overlapping each other in my app and when calling the animation I get the debug-error..

  10. Is this “bug” also affecting earlier releases of the SDK ? Im using 1.7.3, will this build also be rejected ?

  11. Hi Chris, I’m no expert but I’d say it would probably affect all versions of the SDK, due to what seems to be a change on the Apple side in the way they scan apps for possible API conflicts. It seems as though any references Titanium makes to ‘layout’ are flagging as possible conflicts and causing apps to be rejected.

    I believe the safest advice is to take the latest SDK, try that and hope Appcelerator’s latest fix has cured the problem.

    On another note, Stephen if you read this just a little concerned that the term ‘layout’ is still referred to in TiViewProxy.m (line 177) – could this still causes issues?

    Many thanks,

  12. seems that many other forbidden words are in the list. You will be probably thought on this but, have you considered use a code obfuscator for titainum api? I mean, obfuscate all the code.

  13. We need a full list of the restricted api names that appear in the titanium code – otherwise it’s all hit and miss in the short run. can anyone generate this?

    Time is short! We have a lot of unhappy clients who are questioning the use of titanium for future projects!

  14. @Matthew We definitely appreciate the urgency here – it’s our top priority internally to address this.

    Unfortunately, the only people who know what strings will trigger the scanner is Apple, and they have not shared that information with anyone. Also, to note, this is not a Titanium-specific problem – Objective-C developers all over the map are reporting similar problems with simple terms like “index” or “enable”.

  15. Hi Kevin, Thanks for the response. This is truely unbelievable. FYI – posted a tip to techcrunch about the “strings” search by apple. I suggest everybody get this out to the online press ASAP… The only way to solve this is to put pressure on apple to rescind the string search..

  16. An app that was previously rejected twice for this issue with other builds was just reviewed and accepted and is now processing for the App Store (all in about 10 minutes!).

  17. Hi
    I just submitted 2 new Titanium Apps to the AppStore and I got this “layout” warning. I used the official 1.7.3 sdk.
    Is Apple going to reject it? Should I repackage it with the latest nighty build and send it to Apple again?
    Thanks a lot

    • The latest CI build has what we believe should work around this issue, regardless of the warning during build. Also, recently generated apps seem to be making it through – our own Appcelerator-submitted app has not yet been approved with the latest build. We will update when it is.

  18. I just updated Titanium studio with sdk 1.7.5, I spent last 2 months of my life to make a big update for my app, and now, submitted to app store I received the message “The app references non-public selectors in payload…”!
    Probably my app would be rejected??
    It’s terrible..!

    • @stefano It appears Apple has relaxed these requirements around the “non-public” APIs. The reports of app rejections for this reason have stopped, and we have multiple reports now of apps being accepted. We are confirming this ourselves as we speak.

  19. Hi Kevin, thank you for your reply, I haven’t applied any fix to sdk because I noted this problem when I submitted my app with application loader.
    This could be a problem?

    Thank you

    • We’re seeing apps submitted with 1.7.5, regardless of warning messages, being accepted to the store now. Our working assumption is that the private API scanning has been relaxed, but we are still investigating.

  20. I also think that issue should have been communicated to all developers via email. Was this done, did I miss that email???

Comments are closed.