3 ms·

Some of your statements are partially correct, but a few of these assertions are flat out false for React Native. Let's look at them: > - Binary size. A basic

Some of your statements are partially correct, but a few of these assertions are flat out false for React Native. Let's look at them: > - Binary size. A basic Flutter/RN app easily pushes you past 20MB in app size on iOS, whereas a complex and complete app like Tweetbot is ~7MB. I have working examples of fairly complex production applications that are <=10 MB on iOS. > - Poor accessibility. Native iOS apps get a lot of accessibility for free because Apple has done a great job, with RN and especially Flutter you don't get this benefit. False statement. React Native provides you with ability to tag elements so you can use accessibility-tools to navigate the app. I have recently tested this with a RN app running on iOS 13 using the new voice control feature. Several testing frameworks also rely on these features being available.

K0nserv 7y ago
> I have working examples of fairly complex production applications that are <=10 MB on iOS. Fair, the problem isn't as bad for RN, for Flutter it's still very bad though. > False statement. React Native provides you with ability to tag elements so you can use accessibility-tools to navigate the app. I have recently tested this with a RN app running on iOS 13 using the new voice control feature. Several testing frameworks also rely on these features being available. The ability to tag elements is only a very simple basic requirment to get accessibility right. My point was more that if you use UIKit you get significant levels of accessibility for free. Just as a quick example I did a quick ddg search for "react native how to create custom button" and all 5-7 top results that I looked at failed to set the appropriate accessibility roles so the button actually appears as button to a user with the screen reader. Yes you can still do accessibility right with RN, but it's not the easy to get it right be default and most app developers will not do this on their own.
- scarlac 7y ago
  > failed to set the appropriate accessibility roles so the button actually appears as button to a user with the screen reader Appreciate that you looked into it. On iOS and you do not need to set anything to become screen reader friendly _in React Native_. The default TouchableOpacity with a simple piece of text inside of it will become focusable and iOS will read the text aloud for you. This works because RN uses native elements unlike Flutter, Electron, and others. In fact, I took you up on the claim that it wouldn't read correctly. I used my app just now which has never been tested or optimized for accessibility. Covered my eyes and began navigating. It works just fine! All tappable elements are indeed read aloud. I was able to navigate through the app settings, change them, go back, and reload other screens, navigate to the updated content, and perform actions on the new content. Please do not put RN in the same bucket as Flutter or Electron. They are fundamentally differently.

K0nserv 7y ago

> I have working examples of fairly complex production applications that are <=10 MB on iOS. Fair, the problem isn't as bad for RN, for Flutter it's still very bad though. > False statement. React Native provides you with ability to tag elements so you can use accessibility-tools to navigate the app. I have recently tested this with a RN app running on iOS 13 using the new voice control feature. Several testing frameworks also rely on these features being available. The ability to tag elements is only a very simple basic requirment to get accessibility right. My point was more that if you use UIKit you get significant levels of accessibility for free. Just as a quick example I did a quick ddg search for "react native how to create custom button" and all 5-7 top results that I looked at failed to set the appropriate accessibility roles so the button actually appears as button to a user with the screen reader. Yes you can still do accessibility right with RN, but it's not the easy to get it right be default and most app developers will not do this on their own.

scarlac 7y ago
> failed to set the appropriate accessibility roles so the button actually appears as button to a user with the screen reader Appreciate that you looked into it. On iOS and you do not need to set anything to become screen reader friendly _in React Native_. The default TouchableOpacity with a simple piece of text inside of it will become focusable and iOS will read the text aloud for you. This works because RN uses native elements unlike Flutter, Electron, and others. In fact, I took you up on the claim that it wouldn't read correctly. I used my app just now which has never been tested or optimized for accessibility. Covered my eyes and began navigating. It works just fine! All tappable elements are indeed read aloud. I was able to navigate through the app settings, change them, go back, and reload other screens, navigate to the updated content, and perform actions on the new content. Please do not put RN in the same bucket as Flutter or Electron. They are fundamentally differently.