How to transition from the old Parse framework

Hello!
As the title says, how do I make the transition from the old Parse framework to Parse Swift seamlessly (Authentication wise)?
As of now, the only way I see possible is force users to re-login and is not really a viable solution, since we have a lot of users. Is there any way to either link the old user with a Parse Swift one?

There’s currently no conversion from PFUser (objective-c SDK) to ParseUser (Swift SDK) in the Keychain as well as most of PFInstallation. The Swift SDK can get installationId from the Objective-C SDK. If you or someone else would like to build this feature feel free to have the discussion and eventually open a PR.

A number of developers have switched to the Swift SDK. Maybe they can chime in with how they converted over and if they created custom solutions.

1 Like

Given the fact that legacy Objective-C SDK is not actively maintained and is only accumulating problems over time, it may be really a good time to start thinking how to provide seamless transition into the Swift based SDK.

I am one of the guys still actively shipping apps with Objective-C SDK, now with a custom Swift Package Manager support built into my forked copy (https://github.com/mman/Parse-SDK-iOS-OSX/tree/spm). But in order to keep the build clean I am simply removing broken features from the SDK instead of fixing them properly - and I’d love to switch to Swift SDK, but until the migration path is clean for already signed in users this will not be possible…

So it will be a good story for Swift SDK to provide clean migration path. I will be happy to help from September!

Martin

I’ve opened a PR that will allow developers to login their users using the sessionToken from the Objective-C SDK. The added methods will retrieve the sessionToken automatically from the Objective-C SDK Keychain:

Depending how a developer implements the added methods into their app, the migration can happen without requiring the user to input or change anything assuming an internet connection is available.

I think what developers are mostly looking for is a single, clear step-by-step migration instruction article.

The article should contain:

  1. Clarify the future plans regarding the ObjC SDK (i.e. deprecation); explain why we are currently proving two Parse SDKs for the same ecosystem and why migration should be done
  2. Which benefits are there when migrating to the Swift SDK, i.e. some marketing to encourage migration
  3. Which caveats are there when using the Swift SDK, e.g. not feature but performance related
  4. Which features are available in the ObjC SDK but unavailable in the Swift SDK, i.e. the developer is required to code around a non-Parse API to achieve the same functionality; with code examples for how to achieve the same functionality; a simple SDK feature comparison table would be very useful
  5. Which features work out-of-the-box in the ObjC SDK but require a manual workaround / coding / setup in the Swift SDK; with detailed code examples on how to duplicate a default implement of the existing functionality in ObjC SDK

Hopefully you find people to work on the tasks you’ve listed. In addition, maybe you can get them to also work on a “Firebase to ParseSwift” article, similar to:

https://firebase.google.com/support/guides/parse-ios

Along with:

These are challenges and questions developers face when migrating, so maybe we can encourage people who are asking for migration advice (and the people who provide it) to add some bits to these instructions.

I just took a look at the Swift SDK docs (which just link to README) and couldn’t find any section about migration.

You may have the best overview of what GitHub issues / forum threads there are already regarding that topic. What we can use as a basis?

I’ve started an a migration guide in https://github.com/parse-community/Parse-Swift/pull/392. The purpose is to publish it in an early (explicitly incomplete) version ASAP to make the document available for others to contribute.

@danipralea @enodev released some features that should help in the latest version:

When migrating the user from objC I am getting the following error:

ParseError code=-1 error=Could not find a session token in the Parse Objective-C SDK Keychain.

Code should be pretty straightforward?

User.loginUsingObjCKeychain(completion: { result in
                                print(result)
                            })

Any tips on troubleshooting this?

Most likely a bug in the Swift SDK as I never tried to migrate a real Objc Keychain before. I simply looked at the code. I haven’t used that SDK in years… Attempt to set a breakpoint here:

Print out the info in your console log, does it show real data? If so, what do the keys look like? If you post the data (omitting the actual sessionToken and private data) it will help to understand the structure of Obj-C Keychain.

Printing the objcParseKeychain doesn’t give helpful info. I don’t know how to print the keys?

Printing description of objcParseKeychain:
▿ Optional
▿ some : KeychainStore
- synchronizationQueue : <OS_dispatch_queue_concurrent: com.dave.BackcountrySkiReporter.com.parse.sdk.keychain[0x280bef680] = { xref = 13, ref = 1, sref = 1, target = com.apple.root.default-qos[0x107dd92c0], width = 0xffe, state = 0x0000041000000000, in-flight = 0}>
- service : “com.dave.BackcountrySkiReporter.com.parse.sdk”

Are you running your Swift SDK in the exact same app and device you were logged in with the Objective-C SDK? If not, you are using a different device, you need to use the other login methods.

If you are using the same app and device, you can try to debug the Objective-C version of your app, find the Keychain code, and compare the difference in the Swift SDK Keychain. Note, you or someone who has an app using the Obj-C SDK will need to do this as I don’t use that SDK anymore.

Worst case is you can login with the user credentials in the Swift SDK.

Yes I am using the same app and device. Here’s a screenshot of the objC code. I tried to update the swift package to reflect this but couldn’t get it to work. My understanding of keychain is rudimentary at best.

I opened a new PR which should address your issue:

I suspect you will still have an issue with PFInstallation if used it in your Objective-C SDK based app. This is because the Objective-C SDK appears to save the installationId to disk as oppose to Keychain. If you did the information from PFInstallation, I recommend using the new one that the Swift SDK generates, query for all ParseInstallation's related to the current user, copy the deviceToken, channels, and any custom keys from the newest installation that used the Objective-C SDK to the ParseInstallation.current, save the current, then delete the old Objective-C Installations.

This is similar to what I had tried. Using this commit still not finding a value for “currrentUser” key.

The merged updates in PR 407 fixes the problem. If you need help with using the new methods, see my sample app:

When migrating the installation, you should use the Objective-C PFInstallation.current().objectId and Parse-Swift ParseInstallation.become():

Most of the example logic is in ContentViewModel.swift

Unfortunately the “currentUser” key is coming up empty for me as well when migrating. Hopefully someone else who is able to successfully migrate can offer some insight.

I recommend checking to see if you are using the last commit from the PR. The updates are released in 4.12.0, so just use the latest release:

If 4.12.0 doesn’t work, maybe you weren’t logged on in the Objective-SDK on your testing device or you changed something that modified the Keychain. You can also try the sample app I linked in the previous comment to verify. The sample app uses both SDKs and migrating PFUser->ParseUser and PFInstallation->ParseInstallation works as expected as User.loginUsingObjCKeychain() is the only way the app is logging into the Swift SDK:

Screen shots below:

Before Migration and Logging into Objective-C SDK

After Logging into Objective-C SDK and Migrating

Yes the latest release works! Thank you so much for all your work on this.

1 Like