I am constructing an iOS library that incorporates each Swift and C++ code.
Utilizing the brand new C++ <> Swift interop from Swift 5.10, I can now skip the Goal-C bridge – which was annoying to jot down, and likewise slowed every little thing down in efficiency important code.
I managed to arrange the CocoaPod and my instance challenge accordingly – SWIFT_OBJC_INTEROP_MODE
is ready to objcxx
, and I am utilizing C++ 20.
Now I created CxxInstance.hpp
:
#embody "MyPod-Swift.h"
enum class SomeEnum { FIRST, SECOND };
class CxxInstance {
public:
static void runIt() {
auto swiftInstance = MyPod::SwiftInstance::init();
int i = swiftInstance.getInt(); // <-- works ✅
SomeEnum e = swiftInstance.getEnum(); // <-- construct error! ❌
}
};
And SwiftInstance.swift
:
public class SwiftInstance {
public init() { }
public func getInt() -> Int {
return 13
}
public func getEnum() -> SomeEnum {
return .FIRST
}
}
MyPod-Swift.h
was generated efficiently and I can name MyPod::SwiftInstance::init()
.
However whereas getInt() -> Int
works advantageous and could be referred to as from C++, getEnum() -> SomeEnum
fails to construct as a result of C++ can not resolve that methodology.
In Swift it exists and I can use the enum SomeEnum
simply advantageous – it is simply the C++ half that fails to search out the getEnum()
methodology.
Based on their Mixing Swift and C++ information, calling Swift capabilities from C++, the place the Swift operate makes use of C++ varieties needs to be a supported function, however I feel they created separate “Modules” – one for C++ and one for Swift.
In my case I’ve a single .podspec
which incorporates all information – Swift and C++ – as source_files
:
Pod::Spec.new do |s|
s.identify = "NitroImage"
s.model = bundle["version"]
s.abstract = bundle["description"]
s.homepage = bundle["homepage"]
s.license = bundle["license"]
s.authors = bundle["author"]
s.platforms = { :ios => min_ios_version_supported }
s.source_files = [
# C++ part
"cpp/**/*.{hpp,cpp}",
# Implementation (Swift)
"ios/**/*.{swift}",
]
s.pod_target_xcconfig = {
# Use C++ 20
"CLANG_CXX_LANGUAGE_STANDARD" => "c++20",
# Allows C++ <-> Swift interop (by default it is solely C)
"SWIFT_OBJC_INTEROP_MODE" => "objcxx",
}
finish
And CocoaPods all the time generates a default module.modulemap
:
module MyPod {
umbrella header "MyPod-umbrella.h"
export *
module * { export * }
}
I feel I’m utilizing dynamically linked use_frameworks!
, if that issues.
Any concepts of how I can correctly have cyclic dependencies on C++ <> Swift code inside the identical Pod?