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, 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.

This decision is insane. Is there any technical justification you can give me that will allow me to convince my PM that our team now has to learn another programming language to use your API? Box, S3, GDrive, OneDrive and iCloud all have Objective-C apis available. Do you really feel that you'll be able to compete for IOS developer mindshare with just a Swift-based API? I strongly urge you to reconsider.

@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.

Agreed. Most iOS apps are still being written in Objective-C. We really need an Obj-C version of the API.

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.

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

Ashok M.2
New member | Level 1
9 years ago
Hi Gregory,

Could you please share current details and state of DBv2 (swifty).

As per following migration guide for v1 to v2, it says Objective-C SDK is coming out in Aug 2016.

https://blogs.dropbox.com/developers/2016/04/announcing-the-v1-to-v2-migration-guide/

Are you guys planning to release a separate v2 SDK that is purely Objective-C or it's still the Swifty SDK with Objective-C support?

Thanks in advance.
Greg-DB
Dropbox Staff
9 years ago
Hi Nicola, the official Objective-C SDK is available at the link in Stephen's post:

https://github.com/dropbox/dropbox-sdk-obj-c
Zhenya T.
New member | Level 1
10 years ago
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 ;)
Steve M.
Dropbox Staff
10 years ago
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.
Helpful | Level 6
10 years ago
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)
RTS S.
Helpful | Level 6
10 years ago
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.
Steve M.
Dropbox Staff
10 years ago
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:

We could write an Objective-C SDK and encourage Swift developers to use that too.

We could write a Swift SDK and encourage Objective-C developers to use that too.

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:

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.

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.

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?
Joris M.
New member | Level 2
9 years ago
http://ericasadun.com/2016/01/05/swift-development-realities/
Greg-DB
Dropbox Staff
9 years ago
Thanks everyone for all of the feedback! We read everything and sincerely appreciate the time taken to write it.

To be clear, we hear and understand the need for Objective-C support. As Steve mentioned earlier in the thread, we intended for Objective-C support to be available, but made a misjudgment about the technical barriers to making that possible. That unfortunately means it will take us longer than we intended to offer it.

That said, the good news is that API v1 a.k.a. the Core API is not deprecated, so you can continue to use it. We don't intend on deprecating the Core API for some time, and we will offer a long span of time for migration once we do.
TK K.
New member | Level 1
9 years ago
Thanks for the news, also very happy v1 will continue. If I could forward one more positive thought, if/when ya'll do v2 for objC it would be nice if it was an evolution not a revolution ;)

Just curious being a newb - what is in the v2 api functionally that is not in v1 other than oauth2 instead of oauth1? I am actually pretty happy with v1...