Your workflow is unique đ¨âđť - tell us how you use Dropbox here.
Forum Discussion
How to link V2 API for macOS App Store?
My macOS App runs fine while debugging, with the framefwork embedded. But when I archive it for the App Store the resultand binary crashes with this error, how do I resolve this? Thanks.
Dyld Error Message:
Library not loaded: @rpath/ObjectiveDropboxOfficial.framework/Versions/A/ObjectiveDropboxOfficial
Referenced from: /Users/USER/Library/Developer/Xcode/DerivedData/Krypton-gtvflmsjkkiprjawxtyiymiepcwp/Build/Products/Debug/Krypton.app/Contents/MacOS/Krypton
Reason: no suitable image found. Did find:
/Users/lusol/Library/Developer/Xcode/DerivedData/Krypton-gtvflmsjkkiprjawxtyiymiepcwp/Build/Products/Debug/Krypton.app/Contents/MacOS/../Frameworks/ObjectiveDropboxOfficial.framework/Versions/A/ObjectiveDropboxOfficial: code signature invalid for '/Users/lusol/Library/Developer/Xcode/DerivedData/Krypton-gtvflmsjkkiprjawxtyiymiepcwp/Build/Products/Debug/Krypton.app/Contents/MacOS/../Frameworks/ObjectiveDropboxOfficial.framework/Versions/A/ObjectiveDropboxOfficial'
10 Replies
Using the Xcode subproject method BTW. Is there a special Copy Files build setting or something I can use .... (don't see one in the docs). Thanks.
So I canned the Xcode subproject method, and re-did everything using method #2 Carthage only. Now I cannot even run in debug mode, I get the same errors: 1) cannot load Dropbox framework, and 2) Dropbox code signing error. Has anyone actually gotten a macOS app using Dropbox API V2 on the Mac App Store? Is this likely an environment error/stupid error on my part, perhaps?
Thanks.
- Greg-DB
Dropbox Community Moderator
Thanks for the detailed report Steve. I can't say off hand what the issue may be here, but I'll have the team take a look. We'll follow up here once we have some information for you. Thanks in advance for your patience. Why thank you. I went back to method #3 Xcode subproject and I can once again build and run on my Mac, link and unlink, up-and-download, delete, etc.. When I archive, my typical MO is to upload directly to the App Store. Often I will Export the archive as a macOS App for a final dry run - it's this executable that fails. So I have not placed my App in review for fear it will get the same error.
Now, loaders and I do not get along, but I've been paying attention to the absolute paths of the Dropbox files and I'm beginning to suspect that "someone" is picking up the wrong path, but my head hurts so I've stopped :) for now. Thanks.
Steve
- Greg-DBFor anyone watching here, there's an update to the linking issue here:
https://www.dropboxforum.com/t5/API-support/API-V2-analogue-of-canceFileLoad-and-cancelFileUpload/m-p/222333#M11860 FWIW that trick only works on iOS, the macOS version still gets the dynlib error as reported here, unfortunately.
- The iPhone and iPad iOS version of my App with Dropbox V2 API is waiting for review, weâll see if they pass muster. But I still cannot archive the macOS version for review. Should I perchance try to build a static library. I ask because I continue to see confusion when it comes to resolving the real path of the dynamic library: DBRoulette and my App sometimes both get involved during the link processes.A) I have what may be an important clue, but I do not know what itâs telling me, yet - hopefully an Engineer does. I can get DBRoulette to fail with the same dynlib error as my macOS app. Iâm using the DBRoulette example on github which I downloaded 2-ish weeks ago, dropbox-sdk-obj-c-master/Examples/DBRoulette/macOS/CarthageProject/DBRoulette/DBRoulette.xcodeproj.To run the DBRoulette example one needs to configure the project per README.md, specifically, the Info.plist needs an App Dropbox key. The key is part of the App Record, so itâs associated with the Appâs name, in this case Krypton. On my Mac Book Pro the DBRoulette example links to Dropbox via Kryptonâs App key and I can see files on the Dropbox servers, but if-and-only-if there is no occurrence of the real Krypton App on the computer.If I have even one instance of Krypton.app, the DBRoulette link will (often) fail; here is the sequence:1) previously compile Krypton with the Dropbox V2 API such that the executable is lying around somewhere. It doesnât seem to matter where, as long as there is an instance of the Dropbox V2 dynamic library somewhere, whether it be in an exported archive of the App, or buried deep in the Xcode build file hierarchy from a debug test run.2) From Xcode run DBRoulette, and click the Link button.3) This starts the Safari authentication process - Click Allow.4) This brings up what appears to be a JavaScript Alert panel saying â Do you want to allow this page to open âDBRoulette.appâ? â - click Allow. Normally thatâs it, your are linked. But not in this case. Instead, Krypton is recalled instead of DBroulette, and the link error occurs.B) Or, the reverse might happen: I run Krypton in the debugger, begin the link process, and DBRoulette is recalled instead of Krypton. I have no idea why this happens, see pix below showing Krypton running but DBRoulette intercepting the link request.DB asking to link Krypton, but DBRoulette recalled.
- FWIW, the iOS version of my App just passed review and is on the App Store. One down, one to go. Thanks for all your help so far.
Another update:
The macOS version of my App is waiting for review, but I still have reservations about the Dropbox V2 API OSX authentication scheme. To get this more-or-less working version I spent many hours spread over many days trying lots of things. In particular I built a static library, and even though ar showed that all the modules and entry points existed, my App still crashed because DBClientsManager:setupWithAppKeyDesktop couldnât be found. Go figure.In desperation I built a new project from scratch and put my code in bit by bit ⌠I never ran into the dyld error and mis-signed framework, but âŚ.The link mechanism is still, er, odd. If there is another instance of any App that uses my DB key then itâs likely to get loaded (ârecalledâ per my previous post) during authentication after confirming the JavaScriot dialog. This means that there are then *two* instances my App running - you can see them in the Dock - but neither gets authorized. This happens most of the time, but not all the time !! In order to get a working exported macOS test App I must do a project clean to delete the Xcode-generated executable and also delete the archive that I just built because there is an executable buried in that package. Why I get gray :)Goodness! After one hour waiting for review, and one hour under review, the macOS version of the App is on the Store. 2 hours is a new record for me. The average user will only have 1 copy of the App on their machine so authentication should work normally.
I think I'll go check that box indicating that I know about the 28 June retirement date of API V1, and then get some sleep.
About Dropbox API Support and Feedback
Get help with the Dropbox API from fellow developers and experts.
