Going Mobile With React Native(blog.clubhouse.io)
blog.clubhouse.io
Going Mobile With React Native
https://blog.clubhouse.io/going-mobile-with-react-native-891e1a602465
51 comments
https://facebook.github.io/react-native/showcase.html
I use some of the apps that are listed above, and I don't really have a problem with the performance.
Can you explain little bit more on how not using the native components can be big problem when your app gets bigger? I am asking because i really consider using React Native.
Or maybe give an example under which circumstances will those app fail to perform?
I used Cordova and the "lag" makes it clear from the first 5 seconds that it is not a native app. But i haven't experienced it from the apps that they listed on their page.
I use some of the apps that are listed above, and I don't really have a problem with the performance.
Can you explain little bit more on how not using the native components can be big problem when your app gets bigger? I am asking because i really consider using React Native.
Or maybe give an example under which circumstances will those app fail to perform?
I used Cordova and the "lag" makes it clear from the first 5 seconds that it is not a native app. But i haven't experienced it from the apps that they listed on their page.
Not using native widgets/concepts and single threaded are two distinct problems.
Single JS threads restricts your business logic a lot. If you start doing any serious work in JS, your app will suffer greatly.
Regarding native components, the result is that views just don't look native, animations are not native (even down to different timing functions), view behaviors are different (the RN button fade out on tap is different than UIButton, etc).
On top of that, since the JS thread is responsible for UI rendering and business logic, if your JS thread is busy, UI is "stuck", being unable to rerender until the JS thread is freed.
All these issues pile up to create a bad result at the end. Add to that the human element (not always being mindful of performance implications), and it is worse. But, definitely, the ceiling is very low at how much you can achieve.
I say all these things from experience; I work next to a team of dedicated RN developers at my company. In many cases, the need to drop to native is apparent and necessary, which makes the point of RN moot.
Certainly, RN is better than Cordova; no doubt about that. But it's just not as good as many people want to fool themselves at believing.
Single JS threads restricts your business logic a lot. If you start doing any serious work in JS, your app will suffer greatly.
Regarding native components, the result is that views just don't look native, animations are not native (even down to different timing functions), view behaviors are different (the RN button fade out on tap is different than UIButton, etc).
On top of that, since the JS thread is responsible for UI rendering and business logic, if your JS thread is busy, UI is "stuck", being unable to rerender until the JS thread is freed.
All these issues pile up to create a bad result at the end. Add to that the human element (not always being mindful of performance implications), and it is worse. But, definitely, the ceiling is very low at how much you can achieve.
I say all these things from experience; I work next to a team of dedicated RN developers at my company. In many cases, the need to drop to native is apparent and necessary, which makes the point of RN moot.
Certainly, RN is better than Cordova; no doubt about that. But it's just not as good as many people want to fool themselves at believing.
I see, thanks for getting into details.
I guess, if you are one-man team RN makes good sense since you don't have time to write native for 2 platforms from the beginning. If your app takes off, then switch to native for scaling. Is it possible to partly switch from RN to native? something like convert components one by one to native components, while still running RN for some parts?
I guess, if you are one-man team RN makes good sense since you don't have time to write native for 2 platforms from the beginning. If your app takes off, then switch to native for scaling. Is it possible to partly switch from RN to native? something like convert components one by one to native components, while still running RN for some parts?
Why not use Xamarin's stuff to do it all in C# instead then?
Because Xamarin and all the other cross-platform libraries are as bad or much worse.
Most apps don't need native performance, and most that do only need it in a single component. Really good software architects and devs know where a framework like RN is valuable.
Most apps don't need native performance, and most that do only need it in a single component. Really good software architects and devs know where a framework like RN is valuable.
Xamarin is a good choice indeed. Their constant work to create native mapping is very impressive.
Yes, that is certainly possible. It doesn’t have to be 100% either way, you could do any combination of React Native and proper Native you want.
The single threaded nature is a big problem. I have led teams building large RN apps and it is then #1 problem we experience at scale.
The worst bit is that you can only pass strings between threads in JS. Which means you have a lot of serialisation and deserialisation overhead, which can become the cause of UI slowdowns itself, which is a whole world of pain.
The worst bit is that you can only pass strings between threads in JS. Which means you have a lot of serialisation and deserialisation overhead, which can become the cause of UI slowdowns itself, which is a whole world of pain.
Well you can pass TypedArrays as well (using a zero-copy "transfer" method), but that's of fairly limited use.
What does "at scale" mean in this context (mobile application)?
It means an application that is beyond displaying a short list in a two — three screens. Once you start having a real business logic, you hit the relatively low ceiling. And the usual advice of “if you need more, just write a native component” — a. does not scale in performance either and b. what’s the point, just write in native in the first place and save yourself the headache of having to learn or hire native developers at moment of crisis.
Delegate the business logic to a server, I'm not sure what kind of "real business logic" needs to live in a mobile app
Then you don’t understand mobile development. There is absolutely no need to run business logic that can run on mobile on a server. Mobile devices today are more powerful than the majority of laptops out there.
Such as? Still no examples, I see.
Without a real architecture you don't get to complain that a hamhanded solution is less than optimal
Without a real architecture you don't get to complain that a hamhanded solution is less than optimal
For example, a mail app, a chat app. Would not scale at all with RN (or mobile web in web view). Imagine having to preload hundreds or thousand messages or other existing content while the user is viewing or typing. None of that is applicable to "server side business logic". Not if you want a quality app.
This is false, mail and chat apps work fine with multiple hybrid app frameworks. I've created plenty of hybrid apps that have 100s of items in lists, this is what ListViews are designed for. There's no limitation inherent to hybrid apps that prevents holding 1000s of objects in memory. This also works fine on mobile web if it's designed right.
If the mobile client can't handle 100,000 messages (probably more an issue of bandwidth or latency than local memory), then page them from the server. That's where serverside becomes relevant, at huge scale.
I'm not sure you understand how architecture of a mail or chat app would work.
If the mobile client can't handle 100,000 messages (probably more an issue of bandwidth or latency than local memory), then page them from the server. That's where serverside becomes relevant, at huge scale.
I'm not sure you understand how architecture of a mail or chat app would work.
In the past, I have built both a large enterprise-grade mail/calendar/contacts app which interfaces with Exchange, as well as a chat app:
https://www.checkpoint.com/products/capsule-workspace/#overv...
https://itunes.apple.com/il/app/check-point-capsule-workspac...
RN list views are terrible, as all the data is held in memory. For a chat or a mail apps, that's catastrophic. "Paging on the server" is not a solution; users want all their data on the device.
In my previous comment, I actually meant a different scenario than displaying a list. Take any proper mail client or a chat app; the first thing they do once a user logs in is start preloading previous data that can be found in cloud / on the server. Depending on the amount of data available, that is a very serious undertaking in and of itself, doing it efficiently enough in the background while updating the UI where needed upon insertion. This is just not possible in a single-threaded JavaScript.
Your mindset of only holding a small subset of data on the mobile is erroneous and is empirically not what users want; it's a web mentality and has no place in any app development but web. We went with this approach, albeit for security reasons. The result was the vast majority of users were unhappy. Users wanted a full blown Outlook in their mobile, and there was no reason not to give it to them.
https://www.checkpoint.com/products/capsule-workspace/#overv...
https://itunes.apple.com/il/app/check-point-capsule-workspac...
RN list views are terrible, as all the data is held in memory. For a chat or a mail apps, that's catastrophic. "Paging on the server" is not a solution; users want all their data on the device.
In my previous comment, I actually meant a different scenario than displaying a list. Take any proper mail client or a chat app; the first thing they do once a user logs in is start preloading previous data that can be found in cloud / on the server. Depending on the amount of data available, that is a very serious undertaking in and of itself, doing it efficiently enough in the background while updating the UI where needed upon insertion. This is just not possible in a single-threaded JavaScript.
Your mindset of only holding a small subset of data on the mobile is erroneous and is empirically not what users want; it's a web mentality and has no place in any app development but web. We went with this approach, albeit for security reasons. The result was the vast majority of users were unhappy. Users wanted a full blown Outlook in their mobile, and there was no reason not to give it to them.
I don't see how any of this is a limitation of React Native and not a result of poor app architecture. If a list is too big to fit in RAM, but not too big for the device, page it from the local SQlite DB. All kinds of web and mobile apps asynchronously fetch remote data while keeping a responsive UI. There are also service workers and other ways to prioritize UI.
The vast majority of popular chat and email apps keep at least some of the data on the server by default -- Gmail, K9 mail, Outlook itself -- so I don't see where there is proof that users want something different.
The vast majority of popular chat and email apps keep at least some of the data on the server by default -- Gmail, K9 mail, Outlook itself -- so I don't see where there is proof that users want something different.
Could not agree more. There are certainly benefits to using React Native, especially when bootstrapping an app and you've already got a React shop, but once your app and user base gets larger it creates a serious barrier to actually taking advantage of the native platform and it's capabilities.
If all UI components in React Native are implemented in JS then what is "native" about it? Is NativeScript more native than React Native?
Also is NativeScript multithreaded?
Also is NativeScript multithreaded?
NativeScript is still single threaded. It’s the nature of the beast.
On the other hand, NativeScript's UI mapping is directly on top of the platform widgets, as far as I remember.
On the other hand, NativeScript's UI mapping is directly on top of the platform widgets, as far as I remember.
Correct. Every React Native component actually renders into a native view, so on iOS if you use a View (RN) it maps to a UIView when React Native actually builds the UI.
Mapping to UIView is about the only thing that is “native” about React Native. My comment was about Native Script, which uses actual native widgets and concepts, such as controllers, animations systems, navigation, etc.
Most of your reaction is anger and hate. That cannot be the truth. The truth is always balanced. If you were right then all of us who love React Native and have used it to build amazing cross-platform UX are wrong or have less insight than you, which cannot be true unless you've got some real insight or something, which is certainly not true.
The whole point of React Native is to develop apps for both iOS and Android (you seem to be an iOS focused developer so you wouldn't care but many of us are targetting both) and doing that easily (for those who build RN and those who use it) means we have to create a standard set of behaviors that work across both platforms and work far better than running a web app in a webview. React Native achieves that goal. But it also has an enormously capable ecosystem with companies like Airbnb and Wix making substantial contributions to things like Native cross platform Navigation libraries.
When it comes to threading, the native views run in the main UI thread (just like native views would in any native environment) while the JS business logic runs in its own thread. To minimize serialization costs between JS and Native a lot has been done so JS objects like styles are passed by numeric reference. You can always use something like react-native-fetch-blob to natively fetch an image or some other heavy asset and go around the JS-Native bridge. But you can also use Inage component to fetch and remder images without serializing over the bridge. The user community has many other examples and great libraries to complement React Native. All you have to do is be curious rather than judgemental and harshly criticizing things that you obviously lack in-depth knowledge about.
When it comes to layout, Flexbox and support for percentage based siIng give us the primitives we need to replicate the familiar responsive grid systems we use on the web. See this for example:
https://github.com/idibidiart/react-native-responsive-grid
And as far back as August 2015, I was able to create a custom keyboard in Obj-C and expose it as a React Native component:
https://m.youtube.com/watch?v=YV3p09KoYKw
There is nothing that could not be done with a combination of platform specific knowledge and React Native, and the technology is still evolving.
So Facebook has shared their work with us and we shared our work with the community. What do you have to share besides criticism of other people's work? Do you have any work of your own that helps others build things? Put it out there and open it to criticism from random folks on the internets. Let's see your true genius!
The whole point of React Native is to develop apps for both iOS and Android (you seem to be an iOS focused developer so you wouldn't care but many of us are targetting both) and doing that easily (for those who build RN and those who use it) means we have to create a standard set of behaviors that work across both platforms and work far better than running a web app in a webview. React Native achieves that goal. But it also has an enormously capable ecosystem with companies like Airbnb and Wix making substantial contributions to things like Native cross platform Navigation libraries.
When it comes to threading, the native views run in the main UI thread (just like native views would in any native environment) while the JS business logic runs in its own thread. To minimize serialization costs between JS and Native a lot has been done so JS objects like styles are passed by numeric reference. You can always use something like react-native-fetch-blob to natively fetch an image or some other heavy asset and go around the JS-Native bridge. But you can also use Inage component to fetch and remder images without serializing over the bridge. The user community has many other examples and great libraries to complement React Native. All you have to do is be curious rather than judgemental and harshly criticizing things that you obviously lack in-depth knowledge about.
When it comes to layout, Flexbox and support for percentage based siIng give us the primitives we need to replicate the familiar responsive grid systems we use on the web. See this for example:
https://github.com/idibidiart/react-native-responsive-grid
And as far back as August 2015, I was able to create a custom keyboard in Obj-C and expose it as a React Native component:
https://m.youtube.com/watch?v=YV3p09KoYKw
There is nothing that could not be done with a combination of platform specific knowledge and React Native, and the technology is still evolving.
So Facebook has shared their work with us and we shared our work with the community. What do you have to share besides criticism of other people's work? Do you have any work of your own that helps others build things? Put it out there and open it to criticism from random folks on the internets. Let's see your true genius!
Don't confuse anger with distaste. I have a profound distaste for mediocre software. I have distaste for software that looks terrible so the lazy developers can "doing that easily". I, as a user of software, don't care about your ease. I want to have good software, not a minimum value product. From your comment here, you obviously care little for platform-standards; you describe "a standard set of behaviors that work across both platforms and work far better than running a web app in a webview", as if that's some measure of quality. My measure of quality is higher, and I have the stage here and elsewhere to try and spread my message. If you don't like my message, you are welcome to downvote and/or click the [-] button on my posts.
"If you were right then all of us who love React Native and have used it to build amazing cross-platform UX are wrong or have less insight than you, which cannot be true unless you've got some real insight or something, which is certainly not true."
I work at Wix. I have a lot of insight into what I am talking about. We have one of the largest React Native applications out there. I have also contributed to the react-native project itself, and have intimate knowledge of how most of it operates. I have, and am, building tools to improve work with RN. I have an extensive iOS knowledge, and I have access to Android developers with extensive Android knowledge. We happen to share our opinion on RN.
"There is nothing that could not be done with a combination of platform specific knowledge and React Native, and the technology is still evolving."
Try running JS business logic concurrently. (Multiple JS VMs does not count.)
"What do you have to share besides criticism of other people's work?"
What a ridiculous statement. So I can't criticize terrible technology unless I, alone, have created a competing tech to Facebook, who employs hundreds of engineers?
Nonetheless, here are some open source projects which I have contributed or created:
https://github.com/wix/AppleSimulatorUtils
https://github.com/wix/detox
https://github.com/wix/DTXSourceMaps
https://github.com/wix/DetoxInstruments (WIP - no read me or documentation yet)
https://github.com/LeoNatan/LNNotificationsUI
https://github.com/LeoNatan/LNPopupController
https://github.com/LeoNatan/LNInterpolation
Before that I worked at Check Point Software Technologies, a security company, where contributing open source was frowned upon.
"If you were right then all of us who love React Native and have used it to build amazing cross-platform UX are wrong or have less insight than you, which cannot be true unless you've got some real insight or something, which is certainly not true."
I work at Wix. I have a lot of insight into what I am talking about. We have one of the largest React Native applications out there. I have also contributed to the react-native project itself, and have intimate knowledge of how most of it operates. I have, and am, building tools to improve work with RN. I have an extensive iOS knowledge, and I have access to Android developers with extensive Android knowledge. We happen to share our opinion on RN.
"There is nothing that could not be done with a combination of platform specific knowledge and React Native, and the technology is still evolving."
Try running JS business logic concurrently. (Multiple JS VMs does not count.)
"What do you have to share besides criticism of other people's work?"
What a ridiculous statement. So I can't criticize terrible technology unless I, alone, have created a competing tech to Facebook, who employs hundreds of engineers?
Nonetheless, here are some open source projects which I have contributed or created:
https://github.com/wix/AppleSimulatorUtils
https://github.com/wix/detox
https://github.com/wix/DTXSourceMaps
https://github.com/wix/DetoxInstruments (WIP - no read me or documentation yet)
https://github.com/LeoNatan/LNNotificationsUI
https://github.com/LeoNatan/LNPopupController
https://github.com/LeoNatan/LNInterpolation
Before that I worked at Check Point Software Technologies, a security company, where contributing open source was frowned upon.
You're very arogant in your stance so no amount of chipping away at your ego will help. I get that single-platform developers (those not targeting N platforms with one codebase) don't get the idea of cross-platform DX and what design and tech choices make it sustainable in the long run.
My stance is of quality software. I really don't care what technology you use as long as that technology (and the mindset of the developers using it) allow for creating that quality software. RN, in my opinion, does not. Xamarin is a much better tool, from my limited experience with it. Xamarin Forms is just as terrible, though.
Any software that does not use the full benefit of each platform it is running on is mediocre at best for me, let alone something that is limited to a single thread, and reinvents the wheel for simple and/or solved stuff, such as navigation, animation and OS widgets.
I do think that of all the cross-platform approaches, going the native UI and C/C++ business logic approach is best.
Any software that does not use the full benefit of each platform it is running on is mediocre at best for me, let alone something that is limited to a single thread, and reinvents the wheel for simple and/or solved stuff, such as navigation, animation and OS widgets.
I do think that of all the cross-platform approaches, going the native UI and C/C++ business logic approach is best.
If you hate it so much, why work at a company that produces mediocre software?
Good question. I am a believer of change from within, but also, I do find joy in the tools I develop. They are not related directly to the company product software or its quality, but hopefully it helps others improve their development experience.
Thanks Leo. I've seen a few of Tal Kol's posts and talks, and it seemed to me that Wix was all in on React Native. Thanks for sharing a different point of view.
Tal is my team leader. We often have heated debates on these topics within the team.
I've seen Tal's talks and based on his passion and enthusiasm I do not see Wix moving away from RN, for as long as FB actively pushes RN forward. If FB drops it that's a different story.
NativeScript does not support GL/ThreeJS but RN does so I expect games will be built on top of RN. And when that happens we should get lots of new entrants in the ecosystem and greater creative mass.
NativeScript does not support GL/ThreeJS but RN does so I expect games will be built on top of RN. And when that happens we should get lots of new entrants in the ecosystem and greater creative mass.
I see. How likely is it that Wix is switching back to pure native?
Regarding the margin and layout guides: You can use Tachyons.css on react-native to easily achiever proper layouts: https://github.com/tachyons-css/react-native-style-tachyons
The problem is that since the native system of the OS are not used, you always play catch up with the OS in order to look fully native. It just doesn’t scale.
Exactly. It’s an abstraction, you will always be a few libraries and components away from implementing what you actually want, but that’s a lot to build on just to use a system provided tool. For instance, I’m working on upgrading my company’s app to use iOS 11’s new password auto fill APIs. All it needs is for you to set the UITextField’s contentType properly to one of a dozen enumerated values, in this case Username and Password. React Native doesn’t expose that propertie on the TextField component however, so I have to either build my own extension on top of the TextField component or form the React Native project and submit a PR to get this feature working, a feature that’s explicitly supposed to be painless to implement. There are so many cases like this around React Native, the community mindset is usually just to find another dependency to integrate.
“the community mindset is usually just to find another dependency to integrate.”
I fear it’s JS development mindset in general. I mean, you start a new project in RN, you get 1200 NPM dependencies. You start work, and you get thousands of dependencies. All that piles up to a huge amount of code that has to be parsed on start up (no ahead of time compilation or JIT).
I fear it’s JS development mindset in general. I mean, you start a new project in RN, you get 1200 NPM dependencies. You start work, and you get thousands of dependencies. All that piles up to a huge amount of code that has to be parsed on start up (no ahead of time compilation or JIT).
That is one of my pains with react-native and the JS-community. Their tooling sucks, because they use javascript for everything.
Having a NullPointerException/"undefined" in my code means I have to go hunt the bug for a couple of minutes. Having it in my buildtool means I my productivity drops to zero for an hour.
RN also keeps using deprecated and old version of android-buildtools.
Fun fact: "NullPointerException" gives 2.47 million results on google.
"cannot read property of undefined" gives 3.71 million results.
(Background: I'm a Java, Kotlin and JavaScript developer, shipped an app using react-native for the Views only, but Kotlin for the business-logic. I also picked some fights with the RN-maintainers on github issues.)
Having a NullPointerException/"undefined" in my code means I have to go hunt the bug for a couple of minutes. Having it in my buildtool means I my productivity drops to zero for an hour.
RN also keeps using deprecated and old version of android-buildtools.
Fun fact: "NullPointerException" gives 2.47 million results on google.
"cannot read property of undefined" gives 3.71 million results.
(Background: I'm a Java, Kotlin and JavaScript developer, shipped an app using react-native for the Views only, but Kotlin for the business-logic. I also picked some fights with the RN-maintainers on github issues.)
> the community mindset is usually just to find another dependency to integrate.
I agree but tachyons.css is different.
OP asked for "margin and layout" guides.
Tachyons gives you exactly that. A dimensional and typographic scale without forcing you into their framework, because it uses atomic classes.
http://tachyons.io/#style
I agree but tachyons.css is different.
OP asked for "margin and layout" guides.
Tachyons gives you exactly that. A dimensional and typographic scale without forcing you into their framework, because it uses atomic classes.
http://tachyons.io/#style
I work with both native iOS and React Native on daily basis. Both had their own (dis)advantages and it's hard to have a definite answer on which is better. It all depends on the nature of the app you want to build, your budget and trade-offs you are willing to take. RN is moving fast and has improved a lot in the recent months but still has some pain points:
- If you want to build a chat app, forget about well working sticky text input. (https://github.com/facebook/react-native/issues/371)
- All the dev time you have saved with hot reloading will be lost if you hit the infamous 4968 (https://github.com/facebook/react-native/issues/4968)
- Multithreading, but that has been covered in other comments. If you're obsessed about buttery smooth UI you'll have some unpleasant time.
Also :
- I find RN's ecosystem feeble and don't trust packages. Triple check everything you run npm install on.
- Using solely RN/JS is not an excuse to completely avoid learning native development. It bites in the future.
+ ScrollViews are great.
+ Build times are shorter, you get quicker feedback especially for UI small modifications.
+ I really enjoy working with RN's Animated API.
- If you want to build a chat app, forget about well working sticky text input. (https://github.com/facebook/react-native/issues/371)
- All the dev time you have saved with hot reloading will be lost if you hit the infamous 4968 (https://github.com/facebook/react-native/issues/4968)
- Multithreading, but that has been covered in other comments. If you're obsessed about buttery smooth UI you'll have some unpleasant time.
Also :
- I find RN's ecosystem feeble and don't trust packages. Triple check everything you run npm install on.
- Using solely RN/JS is not an excuse to completely avoid learning native development. It bites in the future.
+ ScrollViews are great.
+ Build times are shorter, you get quicker feedback especially for UI small modifications.
+ I really enjoy working with RN's Animated API.
This is a good list of pros and cons. I'd just add this:
+ App also runs on Android (and even web, and tvos)
I'm always surprised when people don't list this massive benefit when discussing RN. It's really the core value proposition. The fact that it's even in the conversation when developing for only one platform seems like quite an endorsement of the developer experience with RN.
+ App also runs on Android (and even web, and tvos)
I'm always surprised when people don't list this massive benefit when discussing RN. It's really the core value proposition. The fact that it's even in the conversation when developing for only one platform seems like quite an endorsement of the developer experience with RN.
Definitely. That is also my main reason for mentioning the budget - building one app for multiple platforms is (usually...) cheaper.
Scrollviews are relatively easy, but table (list) views and collection views are terrible due to the way RN is implemented internally. FlatList, while a small optimization over the normal ListView, is still just not good enough.
As a professional JS and iOS developer, I have to say that React Native is not the way to ever go unless you need to quickly prototype proof-of-concepts. I'm in love with React, but not RN.
Apps just don't feel right (like something is off but you can't tell what), annoying bugs, hacky open source modules, and the fear that it will never live up to it's hype or be able to keep up with native apis.
If you need a quick poc, then use what you're most comfortable with. If your app is simple enough to make in RN, then do it in native. If your app is complicated then you won't be able to do it (successfully) in RN anyway.
Apps just don't feel right (like something is off but you can't tell what), annoying bugs, hacky open source modules, and the fear that it will never live up to it's hype or be able to keep up with native apis.
If you need a quick poc, then use what you're most comfortable with. If your app is simple enough to make in RN, then do it in native. If your app is complicated then you won't be able to do it (successfully) in RN anyway.
It's not really tips, is it, it's just a high-level React-Native-exists article. While I'm on though, what I'd really want to see in the next great-tips article are:
(1) How to make a project more future-proof? (Try it yourself: download any React Native demo app from the past 1-2 years, and see how many of those compiles without complaining about version, platform, what-not.)
(2) An actual cost analysis of a React Native project. My experience is that since most developers are still just learning RN, the good ones are too expensive or too busy, and you'll actually end up paying more for the same app.
(1) How to make a project more future-proof? (Try it yourself: download any React Native demo app from the past 1-2 years, and see how many of those compiles without complaining about version, platform, what-not.)
(2) An actual cost analysis of a React Native project. My experience is that since most developers are still just learning RN, the good ones are too expensive or too busy, and you'll actually end up paying more for the same app.
I can confirm the (1) problem. Recently I've tried to compile the app which was built in March 2017 and this was unpleasant and painful process: lots of build errors, version inconsistencies, etc.
Regarding (2) I think that good developers are always expensive, no matter which technology they use.
Regarding (2) I think that good developers are always expensive, no matter which technology they use.
React-Native is pretty good, mostly feels like doing regular React (web) development.
And if you get perf problems, just write things in the native languages with a bridge.
Not THE way to do mobile apps, but if you already know React, it's the way to go.
And if you get perf problems, just write things in the native languages with a bridge.
Not THE way to do mobile apps, but if you already know React, it's the way to go.
The newer react-navigation is actually a decent router. Before that the routing options were pretty bad
No, this is incorrect. Using merely UIView objects does not mean it is native. It’s not just an abstraction over native. Unlike something like NativeScript, the “great” minds at Facebook have decided to not only offer a JS wrapper around the native, but actually reinvent the wheel on everything. Tables? Let’s have a horrible implementation in JS. Gestures? In JS. Navigation? In JS. Animations? Core Animation you say? Nope. Even simple stuff like buttons are not native UIButton objects. There is nothing “native” in React Native.
Also, the single threaded model of JS just does not scale. The larger the app gets, the more and more it starts to lag. UI is rendering at 60 FPS, sure, but the lag comes from a constantly busy single JS thread.
And that’s before mentioning things like accessibility, large type support, basic iOS concepts such as margins and layout guides, etc. that are sorely missing from RN.
You want a ‘great’ tip? Don’t cheap out; hire native developers. Otherwise your users will suffer a lackluster and inferior product that looks nothing like the platform it’s running on.