RIP native development, long live non-native native development?
Just wait until your BBQ has its own browser - oh shit wait
More and more gets ported to the GPU through parallelized algorithms, and smart GPU memory usage — but CPUs still offer a lot in their ability to do generalized computing.
This is why as I’ve gotten older I’ve come to really respect Computer Science fundamentals; the more you understand how to make the most of resource constraints — whether time, or memory, etc — the more magic you can make.
I think Apple has said that Core Animation (and maybe Core Graphics) now use Metal where possible, but vector to bitmap rendering is still done on the cpu.
If web frameworks really reupload the whole view to GPU on each frame, it's no wonder all apps run like arse and burn battery.
Guaranteed good performance (the bit you picked up on) for a feature people want in an easy to use package sounds great. Well done the author and thanks for sharing your work.
What a trainwreck of a headline. It sounds like someone fell asleep on the push button of a 'modern web dev' phrase generator.
Excited to check this out!
A lot of fluid animations and interactions in React Native are finally not that much of a hurdle anymore thanks to react-native-gesture-handler and reanimated, which are brilliant abstractions that fully offload work to the native thread and don’t interrupt interactions due to work on the main thread.
React Native’s own primitives, like Animated, can only go so far until they require intervention or activation from the main thread.
These libraries by Software Mansion have basically become a “must have” for creating compelling apps in React Native.
I just really recommend to use our library (https://github.com/openland/react-native-fast-animations) for non interactive animations like appearing and disappearing. Since iOS and Android could block UI thread during initial layouting if there are a lot of content and you will get dropped frames or just broken animation (if freeze will be ~200ms).
This is important since iOS actually rely that all animations are done via Core Animation that could not be blocked by main thread and therefore a lot of UI widgets are just slow on first view. Most iOS developers don't care if instantiating view will take 50ms since you have 300ms budget for all transition animations.
This library does same thing for Android by "hacking" native API the same way as official Google Apps do. This is a shame that google not opening this API.
Now we have three to maintain.
I have built native interfaces that would interface C# code, that was slightly less pleasant as a developer experience while I would get a 100% native experience for the user and a better programming language in return.
So what you gain in getting a singular code base for at least your logic and data parts you lose because you're chasing bugs that would never happen if you would have used a better programming language.
The average native project I've seen had 5-15 dependencies. The average React Native project thousands and thousands of them.
Typescript IS better programming language and much more powerful than, say swift. I can't see whats so special about swift comparing to typescript. I was coding for 5 years on swift and know what it is. Tests are much easier, typesystem is much more powerful and flexible. Compilation times are instant comparing to native.
Please, don't rant on JS ecosystem and "dependencies". To build native app you download 30GB xcode, clang and god know how many different libraries and runtimes. JS just not install them globally and 90% of deps are for development only.
Our app have 700kb of compiled JS. I have NEVER ever able to fit my kotlin/swift app to 700kb of compiled binary (excluding libraries).
We are native platform specialists..but have been seriously looking at RN and Typescript.
App sizes is a definite concern since we build for Indian markets.
What about assets? Do they bloat up more than on native.
I could recommend RN if you can tolerate slightly lower performance (because of the stuff i mentioned earlier) and beware that infinite lists are absolute shitshow (we built our own). If you are native specialists you can write bindings by your own and replace only parts of the app with RN.
Assets are stored the same way as in native, not sure how you can do something with them.
But most importantly this question - do you envision that building React Native apps requires one to write wrappers for native at some point ?
Or is it all abstracted away by now.
We built our own since there are much better frameworks on native side - asyncdisplaykit on iOS and Litho on Android. This library claims 60fps without actually measuring it or using very simple layout. We are doing messenger and layouts are really heavy for rendering and rn have it’s limitations, more importantly we reuse lists between screens, we have our own micro react inside that renders mostly static content to json and send it to native side. This is overkill for some, but not for us. We would have done the same without RN anyway.
> Typescript IS better programming language and much more powerful than, say swift.
> Tests are much easier
Good because you’re going to need to write a shit ton just to verify everything that is verified for free by the compiler in Swift.
> typesystem is much more powerful
In what way?
> and flexible.
...because it’s not that strongly typed
> Compilation times are instant comparing to native.
Objective-C was much faster too, because it moved a whole class of bugs to runtime instead of compile time
> don't rant on JS ecosystem and "dependencies"
We could just as well shut down HN if you’re not even legally allowed to rant on the bat shit crazy JS dependency trees anymore.
> To build native app you download 30GB xcode, clang and god know how many different libraries and runtimes.
Actually it’s a relatively small application with a shit ton of simulators shipped with it. So apart from the dramatically inflated download size (like that was even needed given it’s real size) you probably already knew this yourself.
But nothing better than a whataboutism to cover up an inconvenient truth.
I actually got suckered into a point by point rebuttal where I already know where RN shines compared to native dev:
Reactive as it’s basic pattern and hot UI reloads.
It is more powerful because it flexible because it's typesystem is turing complete and you can describe literally anything in it. Everything is strongly typed. It is powerful because you can express anything unlike swift/java/kotlin where you are forced for some subset of what can do in typescript. For example, good luck enforcing string variable to specific values only. Good luck working with two classes that have same fields but don't have common interface with them. It is the fact - you can do much less in this languages than in TS.
Test also is the easiest thing to do in ts: i am coding for 20+ years and jest is simplest solution for tests ever. You just can't compare this to a shitshow of native testing (one is xcode because of xcode, another is android well because it is android).
I don't understand how python or erlang relate to discussion of ts on rn. You advising to write ios apps in erlang?
While you wasn't rational, i still tried to calculate how much i need to install to build anything with plain clang.
I got docker with ubuntu 20.20, base image is 78MB. Executed: 'run apt-get update && apt-get install -y clang python3' now image is 700MB. And i still don't have llvm, debuggers and anything i need.
The docker image of golang alpine is 350MB after downloading. Alpine itself is 5MB.
So how small is small?
Swift has it's own run-time and used to ship it with every app built in it before the ABI was stabilized (and is still added for older versions of macOS and iOS if you target them). It still needs to interface libraries written in C and Objective-C and for that reason some parts of the language aren't as clean as I would like to see it, but otherwise UIKit and other libraries wouldn't have been compatible.
I ask because I'm looking to make a "native" app, and I'm debating between Swift and TypeScript + React Native. I haven't experienced many bugs from JS/TS, but that's because I try to avoid huge dependency graphs in my web apps. It would be concerning if React Native's dependencies were buggy enough to have to chase down multiple bugs per project.
This means there are many libraries just for date and calendar in JS that are really popular while everybody in Cocoa usually uses the ones already shipped with the OS because they work. This is why you see relatively few external dependencies on native apps.
Typescript fixes JS by adding types to the language but the runtime really doesn’t support them, so they’re kind of faked and built upon a leaky abstraction on top of JS.
This means there’s a larger possibility of runtime bugs where Swift and Kotlin offer a more secure type system, even compared to C++ and Java.
Thanks for the information, I think I'll go with Swift.
I'm interested to read more about that, do you have an article or something?
It's too bad it's an interface element that causes a lot of pain by covering content and embracing dark patterns.
- The user doesn't lose their navigation stack because they can tell the bottom sheet can be dismissed, they know where they "came from"
- The user keeps visual context on whatever triggered the bottom sheet, because they can still see what's behind it
- The user doesn't get forcibly navigated away from whatever they were browsing, they know that once whatever they're doing in the sheet is done, they can "go back".
My only complaint is that Apple added them to stock apps in iOS 12, so many iOS users got used to the pattern, but didn't provide an easy way to give the same experience for developers which creating a need for libraries like this.
I suspect most users wouldn't even know the bottom sheet is there nor how to bring it up nor how to dismiss it had they brought it up.
The visual context on whatever is underneath is lost once the sheet is brought up.
The user absolutely get forcibly navigated away; their context is shifted to the new layer which is slapped on top of the other layer. I can't count the number of times I either accidentally activated the bottom sheet or used it then got lost.
Bottom sheets are like hamburger menus; they are rugs that UX designers sweep all their baggage underneath.
I’ve got several apps on my phone (maps, DoorDash, google maps, etc) all doing the same thing, but inconsistently and it’s infuriating. What makes iOS great (IMO) is consistency in UI patterns with things like navigation controllers, toolbars, etc. floating sheets are worthy of that treatment.
What does this mean? I thought Expo was just tooling for React Native.
There are several of these implementations. I’ve recently had to implement something similar in Xamarin.iOS. It isn’t a breeze.
I guess you probably have better insight than the devs of two of the most popular native apps, though. Cheers!
For most companies (maybe all), it’s not needed. Apple is doing a fantastic job abstracting views into SwiftUI and Android team is doing the same with Jetpack Compose.
Then what? More abstractions over abstractions to achieve 60 or 120 FPS through another framework?
And this is not related to the OP post, making these bottom sheets is a breeze. Literally:
1.) Custom ViewController with custom UIView as base view
2.) Add as child or present over root controller
3.) Translate and animate custom base view from bottom (top... left... whatever the hell you like)
Not more than a few days of work to get right at max but still a bit more.
4.) Put scrollview inside base view
5.) Register pan gesture and delegates and write logic for full, mid, none snap points
You clearly don’t need another whole framework to do the above
They developed it to address developer performance and ensure consistency.
Apple's layout APIs certainly could be a lot better but this framework only seems necessary if you want to avoid having the same teachable moments over and over for thousands of junior engineers.
The amount of useless negativity in this thread is really amazing. The repo has ~650 stars right now, so clearly developers are finding this work to be useful. Yet look at all the mindless poo slinging going on in this "community".
Why would you make a remark like this without any explanation or supporting argument? Please don't.
But the coolest example I like to give is this app - https://www.theverge.com/2020/5/4/21246386/augmented-reality...
Energy consumption is definitely a concern, but our app isn't exactly something people are going to be on all the time...it's more of a "check it a few times a day and move on" sort of deal. It's a fairly complex app with quite a few screens and with daily usage I haven't noticed any hit on battery life.
A PWA could be a good fit, and while I think there's many cases where it makes a lot of sense, there's a handful of native features we wanted to utilize (most importantly, push notifications!) that aren't possible yet in the PWA world.
There's always tradeoffs with any of these abstractions and React Native fit the bill with what we were comfortable trading off. I'd love to see the whole thing get the full native experience on iOS and Android once we're profitable and can hire full-time devs on those projects, but we're not there yet and so far the decision to go with RN has paid huge dividends in terms of shipping this. You'd be hard-pressed to tell it wasn't a native app, seriously!
Individual developers / web developers I know who've tried it in personal projects / freelance have gone back to native or looked at Flutter over RN.