I get some push back from a few tech friends because I avoid using apps (except for things like Chess game apps). I can’t say for sure that preferring web versions of services helps with censorship, but it can’t hurt.
Using web versions, not apps, is important because companies keep user device statistics and if enough people insist in using web versions, the the web will continue to be at least partially supported by big tech.
> Using web versions, not apps, is important because companies keep user device statistics and if enough people insist in using web versions, the the web will continue to be at least partially supported by big tech.
It's also frequently just better. If I'm looking for hotels, flights, apartments, restaurants, hiking trails, ect., doing so in a browser allows me to keep dozens of comparable offers open for direct comparison - just by jumping between browser tabs.
Doing the same in the app means endlessly navigating between offers, favorites, and new searches. It's often very obvious that the app was built explicitly to be less powerful.
The main downside to many mobile web sites is the desperate plea to use the app you have to dismiss every time. I feel sorry for the devs who build a great mobile version only to be forced to put a stupid "$SITE is better in the app" banner on it.
There’s also companies which seemed to break their Web experience specifically to drive people into the app. Credit Karma hasn’t worked on a browser on mobile or desktop for me in years. But the app version always works.
I guess it’s my fault for trying to use an Intuit product to begin with when I already know they’re evil.
This is a reason I also like the web is that after the page loads I can just do stuff instead of getting kicked out to have to update the app ... Or even having to re-log in ...
uBlock Origin Lite is available for Safari on mobile, though that's not exactly the same extension. Orion supports standard uBlock Origin on mobile, but then that's not a browser "of note."
What is really stupid is when the app is just a web browser limited to one tab like for Amazon. The web site is better on phones because you can open links in new tabs but you can't in the app even though the app is obviously just displaying the exact same web page.
If a mobile app like that supported tabs AND somehow allowed you to see key things between tabs, you wouldn't even reach for the browser. Crazy how much different that landscape could be if they thought about such a critical use case. My guess is non-power users just look at one offer at a time.
> I can’t say for sure that preferring web versions of services helps with censorship
The linked article isn't enough to convince you? Look up Gab or Parler. (Yes, I find most of the speech there reprehensible. No, I don't think they should be denied the right to publish and distribute an app.)
Using a social media app instead of a website, as most people do, means that everything you are seeing has essentially been pre-approved by Apple and Google.
If the tide swings even a little further to the right on X, expect the X app to be banned as well. I was secretly hoping that it would be banned when Musk took over just to remind the right of why centralized app stores are a terrible idea. But with ICEBlock the left has finally been alerted to that fact as well, which might be even more beneficial to the cause of software freedom in the long run, since the left is generally less afraid of the proper solution to this problem, regulation.
In the meantime, keep using web apps instead of native apps.
They also bent a knee to previous Democratic party administrations and will bend the knee to them again the next time the Democratic party is in power. Large tech companies aren't interested in spending money and poltical capital fighting censorship demands of anyone who is likely to have power within the US government.
And therein lies a problem. Each 'side' has no problem with it as long their team is not affected. Just yesterday -- on AM radio of all places -- I had democratic pundit openly wondering how Epstein's list is going to be used against them after spending a fair amount of political capital pushing for its release. It is all a game and, sadly, we are getting played. In such an environment, it is hard not to become cynical.
There is a huge difference between a president using the “bully pulpit” and threatening to take away a network’s broadcast license because they said something he didn’t like. That was a road too far for even Ted Cruz who criticized both Trump and the FCC.
A democratic president also didn’t accept personal bribes from companies to allow a merger to go through (Paramount) or accept bribes from other companies that were afraid of retaliation - Meta, Google, Twitter and Disney.
The current administration has carved out outs for companies that bend a knee when it comes to tarriffs. This is the worse case of false whataboutism yet.
AWS isn't the only way to host a website, and his been an obviously bad choice for hosting something controversial since it denied service to Wikileaks.
Which reminds us of the difference between AWS and Apple -- Amazon Web Services is the web and the web is an open platform. If AWS denies you, you go sign up at any of their competitors or buy your own servers and plug them into the internet. If Apple denies you, iPhone users can't get your app, and if you go sign up at a competitor or buy your own servers, they still can't get your app.
> As far as X being banned, if you haven’t heard Tim and every other tech CEO bends a knee anytime Trump and conservatives asks him to.
That's because they currently control the government. Now think ahead by more than two days and consider the possibility that the other party might win an election again someday. What should you do right now when you're in control of the government to prevent yourself from getting screwed the next time that happens?
So now you just have to get deplatformed by Cloudflare, AWS, Fastly, Azure, Radware, Google, Akamai, F5, Imperva and every other DDoS protection company in the world all at the same time while simultaneously suffering from a DDoS attack that never lets up or your site immediately comes back.
Meanwhile a DDoS attack is a crime, so Apple doing something with the equivalent effect is now something you're equating with the commission of a crime.
I also think that it sends the right signal in terms of "Hey, this really doesn't need to be an app". I don't need an app for my newspaper, I need a shortcut/bookmark to its web page.
And once you start thinking about it, the same thing goes for a surprisingly large amount of apps.
I feel like in the coming years the facade big A and big G put up in order to push everyone into their distinctive walled garden of apps will crumble in public opinion.
It never was "yeah, it needs to be an app because the web platform doesn't have an API standard for it", geez, apple even forced a single web engine. They could have easily allowed access to their APIs on the browser. It just never was in their corporate interest to do so.
Okay, this devolved into an anti corporate rant without it being my intention to... So, go web!
I don't really know how to articulate exactly how I'd classify into one bucket or the other but I think there are two types of "app" and I tend to have differing preferences on whether they should be native apps or web apps as a result.
One is where relatively-static content is the priority, deep-linking is important or essential and the web platform is pretty ideal for those. News articles or blogs or Wikipedia pages or those sorts of things. Things where I might want to be switching between tabs or forgetting about for a while and coming back to later.
The other is where the app is primarily interactive or where the content is a lot more likely to be real-time or ephemeral. Not least because if you're on a low-bandwidth or high-RTT connection, navigating between web pages or having interactivity blocked behind a backlog of XHRs (particularly where caching isn't permitted) is utterly miserable. My experience is that native apps usually continue feeling responsive to input even when the network itself is not responsive but that is often not true with many clickable elements in many web pages.
PWAs might be the middle-ground here but they feel a lot like Electron apps to me: still foreign to all platforms, not responsive in the way that native UI controls are, weird/missing "back" behaviours and still no better support for deep-linking than the average app would have.
The recent Facebook scandal of running a service to receive requests for tracking shows the app store sandbox model is far more of a denylist vs an allowlist, it's leaky by design in the name of "developer enablement" or "user experience".
Sorry for going off on a tangent, but last week I asked Gemini about security and privacy advantages of running Gmail and Google Calendar using Safari and DuckDuckGo Browser - Gemini made good arguments for using the browser versions: ironic!
I also avoid apps. I tell everyone that I meet to avoid apps because the general population is going to drive us right into a future where there are no more web-based options and almost everything must be accessed through a separate app. People are simply not aware of what they're giving up by using apps that would work perfectly fine as websites.
I just wish a culture of quality would become the rule and not the exception in web app development. It's a far more frequent thing for web apps to stutter and make my phone hot (or on a computer, keep an entire core pegged doing nothing) than it is for native apps to do the same. This experience is universal between browsers and platforms, too; I've observed it on Chrome under Android and Edge on Windows for example.
Of course there are plenty of crappy native apps too, but the incidence and severity is comparatively lower and in many cases, there are well-behaved "handcrafted" small dev alternatives to crappy native apps which are much less common (or at least, more difficult to find) on the web.
Need to have standardized native web components for the "culture of quality". Everyone building their own special widget in JS+CSS+virtual DOM Framework does not enforce UX quality.
Totally agree, it's the inevitable result of infinite wheel reinvention; none of the wheels ever receive the level of refinement they need. By the time the first stone wheel starts showing hints of a polished sheen, it's time to go carve a new stone wheel.
I'm a big proponent of browsers including something resembling a traditional UI framework out of the box. It doesn't have to try to be perfect or fit everybody's needs (which is impossible anyway), but it will serve many developers well and give everybody else a solid foundation to build their own (much lighter) stuff on top of.
You tell this to frontend experts and they are totally against it. "Lack of UI customization", "this is already possible", "you should skill up and learn web-tech", "use one of the popular (multi MB) component libraries", "we don't need more bad browser APIs", yadda yadda yadda.
The real reason is that most of them are afraid it would reduce the number of frontend jobs. But nowadays that is already being eaten by AI...
You should install F-Droid. lmoat every app on there is completely ethical, and there are many (not enough but many).
Many of the ones that require a server side connect to your self hosted server instead of some central server on the cloud, which is a reason they will never get popular, but sounds perfect for you. There are some that use central servers, and this fact will be clearly stated in the antifeatures section. Many other F-Droid apps just work offline. And hardly any have ads.
In almost all cases, phone apps talk to that same central server as the web browser, just with a different (much worse) client that you have less control over.
If it were the case that phone apps weren't networked and could only sync through another channel like icloud/syncthing, then you'd be onto something.
But right now most apps are "web browser but worse".
Native apps might need networking, Web apps require networking, they might simulate offline to various degrees depending on local storage, which they don't have any control over, and is shared.
What you want is a better (and easier to use) sandbox for native apps, so that users can feel as comfortable installing an app as visiting a web page as long as the app doesn't have any more permissions than the web page would have, and then you don't need central gatekeepers approving them.
Just because the US has consolidated many ISP's doesn't mean the rest of the world has. Also, even in the US, that figure is just under 2k. Globally, it is >16k.
Glad to see I'm not alone. I never install apps unless there's no other way, and often remove them as soon as possible. My home screen is a collection of web shortcuts. Amazon, YouTube, X, bank, all web links. But I also use LineageOS with MicroG.
I've been asked why, and it's not really fear of surveillance (although I'm not a fan of it) or making a difference or whatever, just because it's one of the few ways I'm able to give the finger. Sure, noone will notice but it makes me feel better :)
Personally I generally prefer the UX of apps for software that I trust, ie, open source software downloaded via F-Droid. I feel the same with native desktop clients. For untrusted software, web apps are the way to go.
I subscribe to the NYT and find it so irritating that they regularly prompt me to download their app from safari on ios I may cancel. I do not want their app ever.
I've been a web/ux guy for a long time now and I don't think I've ever used a single mobile app/site that is better than a proper full screen piece of software. It's always been a compromise no matter how hard myself or my designers try. Maybe quick photo/video edits but that's less because they're good or they have quality user experiences but more because its often overkill to pop open Photoshop just to cut out a dog pooping in the background or whatever. Most times I feel like mobile devs (myself included) don't even utilize the various unique features mobile devices do have.
I'm also old, cranky and turning into a crusty CLI guy as I get even older and crankier. If you kids need more than a TUI, get off my lawn!
PWA was an awesome idea and should have been the way forward.
Unfortunately both Google and Apple very early on identified that it was in their best interest to keep the concept around in a half-dead state and ensure nobody really built on it...
You get notification. You can autoplay video/audio. You get whaterver video or element full screen with all necessary UI. You get rotation lock. You have a fullscreen to do what ever you want for any purpose. You probably can't touch hardware APIs(for example: bluetooth/nfc) like native app. But that isn't really needed for most apps either.
On the other side. Apple seems sabotage the PWA as much as possible. You can't autoplay video/audio. You can't even fullscreen anything other than video, and when fullscreen video, UI is ignored. Also there is no way to disable gesture so your app will misfire system gesture. And you can't lock the rotation either. There is no way to auto rotate the video player or whatever when maximized either.
It's really a golden example for pretend to do something while actually not. It seems you can do pretty much everything with ios pwa. And when you try to do it. You will figured out it will have a worse experience than native app because all sort of issues.
To be fair, Android also sabotages PWAs, it's just done behind your back. You see, in order to get a PWA to properly install, you'll have to use Chrome, and you'll have to have a Google Play account and Chrome will submit the PWA manifest for validation to a Google server, which in turn will decide whether the PWA is worthy, and if it is, it will generate a so called WebAPK, which is then installed on your device. If it's not worthy however, then it will become a bookmark instead, and many of the features that can be described in the manifest will not work at all.
So if you wanted to use a different browser or install a PWA without a connection to the internet, or without Google Play, all you get is a bookmark.
In my personal experience, it only validate whether manifest is malformatted though. Although it's still up to google if they want to do something wonky.
I saw someone claim on SO that they were not able to get a PWA to install properly until they changed their IP address, supposedly because they were from Iran, a sanctioned country.
To my knowledge, every PWA installed from Firefox on Android will become a bookmark. For Firefox I believe that means for example that if you try to open a link elsewhere that is within the manifest scope, it will not open in the PWA. That's because it's not possible to deep link to the PWA without it having an AndroidManifest with a corresponding intent filter, which is what the Chrome WebAPK achieves and why they can support for example custom protocol handlers or share targets or launch handling options.
AS I said, YMMV. PWA install has seen many a regression. Last Android release it didn't work for me, this one it does. I presume a lot of it is due to ecosystem variations and API changes.
Google invented PWAs and broke their back trying to make them a thing. I'm not a fan of Google but credit where credit is due.
They were also highly incentivized to develop the APIs that make it all work as Chromebooks are basically hosts for browser apps. Apple, as well as the other tech giants involved in the W3C had no such incentives and were dragging their feet.
Admittedly I am not up to date on the latest developments but as far as a couple years ago the PWA runtime on both ecosystems was significantly stymied in comparison to the APP runtime. No access to real storage functionality, significantly less platform APIs, yada yada.
Sure, you could build "better (installable) websites" but even to get standardized stuff like background execution or notifications working was either impossible or a long series of jumping through hoops. Even installation prompts bugged out way too often.
But to be clear, if that isn't the case any more I will be positively surprized by either platform provider.
I respect PWAs, but they take away so much that I personally want. No address bar, no tabs, no history, no extensions. It's a reversion from the glorious amazing user agency of the web to the sad state that computing had held us victim to for decades.
They also don't require a dump truck load of third party dependencies just to have a serviceable set of widgets to use. Every time I start looking into web app development I'm always shocked at what's required to replicate what one gets for "free" in a UIKit app.
Swift doesn't need a service worker to proxy all browser behaviour, and make use of local storage, with unspecified limit, to prentend to be working offline.
You do realize that there are many APIs that exist so that your Swift app works offline, right? There are specific persistence frameworks, tools for controlling caching, extensions for managing external files, etc. The argument that writing JavaScript that doesn’t make network requests and needs to store state to disk is somehow super special and different than any other regular JavaScript makes no sense.
You do realize that neither do browser apps require having a network card on your laptop, right ? You can run local browser apps (HTML + CSS + JS) on a computer with no network card.
No, not at all. Lots of apps using the system webview nowadays. I would urge you to revise your deeply outdated knowledge. Lots of frameworks making this convenient too. Capacitor (Ionic) Apps, Cordova (PhoneGap) Apps, Tauri (non-Chromium modes), etc.
A network card is not required for:
- Loading local HTML files into a WebView
- Packaging an app that embeds the WebView (e.g., WinUI WebView2, macOS WKWebView, Android WebView, blah-blah)
- Running JavaScript, CSS, DOM APIs
- Using local storage, IndexedDB, etc
- Accessing file:// resources
- Communicating with native code (e.g., JS <-> native messaging)
Btw, there are a lot of non-Chromium apps! Are you aware that Microsoft Teams now uses the System WebView on mobile (iOS WKWebView / Android WebView) ?
Linux apps like GNOME Notes, Foliate, ReText, Liferea etc use the system webview.
Apple Music, Apple TV, Apple Podcasts, App Store, Dash, etc use WKWebView
let's say for the ICEblock or whatever - pull up a map pin (geotag), that can be done in a web app.
the things most people advocate apps for e.g notifications are nuisances that some of us permanently turned off. My phone is always on do not disturb, I get 0 notifications. The only time I prefer notifications is something actionable - I pay online then the bank says open app to approve in-app notification (pop up) not those things (notifications) that just come to your phone asynchronously and bother you.
I have a smartwatch (if at all) garmin it's not hooked up to my phone for notifications.
unless you're making games / hell now games can leverage webgpu - no reason to make native apps at all for 96% of things. just make a web app - service workers enable offline access for some things.
- my simple take -> do what the porno companies do in regards to tech. simple & effective. but please don't copy their ads thing.
Yep. Not using apps and avoiding the cloud at all costs (e.g. not backing up everything to iCloud, turning off one drive) are litmus tests for having a clue. Using Bluetooth is almost the same but it’s hard to get by without it nowadays. Same for connecting your tv to the internet.
"People in tech" has grown so large that the term has become a bit meaningless.
For every person in tech that knows who Stallman is and what he stands for, there's a person in tech that believes that NFTs and AI will bring about world peace and end poverty.
I'm disappointed by the EFF not mentioning PWAs and web apps. Fighting censorship means fighting for those too. Platform owners will always have more direct control over sideloading.
Using web versions, not apps, is important because companies keep user device statistics and if enough people insist in using web versions, the the web will continue to be at least partially supported by big tech.