Auto-reuse existing installation object when migrating from ObjC SDK

[mtrezza]

New Issue Checklist

• I am not disclosing a vulnerability.
• I am not just asking a question.
• I have searched through existing issues.
• I can reproduce the issue with the latest versions of Parse Server and the Parse Swift SDK.

Issue Description

After migrating an app to the Parse Swift SDK, launching the app will create a new _Installation object with a new installationId. It will appear as if the app had been uninstalled and then reinstalled, even though it only changed the Parse SDK. See migration guide/known issues.

An SDK change should not create a new installation, because it is not a new but existing installation. This bug also could make it difficult for developers to migrate from the Parse ObjC SDK, as data that is stored in the original installation object and any references to that installation object need to be migrated.

Steps to reproduce

n/a

Actual Outcome

A new installation object is created.

Expected Outcome

Any existing installation object should be used as the current installation.

Environment

Client

• Parse Swift SDK version: 4.14.2

[parse-github-assistant]

Thanks for opening this issue!

• 🚀 You can help us to fix this issue faster by opening a pull request with a failing test. See our Contribution Guide for how to make a pull request, or read our New Contributor's Guide if this is your first time contributing.

[cbaker6]

Those developers seeing this issue should note that this is not true and is not a bug. If you really want to migrate from the Objective-C SDK to the Swift SDK, see the convo, sample app, and a developer who successfully migrated here and #407.

Since I’ve already solved this problem, I will not be spending any additional time on Objective-C SDK migration, so those looking for a better way will need to depend on someone else to provide a different solution which will provide a feature to make it easier than it already is (it’s already easy).

[mtrezza]

I've opened this issue because it's still in the migration guide.
What is the status of this issue, so we can update the guide?

• resolved (no additional steps necessary for developer to avoid a new installation being created)
• open with workaround (creating of new installation can be avoided with additional code by developer in app)
• open without workaround

a developer who successfully migrated here and #407.

We want to be mindful about developer experience and provide migration support via the migration guide. A forum thread and a PR are not conveniently accessible resources so I'm hoping we can better document that for developers.

[mtrezza]

I've searched for instructions how to migrate the installation:

let objcInstallation = PFInstallation.current()!
let swiftInstallation = try await Installation.become(objcInstallation.objectId!)

It seems to expect that the Parse ObjC SDK is installed in parallel to the Parse Swift SDK, is that correct? And if yes, is that even recommended and tested or could they interfere with each other?

[cbaker6]

It seems to expect that the Parse ObjC SDK is installed in parallel to the Parse Swift SDK, is that correct?

The description of #407 (comment) states:

Adding a method like this allows developers to use their own ways to get a particular objectId and use it to migrate to the Swift SDK.

So it doesn't matter if a developer has both SDK's in their app or if they have saved the objectId for their installation somewhere else.

is that even recommended and tested or could they interfere with each other?

Why would they interfere with each other? These are two different SDK's and the only thing they have in common is transmitting data to/from a Parse Server. The probability of these SDK's interfering with each other is the same as using any other two frameworks in the same project. The sample app linked imports and configures the SDK's in the same file. The sample app even uses ParseUser, PFUser, ParseInstallation, and PFInstallation in the same file. Any conflicts between the SDK's will be those created by the developer from within their own app.

[mtrezza]

Thanks for confirming that there is no interference. These answers may seem obvious to you, but these are questions that developers may have when migrating. I will add that to the migration guide.

it doesn't matter if a developer has both SDK's in their app or if they have saved the objectId for their installation somewhere else

It sounds like we have no easy approach? Having both SDKs in the project certainly looks odd and is not ideal from a resource standpoint. Storing the objectId somewhere else again requires an app update to be adopted as the basis for migration, also not ideal. Theoretically the method exists to migrate the installation, but practically one SDK cannot be replaced with the other. With both approaches it seems to require a long-term migration over months or years.

[mtrezza]

I don't mind changing this to "feature", we just need to track the issue.