Child Item

Dropbox V2 Obj-C Installation Query

I followed the instructions on github to 'Manually add subproject' into Xcode with the help of Carthage. This all appears to work fine, but I am confused as to where it is picking the Dropbox framework up from.

When a build is done of my app, this seems to build the Dropbox framework as well. However when performing the 'carthage update --platform iOS' command, this also builds the Dropbox framework into the 'Carthage\Build\iOS' folder.

To add to the confusion, the 'Linked Frameworks and Libraries' section of the General settings has a reference to the version of the Dropbox framework which is built with the app, whereas the 'Framework Search Paths' build setting is pointing to the 'Carthage\Build\iOS' folder.

So my question is, which version of the Dropbox framework should it be putting into my app. The one in the 'Carthage\Build\iOS' folder, or the one which gets built when my app is built?

Find more posts tagged with

API

Abuse

Comments

Greg-DB

If you're using the 'Manually add subproject' installation method, the Dropbox framework does get built both when running carthage, as well as when you build in Xcode. I believe these should both be building to the same Carthage\Build\iOS location though.

This is a bit redundant, but it helps to ensure you have a working copy of the Dropbox library when initially checking it out via carthage.

Mark R.5

Hi Greg. That is not actually the case. The subproject builds the framework to a folder called something like:

/Users/{Name}/Library/Developer/Xcode/DerivedData/App-emiqpeodictxkuhelynkbahkugza/Build/Products/Debug-iphoneos

This is the one that seems to be in the 'Linked Frameworks and Libraries' area.

Stephen C.14

Sorry for the confusion here. You should not be using the one that Carthage builds, but instead the one that is built by your subproject (I think it's the only one you'll have access to when you do the following steps):

In the Project Navigator in Xcode, select your project, and then navigate to your project's build target > General > Embedded Binaries > + and then add the ObjectiveDropboxOfficial.framework file for the macOS platform.

(read more in the SDK docs here)

Mark R.5

Hi. This is actually iOS, not Mac, but I presume the point is the same that it should use the framework built by the subproject.

This confirmation was what I needed since I am still using v3.0.8 of the SDK as I need to support iOS 8 for the time being. I was getting a crash report from the SDK that was easy enough to fix in the code, but was not sure whether users would get the version with the fix or the version built by Carthage, so this hopefully clears it up.

Stephen C.14

Ah ok, yeah this still applies, even when the platform is iOS.

As far as the crash, would you mind sharing the error message or stacktrace?

Also, for my own curiosity's sake, at what point do you think you will consider dropping support for iOS 8 (which now constitutes < 3% of all iOS users)?

Mark R.5

The crash is already fixed in a later release. It was a route method which was not checking for 'nil' data.

Due to the fact that turning off the V1 API will make the Pro Upgrade in my app useless for some people, I wanted to get the initial migration update out to as many people as possible. I have sacrificed the iOS 7 users, but still have a reasonable number of iOS 8 users (due to a large user base), so I decided to support them. I will probably drop support for iOS 8 once iOS 11 is out.

Stephen C.14

Got it, thanks for letting me know. Yeah, we weren't crazy about dropping iOS 8 support on our end either, it's just that we needed access to `SFSafariViewController` (rather than `UIWebView`) for rendering our auth flow.

Google, which offers our users a "Sign in With Google" option for logging in, has dropped support for using this button in anything but a semi-fullfledged browser (like Safari view controller).

That, combined with the fact that App Store was rejecting some apps for using an external browser redirect for auth caused us to drop support for iOS 8.

Hope you can understand where we're coming from. Please let us know if you run into other issues. Good luck!

Mark R.5

Totally understand. I have been through quite a process myself, rewriting my syncing code at a low level to handle automatic syncing on iOS, Android and Windows. It was three different (though similar) implementations, which are all now out in the wild. The general premise was to have two background threads, one listening for changes coming in and another uploading changes going out. I am sure this is similar to what the old Dropbox Sync SDK used to do.

It is not a question of waiting and seeing if any problems arise, which I am sure they will.