[persona]

This seems to be a common problem, made more visible when using third-party authentication, that your application has taken the concepts of "Account" and "Authentication Method" as if they were the same thing.

It appears that the "account ID", "preferred contact method+address" and "authentication ID" are all the same here - which then creates the "account management code into a rat’s nest" scenario they describe in the post.

If an Account is, by design, it's own entity - you should be able to have 100 different authentication methods linked to that same account without impacting any other flow or part of the application.

Turn on and off authentication methods would also allow for seamless transition for users, without worrying about when one method is about to be killed.

[dahfizz]

I feel like they address this in the article. What you say makes sense in a technical UML diagram point of view, but that's not how people work.

The examples they give are getting support and sharing things with another person with an account. As a user, both of those things are easier for me if there is an email associated with the account.

Said another way, the Account needs some human friendly global identifier. The email you use to log in is an obvious choice, and anything else would require extra work from the user to set up. You could have usernames, for example, but that complicates the signup process and still makes sharing things hard. I know my friends emails already, but I don't know what username they ended up with on this site.

[persona]

I'd argue that this makes more sense in the real world than in a diagram, after being burnt in multiple real life experiences :)

The assumption both you and AnyList are making is that an email is "THE obvious choice". From a user experience perspective perhaps this "global sharing identifier" should be defined by them.

You'll notice that different generations have different online behaviors. For some, email is their main id. For others, it's their phone number (they don't know most of their friends' e-mail, but know their phone). For others, it's either online handles or nothing at all - think about the device set up for grandma with her daily To Do list.

Of course, having this approach would add some upfront dev work to them but allow them to navigate this much easier later on. And for anyone starting to develop their new app/site/product thinking about this early on can reduce a lot of future headaches.

[JAlexoid]

That's a very idealistic opinion.

People don't care about usernames and other crap. They want an easy option - enter email, communicate over email and be found using email. This isn't their banking app or anything that important.

[filleduchaos]

Nobody "wants to use their email". They just want to start using whatever app or service they're trying to connect to as quickly as possible - why exactly do you think "Sign in with X" became so popular in the first place?

[dukoid]

+1 Any authentication method that I have enabled for my email should work -- there shouldn't be a need to remember which one is associated with a particular service...

[nikitaga]

With rare specialized exceptions, pretty much nobody needs all this complexity. Certainly not a simple app like AnyList. All this flexibility is not free, it comes at the cost of obviousness, as they described. It's not worth it much of the time.

The real problem is Apple shoving their proprietary, poorly designed services down everyone's throats.

No, I don't want to use icloud email, I already have an email address. No, I don't want to provide a "real" email address after I provided an obfuscated one. No it's not my fault that messages sent to the obfuscated one will go to some icloud inbox that I didn't create and I don't read. No, it's also not my fault that when I contact support I do it from my normal email address and not from the obfuscated one (how would I even do that). It's not the support's fault that they can't connect the two.

It's not the user's fault, and it's not the developer's fault. Apple is the sole designer of this mess. There is no excuse.

[dev_tty01]

You can create an iCloud account with your own email address. That avoids getting another email address.

When using Apple login, Apple offers the choice of providing an anonymous email to the third party or your actual email. It's up to you. Its about user choice. More privacy or less. Apple wants you to have a choice. Use it or not.

[nikitaga]

Then why do most of my non-tech relatives have an @icloud.com address that they never needed and never read?

Blame the user all you want, but their "choice" was guided by Apple designed UI and Apple provided defaults. Whatever it is, it's producing optimal outcomes for Apple and no one else.

[fnordsensei]

I have one too (which I've since swapped for an email I actually use). I'm not one hundred percent sure, but I think it was the only option for a while (inherited from MobileMe, perhaps), or at least it wasn't clear that you could/should add another email.

Either way, Apple could definitely do something with regards to make it easier/more obvious to replace it with a useful email address, especially now as it becomes a federated identity provider.

[dev_tty01]

I can't answer that. However, if you go to appleid.apple.com to create a new AppleID, you must use an existing email address.

When I create a new user account on the mac, it asks the new user if they want to create an AppleID. The default is to use their existing email address. You must specifically select an option to get an iCloud account. If you purchase an Apple device, you again have the option of an iCloud account or using your existing email address for your AppleID. Apple is not using some deceptive UI to get you to create an iCloud email address.

However, I guess you still feel it is somehow evil that Apple does allow you to get a free email account where the provider does NOT read your email content and use it to target ads at you. Suboptimal for Apple from a pure profit perspective.

[nikitaga]

Whatever the UI is now, doesn't speak for what it used to be over the years. The cumulative effect matters.

There are tons of people with @icloud.com email addresses that they never use who will fall into the login / customer support traps described in the article.

But sure let's not even acknowledge those very real problems, deny Apple's role in this, and blame users. That will surely solve the issues.

[dev_tty01]

I think you are missing the point and are perhaps letting this app vendor create an impression of a large problem based on anecdotal evidence. Perhaps they are just whining because they don't want to lose all that data. I have no idea that that is the case, but we can't rule it out.

Tons of people falling into these alleged traps? Really? What is that based on?

Apple is saying they want their platform to support personal privacy. If an app on their platform offers third party sign-ons that are known to abuse personal privacy, that app must offer Apple's solution that respects personal privacy. Despite it being an imperfect solution, I personally am thrilled that I have that option and I'm happy with Apple taking a stand on one of the most important issues today and going forward.

Some occasional customer support issues vs. providing customers with a real solution to significant privacy issues. From a user perspective the value of having such a choice is high.

Nobody is blaming users. Frankly, I think users are smarter than we typically assume. The support situation is really pretty trivial. If you save the onboarding email sent to the anonymized email address, you've got all you need to interact with an app customer support. People will quickly learn this and get on board if they want the privacy benefit. Its just not a big deal.

Apple's role is about increasing privacy and respecting their user's right to privacy. I fully acknowledge that. Does this create some hassle for app vendors? Yes, but I don't care about that in relation to the greater gain.

[mr_toad]

I don’t see any technical reason this couldn’t be done, but it would be more work for both the app developers and the user.

[JAlexoid]

Time and value are not "technical", though they can be measured.

Technically you can build an app that's purely a AR sticky notes specifically on your fridge... but the value of that app is approximately 0.

[gitgud]

I think the problem is that many apps, use the same form for login/signup. So a user thinks they're logging in, but they're actually creating a new account with a new authentication method...