Simperium iOS: Issues with data retention when switching accounts or signing in to existing account -

in 1 of simperium powered apps, i'm trying implement clean experience users when signing out sync account, signing in sync account existing data, switching accounts etc.

what want achieve following (suggestions welcome, if doesn't make sense):

• when signing out of sync account, don't want delete locally, user can continue using data (which important because syncing premium feature , user might cancel it).
• when creating new sync account (which doesn't contain data), want retain local data , sync new account (which makes sense if starts using app without sync , activates sync later).
• however, when signing in existing sync account existing data, need prevent merging hell between local , remote data (imagine switching accounts!). think overwriting local data remote data makes sense here.

simperium not seem directly support approach, rather offers delete data upon sign out. while trying bend simperium needs, i'm facing 2 issues/questions:

1. what preferred way delete local data (including simperium meta data, including in user defaults)? nb: need while user not logged in simperium, can't use signoutandremovelocaldata:yes. guess need [self.buckets.allvalues makeobjectsperformselector:@selector(deleteallobjects)]; (which done in sign out completion handler), can't find public interface this. save delete objects directly via coredata, or leave in user defaults cause issues later, example?

2. i noticed simperium leaves ghost data intact after signing out. causes massive issues when signing in (in case new) account, because doesn't treat objects new objects synced up, rather deletes local objects (presumably because can't find on remote)!

   • is intended behavior? i'd expect simperium rid of sync metadata after signing out, if data not removed. more in case of ghost data, because data tied directly sync account - represents remote state of object, , i'd argue after signing out there no remote state anymore (because there no "remote").
   • anyways, what's best way me reset ghost data initial clean state (that is, { "key" : "...", "version" : "0" })? manually, feels massively interfering internals of simperium.

sorry lengthy question.. help/pointers appreciated, thanks!

---

update/clarification

my goal not carry data on 1 account another. actually, said, plan delete local data before signing exising account, should prevent problems duplicates - client discards local state , uses whatever stored in remote sync account. case retained ghost data causes me problems this:

1. app syncing account a.
2. user signs out account (using signoutandremovelocaldata:no completion:).
3. user happily continues use app (perhaps quite while)
4. user creates new sync account b (that is, 1 not contain data on server). now, default behavior, simperium delete local objects contain ghost data version > 0 (but leave objects have been created while not signed in sync account, leaving database in potentially invalid state broken relationships etc.).

i don't think behavior user expect , i'm sure lead many support inqueries...

my authentication flow looks suggested: have own backend manages subscriptions , generates auth token via simperium auth api , sends client. don't see how solves problems. agree it's not common use case users switch sync accounts (although situation bit different mail accounts, because can use without sync), , don't want encourage users that. problem that, if it's happens rarely, should not break app. , don't know how prevent users doing it, because can freely decide signout , sign up/in again.

what behavior suggest ensure ux? delete local data upon sign out?

by design, simperium isn't meant carry data on account a account b. imagine mail client, upload inbox upon 'signout + sign different account'.

the preferred way reset internal metadata is, pointed out, signoutandremovelocaldata selector. however, spmanagedobject's simperiumkey , ghostdata left intact. big reason we've got not nuking 2 fields that, if sign same account again, wouldn't duplicate entities (the lib know it's same object).

implementing mechanism reset spmanagedobject's simperium metadata fields potential bad idea, reason. nevertheless, if wanted test out, loop through entities reset, nuke fields, , call selector, change disregarded lib itself.

furthermore, if wanted sign different account, duplicate entities issues (that is, assuming second account has objects uploaded).

i'd suggest potential flow scenario:

1. on launch, app can hit this initializer, core data stack ready work.

2. once users ready enable sync'ing, either use this method trigger ios interface, or implement api on own backend, wrap simperium user authentication.

   this helper api return authtoken, used ios client hit method.

3. if had disable sync'ing, whatever reason, either:

   a. stop hitting 'authenticate' method, or

   b. toggle this flag, needed.

assuming ios app has user authentication flow, wrapping in own backend simperium auth call great idea, because crystal clear sync'ing feature 100% tied own account.

i'm afraid carry'ing on data 'account a' 'account b', although technically possible, sounds bad idea. of now, supported mechanism prevent duplicates relies on having same simperiumkey locally , remotely. , (as far understand), assumption won't true in scenarios.

hope helps!

jorge