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...
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.
