4 ms·

I’ve done a couple React Native apps and never again. They’re fine at first but if you let one sit for a few months there is a combinatorial explosion of comple

by imgabe 3y ago

I’ve done a couple React Native apps and never again. They’re fine at first but if you let one sit for a few months there is a combinatorial explosion of complexity among shifting incompatibilities of different versions of javascript libraries, the framework, android/iOS versions, build systems, etc. it becomes a nightmare. I’d much rather just learn Kotlin/Swift and have only one ecosystem to maintain.

wharvle 3y ago
At the time I used it, it was almost worth it just to use RN for Android even if you did iOS in Swift, just because styling on Android was so hellish ("There must be some non-crazy way to set a default typeface for my app. Right?" LOL wrong; "setting this color on this Material input field must be easy" LOL nope, welcome to Java metaprogramming just to set a goddamn color), the documentation-suggested way to structure apps was so bad that you'd be reaching for other solutions anyway if you valued your sanity (I wanna say Square was at the forefront, here? It was some company like that. Like your best bet was just to find their libraries and blog posts and do exactly what they did, ignore the official docs), and in some cases the native libraries for Google APIs were less-capable than the Javascript ones anyway (Maps was one, I remember—god, what a surprise that was to find out). But that was like 5 years ago so maybe it's gotten better.
- rareitem 3y ago
  I agree with you. RN still sucks on some aspects, but it's quite an amazing technology and I'm grateful it exists.
  - fakedang 3y ago
    Nah, among cross-platform, RN has stagnated while Flutter has sped past. The key issue I see these days is that it's just not worth it to build a mobile app these days unless your payment flow happens outside of the app.
    - meowtimemania 3y ago
      I had bad experiences with it 7 years ago, but really good experiences with it recently. If you stick to native modules managed by expo you'll be in a great place! You can run into dependency hell if you use a random react-native npm module that was last updated 5 years ago.
    - jitl 3y ago
      I think most users would prefer an RN app over a Flutter app, especially on iOS, because the RN app will feel much more native because it renders using native views, instead of a Skia framebuffer.
    - willsmith72 3y ago
      > it's just not worth it to build a mobile app these days unless your payment flow happens outside of the app not true at all, 85% of something is better than 100% of nothing. This is coming from someone who hates mobile apps and apple's grip on them
- jamil7 3y ago
  Although I haven't used it, Jetpack Compose exists now, so that and SwiftUI are pretty similar. On a previous project I was contracting on, the CTO managed to bash out a basic Android version of the iOS app I was working on without any Kotlin experience by going through the SwiftUI views one by one and implementing them in Jetpack Compose.
jd3 3y ago
We recently threw out our React Native app and have gone all in on PWAs.
- lakomen 3y ago
  TWA as well? Because I find, the app stores are good for discovery.
conradfr 3y ago
People should just use Ionic & Capacitor. You can still use your React knowledge with it.
- rizky05 3y ago
  [dead]
- factormeta 3y ago
  Capcitor with solid or marko would be better, more lightweight.
ex3ndr 3y ago
This is a very weird thing to say when expo is literally one line installation and it does not require you anything to be installed (even XCode) on machine for most projects. It is literally 10x times easier than just writing in Swift.
- imgabe 3y ago
  If you want to submit it to the app store you'll need to install XCode anyway to build it and submit it. Might as well just start there and have it configured right from the beginning.
  - ex3ndr 3y ago
    No, you do not, you can use a free service by expo that would build in the cloud. Literally requires zero setup. Local build is needed only if you are sensitive to security, but many banks started to use it. Also native plugins became so easy to use it is a joke how simple it is comparing to cocoapods and some cryptic libraries. Expo's workflow is so perfect comparing to pure native, it is not even comparable. To do iOS development you need: Swift Packages, Cocoapods and XCode at least. Whils in general it is simple, but cocoapods constantly fights with apple and xcode to not crash anything. While expo also uses cocoapods, it is much more stable because you can always just delete a native project and regenerate it from scratch and it will work. I am not even starting to discuss how complicated is development for Android - literally everything now have 5+ different APIs for a simple things like "please encrypt this string" or "take a photo". React Native and Expo has perfect packages that solves real problems and work with a few keystrokes.
    - imgabe 3y ago
      I'm glad it works for you. One thing I've learned from bitter experience is "don't swim upstream". Meaning, you're likely to have problems when you're using tech outside the way it was intended. Apple intends apps to be developed in Swift with XCode, so that's what they support and when they develop new features that's what they have in mind. They don't care about Expo and if they do something that breaks Expo or Flutter or any other third-party service, that's not their problem and they aren't going to do anything about it. Expo et al are always going to be second class citizens to Apple. Cocoapods are on their way out. I use Swift Package Manager on new projects and it's literally a couple clicks to install whatever package you want. Haven't had any problems yet.
hardwaresofton 3y ago
Really important to note, this isn’t react native, its NativeScript. The two have some fundamental differences — React Native is complex because the React ecosystem is full of complexity. NativeScripts biggest problem is more ecosystem size.
vietvu 3y ago
Maybe it got better but when I was using RN, it felt fine at the first 3 months; then we found out that it is a hell to work with JS and React Native dependency. To the point we needed to forked multiple project to make it worked. And in the end, we still need a considerable native code for our app. It might just be better to start from scratch with native iOS/Android.
apatheticonion 3y ago
Writing a Windows app, MacOS app, Linux app, iOS app and Android app is a nightmare because of the insanity and divergence of the SDKs. They could all have a common API with OS-specific extensions - but instead of that, everyone is trying to make their own API. As a result, developers just write everything in electron/WebKit/WebView. I wish there was an open standard API for writing native desktop/mobile apps that OSes could adhere to (that the EU forces them to adhere to, haha).
- 0x6c6f6c 3y ago
  I've seen Dart filling this gap for many apps lately
- jdmoreira 3y ago
  Yeah they did that multiple times already. One of them was Java/JVM. That was exactly how they pitched it in 1998
  - apatheticonion 3y ago
    I suppose it's the execution that is important. Given that GUI applications share a lot of aspects between platforms, I'd love to see an open "Vulcan"-like standard that defines a GUI API for native platforms. OSes can interpret calls to that API such that the result looks congruent with the platform's design language - while the application code itself remains portable between platforms. It's really not that hard to define, there's just no willingness to do so from OS vendors as it would erode their efforts to build walls around their platforms POSIX became a standard because the US government needed software interoperability with their hardware. It wasn't enforced, but you'd miss out on the government contract lottery if you didn't adhere. If we value competition in the OS space, it would be wise to support an initiative that would make the OS itself unimportant
adonese 3y ago
I have a mobile app sitting around. Wrote it in 2020ish, Corona year. The mobile app is written in flutter and the server is in Go, you probably know by now where I'm heading with this. I cannot even express how hellish and nightmare that whole flutter thing is: I'm worried about the engine itself (there were breaking changes in the typing system itself that I'd need to worry about), the libraries and packages to update. And not to even stop at the building (signing) stage with the whole ruby shenanigans that needs to match and work well with xcode. Now compare that to go.

by imgabe 3y ago

wharvle 3y ago

At the time I used it, it was almost worth it just to use RN for Android even if you did iOS in Swift, just because styling on Android was so hellish ("There must be some non-crazy way to set a default typeface for my app. Right?" LOL wrong; "setting this color on this Material input field must be easy" LOL nope, welcome to Java metaprogramming just to set a goddamn color), the documentation-suggested way to structure apps was so bad that you'd be reaching for other solutions anyway if you valued your sanity (I wanna say Square was at the forefront, here? It was some company like that. Like your best bet was just to find their libraries and blog posts and do exactly what they did, ignore the official docs), and in some cases the native libraries for Google APIs were less-capable than the Javascript ones anyway (Maps was one, I remember—god, what a surprise that was to find out). But that was like 5 years ago so maybe it's gotten better.

rareitem 3y ago
I agree with you. RN still sucks on some aspects, but it's quite an amazing technology and I'm grateful it exists.
- fakedang 3y ago
  Nah, among cross-platform, RN has stagnated while Flutter has sped past. The key issue I see these days is that it's just not worth it to build a mobile app these days unless your payment flow happens outside of the app.
  - meowtimemania 3y ago
    I had bad experiences with it 7 years ago, but really good experiences with it recently. If you stick to native modules managed by expo you'll be in a great place! You can run into dependency hell if you use a random react-native npm module that was last updated 5 years ago.
  - jitl 3y ago
    I think most users would prefer an RN app over a Flutter app, especially on iOS, because the RN app will feel much more native because it renders using native views, instead of a Skia framebuffer.
  - willsmith72 3y ago
    > it's just not worth it to build a mobile app these days unless your payment flow happens outside of the app not true at all, 85% of something is better than 100% of nothing. This is coming from someone who hates mobile apps and apple's grip on them
jamil7 3y ago
Although I haven't used it, Jetpack Compose exists now, so that and SwiftUI are pretty similar. On a previous project I was contracting on, the CTO managed to bash out a basic Android version of the iOS app I was working on without any Kotlin experience by going through the SwiftUI views one by one and implementing them in Jetpack Compose.

jd3 3y ago

We recently threw out our React Native app and have gone all in on PWAs.

lakomen 3y ago
TWA as well? Because I find, the app stores are good for discovery.

conradfr 3y ago

People should just use Ionic & Capacitor. You can still use your React knowledge with it.

rizky05 3y ago
[dead]
factormeta 3y ago
Capcitor with solid or marko would be better, more lightweight.

ex3ndr 3y ago

This is a very weird thing to say when expo is literally one line installation and it does not require you anything to be installed (even XCode) on machine for most projects. It is literally 10x times easier than just writing in Swift.

imgabe 3y ago
If you want to submit it to the app store you'll need to install XCode anyway to build it and submit it. Might as well just start there and have it configured right from the beginning.
- ex3ndr 3y ago
  No, you do not, you can use a free service by expo that would build in the cloud. Literally requires zero setup. Local build is needed only if you are sensitive to security, but many banks started to use it. Also native plugins became so easy to use it is a joke how simple it is comparing to cocoapods and some cryptic libraries. Expo's workflow is so perfect comparing to pure native, it is not even comparable. To do iOS development you need: Swift Packages, Cocoapods and XCode at least. Whils in general it is simple, but cocoapods constantly fights with apple and xcode to not crash anything. While expo also uses cocoapods, it is much more stable because you can always just delete a native project and regenerate it from scratch and it will work. I am not even starting to discuss how complicated is development for Android - literally everything now have 5+ different APIs for a simple things like "please encrypt this string" or "take a photo". React Native and Expo has perfect packages that solves real problems and work with a few keystrokes.
  - imgabe 3y ago
    I'm glad it works for you. One thing I've learned from bitter experience is "don't swim upstream". Meaning, you're likely to have problems when you're using tech outside the way it was intended. Apple intends apps to be developed in Swift with XCode, so that's what they support and when they develop new features that's what they have in mind. They don't care about Expo and if they do something that breaks Expo or Flutter or any other third-party service, that's not their problem and they aren't going to do anything about it. Expo et al are always going to be second class citizens to Apple. Cocoapods are on their way out. I use Swift Package Manager on new projects and it's literally a couple clicks to install whatever package you want. Haven't had any problems yet.

hardwaresofton 3y ago

Really important to note, this isn’t react native, its NativeScript. The two have some fundamental differences — React Native is complex because the React ecosystem is full of complexity. NativeScripts biggest problem is more ecosystem size.

vietvu 3y ago

Maybe it got better but when I was using RN, it felt fine at the first 3 months; then we found out that it is a hell to work with JS and React Native dependency. To the point we needed to forked multiple project to make it worked. And in the end, we still need a considerable native code for our app. It might just be better to start from scratch with native iOS/Android.

apatheticonion 3y ago

Writing a Windows app, MacOS app, Linux app, iOS app and Android app is a nightmare because of the insanity and divergence of the SDKs. They could all have a common API with OS-specific extensions - but instead of that, everyone is trying to make their own API. As a result, developers just write everything in electron/WebKit/WebView. I wish there was an open standard API for writing native desktop/mobile apps that OSes could adhere to (that the EU forces them to adhere to, haha).

0x6c6f6c 3y ago
I've seen Dart filling this gap for many apps lately
jdmoreira 3y ago
Yeah they did that multiple times already. One of them was Java/JVM. That was exactly how they pitched it in 1998
- apatheticonion 3y ago
  I suppose it's the execution that is important. Given that GUI applications share a lot of aspects between platforms, I'd love to see an open "Vulcan"-like standard that defines a GUI API for native platforms. OSes can interpret calls to that API such that the result looks congruent with the platform's design language - while the application code itself remains portable between platforms. It's really not that hard to define, there's just no willingness to do so from OS vendors as it would erode their efforts to build walls around their platforms POSIX became a standard because the US government needed software interoperability with their hardware. It wasn't enforced, but you'd miss out on the government contract lottery if you didn't adhere. If we value competition in the OS space, it would be wise to support an initiative that would make the OS itself unimportant

adonese 3y ago

I have a mobile app sitting around. Wrote it in 2020ish, Corona year. The mobile app is written in flutter and the server is in Go, you probably know by now where I'm heading with this. I cannot even express how hellish and nightmare that whole flutter thing is: I'm worried about the engine itself (there were breaking changes in the typing system itself that I'd need to worry about), the libraries and packages to update. And not to even stop at the building (signing) stage with the whole ruby shenanigans that needs to match and work well with xcode. Now compare that to go.