COVID tracker

Virus tracking mobile app

What’s the most powerful way to stop a pandemic? Limit the number of people getting infected. In case of COVID-19, this meant limiting the contact people have with each other. COVID tracker helps with exactly that.


infection prevention on a mass scale

COVID tracker helps its users in identifying which places to avoid (crowded squares, malls, public transport, etc.) Even more than that, it sends a notification to users about potentially being infected. By creating a database of routes infected people took in the two weeks prior to them being diagnosed (the official dormancy period for the virus), others can stay safe. Once someone is infected, they upload their anonymised routes and it shows up for every other user on a heatmap and a notification is sent to anyone with whom they crossed paths in the past 14 days. In the future, parts or the whole of the application can be reused e.g. tracking, manually pinning locations etc.


efficient tracking and proximity detection

No registration

We wanted to create an application that could be used without registration by using a generated token so more people would adopt the solution. This also helps protect anonymity.

Displaying infection data

One of our goals was to enable our users to avoid potentially dangerous places. These locations are determined by the anonymously collected location data of infected people who opted to share them, specifically their data from two weeks before the diagnosis up until the time of diagnosis. This dataset is then turned into a heatmap on top of a regular map.

Continuous tracking

In order to continuously track a user’s location we had to implement mobile platform specific solutions that could run in the background without draining the battery while providing us accurate enough results with a given periodicity. We save this data locally, and it can also be displayed on the aforementioned map.

Manual track editing

To fill in the gaps and clean up the errors of automatic tracking, we wanted to allow users to edit their tracking data right from the application, which required a set of interfaces for these operations that were user-friendly.

These operations would be adding new points and deleting existing ones. The add functionality is supported by a search option for finding places to add by name instead of manual coordinate selection.

Infection reporting

An essential functionality was the ability for the users to report if they were and when they were infected, and optional, possibly relevant information like their age. They can upload their two weeks worth of tracking data preceding the given time of diagnosis to our servers, which then provides the anonymised data alongside all uploaded tracks to the application for generating the heatmap.The application also shows medical instructions for the infected person in an effort to minimise further infection.

Detecting potential infections

A periodically running algorithm detects if the user had been near an infected person or area by comparing the user’s last two-week tracking data to the aggregated infection reports.

Push notifications

We plan to later add notifications of related news sent from our servers alongside warnings if the user is near potentially dangerous locations, so we prepared our backend to handle different mobile platforms uniformly from the server side.


an iterative process

Our solution consists of multiple components. We started developing a mobile application and a backend in parallel, both in an iterative manner, taking up around 3 weeks of total development.

The iOS version of the mobile application was selected to be implemented first to serve as a basis for prototyping, getting feedback and collecting test data.

The anonymous identification of the app’s users is based on Google’s Firebase Cloud Messaging. It generates a token on first launch, which is then sent to our servers in exchange for a JWT for authentication. The FCM token is destroyed upon deletion of the app’s data.

We integrated multiple features of Google Maps Platform, since it is platform agnostic and free to use for our use-cases. We use this to show an interactive world map to the user and an additional utility library that accompanies the base GMP library allows us to display a customizable heatmap. We found this combination to be of high-quality and easy to integrate.

Testing is in progress, and distribution is through Apple’s TestFlight service. The Android version is soon to be implemented heavily relying on the design decisions made during the creation of its iOS counterpart, given that it reaches a certain maturity level. We decided to target iOS 12 and above and Android 4.4 and above, since they cover 93% and 96,2% of their current market shares, respectively.

The backend is a Spring application with a REST API and the responsibility of handling authentication, infection report aggregation and querying. Messages to the server are in JSON format, and persisted in MongoDB for simplicity. 

The backend is responsible for generating and storing the JWT of the user in exchange for a FCM token. It’s also responsible for storing the uploaded user location data, and making the anonymised data accessible to the other users.

Another one of its capabilities is sending push notifications remotely to iOS and Android users using the acquired FCM tokens. Lastly, a news feed which is to be displayed in the app in the near future will also be powered by the backend.

An admin interface and a website are also among our near-future plans.

technology stack

backend and iOS mobile app






#Open API



complex architecture

the result

MVP version for iOS that is a good base for iteration



duration (week)