AppStore submission for Ruby/Glimmer app on MacOS without Xcode

Background

I've repeatedly run into codesigning (and missing provisioning profile) issues for my Ruby/Glimmer app and am looking for ways to troubleshoot this outside of Xcode. The app structure is as follows:

PATHmanager.app
└── Contents
    ├── Info.plist
    ├── MacOS
    │   └── PATHmanager
    ├── PkgInfo
    ├── Resources
    │   └── AppIcon.icns
    ├── _CodeSignature
    │   └── CodeResources
    └── embedded.provisionprofile

Architecture

I have a Mac mini Apple M2 Pro with macOS Ventura 13.4. Xcode is not used directly, but the underlying command line tools (e.g., codesign, productbuild, pkgutil, xcrun) are run from a custom Ruby script.

xcodebuild -version
Xcode 14.3.1
Build version 14E300c

Questions

  1. Is the .app directory and file structure/naming sufficient? If not, can you point me in the direction of a minimal example that does not use Xcode?

  2. Info.plist is an XML text document (not binary), which I believe is in an acceptable format, but how do I lint this file and determine if it contains all of the necessary key/value pairs?

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>CFBundleDevelopmentRegion</key>
	<string>en</string>
	<key>CFBundleDisplayName</key>
	<string>PATH manager</string>
	<key>CFBundleExecutable</key>
	<string>PATHmanager</string>
	<key>CFBundleIconFile</key>
	<string>AppIcon.icns</string>
	<key>CFBundleIdentifier</key>
	<string>com.chipcastle.pathmanager</string>
	<key>CFBundleInfoDictionaryVersion</key>
	<string>6.0</string>
	<key>CFBundleName</key>
	<string>PATHmanager</string>
	<key>CFBundlePackageType</key>
	<string>APPL</string>
	<key>CFBundleShortVersionString</key>
	<string>1.15</string>
	<key>CFBundleSupportedPlatforms</key>
	<array>
		<string>MacOSX</string>
	</array>
	<key>CFBundleVersion</key>
	<string>1.15</string>
	<key>ITSAppUsesNonExemptEncryption</key>
	<false/>
	<key>LSApplicationCategoryType</key>
	<string>public.app-category.developer-tools</string>
	<key>LSMinimumSystemVersion</key>
	<string>12.0</string>
	<key>LSUIElement</key>
	<false/>
	<key>NSAppTransportSecurity</key>
	<dict>
		<key>NSAllowsArbitraryLoads</key>
		<true/>
	</dict>
	<key>NSHumanReadableCopyright</key>
	<string>© 2025 Chip Castle Dot Com, Inc.</string>
	<key>NSMainNibFile</key>
	<string>MainMenu</string>
	<key>NSPrincipalClass</key>
	<string>NSApplication</string>
</dict>
</plist>
  1. PATHmanager is a Mach-O 64-bit executable arm64 file created by using Tebako. Does this executable need to be codesigned, or is codesigning the .app folder sufficient?

  2. Does the .app directory need an entitlements file? Here's how I codesign it:

codesign --deep --force --verify --verbose=4 --options runtime --timestamp --sign 'Apple Distribution: Chip Castle Dot Com, Inc. (BXN9N7MNU3)' '/Users/chip/Desktop/distribution/PATHmanager.app'
  1. Does the PATHmanager binary need an entitlements file? Here's how I codesign it:
codesign --deep --force --verify --verbose=4 --options runtime --timestamp --entitlements '/Users/chip/Desktop/PATHmanager.entitlements' --sign 'Apple Distribution: Chip Castle Dot Com, Inc. (BXN9N7MNU3)' '/Users/chip/Desktop/distribution/PATHmanager.app/Contents/MacOS/PATHmanager'

  1. How can I verify what entitlements, if any, are required for codesigning the binary? The PATHmanager.entitlements file is an XML text file containing only the following:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.security.app-sandbox</key>
    <true/>
</dict>
</plist>
  1. Is the embedded.provisionprofile necessary, and if so, how do I know determine if it matches the certificate or entitlements that I'm using? Additionally, is it named and located properly?

  2. I submitted this to the AppStore several weeks ago and the reviewer reported that the executable would not load on their machine (even though it worked on mine.) Is it better for me to release via TestFlight for testing, and if so, do I need to following a separate process for codesigning (i.e., using different entitlements, profiles, certs, etc) when doing so?

I've been playing whack-a-mole with this for too long to mention and am hoping to nail down a better deployment flow, so any suggestions for improvement will be greatly appreciated. Thank you in advance.

Ok, I had to get some support from the tebako folks before I could reply. Here's the output of the codesign --verify -vvv "PATHmanager.app" command you suggested:

Extract pkg contents

/tmp
λ xar -xf ~/code/ruby/PATHmanager.pkg

Verify Bill of Materials

/tmp
λ lsbom com.chipcastle.pathmanager.pkg/Bom
.	0	0/0
./PATHmanager.app	40755	0/0
./PATHmanager.app/Contents	40755	0/0
./PATHmanager.app/Contents/Frameworks	40755	0/0
./PATHmanager.app/Contents/Frameworks/libui.dylib	100644	0/0	925632	3337342204
./PATHmanager.app/Contents/Info.plist	100644	0/0	1415	1981579098
./PATHmanager.app/Contents/MacOS	40755	0/0
./PATHmanager.app/Contents/MacOS/._PATHmanager	100755	0/0	0	0
./PATHmanager.app/Contents/MacOS/PATHmanager	100755	0/0	30036560	1901427662
./PATHmanager.app/Contents/PkgInfo	100644	0/0	8	742937289
./PATHmanager.app/Contents/Resources	40755	0/0
./PATHmanager.app/Contents/Resources/AppIcon.icns	100644	0/0	56310	2265036908
./PATHmanager.app/Contents/_CodeSignature	40755	0/0
./PATHmanager.app/Contents/_CodeSignature/CodeResources	100644	0/0	2822	2461487254

Check Payload

/tmp
λ cpio -i < com.chipcastle.pathmanager.pkg/Payload 
60595 blocks

/tmp
λ find com.chipcastle.pathmanager.pkg 
com.chipcastle.pathmanager.pkg
com.chipcastle.pathmanager.pkg/Bom
com.chipcastle.pathmanager.pkg/Payload
com.chipcastle.pathmanager.pkg/PackageInfo

Inspect .app folder contents

/tmp
λ find PATHmanager.app               
PATHmanager.app
PATHmanager.app/Contents
PATHmanager.app/Contents/_CodeSignature
PATHmanager.app/Contents/_CodeSignature/CodeResources
PATHmanager.app/Contents/MacOS
PATHmanager.app/Contents/MacOS/PATHmanager
PATHmanager.app/Contents/Resources
PATHmanager.app/Contents/Resources/AppIcon.icns
PATHmanager.app/Contents/Frameworks
PATHmanager.app/Contents/Frameworks/libui.dylib
PATHmanager.app/Contents/Info.plist
PATHmanager.app/Contents/PkgInfo

Verify with codesign

/tmp
λ codesign --verify -vvv "PATHmanager.app"        
--prepared:/private/tmp/PATHmanager.app/Contents/Frameworks/libui.dylib
--validated:/private/tmp/PATHmanager.app/Contents/Frameworks/libui.dylib
PATHmanager.app: valid on disk
PATHmanager.app: satisfies its Designated Requirement

Conclusion The only thing I see that strange is the ._PATHmanager file when inspecting the BOM. Any suggestions are appreciated. Thank you.

That ._PATHmanager file is an AppleDouble file holding extended attributes. I talk about that in Extended Attributes and Zip Archives.

The extended attributes might be benign, but they might indicate a more serious problem. What does the following print?

% xattr PATHmanager.app/Contents/MacOS/PATHmanager

Share and Enjoy

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

As an update, I was able to remove the AppleDouble file, remove the com.apple.macl extended attribute, and extract the pkg again. This time everything looks normal - no AppleDouble files, no extended attributes on any file in the app bundle, including the binary. Transporter reports the following even though the sandbox property is in the entitlements file:

Validation failed (409) App sandbox not enabled. The following executables must include the "com.apple.security.app-sandbox" entitlement with a Boolean value of true in the entitlements property list: [( "com.chipcastle.pathmanager.pkg/Payload/PATHmanager.app/Contents/MacOS/PATHmanager" )] Refer to App Sandbox page at https://developer.apple.com/documentation/security/app_sandbox for more information on sandboxing your app. (ID: 784e5cd5-38e6-4b93-be65-640ff87f6d66)

Hmmm, I think I’ve reached the limit of what I can debug without getting my hands on your installer package. Can you share a copy of that with me here?

If so, please upload it to a website of your choice and post the URL.

IMPORTANT Post the URL in the clear, as explained in tip 14 of Quinn’s Top Ten DevForums Tips.

If not, that’s cool. Lemme know in that case and I’ll suggest an alternative path.

Share and Enjoy

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

It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits.

Here's the link

Thanks. I downloaded that and extracted your app:

% xar -xf PATHmanager.pkg 
% cpio -i < com.chipcastle.pathmanager.pkg/Payload 
58111 blocks

I then dumped its code signature:

% codesign -d -vvv --entitlements - PATHmanager.app 
Executable=/Users/quinn/Desktop/test/PATHmanager.app/Contents/MacOS/PATHmanager
Identifier=com.chipcastle.pathmanager
Format=app bundle with Mach-O thin (arm64)
CodeDirectory v=20500 size=223078 flags=0x10000(runtime) hashes=6964+3 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha256=ed5d7d18f524cae6db2b57b2682ebfa61572510b
CandidateCDHashFull sha256=ed5d7d18f524cae6db2b57b2682ebfa61572510b56d6a26c037c8cc003f1f1d3
Hash choices=sha256
CMSDigest=ed5d7d18f524cae6db2b57b2682ebfa61572510b56d6a26c037c8cc003f1f1d3
CMSDigestType=2
CDHash=ed5d7d18f524cae6db2b57b2682ebfa61572510b
Signature size=9115
Authority=Apple Distribution: Chip Castle Dot Com, Inc. (BXN9N7MNU3)
Authority=Apple Worldwide Developer Relations Certification Authority
Authority=Apple Root CA
Timestamp=25 Mar 2025 at 23:34:55
Info.plist entries=19
TeamIdentifier=BXN9N7MNU3
Runtime Version=15.0.0
Sealed Resources version=2 rules=13 files=2
Internal requirements count=1 size=204
% 

I see no App Sandbox entitlement. Compare that to some other app that I downloaded from the App Store:

% codesign -d -vvv --entitlements - "/Applications/Hex Fiend.app"
…
Internal requirements count=1 size=228
[Dict]
	…
	[Key] com.apple.security.app-sandbox
	[Value]
		[Bool] true
	…
% 

I’m not sure what’s going on here but App Store Connect is App Store Correct in this case (-: Your app isn’t sandboxed )-:

Share and Enjoy

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

I was able to get it submitted to TestFlight, but am now getting a slightly different error for the dylib than before:

“libui.dylib” Not Opened

Apple could not verify “libui.dylib” is free of malware that may harm your Mac or compromise your privacy.

The dylib is located under Contents/Frameworks, so I'm not sure what else there is to be done.

Bundle contents

λ xar -xf ~/code/ruby/PATHmanager.pkg


/tmp
λ lsbom "com.chipcastle.pathmanager.pkg/Bom"
.	0	0/0
./PATHmanager.app	40755	0/0
./PATHmanager.app/Contents	40755	0/0
./PATHmanager.app/Contents/Frameworks	40755	0/0
./PATHmanager.app/Contents/Frameworks/libui.dylib	100644	0/0	925632	2654273729
./PATHmanager.app/Contents/Info.plist	100644	0/0	1415	196399421
./PATHmanager.app/Contents/MacOS	40755	0/0
./PATHmanager.app/Contents/MacOS/PATHmanager	100755	0/0	28765680	1121196294
./PATHmanager.app/Contents/PkgInfo	100644	0/0	8	742937289
./PATHmanager.app/Contents/Resources	40755	0/0
./PATHmanager.app/Contents/Resources/AppIcon.icns	100644	0/0	56310	2265036908
./PATHmanager.app/Contents/_CodeSignature	40755	0/0
./PATHmanager.app/Contents/_CodeSignature/CodeResources	100644	0/0	2969	2120637324
./PATHmanager.app/Contents/embedded.provisionprofile	100644	0/0	12377	748912970

/tmp
λ cpio -i < "com.chipcastle.pathmanager.pkg/Payload" 
58137 blocks

/tmp
λ find PATHmanager.app                            
PATHmanager.app
PATHmanager.app/Contents
PATHmanager.app/Contents/_CodeSignature
PATHmanager.app/Contents/_CodeSignature/CodeResources
PATHmanager.app/Contents/MacOS
PATHmanager.app/Contents/MacOS/PATHmanager
PATHmanager.app/Contents/Resources
PATHmanager.app/Contents/Resources/AppIcon.icns
PATHmanager.app/Contents/embedded.provisionprofile
PATHmanager.app/Contents/Frameworks
PATHmanager.app/Contents/Frameworks/libui.dylib
PATHmanager.app/Contents/Info.plist
PATHmanager.app/Contents/PkgInfo

/tmp
λ codesign --verify -vvv "PATHmanager.app"                
--prepared:/private/tmp/PATHmanager.app/Contents/Frameworks/libui.dylib
--validated:/private/tmp/PATHmanager.app/Contents/Frameworks/libui.dylib
PATHmanager.app: valid on disk
PATHmanager.app: satisfies its Designated Requirement

Codesigning output

λ ./appstore.rb
codesign --remove-signature '/Users/chip/code/ruby/distribution/PATHmanager.app/Contents/Frameworks/libui.dylib'
remove_signature returns: true
codesign --remove-signature '/Users/chip/code/ruby/distribution/PATHmanager.app'
remove_signature returns: true
Signing the .app...
codesign --preserve-metadata=entitlements --force --verify --verbose=4 --options runtime --timestamp --sign 'Apple Distribution: Chip Castle Dot Com, Inc. (BXN9N7MNU3)' '/Users/chip/code/ruby/distribution/PATHmanager.app/Contents/Frameworks/libui.dylib'
/Users/chip/code/ruby/distribution/PATHmanager.app/Contents/Frameworks/libui.dylib: signed Mach-O universal (x86_64 arm64) [libui]
sign_app returns: true
codesign --preserve-metadata=entitlements --force --verify --verbose=4 --options runtime --timestamp --entitlements '/Users/chip/code/ruby/distribution/PATHmanager.entitlements' --sign 'Apple Distribution: Chip Castle Dot Com, Inc. (BXN9N7MNU3)' '/Users/chip/code/ruby/distribution/PATHmanager.app'
/Users/chip/code/ruby/distribution/PATHmanager.app: signed app bundle with Mach-O thin (arm64) [com.chipcastle.pathmanager]
sign_app returns: true
Verifying signature for /Users/chip/code/ruby/distribution/PATHmanager.app/Contents/Frameworks/libui.dylib
codesign --verify --verbose=4 '/Users/chip/code/ruby/distribution/PATHmanager.app/Contents/Frameworks/libui.dylib'
/Users/chip/code/ruby/distribution/PATHmanager.app/Contents/Frameworks/libui.dylib: valid on disk
/Users/chip/code/ruby/distribution/PATHmanager.app/Contents/Frameworks/libui.dylib: satisfies its Designated Requirement
verify_app_signature for /Users/chip/code/ruby/distribution/PATHmanager.app/Contents/Frameworks/libui.dylib returns: true
Verifying signature for /Users/chip/code/ruby/distribution/PATHmanager.app
codesign --verify --verbose=4 '/Users/chip/code/ruby/distribution/PATHmanager.app'
--prepared:/Users/chip/code/ruby/distribution/PATHmanager.app/Contents/Frameworks/libui.dylib
--validated:/Users/chip/code/ruby/distribution/PATHmanager.app/Contents/Frameworks/libui.dylib
/Users/chip/code/ruby/distribution/PATHmanager.app: valid on disk
/Users/chip/code/ruby/distribution/PATHmanager.app: satisfies its Designated Requirement
verify_app_signature for /Users/chip/code/ruby/distribution/PATHmanager.app returns: true
Building the .pkg...
productbuild --sign '3rd Party Mac Developer Installer: Chip Castle Dot Com, Inc. (BXN9N7MNU3)' --identifier 'com.chipcastle.pathmanager' --version '1.23' --component '/Users/chip/code/ruby/distribution/PATHmanager.app' /Applications '/Users/chip/code/ruby/PATHmanager.pkg'
productbuild: Adding component at /Users/chip/code/ruby/distribution/PATHmanager.app
productbuild: Signing product with identity "3rd Party Mac Developer Installer: Chip Castle Dot Com, Inc. (BXN9N7MNU3)" from keychain /Users/chip/Library/Keychains/login.keychain-db
productbuild: Adding certificate "Apple Worldwide Developer Relations Certification Authority"
productbuild: Adding certificate "Apple Root CA"
productbuild: Wrote product to /Users/chip/code/ruby/PATHmanager.pkg
productbuild: Supported OS versions: [Min: 12.0, Before: None]
build_package returns: true
Verifying signature for /Users/chip/code/ruby/distribution/PATHmanager.app/Contents/Frameworks/libui.dylib
codesign --verify --verbose=4 '/Users/chip/code/ruby/distribution/PATHmanager.app/Contents/Frameworks/libui.dylib'
/Users/chip/code/ruby/distribution/PATHmanager.app/Contents/Frameworks/libui.dylib: valid on disk
/Users/chip/code/ruby/distribution/PATHmanager.app/Contents/Frameworks/libui.dylib: satisfies its Designated Requirement
verify_app_signature for /Users/chip/code/ruby/distribution/PATHmanager.app/Contents/Frameworks/libui.dylib returns: true
Verifying signature for /Users/chip/code/ruby/distribution/PATHmanager.app
codesign --verify --verbose=4 '/Users/chip/code/ruby/distribution/PATHmanager.app'
--prepared:/Users/chip/code/ruby/distribution/PATHmanager.app/Contents/Frameworks/libui.dylib
--validated:/Users/chip/code/ruby/distribution/PATHmanager.app/Contents/Frameworks/libui.dylib
/Users/chip/code/ruby/distribution/PATHmanager.app: valid on disk
/Users/chip/code/ruby/distribution/PATHmanager.app: satisfies its Designated Requirement
verify_app_signature for /Users/chip/code/ruby/distribution/PATHmanager.app returns: true

Any ideas? Thanks in advance.

I was able to get it submitted to TestFlight, but am now getting a slightly different error for the dylib than before:

So, you’re seeing this when launching the app that you installed using TestFlight?

If so, reproduce the problem and then dump the signature of your app and its embedded dynamic library. So, this:

% codesign -d -vvv /Applications/PATHmanager.app

and this:

% codesign -d -vvv /Applications/PATHmanager.app/Contents/Frameworks/libui.dylib

They should be the same, that is, both signed by Apple Mac OS Application Signing. Is that what you see?

Share and Enjoy

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

Yes, sorry that I wasn't clear - The error did occur when attempting to open the app with TestFlight (the dialog box opened twice with the same message, BTW.) Plus, PATHmanager.app is neither installed under /Applications, nor ~/Applications. If there's something else I can do to get it installed, I'm all ears. :-)

I'll post the output of your suggested commands from the extracted .pkg file that was uploaded using Transporter (hopefully that helps?):

Signature dump for app bundle

/tmp
λ codesign -d -vvv "PATHmanager.app/"                               
Executable=/private/tmp/PATHmanager.app/Contents/MacOS/PATHmanager
Identifier=com.chipcastle.pathmanager
Format=app bundle with Mach-O thin (arm64)
CodeDirectory v=20500 size=223206 flags=0x10000(runtime) hashes=6964+7 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha256=a7e912f449ef085b27467d282bfeca980b8e4d9c
CandidateCDHashFull sha256=a7e912f449ef085b27467d282bfeca980b8e4d9c9063d3b31bb34aaa15383e7d
Hash choices=sha256
CMSDigest=a7e912f449ef085b27467d282bfeca980b8e4d9c9063d3b31bb34aaa15383e7d
CMSDigestType=2
CDHash=a7e912f449ef085b27467d282bfeca980b8e4d9c
Signature size=9116
Authority=Apple Distribution: Chip Castle Dot Com, Inc. (BXN9N7MNU3)
Authority=Apple Worldwide Developer Relations Certification Authority
Authority=Apple Root CA
Timestamp=Mar 27, 2025 at 1:01:31 PM
Info.plist entries=19
TeamIdentifier=BXN9N7MNU3
Runtime Version=15.0.0
Sealed Resources version=2 rules=13 files=3
Internal requirements count=1 size=204

Since that doesn't tell me much, I'll add this as well:

λ codesign -d -r- "PATHmanager.app"                 
Executable=/private/tmp/PATHmanager.app/Contents/MacOS/PATHmanager
designated => identifier "com.chipcastle.pathmanager" and anchor apple generic and certificate leaf[subject.CN] = "Apple Distribution: Chip Castle Dot Com, Inc. (BXN9N7MNU3)" and certificate 1[field.1.2.840.113635.100.6.2.1] /* exists */

Signature app for dylib

λ codesign -d -vvv "PATHmanager.app/Contents/Frameworks/libui.dylib" 
Executable=/private/tmp/PATHmanager.app/Contents/Frameworks/libui.dylib
Identifier=libui
Format=Mach-O universal (x86_64 arm64)
CodeDirectory v=20500 size=3281 flags=0x10000(runtime) hashes=97+2 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha1=6f0f3b4eefb0e542619665c4c6396f84b765a92f
CandidateCDHashFull sha1=6f0f3b4eefb0e542619665c4c6396f84b765a92f
CandidateCDHash sha256=51b0d7e81f542de2b8c8a8d091548bfd4b1091e5
CandidateCDHashFull sha256=51b0d7e81f542de2b8c8a8d091548bfd4b1091e5ce8be2b38188f806bed13dc6
Hash choices=sha1,sha256
CMSDigest=705e70b2c2bda6cefedab9ccb490452f2ea83ce07d9ed5e0285c74cd6eedb151
CMSDigestType=2
CDHash=51b0d7e81f542de2b8c8a8d091548bfd4b1091e5
Signature size=9197
Authority=Apple Distribution: Chip Castle Dot Com, Inc. (BXN9N7MNU3)
Authority=Apple Worldwide Developer Relations Certification Authority
Authority=Apple Root CA
Timestamp=Mar 27, 2025 at 1:01:31 PM
Info.plist=not bound
TeamIdentifier=BXN9N7MNU3
Runtime Version=12.1.0
Sealed Resources=none
Internal requirements count=1 size=184

And also:

λ codesign -d -r- "PATHmanager.app/Contents/Frameworks/libui.dylib"
Executable=/private/tmp/PATHmanager.app/Contents/Frameworks/libui.dylib
designated => identifier libui and anchor apple generic and certificate leaf[subject.CN] = "Apple Distribution: Chip Castle Dot Com, Inc. (BXN9N7MNU3)" and certificate 1[field.1.2.840.113635.100.6.2.1] /* exists */

Thanks again.

So, lemme see if I understand you correctly here. You’re getting this “libui.dylib” Not Opened error when you try to install the app using the TestFlight? So it’s not from the app itself? And the error prevents TestFlight from actually installing the app in /Applications?

Share and Enjoy

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

Yes, that's correct. That error only only occurs when installing via TestFlight and pops up twice. The app is never installed under /Applications.

To be clear, before codesigning, the app runs fine on my system (always has).

As a further test, if I extract the pkg file that I uploaded via Transporter, which is subsequently available via TestFlight, I get this:


/tmp
λ xar -xf ~/code/ruby/PATHmanager.pkg                               

/tmp
λ ll
total 8
drwxrwxrwt  7 root  wheel   224 Mar 31 09:23 .
drwxr-xr-x  6 root  wheel   192 Mar 20 09:49 ..
-rw-r--r--  1 chip  staff  1217 Mar 31 09:23 Distribution
drwx------  3 chip  wheel    96 Mar 20 09:50 com.apple.launchd.AUOVCHr68r
drwx------  5 chip  staff   160 Dec 31  1969 com.chipcastle.pathmanager.pkg
srwxr-xr-x  1 chip  wheel     0 Mar 20 09:50 mykitty-1525
drwxr-xr-x  2 root  wheel    64 Mar 30 15:31 powerlog

/tmp
λ cpio -i < "com.chipcastle.pathmanager.pkg/Payload"
58137 blocks

/tmp
λ ll
total 8
drwxrwxrwt  8 root  wheel   256 Mar 31 09:23 .
drwxr-xr-x  6 root  wheel   192 Mar 20 09:49 ..
-rw-r--r--  1 chip  staff  1217 Mar 31 09:23 Distribution
drwxr-xr-x  3 chip  wheel    96 Mar 31 09:23 PATHmanager.app
drwx------  3 chip  wheel    96 Mar 20 09:50 com.apple.launchd.AUOVCHr68r
drwx------  5 chip  staff   160 Dec 31  1969 com.chipcastle.pathmanager.pkg
srwxr-xr-x  1 chip  wheel     0 Mar 20 09:50 mykitty-1525
drwxr-xr-x  2 root  wheel    64 Mar 30 15:31 powerlog

/tmp
λ open PATHmanager.app
The application cannot be opened for an unexpected reason, error=Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0x600003c9c0f0 {Error Domain=NSPOSIXErrorDomain Code=153 "Unknown error: 153" UserInfo={NSLocalizedDescription=Launchd job spawn failed}}}
if I extract the pkg file that I uploaded via Transporter … I get this:

Just FYI, you shouldn’t expect to be able to run the code from the package you submit to the App Store. See Don’t Run App Store Distribution-Signed Code for an explanation as to why.

Yes, that's correct. That error only only occurs when installing via TestFlight and pops up twice.

Weird. You should definitely file a bug about that. Something should be giving you a more actionable error here, probably on the App Store ingestion side.

Make sure to include a sysdiagnose log taken shortly after reproducing the problem.

Once your done, post your bug number here. I then take another look at this.

Share and Enjoy

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

Thanks for the tips! I tried sysdiagnose in various incantations, but received no output. Here's a sample:

sudo sysdiagnose -H -v 30371

The 30371 is the pid for TestFlight on my system at the time. I'm new to sysdiagnose, so I could've easily used it improperly.

I also inspected the contents of /private/var/tmp, which had on 2 directories, one of them being empty. The other only contained a binary file at /private/var/tmp/SoftwareUpdateCore/EventReporterPersistedState/SUCoreEventReporterState.state, but I'm assuming this is not related.

At any rate, I clicked on the Send Feedback button from within TestFlight and provided a screenshot along with a description in case that helps. I'll also attach the screenshot here so you can see what I mean. Thanks again.

I tried sysdiagnose in various incantations, but received no output.

The -H option tells sysdiagnose to print its output path and then exit )-:

You don’t need to do anything fancy here. Just run sysdiagnose with no options and it’ll lead you through the process:

% sudo sysdiagnose

If you run it from Terminal, it ends by bringing Finder to the front with the output file selected.

For more detailed instructions, see Sysdiagnose for macOS on our Bug Reporting > Profiles and Logs page. For lots of general advice on filing bugs, see Bug Reporting: How and Why?.

Share and Enjoy

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

Thank you for the documentation.

Let's see if I got the steps straight...

I launched TestFlight, then from the Terminal I typed sudo sysdiagnose, clicking Enter for it to start processing. I then clicked Open from TestFlight and clicked Done on both error dialogs. Per the sysdiagnose instructions, I clicked Ctrl-\ within the Terminal to allow it to finish processing. Per the documentation you provided, I waited more than 10 minutes. At that point, neither did sysdiagnose bring the Finder to the front, nor did it create any files under it's directory.

Here's verification:

λ sudo sysdiagnose -H
Password:
Sysdiagnoses can be found at '/private/var/tmp'

~
λ ls -alR /private/var/tmp
total 0
drwxrwxrwt   2 root  wheel    64 Apr  2 21:17 .
drwxr-xr-x  36 root  wheel  1152 Mar 20 09:49 ..

I have yet to hear back from support regarding my bug report, so I'll wait. Thanks again.

Nope, sorry, you’re in the weeds here. Note this line in the sysdiagnose output:

% sudo sysdiagnose
…
Press 'Enter' to continue. Ctrl+\ to cancel.

When it says cancel is really means it. Pressing ^\ will cancel the sysdiagnose log generation process completely. You need to press the Return key [1] to start the operation and then wait for it to run. I’ll show progress like this:

Progress:
[||||___________________________________05%____________________________________]

Share and Enjoy

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

[1] Enter actually works too, but many Macs don’t have an Enter key (instead you press fn-Return to get Enter).

(Smacks head) Ha! Ok, I moved too fast on that one. Thanks for clarification.

I extracted the resulting tar.gz file and inspected quite a few files, but I'm kinda flying blind here

TestFlight feedback allows for attaching screenshots, but not other files. The archive is too large to attach here, so what would be of interest?

Thanks.

Here's the file listing in case you see where I should focus. Thanks.

I recommend that you file a bug using Feedback Assistant. For more on that process, see Bug Reporting: How and Why?. If you file a bug in that way, you’ll be able to attach the sysdiagnose log you just recorded.

Once you’re done, post your bug number and I’ll take a look.

Here's the file listing in case you see where I should focus.

Generally, you want to look in the system log snapshot, that is, system_logs.logarchive. However, that’s huge and quite hard to navigate if you don’t know what you’re looking for. I have some general hints and tips in the Explore the System Log section at the end of Resolving Trusted Execution Problems.

Share and Enjoy

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

Bug number: FB17118773

I tried exporting from Console any Process matching TestFlight to no avail. I didn't see anything of interest there, though. Thanks.

Actually, I just found this within the Console output:

Library Validation failed: Rejecting '/Users/chip/Library/Containers/com.chipcastle.pathmanager/Data/tmp/tebako-runtime-20250404-48697-v1sra5/libui.dylib' (Team ID: none, platform: no) for process 'PATHmanager(48697)' (Team ID: BXN9N7MNU3, platform: no), reason: mapping process and mapped file (non-platform) have different Team IDs

This is strange, because I'm using the same Team ID in the cert when codesigning the libui.dylib and the app bundle.

Additionally, I'm unclear on why the dylib would be located under /Users/chip/Library/Containers/com.chipcastle.pathmanager/Data/tmp/tebako-runtime-20250404-48697-v1sra5/libui.dylib, because not only is that not where I initially built the binary, it's not where I copied it for codesigning.

Bug number: FB17118773

Thanks. I’m in the process of getting access to that but I wanted to respond to your other points immediately.

I'm unclear on why the dylib would be located under …/tmp/tebako-runtime-20250404-48697-v1sra5/libui.dylib

Well, I’m pretty sure that TestFlight hasn’t copied it to your temporary directory (-:

I suspect that you have two copies of this library:

  • One in Contents/Frameworks, where it needs to be for App Store distribution to work.

  • Another embedded with your app via your third-party tooling.

When you run the app it’s extracting the embedded copy of the library to your temporary directory and something ends up trying to load it from there.

If you run a development-signed version of your app, do you see this library get loaded? One option here is to run the app and then force it to crash by sending it a SIGABRT from Terminal:

% kill -ABRT YourAppProcessID

The crash report will include a Binary Images section that lists all the libraries it loaded.

Share and Enjoy

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

Thank you for the tips on creating the crash report. Very helpful, and yes, libui.dylib does show up on lines 128 and 270-271 of attached report. However, I'm unclear on next steps. Thanks again.

To recap, my Ruby files for the app are located under ./app, with the gems being "vendored". This library is located at ./app/vendor/bundle/ruby/3.3.0/gems/libui-0.1.2-arm64-darwin/vendor/libui.dylib.

I'm curious if I should codesign the libui.dylib before building the binary with Tebako?

If so, would I still need to codesign the Contents/Frameworks files under the app bundle? (I'm assuming yes on this latter point.)

Thanks in advance for your suggestions.

It’s clear that your third-party tooling is still sequestering the library somewhere, then unpacking the library to a temporary directory, and then trying to load that library. This technique won’t work for App Store apps.

Actually, it’s worse than that, it can’t be made to work for App Store apps [1]. You can’t get around this by signing your code prior to the sequester because the App Store needs to resign it.

The only solution is:

  • In your third-party tooling, disable the mechanism that sequesters and expands this library.

  • Instead, have it load the library from Contents/Frameworks.

  • Build your app with your third-party tool.

  • Put the library in Contents/Frameworks.

  • Sign the library for distribution.

  • Then sign the rest of the app.

Regarding the first two points, I can only provide general advice on that front. This sequestering is done by your third-party tooling and you’ll need to ask them how to disable it.

My general advice relates to how your library is identified: I recommend you use an rpath-relative install name, as explained in Dynamic Library Standard Setup for Apps.

Share and Enjoy

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

[1] You can make this work for directly distributed apps, although it requires some faffing around.

AppStore submission for Ruby/Glimmer app on MacOS without Xcode
 
 
Q