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

[C. Tim]

We didn't use swift in our app development for iOS devices.

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

Please kindly provide an objective-C version!

[Steve M.]

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?

[Ari W.]

@Steve, thanks for providing the additional information and for your transparency. I'll just quickly reiterate that for us (and for many other iOS developers), including any Swift code in our app is not an option at this point in time.

Your decision to not write the SDK itself in Objective-C on the grounds that "the experience of using an Objective-C library from Swift is not great" doesn't seem logical to me, because the converse (not being able to use Swift code in Objective-C) is a far more severe problem. Also keep in mind that all of Apple's iOS system frameworks are written in Objective-C, and Swift developers are more than capable of using them. Apple has made some great additions to Objective-C recently (nullability, generics) specifically to improve this type of interoperability.

If I were in your shoes, I would invest your time into re-working the new SDK to be written solely in Objective-C, and perhaps distribute a nice Swift wrapper with fancy enums if that is something that developers are interested in. Maintaining 2 separate SDKs does not seem like a good choice. The majority of iOS apps today are written in Objective-C, not Swift. Your goal as an SDK vendor should be to ensure that your SDK is usable by the most number of developers, and potentially excluding more than half of your audience due to a programming language choice is a poor decision.

[RTS S.]

Steve,

  My wrapper is very specific to my APP.  So I do not think it would be applicable as a general API. My wrapper handles all of the errors. It's a simple object that references the Client Object and has a bunch of methods to manipulate the DB Files API. They typically return nil for error  or the primary subject of the method like the Metadata or Account info.

You mention the strong dependencies of enums for your choice of Swift. This does not really provide anything of value to the consumers of the API. It may have been useful in the implementation, You could have achieved similar results with a consistent design pattern that maps int enum value in the JSON response to an  appropriate object class. 

The types that pass across the API's  public interface  are already objects like  Metadata, Account, and Error Types..  

So you could have provided the SAME Swift User experience to users with an API written entirely in Objective-C

As I said previously: The style of passing completion blocks/closures for each request is a tremendous improvement over the previous delegate based model.

[Steve M.]

Here's an example of non-numeric enums that I quite like:

if let authResult = Dropbox.handleRedirectURL(url) {
    switch authResult {
    case .Success(let token):
        print("Success! User is logged into Dropbox with token: \(token)")
    case .Error(let error, let description):
        print("Error \(error): \(description)")
    }
}

[Crypto C.]

I think that now build a library "only" in swift it's senseless, better make calls on server HTTP (S) (PUT e GET) with NSURLSessionDataTask and NSURLSessionDownloadTask ... the version 1 it deprecated and do not allows background session ...

My app is object-c and for now we have no intention to migrate in swift !

thanks

[Joris M.]

Another long time iOS developer here with a huge codebase and quite a few clients with running apps that require maintenance, and no plans to be switching to Swift anytime soon.

It's all nice that we have these hipsters jumping on the Swift bandwagon as soon as it came along (it's from Apple so it should be the next great thing right?), but stability issues in Xcode at first and language changes along the road makes you think twice about switching all your Objective C code to Swift, unless you do this as a hobby and not write iOS apps for a living.

There is a huge amount of code out there that is written in Objective C. Using Objective C from Swift is a lot easier than the inverse (which might be impossible in some cases as you have shown yourself), and there are a lot of apps out there (you will know better than me) that already integrate with Dropbox. You can't possibly expect all those developers to switch languages or include the Swift runtime + all the problems when trying to get the thing to compile if they want to maintain their app and integrate SDK V2?

I think there has been a wrong decision at Dropbox: since you guys started a new SDK from scratch anyway it would make sense to just use the latest and "greatest" tech to write it in.

I am currently writing an SDK myself for one of my clients, and doing it in Objective C for the reasons mentioned by my colleagues in the previous posts.

Let's talk Android: would it make sense to build an Android SDK which would only work on Android 6.0 today? For me it is a similar story with iOS.

[Joris M.]

http://ericasadun.com/2016/01/05/swift-development-realities/

[Raheel S.]

Yet another long time ObjC developer. I agree with everyone here and I desperately need an ObjC wrapper atleast

@Steve, I wanted to point out that its now Jan 28. I have a couple of months to migrate from DBDataStores to some new model with text files using a totally new swift-based SDK without a Sync Api at all. 

I am trying hard to find a way to successfully transition from Datastores to File-based Sync, redoing the logic and everything else. With some respectable users already using my app, I'm pretty scared.

Please tell us if you have any plans at all to release some ObjC SDK or, at-least, a Wrapper. I would really like some notice on your part before I again invest months and months and have it turned out to not last (Datastores).

So, please, let us know what you are upto with this issue. Time is really running out for some of us Datastores lovers.

PS: I'm just sad Datastores are ending, Its not that they're special to make/host, they're special because of Dropbox behind it. Oh well!

[Mike K.14]

Just chiming in, another ObjC developer wanting v2!

[Harald S.2]

I think Dropbox is ignoring those developing and building value for them. Following changes in technology is fine but maintaining existing technologies is as important. It is about securing investments. Deprecating an API generates lot of efforts for the developer community. Leaving those willing to support this change nevertheless with no option is even worse.

I have a large Objective C code base and nearly a dozen of apps on the store. I will try to keep the v1 API as long as possible and drop Dropbox support afterwards. There are other options.