AskarWallet: Incorrect key for wallet 'walletId' error after onboarding

[knguyenBC]

Description of problem

While going through onboarding on an installation of the BC Wallet app via the iPhone's "import your old phone to your new one" process. An error appears, screenshot below.

Expected behavior

after onboarding, the app should successfully open to the home/notification screen

Steps to reproduce

• transfer apps to new device
• open the bc wallet app
• go through onboarding

Screenshots and/or log output

Environment

• [ ] Occurs on Android
• [x] Occurs on iOS

Build #: 1.0.16

Android Device Model:

iOS Device Model: iPhone 15

Workaround

Uninstall and reinstall the app.

Severity

• [ ] High
• [ ] Medium
• [ ] Low

[cvarjao]

Is there a way to mark iOS apps are not transferable?

https://developer.apple.com/documentation/cloudkit/deciding_whether_cloudkit_is_right_for_your_app?language=objc

[jleach]

Mark Nonpurgeable Data as Excludable

[knguyenBC]

@jeznorth I tested this and it's still an issue but then realized that this ticket was just a spike. If this is just a spike, should it still be in QA?

[jleach]

Developer builds are not backed up so the only way I can see what might/works is to get it installed via TestFlight so my trial and error is kind of a normal fix so... 🤷

[bryce-mcmath]

Looks like Kim tested and it's still an issue, moving back to Ready, unless anyone has objections.

[jleach]

Read the docs a bit harder. Looks like the isExcludedFromBackup = true property is only a suggestion to the OS, not a guaranteed mechanism to exclude the path:

The isExcludedFromBackup resource value exists only to provide guidance to the system about which files and directories it can
exclude; it’s not a mechanism to guarantee those items never appear in a backup or on a restored device.

We may need to come up with our own mechanism to mange this. If marking a file as excluded from backup is not guaranteed and the "caches" directory can be purged then we don't have many OS based options:

Note that the system may delete the Caches/ directory to free up disk space, so your app must be
able to re-create or download these files as needed

[jleach]

I think Androids guide are probably a reasonable gold standard that also capture the spirit of Apples sentiment on UUIDs. In summary,

Use a Firebase installation ID (FID) or a privately stored GUID whenever possible for all other use cases,
except for payment fraud prevention and telephony. For the vast majority of non-ads use cases, an
FID or GUID should be sufficient.

Since we use Firebase we could abstract it away behind a function that provides an installation ID that will change on every install of the app. This can be used as the wallet ID. For backwards compatibility we could look to either rename or change an existing wallet ID or just use the existing wallet ID as the installation ID if the wallet ID is already set.

NOTE: We include Firebase at the OS level not via an NPM package so maybe installing the firebase NPM package will be an issue?