오늘 주제는 리액트네이티브(ReactNative)는 플러터(Flutter)를 다시 따라잡을 수 있을까?입니다.

저도 받아들이기는 싫지만, 누가 그래?라고 하실까봐 한번 증명해보도록 하겠습니다.

1. 플러터가 리액트네이티브보다 시장에서 더 환영받는 건 사실입니다.

(리액트 네이티브 vs 플러터, ReactNative vs Flutter 시장 점유율)

전체 데이터를 보았을 때 플러터가 리액트네이티브보다 선호되고 있는 것은 이제 이견의 여지가 없습니다.

찾을 수 있는 모든 데이터를 바탕으로 이를 증명해보도록 하겠습니다.

1. - 구글 트렌드 : 플러터 > 리액트네이티브

구글 트렌드에서 보면 , 파란색이 리액트네이티브 , 붉은색이 플러터입니다.

플러터가 2020년초부터 검색량이 리액트네티이브를 추월한지 꽤 되었습니다.

https://trends.google.com/trends/explore?date=2018-01-02%202022-01-02&q=%2Fg%2F11h03gfxy9,%2Fg%2F11f03_rzbg

https://www.nomtek.com/blog/flutter-vs-react-native

• - 스택오버플로우 설문조사 : 플러터 > 리액트네이티브

프레임워크 기준으로 사용하고 있거나, 사용하고 싶거나 두개 부문 모두 플러터가 리액트네이티브를 압도하고 있습니다.

소폭으로 앞서고 있다고는 하지만, 밀리긴 밀립니다.

• - 스태스티카(Statstica) 점유율 : 플러터 > 리액트네이티브

• 플러터의 사용 점유율이 2020년부터 올라가면서, 상대적인 리액트네이티브 및 다른 프레임워크의 점유율이 떨어졌습니다.

  

• - 기능성 : 플러터 > 리액트네이티브

데스크탑, 게임어플리케이션, AR 등의 어플리케이션에서는 리액트네이티브는 어울리지 않습니다.

다시 말해, 동적인 요소가 많이 포함되거나, 뭔가 리소스를 많이 쓰는 앱에서는 플러터가 압도적이라는 의미입니다.

https://blog.flutter.wtf/flutter-vs-react-native/

2. 그래서 플러터 시장성 있으니까 쓰라는 이야기냐?

그 의도는 아닙니다. 두개의 언어차이(C++ vs Javascript)도 있고, 통신 방식도 많이 다르니까요

플러터가 빠르다는 건 , 여러가지 벤치마크에서 증명이 되었기 때문입니다.

그대로 이 차이를 인정하고 살아갈 수 밖에 없었죠. 아키텍쳐가 다른데 뭐 어떻하겠습니다.

플러터의 주요한 장점으로 이야기되는 특징은 두개입니다.

1) C++ 사용자가 익숙하게 크로스 플랫폼에 접근할 수 있다.

2) 자체 캔버스를 쓰기 때문에, 빠르게 화면을 그릴 수 있다.

리액트의 주요한 장점은 또한 두개정도입니다.

1) 기존 레거시(웹 서비스)를 가지고 있는 사람은, 대부분의 코드를 재활용이 가능하다(특히 함수레벨)

2) 실제 네이티브에 쓰는 컴포넌트를 불러와서 사용할 수 있다.

근데 리액티네이티브를 계속 써왔고, 그것밖에 못쓰는 자바스크립트쟁이는 분하긴 하죠

어이어이 리액트네이티브 힘좀 내라구? 초사이언으로 레벨업 노력이라도 해라 임마!!!!!!

3. 리액트네이티브 0.73 뭐 다른게 있어?

저는 리액트네이티브 버전 업그레이드에 대하여 상당히 둔감합니다.

리액트네이티브 버전의 업그레이드는 대부분은 두가지입니다.

1) 리액트자체의 버전이나 안드로이드/IOS 버전의 올라감에 따라 대응하는 버전 업데이트

2) 버그 픽스

그렇기 때문에, 버전이 올라가면 엄청 귀찮게 테스트를 많이 하고, 전체 패키지를 올리는 수고가 필요하긴 하지만,

여러가지 설정만 변경해주면 되니, 테스트 포함해서 일주일정도 걸리니, 안드로이드, IOS 두개 적용한다고 가정하면, 나쁘지 않습니다.

0.71부터 뭔가 바뀐다는 것을 눈치챘습니다.

렛플은 2024년 2월까지는 0.70.X 버전을 활용하고 있었습니다.

0.70.X 버전은 2022년 9월에 나온버전입니다. 3개월정도마다 주요 패치를 하기 때문에 2022년말까지는 가장 최신버전이라고 볼 수 있습니다.

2023년 0.68버전에서 0.70.X 버전을 올리려고 고민할때, RN의 가장 최신 버전은 0.72버전이었습니다.

그래서 0.72버전으로 바로 올리려고 했는데, 뭔가 변화가 엄청 많더라구요.

몇번 도전하다가, 이건 일주일 분량으로 보이지도 않고, 전체 프레임워크 구조가 변경되는 느낌이 강해서 포기하고 0.70버전까지만 적용했습니다.

실제 0.71부터 NEW Architecture들이 속속 들어가기 시작합니다.

https://reactnative.dev/blog

1) 타입스크립트 디폴트 지원

2) 데브툴(개발도구) 지원 및 아예 실험적인 디버깅 도구로 변경

3) Hermes 엔진의 통합

4) 뭔가 신규 아키텍쳐로 간다구???

그리고 0.73(2023년 12월)에서는 최종적으로 신규 브릿지리스 모드(bridgeless mode)가 최종적으로 나왔습니다.

4. 그래서 호들갑떨정도로 많이 바뀐거야?

브릿지모드는 리액트네이티브의 가장 근간이 되는 개념입니다.

브릿지모드를 통해서 네이티브 기기와 통신을 하고, 네이티브의 컴포넌트를 가져다 쓸 수 있는 방식이고,

이게 다 코르도바(Cordova)에서부터 시작된, 자바스크립트를 이용한 앱 만들기 프로젝트의 연장선상입니다.

또한 이 브릿지모드 때문에, 리액트네이티브가 느릴 수 밖에 없다라고 평가하는 이야기가 상당히 많았죠.

이에 비해 플러터는 브릿지모드를 쓰지 않기 때문에 빠르다라고 평가받기도 합니다.

리액트는 플러터와 싸우는데 진심모드를 꺼냈습니다.

0.73버전 보기전에는, 저는 생각햇습니다.

“리액트네이티브야, 플러터의 좋은점좀 가져와서 베끼자.

아무리 내가 열심히 한들, 니네가 느린데, 렛플앱이 빨라지는데 한계가 있잖아.”

렛플앱에도 속도개선을 엄청나게 하는데도, 한계점이 분명하다는 것을 느끼고 있었습니다.

속도가 이렇게 느리다는데, 굳이 브릿지써야되니, 컴포넌트 캔버스에 그리면 안되냐? 사람들 그렇게 신경안쓴다구.

근데 진짜 브릿지모드 없앴어?. 오이오이 믿고 있었다구?!

5. 속도 개선효과를 확인해보자

제가 어제 몇시간동안 검색을 해봤는데, 아직 아예 플러터와 속도 레벨까지 대비해본 퍼포먼스 벤치마킹 자료는 없었습니다.

다만, 기존과 얼마나 다른지에 대해서는 몇가지 문서들이 있어 소개해볼까 합니다.

가장 중요한 핵심은, 리액트네이티브가 속도에 진짜 신경쓰기 시작했다는 점입니다.

다만 이 버전은 0.72버전을 바탕으로한 결과입니다. 0.73버전에서는 얼마나 올라갔는지는 조금 시간을 기다려봐야할것 같습니다.

브릿지모드까지 적용해서 속도를 잰다면, 더 속도가 올라가지 않을까 싶습니다.

https://github.com/reactwg/react-native-new-architecture/discussions/85

https://rn-new-arch-perf.netlify.app/a10s/manyviews/report

전체 점수는 두배정도 높아진것으로 평가되고 있습니다.

2024년 3월부터는 아예 0.73버전으로 업데이트 했습니다.

아예 패키지만 올리는게 아니라 그냥 폴드구조와 네비게이션 구조를 모두 변경하였습니다.

다만 신규 아키텍쳐에 대응하기 위해서 , 전체 연관 패키지들이 변경되고, 손을 많이 대야 됩니다.

테스트 지옥을 한달간 진행하였습니다.

그래서 저희 렛플앱은 2.0.1 버전부터 브릿지모드를 적용해보았습니다. 얼마나 빠른지 체감을 해보세요.

지난 버전과 얼마나 속도가 다른지 체감해보시고, 각자 서비스에 적용하실지 검토한번 해보시죠?!!

https://play.google.com/store/apps/details?id=org.letspl.awesomecrew&pli=1

https://apps.apple.com/kr/app/id1595017110

이제 리액트네이티브(RN)파는 고개를 드세요.

참고.RN vs Flutter vs Native

이전에 각 프레임워크별 성능비교한 자료는 이것 참고해보세요

https://mondayless.tistory.com/m/29

많은 이미지의 Android Test 결과

참고.리액트네이티브 0.73의 새로운 아키텍처 상세

브리지리스 모드 소개 – 새로운 아키텍처 업데이트

React Native 개발자는 오픈 소스 커뮤니티의 다른 개발자에게 면세를 제공하기 위해 세 번째 기둥을 출시합니다.

사용자는 React Native 0.68부터 새로운 네이티브 모듈 시스템(TurboModules)과 새로운 렌더러(Fabric)를 모두 테스트하고 탐색할 수 있습니다.

우리는 지금까지 커뮤니티의 의견에 감사를 표하고 싶습니다.

팀은 12월 8일에 New Architecture의 또 다른 구성 요소인 Bridgeless 모드를 출시했습니다.

지금까지 Bridge는 앱에서 새 아키텍처를 활성화할 때 이전 구성 요소 및 모듈과의 하위 호환성을 지원하는 데 사용할 수 있었습니다.

하지만 Facebook 소유자의 목표는 브릿지인터페이스를 없애는 것입니다.

브리지리스 모드는 React Native 0.73부터 활성화할 수 있으며, 이를 통해 브리지 생성을 완전히 방지할 수 있습니다.

브리지리스 모드와 함께 기본 모듈 상호 운용성 레이어를 제공하므로 브리지리스 모드에서 기존 모듈을 사용할 수 있습니다.

이 새로운 아키텍처는 풍부한 잠재력을 갖고 있는 것처럼 보이지만 아직 실험 단계에 있습니다. 그러므로 그것에 전적으로 의존하지 마십시오.

React Native 앱 개발자가 문제에 직면하거나 새 업데이트가 호환되지 않는다고 생각하는 경우 New Architecture Working Group에 문의할 수 있습니다.

디버깅 개선

우리 모두는 Hermes가 React Native에 최적화된 오픈 소스 JavaScript 엔진이라는 것을 알고 있습니다.

두 팀(Hermes 및 React Native)은 React Native 앱 개발 서비스의 디버깅 경험을 개선하는 데 가장 적합합니다.

Hermes의 콘솔 로그 기록

가장 빠른 디버그 감지기 중 하나는 console.log()입니다.

이전 0.72 릴리스에서는 모바일 앱 개발자가 React Native 앱의 콘솔 로그를 사용했지만 디버거가 디버거에 연결될 때까지 기록하지 않았습니다.

이로 인해 앱 로드 과정에서 발생한 로그를 캡처하기가 어려워졌습니다.

React Native 0.73에서는 Hermes infusion의 도움으로 이 문제를 극복했습니다.

Hermes는 이제 웹 브라우저의 디버깅 환경과 일치하도록 디버거가 처음 연결될 때 콘솔 탭을 보내 시스템 뒤에서 실행되는 모든 console.log()를 감지할 수 있습니다.

Flipper, Hermes에 연결된 Chrome DevTools 및 실험적인 New Debugger에서 이러한 변경 사항을 조정할 수 있습니다.

향상된 디버깅 문서

React Native 플랫폼의 모바일 앱 개발자는 설명서의 디버깅 섹션을 완전히 업데이트했습니다.

새로워진 이러한 변경 사항에는 이제 지원되는 모든 디버거를 연결하는 방법에 대한 정보, React DevTools에 대한 더 많은 통찰력, 새롭고 매력적인 시각적 아이디어가 포함됩니다.

실험적인 새로운 디버거

지금까지 우리는 0.73이 실험에 관한 것이라는 점을 이해했으며,

따라서 Flipper를 최신 React Native 버전에만 통합된 새로운 Technical Preview로 대체하는 것을 목표로 하는 많은 새로운 디버깅 기능이 포함되어 있습니다.

새로운 디버거는 더 빠르게 작동하며 Hermes를 사용하여 React Native를 디버깅하기 위한 맞춤형 Chrome DevTools UI를 추가합니다.

그러나 이 새로운 업데이트는 실험 단계에 있으므로 모바일 애플리케이션을 구축하는 동안 문제가 발생하면 즉시 보고되어야 하므로 이에 의존하지 말 것을 다시 한 번 상기시켜 드립니다.

Metro의 안정적인 Symlink 지원

Metro는 React Native 인프라의 안정적인 개발 플랫폼입니다.

이는 심볼릭 링크에 대한 지원을 제공하는 JavaScript 번들러 및 확인자 역할을 합니다. 이제 React Native의 Symlink는 무엇입니까?

간단히 말해서 심볼릭 링크는 모바일 앱 개발 서비스에 외부 모듈을 추가하는 간단한 방법입니다. 여러분이 해야 할 일은 'metro.config.js'라는 파일 이름을 만들어

React Native 루트 디렉터리에 넣는 것뿐입니다.