My advice is to build such solutions around open products like Signal, XMPP or Matrix if possible. Or even Telegram.
On top of providing a better developer experience compared to Meta's ultra-locked and limited APIs, they aren't subject to the whims of a giant faceless company that can kill your product for no apparent reason with no chances of appeal.
Especially if you're doing these projects for folks in the developing world. Let's not lock them in proprietary American spyware like the whole West has already done :) from a user's perspective, if things are done properly, it'll just be a matter of installing another app.
And btw using a Matrix server with a WhatsApp bridge could also be a temporary solution to bypass the ban. But I haven't tested it with business accounts.
Signal is a closed centrally controlled network that has a hard requirement on users to pay money to centrally controlled telco providers to get accounts making it impossible to be legally anonymous in most countries. It is also very unfriendly to custom clients or automation. In those regards it is no different from WhatsApp.
I think you're ultimately correct, the trouble is the same as what advertisers discovered when they tried to do the same thing years ago.
Facebook owned the users. Similarly, WhatsApp owns the users.
The choice between:
1. Tying yourself to a platform that could boot you at any time, while also reaching all the users they already have
2. Bootstrapping something from scratch with 0 users, when all the users you want are already using said platform and have little incentive to leave
Choice 1 is often the only viable option, particularly if you're financially dependent on the results.
I also think we repeatedly see, even on HN, that "it'll just be a matter of installing another app" is actually a huge mental hurdle for many people - especially those who aren't technologically savvy enough to know how to use something that isn't Facebook/WhatsApp for communicating with people.
This reminds me of a thread a few days ago where I pointed out a similar thing you’re saying here. I think you make a strong case that, in the business context, this tie in is mandatory.
It’s all well and good taking a principled stance on not using FB/WhatsApp/etc. While you’re doing that, your competitors are selling out, using them, and getting to your customers more easily than you are. They might get cut off but that’s tomorrow’s problem, while your problem is here and now.
Indeed. If they are your customers, then it’s your job to work on effective communications. remember how we did it before the days of social media? It can be still be done- just learn the channels outside Facebook and establish points where the customers can reach you there. Make it painless and easy. That might mean managing your own support platform instead of using Facebooks for free.
While I don't enough about the problem domain and the app, "just don't use WhatsApp" is not necessarily helpful. The dev experience might be better, I dunno, but your product also needs users, and in my countries / communities, WhatsApp is the only thing they use, and meeting your users where they are is important.
Forcing your users to first install one more messaging app is going to cause people abandoning you immediately or slowly churn, which can make or break a product.
Then it sounds like the best business in those markets is to disrupt Whatsapp and educate users on the problems of relying on billionaires like Zuck for privacy.
WhatsApp has a critical advantage in Kenya from my experience: telecom operators such as Safaricom include quite generous WA bundles in their customers' subscriptions, allowing one to use it even though they would otherwise be out of credits. Being out of credits/airtime is not uncommon, since the economical bundles are sold as expiring in 24h/7d/30d.
It's more generic than that. If you build on other peoples turf or your operation depends on others you risk everything on a change of terms or a service vanishing entirely. The company could be big, could be small.
One classic joke is buying your competitors supplier.
As the developer of a GPS tracking app that relies a lot on OpenStreetMap, I've faced many of these problems myself. A couple of learned lessons/insights:
- I avoid relying on any generic location name/description provided by these APIs. Always prefer structured data whenever possible, and build the locality name from those components (bonus points if you let the user specify a custom format).
- Identifying those components itself is tricky. As the author mentioned, there are countries that have states, others that have regions, other that have counties, or districts, or any combination of those. And there are cities that have suburbs, neighbourhoods, municipalities, or any combination. Oh, and let's not even get started with address names - house numbers? extensions? localization variants - e.g. even the same API may sometimes return "Marrakesh" and sometimes "Marrakech"? and how about places like India where nearby amenities are commonly used instead of house numbers? I'm not aware of any public APIs out there that provide these "expected" taxonomies, preferably from lat/long input, but I'd love to be proven wrong. In the absence of that, I would suggest that is better to avoid double-guessing - unless your software is only intended to run in a specific country, or in a limited number of countries and you can afford to hardcode those rules. It's probably a good option to provide a sensible default, and then let the user override it. Oh, and good catch about abbreviations - I'd say to avoid them unless the user explicitly enables them, if you want to avoid the "does everybody know that IL is Illinois?" problem. Just use "Illinois" instead, at least by default.
- Localization of addresses is a tricky problem only on the surface. My proposed approach is that, again, the user is king. Provide English by default (unless you want to launch your software in a specific country), and let the user override the localization. I feel like the Nominatim's API approach is probably the cleanest: honor the `Accept-Language` HTTP header if available, and if not available, fallback to English. And then just expose that a setting to the user.
- Bounding boxes/polygons can help a lot with solving the proximity/perimeter issue. But they aren't always present/sufficiently accurate in OSM data. And their proper usage usually requires the client's code to run some non-trivial lat/long geometry processing code, even to answer trivial questions such as "is this point inside of this enclosed amenity?" Oh, and let's not even get started with the "what's the exact lat/long of this address?" problem. Is it the entrance of the park? The middle of it? I remember that when I worked with the Bing in the API in the past they provided more granular information at the level of rooftop location, entrance location etc.
- Providing localization information for public benches isn't what I'd call an orthodox use-case for geo software, so I'm not entirely sure of how to solve the "why doesn't everything have an address?" problem :)
The irony of watching this 2017 TED video in 2025, and find out that my NoScript extension reports half a dozen of JS trackers and ads providers on this page - including Google, doubleclick.net, sail-personalize and sail-track.
Oh, and if you navigate to this page without NoScript, AdBlocker or a PiHole DNS you'll probably be presented with a cookie consent banner, a bunch of ads on the page and before watching the video, and your data being shared with at least half a dozen partners (a number that can increase dramatically if you visit the page of any news outlet instead of ted.com).
So yeah, I guess that the message of this video aged like fine wine.
All the features you mentioned can also be achieved by a well developed PWA. Of course, minus the widgets or some deeper system integration (like controlling phone calls etc.)
There are cases like media apps, camera apps, videogames, terminal emulators, clipboard managers etc. that won't become Web apps any time soon.
Either because they need to operate closer to the OS, or for performance expectation reasons.
But I've just had a quick scroll through the apps on my phone, and I can confidently say that 90% of them are basically HTTP clients that interact with an HTTP server.
And even those that do more could probably be wrapped into a WebAssembly artifact with comparable performance in a near future.
The reason why they are not PWAs, and why engineers are often expected to do triple work (iOS, Android, Web), and why there aren't more products released as PWAs, keeps eluding me.
Sure, you have to tell folks how the "Install/Add to home screen" process works from a mobile browser, but is it that really that much more friction compared to an App Store paradigm to justify the abuse of native apps that either reinvent the wheel multiple times, or are just unglorified Web browsers running an Electron app just to show you the discounts at the supermarket near your house?
Heh, I was actually building one. Haven't considered the battery... Are the web audio APIs bad, or are you forced to use the CPU? I guess with webgpu it may be easier?
I think on iOS you need access on the CoreAudio level if you want to be efficient, ie fill audio buffers on a high priority thread with some lower level static language.
It doesn't sound like anything that a PWA (paired with some a sync mechanism like Websockets) can't solve. And with WebAssembly the convergence is even more compelling.
It depends on how much Firefox enshittifies. If it's just about removing some telemetry configuration from upstream, then a couple of downstream patches will still do the job. If, say, Firefox decides to fully embrace the spyware business model and drop support for Manifest V2 in order to kill adblockers, then LibreWolf will probably have to maintain their own fat piece of logic built on top of Firefox. Keeping it as a soft fork would then be a lot of work (you'd basically have a patchset of tens of thousands LoC to keep porting through different versions of Firefox). And making it a hard fork would be even more work (it basically means that the LibreWolf folks are on their own and they have to maintain their own independent browser).
If you hate Windows just use Linux, BSD or whatever.
I'm sick of all the "Windows 11 sucks" folks that yet keep using Windows.
Just boot your laptop from a Linux ISO and you've got the best way to bypass Windows 11.
Boycott Microsoft and everything it touches.