zlacker

[parent] [thread] 2 comments
1. meeste+(OP)[view] [source] 2017-07-27 16:08:02
whats the issue if you're granting permission for them though? just say no if it's from Buzzfeed, yes if it's from my XYZ service - that's all it takes. And - I would expect notification management would need to be similarly accessible.

Notifications are tough to do as is - and a core user need. You and I might turn them off, but many people rely on them heavily. If I have responsive web app with notifications - that's the dream for me. because I don't want to have to build a native app JUST for that. Nor, should many others need to.

replies(1): >>cridde+O6
2. cridde+O6[view] [source] 2017-07-27 16:45:22
>>meeste+(OP)
I may be wrong about this, but it seems like waking up a web app periodically to check for notifications would use a lot more power (and maybe data) than it does for a native app. Web apps in general are going to be less efficient, aren't they?

So a web app is easier for you, but aren't you really just transferring the cost to your users in the form of battery and data consumption?

replies(1): >>meeste+fg
◧◩
3. meeste+fg[view] [source] [discussion] 2017-07-27 17:40:01
>>cridde+O6
Well, I wouldn't go so far as to say a lot more power - and apple could potentially integrate it with their existing push service.

Would it be, in a way, pushing costs onto users? potentially. But, it's a matter of shipping something that works at the loss of some battery and data usage (minimal) or spending 6 months to a year learning and developing a native app which is more efficient for end users. But both approaches are subject to market validation - one lets you reach validation quickly, the other requires quite a detour.

So, I'd rather not throw away all that time. If I can get notifications that work, even if only checked every 10 minutes vs. instant, I would be happy. Then, if there is market fit and proper demand, I can likely afford the time/money to build out a native experience.

[go to top]