I like the post. But I feel like I am reading a slightly edited Gemini AI response. Just me?
Do not download the app, use the website
191–200 of 760 posts
Re: Do not download the app, use the website
#192Earlier quoted context omitted.
>Android has long had PWA support. Almost no one uses it at all. Yes. Because if you're making a mobile app you want to target the two major platforms. If IOS's PWA's suck, you're not going to try and make a PWA for android. So it's a negative feedback loop. >Despite entirely separate bases that could be served in entirely different ways, differnt ways costs money. So often it isn't done. They pick a framework that l…
[flagged]
>Ignoring that almost all of these orgs are also building web apps
Poorly, but yes. You can say they have something reseming a web app.
>several of the major frameworks can share the majority of code with PWA apps.
But as we should all know, it's not enough to press a button and deploy perfectly. You gotta fix all thr quirks, and that's where most of the budget for a dedicated team back in the day went. Not so much these days.
>Yet despite Android making up like 75% of the market....almost no PWAs have any traction at all. It's almost like it isn't Apple's fault.
75% isn't enough when targeting 100% of the market. And this decade isn't a good example of how companies are trying to win customers over with quality and care.
>Can you cite what you're talking about?
Straight from the horses' mouth: https://developer.apple.com/support/dma-and-apps-in-the-eu/
Can't get more term-Y than "you can't do this here".
>It isn't Apple's fault, as boring and constant as that cry is.
It's not apples fault in the same way it's not their fault Flash died. they didn't land the killing blow, but they sure did slice some limbs off.
You seem too obsessed with thinking that there's this "android exclusive "market to appeal to to really understand my argument on how app development and support actually works in practice, so I'll leave it at that metaphor.
Re: Do not download the app, use the website
#193Earlier quoted context omitted.
I argue that this decade shows you do not have to provide value. You capture the market yester-decade and then you can hold the users hostage as you do any and everything to appeal to shareholders and advertisers. This is indeed a short term strategy, but tech companies right now are thinking very short term.
How do you hold users hostage without providing them value?
Nostalgia, network effects, and boiling thr frog. Then you build on that with business incentives; you may not like Facebook, but you need to advertise there because that's where everyone is.
Basically, you rely on goodwill from yester-year and slowly ad in intrusive stuff that users adjust to. Thars enshittification in its raw essence. Admittedly, this mostly works because the general user is not "active" and will not take the time to migrate unless something absolutely scandalous happens. For them, it's easier putting up with ads than trying to log into an ad free substitute.
Re: Do not download the app, use the website
#194Earlier quoted context omitted.
UIKit is fine, good even, SwiftUI isn’t fully baked yet, Android Framework definitely sucks, and Jetpack Compose is decent but needs work. Both platforms have at least one SDK that’s good to use, and personally I’d take them over fighting the extra layer of issues something like RN adds on top of the native issues that devs will encounter regardless of the SDK used. Cross platform frameworks really aren’t the magic w…
Cross-platform is very much not a magic wand, but it's still often easier than building the same thing in two different native SDKs, and I can see why people do it. Disagree about UIKit, mainly cause of Autolayout, unless it's gotten reworked in the past 8 years. When I started using RN, I had zero web experience, and still it was way quicker to set up a basic UI than in the UIKit stuff I'd been doing for years. And…
The thing about UIKit is that you really need to forget about the drag and drop UI editor (XIBs and storyboards). They make everything including autolayout much more painful than they need to be.
Pure code UIKit using autolayout’s anchors API is quite serviceable, and if you follow recommendations (use safe area and keyboard constraints! They exist for a reason) reasonably futureproof. The iOS apps I’ve worked on have needed very little change year to year for quite some time at this point.
Re: Do not download the app, use the website
#195Earlier quoted context omitted.
Most apps nowadays are already websites inside a thin wrapper, and that part is just so it can go on the App Store and have certain OS integrations, not for the UI. Like yeah React Native implements a button with UIButton, but Safari also implements a button with native code. Good example is Discord. Complex app, only really difference for native is something about push-to-talk.
Not quite, at least on iOS. React Native is the dominant non-native framework there. I run into web shells on occasion but they’re unusual relative to desktop.
Oh, I meant React Native, not an actual full-page UIWebView rendering the entire app (though there is that too). Yeah RN is a totally different renderer, but if something works in RN then I expect the same to work in web. Discord did both.
Re: Do not download the app, use the website
#196Earlier quoted context omitted.
Chase Mobile for iOS is 350MB; far from 500, but still baffling why an app would need to be that large just to show me some numbers. Capital One is 435MB... Garmin Connect is 518MB for some stupid reason, while Strava is half that and Gaia GPS (great app), is under 100.
Almost certainly has to do with how the app is built. Most thoughtfully built native SDK (UIKit, etc) apps clock in well under the 100MB mark, often under half or a quarter that. Bloat like that is usually due to unnecessarily convoluted tech stacks pulling in a list of dependencies that goes out to Mars and back, or for globally targeted apps sometimes it’s translations for everything in the app for hundreds of diff…
"clock in well under the 100MB mark"
But this is still incredibly ridiculously comically gross. The fact that we can afford it these days is an irrelevant seperate thing. These numbers are just unjustifiable for what most apps actually do.
Re: Do not download the app, use the website
#197Earlier quoted context omitted.
It's not a bad thing for users . It would reduce the ability of Apple and Google to extract revenue from their stores though, so they're motivated to do the opposite.
For more complex apps, efficiency could be a considerable issue. As capable as the web has become, it’s not very battery friendly for more advanced use cases.
Sure, native apps can be good for users in some cases, but this post isn't about those.
Re: Do not download the app, use the website
#198Earlier quoted context omitted.
Cross-platform is very much not a magic wand, but it's still often easier than building the same thing in two different native SDKs, and I can see why people do it. Disagree about UIKit, mainly cause of Autolayout, unless it's gotten reworked in the past 8 years. When I started using RN, I had zero web experience, and still it was way quicker to set up a basic UI than in the UIKit stuff I'd been doing for years. And…
The thing about UIKit is that you really need to forget about the drag and drop UI editor (XIBs and storyboards). They make everything including autolayout much more painful than they need to be. Pure code UIKit using autolayout’s anchors API is quite serviceable, and if you follow recommendations (use safe area and keyboard constraints! They exist for a reason) reasonably futureproof. The iOS apps I’ve worked on hav…
That's true, though some will tell you the opposite. But even then, the pure code autolayout seemed a lot harder to use than HTML/CSS. The fact that so many people got it that wrong says something. Like yeah a desktop website might break on mobile, but I'm talking about a mobile screen just getting slightly longer or something.
Re: Do not download the app, use the website
#199Earlier quoted context omitted.
Why is that a bad thing? Wouldn't we be better off with all of them being PWA's?
Gotta love the HN bubble. Users want apps, not PWAs.
I don't think the average non-technical person would know one from the other aside from the installation process. This situation didn't come about because users demanded native apps, but because companies profit more from them.
Re: Do not download the app, use the website
#200Earlier quoted context omitted.
not having a way to divide notification channels, transactional vs promotional, make it worse than android.
Explicitly promotional push isn't allowed on iPhone to begin with. Only exception is if the user enables it via some setting inside your app, separate from the regular permission dialog, which is really unlikely. Of course you can just pass off promotional stuff as not promotional, but same on Android, and you have to be sly about it.
>Only exception is if the user enables it via some setting inside your app
Or if Apple has a movie they really really want to promote