This is a known issue; as you surmised, iOS 13 and 14 have different arm64e ABIs which is perfectly valid since the ABI is currently unstable -- and so it might change in the future as well.

One potential solution that I've been thinking about is to allow users to specify multiple toolchains which can be used to build different slices of the MachO. It should be possible to lipo them together because the CPU subtype differs for different ABI versions, but in case that doesn't work then your suggestion of creating multiple packages might just be the best route.

thanks for your response.
I just tried lipo, hmmm looks like could not create unified arm64e ABI version binary by lipo.

$ lipo -create Sleipnizer.11.dylib xcode12_arm64e.dylib -output unified.dylib
fatal error: /Applications/Xcode_121.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo: Sleipnizer.11.dylib and xcode12_arm64e.dylib have the same architectures (arm64e) and can't be in the same fat output file

okey, this is not theos resolvable issue... correct?

iirc someone figured out that it might depend on the order in which you supply the slices so try reversing the order to see if that works. This issue should remain open since we'll need to add dual toolchain support to Theos in order to work around it.

Do "order" means lipo argument order?
both order of lipo command are failed in my machine.

$ lipo -create arm64e_xcode_11.dylib xcode12_arm64e.dylib -output unified.dylib
fatal error: /Applications/Xcode_121.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo: arm64e_xcode_11.dylib and xcode12_arm64e.dylib have the same architectures (arm64e) and can't be in the same fat output file

$ lipo -create xcode12_arm64e.dylib arm64e_xcode_11.dylib -output unified.dylib
fatal error: /Applications/Xcode_121.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo: xcode12_arm64e.dylib and arm64e_xcode_11.dylib have the same architectures (arm64e) and can't be in the same fat output file

Yeah that's what I meant. Try using Xcode 11's lipo?

Unfortunately, same error.

$ xcode-select -p
/Applications/Xcode.app/Contents/Developer

$ xcodebuild -version
Xcode 11.7
Build version 11E801a

$ lipo -create xcode12_arm64e.dylib arm64e_xcode_11.dylib -output unified.dylib
fatal error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo: xcode12_arm64e.dylib and arm64e_xcode_11.dylib have the same architectures (arm64e) and can't be in the same fat output file

$ lipo -create arm64e_xcode_11.dylib xcode12_arm64e.dylib -output unified.dylib
fatal error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo: arm64e_xcode_11.dylib and xcode12_arm64e.dylib have the same architectures (arm64e) and can't be in the same fat output file

I just found this thread; Matt's research seems promising.

Hmm, patched version of lipo is required to create multiple same arch slice having fat binary...?

the lipo'd dylib with two arm64e slices seems to work on 13.5 at least, we still need to test whether it works on 14

EDIT: seems to work on 14 too

great news!

if that solution is perfect, probably we should create drop-in replacement for patched lipo like dm.pl in the future.

not only that, but to be honest it would be nice if theos could automate the entire process because a lot of developers (effectively anyone that develops something that's not only hooking appstore apps) will have problems with this once a 14 jailbreak that supports arm64e devices drops. you would of course need to have both xcode 11 and 12 toolchains installed.

@opa334 that's the plan; it would ideally be possible to select different toolchains for different architectures.

I confirmed too. fat binary that created by patched lipo works well in

• arm64e A13, iOS 13.5
• arm64e A12, iOS 12.0.1
• arm64 A11, iOS 14.1

$ file .theos/obj/debug/DeleteCut.dylib
.theos/obj/debug/DeleteCut.dylib: Mach-O universal binary with 4 architectures: [arm_v7:Mach-O dynamically linked shared library arm_v7] [arm64:Mach-O 64-bit dynamically linked shared library arm64] [arm64e:Mach-O 64-bit dynamically linked shared library arm64e] [arm64e:Mach-O 64-bit dynamically linked shared library arm64e]
.theos/obj/debug/DeleteCut.dylib (for architecture armv7):	Mach-O dynamically linked shared library arm_v7
.theos/obj/debug/DeleteCut.dylib (for architecture arm64):	Mach-O 64-bit dynamically linked shared library arm64
.theos/obj/debug/DeleteCut.dylib (for architecture arm64e):	Mach-O 64-bit dynamically linked shared library arm64e
.theos/obj/debug/DeleteCut.dylib (for architecture arm64e):	Mach-O 64-bit dynamically linked shared library arm64e

$ file .theos/obj/debug/DeleteCutSettings.bundle/DeleteCutSettings
.theos/obj/debug/DeleteCutSettings.bundle/DeleteCutSettings: Mach-O universal binary with 4 architectures: [arm_v7:Mach-O dynamically linked shared library arm_v7] [arm64:Mach-O 64-bit dynamically linked shared library arm64] [arm64e:Mach-O 64-bit dynamically linked shared library arm64e] [arm64e:Mach-O 64-bit dynamically linked shared library arm64e]
.theos/obj/debug/DeleteCutSettings.bundle/DeleteCutSettings (for architecture armv7):	Mach-O dynamically linked shared library arm_v7
.theos/obj/debug/DeleteCutSettings.bundle/DeleteCutSettings (for architecture arm64):	Mach-O 64-bit dynamically linked shared library arm64
.theos/obj/debug/DeleteCutSettings.bundle/DeleteCutSettings (for architecture arm64e):	Mach-O 64-bit dynamically linked shared library arm64e
.theos/obj/debug/DeleteCutSettings.bundle/DeleteCutSettings (for architecture arm64e):	Mach-O 64-bit dynamically linked shared library arm64e

NOTE: lipo -info and otool will be same contains two of the same architecture error for that binary.

Xcode 11 is not openable from finder on M1 mac.

But it is useful to build for iOS12-13 arm64e binary in Rosetta mode.

Newly Substitute v2 saying iOS 14 arm64e support added.
So I investigate libsubstitute.dylib inside the package what architecture contains.

As a result, it only contains single arm64e slice, and caps 0x00 ABI version.
Is it really work in iOS 14 arm64e device...? @sbingner

libsubstitute.dylib (architecture arm64e):
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
 0xfeedfacf 16777228          2  0x00           6    18       1872 0x00100085

I figured out a potential way to do this via iOSOpenDev, and might be useful for you all to know how I approached the problem. That said, this is not tested on a real device but follows on from the work I did in the linked thread above. Consider it as "probably works with maybe minor adjustments"!

Pre-requisites:

• My patched lipo (https://www.dropbox.com/s/6h85hlc4sm14zeg/lipo?dl=0)
• Xcode 11 toolchain (from /.../Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain)
• x86 mac -> only because I haven't patched the arm64 slice of lipo

Steps:

1. Copy /.../Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain to /Library/Developer/Toolchains (directory likely needs to be created)
2. Rename the toolchain, to e.g. Xcode.arm64eLegacy.xctoolchain
3. Update the newly copied toolchain's ToolchainInfo.plist with the following format (its a binary plist so don't just copy/paste this):

{	
        Aliases = ["arm64e-legacy"];
	CFBundleIdentifier = "com.applex.dt.toolchain.Xcode.arm64e.legacy";
	CompatibilityVersion = 2;
	CompatibilityVersionDisplayString = "Xcode 8.0";
	DisplayName = "Xcode arm64e Legacy";
	ShortDisplayName = "Xcode arm64e Legacy";
}

Pay very close attention to the value of CFBundleIdentifier. This cannot include com.apple.dt as the prefix, and has to be modified for Xcode to recognise it.

4. Open Xcode 12. You should now see the newly added toolchain in the Xcode preferences next to simulators.

That now is Xcode 12 ready to build with the older toolchain for arm64e.

5. Copy my patched lipo to a safe place but preferably not on $PATH for now, e.g., I used /opt/iOSOpenDev/bin/

The following is iOSOpenDev specific, but you'll get the idea.

6. As the final step of build phases for a given target, add the following as a new Run Script:

if [ "${SKIP_LEGACY}" = "1" ];then
  exit 0;
fi


if [ "${CONFIGURATION}" != "Release" ];then
  exit 0;
fi

export SKIP_LEGACY=1

FINAL_PRODUCT="${BUILT_PRODUCTS_DIR}/${FULL_PRODUCT_NAME}"

xcodebuild -project "${PROJECT_FILE_PATH}" -target $TARGETNAME -toolchain "com.applex.dt.toolchain.Xcode.arm64e.legacy" VALID_ARCHS=arm64e SYMROOT="${SYMROOT}/arm64e-legacy" CONFIGURATION=$CONFIGURATION

echo "Merging ${SYMROOT}/arm64e-legacy/${CONFIGURATION}-${PLATFORM_NAME}/${FULL_PRODUCT_NAME} and ${FINAL_PRODUCT}"
"${iOSOpenDevPath}/bin/lipo" -create "${SYMROOT}/arm64e-legacy/${CONFIGURATION}-${PLATFORM_NAME}/${FULL_PRODUCT_NAME}" $FINAL_PRODUCT -output $FINAL_PRODUCT

This script will re-run compilation for the current target for Release configurations, using the older toolchain setup above. Then, once compilation completes it will automatically lipo together the generated arm64e slice with the existing fat archive created by Xcode's default toolchain.

After this, the output should then be a fat archive containing both the new and old arm64e formats, all handled automatically inside Xcode.

I'll be bundling this all up into an easy to use setup on my branch of iOSOpenDev, but I'm aware nobody except me uses that...!

EDIT:

During testing, I have found the following modifications are required for a successful build to occur (usually applied when patching Xcode via iOSOpenDev's install script).

In /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/SDKSettings.plist, update the following properties

AD_HOC_CODE_SIGNING_ALLOWED=YES
CODE_SIGNING_REQUIRED=NO
ENTITLEMENTS_REQUIRED=NO

Nice works with toolchain system!

Is it possible to replace toolchain that swift.org distributed one? (It is small download size than full Xcode and can be support Linux(Ubuntu))

@r-plus i think so? As long as the clang version they ship predates the change to the arm64e ABI, then it should all work in a similar way.

Last I checked, the toolchains on swift.org don't support arm64e compilation at all. It is possible to build a non-macOS toolchain with arm64e support though: Procursus does it here, although the Swift open source repo seems to not have support for the new (iOS 14) ABI yet.

uh, that's too bad.

I remembered some developers still supporting armv6 using custom theos to support multiple toolchain.
https://github.com/rpetrich/theos
https://github.com/rpetrich/AppList/blob/master/Makefile#L25-L37

Inspired by @opa334 's script, I implemented an experimental second toolchain support in my theos fork.

brendonjkding@873a2fa

Xcode 11 toolchain and plipo is also needed.

The only difference is to export SECOND_PREFIX in your makefile and make as usual. Theos will handle the rest for you.

I have checked the generated binary(Tweak with preferences bundle) using otool -l and tested the fat binary on my ipad mini 5 (A12). It seems works fine.

Hope it can be helpful and there will be an official support. :D

i think new variable to support multiple toolchain should receive array (colon separated string like TARGET) of additional toolchain path to support more future ABI changes.

for example

export ARCHS = arm64 arm64e arm64x
export NEW_VARIABLE_1 = arm64e:path_to_xcode_11_toolchain:path_to_future_toolchain
export NEW_VARIABLE_2 = arm64x:path_to_toolchain_1:path_to_toolchain_2

If Apple change the ABI again in the future, developers simply add :new_path_to_toolchain to trailing of variable to support it without update theos.
Specifying architecture as first argument to support future arm64x architecture if apple added.
But yes, separated incremented variables to define arch * toolchains matrix is not good design to detect definition from theos.

@kabiroberai do you have any plan?

@r-plus I've been considering something similar to your suggestion – except it'd probably be easier for Theos to deal with if we did it along the lines of PREFIXES_arm64e = /path/to/first /path/to/second. We might even want to utilise the (relatively obscure) schema feature so that the user could set per-toolchain variables, for example arm64e_v2.CFLAGS = -blah.

This'll definitely require at least some degree of re-architecting (potentially adding another level of Make recursion which sucks because that means more overhead) but it's a necessary evil.

Update: @kirb and I were able to come up with a solution that's relatively elegant. Feedback would be appreciated before it's merged – see #574.

0x80 ABI version of arm64e slice is not required to work in my tested tweaks (and preferencebundle too) and environement (iPhone 12 mini + iOS 14.1 + unc0ver)

hmm, unc0ver doing something specially for this?
CoolStar announced tweaks need 2nd arm64e slice https://twitter.com/CStar_OW/status/1359500321345527816, is it still need for chimera14?

second slice is only needed for binaries, not for dylibs (and binaries don't need an arm64e slice at all, arm64 works fine)

no, unc0ver is not doing anything special

Thanks for confirming @opa334.

So in that case we need to:

1. Add a warning to Theos when linking arm64e for deploy target <14.0 when clang and swift are too new to actually support the requested deploy target.
2. Remove arm64e as a default arch, only setting it for library or bundle targets, and for iphone target only.
3. Longer-term solution: Automatically download an appropriate toolchain (I think @kabiroberai has ideas here).

To clarify, my intent isn't to automatically download the appropriate toolchain but to present a warning that recommends switching to the right one. More specifically, I've been doing some experimentation and it turns out the OSS Swift 5.3 toolchains from https://swift.org/download contain clang/swiftc binaries which are capable of building for the iOS 13 arm64e ABI while being compatible with the iOS 14 SDK. I still need to do some more research but this may be our best bet for now.

The only other officially supported alternative (and the only official solution atm) on macOS is to download Xcode 11 alongside Xcode 12 and specify the former to Theos via xcode-select/DEVELOPER_DIR. I do not recommend ad-hoc solutions involving downloading a standalone copy of Xcode 11's XcodeDefault.xctoolchain because that toolchain is not designed to be used outside of Xcode 11.

I used the lipo on https://www.dropbox.com/s/6h85hlc4sm14zeg/lipo?dl=0. tested on macOS Monterey 12.0.1, Xcode 13.1, Xcode 11.5. When compiling the tweak, it failed:
==> Signing AbcTweak…
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate: fat file: /path/to/tweak/.theos/obj/debug/AbcTweak.dylib.47ba6b93.unsigned contains two of the same architecture (cputype (16777228) cpusubtype (2))
ldid/ldid.cpp(989): _assert(WEXITSTATUS(status) == 0); errno=0

I used the lipo on https://www.dropbox.com/s/6h85hlc4sm14zeg/lipo?dl=0. tested on macOS Monterey 12.0.1, Xcode 13.1, Xcode 11.5. When compiling the tweak, it failed: ==> Signing AbcTweak… error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate: fat file: /path/to/tweak/.theos/obj/debug/AbcTweak.dylib.47ba6b93.unsigned contains two of the same architecture (cputype (16777228) cpusubtype (2)) ldid/ldid.cpp(989): _assert(WEXITSTATUS(status) == 0); errno=0

using lipo is unnecessary, the arm64e slice compiled with Xcode 11 works on both <= 13 and >= 14

somebody suggested this on the Discord group a while ago, so I thought I would drop it here as a possible solution for any passerbys who don’t mind using python:
https://gist.github.com/dlevi309/0274792c28ebe65995fb9a851efd6335 just run this script on the target binary and it will switch between the iOS14 / iOS13 arm64e abi. Note: this does not work for tools, only dynamic libraries and frameworks. And don’t forget to resign the converted binary with ldid -S input.dylib

FYI: If you see this error message when use Xcode 11.7 on newly macOS (in my case, clean installed M1 mac Monterey 12.3.1)

$ swift -version
xcrun: error: unable to load libxcrun
 (dlopen(/Applications/Xcode_117.app/Contents/Developer/usr/lib/libxcrun.dylib, 0x0005): tried: '/Applications/Xcode_117.app/Contents/Developer/usr/lib/libxcrun.dylib' 
(code signature in <2E603D2B-AE50-3DEA-B024-54A66AA7B820> '/Applications/Xcode_117.app/Contents/Developer/usr/lib/libxcrun.dylib'
 not valid for use in process: library load disallowed by system policy)).

disabling SIP (System Integrity Protection) is the way to resolve.

Here's the POC change in Theos you may use for building compatible arm64e slice, with the latest version of Xcode.

# makefiles/targets/_common/darwin_tail.mk

_THEOS_TARGET_CFLAGS := -isysroot "$(ISYSROOT)" $(VERSIONFLAGS) $(_THEOS_TARGET_CC_CFLAGS)
+ ifeq ($(THEOS_CURRENT_ARCH),arm64e)
+ _THEOS_TARGET_CFLAGS += -fno-ptrauth-abi-version
+ endif
_THEOS_TARGET_CCFLAGS := $(_TARGET_LIBCPP_CCFLAGS)
_THEOS_TARGET_LDFLAGS := -isysroot "$(SYSROOT)" $(VERSIONFLAGS) $(LEGACYFLAGS) -multiply_defined suppress $(_TARGET_LIBCPP_LDFLAGS) $(_TARGET_LIBSWIFT_LDFLAGS)
+ ifeq ($(THEOS_CURRENT_ARCH),arm64e)
+ _THEOS_TARGET_LDFLAGS += -Xlinker -ios_version_min -Xlinker 6.0 # anything between 5.0 (inclusive) to 14.0 (exclusive)
+ endif

https://github.com/PoomSmart/theos/pull/1/files

When linking, you may see a warning like this which can be ignored:
ld: warning: object file (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/13.0.0/lib/darwin/libclang_rt.ios.a(outline_atomic_ldset2_1.S.o)) was built for newer iOS version (14.0) than being linked (11.0)

^ For future reference, it appears that using the flags above does NOT actually work: https://discord.com/channels/811490080278839327/811494949849661490/1162546530654355546

It was re-tested today:

• two SpringBoard tweaks loaded, but didn't do anything
• preference bundle crashed

Nonetheless if someone ever wants to test out the above flags with Xcode 15+ (and without modifying Theos itself), I'd suggest this way in Makefile (-ld_classic is a new thing that needs to be added there):

ifeq ($(THEOS_PACKAGE_SCHEME),rootless)
	ARCHS = arm64 arm64e
	TARGET = iphone:clang:latest:15.0
else
	ARCHS = armv7 armv7s arm64 arm64e
	TARGET = iphone:clang:latest:7.0
	arm64e_CFLAGS = -fno-ptrauth-abi-version
	arm64e_LDFLAGS = -ld_classic
endif

It seems the issue is not fixable, right? All to the different ABIs.

Yeah, but it's somewhat strange that Apple would completely break compiling for the old ABI in newer compiler. I'm not sure how much the switch -fno-ptrauth-abi-version actually does in terms of altering compilation (besides changing the header). I know a new thing is that without -ld_classic, the linker would complain with the following error:

ld: warning: ignoring file '/Users/p0358/ios/SilentScreenshots/.theos/obj/debug/arm64e/Tweak.x.78c3daa0.o': found architecture 'arm64e.old', required architecture 'arm64e'

and that using -ld_classic seems to be a common thing people apparently sometimes needed after updating to Xcode 15 across several projects. But why did this ld warning occur in the first place, where did it expect new ABI of arm64e? Perhaps it simply didn't take the flag that makes it use old one into account, idk.

But either way, I can't seem to find any code for this option in public sources, so I suppose it's not open sourced yet, and so we won't really know what it actually does until it is...?