To use API v2 in iOS platform, we need an objective-C version

Thanks for all the detailed feedback! As requested, let me explain some of our thinking. I'm just one person who worked on this, but I'll do my best to explain the thought process.

When we first started work on SDKs for API v2, we looked at a few options for how to support iOS developers:

1. We could write an Objective-C SDK and encourage Swift developers to use that too.
2. We could write a Swift SDK and encourage Objective-C developers to use that too.
3. We could write both an Objective-C SDK and a Swift SDK and encourage developers to use the SDK in the language of their choice.

#3 is somewhat appealing in that it allows for building SDKs very specifically tailored to the features of each language. But it has the downside of doubling the support/maintenance cost.

#1 is possible, but the experience of using an Objective-C library from Swift is not great, and then the SDK can't take advantage of great Swift features like enums.

We ultimately decided to take the approach in #2 and build only a Swift SDK. The runtime size is indeed a concern, but we expect Swift development to become more and more popular over time. We'll eventually deprecate API v1, but we haven't set a timeline for that yet. I suspect that by the time API v1 is fully deprecated, this won't be much of a concern anymore.

It turns out that making a Swift SDK easily accessible from Objective-C code is harder than we anticipated! When we came to this realization, we considered a few options for how to make the SDK work better for all iOS developers:

1. We could rework the Swift SDK to be more Objective-C-friendly. (As an example, we'd have to drop our use of non-numeric enums.) We rejected this on the grounds that this "least-common denominator" approach would make the SDK worse overall. We recently took the Swift SDK out of beta, and we now intend to keep its interface stable.
2. We could write a separate Objective-C SDK. This has a somewhat high maintenance cost, so for now we're trying to avoid doing this.
3. We could write a compatibility layer into the Swift SDK that made calling it from Objective-C easy. This is our current plan of record. It lets us keep the nice features of Swift for Swift developers, but it should make it easy for Objective-C developers to adopt the SDK and not have to do work themselves writing a wrapper.

Because we're not that deep into our investigation of #3 yet, it's possible we'll discover things that make us want to revisit the decision.

For those of you (RTS?) who built your own wrappers on top of the Swift SDK, would you mind sharing what worked well/poorly?