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

Back-pedaling here a bit, sorry. After further investigation yesterday, it looks to me like making it easy to call SwiftyDropbox from Objective-C is going to be considerably more work than I thought. I don't think Objective-C support will make it into the initial release of the SDK, but it is something we will look at after the initial release.

We'd welcome contributions from the community here if perhaps someone on this thread is more experienced with mixing Swift and Objective-C than we are. The biggest challenge identified so far is the use of enums.

Completely agree with @ari can someone provide some kind of rational as to why this decision was made? It will be quite a while before swift is included with iOS and the extra app size is substantial. if written in Obj-C this library could easily be used in swift

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.

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)")
    }
}

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

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!

Just chiming in, another ObjC developer wanting v2!

@Gregory: any word on Datastores deprecation? Any delays there? 

We need to keep using the deprecated Sync API, too.

Could you please delay the deprecation of Sync API?

Otherwise, we have no choice to disable Dropbox support but only offer iCloud support in our new apps.

First I am a developer and NOT a paid DropBox fanboy ;) You know, I felt the same way at first about the lack of a v2 API for objC. However after integrating the v1 SDK for iOS, and taking a hard look at what "new" or different features are available in the v2 iOS SDK for Swift, there really are no significant features missing.

You are really stressing over the name - v1 vs v2 without considering what the SDK provides or how DropBox really works (under the trappings of any of the SDKs). The core DropBox API is usable by anyone directly using HTTP requests - the interface libraries are just someone's take on making it easier for a given platform or programming language. Furthermore, these libraries (SDKs) are not optimal - NONE of them expose ALL the features of the core DropBox API as it exists as a RESTful interface. They all leave out something you might want or do it in a way which may not fit your desired usage.

What is nice about the DB SDKs is that they are open source and you can enhance them to your liking, use them as is, or roll your own. Also the folks on here are somewhat responsive compared to the other platforms (Drive, iCloud, OneDrive...). The core DB API is much easier to use than any of those other storage APIs as well IMO.

So while I too felt the same way, I have to agree with DropBox - even though they don't say it the iOS v2 SDK does not really bring a lot to the table that the v1 SDK does not bring. And as a developer that has used the v1 SDK, if they were to come out with a v2 SDK for objC, I would be bummed if I had to rewrite a bunch of code for new/different interfaces just to achieve the same functionality I already have today. The only thing I would do to their v1 API is make it Oauth2 compliant and leave everything else the same anyway.