You realize of course that you are also on HN and thus this apparent dichotomous behaviour applies to you as well? I imagine you have some reason for why it doesn't and I think you'll find that it can just as easily apply to everyone else.
From what I've seen,the refractions happen in predictable contexts so I suspect that they'll be able to create shaders, etc that will limit the performance hit
I was glad to see the discussion as well but it feels like the downsides were also very understated. Working on an RN app as a native dev requires a lot of cross-domain knowledge that isn't typical for a native dev.
Blazing fast is a bold claim. I use this app nearly every day on a brand new Pixel 9 Pro and, while much improved from a few years ago, it is far from "blazing fast".
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.
On our apps we consistently see a p50 3-4x speed difference between iOS and Android (though there are more lower end android devices). Hard to fathom if it's all due to variability in android devices vs RN being less performant on Android.
Pixel 9 Pro, or virtually all android phones apart from the recent snapdragon Elite and coming ARM Cortex X5 all have much slower single threaded performance comparing to iPhone.
The Google Tensor G4 in single thread and integer only is roughly in between iPhone 11 and iPhone 12. That is the performance between 2019 and 2020 on iPhone.
And Tensor G4 is already on the high end Android Phones. You can quickly see how all previous and lower end android phone are much slower.
Developing for Apple can be a PITA with their strict background processing rules, apps just terminate/stop working unless they fall under a special case. I get it but yeah.
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
But as a user I appreciate the strictness much more. I don't have to worry about closing background apps or having a bunch of crap running when I'm not actively using it. The OS (mostly) handles that for me, as it should.
Absolutely. I’d rather have backgrounded apps unexpectedly closed from time to time than to find a big chunk of battery gone at a bad time because some app I don’t even care about has decided it needs to keep running and eating resources for some reason.
I wrote an app to log mileage while doing deliveries, etc for my small business. It gives me a small tax benefit at the end of the year. To make it more fun, I gave the UI a "terminal" flair.
I wrote it over the course of a week or so and I use it frequently.
It's not that it won't see the light of day for anyone else but it's a very specific niche so I doubt anyone would even find it on the app store
No hate but saying that collectors simply gather things that others made is rather dismissive. It may certainly be true in some cases but it's also very possible that true, potentially even ingenious, effort was required on the part of the collector to build, maintain, and be knowledgeable about the collection.
I had a similar thought a few years ago when trying to think of "useful" uses of NFTs. It could be great if I could buy music, etc and then play it on any streaming service via some sort of proof-of-right-to-play mechanism.
It will never happen. Why would the future platform owners, or especially separate service owners, want to let you enjoy the benefit of their hosting costs when they get nothing?
Imagine Spotify being able to continue streaming you music that they no longer have access to, because you "the user" still have individual rights to the music.
Thwn, you can stream your own music and Spotify's music side by side.
And, it's a double win, since they're not paying an royalty fees for a single user streaming music they already own.
I'd like to introduce Trtl, a mobile app I'm working on with a terminal-like UI.
I don't see many mobile apps on HN but this one has a twist that I thought might be interesting to the HN community.
I recently sat down to write myself an app to record business trips in my personal vehicle and the simple use-case was an excellent opportunity to explore an old thought that a terminal interface could be a good fit for mobile.
There's a concept in the UX world loosely called "Reachability" which refers to how much of the screen the user can comfortably reach with their thumb. The idea behind it being that frequently used elements should be located within that convenience zone. A terminal-like interface, with it's keyboard-first interactive model, is very compatible with this.
Further, our fingers are also the mouse in the mobile context so mouse-centric design patterns like buttons can still be useful. One example of this in Trtl is the custom odometer entry control. It uses the keyboard for entry but you can also change the currently selected digit by tapping the UI element. The actions presented in the command lines are also tappable!
It's definitely not perfect. There are some notable UX issues to iron out, touch target sizes, discoverability, etc. Still though, I'm personally surprised and impressed by how well a terminal-like concept works in a mobile app.
