1. Put the C++ code in its own directory under foo_plugin/ios (not foo_plugin/ios/Classes), say foo_plugin/ios/myNativeCode.
2. Do not do anything in Xcode. Instead, in foo_plugin/ios/foo_plugin.podspec, put
s.public_header_files = 'Classes/**/*.h'
s.source_files = [
'Classes/**/*',
'myNativeCode/**/*.{cpp,hpp,c,h},
]
Note that only (the automatically created) Classes/FooPluginPlugin.h will actually be taken as part of public_header_files; your own code from myNativeCode will be considered 'private' according to Podspec:
3. Carry on with Step 3 of the c-interop guide.
Some other useful podspec options:
# add HEADER_SEARCH_PATHS to pod_target_xcconfig, e.g:
s.pod_target_xcconfig = {
# Allow relative "#include"s from the project base directory:
'HEADER_SEARCH_PATHS' => [
'$(PODS_TARGET_SRCROOT)/myNativeCode',
],
# Ensure some particular C++ standard, e.g:
'CLANG_CXX_LANGUAGE_STANDARD' => 'c++11',
'DEFINES_MODULE' => 'YES',
# Flutter.framework does not contain a i386 slice.
'EXCLUDED_ARCHS[sdk=iphonesimulator*]' => 'i386',
}
# Exclude some files that aren't to be included
s.exclude_files = [ 'myNativeCode/win32/**/*' ]
# Ignore warnings from the compiler
s.compiler_flags = [
'-GCC_WARN_INHIBIT_ALL_WARNINGS',
'-w',
]
Something to be aware of when editing your .podspec file (and that caused me a lot of wasted time): CocoaPods and/or Xcode seem to cache a lot of stuff. Updates you make to your podspec might not propagate, unless you clear pod-related information in the destination project first. In the example app for a plugin, it mostly seemed enough to delete the files Podfile, Podfile.lock and the directory Pods in example/ios before trying to build the app again.
A link to the Podspec Syntax Reference:
Thanks for your help,
Odev