Xcode archive validation fails for Mac App Store submission with the error "Couldn't find platform family in Info.plist CFBundleSupportedPlatforms"

Hello


I'm uploading the first build of my app to the Mac App Store, but Xcode archive validation is failing just before upload with the following error:


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}


I've successfully built, tested, archived, validated, exported, and run several builds of this app using the Developer ID workflow (not the MAS workflow), so AFAIK there's nothing wrong with the application code itself. But something's breaking in the final stage of app validation - and there's not much documentation on why this is happening.


Some background:


  • This is a Swift Mac app that uses NSTask to call a third party *nix program (the kind that you would normally invoke on the command line).
  • The program binaries and dependencies are embedded in the app's Resources bundle for portability.
  • Some parts of the third party program - and its own dependencies - are native code compiled by the project authors (not me).
  • AbstractMemory.o is one such dependency. There are many more!
  • The third party program is NOT an Xcode framework - it's just a *nix utility, and totally unaware of Xcode. This makes most of the (very few) suggested fixes out there (like putting an Info.plist inside the program's folder) not applicable.
  • The corresponding app record is set up and ready to receive archive uploads in iTunes Connect, so there's probably nothing wrong there.
  • During archive validation, Xcode seems to recognise native code parts of the third party program and treats them in special ways: unlike, say, a README file (which it just passes through), in the archive validation dialog it lists all of these .o, .a, .bundle, and .dylib files just underneath the main application's binary. This may be contributing to the problem - I do not want Xcode to treat these things specially, I just want it to pass them through transparently into the .app product.


Build system:


  • Mac OS 10.11.6
  • Xcode 7.3.1
  • Mac OS SDK: *Probably* 10.11.3 but I don't know how to test for sure.
  • For what it's worth, NSFoundationVersionNumber currently resolves to 1259 on my system.


As a first port of call, I have tried putting CFBundleSupportedPlatforms into the minimal plist below and putting that file in various places in the third party program's folder, cleaned, and rebuilt, but it has not worked:


<plist version="1.0">
  <dict>
    <key>CFBundleSupportedPlatforms</key>
    <array>
      <string>MacOSX</string>
    </array>
  </dict>
</plist>


I have also posted this question over at StackOverflow, but haven't had any luck yet: http://stackoverflow.com/q/39193295/1475135


So... does anyone know why archive validation would fail in this way, and more importantly how to solve it?


Regards,


Chris K

Up vote post of themasterchef Down vote post of themasterchef
3.6k views
Posted by
themasterchef
Reply
Add a Comment

Accepted Reply

How I debugged this:


After following this mechanical process:


  1. Build archive.
  2. Validate archive.
  3. If Xcode complains about a file still in the archive, remove it on disk, and return to step 1.
  4. Archive successfully exported (though the app will not work).


I identified which parts of the Ruby utility + gems were problematic:


  • All .o files failed validation. When inspected with 'otool -l' they *did not* have the LC_VERSION_MIN_MACOSX load command.
  • *Some* *nix executables failed validation. When inspected with 'otool -l' they *did not* have the LC_VERSION_MIN_MACOSX load command.


And which parts were fine:


  • All .bundle, .dylib, and .so files passed validation. When inspected with 'otool -l' they all had the LC_VERSION_MIN_MACOSX load command in their Mach-O header.
  • All .a files passed validation. When inspected with 'otool -l' they *did not* have the LC_VERSION_MIN_MACOSX load command - but I guess Xcode is fine with that.
  • All non-object code e.g. plain text files, .rb files was passed through and Xcode did not take issue with it.


How I fixed this:


TLDR: The only surefire way to fix it is to recompile all the native code in the dependency project with the Xcode 7 build tools.

If you need Yosemite Deployment Target compatibility, you could risk it for a biscuit 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 native code plays nice with El Capitan things like SIP.

I was able to do this myself because the dependency project was open source. If you are using a proprietary dependency, I guess you'll have to ask the vendor to recompile it.


For more details, see my answer to my StackOverflow question: http://stackoverflow.com/a/39796560/1475135

Posted by
themasterchef
Up vote reply of themasterchef Down vote reply of themasterchef
Post marked as solved
Add a Comment

Replies

How I debugged this:


After following this mechanical process:


  1. Build archive.
  2. Validate archive.
  3. If Xcode complains about a file still in the archive, remove it on disk, and return to step 1.
  4. Archive successfully exported (though the app will not work).


I identified which parts of the Ruby utility + gems were problematic:


  • All .o files failed validation. When inspected with 'otool -l' they *did not* have the LC_VERSION_MIN_MACOSX load command.
  • *Some* *nix executables failed validation. When inspected with 'otool -l' they *did not* have the LC_VERSION_MIN_MACOSX load command.


And which parts were fine:


  • All .bundle, .dylib, and .so files passed validation. When inspected with 'otool -l' they all had the LC_VERSION_MIN_MACOSX load command in their Mach-O header.
  • All .a files passed validation. When inspected with 'otool -l' they *did not* have the LC_VERSION_MIN_MACOSX load command - but I guess Xcode is fine with that.
  • All non-object code e.g. plain text files, .rb files was passed through and Xcode did not take issue with it.


How I fixed this:


TLDR: The only surefire way to fix it is to recompile all the native code in the dependency project with the Xcode 7 build tools.

If you need Yosemite Deployment Target compatibility, you could risk it for a biscuit 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 native code plays nice with El Capitan things like SIP.

I was able to do this myself because the dependency project was open source. If you are using a proprietary dependency, I guess you'll have to ask the vendor to recompile it.


For more details, see my answer to my StackOverflow question: http://stackoverflow.com/a/39796560/1475135

Posted by
themasterchef
Up vote reply of themasterchef Down vote reply of themasterchef
Post marked as solved
Add a Comment

Hi.

Did you ever find a solution to this? Im having the same issue with third party helper executables.

Thanks

Neil

Posted by
Dopple
Up vote reply of Dopple Down vote reply of Dopple
Add a Comment

Hi Neil - I've updated my post above with my solution.

Posted by
themasterchef
Up vote reply of themasterchef Down vote reply of themasterchef
Add a Comment