Library missing

Second attempt to publish the Mac version of my App, but it was rejected again due to the same error: 'Library missing'.

The library IS included with the build.

The extracted .app from .xcarchive runs without a problem on different machines, both M1 and Intel. So, I don't know what's wrong.

Can somebody please help me?

I can provide the complete .ips from Apple if needed.

{
  "code": 1,
  "flags": 518,
  "namespace": "DYLD",
  "indicator": "Library missing",
  "details": [ "(terminated at launch; ignore backtrace)" ],
  "reasons": [
    "Library not loaded: @rpath/TitaniumKit.framework/Versions/A/TitaniumKit",
    "Referenced from: <85BA8613-0157-3B28-99AF-E73F1E579B72> /Applications/TiDesigner.app/Contents/MacOS/TiDesigner",
    "Reason: tried: '/usr/lib/swift/TitaniumKit.framework/Versions/A/TitaniumKit' (no such file, not in dyld cache),
    '/System/Volumes/Preboot/Cryptexes/OS/usr/lib/swift/TitaniumKit.framework/Versions/A/TitaniumKit' (no such file),
    '/usr/lib/swift/TitaniumKit.framework/Versions/A/TitaniumKit' (no such file, not in dyld cache),
    '/System/Volumes/Preboot/Cryptexes/OS/usr/lib/swift/TitaniumKit.framework/Versions/A/TitaniumKit' (no such file),
    '/System/Library/Frameworks/TitaniumKit.framework/Versions/A/TitaniumKit' (no such file, not in dyld cache),
    (security policy does not allow @ path expansion)"
  ]
}

Replies

The extracted .app from .xcarchive runs without a problem on different machines

That’s a useful datapoint, but it’s not definitive because Xcode re-signs the app as part of the store upload process. A better option here is to use the Xcode organiser to export the app to a Mac App Store installer package (using Distribute App > App Store Connect > Export) and then unpack the installer to look at its contents.

I generally unpack an installer using Pacifist, but you can use Apple tools if you want. See Unpacking Apple Archives.

You may or may not be able to run the extracted app. See Don’t Run App Store Distribution-Signed Code for more on that. However, you can look at the app to make sure it’s structured correctly. Specifically:

  • Check that the TitaniumKit is present in Contents/Frameworks.

  • Check that it’s structured correctly. One common gotcha here is folks copying a framework in a way that doesn’t preserve symlinks.

  • Use otool to check that its library identifier (LC_ID_DYLIB) is set correctly.

  • Use otool against the app to make sure that it references the library correctly (LC_LOAD_DYLIB).

  • And check that there’s an rpath command (LC_RPATH) that points to your Contents/Frameworks directory.

I suspect it’s that last point that’s the problem here, because the error message you posted shows no indication that the dynamic linker checked that directory when looking for your framework.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

  • Thanks, Eskimo. I'll try to unpack the app and test it locally that way!

Add a Comment

This is what I get with:

otool -l /Users/cesar/Desktop/TiDesigner\ Installer/TiDesigner.app/Contents/MacOS/TiDesigner | grep -A2 LC_RPATH

Are they normal??

          cmd LC_RPATH
      cmdsize 32
         path /usr/lib/swift (offset 12)
--
          cmd LC_RPATH
      cmdsize 40
         path @loader_path/../Frameworks (offset 12)
--
          cmd LC_RPATH
      cmdsize 40
         path @executable_path/Frameworks (offset 12)
--
          cmd LC_RPATH
      cmdsize 32
         path /usr/lib/swift (offset 12)
--
          cmd LC_RPATH
      cmdsize 40
         path @loader_path/../Frameworks (offset 12)
--
          cmd LC_RPATH
      cmdsize 40
         path @executable_path/Frameworks (offset 12)

Are they normal?

No.

The best way to determine what’s normal is to create a new test project from the macOS > App template. When I do that, this is what I see:

% otool -l Test732675.app/Contents/MacOS/Test732675 | grep LC_RPATH -B 1 -A 2 
Load command 29
          cmd LC_RPATH
      cmdsize 48
         path @executable_path/../Frameworks (offset 12)

If I set the deployment target back to macOS 11.0 — where the Swift runtime isn’t in the OS — I see this:

% otool -l Test732675.app/Contents/MacOS/Test732675 | grep LC_RPATH -B 1 -A 2 
Load command 30
          cmd LC_RPATH
      cmdsize 32
         path /usr/lib/swift (offset 12)
Load command 31
          cmd LC_RPATH
      cmdsize 48
         path @executable_path/../Frameworks (offset 12)

That’s pretty much what I’d expect for a Mac app.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi!

Just in case this helps others having the same issue in Mac Catalyst:

I was having a very similar issue. The frameworks were there, and I followed the instructions above on the xcarchive app. The only thing missing was the LC_ID_DYLIB, which returned empty.

In the end, I had deleted the Hardened Routine capability (https://developer.apple.com/documentation/security/hardened_runtime) from my (initially multi-platform) target when I found out some of my code would only run under Mac Catalyst and deleted macOS support to include it in the target.

My frameworks were embedding and running fine on other platforms. It was only on Mac that the archived / TestFlight version was crashing and reporting missing frameworks with the following:

Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000

Termination Reason: Namespace DYLD, Code 1 Library missing Library not loaded: @rpath/[framework_name_deleted].framework/Versions/A/[framework_name_deleted] Referenced from: <[uuid_deleted]> /Applications/[app_name_deleted]/Contents/MacOS/[app_name_deleted] Reason: , (security policy does not allow @ path expansion) (terminated at launch; ignore backtrace)

Including the Hardened Routine back (with no exceptions in my case) made it run perfectly in TestFlight