So what's the deal about the 17.2 rule and requiring users to register ?

Are you making the second app for the sole purpose of harvesting emails/personal information?

>Now, I'm currently working on an app that will require users to register & authenticate themselves by asking for their email, and I fear that I will encounter the same issue with the App Review team ; only this time, my service won't be accessible via a website, so the aforementioned argument will not stand.

Seems you've answered your own question, then.

The key word in 17.2 is 'require'. Just make the app do something, anything and, in addition to that anything give the user the chance to use the full app by registering using whatever personal infomration you wish to demand. Then you are not 'requiring' the personal information.

But a better design is to generate your own identifier and store that identifier either in the keychain (for a device by device system) or in the users key-value file in iCloud (for an iCloud Account by iCloud Account system). Just grab any random number (or use the identifierForVendor) and stick it up there in iCloud and use that to identify the user on your website. That way you can log in in the background without asking the user for anything.

Thanks for your reply !

"The key word in 17.2 is 'require'. Just make the app do something, anything and, in addition to that anything give the user the chance to use the full app by registering using whatever personal infomration you wish to demand. Then you are not 'requiring' the personal information."

I thought so too. Sadly, that doesn't get me very far, since my app wouldn't be able to provide many features while the user is logged out, except for a quick tutorial and a registration process... but I'll try to come up with something if that's the only way.

"But a better design is to generate your own identifier and store that identifier either in the keychain (for a device by device system) or in the users key-value file in iCloud (for an iCloud Account by iCloud Account system). Just grab any random number (or use the identifierForVendor) and stick it up there in iCloud and use that to identify the user on your website. That way you can log in in the background without asking the user for anything."

Thank you for your ideas, but I'm afraid relying on iCloud keychain or iCloud shared preferences wouldn't work in 100% of the cases, since users can opt-out of iCloud. I'm pretty sure I've already seen some cases of app rejections because the apps relied solely on CloudKit, which is only available to users logged into iCloud, and not functioning for the users who opt-out is cause for rejection.

identifierForVendor might work, but I'm pretty sure that this identifier can change over time, and that users are able to reset it in the device privacy settings. I might be wrong there too.

You can require a login; you just can't require it to be personal information such as an email address without good reason. If the user can register by entering their own username that they make up, you're good.

It seems that the best solution would be whatever doesn't give the reviewer any reason to even consider rejection. Instead of thinking up ways to get around the rule, what would you do if it were actually impossible (or illegal) to get the email address?

I think I'll end up going with this approach. A bit of a pity that by design, this doesn't allow a user to recover his username or reset his password.

Thanks for your reply !

"It seems that the best solution would be whatever doesn't give the reviewer any reason to even consider rejection."

Couldn't agree more actually.

"Instead of thinking up ways to get around the rule, what would you do if it were actually impossible (or illegal) to get the email address?"

I'm not trying to get around the rules, I'd just like to know what differentiates an app that can ask a user for his email address, and a one that can't, to see where my app lands. I'll go the safe way and change my auth system for a basic username/password combination instead of an email/password one, thanks for your reply.

You can ask. You can't require. You can encourage users to enter their email address by explaining that it would allow password recovery, but as long as you give them the option of using something else, I think it's OK with app review. (Disclaimer: from what I've read here over the years. None of my apps require login so I don't have personal experience in this matter.)

This is actually a great idea, and yes, that shouldn't be a concern for App Review.

I doubt many users will go through the pain of providing a username AND an email address, but at least, it'll be there for those who want it.

Thanks a lot !

> "The key word in 17.2 is 'require'. Just make the app do something, anything.........

> my app wouldn't be able to provide many features while the user is logged out, except for a quick tutorial and a registration process...

I suspect that (the quick tutorial) would work for App Review to get you past 17.2 although wouldn't it be nicer to log in in the background and not need a username/password? That can be done with a random number saved to iCloud (not CloudKit) and Apple allows you to rely on iCloud access for other requirements (like copying non-renewing subscriptions).