Objective-C SDK crash

Thanks for the report! To make sure I can reproduce the exact issue you're seeing, can you share the code snippet you're running that triggers this, and indicate on which line in particular it happens?

Also, you mentioned you installed the SDK "by manually copying all the classes". Are you referring to the "Manually add subproject" installation method? If not, the SDK may not be installed correctly. We only officially support the installation methods listed here. If you're not using one of those, please switch to one of them.

And, you mentioned you're using commit 500. We recommend only installing a particular release version though, not a particular commit version, e.g., from master. The latest release version is v5.0.4. Please try installing v5.0.4 via an officially supported installation method and let me know if the issue issue still occurs.

Hi Greg,

thank you for your answer. Yes, I installed the latest release (version v5.0.4). I installed it manually by following the steps of the pod file, so it shouldn't be an installation problem. Infact, as said with the previous message, the crash only occurs just after my app is called back after the authorization flow. If I run again the app there are no crashes and the app is correctly linked to Dropbox. 

The exact line that triggers the crash is the line 43 of the class DBTransportBaseClient : this is the first line in which the parameter "transportConfig" is used, and the crash occurs because at runtime the parameter is of a different class, not the "DBTransportBaseConfig" one, and so it crashes because the instance doesn't have an "appKey" method.

Hope this helps.

    Mario

Thanks for following up. First, when you say you "installed it manually by following the steps of the pod file", do you mean you followed the "CocoaPods" installation method instructions in particular?

Also, I understand you saw the issue occur in DBTransportBaseClient, but it would be helpful to know what code you were running yourself, and on which line of that the issue occurred. For instance, you said it "occurs just after my app is called back after the authorization flow", so it sounds like it's occurring during the "Handle redirect back into SDK" step. Is that correct? For example, is it occurring when your app calls "handleRedirectURL", or something else? Please share the relevant code you're running (not in the Dropbox SDK itself) for reference.

These additional details for how to replicate your scenario would be useful, since this issue doesn't reproduce for me. I've installed the official Dropbox Objective-C SDK v5.0.4 using CocoaPods into a project, set up the authorization flow as documented, and run the project using Xcode 12.3 on a device running iOS 14.2, and it doesn't crash for me.

Yes, I installed it by manually following the steps of the pod file of the "CocoaPods" installation method.

Yes, the crash occurs during the "handle redirect back into SDK". The code I use for managing the redirect is the following (it is a method of the app delegate):

- (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary<UIApplicationOpenURLOptionsKey, id> *)options {
    DBOAuthCompletion completion = ^(DBOAuthResult *authResult) {
        if (authResult != nil) {
            if ([authResult isSuccess]) {
                // update the flag
                self.automaticallyUpdateDropboxInfo = YES;
            }
            else if ([authResult isCancel]) {
                // log
                // ...
            }
            else if ([authResult isError]) {
                // log
                // ...
            }
        }
    };
    BOOL canHandle = [DBClientsManager handleRedirectURL:url completion:completion];
    return canHandle;
}

I also add the code I use to begin the authorization flow. I don't think it is the problem, but who knows... The code is the following:

- (void)linkUser {
    DBScopeRequest *scopeRequest = [[DBScopeRequest alloc] initWithScopeType:DBScopeTypeUser
                                                                      scopes:@[@"account_info.read",
                                                                               @"files.metadata.read",
                                                                               @"files.metadata.write",
                                                                               @"files.content.read",
                                                                               @"files.content.write"]
                                                        includeGrantedScopes:NO];
    [DBClientsManager authorizeFromControllerV2:[UIApplication sharedApplication]
                                     controller:[self getRootViewController]
                          loadingStatusDelegate:nil
                                        openURL:^(NSURL *url) {
                                                      [[UIApplication sharedApplication] openURL:url
                                                            options:[NSDictionary dictionary] completionHandler:nil];
                                                }
                                   scopeRequest:scopeRequest];
}

Please help, I am stuck on this since a week... Thank you very much,

    Mario

PS: I have installed the Dropbox app into my device, and I am logged into it. So the official Dropbox app takes part to the authentication flow.

Hope this helps,

    Mario

Thanks! This all looks correct. I also just tried copying these snippets into my own sample project here though to be sure, but I still can't reproduce the issue. (And I also have the official Dropbox iOS app installed, handling the app authorization flow.) 

Also, just to confirm, you're calling DBClientsManager setupWithAppKey in didFinishLaunchingWithOptions, right?

It's unclear why this would be occurring, as these unexpected classes (NSSQLiteStatementCache, NSContentSizeLayoutConstraint, and UICTFontDescriptor) seem to be from system frameworks (such as Core Data and Foundation). The Dropbox Objective-C SDK doesn't reference these classes at all.

A few more things to try to narrow this down:

• Is this reliably reproducible for you, or does it only happen on random attempts?
• Have you tried this on multiple devices? Have you tried it in the simulator?
• Have you tried completely uninstalling and reinstalling the Dropbox SDK?
• Do you have any non-standard  project settings? Does this also occur for you if you set it up in a new project?

Thank you very much, Greg.

In the following days I'll try all the things you suggested. And I'll let you know.

Thank you again,

    Mario

Hi Greg, some updates:

- Now it works: to fix the problem I completely uninstalled the Dropbox SDK and reinstalled it with Cocoapods. Nothing else worked.

- I am calling DBClientsManager.setupWithAppKey in app delegate "applicationDidBecomeActive:", but this shouldn't be a problem.

- The crash was 100% reproducible. I tried it on multiple devices, iPhones and iPads, and it crashed every time.

Thank you very much for your help :-)

    Mario

Another question: if I update the configuration of my production app to use scopes and short-lived tokens, what happens to users who never update the app? Will they be able to connect the app to Dropbox in following weeks, or they will get an error? And what will happen after September 30, 2021? 

Thank you,

    Mario

Any users using old versions of your app will continue to be able to use it without issue for now. Once you switch the  "Access token expiration" setting for your app on the App Console to "Short-lived", or on September 30, 2021, whichever comes first, users using old versions of your app should still be able to use it, but they'll start receiving short-lived access tokens when they process the app authorization flow, instead of long-lived access tokens. Short-lived access tokens only last for four hours, at which point further API calls will fail, and the app will receive an DBAUTHAuthError (like it would currently if the user unlinks the app from their account). Exactly how your app handles that error depends on how you've programmed it. E.g., it may prompt the user to re-authorize the app.