[MacRuby-devel] Appstore rules on symlinks Macruby
rob.ista at me.com
Mon Jun 4 06:08:42 PDT 2012
Hi, obviously filing a bug has a broken link now so ...
- Apple indeed wants the Version to be A (or B) so macruby_deploy has to be changed. All exactly like Apple wants it to.
- I personally didn't succeed in doing so, so i decided to leave that to the pro's and have built a "by-the book ready-to-go" MacRuby-framework including the Headers and all. Significant detail is that I removed all the .dylibs (I didn't have seen a malfunction for that thus far) including their symlinks and only have a MacRuby binary (a copy of the dylib) where it shoud be including a symlink on top-level because
- codesigning "materializes" all symlinks into real binaries. E.g. you'll end up with 3 fullsize binary dylibs in the /lib folder with an exploded app-size as a result
- that's why you shouldn''t codesign a xyz.framework itself but the real Version(s) ("A", "B" etc.) because it would "materialize" all symlinks it can find including the one pointing to the main binary
- codesigning .rb files is not necessary anymore, only the .rbo's and the bundle's
- so, i just deploy an app, remove the macruby framework which was built by macruby deploy, replace it with my "by-the-book ready-to-go" one, run my post-compile script which "hacks" the binaries again with the Version (it should work with Current as well i guess), remove the Header-stuff and codesigns everything in the right order (first the .rbo's etc., then the framework Version, then the app)
- and .... no errors or even warnings when uploading to the store. The app even works and is accepted :)
Personally i think it's more convenient to have that "ready-to-go"' framework in the nightly builds and copy it during deployment. Hacking a framework together is a bit fuzzy and lookes like everything is still in beta. Well, even if it is, i think we should avoid it :). May be it's then even possible to avoid having to hack the binaries as well and only codesign the details before uploading.
On 10 May, 2012,at 04:00 PM, macruby-devel-request at lists.macosforge.org wrote:
Send MacRuby-devel mailing list submissions to
macruby-devel at lists.macosforge.org
To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to
macruby-devel-request at lists.macosforge.org
You can reach the person managing the list at
macruby-devel-owner at lists.macosforge.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of MacRuby-devel digest..."
1. Re: Appstore rules on symlinks Macruby framework changed ?
Date: Wed, 09 May 2012 16:44:01 +0200
From: Rob Ista <rob.ista at me.com>
To: macruby-devel at lists.macosforge.org
Subject: Re: [MacRuby-devel] Appstore rules on symlinks Macruby
framework changed ?
Message-ID: <B1B2E2DD-95D9-44D3-81F1-2BFF161EAD7F at me.com>
Content-Type: text/plain; charset=windows-1252
Yes, i have seen that .. i will do some tests to see if i can get a working app with a symlink although a manual change did not succeed thus far .. either it cannot find macgems (if i hack the binary with "A") or it just crashes because it can not find "Current" through the simlink any more
and yes, it seems that apple is really stretching their rules to the limits .. i sensed some disturbance in the python community as well with similar issues the last few days ? the response from the review team was :
- - - - -
We have discovered one or more issues with your recent delivery for "SubtitleReSync". To process your delivery, the following issues must be corrected:
Malformed Framework - The framework bundle MacRuby (SubtitleReSync.app/Contents/Frameworks/MacRuby.framework) 'Versions' directory must contain a symbolic link 'Current' resolving to a specific version directory. Refer to the Anatomy of Framework Bundles for more information.
- - - - -
The funny thing is that i have another framework but didn't bother to create a "cute" one so i just dumped the .dylib into Frameworks. That seems to be allowed and ok :)
I will file a bug report as well
> macruby_deploy fiddles with the version symlinks on purpose. We changed it in the past for app store guidelines at some point; you should be able to see it in the history of macruby_deploy.
> It would be fastest to just revert that change and see if that fixes things. Though if Apple really wants the version to be A then we will need to do a bit more work.
> macruby_deploy is fairly straightforward, so it is easy to go through and find what needs to be changed.
> Sent from my iDevice
> On 2012-05-07, at 9:38, Joshua Ballanco <jballanc at gmail.com> wrote:
>> Hi Rob,
>> I haven't had time to look into it, but hopefully Apple is not looking to restrict versions within framework bundles to "A", "B", "C", etc. As for "Current" not being a symlink, that does seem like a bug. Would you mind filing it as such so that we don't loose track of it?
>> - Josh
>> On Saturday, May 5, 2012 at 8:27 PM, Rob Ista wrote:
>>> Hi all,
>>> it seems that the Appstore validation has sharpened its control (again) ? submitting an app now is rejected because the Macruby framework does not comply to the official Anatomy of Framework Bundles ? There should be a symbolic "Current" resolving to "A" ... in the Macruby Framework this is now a fixed "Current" .. does anyone have seen this before and is there a workaround for the time being ?
>>> Secondly, the code signing of the bundle contents is still a bit shaky although it seems to work on Lion .. on SL the .rb files create an "argument list too long" message (see below) .. commenting out the .rb files in macruby_deploy for codesigning makes the deploy come to a proper end but of course now the .rb are not signed. Daniel has done some great work on this already but are there any other ideas?
>>> rgrds, Rob
>>> /Users/robista/Library/Developer/Xcode/DerivedData/SubtitleReSyncBasic-ayrbtqtujxpvspgaanykiwlaojxy/ArchiveIntermediates/Deployment/BuildProductsPath/Release/SubtitleReSyncBasic.app/Contents/Frameworks/MacRuby.framework/Versions/Current/usr/lib/ruby/1.9.2/abbrev.rb: Argument list too long
MacRuby-devel mailing list
MacRuby-devel at lists.macosforge.org
End of MacRuby-devel Digest, Vol 51, Issue 14
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the MacRuby-devel