Hello

The Swift code is typically in the Facebook SDK source code, and you encounter that when you use CocoaPods to layout the Facebook SDK source code and compile it altogether with your project. But there's a better way to do it where you don't encounter this problem.

If you use the pre-compiled Facebook frameworks (the release labeled "static" or "dynamic") you don't need to compile that Swift code yourself as it's already been compiled into the Facebook framework, all you need to do is to supply the missing frameworks your project needs to the linker through the "Add extra framework" buttons (and of course, make the appropriate Info.plist changes as documented by Facebook).

There are a couple threads on this forum that illustrate how to link with pre-compiled frameworks. The process is similar for whichever SDK your project uses (Facebook, Google, etc).

Let me know if you need more help.

Hello

Well, I wasn't yet aware that there could be Swift files in a Xcode project that the Unity editor generates itself, so that could be a first timer.

Could you please send me your project (or a stripped version of it that still demonstrates the problem) so that I see what to do ? Confidentiality is guaranteed.

You can e.g. upload it on an online storage space and send the link to my email address (pm at this domain dot com).

If your project is buildable I'll tell you how to do it, and if it's not I'll fix what's needed so that it is.

Thanks in advance

:: @Pierre-Marie Baty added on 12 Sep ’22 · 17:14

*edit* IMPORTANT: make sure it's a fresh, untouched Xcode project just created by the Unity editor (i.e. delete the Xcode project directory thoroughly, and have Unity create it again).

Unfortunately I have no workaround at the moment.

Integrating Swift has become a priority but unfortunately I have another task to fulfill (paid contract) that will keep me busy until end of January.

In the meantime perhaps the people who developed the Facebook SDK for Unity could be contacted and be asked to rewrite these 4 files in Objective-C ? It shouldn't be a daunting job.

I promise to address this problem as soon as I have the possibility. Currently what I lack is a way to drive the Swift compiler to produce cross-compiled object files (ie the Swift compiler knows it runs on a Windows/Intel platform, but I want it to compile object files that will be linked for an Apple/arm64 platform). I know how to do that with clang, I haven't found how to do that with swiftc. Maybe the possibility already exists, but there doesn't seem to be many people out here doing it and I can't find that documented anywhere. If anyone has a clue...

Hello Fraccas

I understand this (compiling mixed-source targets) is the most urgent problem to solve for many users. Alas, I have other activities of counseling and development and I'm currently poised with a customer with so much needs that it leaves me with very little free time, and this situation will last until january. It's twice more unfortunate, because I *know* how to implement what's needed to build mixed-sources projects (now that the Swift compiler works), but I just don't have enough time to achieve it. I have just enough free time to handle the other simpler requests.

If you can't wait til january, and buying a used Mac (but recent enough to support the latest iOS SDK) is within your budget, I'm afraid it's the safest thing to do for you now.

The alternative for you is to not use the master build script and implement your own scripted logic for building your project, using the builder's tools. Everything is here, it's just a matter of doing things slightly differently. Basically you need to "swap" compiler-produced source layout files at the right time when you build mixed-source projects. The Objective-C part of the module needs to be exposed to the Swift compiler when building the Swift files, and the Swift part of the module needs to be exposed to the Objective-C compiler when building the Objective-C files. It's kind of a chicken-and-egg problem ; and to solve it 3 passes are necessary, 2 for producing the interface definition files, the actual build being done in the third. Have a look at Jordan Rose's reply here: https://forums.swift.org/t/how-apple-sdk-overlays-work/11317/2, and of course https://github.com/apple/swift/blob/main/docs/Driver.md - beware, if you're not quite experienced with all this, it might be hard for your to understand what it's all about - and what you need to do to make it work.