I am certain if I had the estimated $4,000,000,000 it took to get Voyager 1 launched, I could get some microservices to function regardless of all scenarios.
The reality is, its only worth it to build to 99.9999% uptime for very specific missions... There is no take-backsies in space. Your company will survive a microservice outage.
If this is true, why don't they go out of business? I just don't buy the argument that PE takes over businesses and makes them strictly worse. You don't make money doing that.
They will go out of business, in the long-term. What PE does is hot potato: they "trim the fat" off an existing business to goose up margins in the short-term, unload it to someone else, and that someone else is stuck with a business that's unsustainable long-term because that "fat" was actually resilience.
Sometimes, these buyouts are leveraged, with the company itself taking on the debt the PE firm used to buy it, so the PE's own risk is minimal.
That's the problem though. PE firms are stuck with billions and billions of dollars in businesses they can't cash out of because they have no other buyers than other PE firms.
That's why they are pushing the Trump admin to allow 401k funds to take over the toxic PE assets.
There are also a lot of PE strategies. Buying a class of small business and squeezing out value is one, but it's completely different from buying failing businesses and restructuring them, hoping for a turnaround.
Increased costs here, I assume, means to the customer, not to the business. PE buying up medical adjacent practices (vets, eye doctors, dentists) has been growing model over the last decade. They make money just fine because there's no alternatives, and manage to make both their employees and clients more miserable in the process.
You certainly can. It depends what kind of investors you can find. There is often a lag between the time sellers make changes to the business and the collective buyers' reaction to those changes, so if you can line up investors (whether it be equity or fixed income), then you can turn long term good will into short term cash for yourself.
For example, the business in the comment above might be selling veterinarian services, but the new owner's business is actually selling cash flow. The veterinarian services are just a means to an end, so it could be possible to take the built up good will and convert that to cash flow by cutting costs/raising prices in the short term, and then selling the new and improved cash flow.
You might ask, who would buy from this person again when they know the underlying business is being trashed? The answer is usually dumb money, such as defined benefit pension funds where the investor and the beneficiary are far disconnected. As long as it looks like due diligence happened, everyone can kind of get away richer in the short term with no one to stop them.
The hard part is lining up the investors, that requires being in the right networks.
Yes, there are some PE takeovers that are legitmately trying to improve things and generate more profit. You don't hear about those because it's not controversial. You only hear about the "slash costs and cash out" types of takeovers.
> I just don't buy the argument that PE takes over businesses and makes them strictly worse. You don't make money doing that.
The effects in health care were studied.[1]
Less competition supports higher prices. People can be convinced to purchase unnecessary services. People are slow to leave trusted doctors. Non compete agreements limit new competition. The time to train new veterinarians limits new competition. Short term profits fund future acquisitions.
In my town it works like this: Vets get taken over by PE, raise prices over time. People move to the old style vets. These are overwhelmed and can’t take more patients, so people have no choice but going to the PE vets.
Important extra step is that the market can't respond and increase capacity - it is increasingly difficult to set up a new vet clinic (nimby, local regulations, insurance, fitout costs) and so any existing vets who wants to roll their own usually can't get capital together to start a new clinic.
How many vet clinics do you know about? How often do you take your pet to the vet? Are there any “first visitors” events you need to do?
If someone is going to the vet once a year for blood work and a rabies vaccine; and there’s only like 3 in the whole city, you’re probably not going to rotate between them. What if the next one is even worse?
I have left a single vet over “bad behavior” and most of the other times it’s been over moving and things getting too far away.
The reality is most of their “getting worse” and “increased prices”, etc, is missed because most people come in once a year, so changes over time aren’t especially visible.
I have experienced it first hand so many times. You have to understand that PE comes in with an exit plan. They most often do not plan to hold the asset beyond 5, maybe 10 years max. Their goal is to come in, extract as much money as possible in the short term to recoup the expense, and then sell off the remaining assets for whatever they can get for it as a cherry on top.
How do they extract as much profit as possible? Because wouldn't the previous owner have tried to, you know, make as much money as possible? Yes, but PE firms have more capital and scale and will specialize in a certain type or types of business to maximize impact.
Here's how it works:
1. First the PE Firm will focus on a business type - maybe it is auto repair shops, maybe it is pediatric clinics, maybe youth sports facilities and leagues. It doesn't really matter. What matters is that they will buy a lot of them.
2. Now that they own quite a number in a certain geographic area, maybe even most of that type of business they have leverage over customers, employees, and sometimes suppliers. The PE playbook dictates they first cut costs wherever they can. Reduce staff, add surcharges and fees, negotiate better prices with suppliers.
3. The businesses are now operating at a slightly higher margin, which is great, because the initial capital outlay was huge and they had to pay a premium because no one really wants to sell to PE. So over the next 5 years or so they need to make all of that investment back and they usually will. They might lose some employees and some customers, but people hate change and most will stick around even though service is a bit worse. And anyway, who cares, their profit margins are now nice and padded.
4. It has been 5 years and now their businesses are really starting to show signs of cracks. It is getting harder to find competent onsite management who will put up with the terrible work environment. Customers are leaving. Some of those employees are starting their own shops. But who cares, the money has already been made back. Now is the time to sell before the whole thing implodes and if it already has imploded, well, that is less than ideal, but there are still assets to sell. Sell for whatever you can and walk away. The PE firm netted slightly higher than if they were to invest in the stock market. Could they have made even more by just running competent businesses over the long term? Maybe...but that would have required a lot of time and active management and no one wants to do that, so on to the next venture.
This! All day long.
For a minute Pre-COVID and the inevitable reassessment of my life choices, I was a Private Equity fund manager for a International PE org with significant assets in a wide spectrum of energy technology and agriculture ventures.
We operated with a slightly different approach; leveraging long term lease back of land and physical resources to the original operators with caveats, such as transitioning to Organic Certification and Cost Effective Staffing - read that as Wallpapering the Products' Perceived value while shorting the personnel costs through under-staffing and underpaying - with some real improvements which included international market access and lower ecological footprints by ceasing deforestation for expansion and removing toxic petrochemical fertilizers, herbicides and insecticides from the operations which are actually beneficial to both employees and the community.
However, the standard modus operandii in the industry was and still is some flavor of this get in, grow, leverage, and then exit approach.
Individual operations' access to low to no interest financing for OPEX and CAPEX was a fundamental uplift to the value of those operations. There existed the possibility of leveraging the organizations' histories to secure low-to-no interest loans equal to the estimated market value of those operations; spend that money to expand and partially offset the cost of acquisition (protecting the investment funds from market volatility) and leverage those expansions to reduce competition through assimilation or under-pricing the competition.
Often the 'exit strategy' can include sell-off of physical assets to cover the loans; or folding the organization and defaulting on outstanding loans.
The fund never actually has to be at risk, the upsides are up-front during the stage wherein the public sees the 'investment' into expansion of or improvement of goods and services before the inevitable degradation due to under-staffing and cost cutting through volume renegotiation or through changing suppliers and processes for cheaper and less effective inputs. When customer satisfaction and employee burnout reach a crescendo... move on.
The end for me was when the organization decided to use COVID as an excuse to cut an entire environmental tech development team from payroll; with zero benefits and the expectation that local government to provide the entire cost of team members and their families' survival, while selling the technology invented and being developed by those team members for approximately one dollar to show as great a loss as possible.
PE is at least as big a blight on the global economy and community well being as joint-stock monopolies serving a few majority shareholders.
Working at a company that uses react-native I wish nothing more than for the end of app stores and differing platform languages.
We're heavily considering just having a website next year with a mobile app using webview, and then native code for the native notifications, GPS and healthkit / health connect.
I feel like AI is changing the equation, its nearly better to write your business UI 3 times one for each platform.
It’s called a “WebView app” and you can get a really good experience on all platforms using them. Just:
- don’t make any crazy decisions on your fundamental UI components, like breadcrumbs, select dropdowns, etc
- add a few platform-specific specialisations to those same components, to make them feel a bit more familiar, such as button styling, or using a self-simplifying back-stack on Android
- test to make sure your webview matches the native browser’s behaviour where it matters. For example, sliding up the view when the keyboard is opened on mobile, navigating back & forth with edge-swipes on iOS, etc
I also went the extra step and got service workers working, for a basic offline experience, and added a native auto network diagnostic tool that runs on app startup and checks “Can reach local network” “Can reach internet (1.1.1.1)” “Can resolve our app’s domain” etc etc, so users can share where it failed to get quicker support. But this is an app for small-to-medium businesses, not consumer-facing, and the HTML5 part is served from the server and cached. I haven’t thought much about what you might need to do additionally for a consumer app, or a local-first app.
It’s because if a webview app experience is good, you don’t notice it, you only notice if it’s bad.
A while ago saw a blog link on HN that explained how Apple uses it everywhere and we never notice it because they are done well. Of course I can’t find that link now, I summon the HN gods…
On mobile the webview app experience is crap and it's immediately obvious that an app is not native. Simply nobody asks customers how they like it. The management assumes that as long as nobody complains and the users don't leave in droves, the experience must be impeccable.
It's often easy to tell, but my concern has shifted from "Why isn't this native? It's ugly/slow" to "Why isn't this a goddamn webpage? It can't justify neither its permissions nor its space".
> It’s because if a webview app experience is good, you don’t notice it, you only notice if it’s bad.
Aside from Apple’s apps (which imo are noticeably worse than the old ones, but that’s beside the point), what are some good WebView apps on iOS right now?
Somebody scraped the play store and checked the framework, so a list for Android WebView apps, built with capacitor, is here: https://capgo.app/top_capacitor_app/ Maybe an equivalent is there on iOS for the same app...
lichess is really good. Thanks for the info, I'm not surprised to learn it's a webview app, but it is really good.
It doesn't look native but who even cares. I think when a UI sucks or is unintuitive or buggy then "it's not native" is a sort of catchall easy complaint. Native is a crutch. Sometimes it's a good crutch (accessibility etc). But that's more about developer efficiency and bare minimums of polish.
Sadly i couldn’t find a reliable way to do it on Apple Store, it’s pretty hard to download from the store outside of apple device. If anyone know how i can do it too
Yes, Apple's apps are really really bad - including the app store. I am not even sure whether that app store can be considered a stand alone app or we should call it part of the OS.
A webview app is by design bad. Webviews were made for one thing - web views.
The app store is the only application that I am aware of that you can't find through spotlight search. You can search the app store directly from spotlight search, but it will never list the App Store as an app. Very annoying.
Thanks for this comment. I was able to fix this issue, finally. Had to toggle the switch in setting> apps> App Store > search and restart my devices. :)
I thought it was some legal thing about App Store competition.
> It stands to reason that Apple wouldn't have developed this feature [liquid glass css property] if they weren't using it. Where? We have no idea. But they must be using it somewhere. The fact that none of us have noticed exactly where suggests that we're interacting with webviews in our daily use of iOS without ever even realising it.
There's some jump from _a property exists_ to _it must be used_, but a massive one from _a property exists_ to _Apple uses it everywhere and we never notice it because they are done well_.
It is immediately obvious when you are using a web view app, as it uses browser layout and non-native controls. And I have never found one to be as intuitive or nice an experience as native controls.
If Apple are using it for the AppStore - then I defo Italy do notice it. The AppStore runs so badly.
I would be interested in any links to Webview apps that run really well, I’ve never seen one that I’m aware of but so many that I am aware of and are bad!
I've done it before on a personal project and I was pretty obsessed with user experience. For example, I changed the way buttons work (because they were natively links with Cordova, which trigger upon tap, not "finger lift", like native buttons). Also, implemented some gestures to e.g. switch between pages (tab-style navigation). While not really in line with system UI (wasn't my goal), I think usability is quite decent.
I have experienced the opposite with Zed, which has its own bespoke UI framework - it behaved somewhat unexpectedly and didn't work exactly how I'm used to an UI to behave giving me this uncanny feeling.
This kinda shows you how much effort and experience goes into getting an UI framework right, and the long tail quirks (of which there are a zillion) matter for UX, and while I appreciate they took on the task of breaking away from the browser, it's understandable why someone wants to ship an app on time and budget goes with a web based solution.
Sorry if that wasn't clear, that was the point I was trying to make - Zed's UI worked oddly for me in subtle ways that I can't really give an example of right now, but created a sense of discomfort that made me give up on it after a short while.
I use Voyager, a client for Lemmy, on a daily basis and it’s my favorite mobile (iPad) app. Voyager is the spiritual successor to the Apollo client for Reddit.
The app uses Ionic’s Capacitor, which to my rudimentary understanding is the webview-based upgrade of Cordova. I’ve had far fewer issues with this app than the likes of Bluesky (react native) and Discord (I think also react native but not sure).
The webview approach seems to be the only way for a one-person team to feasible provide a cross-platform app with an app-store presence. Another promising alternative to Capacitor is Tauri Mobile which does essentially the same thing, but mobile doesn’t seem to be a high priority for them.
I installed this on Android, and unless iOS experience is massively different, this is not a good example:
- there's no touch feedback (ripple) on many of clickable components. Some that do have it look non-native, inconsistent and sometimes gets stuck
- the search bar on top app bar in `search` tab looks very non-native and non-standard (it's elevated on top of elevated app bar already)
- the lists look iOS-y, especially settings
- the settings list item has weird glitch where it loses background after touching (but not clicking)
- collapsing comments is pretty choppy (on a Samsung S25 so a pretty powerful phone)
- can't swipe down a bottom sheet (with post options/actions)
- it's just not android-y — the navigation is weird, the design is all over the place,
It's not unusable and it's a good tradeoff for a small team I guess. But this is nowhere near the experience a native app can provide, and has lots of small papercuts that would make for at least a slightly frustrating experience. It is a decent app don't get me wrong, but it's clearly not native
Like GP I haven't experienced many WebView based apps that are great so I had to give this a spin and I have to say it's actually pretty good! I would not have identified this as a WebView app if I didn't already know about it from this comment.
You are comparing web view apps to web view apps. “React Native” has muddied the waters here with intentional misuse of terminology. With React Native you still write a web view app - it just ahead of time compiles to run without the browser view on device. But it doesn’t use any native UI components, which is what “native app” used to mean.
I may have read your comment backwards but it seems rather wrong: react native DOES use native UI components, thats why it has “native” in its name. It’s also not compiled ahead of time per se, you still execute JS in the app (not in webview, yes) , but its mapped to native components
Thank you, it appears I was misinformed and/or conflating my knowledge of how flutter works. Mae culpa.
It does seem that many RN apps do React (not native) components when they need to do something custom, which may explain my sub-par, non-native experience with the RN apps I have used.
Even something “custom” is still a native component. The JSX you write eventually creates native views. Whether or not those views and components match the style and behavior of stock iOS or Android is a different story, and whether or not there are performance bottlenecks due to React Native’s bridge (now in theory no longer an issue because of a big architecture rewrite called Fabric) is another.
Well you haven't used the cutting-edge latest breed. Try using Uber in a browser. There's many high-quality apps today where you honestly cannot tell that it's a website running in a browser. There are many many more but I can only think of Uber off the top of my head.
Do you use iOS by any chance? On android I've very noticed performance problems. Even in apps like Discord and Instagram. But Google maps and Duolingo are pretty bad at times for example. So it's not webviews that are the common denominator here
Gathering all the metaphors (I know) here for reference:
- "All toupées look fake. I've never seen one that I couldn't tell was fake." [1]
- All CGI in movies looks fake. It jumps out at me every time I see it."
- All WebView apps suck. Every one I've seen has a bad obviously-web-derived UI.
re: that last one though -- I'd at least acknowledge that WebView apps are roughly at the end of the early-2000's era of CGI: not exactly "The Rock in The Scorpion King" bad, but generally not at the level of Avatar or Les Misérables.
Using webviews on native platforms can look very appealing from a management perspective: a single codebase, simpler coordination, reduced UX overhead, and faster iteration cycles.
However, from the user's side, this approach often results in a buggy, inconsistent experience that lacks the responsiveness and smoothness of a true native app that elusive "snappy" feeling (i know, I hate that word too)
Companies usually choose this route because it's cheaper, but that same "cheap mentality" often seeps into the overall product quality. Corners get cut, bugs get ignored, and long-term maintenance becomes a mess.
From a developer's perspective, it's a nightmare
You're essentially expected to deliver on three platforms doing the work of three people for the same $
In theory, any web developer could handle it. In practice, you need to understand all the native platforms just to maintain some basic, stable integrations even with frameworks like React Native.
The result?
Maybe 20% of your time goes into actual feature development, 30% into testing, and the remaining 70% into fixing obscure, platform-specific bugs while working overtime under pressure from cost-driven management.
In my experience, developers will do almost anything to avoid dealing with the native parts of this kind of setup those tasks usually get dumped on whoever is most "familiar" with native, because it's such a pain to handle.
And let's not forget QA testing across these hybrid layers is an absolute nightmare as well.
In the end, my view is simple:
If a company can't afford dedicated native teams, they probably shouldn't build a native app.
(Of course, smaller apps with limited complexity should be fine)
This comments spot on. Coming from a guy that used to do mobile professionally as a one man show where the company had multiple apps and multiple stacks. I had the least pain from the ionic stack which I guess is a happy middle ground, but even then there's always some new app store requirement changes to adhere that's almost a full-time job in itself.
Trust me, native camera access is extremely important if you need to directly control focus (for example). We have web and mobile apps that scan ID images and our ability to capture high quality images on mobile native devices is 5x better.
You can still have native views that appear over the WebView for certain tasks. I think you can also provide your own rendering context for <canvas> elements, so you could roll your own <video> element for showing the current camera view. Either way, you can still have full native camera control without having a 100% native app.
Isn't there a high chance your app is going to be rejected from app stores because you use a web view? You can change your whole app completely upon approval.
Or you ship your HTML/JS and not just embed a URL?
I just rolled my own. I always find frameworks bring too many “weird errors” that waste my time trying to figure them out. Also, they’re just another thing that needs upgrading eventually, and they love to COMPLETELY change their APIs between each major version. (“FrungisFactory is deprecated! Try the new async-fibre-layout BloopisGrid now before we completely delete that thing that worked perfectly for you!”)
The platforms provide more than enough capability to build basic WebView apps with minimal effort, and usually the DX is good.
Native escape hatch, for when you need native capability. For example, my app uses the Zebra DataWedge API on Zebra Android devices.
Native experience for users, where the app appears in their app drawer/library. The app doesn’t disappear randomly like shortcuts do on iOS (maybe this is fixed now?).
Better DX for certain features, like notifications, storage, control of caching, local network device access, etc.
That. And specifically, fuck Apple and their prohibition on JITs.
We have a React Native app that shares some code with a webapp, and that needs to do some geometry processing. So we're constantly playing the game of "will it interpret quick enough". Everything works fine in browsers, but in a RN app it often slows down to unusable speeds.
Could your processing work in a webview? i.e. webgl or webasm or similar and you communicate with it via postMessage. Something like Polygen might help with the scaffolding, but I have not tried it personally
Using apps made with Electron or those so-called "universal" UI frameworks I wish nothing more than for everything to be native.
They always have to give up some basic or hidden conveniences that native controls get for free, so they always feel slightly different and "off" in a weird way which induces a constant vague annoyance while using them, like walking with a little pebble in your shoe, or a sitting in an chair that isn't balanced right.
It's funny how even after 50 years UI still isn't "solved" ..before writing a universal API, we don't even have universal consensus, or at least some kind of standards authority, on how controls should behave.
Hell not even users can’t agree, as would be seen on any comments about this topic, on stuff like whether lists should scroll up when swiping down, or scroll down when swiping up :')
I started with desktop applications, so my go-to for GUI has been Qt, especially QML. It works on Windows / MacOS / Linux as well as iOS and Android. I think there’s now a way to compile QML to webassembly as well. It also has a ton of support classes that are loosely analogous to the various *Kit things supplied on iOS and Android.
The downside is that the core of Qt is in C++, so it’s mostly seen (or used for?) embedded contexts.
I recently used Slint as well, which isn’t anywhere near as mature, but is at least written in Rust and has some type-safety benefits.
SwiftUI is pretty good too, and I wish I got to work on Apple platforms more.
To me, the simplicity of creating a “Button” when you want a button makes more sense, instead of a React component that’s a div styled by layers of CSS and brought to life by JavaScript.
But I’m kind of bummed that I started with that route (well, and writing partial UI systems for game / media engines a few times) because most people learned web apps and the DOM, and it’s made it harder to get the kind of work I identify with.
So it’s hard for me to recommend Qt due to the career implications…but at the same for the projects I’ve worked on, it’s made a smaller amount of work go a longer way with a more native feel than electron apps seem to have.
If you still need to wrap a cross-platform web experience in a native container, I really begin to lose the plot. Once you are engaged with the iOS code signing monster, you might as well go all the way into the ecosystem.
To me, the web is the way around the app stores and codesign. I know how to visit HN on my iPhone despite there not being an official native app for it. It can work. The challenge is making it work in your particular case. Fear that the user wont know how to access the product seems to be a primary factor driving hyperbolic takes on how consumer apps must be built. Perhaps a bit of marketing budget (scan this QR code / visit this link) could eliminate a very expensive tech problem. Why fight visibility in the crowded App Store when there are countless other advertising channels you could pour your resources into?
> native code for the native notifications, GPS and healthkit / health connect.
Modern web can address everything here but the HealthKit item. You could consider handling this with a simple companion application that is exclusively about the collection and transfer of the data while respecting user privacy & consent procedures.
Push notifications and mental real estate by being “an app” are the primary business reason (based on both statsig experiments I’ve seen across my career as well as some intuition about behavioral psychology regarding the app mental real estate bit).
I try this every decade. Love the first few months for speed. Then I end up paying the price later when I want to integrate "new OS feature X" or make a system gesture/style/animation feel native.
Lack of swipe for back on iOS is usually the easiest way to tell I'm looking at a web view.
I see some downvotes but you're correct. For example, in the App Store feature cards swipe left only bounces the card, you have to keep swiping to close. Swipe down closes it at once. It's not that far from the usual but has always felt strange to me. This same gesture won't close Home's new accessory card.
> its nearly better to write your business UI 3 times one for each platform.
Anyone have any experience of doing this for a complex and long-life app?
Sounds like a nightmare that would increase friction and decrease development fun by x10 because of the huge overhead and tedium of having to keep your features and tests in sync across platform for every change you want to iterate on, and requiring developers be proficient at multiple stacks.
I get the usual complaints about bad webview implementations, but separate native codebases sounds like a prohibitively enormous tradeoff if most users only perceive the UX as being a little better than a good webview implementation. I feel like I'm missing something that native codebases is suggested as if it's a simple alternative, or this is coming from people that aren't actually involved in this?
You don’t do that though. You write your logic in a common languages and then the UI is an external layer you switch with build settings. The thing is, yiur choice is usually c|c++. Or an embedded language like lua. RN has gone the latter route and then extend it further by using React as a DSL for the UI.
> You write your logic in a common languages and then the UI is an external layer
Isn't reimplementing all your UI widgets, views, layouts and interactions for multiple platforms still a ton of work though? I'm not meaning people using things like React frameworks, but the suggestion of sticking to native only.
If you do that, then you intent to take advantage of the native framework (or a mature one like qt for some platform). They are really expansive and you can create an interface very quickly. You usually get animations, themability, navigation,… for free and you’re mostly arranging the layout and writing glue code.
Also, you usually get better tooling in regards to instrumentation and the like.
I can share a bit on this one.
I’m doing hybrid apps for the last 8 years and stick to Cordova on my day job but also tried Flutter and RN for a bit.
As I’ve seen some other comments about the iOS/Android look and feel (swiping gestures, etc.), Ionic (or the Cupertino package in Flutter) is the way to go. Without this, it would be a lot of trouble. However, as the recent iOS 26 update has shown, neither Ionic nor Flutter is going to support the new liquid glass design (yet). Since we never went with “our app must exactly match the (apple) design guides” this is not a problem for us but I’m sure others would love to be able to adapt the new liquid glass style.
I also never heard of any app being rejected due to being a hybrid app or not having the correct look and feel. Of course, you might see/feel that it’s not a native app but who cares.
Back in the days we even used a OTA plugin (it was a MS plugin, don’t remember the name) to automatically ship new .js/.html files without going through the review process. If I remember correctly Ionic still provides something like this.
When it comes to native stuff it get’s tricky. As always it really depends on the use case of the app. In our case we develop a navigation app using a native SDK to show a map + turn-by-turn nav + offline maps etc. This is probably the most non ideal use case for a hybrid app. We developed a few plugins to share data between js /native to initialize the map etc. However, the idea of sharing business logic is long gone. There’s so much stuff that’s happening natively and each time we implement it on Android, we have to switch to iOS and implement the Swift version of it.
Some others have also mentioned that a single person now has to know three platforms (iOS, android and Cordova (in our case with ionic + angular). This is true and the real downside. I’m quite familiar with iOS and android yet I’d never call myself a native iOS / Android developer. Yet, I’ve to write so much native code regarding permission handling, geolocation, threading (Ui/non-ui) and there’s always a ton to stuff happening from version to version (e.g. 16 KB Page Size on Android, iOS support for rotation the device/adaptive layout on iPadOS, etc). This is where a lot of time is lost. And the time is not only lost there but also with unmaintained outdated community plugins you suddenly need to understand and fix.
As a corollary, working with RN quite a lot, we just built an app for a client that was end to end finished and fully approved to both apps in a month, including pretty deep feature work and redesigning multiple screens. It includes the latest liquid glass native UI as well.
RN is a mess to get into, but once you've found a good stack you can really fly. We are working on a starter kit based off our experience that I think should represent the best possible starting point once it's released sometime before the EOY.
I recently downloaded the Moodle app and was surprised to find it's powered by Ionic and a webview, which I only realized due to CSS misconfigurations that caused the app to fall back to Serif font for CJK glyphs.
Recent mid-tier phones are powerful enough that webview has a negligible impact on performance.
I personally have a preference for Apple's native frameworks. From a purely engineering standpoint, they're very well thought out and have very clear separations of concerns. Spending my time with their libraries helped me write good, scalable code for platforms beyond their own.
That said, platform lock-in is bad for business because it makes operations dependent on a single provider, but I have no delusions that a web front-end is better.
From an engineering standpoint, front-end web frameworks are less complete and require too many third-party libraries and tooling to assemble. From a UX standpoint, it's actually worse--almost every website you visit today spams you upfront with Google sign-in and invasive cookie permission requests that you can't refuse. But never mind that--from a purely business standpoint, a single platform accessible anywhere saves costs. Most importantly, however, the web is a "safe space" for deploying software anti-patterns without an intermediary entity (i.e an app store) to police your code, so you can do whatever the heck you want.
I'd wish for nothing more than the end of web and app front-ends in favor of purely structured data derived from natural language prompts by users. However, the more realistic mindset seems to be that: the front-end layer is such a high level of abstraction with a very low barrier to entry, so that its tech stack will be in constant flux, in favor of whoever's currently the best-financed entity seeking the most market share, the most developer mind-share, and the most behavioral control among its users.
Their Cocoa based frameworks were good for their time, I'll grant you that. Swift & SwiftUI, at least in their current state, are a mess with some pretty fundamental issues.
CapacitorJS makes for a REALLY awesome app dev experience compared with React Native. It's basically just a really well integrated system for building exactly what you describe. The company I work at made the switch from an RN app to a CJS one and it was might and day in so many ways, performance included!
Unfortunately, all too often not enough. But then again often one has UX designers for that, but they are all too often off to build flying castles in Figma.
Visual design is only one part of UX- interaction design and information architecture are equally important components.
At my last two jobs, when I did v front end work I had to coach designers through UX on a regular basis, because the designers did as much for the marketing department as they did for the development team.
Sadly, UX as a discipline doesn't get much love from most companies.
Most of UX design for the past ~15 years has been new and innovative ways to trick users, lie without really lying, and annoy your users just enough so you can extract what ever you need to extract, but not too much such that they actually leave.
If you want to create good UX, I would look at whatever the big dogs are doing (Amazon, Meta, Google, et. al.) and not do that.
AI doesn't change the Apple Guidelines, I write my business UI once and translate it between React Native and React using an LLM
4.2 Minimum Functionality
Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or “app-like,” it doesn’t belong on the App Store. If your App doesn’t provide some sort of lasting entertainment value or adequate utility, it may not be accepted. Apps that are simply a song or movie should be submitted to the iTunes Store. Apps that are simply a book or game guide should be submitted to the Apple Books Store.
So you can get native behaviors when it’s critical. Like share sheets, push and many other critical features that only apps get even if the bulk of the experience can be done in a webview. This is because mobile OS platforms choose not to make these available to web apps, because app store profits are better for them than an open ecosystem where sites can do the same things as apps.
It's rarely better to write the business UI 3 times for each platform.
At the time such decisions are made, maybe the platforms couldn't do what was needed, but those platforms do tend to evolve, but not remain tracked.
Flutter to me has been one of the platforms that can quietly ship to multiple platforms as long as the parameters of what you're after can be accomplished in Dart, and if needed a bit of custom code for any particular platform.
With the first iPhone Steve Jobs wanted a web based future.
Then jailbreaking got us native apps and AppStores and the rest is history.
I still remember my Nexus One running flash!
Anyway, I wonder if the web path would’ve been the chosen one, how Apple would’ve played the web standards that are crippled today especially on Safari.
The <canvas> tag using webgl offers a lot lower access to buffers than you might imagine and is very accessible using JS/DOM. I've gotten surgical AR devices approved from FDA - if it works good enough for life or death situations - it can certainly work for a toy app.
I had an internship at HP when I was 16. I probably wasn't particularly useful, but I learned a lot about how the corporate world works. I'm glad I didn't have to wait until I was 18 to figure that out, and get on the right course for my education and career.
One of my high-school friends went to college for a teaching credential, only to learn at the end that he didn't like teaching.
College or not, it's extremely useful to be exposed to a field of work for at least a few months, before dedicating years if your life to it.
In defense of foobarian AFAIK driver code is famously the lowest quality code of just about any domain, even worse than academic code. The software is written by cost cutting hardware companies.
Everyone who has had to work with printers in a enterprise/production environment knows this... I'm amazed it's an industry that hasn't been disrupted. cough
As someone who has had to support printers.....its a spectrum of pain from "god why do they do this" to "I'm pulling hair out, because no sane person would want to use this product willingly"
We've officially lost the plot, we will now ship our AI data centers to ~space~ ... This will not work with modern technology.
The sun will be eclipsed by earth many times per day, requiring you to either shift all workloads or add substantial UPS weight. The radiator grid you need to cool 125kw is something like 16x the size of the entire data center.
I watched this video last week that went into 3 different scenarios, it's a good watch.
That is assuming you need that 1 core 24/7, you can get 2 core / 8gb for $43, this will most likely fit 90% of workloads (steady traffic with spikes, or 9-5 cadence).
If you reserve that instance you can get it for 40% cheaper, or get 4 cores instead.
Yes it's more expensive than OVH but you also get everything AWS to offer.
API responses should be limited to authenticated users. IDs are often present in hyperlinks that are included in insecure emails, or in URLs that, being routed through all sorts of networking hops may be captured and available as metadata.
I feel like this is left out of the story too often - people tend to compare the most optimistic "self-hosted", usually just one or two servers at best, to a less than ideal cloud installation.
My parent company (Healthcare) uses all on prem solutions, has 3 data centers and 10 sys admins just for the data centers. You still need DevOps too.
I don't know how much it would cost to migrate their infra to AWS, but ~ $1.3M (salary) in annual spend buys you a ton of reserved compute on AWS.
$1.3M is 6000 CPU cores, 10TiB of RAM 24/7 with 100TB of storage.
I know for a fact due to redundancy they have no where near that, AND they have to pay for Avamar, VMWare, (~$500k) etc.
There's no way its cheaper than AWS, not even close.
So sure someones self hosted PHP BB forum doesn't need to be on AWS, but I challenge someone to run a 99.99% uptime infra significantly cheaper than the cloud.
I didn't try to hit that because that's harder to call, especially at a small startup. If what is probably "the guy doing all this" happens to be more comfortable with k8s than the AWS stack you can end up winning by going with a nominally more complicated k8s stack that doesn't force you to spend dozens of hours learning more new things and instead just using what you already know. For a small startup those training costs are proportionally huge compared to a more established larger going concern already making money. Startups should generally always go with whatever their engineers already know unless there is a damned good reason not to. (And "I just wanted to learn it" is not a good reason for the startup.)
But monetarily, even for a startup, $400/month savings is something you shouldn't be pouring the equivalent of $5000 (or more, just picking a reasonable concrete number to anchor the point) into. You really need to solve a $400/month problem by putting your time into something, anything that will promote revenue growth sooner and faster rather than optimizing that particular cost.
If your parent company sysadmins invest heavily into automation each sysadmin could be managing thousands of servers.
Also, 6000 CPU "cores" on the cloud is more like 3000 CPU cores. Which you can get in just 20-50 servers. This is in the range of something that could be taken care of as a part time job.
Exactly this. I know people don't like to use this term (because it comes from traditional IT), but this is effectively known as TCO (total cost of ownership). The whole "bare metal" versus the well known hyperscalers debate often misses this with a hand-wavy "just get better devops people and its cheaper".
The reality is, its only worth it to build to 99.9999% uptime for very specific missions... There is no take-backsies in space. Your company will survive a microservice outage.
reply