The application links against </usr/local/lib/HXRuntime Carbon Mach-O.dylib>, which is missing.
We believe that this is a false-positive in Apple's automated rejection tools. While 2011r1 will not have this 'problem', you can work around it via the following command line invocation:
[joe@Mac-Pro.local ~] install_name_tool -id '@executable_path/rbframework.dylib' '/My Application.app/Contents/MacOS/rbframework.dylib'
The rest of the post is a technical explanation of what is going on and can be skipped if you are not interested. Also, it describes the current implementation details and is in no way an API contract or something to rely on.
The bulk of the REALbasic framework is implemented in C++ and lives in the 'rbframework.dylib' file next to your executable. When you build an application, the REALbasic linker hardcodes the relative path to that dylib. This can be seen by running 'otool -L' on your binary:
[joe@Mac-Pro.local ~] otool -L '/My Application.app/Contents/MacOS/My Application' My Application: @executable_path/rbframework.dylib (compatibility version 0.0.0, current version 0.0.0) /System/Library/Frameworks/Carbon.framework/Carbon (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libSystem.dylib (compatibility version 0.0.0, current version 0.0.0)
Dylibs also have an 'install name', which is used solely by 'ld' (the linker that comes with Xcode). When you link a binary using Xcode, ld takes the install name of the library it's going to link in and then embeds it in your resulting binary. Since REALbasic does not use ld, we have simply left the install name for rbframework.dylib at its default. This can be seen by running 'otool -l' and searching for the install name's load command:
[joe@Mac-Pro.local ~] otool -l '/My Application.app/Contents/MacOS/rbframework.dylib' ... Load command 5 cmd LC_ID_DYLIB cmdsize 72 name /usr/local/lib/HXRuntime Carbon Mach-O.dylib (offset 24) time stamp 1 Wed Dec 31 19:00:01 1969 current version 1.0.0 compatibility version 1.0.0
Our guess is that Apple has an automated tool that is looking at the install name of rbframework.dylib and rejecting it because it does not exist. However, since the install name is unused by anything but ld64, it is a false positive and not something Apple should be looking at.
While a future version of REALbasic will contain an install name that does not trigger this false positive, a temporary solution is to manually change the install name via install_name_tool, as mentioned above.