I have an iOS app in production, back by Kinvey that requires registration to use. I am interested in exposing some of the functionality without requiring registration. I understand the [KSCUser activeUser] pretty well but would like a general direction to head in for implementing lazy registration. My thoughts for architectural options thus far are as follows:

1) Use an implicit user, then modify it later when I need to collect uname, pword, fname, etc.

2) Create a temp (named) active user, then change its properties later

3) Don't even bother with the Kinvey user concept at all, until I actually need them to register. Just present the app and limited functionality, then get the user details when I need them. ( Check by if ([KCSUser activeUser] ) { //do cool stuff} )



Much appreciated if I could get some advice on a direction to head in. I am not even sure if any of the three options are possible. Thanks in advance

#3 is a best practice, especially from an app store standpoint. Give the user as much functionality as you can before asking them for info. If you have global data you want to access, and don't mind leaking access you can create a global "initial user". If you want to progressively add info, then #1 is a good way to go, so you are still just creating one user. You just have to be careful around making sure username, password, and email are properly set to make sure that future logins and password resets work appropriately.

@Michael - Good deal. I like number 3. So let's say my app launches and there is fun stuff to do without registration. Then they tap on something and I prompt for registration. At that point can I just call the [KCSUser userWithUsername...] method? Or is there an object in [KCSUser activeUser] I should modify? Thanks!

Should just have to do userWithUsername. There should be no active user until you create one or login one in (or previously ran the app with an active user)