XCFramework support

[lapfelix]

Now that arm64 Macs exist, iOS binaries now need two arm64 slices (one for arm64 iOS devices, one for arm64 Macs running the iOS simulator) and a fat binary can't contain two slices of the same architecture. The current Cocoapods integration relies on .a fat binaries. Apple's solution to this problem is XCFramework, which separates the binaries for different platforms in different folder in a framework package.

Otherwise, we can't compile for the iOS simulator on the new Macs with arm64 processors: building for iOS Simulator, but linking in object file built for iOS, file '~/myrepo/Pods/agg/lib/ios/libagg.a' for architecture arm64

[igagis]

Thanks for report!

hm... I wonder how it worked before, when the binary was iOS arm64 and the simulator was running on Mac amd64, also different architectures...

I'll take a look at this XCFramework. I don't have Mac M1 to play with it though...

[lapfelix]

The simulator's architecture matches the host computer's architecture (because it's not an emulator). So before we would need an x86_64 slice in the binary for the iOS simulator, and it worked well because iOS devices didn't have x86 CPUs.

[igagis]

Actually, my current Pod archives do not contain amd64 architecture binaries. For example:

ivan@igagisw:~/prj/utki$ file ~/Downloads/lib/ios/libutki.a 
/home/ivan/Downloads/lib/ios/libutki.a: Mach-O universal binary with 2 architectures: [arm64:current ar archive] [armv7:current ar archive]

This fat binary has arm64 and armv7 archs. So, I suppose that on amd64 macs when running in simulator it actually simulates arm processor.

I'm still investigating how to resolve M1 problem.

[igagis]

@lapfelix I have updated the packages, now those contain xcframework instead of fat library. I haven't tested it though. Could you update your packages and try?

[lapfelix]

There seems to be an issue with papki, because the xcframework doesn't get added to my test xcodeproj so I get Undefined symbol papki::xxxxxx errors. However if I manually download the pre-built papki SVGFramework (from here) and drag it into Xcode it does work!

In our case though, we can't really use pre-built binaries because I realized yesterday that papki requires iOS 13 (and we still support iOS 12) because it uses new std::filesystem methods in a function. I fixed it in my fork, but maybe there's a way to make it compatible with iOS 12 by using preprocessor directives to check if the new APIs are available. I can open a story in the papki repo about this specifically (and I could probably fix it myself).

But this is going to be great for iOS 13+ support.

[igagis]

Thanks for testing! I found that in papki I forgot to change library to framework in the podspec. I will fix it shortly.

As for iOS 13... before sdt::filesystem I had implementation via dirent API. I think I could revert it back. I'll make a new papki release today/tomorrow.

[igagis]

It actually appeared easier than I thought. I reverted back dirent implementation for iOS and now it supports iOS 11.0. I don't know, what is the minimum iOS version it is reasonable to support nowadays. Maybe even earlier iOS version could be enough, but I set 11.0 for now, as it is minimum one which does not produce i386 binaries for simulator.

The new papki package of version 1.0.112 is released. Please update your packages and try. Let me know if it works or not. I'm aiming to provide smooth experience when using the libs, there should be no need to hack anything, just install the package.

[igagis]

Actually, I have updated iOS version to 9.0 in all packages

[igagis]

@lapfelix ping

[lapfelix]

Hi, thank you so much! It works very well. We don't use Cocoapods but I just set up an empty project with the svgren pod, grabbed the xcframeworks and the headers from it and now we have svgren binaries that work with iOS devices and the iOS simulator on the new Macs.