Yuzu | https://yuzu.health | Engineers & Designers | Onsite in NYC | Full-time
At Yuzu, we’re building the next-generation health insurance company. We are NOT building a digital brokerage or an AI wrapper - we are going deeper to build the foundational infrastructure required to power tomorrow’s health plans.
Hi! I tried to apply but I was getting an error message on the form (didn't find any extra info in the API response either), tried contact form. Is there an email I could send an application to?
At Yuzu, we’re building the next-generation health insurance company. We are NOT building a digital brokerage or an AI wrapper - we are going deeper to build the foundational infrastructure required to power tomorrow’s health plans.
Are there any examples of really a great PWA on mobile? I always find the experience of company's mobile site far worse than its app (such as YouTube or Spotify), and I'm never sure if it's just lack of effort and attention, intentional to push users to the app, or just the ever so slight annoyances like slight tap delay on Safari iOS.
Starbucks put a lot of effort into their PWA [1] to ensure users of low-end devices were able to get a rich experience. I just found a case study [2] by the team that built it that goes into some interesting details.
Personal experience as a web dev: the mobile Safari PWA experience (and even regular browser experience) is terrible. The browser is riddled with bugs and lacks support for features that have been around for a while. I apologzie for not having examples bc it was a few months ago that I was struggling with this, but hopefully someone else can fill some in. I honestly believe Apple's stranglehold on the mobile browsing experience has been one of the most disempowering things to mobile users in the last decade.
Why is the answer to this question always “Safari sucks”?
Are there no good PWAs that run on Android? Are there none that, though perhaps smaller is scope, run well in Safari?
People have been advocating for PWAs for a very long time now but it’s incredibly hard to get examples of good ones. There is always some complaint about Safari instead.
>There is always some complaint about Safari instead.
when one app is used by roughly half of all mobile users, that's not something you can ignore. so complaining about that one app when these conversations come up does not seem out of place. essentially, the conversation is something like:
- PWAs are great!
-- How well do they run on Safari?
- PWAs are great on other platforms.
-- So about half of mobile users? Doesn't seem that great to me
Google, to some degree, worked with Twitter to make twitter.com a 'flagship example' of what PWAs could be. If that's the best Google could come up with, the platform stands zero chance.
Apple's stronghold affects PWA feasibility on Android too. If I have to write a PWA for Android and a native app for iOS to cover gaps in Safari, why choose a PWA at all?
Apple may be ~50% of the market in the US but it’s ~20% of the market worldwide. On the desktop anyone on any mainstream OS can use Chrome or FF.
Yet someone the total lack of PWA success is 100% Safari’s fault.
Look at all those users I listed above. How are there no common/well known PWAs if they’re so great? People use websites like the Google Suite and Figma and such. They use web apps built as desktop apps in Electron. They use native apps.
Almost no one uses PWAs. Even if Figma or Gmail or whatever is available to be saved as a PWA it doesn’t seem to be commonly done.
There must be some other problem than Safari. It can’t be the big issue.
Telegram is probably the best example of a PWA. It's not as good as the mobile app, especially for gestures, but it's better than a lot of native apps.
Telegram really is an outlier among messengers. Each version is developed by like one person, and they are all feature-rich, feature-complete, fast and smooth.
There's a bunch that run very well on Android: Twitter, Instagram, Uber, Lyft, even TikTok all have very good PWAs.
TikTok aggressively funnels you into the native app for various business reasons, but the experience is well polished if they'd let you use it all the time.
Safari (really that iOS won't let you pick a different browser) has definitely been holding back the growth of PWAs though. Without decent install to home screen support (apple doesn't implement install banners for web), no push notifications, many of the native API integrations missing, it's hard to go too far down the web path before the business folks want the native app for growth angles. It's a lot more about making money than the better UX that can be had with native.
The reason iOS and Google/Android PWAs suck is because Apple does everything in its power to make them suck:
- Complex and user-unfriendly "add-to-homescreen" functionality
- Limited/trailing functionality for native APIs
- The obnoxious url/browser bar persistent at the bottom of the page, with horrendous and uncustomizable hiding/showing of said bar.
People advocate for PWAs, but I never use them because as an end-user they're awful to use, because developers can't create them to the quality of native applications because of these limitations. Of course the complaints go to Safari in that case.
They absolutely could have PWAs be of higher quality, but they don't, for obvious reasons.
I can't entirely speak for Android, but I assume that Google has similar nonsense (as evidenced by sideloading being a pain to the average user)
For Windows, Linux, and MacOS, there's no real need for them, or not enough need for them to exist. There are no policies or guidelines to follow, there is no 30% tax.
The browsers people use on desktop devices provide everything that developers need and can reasonably expect of the platform. There aren't any usability differences, there are barely any performance differences, and there are barely any feature differences.
In fact, I think many desktop end-users would prefer the app to be web-based because it feels so native.
In addition, it's what another commenter said - if it can't be on iOS, then what's even the point of having one?
100%. PWAs are not a priority for Apple (and shouldn't be for developers) because users don't search for apps in web search engines, they search for them in the App Store.
App store discoverability is very poor. Web discoverability is much easier to manage. It's something you have more control over and can buy easier through marketing via any channel you want. App store pages just don't convert well.
I agree about the installation process (though the user shouldn’t need to fill in any info). The actual user experience when using home screen PWAs can be made to be OK, but there really needs to be a meta tag or whatever to allow an ‘Add to Home Screen’ banner to appear (similar to the way you can link to the App Store if you have a native app).
I'm not even talking about bugs per se. Just the experience. I find myself constantly battling misinterpreted gestures. I try to zoom out on a page. Safari thinks I want to switch to the Tab View. I don't. Please just make the page smaller so I can see it all.
Or, I try to grab a UI slider that's positioned near the left edge of the viewport. Safari thinks I want to navigate back to the previous page. Nope. Apparently if form controls are too close to the screen's edge, they're read-only at that point?
So many gestures are overloaded now that it's a stressful thing sometimes to get it to do what I want. Being pixel-perfect with my fat dumb finger is no fun.
Isn't the main purpose of a native app access to data collection that a browser would not have access? That way they can make money on that data collection?
On the dev side of things, a huge advantage of using the native SDK is that you’re not stuck with the downsides of the web’s “bring your own everything” approach. You’ve get an expansive set of capable UI widgets and frameworks for everything imaginable that are battle-tested and opinionated with there being a well supported “happy path” for just about any task.
Additionally many of the APIs are mature and haven’t changed significantly in a while, which means the body of relevant reference material online is huge — it’s not necessarily outdated just because it’s a couple years old, predating [X buzzword feature] getting added to [Y trendy JS framework] and turning popular convention upside down for the fiftieth time.
Well, that’s how it on iOS at least. It’s more murky on Android because Android Framework is kind of a mess, but it still has some advantages over the web.
This isn't true for 99% of business out there. Almost every mobile app is worse than its website in a mobile browser because most business can't afford a web dev team, an android dev team, and an ios dev team. The exceptions are the few apps built by the mega-corps that have the resources to build a good mobile app. Nobody want's to install some broken app with a fraction of the functionality of the web site, but that's what 99% of the apps in the app store are.
I think that it really depends on what the PWA is trying to do and its purpose. I think the Twitter, Instagram, and Starbucks apps are both good examples of what can be done. Potentially a lot more could be done with PWAs, if there was more push to make them better.
Scrolled around and decided to try the TikTok app. It’s perfectly functional but immediately pops up asking to install the native app for the “full experience”.
The first popup was dismissible, so I kept swiping. Within two videos the same popup was back and it was not dismissible.
Companies intentionally cripple the web experience.
Also mobile Web is good enough for most forms over data kind of applications.
Other than games, where Web 3D APIs are stuck in 2010, many "apps" could be easily done as mobile Web, specially all those that are basically mobile Electron.
The biggest thing hurting PWAs in my opinion is that SPAs and web apps in general is done as a cost-saving measure.
This means that while they can be good, they very often aren’t because they aren’t getting the budgets and caliber of engineering talent they’d need to be good, and so it’s much more common that they fall somewhere on the less-great side of mediocre.
Users then associate this degraded quality with web apps and disinclines them from using them, even on platforms where PWA installation is promoted (like with Edge/Chrome on Windows and Chrome on Android).
Safari’s limitations play a part too but even if Safari vanished tomorrow PWAs would continue to get lukewarm reception so long as companies aren’t putting the same kind of resources they’d put into a flagship native app into their PWAs. At the end of the day, if you cheap out you get a crap experience.
What's wrong with the YouTube pwa? To me it looks and feels very similar to the app.
Edit: just tried the Spotify pwa and it's not bad. Maybe not as good as native, but that's partly because of the big "Get App" button in the bottom right corner.
Agreed, both are pretty good. Especially the YouTube PWA runs just as good as the native app on my Android phone, up to the point where I often forget which one I'm currently using.
I know you're joking (and it was funny), but thinking about it I think it's actually harder in some ways because you go from almost no traffic most of the year to needing to scale really, really fast. And the PWA has a ton of games and other things in it, so not as simple as the old school trackers that don't even need a backend cause all of the "tracking" happens in the browser
I'm 100% unawares of the Santa Tracker app that you speak, so yes, I was attempting to be funny. However, for that 1 day of the year, is it that hard to have the "tracking" done locally since it's literally just made up data? Just know the localized time and where sunset is, and have the "Santa" moving around in the nighttime areas of the globe. Guessing on efficiency suggests to me rapid movements along the North/South with magical speed roughly equidistant from the terminator at a distance equivalent to midnight.?? Again, since it's 100% make believe, it's not like your browser has to show the exact same location as someone else's.
Any other games the app might be included are out side of the scope of the imaginary app in my mind.
> I thought that a number of first party Google "native" apps is just a packaged PWA, isn't it?
I wonder what those are. Because the apps where they want actual fast responsive apps with smooth animations etc. (and tracking :) ) are all native as far as I can tell.
I love breaking things and I've noticed that user are able to intercept the UID / ID of the received messages in the Websocket and edit / spoof past messages from other users.
edit: And editing other user names and rooms settings.
Thanks for catching that! One thing I really wanted for the project was not having to sign in to use, but that's been causing a lot of security holes like this. Gonna try to fix everything soon
Out of curiosity, what are the motivation(s) for not requiring users to sign in? Is it just lowering the barrier to entry, or are you concerned with privacy?
I'm really not knowledgeable about firestore, firebase or even authentification systems but couldn't an user request a secret key that the user will use to authentificate itself when sending a message into the websocket (that will not be transmitted to the other users)?
For the login-gate, I'm pretty sure 99%+ of the visitor would have not created an account. Even without the login, the HN room shared in that thread was kind of inactive.
Since the rooms are "private' by default (secret token in the URL), authentification is now really necessary for casual usage.
Yes you could generate a rsa key pair in the browser and send a tuple of user id (or just a nonce) and public key to the server as a form of automatic registration. The client could prefix each chat with the user if/nonce and sign it with the private key before sending it to the server. From then on the server could simply retrieve the public key it has associated with the user id prefix and reject any messages that fail signature validation.
This could also work in a peer-to-peer context by only using the server for public key registration (i.e. by chat room). All messages would go directly between clients and the server would never receive chat messages.
I tried my hand at something similar using a sleep music themed YT channel and website. Couldn't get things to click. And FB ended up blocking my site on the sharing debugger.
I think there's a line where it stops being reasonable. If I know every comment on a Show HN is going to be blatant self promotion, I'm not going to view those posts even if the OP is interesting to me.
> Show HN is for something you've made that other people can play with. HN users can try it out, give you feedback, and ask questions in the thread.
> On topic: things people can run on their computers or hold in their hands. For hardware, you can post a video or detailed article. For books, a sample chapter is ok.
I am glad to see work from other hacker news members. When it isn't interesting to me, I find something else on the internet or IRL that is.
Great point. While not everything is appropriate to share in response to someone else's "Show HN" post, I've definitely seen (and appreciated) others linking similar projects. It usually is in the context of saying something like:
- I tried this too, and can appreciate that you solved way harder things than we expected to have to deal with
- I had this idea too but like your execution
I think it's very fitting, especially since we are celebrating not just the idea, but the execution that someone did to be able to show it off here.
Maybe there should be a weekly/monthly “Show HN” (like the who’s hiring thread) where everyone can promote what they’re working on. Doesn’t have to be new things, even progressive updates would do.
Hey @dang, how does a free-for-all self promotion thread sound (minus the spam)
I feel this site shows why websites need more than 512kb these days... Most of these are just unaesthetic, simple personal sites with a few blog posts. Nothing wrong with that but nothing to glorify either.
512kb is still a lot of space to play with. My website - the one I live from - is about half of that, except on longer articles. That's despite large header images and quality-of-life JavaScript. It wasn't very hard to keep it that way.
Custom fonts, images that look nice on retina / hdpi screens, complex responsive layouts can all add up. Images are obviously the worst offender, but the rest all contribute.
Of course, aesthetics are a matter of subjectivity, so what is pleasing to one might be gaudy or bare to another. It is largely a matter of picking your audience, I think.
I used to have the same issue. Looking for interesting tidbits in a podcast was like finding a needle in an 1hr long rant haystack, and I personally like to have some snippet as a reference for later when I'm learning, but I found this app https://www.airr.io that lets me save and share snippets of podcasts. Pretty useful!
We're hiring aggressively across the board, see open roles at https://yuzu.health/careers