Adobe Air iOS Apps signed with "a relatively old structure"

so let's quote them

We also cannot sign an app that does not have enough space to store the newly signed structure. Adobe AIR iOS app is an example of this. It is signed with a relatively old structure and does not leave any space to store an updated signature structure. Unfortunately, at this moment, we need to fail the wrap process for these apps.

it's kind of vague ... imho either they got it wrong or did not try hard enough

under macOS (but also otherOS) wether you sign desktop app or mobile app

you have all the tools within Adobe AIR toolchain (ADT) to sign, resign, migrate signatures, etc.

see Signing AIR applications

the doc is pretty extensive and the ADT tool reuse what is on the system: keychain, java keystores, etc.

what people could call "industry standards"

"old structure" may refer to something like that: Technical Q&A QA1940

eg.

... a security hardening change that was introduced with iOS 10, macOS Sierra, watchOS 3, and tvOS 10. Code signing no longer allows any file in an app bundle to have an extended attribute containing a resource fork or Finder info

so yeah if you use codesign to sign a desktop AIR app, you will get the error

"resource fork, Finder information, or similar detritus not allowed."

because when ADT sign the AIR app it add some ressources into the Mach-O
eg.

$ xattr -lr bin-deploy/foobar.app

you can see

bin-deploy/foobar.app/Contents/Info.plist: com.apple.FinderInfo: 00000000  00 00 00 00 00 00 00 00 00 00 FF FF FF FF 00 00  |................| 00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................| 00000020 bin-deploy/foobar.app/Contents/Info.plist: com.apple.quarantine: 0081;55dd2ab1;Google\x20Chrome.app;8414EC98-9FF9-463F-ACD5-305B18828E7A bin-deploy/foobar.app/Contents/MacOS: com.apple.FinderInfo: 00000000  00 00 00 00 00 00 00 00 00 00 FF FF FF FF 00 00  |................| 00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................| 00000020 bin-deploy/foobar.app/Contents/MacOS: com.apple.quarantine: 0081;55dd2ab1;Google\x20Chrome.app;8414EC98-9FF9-463F-ACD5-305B18828E7A bin-deploy/foobar.app/Contents/PkgInfo: com.apple.FinderInfo: 00000000  00 00 00 00 00 00 00 00 00 00 FF FF FF FF 00 00  |................| 00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................| 00000020 bin-deploy/foobar.app/Contents/PkgInfo: com.apple.quarantine: 0081;55dd2ab1;Google\x20Chrome.app;8414EC98-9FF9-463F-ACD5-305B18828E7A bin-deploy/foobar.app/Contents: com.apple.FinderInfo: 00000000  00 00 00 00 00 00 00 00 00 00 FF FF FF FF 00 00  |................| 00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................| 00000020

in short, it create what is called a resource fork and new rules in macOS now quarantine those
(see: macOS Code Signing In Depth "Moving Away From Custom Resource Rules")

but nothing that can not be updated with a

$ xattr -cr bin-deploy/foobar.app

which fix the problem.

Now specifically for iOS, Adobe AIR apps are cross-compiled to native binaries

(almost the same as if you would compile Obj-C code)
so I really don't see what kind of problems Citrix encountered there

the part "does not leave any space to store an updated signature structure" is kind of false
you can take an IPA generated by ADT, "unzip" it and change "things" (eg. update/change certificates) like any other IPA

Really, among all the targets Adobe AIR can publish to, the iOS one is the exception that is like native

my guess is that Citrix overlooked something, better ask them the details about their vague comments.