With the iOS change to making all the Unity code now be in the UnityFramework target it's added some new hurdles for using swift to write a plugin to expose iOS functionality to the c# side. Previously you could create a bridging header to bridge swift and objective-c/c++ so that you can have your swift code and then c wrapper to expose to c#. Unfortunately frameworks are not allowed to have bridging headers. Mixing Swift and Objective-C/C/C++ code in a Framework requires you to have any code that the Swift code needs access to in the Public Headers section of the build target. So for Swift code to access the Unity "SendMessage" function you need access to the UnityInterface.h. So ideally you'd add UnityInterface.h to the headers and then be done, except that you can't because UnityInterface isn't a header that is allowed in the headers section. This is solvable though you can build an objective-c wrapper class for UnityInterface.h's SendMessage and then include your objective-c classes header in the headers section. And then also include it in the UnityFramework.h umbrella header. Also strangely you may need to re-order the build phases so that the the headers build phase is first for everything to work. So while you can get swift plugins to work with some manual manipulation of the Xcode project, these manual steps as far as I can tell are not available in the PBXProject class. It seems like at least some of that is "almost" part of the PBXProject class, I can locate the header I need using FindFileGuidByProjectPath, and it seems like AddFileToBuildSection ought to work if you give it the write guid for the header section, but interestingly if I copy the guid out of the pbxproject used for that section and use it it AddFileToBuildSection crashes. Also oddly calling GetBuildPhaseName on that guid causes a null reference, which is odd considering GetAllBuildPhasesForTarget does return that guid in it's array. But even if that did work there's no good way to re-order the build phases as far as I can see, and add your wrapper header to the UnityFramework.h. I think ideally UnityInterface.h would be made compatible or some equivalent compatible header would be in the headers section already and possibly the headers would be at the top of the build phases by default.