💡 For reasons of rights and confidentiality, I am not able to communicate the name of the project on which I worked.
But I will give you some details on the requirements and details we had to deals with to achieve that goal.
- The project developments were started 6 weeks before its strong deadline. Which means there was no way to get more time.
- It involved 5 separate teams from 5 companies in data exchanges, customer, web development and mobile development. My team worked on the mobile application with a small backend for push notifications using serverless Firebase Functions (Google Cloud Functions).
- Specs and design has been changing throughout the project with a lot of Back & Forth, that’s Lean Startup.
- The mobile app was polling at regular intervals on some screens to get near real-time updates. The backend provider and we weren’t able to implement web-sockets within the deadline due to legacy code.
- We used React Native 0.61.X, GraphQL and Firebase as main technologies.
Protagonists are happy with what has been achieved in the given time frame. We have all learned a lot from mistakes and users feedback, this article aims to help people improving their schedule and programming sessions to succeed in such problematic.
We did some great choices but also some mistakes. In the end, we learned a lot and we took those elements as lessons for the future. You should always growth from your experiences.
I worked to pack this into 5 pieces of advice, here are them:
✈️ Leverage remote config and Over The Air Updates to adapt your application once live
One thing you need to know with mobile application: rollout inertia is very, very, veryyyyyy long.
Applications stores validation process
🍎Apple is known to have a strong and reliable app review process for the app store.
It’s a good thing because it filters upstream some garbage apps from the list. The reviews are linear and generally take within 12–48 hours for most apps.
🔍 Google was known for no review processes
Until now the Google play store was the far west. You can find anything including virus shipped apps as the review was nearly in-existent.
Early in summer 2019, Google updated review policies that are now claimed to be stronger and that’s a good thing… At least that’s what I thought at first glance…
The app’s first review on Google play took 4 days to get validated… Well… It’s fast compared to the « one week » they announced…
But I’m not sure why this took so much time because the very first release was a bugged one with the app displaying a blank screen thanks to a bug with React Native Android Loader (SoLoader).
And even with that: We got validated on the Google Play… Hopefully, after the first submission, the next releases are fast on Google play, it’s only a matter of a couple of minutes.
💡Advice: Anticipate deployments on apps stores and always check your Android App Bundle using Internal App Sharing first as it might differ from standard tests.
You cannot rely on user updates.
You cannot guarantee that your users will update their app within the event, but you can be sure they will leave a bad review on the store 😿.
In case you are not able to patch quickly, think of ways to invite them to update. Push notifications are nice tools to help with that, but as they are on 4G or maybe less, don’t count too much on it.
Remote config and OTA to the rescue
If I had to do that again, I would definitely add both, directly at the beginning of the project. They are now, by the way, part of all my project scaffolding templates.
- Firebase RC gives you the flexibility to adapt your configuration remotely depending on variables such as analytics, user/app metrics or even randomness/timing. You can change remotely features depending on people.
- Codepush in its concern allows you to release new updates that do not change the global behavior of the application. It’s perfect for patching and hot-fixing.
💡Advice: Using Codepush and Remote config you can handle any edge case that hasn’t been caught in pre-production.
🇩🇪 🇫🇷 🇪🇸 Manage translations remotely with a local caching fallback strategy
It’s easy for the customer to forget something or to change its mind during the event.
Oh, people say at the event that this section name is not clear, can we update it?
There is only two way to help him with that case:
- Or better, you’re managing your translations remotely using a custom service or external provider such as Localizejs.
💡Advice: This is a pretty common request. Manage your translations remotely and try to never delete but add a new one to maintain backward compatibility for old versions.
🛡Defensive programming is awesome for embedded systems
While working on that project, as I told you above we had many protagonists, some with cutting-edge technologies, some with fewer commons.
We were only doing the front mobile application and were consuming a GraphQL API which was playing the data aggregator role.
Guys at backend were really skilled but they had not enough data given the time frame to ensure that the delivered will respect a given format, we all know that it might change during the event… and you know what? It did.
With that in mind, we applied one pretty common programming style used in embedded systems: 🛡 Defensive Programming.
Let’s take a small definition from Wikipedia:
Whoa…! It looks like it fit perfectly our use case.
So briefly, we highly relied on Lodash
_.get method to access our variable plus we made a deal with the backend thanks to GraphQL schema types. We also used React error boundaries, retry buttons, GraphQL content caching.
That way, we could have ensured to get the most stable data as we could to prevent crashing and bad user experience.
💡Advice: Never, never, ever trust the incoming remote data especially the one that is not coming from your servers on which you have a hand on. Try as most edge cases as you can upstream with your QA engineers.
📊Do not forget to collect data and metrics to improve later
Your main goal as an application owner/creator is to ensure user retention on your app. It’s easier to trigger a conversion on someone that is already a user than getting new users.
There are three spearhead information you cannot release without to achieve that goal:
- The first one is just the user journey/behavior tracking through your app. What screen has been viewed, when, in which order. Which events have been triggered. Is that feature correctly used and understand by the users? For that, we used Firebase Analytics along with Google BigQuery.
- The second is the crashes/performance monitoring: for that, we used Crashlytics and Performance Monitoring from Firebase which are great tools.
- The last is the feedback collecting: For that, we relied on on-site user feedback collecting using surveys. Also with the store comments sections and emails.
All those metrics will drive your customer’s strategy in terms of content delivery and many other things. They will also help you catch any pitfall that makes the app crash, where it fails and what code to improve.
💡Advice: Design your app for end-users, always collect feedback for and from them. That way they will feel concerned about your product and they will trust you which results in higher retention.
✅ Code review using small features, don’t get a big team
On that project, in terms of pure mobile development without counting side profiles such as project manager or designer, we were a team of 3 developers.
As a Tech Lead, I love small teams of less than 5 developers
By having a small team working on a specific thing you can allow enough time to review merge requests correctly by testing each integration and giving feedback.
It’s also easier to have a global vision on what is doing each people in the team and also bring assistance if required.
People are not conflicting in terms of functionalities or at least less.
Also on such small delivery times, reduce the number of meetings and rituals and prefer direct communication, before feature handling and before merging to be sure everything is correctly aligned.
💡Advice: Keep the team small, take time on merge requests to check that everything is relevant and functional, share feedback between team members and deliver small chunks of features.
This might look very dumb but this is probably the most important advice I can give you.
Even if the stakes are big, even if the deadline is close or if your boss is pushing you for results: do not forget to sleep and relax your mind by doing something else.
Otherwise, by doing such, you’re heading straight to the burnout.
And if you get burned out, everybody loses its interest.
You’ll probably need to work a bit more, It’s okay you do overtime hours and earn more money, but mental health is the most important thing you need to keep. Try to find a balance that fits your situation.
There is no point in being the richest man of the graveyard.