cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Want to learn some quick and useful tips to make your day easier? Check out how Calvin uses Replay to get feedback from other teams at Dropbox here.

Dropbox API Support & Feedback

Find help with the Dropbox API from other developers.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Can't build for iOS Simulator when SDK installed with Carthage

Can't build for iOS Simulator when SDK installed with Carthage

Robert S.138
Helpful | Level 7
Go to solution

Apple broke my Dropbox SDK installation in their latest XCODE 12.0.1.  I was using the Cocoa Pods method ever since Dropbox V2 came out.  So I decided to redo my project using Carthage.  It works fine when building for an iOS device, but fails when building for the simulator.  I don't know how Cocoa Pods handled it.  All I know it that it used to work.  But with Carthage, apparently, the SDK builds a static library for ARM processors only, and the simulator requires X86_64.  By the way, the failure in the Cocoa Pods method was that the Dropbox SDK headers were not found when building for the simulator, even though they were found when building for devices.  So with both Carthage and with Cocoa Pods, I can build for devices but not for the simulator, but for different reasons.  Is there a way with XCODE 12.0.1 to build for the simulator?  (I need to use the latest XCODE because I am debugging an iOS 14 problem which is only supported in XCODE 12.)

 

10 Replies 10

Robert S.138
Helpful | Level 7
Go to solution

**SOLVED**

 

The main problem was that the Intel 64-bit architecture was not recognized by XCODE as on of the build architectures. That in turn was caused by the update to XCODE 12.  Even though the architectures were properly indicated as $(ARCHS_STANDARD) in both the project and the target build settings, they were being overriden by a setting in the USER-DEFINED section of the build settings that XCODE transferred there for some reason.  The setting in USER-DEFINED was

 

VALID_ARCHS     armv7  arm64

 

The solution was to click on this setting and hit DELETE so it totally vanishes.  Then the main project build settings that include all standard architectures can be effective.  It was odd that this error led to the error "ObjectiveDropboxOfficial/ObjectiveDropboxOfficial.h" not found.  But perhaps it had to do with CocoaPods making a copy of the header files for each architecture, because this error did not happen when building for a real device.  Anyway, it is solved.

 

Oh, I gave up on Carthage and returned to my original Cocoapods setup.  Also I updated Cocoapods to the latest, version 1.10.0 with

 

  sudo gem install cocoapods

 

Also I updated the ObjectiveDropboxOfficial project to ver 5.0.3  with:

 

   pod update

   pod deintegrate

   pod install

 

(I don't know if the last two commands were necessary.)

 

Updating to Dropbox API version 5.0.3 and XCODE 12 only required two small accomodations in my source code.  One was that the type of the first parameter in the response block for the function createFolderV2 had to be changed from DBFILESFolderMetadata to DBFILESCreateFolderResult.  The other change was that [DBClientsManager handleRedirectURL] now uses a completion block instead of returning the DBOAuthResult directly.

 

Anyway, I am back to using Cocoapods and everything is working as it should.

 

Need more support?
Who's talking

Top contributors to this post

  • User avatar
    Robert S.138 Helpful | Level 7
  • User avatar
    Greg-DB Dropbox Staff
What do Dropbox user levels mean?