[roop]

If your SDK is meant to be used as a binary framework or in any sort of compiled form (which is probably unlikely because you say it's going to be open source), I'd recommend Obj-C, because Swift's ABI is not stable yet.

If your SDK is meant to be used from source, I'd recommend Swift. I'd even say you should prioritize providing a good Swift API over providing any Obj-C API at all (so if the API would work best if it uses enums with associated values or protocols with associated types, so be it, even if that means it can't be used from Obj-C).

You have mentioned the downsides of picking Obj-C, and they are both valid. There are no upsides to picking Obj-C though - Swift is more popular, and can do anything Obj-C can do (because it can piggyback on the Obj-C runtime when required), and do lots more that Obj-C can't do.

The biggest problems with Swift earlier were (1) Xcode crashing or being too slow and (2) the language changing every year. Both are pretty much fixed now.

At this point, the only reason an Obj-C expert would stick to Obj-C is familiarity - it's faster to code in a language you got to know well over many years. That's however not a reason for _your_ SDK to be in Obj-C.