Article by Andrew Thompson, VP Engineering at Yoyo Wallet
- We built the Caffè Nero App on top of the existing Yoyo platform
- We achieved #1 in the Food & Beverage category on launch day ahead of Starbucks and UberEats
- We have the highest rated app in its category (mostly 5 star reviews)
- We modified our architecture and built a fully automated CI/CD system for rapid, regular releases
On April 10th, 2017 my team and I at Yoyo Wallet launched the Caffè Nero App across the UK and Ireland enabling a digital payment and loyalty experience for millions of Caffè Nero's customers.
The product engineering team at Yoyo Wallet (consisting of Android, iOS and backend engineers along with product mangers and designers) were responsible for designing, building and shipping the Caffè Nero App for the April deadline, whilst still continuing to improve and maintain the Yoyo Wallet App which is live across the UK and Europe at many Universities (e.g. Imperial, Oxford Brookes, York), Corporates (e.g. JP Morgan, Guardian, Accenture) and high street stores (e.g. Planet Organic, independent coffee shops).
Nero kicked off a number of marketing campaigns after the release of the app to raise its profile, including posters and collateral in-store (see above) and email campaigns.
On launch day and the days since we've seen a surge in registrations for the app which resulted in the app obtaining the top ranked spot in the Apple App Store for the Free Food & Drink category (out ranking other apps such as Starbucks, Costa, UberEats, Nando's and Just Eat to name a few). Off the back of customers downloading, registering and using with the app to pay and collect stamps, we've received mostly 5 star reviews making us the top reviewed app in the category (As of April 27th we've received a total of 395 iOS and 416 Android reviews with ratings of 5.0 and 4.7 respectively). Along with positive user rankings, we've also maintained a very high quality threshold shown by our crash-free session rates which are at 99.97% and 99.94% for the latest versions of the iOS and Android apps respectively (measured via Fabric's SDK).
We've abstracted away much of the complexity of the app behind a simple UI/UX that customers engage with and rate highly. Behind this simple UI/UX the app has the following features:
- Multi-mode registration (Email, Facebook or Yoyo login)
- Camera based credit card scanning to more easily gather card details (A/B testing proved the uplift in conversion)
- Secure payment and loyalty in a single scan of the app OR loyalty-only so customers can also pay with their own cash/card
- Rule-based loyalty that triggers in real-time based on each items in a customer's basket and notifies them via silent push notifications of their loyalty reward(s)
- An activity feed that aggregates receipts and loyalty reward information
- Store locator for finding the closest store
- Apple and Android Wallet integration for loyalty-only transactions
- Settings: account management, support and promo codes
Given that Yoyo is powering the Caffè Nero app, as an engineering team we were very conscious of leveraging both our existing mobile and backend platform architecture in the right way to minimise code/feature duplication across 2 (and eventually more) mobile frontends. Both sets of mobile apps call the same Yoyo API endpoints running on Amazon Web Services (AWS) and much of the mobile code base, for both iOS and Android, is re-used inside our own internal SDK as well as the core business logic of the app which we call "App Core". Only the UI of the mobile apps (which is visually different) and a small bit of custom business logic are unique to each app and therefore cannot be re-used:
At Yoyo we ship new versions of ALL our mobile apps to their respective app stores every week without fail on Tuesdays at 3pm for iOS and Tuesdays and Thursdays at 3pm for Android (we follow a release train process). This requires building, packaging and deploying a total of 6 .ipa and .apk binaries across our internal test, staging and production environments along with our 3 testing channels (alpha, beta and live). To manage this complexity effectively we've automated the entire build, package and deployment process for multiple apps by using our own custom mobile CI/CD pipeline built on Bitrise, Fabric, Testflight and our own scripts.
Here is an example of what our mobile CI/CD pipeline does each day multiple times:
- An iOS engineer fixes a bug in the SDK and merges his/her change to master
- Bitrise immediately kicks off a new CI build cycle for both the Yoyo Wallet and Caffè Nero versions of the iOS app
- Once complete both iOS .ipa binaries are pushed out via Fabric to all alpha testers
- The next time all alpha testers open their Yoyo Wallet or Caffè Nero app on their iPhones (most internal Yoyo staff are alpha testers except the sales team) they will be asked to download the latest build
- Once downloaded, alpha testers will be using the latest and greatest version of the app and are more easily able to identify bugs or usability issues
This new, fully automated, CI/CD pipeline was implemented late in 2016 and has dramatically increased our mobile team's ability to rapidly release new versions of the mobile app to our users. The chart below shows this increase over time as we've improved our ability to ship to production using automation:
It's worth mentioning that we also use a company called Applause for crowdsourced continuous testing of our mobile apps. The service that Applause provides is incredibly helpful and cost-effective in terms of finding many usability issues and bugs across the plethora of Android devices and configurations that are available in the marketplace today. However we do not use their crowdsourced continuous testing service as a quality assurance gatekeeper for pending production app deployments (there is a very specific reason for why we do not use them in this way which I will explain further).
Whenever there is a human gatekeeper of quality, I find that developers and their teams often rely on that person or set of people as the main quality assurance mechanism instead of themselves (they are less thorough with their code changes and code reviews and often write fewer automated tests). They effectively offload the burden of responsibility for quality assurance to someone else for the change(s) they are making. This is orthogonal to the idea that each developer is the best person to know what could be most affected by their changes and should therefore assure the quality themselves. At Yoyo we wanted to keep quality high by using Applause but did not want the service to become a crutch for developers to rely on. Therefore we only use Applause in parallel with existing deployments to production. Applause testing never stops any deployment, it merely identifies existing issues and bugs that need to be fixed post deployment and does a very good job at this task.
- Watch out for trademark checks: One unexpected thing to happen in the 11th hour was when we submitted the Android app to Google Play and it was rejected. We had completed and submitted the iOS app a week earlier because we knew the review process was more stringent and always took longer with Apple. We weren't worrying about our submission to Google Play as it was always seamless due to less checks and balances (or so we thought). This was not what happened in our case, Google flagged the fact that a 3rd party developer (i.e. us as in Yoyo Wallet) were submitting an app with someone else's trademarked branding and so the app was rejected. We had to scramble in the 11th hour over a weekend to get documents signed by Caffè Nero to assure Google that we, as a 3rd party developer, had the right to submit an app that contained Caffè Nero branding. This did delay our Android submission by a few days but luckily we still had enough head room for it to ship on-time.
- Public wifi with logins can cause headaches: A phone's OS will automatically connect to a public wifi that it has previously connected to when it's within range but the user usually still has to accept the terms and/or re-login to gain full internet connectivity. If the latter does not occur then the user usually assumes they have internet connectivity when the app is open due to the wifi symbol displaying on their phone when in fact they do not have internet connectivity. There are a few ways to solve this by either (1) if the public wifi is within your control make sure certain outbound connections (via IP or domain) are given access even without the need to accept the terms or re-login to the public wifi OR (2) the app displays a "no internet connectivity" warning message so users expect limited functionality until they have fully connected to the internet.
- Improving mobile architecture and deployment infrastructure upfront was worth it: Given that we had the Yoyo Wallet app and were effectively white labelling it (modifying the UI for Caffè Nero as well as adding some new features), we wanted to approach this intelligently to minimise long-term technical debt. We knew that white labelling Yoyo Wallet could get rather messy quite quickly with multiple sets of apps being created and maintained long-term. Yoyo's mobile team spent time upfront to improve the mobile architecture on both iOS and Android to separate out the App SDK and App Core dependency layers which could be re-used across apps while the UI layer could be modified heavily. We also focused on improving the deployment infrastructure using Bitrise CI and compile time configuration flags within the app so that we could automatically build the different UI versions of the app with the reusable App SDK and App Core dependencies. Although this deployment infrastructure took time upfront to build and configure correctly, it reaped large dividends later in the project as the deadline loomed (it continues to reap ongoing benefits every day with each new commit). Mobile engineers now barely need to think about the Yoyo Wallet or Caffè Nero app deployments, we focus on improving the UI or business logic of the app and the deployments continue to happen automatically each day and in exactly the same way since the start of the Caffè Nero app project.
The entire team at Yoyo Wallet have done an incredible job building Caffè Nero's mobile app on time for the April 10th launch. Not only did they meet the deadline but have built an app that is available to millions of Caffè Nero customers. Many of these customers already love the product based on their ratings and are actively asking for more functionality to be added in near the future which is exactly the kind of response a product engineering team hopes for when releasing a major new product into the market.