If I recall correctly you have to make a separate module with the bridging headers, but the first problem is that I can't remember exactly of the syntax of that file.
The second is that it's a lot of code and files to make when we only have one import to hack something quickly. For a full library it's probably a very cool feature though.
The third one is more related to my use case. I made a binding with a non-C codebase, and Swift cannot directly import C functions AFAIK, so I had to write C code in addition to the Swift one to make headers. It's not impossible, but it does take time to write all of that in a third programming language.
The fourth problem is related to library imports. In SPM, you either import a system library, or an xcframework. If your app targets any non-Apple platform, xcframeworks are not an option, so if you made a binding to your own lib that's annoying as it is probably not installed while you're building. And even if you're targeting Apple platforms, making an xcframework without Xcode is not well documented.
I probably missed a few problems as my experience is not very extensive, and there are probably better ways to achieve some of the things I wanted to do, but there isn't much documentation about all of that online anyway as far as I saw.
Alright yeah, I can concur with the packaging of the library so that it would eventually link and be accepted by the App Store which is surprisingly not the same set of requirements. It's just that I didn't completely chalked this up to Swift interop with C specifically but more the fact that multiple things Apple side need some jumping-through-hoops and that's just one of them.
I solved that through importing the dependency with Conan, and having extra steps running afterwards that would perform some quick and dirty lipo, xcodebuild and PlistBuddy stuff. It just wasn't that complicated, and only a few headscratches, but then it'd work and there was no need to touch that again, but situations may vary and I get that it could be painful in some cases.
I'm not op and it's been many years since I tried but back in the early days of Swift interop with C worked great until it didn't and it was very difficult to figure out what was going on because the debugger might as well have not existed.
Not aimed at you particularly, but I've noticed more and more of the technical discussion on HN turn into "I don't really use it, but here's my many years old experience / non-user observation", which is mostly just confusing to people trying to leadn.
You don't need to justify op with old anecdotes, people want to know what the issues are today, if any. At least that's what makes this website valuable for me.
Do you expect people to periodically repeat failed experiments just so they can provide you with up to date information? You are always free to ignore it.
In any case, this particular observation is timeless: language bridges always have trolls under them. Maybe your project can get away with using the bridge anyway, but maybe a highly critical API gets locked out because the bridge deals poorly with variadic arguments or object lifetimes or templates/generics or nested objects or latency/overhead assumptions or.... whatever, and the troll conks your schedule on its head. Try to minimize exposure and prioritize steps to de-risk the bridge.
Do you expect people to periodically repeat failed experiments just so they can provide you with up to date information?
Not OP, and I for one don't, but noting the age of the reported experience would be valuable. I have also noticed the "stale cache" problem. It leads to confusion and misunderstanding.
Definitely makes sense. In defense of the previous comment I made though, the debugger is only marginally better than when Swift first came out. That's regardless of whether or not you're interoping with C. It's still a terrible experience compared to what Obj-C provided.
The second is that it's a lot of code and files to make when we only have one import to hack something quickly. For a full library it's probably a very cool feature though.
The third one is more related to my use case. I made a binding with a non-C codebase, and Swift cannot directly import C functions AFAIK, so I had to write C code in addition to the Swift one to make headers. It's not impossible, but it does take time to write all of that in a third programming language.
The fourth problem is related to library imports. In SPM, you either import a system library, or an xcframework. If your app targets any non-Apple platform, xcframeworks are not an option, so if you made a binding to your own lib that's annoying as it is probably not installed while you're building. And even if you're targeting Apple platforms, making an xcframework without Xcode is not well documented.
I probably missed a few problems as my experience is not very extensive, and there are probably better ways to achieve some of the things I wanted to do, but there isn't much documentation about all of that online anyway as far as I saw.