I'm under the impression, in Udacity's case especially, that part of the problem stems from asking native engineers to use a language and ecosystem that they're not used to working with, and then trying to get them to integrate RN code into an established, brownfield native codebase.
As a sole dev in a 3-person startup, I’ve managed to build a pretty large app with React Native, having zero prior native experience (although, that’s not to say that I haven’t had to learn a _lot_ about Xcode!)
I had a pretty similar experience. It's still a challenging environment - getting performance and memory management nailed across platforms and devices took some very careful engineering.
Based on my limited experience with native iOS app development, RN actually requires an almost completely different way of working.
That sounds like unnecessary complexity, skills and cost. Until it’s simpler to build, higher quality and a more predictable result than native, i will continue to use native frameworks.
That was my impression as well. What he wrote about localisation as well - they are trying to localise text in RN files, native iOS files and Android files, maybe using a different approach for each platform, so of course it's complicated.
I managed to localise a relatively large cross-platform app built in Electron and React Native using gettext and had no problem with it. It supports 18 languages and people send me update from time to time, which are very easy to integrate.
It seemed a large part of their frustration was integrating the native with react native. I think too if you decide to use react native you don't hire more iOS and Android specific devs, you hire react native devs and replace the entire native codebase.
> stems from asking native engineers to use a language and ecosystem that they're not used to working with
yes, so reminiscent of “enterprise” situations where SAP (or put any of your other favorite's name here) is so dominant. In a recent situation, the marketing side of the business kept asking for newer agile mobile technologies, and so the cio-purchasing-manager engages Gartner (or put any of your other favorite consultant’s name here) for guidance. Well, the result is to start an in-house prototyping team composed of who -- folks seeped in SAP maintenance but who wants to learn the newer mobile technologies for career development. They do create some prototypes but so many things remain open while they are busy doing their daily SAP work, their forte. The CIO then steps in to satisfy the marketing folks: We buy SAP’s packaged solution for mobility and an outside consultant will integrate it. Problem solved. Or is it? The answer waits another three years when the integration is really completed, by then the CIO leaves and the issues need to be visited again.
Can I reach out to you? My team will shortly be starting out with RN to build our mobile app. I'd love to get some pointers and advice on what we can do to make it as successful an experience as possible.
Show us the app and ideally some code to let us judge how well you managed then. I believe the standards for native development are well known at this point.
Checked this app out of curiosity. It’s decent but doesn’t feel native to me. Each platform has its own nuanced differences that we might think is okay to ignore but customers see through when the experience isn’t consistent with past expectations.
The transition animations in some situations were what felt out of place to me in particular.
1. When the app starts, the onboarding screen appears with a flicker/glitch: https://imgur.com/IyjM82n
2. The app starts with a launch image (the logo in the center), which then fades away to show another launch image (with the logo on the top half of the screen): https://imgur.com/0n3Zbof (probably because ReactNative must load the JS bundle before it can show anything)
3. The login screen of the application fits on the screen, yet it can be scrolled up/down for seemingly no reason. The amount you can scroll feels suspiciously close to the height of the iOS status bar: https://imgur.com/P6conGz (probably because ReactNative sets the UIScrollView's contentInset incorrectly)
4. Text fields / buttons look like on a website.
5. When you navigate back from the login screen after a failed login, there's a brief moment while the "Unsuccessful login with Facebook" message is visible, which then quickly disappears: https://imgur.com/hTTKbIt
Sorry, but it feels like a webapp to me. Though it might be perfect for your use case!
Update:
I've found some other issues:
6. You can't interact with buttons (e.g. "Next" button on registration) while the keyboard is visible: https://imgur.com/dpy5xv8
7. The first time you switch to a tab, it's completely empty, then suddenly the content pops into place: https://imgur.com/JKaCJED
8. Tapping on the search button makes the content of the previous page jolt against the top of the screen while navigating to the search page: https://imgur.com/BJDYvda (focus on the panda)
9. The "sidebar" menu feels very out of place on iOS. Also, when you select e.g. "Settings", the content on the right does a very weird fade/slide animation: https://imgur.com/ChNzvwW
10. When you switch between two non-adjacent tabs, the viewport slides over the in-between tabs too: https://imgur.com/BZFU0Sv
1. I reviewed the app. I didn't attribute any of the issues to React Native itself, did I?
2. The Airbnb and UberEats apps were written by expert native developers (I happen to know a few of them), using some React Native.
You see, expert native engineers can deliver quality apps using native frameworks. And surely, if they look into React Native, most of the time they can manipulate it from the JS side to get the desired outcome on the native side. The middleware is a hinderance for them as it gets in their way of implementing what they want in the first place.
It's like building those ship models in a bottle: if you know how to build the ship, you just have to learn how to do it through the neck of the bottle. If you don't know how to build it in the first place, well... that's a different story.
You have it wrong, only the restaurant dashboard app is built using ReactNative, that was done because they had a website earlier and they wanted to convert that quickly to a tablet app and their developers who were working on that web app had very limited knowledge of iOS/Android, refer to https://eng.uber.com/ubereats-react-native/
I definitely agree with the fact that it feels like a web app, but this is the design the customer asked for. Most of this things are actually not a React Native problem but the way the app was made. Onto your points:
1. This can easily be fixed with a module, however time pressure didn't allow for additional "tweaks"
2. Same as 1.
3. Using Scrollview for this, since some android devices with smaller screens can make the Login screen look very ugly and small, so in that case scroll looked better.
4. Do they look like or feel like ones on a website? It is by design, but interested to see how you feel about the fields as a user (although we don't support the app anymore)
If only we could learn from past experiences, many companies have done that in the past because some CXO thought that they could save some money using hybrid frameworks, didn't go well for them and they ended up writing native apps. It's like you are asking people to fire "Master of one" and hire "Masters of none".
Check out the landing page at https://vue-native.io/ at the bottom, "Compiles to React Native". It's important to note that "Vue Native" isn't officially endorsed by Vue.js.
Training budget for confs/courses/books is a big one for me, it shows that a company is invested in you and helping you further your career.
Another one is relaxed working hours and having a culture of trust with regards to when you're actually in the office. It shouldn't be a big deal if I need to leave early one day, or if I decide to do reduced hours but work flat out during the time I'm in the office, as long as the work gets done - who cares when?
I really disagree that it's a "waste of developer time" to use React for projects like this.
`npm install next react react-dom` takes an insignificant amount of time and gives you an extremely efficient developer experience immediately, with automatic code splitting, server side rendering and great modern CSS support. Compared to the amount of time I've spent over the years fiddling with gulp/grunt configuration files for "static websites", it's a no brainer for developers who are already productive in React.
React Native. Write the React we all know and love, be supported by a huge ecosystem and community, and leverage the power of OS level UI components and libraries whilst enjoying the ease of writing in JS. It’s making the production of a truly native-feel app completely painless and with little learning curve for an existing React/JS developer
Allows you to create custom MacOS menubar items from the text output of any script.