Alamofire compilation errors after installing the SwiftyDropbox in Xcode project with CocoaPods

Hi Greg-DB,

I replied the eamil sent to me from Dropbox Forum with the error info and steps of how I generated the errors. Did you get that email? Or do I need to put the info in this thread?

Thanks a lot for your help.

Shimin

ShiminCai I don't believe replying to the notification email sends the content anywhere I can access it. Please post the information in the thread here. (If you need to share it privately for some reason, you can open an API ticket here instead.)

Hi Greg-DB,

Many thanks for your reply and sorry I did not know that.

My development environment is Xcode 8.3.3, Swift 3.1 and CocoaPods 1.4.0.beta.1.

The project is a currently deployed enterprise app which uses pod 'Dropbox-iOS-SDK' (Dropbox api v1) to enable file download and upload. Building the project now does not generate any compilation errors.

Change the Podfile to install pod 'SwiftyDropbox'. The "pod install" removes Dropbox-iOS-SDK and installs

Alamofire (3.5.1) and SwiftyDropbox (3.3.1). The Terminal output is as below:

Last login: Fri Oct  6 08:44:21 on console

fcl1611-9syvsc2:~ shiminc$ cd projects

fcl1611-9syvsc2:projects shiminc$ cd fcmapapp2

fcl1611-9syvsc2:fcmapapp2 shiminc$ pod --version

1.4.0.beta.1

fcl1611-9syvsc2:fcmapapp2 shiminc$ pod install

Analyzing dependencies

Removing Dropbox-iOS-SDK

Downloading dependencies

Installing Alamofire (3.5.1)

Using ArcGIS-Runtime-SDK-iOS (10.2.5)

Using SVProgressHUD (2.1.2)

Installing SwiftyDropbox (3.3.1)

Generating Pods project

Integrating client project

Sending stats

Pod installation complete! There are 3 dependencies from the Podfile and 4 total pods installed.

[!] The `FCMapApp [Debug]` target overrides the `ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES` build setting defined in `Pods/Target Support Files/Pods-FCMapApp/Pods-FCMapApp.debug.xcconfig'. This can lead to problems with the CocoaPods installation

    - Use the `$(inherited)` flag, or

    - Remove the build settings from the target.

[!] The `FCMapApp [Release]` target overrides the `ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES` build setting defined in `Pods/Target Support Files/Pods-FCMapApp/Pods-FCMapApp.release.xcconfig'. This can lead to problems with the CocoaPods installation

    - Use the `$(inherited)` flag, or

    - Remove the build settings from the target.

fcl1611-9syvsc2:fcmapapp2 shiminc$

The 'pod update' runs ok and the Terminal output:

fcl1611-9syvsc2:fcmapapp2 shiminc$ pod update

Update all pods

Updating local specs repositories

  $ /usr/bin/git -C /Users/shiminc/.cocoapods/repos/master fetch origin

  --progress

  remote: Counting objects: 1683, done.        

  remote: Compressing objects: 100% (1016/1016), done.        

  remote: Total 1683 (delta 1101), reused 1159 (delta 586), pack-reused 0        

  Receiving objects: 100% (1683/1683), 187.06 KiB | 0 bytes/s, done.

  Resolving deltas: 100% (1101/1101), completed with 351 local objects.

  From https://github.com/CocoaPods/Specs

     77c312d3207..032e4c6e436  master     -> origin/master

  $ /usr/bin/git -C /Users/shiminc/.cocoapods/repos/master rev-parse

  --abbrev-ref HEAD

  master

  $ /usr/bin/git -C /Users/shiminc/.cocoapods/repos/master reset --hard

  origin/master

  HEAD is now at 032e4c6e436 [Add] Yams 0.3.7

Analyzing dependencies

Pre-downloading: `SVProgressHUD` from `https://github.com/SVProgressHUD/SVProgressHUD.git`

Downloading dependencies

Using Alamofire (3.5.1)

Using ArcGIS-Runtime-SDK-iOS (10.2.5)

Installing SVProgressHUD 2.2.1 (was 2.1.2)

Using SwiftyDropbox (3.3.1)

Generating Pods project

Integrating client project

Sending stats

Pod installation complete! There are 3 dependencies from the Podfile and 4 total pods installed.

[!] The `FCMapApp [Debug]` target overrides the `ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES` build setting defined in `Pods/Target Support Files/Pods-FCMapApp/Pods-FCMapApp.debug.xcconfig'. This can lead to problems with the CocoaPods installation

    - Use the `$(inherited)` flag, or

    - Remove the build settings from the target.

[!] The `FCMapApp [Release]` target overrides the `ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES` build setting defined in `Pods/Target Support Files/Pods-FCMapApp/Pods-FCMapApp.release.xcconfig'. This can lead to problems with the CocoaPods installation

    - Use the `$(inherited)` flag, or

    - Remove the build settings from the target.

fcl1611-9syvsc2:fcmapapp2 shiminc$

Now building the project generates 267 compilation errors that are related to Alamofire:

I also tried to open the project in Xcode 9 and had the same problems.

Thanks a lot for your help.

Cheers,

Shimin

It looks like you're getting an old version of SwiftyDropbox (3.3.1) and consequently an old version of Alamofire (3.5.1). You should be getting 4.2.0 and 4.4.0, respectively.

It's not clear why you're getting the old versions though. Can you try the following?

pod cache clean --all
pod repo update
pod update

Hi Greg-DB,

Your reply helped figure out why I was getting old versions of SwityDropbox and Alamofire. It is the deployment platform specification in the Podfile. It was platform :ios, '8.0'. After changed it to platform :ios, '9.0', I now got the SwiftDropbox 4.2.0 and Alamofire 4.4.0, and all 267 Alamofire-related compilation errors are gone. Thank you.

However, I'm still getting a compilation error about SwiftyDropbox as shown below:

Cheers,

Shimin

Hi Greg-DB,

That resolved the SDK compilation error. Many thanks.

Now it's up to me to migrate my code to V2. Our Dropbox implementation is very basic: We put files in the Dropbox app folder. A list of those files is presented to users in the app and users tap a file to download it to the app. There is no interaction between users and Dropbox such as user sign-in, etc.  I would appreciate it much if any guide regarding how to migrate this is available...  

Cheers,

Shimin

ShiminCai We don't have a migration guide for moving between these SDKs in particular. I recommend just reading through the readme for SwiftyDropbox, which covers the different kinds of calls, to see how each piece should be implemented.