If you’ve had success, maybe you would be willing to exchange some email?
> Warning! The localStorage getter provides access to shared state. This specification does not define the interaction with other agent clusters in a multiprocess user agent, and authors are encouraged to assume that there is no locking mechanism. A site could, for instance, try to read the value of a key, increment its value, then write it back out, using the new value as a unique identifier for the session; if the site does this twice in two different browser windows at the same time, it might end up using the same "unique" identifier for both sessions, with potentially disastrous effects.
https://html.spec.whatwg.org/multipage/webstorage.html#intro...
https://webkit.org/tracking-prevention/#intelligent-tracking... "Home Screen Web Application Domain Exempt From ITP". This is 100% bullshit though.
My personal belief is that Apple is purposefully nuking PWAs from orbit in a non-deterministic and "buggy" way because they are a threat to the app store business model, and I suspect if they frustrate enough developers, people will stay away from PWAs.
Cross-platform webapps should be table stakes for adopting any platform.
You essentially have to build your app from zero with these limitations in mind if you want any chance at getting around them.
This is a large part of why I am not a fan of frameworks and other popular design patterns. Having total control over how state is managed and communicated is really important if you don't want to get trapped in various tar pits.
If there is evidence of the veracity of this claim, this topic deserves a whole lot more attention. Especially considering Apple's stance on 3rd party mobile web browser engines - Apple forbids them, although EU regulation may force this to change.
I searched a bit and found no smoking gun, the closest hit was:
https://old.reddit.com/r/Safari/comments/185cra6/safari_nuki...
But it seems more likely caused by legitimate bugs than any intentional campaign.
Have I been nerdsniped here by a nutter? :-s
I would absolutely make this claim.
This isn't even a PWA thing. We had a really simple series of boring web forms that suffered from this. The first iteration of this had the server swap an initial tokenized link for a cookie when clicked.
After some feedback from our customers, we discovered that iOS users were having a lot of trouble getting all the way through the desired workflow. We were able to replicate this on our iOS devices but it seemed completely arbitrary.
After abandoning cookies in favor of maintaining a tokenized URL, we found we were getting 100% success rate for iOS end users.
My theory is there is a malicious bit of code in iOS Safari that is applying some insane cookie policy over "unpopular" domains.
But on the plus side, random deletions also happen on Android!
This is true even if you use Google's own tool to wrap your PWA and put it in the Play Store, and even if you use the so-called "persistent storage API" to have users request their data not be deleted - still get random data loss, and it makes it very hard to maintain a 4+ star rating when there are a bunch of 1 star reviews about users losing all their data.
I realize I'm a bit of an edge case. But also, ideally we could make PWAs that operate with similar data guarantees as native apps. That's kind of the idea of PWAs, that web apps should be able to mostly be the equivalent of native apps.
And it almost works, except for the data loss issue. Kind of sad. Cause there are so many other advantages of a PWA... like being able to target all platforms with one PWA is incredible. Having no gatekeepers to "approve" my app updates is incredible. But the cost is sometimes users lose all their data :)
It’s a Klondike Solitaire game. It used to bring ~$500/mo of advertising revenue, but that’s significantly down these days: I refuse to have a cookie/consent banner, so I refuse customized ads (in the UE, in some US states now, &c.)
Players do add it to homescreen. There is a non-intrusive button prompting them to do so, at the end of a game. People like to be able to play offline. Apart from that, I don’t use much PWA/browser features; no notifications, etc.
More info here: https://news.ycombinator.com/item?id=34483398 Happy to answer any question you may have! Happy to get some feedback too ;-)
Safari (and Firefox) does not have https://developer.mozilla.org/en-US/docs/Web/API/BeforeInsta... So you can’t have a custom button/way to prompt players to install.
However, they can install a PWA manually, by themselves; there is the option somewhere in their browser menu.
“it’s just opening a browser window with no actual browser controls”: yes, due to the `display` setting in the app manifest: https://developer.mozilla.org/en-US/docs/Web/Manifest/displa...
It’s similar to a `WebView` component: https://en.wikipedia.org/wiki/WebView
But there is nothing a PWA can do that a website can’t do. It’s all about Web APIs. Take push notifications (https://developer.mozilla.org/en-US/docs/Web/Progressive_web...): they make more sense for an (PW)app, but a simple website can do them too (if given permission).
See MDN intro on PWA: https://developer.mozilla.org/en-US/docs/Web/Progressive_web..., or https://web.dev/learn/pwa/ for more info.
If Apple supported this API it would be much easier to convince stakeholders that PWA is enough.
You can do browser detection and show a dismissible pop up with instructions but it will still just confuse some users and others with scoff at the need to do that.
The algorithm is described here: https://FreeSolitaire.win/strategy I came up with it by myself.
“The strategy presented here is the basis of the computer algorithm of FreeSolitaire.win, which is used to select finishable deals, offer hints, and detect dead-ends. You also see it surface when you are told that The computer could do it in N moves at the end of a game.
This strategy/algorithm is quite simple. It does not require to “count cards”, i.e. keep track of which cards were seen in the stock. It doesn’t require to make guesses on where such or such face-down card must be located. And the procedure is the same all along the game; there is no special treatement of the opening or ending. It’s stateless, a programmer would say. […]”
That is truly great, @palsecam. I love HN because of this!
(You can also choose the mode in the New Game dialog.)
And yes, it’s indeed harder. The solving algorithm has a winning rate of 52% in “turn one” mode, but only 18% in “turn three”.
How did you get it off the ground and gather first users?
Word of mouth, mainly. Posted it on Reddit back then, things like that. It grew organically from that. And, although it’s far from being on top results on SERP (search engine result pages), some people do find it that way.
Also: because it’s so lightweight, it got included some years ago in the Moya app (https://play.google.com/store/apps/details?id=nu.bi.moya), a popular messaging app in South Africa that is “data-free” for users (it does reverse-billing). Now half the players are South Africans!
Maybe it's just a different style of solitaire? This one seems too easy, though. Well done app, regardless - cheers! :)
It’s because of https://bugzilla.mozilla.org/show_bug.cgi?id=1813213
I just spent a couple hours trying to find a clean workaround, without success… Will investigate more ASAP.
Thanks again!
/*
Work around Firefox Mobile getting the hit target (clickable area)
of the game control buttons wrong, when the (bottom) navigation bar
gets hidden (when scrolling down).
See https://bugzilla.mozilla.org/show_bug.cgi?id=1813213
and https://stackoverflow.com/questions/70893056/mozilla-android-addressbar-conflict-with-sticky-button-on-bottom
and https://news.ycombinator.com/item?id=40733062 ← thanks @ttymck for the bug report!
*/
if (/Mobile.+Firefox/.test(navigator.userAgent)) {
self.addEventListener('resize', frameThrottle1(() => {
document.getElementById('metagame').style.position = (window.outerHeight > window.innerHeight)
? 'sticky'
: 'fixed';
}));
}I understand your will to disable vibrations. But thing is, right now I can’t think of how to offer that option properly. For instance, adding a Setting menu+icon just for that would be lame.
I’ll think about it more, tho.
Again, well done
When you've got the problem you want to work on, is a PWA the best method of use/distribution/discovery?
Perhaps a mobile app is the best method, or a hardware device.
When you're thinking about what you want to build, don't forget about distribution. There is a saying that 1st time founders focus on product, 2nd time founders focus on distribution.
Customers want apps. Companies want apps. No one except us nerds want PWAs. We can talk about how PWAs are second class citizens and how unfair that is or we can remember that end-users _do not care_ about the underlying technology. We constantly make this mistake, customer don’t care what language you are using, they don’t care what framework you use, they don’t care about native vs web, they just want it to work.
I’ve been developing cross platform mobile apps (web, iOS, native) for around 15 years (Titanium, Cordova, and now Capacitor) and while the lesson has been painful: no one cares about PWAs. I will tell clients “you can go to <website> and see exactly what your app will look like once it’s packaged for the app stores” and they will simply wait for the native app instead. I’ve lost count of the number of times the code has been running on the web for weeks+ and it’s not till it’s in the stores that I get _any_ feedback (things they could have easily seen in the web version but didn’t bother with till it was an “app”).
You can complain about this, you can talk about how unfair it is, you can extol the virtues of PWAs but at the end of the day it just doesn’t matter. Customers have spoken, they want apps. I launched my current company as a website/PWA and all I got was a lot of heartache: “I can’t find it in the App Store”. Not a single person said “thank you for making this a website”. In fact, I get 1-2 complaints (from thousands of users) of “I don’t want to download an app” to which I tell them “you don’t have to, the website spells this out very clearly, you can use the website and/or save it to your home screen, no app install needed”. I tell that story to illustrate how few people even say they care, but also can’t grok that they don’t need to install an app. That “1-2” pales in comparison to the people who complained about it not being a “real app”.
So if you want to fight against native apps be my guest but you’re fighting a battle that customers do not care about (I cannot stress enough that: HN != normal customers) and they will not thank you for. Yes, the 15-30% “tax” can suck but 15% of $X is better than 0% of $Y. You will simply miss out on a large number of customers if you refuse to make an app.
No customer has ever cared if you use spaces or tabs internally and they don’t care if you provide a PWA, they just want open their platform’s App Store and search for your app. The ship has sailed on this topic and you can complain about it or you can live in reality and go to where your customers are, the app stores.
You can say this isn’t fair but as my dad used to say: the fair comes once a year and if you miss it, it’s your own damn fault.
Just like language is a vehicle for logic, the app delivery tech is just a vehicle for a UI. PWA tech sucks because platforms are incentivized to make it suck. People prefer native apps because they're being funnelled down that path by anti-competitive interests. You don't seem to make that connection.
I get it, you were burned by PWAs and now you just want to build something that works for everyone relatively painlessly and makes money. Nothing wrong with that. But some of us also want support tech that fulfills the goals of the open web. You don't seem to care about that, but others do. Telling everyone its basically a lost cause is a silly and pointless endeavor, because PWAs are the long game, and you're playing the short game.
Yes, I know that installing a PWA is confusing (especially on Apple's systems), but there no reason it has to be that way.
PWA (if it were implemented properly): "Click here to install app". Click. Confirmation dialog. App is installed. App opens in the same window.
App store: "Click here to install app". Click. An entirely different application opens. Confirmation dialog. App is installed. You open it, but now you're in a different context.
> App store: "Click here to install app". Click. An entirely different application opens. Confirmation dialog. App is installed. You open it, but now you're in a different context.
You’re unfortunately oversimplifying the PWA installation. Say a user has heard of a new service called “Florb” which has a PWA and a native app. To install natively:
1. Open the App Store
2. Tap the search button (optional, might already be selected)
3. Search “Florb”
4. Tap Get
5. Confirm download
For the PWA:
1. Open Safari
2. Search for Florb using your chosen search engine
3. Open Florb homepage
4. Tap “share”
5. Hunt and scroll for “Add to Home Screen”
6. Tap “Add to Home Screen”
7. Give the app a name
8. Tap Add
This is ignoring the possibility that searching Florb returns other sites first (maybe news articles about the neat service, or a wiki page), nor that there are usually enough ads on google pages to completely obscure the first real results from the screen on page load. Yes, the App Store also shows an ad, and it’s possible for other similarly named apps to appear first in the list, but it’s generally less of a problem than relying on google searches.
Even ignoring the fact that the average user doesn’t know or care that PWAs exist, the first option is simply easier and more reliable. There’s no getting around that. And that’s also ignoring that PWAs are, to an average user, “installing a website” rather than “installing an app,” which just feels wrong.
“Add to Home Screen” has been available on iOS since at least iOS 4 (that’s the first time I remember seeing it, but it may have been around longer). If people don’t care about it yet, I have a hard time believing they will any time soon unless it is substantially and objectively better than the App Store.
And when I click "add to home" in my browser's menu I don't need to name the app. The app has a name. What are you talking about?
> 5. Hunt and scroll for “Add to Home Screen”
> 6. Tap “Add to Home Screen”
>7. Give the app a name
> 8. Tap Add
None of this is essential except maybe 8.
That is why I said "if implemented properly". In specific,
> Yes, I know that installing a PWA is confusing (especially on Apple's systems), but there no reason it has to be that way.
> PWA (if it were implemented properly):...
You're also pretending there aren't a bunch of junk/garbage/spam/ripped off apps in the App Store with names similar to the real app.
I assure you that is not the case.
Because it is strange and different. If Web apps were standard going to the iOS App Store would be weird. It’s not so PWAs are weird. Just give them an app, don’t make them work to install it.
Get off the cross, we could use the wood.
Spare me. I love the web, in fact all my “apps” are built with web tech and I offer them all as websites/PWAs in addition to apps but standing on principals of only using the web as some kind of middle finger to the app stores AND your customers is just silly.
So I bite the bullet and wrap my web apps in a thin wrapper and shove them into the App Store. You can call it principles but I just call it stubborn and dragging your customers into a crusade they don’t care about.
At the end of the day I care about the customers of my products more than I care about trying to wage a losing war against something they actively want, apps from stores.
Life is way too short to tie up your identity in things like this. I want to spend my time making products people enjoy using. If you actually care so much about PWAs then stop writing PWAs that your users hate using and go be a full time advocate for that instead. Right now shipping PWAs is a worse experience so the only one you hurt is yourself and your customers when you double down on them.
Your hate for PWAs seems a bit excessive. Nowadays it's possible to build binaries for iOS and Android using PWAs and it'll behave just live your Cordova projects. Don't be stuck in the past.
> I love the web, in fact all my “apps” are built with web tech and I offer them all as websites/PWAs
I'm well aware you can build binaries and ship a PWA, I literally do that. I don't hate PWAs, I dislike people that refuse to ship anything but PWAs and I especially dislike being told I don't care about the "open web".
If you want to be a martyr and _only_ ship PWAs be my guest but pretending it's noble is just silly and drags your customers (you know, the people you should actually care about) into a battle they don't give 2 shits about all while making their experience worse.
What a weird thing to get all bent out of shape over. People do things a different way than you, get over it. If someone wants to only ship PWAs, why does that bother you so much? Because they're hurting users, and you're trying to protect them?
I do care about PWAs, and so I am advocating, right now. I don't know why you come across as so angry about people who advocate for PWAs. Pushing companies to adhere to open web standards is a good thing, otherwise we'd still be stuck in IE6 world.
“Preaching to the choir” comes to mind.
I'm replying to the people who disagree with me here, and there are several. The readers who are on the fence can make up their own mind. Your discouragement is not necessary or useful.
I used to work on a platform that offered native iOS apps, native Android apps, and PWA / web apps for all our customers. When users were given the choice, around two thirds opted for the native iOS app, about a quarter opted for the native Android app, and about 10% opted for the PWA / web app. That’s including desktop users, not just mobile.
Users want native apps.
If Apple wasn't hamstringing PWAs, they might be viable for more categories of software.
In another timeline, Apple chose to double-down on PWAs instead of the App Store after the iphone 1, and PWAs are the majority of non-performance-sensitive smartphone applications.
Developers complained when the first iPhone came out and when Steve Jobs called web apps a “sweet solution”. Even Gruber called the solution a “shit sandwich”.
If it’s only Apple holding PWAs back, then why do most of the same companies write Android apps instead of just producing PWAs that work on PCs and Android devices?
Google followed Apple's lead, so it's not like they have a choice.
And in case you haven't noticed, those same companies are happy to accept the performance hit of cross-phone libraries in order to not develop an app twice. If the PWA experience were better, they'd probably try that instead.
Most apps are boring, and don't require native performance.
Can’t have that on the app store.
That’s not customers choosing PWA over native, it’s customers forced to use PWA since native isn’t an option.
People in the know rightfully care about the erosion of standards for which big tech have built their empires upon.
On my computer I always use the web. I prefer the web on my computer but on my phone apps can provide a nicer experience (larger touch targets, swipe gestures, etc). But in general I find the phone (and tablet) limiting and if I need to do any actual "research" I immediately move to my computer where I can open multiple tabs and move between them easier.
isn't it a small racketeering/marketing price for the promissed discoverability?
Depends on your audience on whether this will actually be worth the investment. Being on the app store doesn't necessarily make you visible anyhow. It's just easier to install for apple users.
In that situation I don't think charging more would go over well with consumers.
Have you seen this done?
Netflix offers in app purchases for streaming subscriptions if you pay through their games. But only the ad tier.
You can subscribe to YouTube or Hulu via in app subscriptions. But you can’t subscribe to YouTube TV or Hulu Live TV via the app.
I guess these days I would offer a higher month to month subscription through in app purchases and a lower yearly subscription from the web.
70% of something is more than 100% of nothing (especially when the product is software or something else that has a marginal cost of production of essentially zero).
I would say running as a PWA has been a mixed bag. There are quite a few missing features across web platforms (for starters, background sync, full featured push notifications, haptics) that make it hard to be competitive with native apps. Every WWDC, we watch in hopes that Safari gets more PWA features, but it's a thin drip. There's a reason so many apps repackage into electron/cordova/whatever shells.
As other folks in thread have pointed out, it's probably worth thinking through why a product works particularly as a PWA vs alternative distribution methods.
WebKit and Safari have come a long way. Flowery puts browser engines through their paces with its UI animation, which is smoothest on WebKit. Safari’s OS integration (e.g., elastic scroll, Sonoma’s “Add to Dock”) is more polished than Chrome’s.
It wasn’t a walk in the park though. An early decision, after maddening attempts to circumvent browser quirks five years ago, was to build substitutes for common building blocks of the browser on mobile, notably the virtual keyboard, textboxes, and text selection. This wouldn’t have been possible without web components and Google’s excellent Lit library.
I did figure out there is some sort of spaced repetition component to it, but that’s probably because I’m already an Anki user and aware of the concept.
I quite like the eccentricity of it, although I’m sure it could be toned down a notch for wider appeal.
Feature-wise, having thesaurus definitions immediately accessible is very useful.
I may have gone overboard with the minimalism. Users had been all the more baffled before I added the tooltips hinting to tap the hearts, so I should probably double down on some sort of tutorial.
The Stripe integration launched a few days ago, so the app is very much in the red. Paid advertising since the initial release six months ago has shown promising signs from prospective customers though.
Nothing big/fancy as you probably want, but for me they are definitely successes for me!
Your question might be too light on details to provide much advice.
But I guess you will need Macbook to debug any Safari issues too.
This allows us to publish to the respective stores. Would be hard to convince non-technical users to click "Install as PWA" because noone knows what that is.
Don't trigger my nostalgia! Fun times, been there done that 2005-2008 https://web.archive.org/web/20080118184913/http://www.sudoku... — then sold it on to another "micro-ISV" (the popular term for indie software maker back then)
The 5.25" and 3.5" floppy disk shareware cardboard bins on tables at Weird Stuff.[0] This was the equivalent to [Download Demo] in the 90's, except they made you drive to a brick & mortar store and pay for privilege.
Been using them as a PWA for a very long time.
Flipkart.com and housing.com and few good examples