In my experience, this almost always happens when a web developer makes a native application. They ignore the platform conventions and interface guidelines and design it as if it’s a web application instead of designing a native application. So there’s a sign-up process because that’s the way it’s normally done for web applications.
The relevant part of Apple’s Human Interface Guidelines:
> Delay sign-in as long as possible. People often abandon apps when they're forced to sign in before doing anything useful. Give them a chance to fall in love with your app before making a commitment to it.
— https://developer.apple.com/design/human-interface-guideline...
Please, if you’re building a native application, actually build a native application not a web application. Native applications run in different contexts with different constraints, you can’t just assume that what works well or is necessary for a web application makes sense for a native application. In particular, dumping new users into a registration screen just because you want to persist state is bad design for most native applications. Native applications don’t need that in the same way web applications do.
If you need to support remove users, then provide an "invite link" that you can text and it lets people download the app and then connect with you on the app. You don't need an account on a server for that.
To make money:
1. Show an affiliate link to watch the movie on Redbox [0] or another pay-per-view streaming service.
1. Show local theater showtimes with an affiliate link to buy the tickets [1].
Otherwise modern day Web Browsing on Smartphone is mentally incompatible with Apps usage.
When you have the web page / web application open, press the action button, then select Add to Home Screen.
Its also so that you can lookup and add your friends.
I understand the frustration, though. I'm working on a version with webhooks where you can just join a lobby and start swiping.
> Its also so that you can lookup and add your friends.
Right, but what about that requires me to type in three magic strings into three (wait, actually probably six?) input fields? Just associate the data on the server with some UUID that you store on my device. Inviting others could work by just sharing a link.
Thanks for the new perspective.
Now what happens if you switch phones or use multiple devices? The behaviour would be inconsistent. What if I build up a large amount of likes/dislikes? Would they be suddenly gone without way to export them?
Additionally, I actually would like it not to store data. Maybe I want to get the recommendation for a movie next time because I’m just not in the mood to watch that Horror movie right now. Edit: this last bit is actually exactly what elliekelly write more eloquently.
I agree this is a likely reason, but I think it’s a cargo cult design that makes sense on the web, but is the wrong priorities for a trivial/frivolous mobile app like this.
I don’t know anything about Android, but with iOS this just isn’t an issue. Everything is backed up and when I get a new phone everything is restored automatically.
Even for the quite uncommon case where a poweruser is switching between iOS and Android, it’s not worth blocking the 99% users who just want to try the app as effortlessly as possible and will never end up in that situation. It would certainly be possible to convert an automatic anonymous user account to one that uses password-based login, for users who care a lot about the data in the app.