One of the key reasons Red Badger chose to take on the Pride in London App was to give us the opportunity to gain more experience with React Native. React Native is an interesting choice for us. It complements our experience building web applications with React, and we have learnt a lot along the way.
Performance
Throughout our journey we have hit a number of performance issues with the app, and getting to the root cause has not been trivial either. Profiling is especially difficult if a particular issue is causing the app to lock or crash. There are some new tools on the horizon that may help with this, for example Sonar.
Most issues we have experienced have been solved in two ways. The first is by using Reacts shouldComponentUpdate lifecycle method to stop unnecessary rendering. The second is memoizing state transformations to avoid recomputation. These two solutions took our app from something that felt painfully laggy to something that is generally pretty smooth. We still have a few issues that we would like to resolve, however they are less of a priority than the features we are developing for parade day.
Maps, maps, maps
One of the core features of the app is the ability to see the Parade route and surrounding stages on a map. For this we chose to use an open source library, react-native-maps.
With this choice came an interesting bug that to date has caused about 40 crashes for our Android users. Not ideal. After a number of hours attempting to profile, hunting through Android logs and testing in emulators we found a way to fix the issue. We just had to disable a certain prop on the MapView component.
This experience has highlighted that a lot of 3rd party libraries, like our chosen map library, are somewhat fragile and can introduce hard to understand bugs over their lifetime. It pains me to think what bugs may be introduced in the future when upgrading this library. We have noticed that a fair number of libraries have missing or misleading documentation, are not supported by automated tests, or just do not work as expected. This has highlighted the immaturity of many libraries available to React Native projects and is an area that can definitely be improved.
Navigation
Another core piece of functionality is being able to navigate various screens in the app. Due to the design we wanted to achieve we ended up choosing react-navigation. This library is an interesting one, it emulates iOS and Android style navigation but completely in the JavaScript thread.
As with our map experience, our navigation choice also suffers from missing or misleading documentation and some unexpected behaviour. One problem we found was screens re-rendering even if they were not currently displayed. This problem was not obvious either. We only found the root cause after investigating some janky screens. As a work around we ended up implementing a wrapper for each of our screens to track if it was focused or not, and only update the screen if so.
I still have a sneaking suspicion this library is adding to other performance issues too. This is definitely an area that could be improved.
Accessibility
Pride are very conscious of ensuring their app is inclusive. As a result, one of the core non functional requirements was to reach an “AA” standard for accessibility. We did not anticipate how much extra work this would take. React Native feels somewhat immature in this space.
One issue we ran into was varying support across platforms for accessibility traits. Accessibility traits enable screen readers to present and navigate content in different ways. For example if you declare text as a headline, users will be able to quickly navigate to them. If you declare text as a button, users will know that they can interact with it. This works pretty well on iOS because React Native supports annotating these with accessibility traits. Android on the other hand only supports annotating these for buttons and radio buttons. This means navigating by headline in TalkBack is impossible.
Developing any mobile app has some interesting challenges even if you do not use React Native. According to the WCAG 2.1, users should be able to resize text to 200%. This is very challenging on small screens. Although we came close to meeting this requirement in most cases, we did not manage to achieve this everywhere without breaking the layout.
So that was all the negatives I could think of. All that said, we would not have a beautiful, functioning application delivered on two platforms if we were not using React Native.
React Native has enabled our team to quickly pick up developing for two new platforms. We have been able to build on principles we already know and understand. Given our teams lack of pure Native experience in iOS and Android I believe if we tried to tackle the project without React Native, we would have very little to show for all of our effort.
Find out more about the project here.
This blog article was first published on red-badger.com/blog