But as a user of computers and occasional native mobile app developer, hearing "<500ms screen load times" stated as a win is very disappointing. Having your app burn battery for half a second doing absolutely nothing is bad UX. That kind of latency does have a meaningful effect on productivity for a heavy user.
Besides that, having done a serious evaluation of whether to migrate a pair of native apps supported by multi-person engineering teams to RN, I think this is a very level-headed take on how to make such a migration work in practice. If you're going to take this path, this is the way to do it. I just hope that people choose targets closer to 100ms.
When the user clicks a button, we start a server round-trip and fetch the data and do client-side parsing, layout, formatting and rendering and then less than 500ms later, the user can see the result on his/her screen.
With a worst-case ping of 200ms for a round-trip, that leaves about 200ms for DB queries and then 100ms for the GUI rendering, which is roughly what you'd expect.
Also, even if it was involved, 200ms for round-trip and DB queries is complete bonkers. Most round-trips don't take more than 100ms, and if you're taking 200ms for a DB query on an app with millions of users, you're screwed. Most queries should take max 20-30ms, with some outliers in places where optimization is hard taking up to 80ms.
Never lived in Australia I see
You could do the maths on conversion rate increase if that latency disappeared vs the cost of spinning up a dc & running it (including the mess that is localised dbs)
I’m not sure the economics works out for most businesses (I say this as an Australian)
Most queries are 20-30ms. But a worst case of 200ms for large payloads or edge cases or just general degradations isn't crazy. Without knowing if 500ms is a p50 or p99 it's kind of a meaningless metric but assuming it's a p99, I think it's not as bad as the original commenter stated.
Realistically 50ms p75 should be achievable for the level of complexity in the shopify app.
I personally wouldn't be very happy with a P75 of 500 ms. It's slow.
time curl -o tmp.del "https://news.ycombinator.com/item?id=42730748"
real 0m1.427s
"if you're taking 200ms for a DB query on an app with millions of users, you're screwed"
My calculation was 200ms for the DB queries and the time it takes your server-side framework ORM system to parse the results and transform it into JSON. But even in general, I disagree. For high-throughput systems it typically makes sense to make the servers stateless (which adds additional DB queries) in exchange for the ability to just start 20 servers in parallel. And especially for PostgreSql index scans where all the IO is cached in RAM anyway, single-core CPU performance quickly becomes a bottleneck. But a 100+ core EPYC machine can still reach 1000+ TPS for index scans that take 100ms each. And, BTW, the basic Shopify plan only allows 1 visitor per 17 seconds to your shop. That means a single EPYC server could still host 17,000 customers on the basic plan even if each visit causes 100ms of DB queries.
Also, Postgres has supported parallel scans for quite a long time, so single-core performance isn’t necessarily the dominating factor.
And being not logged in - probably a poor comparison with Shopify app.
Anecdotally, I’ve been playing AoE2: DE a lot recently, and have noticed it briefly stuttering / freezing during battles. My PC isn’t state of the art by any means (Ryzen 7 3700X, 32GB PC4-24000, RX580 8GB), but this is an isometric RTS we’re talking about. In 2004, I was playing AoE2 (the original) on an AMD XP2000+ with maybe 1GB of RAM at most. I do not ever remember it stuttering, freezing, or in any way struggling. Prior to that, I was playing it on a Pentium III 550 MHz, and a Celeron 333 MHz. Same thing.
A great anti-example of this pattern is Factorio. It’s also an isometric top-down game, with RTS elements, but the devs are serious about performance. It’s tracking god knows how many tens or hundreds of thousands of objects (they’re simulating fluid flow in pipes FFS), with a goal of 60 FPS/UPS.
Yes, computers today are doing more than computers from the 80s or 90s, but the hardware is so many orders of magnitude faster that it shouldn’t matter. Software is by and large slower, and it’s a deliberate choice, because it doesn’t have to be that way.
If you buy poor software instead of good software (yes, branding, IP and whatever but that's just even more reason for companies not to make it good), complaining doesn't help does it. Commercial software is made to be sold and if it sells enough that's all company executives care about. As long as enough people buy it, it will continue to be made.
Company devs trying to get more time/resources to improve performance will be told no unless they can make a realistic business case that explains how the expense of increased focus on performance will be financially worth in terms of revenue. If enough people buy poor software, improving it is not business smart. Companies exist to make money not necessarily to make good products or provide a good service.
I understand your point but you need to understand that business execs don't care about that unless it significantly impacts revenue or costs in the present or very near future.
Tech interviews are wildly stupid: they’ll hammer you on being able to optimally code some algorithm under pressure on a time limit, but there’s zero mention of physical attributes like cache line access, let alone a realistic problem involving data structures. Just once, I’d love to see “code a simple B+tree, and then discuss how its use in RDBMS impacts query times depending on the selected key.”
RTT to nearest major metro DC should be up to 20ms (where I am it is less than half that), your DB calls should not be anything like 200ms (and in the event they are you need to show something else first), and 10-20ms is what you should assume for rendering budget of something very big. 60hz means 16ms per frame after all.
As you reach for higher percentiles, RTT and such start growing very fast.
Edit: other commenter mentioned 75% as percentile.
Also, due to layouting, a CRUD app may actually be harder to optimize per frame, than the trivial to parallelize many triangle case as seen in games.
This is also a great litmus test to check if an app was made with electron because they always redraw slowly.
There's no argument that starts this way which doesn't end either with "support working offline", or defining when you consider that a user has stepped out of bounds with respect to acceptable parameters, which then raises the question what do you do in that event?
If all you're trying to do is say 75% of users have a good experience, and in your territory 75% means a 150ms and that's too long then the network cannot be in your critical path, and you have to deal with it. If you're on a low end phone any I/O at all is going to kill you, including loading too much code, and needs to be out of the way.
If you can tell the UX is going to be bad you will need to abort and tell them that, though they really will not like it, it's often better to prevent such users ever getting your app in the first place.
I come from mobile games, and supported titles with tens of millions of players around the world back in the early 4G era. All I can tell you is not once did mobile ping become a concern - in fact those networks are shockingly good compared to wifi.
over a mobile network? My best rtt to azure or aws over tmobile or verizon is 113ms vs 13ms over my fiber conection.
I'm not joking: https://www.pcmag.com/news/is-starlink-good-for-gaming-we-pu...
Are you doing the 113 test from the actual device, or something tethered to it? For example, you don't want a bluetooth stack in the middle.
I can only guess the connectivity between your mast and the Internet is awfully congested, and/or you are in the middle of nowhere.
One of the reasons starlink does as well as it does is the ground stations are well connected to the wider world, whereas your nearest cell mast might not be.
On T-Mobile, I get 30ms to Cloudflare but 150ms to my local AWS.
But I also get 450 mbps on T-Mobile so I’m not complaining.
No. Just no. There’s an entire generation of devs at this point who are convinced that a DB is something you throw JSON into, use UUIDs for everything, add indices when things are slower than you expected, and then upsize the DB when that doesn’t fix it.
RAM access on modern hardware has a latency of something like 10 nanoseconds. NVMe reads vary based on queue depth and block size, but sub-msec is easily attainable. Even if your disks are actually a SAN, you should still see 1-2 msec. The rest is up to the DB.
All that to say, a small point query on a well-designed schema should easily execute in sub-msec times if the pages are in the DB’s buffer pool. Even one with a small number of joins shouldn’t take more than 1-2 msec. If this is not the case for you, your schema, query, or DB parameters are sub-optimal, or you’re doing some kind of large aggregation query.
I took a query from 70 to 40 msec today just by rewriting it. Zero additional indexing or tuning, just unrolling several unnecessary nested subqueries, and adding a more selective predicate. I have no doubt that it could get into the single digits if better indexing was applied.
I beg of devs, please take the time to learn SQL, to read EXPLAIN plans, and to measure performance. Don’t accept 200 msec queries as “good enough” because you’re meeting your SLOs. They can be so much faster.
What modern hardware are you using that this is true? That's faster than L3 cache on many processors.
As an actual example of RAM latency, DDR4-3200 with CL22 would be (22 cycles * 2E9 nsec/sec / 3200E6 cycles/sec) == 13.75 nsec.
Shopify is hosting a large number of webshops with billions of product descriptions, but each store only has a low visitor count. So we are talking about a very large and, hence, uncacheable dataset with sparse access. That means almost every DB query to fetch a product description will hit the disk. I'd even assume a RAID of spinning HDDs for price reasons.
I would be very surprised if “almost every query” was hitting disk, and I’d be even more surprised to learn that they used spinners.
And state of the art query optimizers can even do all this automatically!
While I do very much appreciate things like WHERE foo IN —> WHERE EXISTS being automatically done, I also would love it if devs would just write the latter form. Planners are fickle, and if statistics get borked, query plans can flip. It’s much harder to diagnose when all along, the planner has been silently rewriting your query, and only now is actually running it as written.
Also reporting p75 latency instead of p99+ just screams to me that their p99 is embarrassing and they chose p75 to make it seem reasonable.
200ms round trip is like 10x more than what's reasonably possible.
Same with your other numbers.
A linked post[0] says their p75 was 1400ms before 2023, yowza.
[0] https://shopify.engineering/improving-shopify-app-s-performa...
No. It on a request basis, meaning that one in a four clicks a user does take more than half a second to complete. Slow times for as low percentiles as 75 mean users hit the bad cases very often in practice.
Nike’s website is phenomenally quick. But again. Ask anyone if that is what they care about. Nope. It’s the shoes.
The implication is that React Native is to blame for this and I'm not sure that's true. What would the ms delay be with pure native? I have plenty of native apps that also have delays from time to time.
From another comment by seemack (https://news.ycombinator.com/item?id=42730348):
> For example, I just recorded myself tapping on a product in the Product list screen and the delay between the pressed state appearing and the first frame of the screen transition animation is more than half a second. The animation itself then takes 300ms which is a generally accepted timeframe for screen animations. But that half second where I'm waiting for the app to respond after I've tapped a given element is painful.
(next mini question: why is it seemingly impossible to make an Android app smaller than 60mb? I'm sure it is possible, but almost all the ones I have from the app store are that size)
This obviously isn't the case for every app and most of the ones I've worked on had a lot of bloat/crap in them as well.
I've just tried whatsapp, notes, gallery, settings and discord out of curiosity, none did and I have a very fast phone.
It's a cross-platform spiritual successor of WPF and it kicks ass! You get proper separation of models and views, you can separate what controls there are from how they look (themes/styles), you can build the entire thing into a native compiled application with very reasonable speed and memory use.
Why? If it's about the phone burning battery for 500ms, it probably isn't doing that - it's just waiting for data to arrive. And even when it's rendering, it's probably not burning battery like say Uber (with which you can feel the battery melt in your hands).
But that's not why I am commenting. I am writing because so many commentors are saying that 500ms is bad. Why is 500ms bad, as long as the UI is not freezing or blanking out?
Why not lower expectations, and wait for half a second? Of course, there are apps for which 500ms is unacceptable - but this doesn't seem to be one of them.
It’s easy to get caught up on numbers, but at the end of the day the user experience is all that matters. And I very much doubt that performance is a concern for their users.
As an Elixir dev who aims for and routinely achieves <10ms response times, (and sometimes < 1 ms for frequent endpoints that I can hand optimize into a single efficient SQL query, which Ecto makes easy I might add!) I find the response time to be the more egregious part :-D
Why are you assuming the app is either burning much battery or even doing more than waiting on current data from the server? For an app that I would assume isn't much use without up-to-date data from the server?
"Native devs are crucial
Mobile engineers who specialize in iOS and Android are essential to building great mobile apps. There is no replacing experience and taste that comes from having built many mobile products and deeply understanding conventions and usability. Being able to drop down to the platform layer, write bindings, master build & release, distribution, etc requires native expertise.
They also play a vital role in optimizing app performance across the myriad of device models, ensuring a consistent user experience for all users. Additionally, native expertise is essential for managing React Native version updates, as well as adopting new features, APIs, and tooling changes that accompany new iOS and Android releases. You can't build a good product without these experts.
We invested in training our native mobile developers in React Native through a self-serve course that covered everything they needed to know to ship production-ready code. Additionally, we set up office hours with developers who were already proficient in React Native to provide support through Q&A sessions, pair programming, and code reviews.
We also supplemented our mobile teams with some web developers for their Javascript, Typescript, and React expertise. This ensured we had strong expertise in both native and React Native, and over time, it levelled up the entire team.
Having a good mix of native and web developers is the key to building great mobile apps using React Native in our experience. "
I think it's one of the big misconceptions that React Native is _the_ path to get your web devs or even existing code onto mobiles. That's how you get the criticism that RN builds bad, mouldy apps.
Between our clients that have had this issue with quality and shops in the same space as us that haven't (one who boasts a review on one of their apps being "an example on how to build a proper fully native app"), having a good portion of native devs on the team is a big differentiator. Unfortunately this means a RN Team isn't as cheap as some hope.
— https://medium.com/airbnb-engineering/sunsetting-react-nativ...
Full Navive: 2 very big bubbles
React Native: 2 small bubbles and one big bubble
It doesn't happen very often but it can be quite annoying to implement features that need native controls on both platforms. In my case I only know native android (no ios) so when implementing native things I need to bring in an ios native dev and agree on the communication API and any platform-specific edge case before implementing stuff.
It is a lot easier when I can do it all by myself and it is even harder for team members who have no native experience at all.
For example, I just recorded myself tapping on a product in the Product list screen and the delay between the pressed state appearing and the first frame of the screen transition animation is more than half a second. The animation itself then takes 300ms which is a generally accepted timeframe for screen animations. But that half second where I'm waiting for the app to respond after I've tapped a given element is painful. UX studies indicate 0.1s as a number where an application no longer feels instantaneous. (https://www.nngroup.com/articles/response-times-3-important-...)
Contrast this against something like the Slack app where the screen is navigating even before the pressed animation has appeared. Or for an app with probably not as much engineering focus, Fastmail, which begins the screen transition within 100ms of the pressed animation state appearance.
Not saying I have the answer, but it is a curiosity
edit: by terminate I don't mean crash, it just stops code execution an example is an active socket connection getting disconnected unless it's doing something like streaming audio
The biggest game-changer recently is Expo's Continuous Native Generation[0]. You can configure all of your native modules and ios/android files with a simple config file (which has its limits, whereby you'll need to write an Expo Config Plugin[1]). You will no longer commit the ios/android native code to your repository, and instead let it be procedurally built.
This resolved a lot of environment issues developers would often run into, and greatly simplified onboarding new devs. You can build your iOS/Android apps through the CI with ease. And you'll no longer be afraid of upgrading React Native, as Expo will handle all of the breaking changes in the native code for you.
My guess is that Shopify started with bare metal React Native apps (which I would have done the same 5 years ago), and now migrating back to Expo-managed projects is nontrivial. At my work we only manage one app, and it was well worth migrating back.
[0] https://docs.expo.dev/workflow/continuous-native-generation/
Flutter draws its own components that can look superficially like the target platform (or not, it’s up to the developer) in a manner closer to a game engine. HN seems to love Flutter and apparently the developer experience is excellent, but as a user I find Flutter apps to be in general a poor experience. They rarely look or act quite right (assuming the developers even try; I’ve used a number that look like someone has transplanted an Android app onto iOS).
Expo is React Native with some nice things sprinkled on top. I'd go with Expo.
I fend that React Native app "feel" more native because they're actually using native components, but controlled via a JS runtime. Flutter on the other hand mostly renders to a canvas and re-implements native controls (although it can also wrap native components like RN does).
This leads to there being less of an "uncanny valley" in React Native apps compared to flutter. It also means that all the little details from the system (the text selecting and editing interactions in text inputs being a major one) are idential to native apps when using React Native, because it IS the native component.
The downside to this is that you need to consider platform differences more with React Native, which is one of the things which leads to developers without mobile experience having issues with it.
As the article says, you get the most out of React Native if you're a mobile developer, or at least have someone on the team who is. You can't abstract away all the details of a mobile platform without some tradeoffs.
So, the main reason for Expo (there are others) is: get to write in the language most developers already know.
I’m not sure I would consider 0.5 seconds to be blazing fast.
I wish the article went into detail on what these screens do and what a screen load means exactly.
Since the blog post doesn't mention previous native-only perf, I'd assume they didn't compare or the RN version isn't close to native-only perf (leaning heavily towards the second reason).
Looking at a previous blog post, the first hunch seems to be correct - the second may also be true.
From 2024 March, https://shopify.engineering/improving-shopify-app-s-performa... talks about how their RN-ified app was loading screens in 1400ms (P75) and the steps they took to reduce that to 500ms.
I hope they benchmark their load-screen time with every release/CD to stay on top of any regressions, otherwise, there'll be more mad scrambles when the perf debt piles up too high.
It's a mix of layout stuff (like using lazy list views to avoid below the fold rendering) and network fetches (they talk about using better caching).
If a "screen load" includes making a network request to fetch data, then this is a very weird metric to include in a post about React Native. Most of that time budget should just be waiting for the request to complete. Just as before, it should take <16ms to render the screen once the data arrives.
500ms sounds about right for a cold launch but otherwise is pretty poor.
50-100ms for "minor" screen changes and 100-200ms for "major" ones are otherwise reasonable for native screens.
Keeping UI rendering under 16ms is the gold standard for native apps. That leaves only deserialization as the other target which the mobile developer can optimize. However, the typical solution there involves convincing the backend to ship a different format (i.e. switching from JSON to binary PList or to SQLite DB file).
No, it isn't.
If you're not including the actual rendering, so the actual code of the app only or at least only the code on the UI thread, the targets are much smaller. More like 3-6ms/frame.
If you're including rendering then pipelining and 90hz+ being common still changes that anyway.
Not since they’ve started releasing 120hz screens.
The wider noise around React Native is seemingly that it works, especially while iterating on things, but it makes the final 20% of work much harder than it already was. As one person put it to me recently “with RN you just have to face the fact you won’t be winning any design awards”.
What really amazes me is how far React Native and web React have separated, to the point using the web one is a complete non event.
I don’t know why the quality of the app feels cheap, but it just feels so (the web views load in with zero ease, they just jank onto the screen. So while you have native screen transitioning, you still have this low quality feeling of a bad nypost article shitting out an ad popup on you. Hard to explain, but that’s my my general feeling).
Regardless, while not impressive, it’s in this non-impressiveness that informs my unwillingness to invest into native or something like Flutter. These apps are too simple to go through the hoops.
Shopify RN app is a good example of a mundane non-sexy tech decision.
Overall nothing beats CSS and JavaScript for UI, but even in 2025 we cannot reliably push 60fps.
For mobile apps generally I cannot recall the last time I was actually impressed by one. The reverse is often true, such as with Sonos. Individual features (again Sonos, the calibration it can do) can be neat but experiences as a whole have gone off a cliff, React Native or not.
Just to give one simple example. Take the concept of a mixin where you want to essentially create a partial class interface and use it for basic composition. An incredibly straightforward 101 level OOP concept.
Then take a look at how it works in Typescript here:
https://www.typescriptlang.org/docs/handbook/mixins.html
and contrast that with how you do the same thing in Dart here:
https://dart.dev/language/mixins
I’ve got extensive experience with both. I promise you Dart is much much much nicer to work with on every relevant metric I can think of.
JS and CSS compile to native, somehow.
My ability to do this
function App() () { const items = get(url); render(items) }
Does not exist on native. It's 2025. Why is this?
----
It's because we don't have literate programmers. They don't know how to speak CLEARLY.
Mate, I think this is a bit of a reach.
The article alludes to something people do. They wrote a whole lot of code to not write a whole lot of code. These are deep stories.
React very much feels like programming using only side-effects and that’s not really a fun experience IMHO. Performance issues are also somewhat difficult to spot in review and not very elegant to solve.
It’s been a few years since I’ve used React Native so maybe things are better now?
Small teams trying to keep burn ultra low vs. giant companies might have similar technical goals but opposite staff capabilities. This is a crucial factor.
A second-order effect is how much time/energy/money you have to throw at maintenance. Can you afford to spend X% of your time on maintenance? Which technologies offer comparative advantages on maintenance cost? These are surprisingly often easy to answer, and nearly never explicitly considered!
I agree that maintenance costs are often overlooked/ignored, but I'm curious how you get answers on the costs. I've never found it particularly easy to get reliable information on maintenance costs.
Im dense enough to delete things and rewrite if they require babysitting.
Express is almost decade old, react is more than a decade old, redux is almost a decade old, Tailwind is the only new thing but that too is almost half a decade old.
Can you share your package.json?
And every React-adjacent project either ends up abandoned or subsumed into the beast.
Hooks are a bit of a cancer, they leak absolutely everywhere on top of making it quite difficult to reason about re-renders.
This is interesting and I like the way you've phrased it. Are you talking about React Native, or React in general? And do you use hooks?
I like React on the web, but only when using hooks and only because I haven't found anything that I like more than it. I still find it tedious and overly hook-y¹. It also gives a lot of wiggle room for devs to shoot themselves in the foot with useEffect, like some of my previous clients have done.
¹ Hold on, I gotta pull in 18 hooks from across my project, npm dependencies and react itself before I can write the jsx in what would otherwise be a 10-15 line fooButton function.
After being thrown into the Angular woods for a while I found that what I really wanted was just a "React with RxJS Observables that look like writing Hooks if you squint, but don't have some of the complex rules either" and then I realized that I was basically trying to reinvent some of Knockout, but with TSX templates. I'm still amazed by how much I was able to accomplish from that idea, including some of the "advanced" features of modern React, in a relatively small package (modulo the one and only one dependency on RxJS).
I don't know how many other developers want the same thing.
(I know some find RxJS overly complex, which is exactly why Angular is as awful to work in as it is, both in how it badly uses RxJS (and teaches bad habits) and how there's generally three ways to do everything, one with RxJS and two others avoiding it or misusing it, with now a fourth way of Signals which are just RxJS-lite with Knockout-style `computed`, proving time is a flat circle and Angular remains a design-by-committee mishmash of too many things that don't interoperate well. I think learning Angular's mishmash is far worse than just learning RxJS well, but I also spent a lot of time doing Rx in C# and in CycleJS for a while, too.)
> and then I realized that I was basically trying to reinvent some of Knockout, but with TSX templates.
https://vuejs.org/guide/extras/render-function.html#jsx-tsx
React's reactivity model is "inverted" from almost every other model out there. Vue, to me, feels the most like Knockout. I also find that I rarely run into edge cases compared to React and Vue feels the most like OG HTML.
A part of the way I see it is that Knockout promised "Observables" and `computed` was sort of the distracting fork away from something like RxJS Observables. Now that fork seems to be named "Signals". I'm not a fan of "Signals" and think they miss a lot of the power and elegance of "real" Observables like RxJS. I understand the appeal of the "magic" of `computed` tools. I better appreciate the power of the larger toolbox of RxJS operators. (I also think Observables are a lot easier to unit test than `computed`. A good "marble test" is a thing of beauty.)
For what it is worth, my RxJS-based solution: https://github.com/WorldMaker/butterfloat
Trying to figure out if Flutter or RN would be best use of what little time I have left on this planet
> We’ve achieved sub-500ms (P75) screen loads in the Shopify app
Pick 1.
Also interesting that this deep care about performance extends to blogs, where a simple animated image showing how awesome hot reload is causing a noticeable delay in scrolling
Some are very closely watched, some were mostly just meant as extraction and not really expecting outside contributions.
https://news.ycombinator.com/item?id=34263628
Will another 10 years go by and there still won't be a dark mode for the app?
As someone who uses the mobile app basically every day, it is absolutely one of the things that bothers me, every single time I use it. That's not a good thing.
We can't agree to use colours that are unambiguous for colourblind folks, we can't agree to use sufficient contrast in our UIs, we can't agree to use big enough touch targets, most companies are truly awful at accessibility... and yet everyone wants dark mode, and most companies implement it. How much time have we lost as an industry making interfaces harder to read?
Calling it dark mode might not be ideal though. We should probably call it something like system theme awareness, or anything that doesn’t make the reader to think “gee, that’s not the theme I like.”
Prefers-color-scheme exists. It’s not that hard.
https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...
Apple just keeps making billions and billions by focusing on UX, when other ”tech” companies are satisfied with this garbage.
Every so often they write an article talking about how great their several-years-long effort to switch to React Native is going, and every time I read it and come away with an even more negative opinion of React Native.
https://news.ycombinator.com/item?id=34263896
https://www.reddit.com/r/swift/comments/1bxogd1/have_you_con...
I suppose taken from the perspective of "We want to easily hire frontend devs that can easily be slotted in to work on the project and make impact on all platforms, including mobile" then it's a win, but at a cost in years and a degraded user experience. From a business perspective, probably a good move in the long run.
If what you're using makes it this way, maybe stop using it? Stop drinking the kool-aid, get over your sunk cost fallacy and start thinking about what your end user experience should be, and work backwards from there, making decisions that guarantee you hit it. Don't choose the language or tool first and leave yourself constrained to only what is possible in it.
Saw this the other day and looks interesting
Not sure I agree with this though:
> first-class development environment (Xcode)
Shitty native toolchains that constantly need to be updated (looking at you, Xcode), dumpster fire IDEs (both Android Studio, still don’t understand how Google managed to butcher IntelliJ like that, and Xcode), half completed libraries that are either deprecated or in alpha and, for some reason, in need of constant changes. Compile times in double digits for large projects. Stay up to date with shitty Gradle if you want to have semi sane development experience on Android (maybe they’ll finally roll out declarative version this year, but they said they’re still committed to original DSLs, so good luck to poor sob who will encounter mix of Groovy and Kotlin DSL). Wonderful world of single vendor languages where only interests of vendor dictate how language evolves (just how much resources and time were wasted on horrible KMP, because JetBrains wants to grab mobile market fully).
Let’s gooo!
I have no idea what libraries you're talking about but you don't really need to use any third party libraries to build a good iOS app. Unless you're doing something incredibly obscure most of the big/popular ones are very well maintained.
Let's note that because the clients are fully open-source and on GitHub, people from Expo and React Native are helping the little team behind the clients improve performance over time: it's not their final form!
I've seen many iOS projects overwhelmed by tech debt while its Android counterpart was still OK-ish. I don't believe this is coincidence.
So how hard is it to apply React Native the correct way? Having a dedicated team of dozens of engineers including native experts for each platform is different than your average 4-8 people dev (web, API, iOS, Android) team. Let alone if you only have people experienced in web doing the work.
When I build Swift applications the fact they have sub 500ms loads is not an achievement, they're simply already doing that without me trying. But I have found the right way to build iOS apps myself over the years, very little help from Apple.
https://infrequently.org/2024/11/if-not-react-then-what/#fn-...
That's a difficult to interpret metric. If it's only being met 75% of the time, I'd tend to assume most features are much better than that, but some are never meeting the target, and there's no indication by how much.
Hahaha we are absolutely cooked.
I frequently encounter Shopify e-commerce in the wild, and it’s my most disliked experience. From browsing the stores to checkout, it always feels clunky.
I always shrugged it off as iOS bullshit but now I know the real reason. It’s just slow enough to make you doubt yourself - it’s not the website, it’s probably my shitty {phone|poor internet|computer}
> I literally cannot allow for my brain to rot waiting for minutes waiting for Xcode to compile for a simple border radius change.
You can literally think about/edit other things while your simple border radius is being updated. No rot involved