Appcelerator Blog

The Leading Resource for All Things Mobile

“Layout” keyword and Apple app analysis

0 Flares 0 Flares ×
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. link
0 Flares Twitter 0 Facebook 0 Google+ 0 LinkedIn 0 Email -- 0 Flares ×


  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/ layout”

    I still continued the submission, so fingers crossed.

  2. ManyMinds

    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. Peter Wiley

    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. Chris Leyton

    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. Stephen Tramer

    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. Seb

    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. Alex Florea

    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 are planning a few new releases… I guess, I wait for the fix before we get a heart-attack on not being able to upload the app or being rejected.

  9. Stephen Tramer

    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.

  10. andersoe

    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..

  11. Chris Magnussen

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

  12. Chris Leyton

    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,

  13. Chris Magnussen

    If any reference to “layout” is flagged, there are 482 of them in the SDK.

  14. 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.

  15. Matthew Luchak

    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!

  16. Kevin Whinnery

    @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”.

  17. Matthew Luchak

    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..

  18. Peter Wiley

    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!).

  19. 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

  20. andersoe

    I’m still getting the layout warning.. Any new build on it’s way?


    • Kevin Whinnery

      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.

  21. stefano

    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..!

    • Kevin Whinnery

      @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.

  22. stefano

    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

    • Kevin Whinnery

      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.

  23. Seb S.

    App just approved with the r334fb360 build! Thxxxxxx :-)

  24. Tony Yustein

    The mentioned r334fb360 build is not available on the web site. Should we try the latest build instead? I just got an App rejected which was compiled with 1.7.5.

    • Kevin Whinnery

      The latest build from the 1.7.x branch should contain this fix

  25. Tony Yustein

    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.

Sign up for updates!

Become a mobile leader. Take the first step to scale mobile innovation throughout your enterprise.
Get in touch
computer and tablet showing Appcelerator software
Start free, grow from there.
0 Flares Twitter 0 Facebook 0 Google+ 0 LinkedIn 0 Email -- 0 Flares ×