Windows 11
Builder 3.58
iOS SDK 16.2
I have the issue, that one of our corporate clients uses a custom Enterprise AppStore to deploy the iOS Apps that we create for them. You upload the app to their portal and they unpack it, read the information from the info.plist and then pack/resign the whole thing with their enterprise provision.
The issue now is, that the apps built with the iOS package builder behave differently when being decompressed by the rubyzip libary in use than the XCode built apps.
We figured that out in detail - the current ipas from the builder don't show their full parent-folder structure, allthough when upacking with 7zip on windows, you get all the folders and the apps themselves are valid.
I assume, that there is some weird header/metadata issue - and we can solve it so far, by manually unpacking the built ipa and then repacking it with 7zip afterwards. Then the package behaves identical to the one built with XCode.
We assume, that the current packaging library in use by the iOS project builder has some setting, that makes it diverge from the original XCode archiving process.
It's not a deal breaker, as we do have a working work-around (which feels super silly) - but it could be looked into, to make the IPAs more identical to the ones that XCode creates.
To debug this:
install Ruby and import the package (called gems in Ruby) rubyzip (https://github.com/rubyzip/rubyzip) - and simply run this ruby short ruby-script:
require 'zip'
Zip::File.open('PATH_TO_IPA') do |zip_file|
# Handle entries one by one
zip_file.each do |entry|
puts entry
end
end
You will see, that an ipa created by the builder does not output any "Parent folder" structure (like /Payload/) but only the full path to the content files /Payload/appname.app/filename.xyz)