In early 2017 I was hired by YellowLabel as their CTO and only technical member to help them build out a platform designed to create a marketplace for discounted goods (products about to expire or that need to leave the shelf) across all supermarkets in the UK. The idea was to both help supermarkets decrease their waste levels and increase sales whilst helping customers save money on their grocery shopping.
This blog post is going to outline my journey in building a beta app for both iOS and Android devices using React Native. Despite this being my first experience building and releasing an app on the respective stores, the beta version was robust enough to withstand three separate beta tests held over several weeks and downloaded by thousands of users across the UK. I will go into more depth in the results of our last beta test in the next blog post.
As mentioned the app was built in what today we would call the ‘vanilla’ version of React Native (something I will explain in more detail later) coupled with Redux for app-level state management and Firebase’s non-relational real-time database and hosting service as a backend. I also had to write some python code to allow our operators to upload csv files to update our backend with new discounted item data.
Here are some screenshots of the product:
(that unfortunately were taken post-beta test are very limited)
Nothing broke during our multiple-week beta tests where hundreds of users across the UK were able to use our app to save money and decrease food waste!! This for me was the most incredible part as the app was built in only a few months without any previous experience. This was my first time delivering a product to a real customer and the feeling is still something that causes goosebumps when I think about it. I even had to make changes to the app during the beta test to fix some unforeseen bugs, but even those complicated deployments to the app store went well!! It was extremely rewarding to have our users email me individually thanking our team for our product!
React Native was still in its very early stages and was what we call today ‘vanilla’ React Native – there wasn’t even syntax check in editors! It was extremely hard and annoying to import libraries that went into the native systems of the phones such as maps and notifications. I actually had to restart the project four times due to installed packages unexplainably breaking everything. It was a real pain to have to open Android Studio and XCode to try and fix these problems despite the decent amount of support from the online community. Most would have given up on using React Native at this point, since the entire application relied on two libraries of this type, maps and notifications. The other issue with vanilla React Native was deploying to the two app stores which required going into Android Studio to create an apk and into XCode to deploy the app to the store.
I had one particular issue with the notification system that perfectly encapsulates the problems faced by early adaptors of React Native. At the time there were a myriad of third party libraries for notifications coded by oss developers mostly for their own or their employer’s particular needs, which meant each library came with its own trade-off in terms of functionality. I tried about 10 different libraries, several of which I was not even able to successfully install on both operating systems, but none of them were able to both receive the data from the backend about the notification and also actually emit the device-level notification. I ended up having to use a hybrid solution of the only notification library that would emit device-level notifications and a real-time link to a certain section of my db which would update itself when new discounted item data was loaded manually into our backend by our operators.
In hindsight, I had a lot of the same problems developers were experiencing in the early days of React Native. Researching my problems online, I came across a company named Exponent (now known as Expo) that promised to solve both the third party libraries (that need native capabilities of the device) installation process and to streamline deployment to both stores. Given the nascent days and limited capabilities of Expo, I never expected it to be the foundation in building v0 of the app.
Although using Redux was not a problem in terms of functionality, a lot of people in the community shared my feeling of over-verbosity and complication for something as straight forward as app-level state managements. All these Providers, actions, and reducers proved to be something that bothered the React core developer team too as years later in React v18 they introduced the world to the Context API which promises to solve these state management issues.
The other elephant in the room in the tech stack is the use of Firebase as a backend, which really seemed to have been designed for test projects not an app used by hundreds of real users at the same time!! It was really easy to use and link with React Native at the time so I decided to stick with it and work out any negative externalities in the front-end. Luckily it never crashed on us despite the very ‘hacky’ way our operators uploaded new discounted items into the database. I knew that my next backend would have to be built on a proper hosted server and I already had in mind to use the Node/MongoDB/GraphQL stack as I’d been reading that this was the most frequently used by the community.