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!

[Zhenya T.]

I don't think that full support of Objective-C is reasonable here. Cause Swift provides more good development patterns based on its structs and enums that are not accessible from Objective-C. The best solution here from my point of view is If you want to use Swift SDKs from your Objective-C code than write the wrapper in Swift that will handle the paradigm difference as you like. May be it will push you to write projects in Swift. It's good since 2.0 version 😉

[C. Tim]

Without obj-c support, we will skip Dropbox support in any of our new app developments and use iCloud for our initial version.

This is also a trade-off for Dropbox.

The more limit set by Dropbox, the less scope of the app users in iOS platform.

[Steve M.]

As I said, we plan to add support for Objective-C users. I don't have an ETA yet, but once we finish up the Swift SDK and take it out of beta, it's going to be the next thing we work on in the library.

[RTS S.]

If this comes in phases .. it would be good to get the Files.Metadata classes available in Objective-C.  I find it convenient to keep meta associated with a Dropbox path in my App. I need to handle all the various Files.Metadata sub classes. 

The Users.Account class would also be useful, but sine any app only has one to a few accounts ... this is less needed (i.e. it can be easily wrapped)

[Dal R.]

Deriving from NSObject would be the first, then adding @objc to all protocols. + You're still limited only to apps that support dynamic frameworks, so iOS8+. And if you use CocoaPods (which many of us do), you cannot really mix and match dynamic frameworks and static libs. If you are using static libs, you'll have to manually integrate this framework.

[Nicholas C.5]

I usually read "no ETA" as in "1-2 years". Looks like I'm sticking with iCloud.

[Ari W.]

@Steve, my team and I make the Workflow app and we disappointed in your decision to write the Dropbox v2 SDK in Swift. We are not able to adopt Swift yet because:

- Including Swift code in an app causes the entire Swift runtime to be included in the app, which substantially increases the size of the app, the amount of time it takes for the user to download it, and the amount of space it takes on the user's phone.

- Additionally, the Swift programming language is still rapidly evolving, and Swift code you write today may not compile tomorrow. This makes Swift a bad choice for large codebases like ours.

- New versions of Swift are tied to new versions of Xcode and iOS. When iOS 10 enters beta, it will come alongside a new version of Swift that will not compile with the production, shipping version of Xcode (which you must use to submit apps to the App Store). Therefore we'd have to fork our codebase between the two versions of Swift.

For the reasons I outlined above, we will not be able to adopt Swift until the language is more stable and the runtime is included in iOS. This means that even if you add Objective-C support to the framework, we will not be able to use it and will have to write our own version of the SDK from scratch.

This has not been a problem with other SDKs, as it is standard practice for vendors to write their SDKs in Objective-C. Most major iOS apps (and indeed, the iOS frameworks and apps themselves) are still written in Objective-C and I believe you are making a sizable mistake by writing the new Dropbox SDK in Swift, let alone not including Objective-C compatibility. A lot of developers will be unable to use this SDK. The correct way of doing this would be to distribute an Objective-C SDK that works with both Objective-C and Swift apps, and perhaps an additional Swift wrapper if you want to provide a more Swift-native interface.

[Enea G.]

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

[RTS S.]

I think it's unlikely that this will change soon ... Swifty is bootstrapped from Alamofire which is also a Swift base framework However Alamofire is derived from an Open Source Objective-C library.

In general I like the style of the new interface ... passing blocks/closures for the completion of a request as opposed to the delegate model of the previous objective-c API. But this can still be done in Objective-C ... In fact I wrapped the previous API in a layer that looks a lot like the new API. I still need the wrapper layer now ... because I need to call it from Objective-C ... but the wrapper is pretty trivial.

[Oliver M.13]

Just adding a note to the great arguments @Ari mentioned: for agencies supporting multiple customers at once with projects of different size and probably not updated code bases for months/years but still in heavy use, it is already hard to argue to update APPs for such simple things as outdated APIs. Putting even more pressure into this situation is definitely not ending in an switch-to-swift decision but rather a drop of DropBox support in the first place.

As an API/SDK provider going swift only is definitely too far stretched.