I have a Swift project which calls a command line utility using NSTask.
For portability, I have included that command line utility in the bundled resources of the app.
The utility is quite complex - it's a Ruby interpreted application, with a bunch of gems, some of which have native extensions. The gems are all installed with Bundler into a standard vendor/ directory within the utility.
I have successfully archived, validated, distributed, and run the app on a second Mac which does not have that CLI utility (or Xcode) installed through the Developer ID ('outside the Mac App Store') workflow several times.
However, the archive failed to validate for Mac App Store distribution with this error:
2016-08-28 15:26:41 +0000 [MT] Presenting: Error Domain=DVTFoundationNSBundleAdditionsErrorDomain Code=1 "Couldn't find platform family in Info.plist CFBundleSupportedPlatforms or Mach-O LC_VERSION_MIN for AbstractMemory.o" UserInfo={NSLocalizedDescription=Couldn't find platform family in Info.plist CFBundleSupportedPlatforms or Mach-O LC_VERSION_MIN for AbstractMemory.o}
So... why would app archive validation fail in the MAS workflow, but not the Developer ID workflow, with such an error?
Potentially interesting points:
iconv
, xmlcatalog
)AbstractMemory.o
)ffi_c.bundle
, nokogiri.bundle
)libcapi.dylib
, libcharset.dylib
)libcharset.a
)The dependency project had originally been compiled with a really old version of Xcode and OS X, so a number of Mach-O executables inside it did not have the LC_VERSION_MIN_MACOSX load command in their headers. Basically I had to find a way to squeeze that load command in.
The only surefire and clean way to do that is to recompile all the native code in the dependency project using the Xcode 7 build tools. If the dependency is open source you could do it yourself. If not you'll have to plead with your software vendor.
If you need Yosemite Deployment Target compatibility, you could risk it and use Xcode 7.1 GM on a Yosemite build box. But I recommend that you recompile the code with Xcode 7.1+ on an El Capitan build box, to ensure your binary dependency plays nice with El Capitan things like SIP.
In my case, the dependency project was open source, so I was able to:
otool -l [path to executable]
.I was able to set up multiple OS X build VMs without going mad by using Travis CI's Mac build fleet.
"Include symbols for debugging" had to be unticked for archive validation or export. This is because the symbolicator could not deal with the third party object code. I guess this is because it was built for release, and so the object code did not come with any accompanying debug symbols.
If you are not able to recompile the code I've heard rumours of dirty workarounds that can stuff Mach-O load commands into a pre-existing binary. This suffers from the following problems:
I cross-posted this question to the Apple Developer forums at https://forums.developer.apple.com/message/175427 to see if it would get answered any faster by a more specialist community. It wasn't, but you may find additional discussion of the problem through that link.