We are aware of the issue with the badge emails resending to everyone, we apologise for the inconvenience - learn more here.
Forum Discussion
C. Tim
10 years agoNew member | Level 2
To use API v2 in iOS platform, we need an objective-C version
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!
- Ari W.New member | Level 1
@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.
- Paradigm M.New member | Level 1
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.
- Ari W.New member | Level 1
@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.
- Paradigm M.New member | Level 1
Agreed. Most iOS apps are still being written in Objective-C. We really need an Obj-C version of the API.
- Joris M.New member | Level 2
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.
- C. TimNew member | Level 2
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.
- David N.18New member | Level 1
It is incredible that a company such as Dropbox would even go down this path. Supporting developers should be any companies #1 priority. Instead it sure seems like you and your team are focused on doing 'what you enjoy' instead of supporting the rest of us. Our team has chosen to pull all of our Dropbox support and only support Google Drive. We need a cross-platform way to access and manage files from a variety of devices and the lack of true Obj-C support is ridiculous. The two pages of complaints and explanations on why this is important only results in 'we underestimated, and it's not a priority'. This is an extreme disappointment to us and we feel that only by directing our clients to other services and moving our business away will the point be driven home. I'm sorry for your approach to this and your response so far has only been disappointing. Good luck with your push towards Swift, it sure looks like it's going well for you. I'm glad you get to use the Enums you like.
- Greg-DBDropbox Staff
Thanks for the request! I'm sending it along.
For reference, I believe it's possible to use a Swift library in an Objective C app, though unfortunately I don't have any instructions for doing so available.
- Mobile H.New member | Level 1
Is there still no ObjectiveC sdk on github or I can't find it? Or at least an Objective-C project that is using the swift dropbox library.
- Nicholas C.5New member | Level 1
I usually read "no ETA" as in "1-2 years". Looks like I'm sticking with iCloud.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
5,877 PostsLatest Activity: 12 months agoIf you need more help you can view your support options (expected response time for an email or ticket is 24 hours), or contact us on X or Facebook.
For more info on available support options for your Dropbox plan, see this article.
If you found the answer to your question in this Community thread, please 'like' the post to say thanks and to let us know it was useful!