João Freitas

The direct connection from your vehicle to your world.

The MyBMW App is a mobile app that enables BMW/MINI customers to feel more connected to their vehicles, even if they are remotely distant. Depending on the region/market the customer is present and the features subscribed to, customers can:

and much more.

screenshots of an older my bmw app

Overview of an old app version

My role on the project was to integrate and maintain personalization and experience features in the app, which is developed in Flutter. Our team worked on features such as the

We worked as feature teams and features were distributed based on the domain area each department focused on. In our case, it was the personalization department.

The user avatar and vehicle login were our best-selling points. When customers interacted for the first time with the app, they always felt the need to personalize their profile. Here’s a video of the avatar + vehicle login features in action:

video thumbnail

These features were implemented in a reactive approach, by extensively applying the BLoC pattern using the bloc library. We consumed data from micro-services that execute business logic on top of other legacy BMW services. Then, we transformed this data into micro UI elements styled in a UI library that follows BMW UI guidelines.

a sequence diagram describing the communication between each layer of the mobile app

From a high-level point of view, the app architecture lays down to four layers

The BMW tech stack is extensive, but for the microservices we worked on, we used nest.js (targeting Node runtime). These services are orchestrated through infrastructure central gateways, which are built and automated using Docker, Kubernetes and Terraform. Monitoring, logging and observability in general was achieved using tools like Grafana, Prometheus and Countly.

Communication was one of the major pain points I felt while working on the project. More than 300 people work on the project, from multiple BMW tech hubs/contractors all over the world. Time zone synchronization was a big issue in communicating with American and Chinese colleagues, and getting short feedback loops right was nearly impossible.

We used agile management tools that assisted us with communication, such as JIRA, Confluence, GitHub Wiki and Microsoft Teams. However, neither of them was able to solve the miss-alignment of time zones.

hell version of jenkins logo

Jenkins every day and night

Another significant pain point everyone suffered was our CI environment. We mostly used Jenkins (and a bit of GitHub Actions), and I think the ol’ man never endured that much load. At any point of the day, hundreds of builds were being executed in parallel, leading to simple pull requests taking around 40 to 50 minutes to build. When we had outages, machines were vertically scaled by adding more resources to BMW data centers. Personally, I don’t think this is the right solution since that’s just buying more time to fix the problem itself.

Here’s a list of technologies I worked/had the opportunity to tinker with:

FlutterMobile app development
KotlinNative Android plugins development
SwiftNative iOS plugins development
CountlyApp analytics
Nest.jsMicroservices development
DockerMicroservices bundling
KubernetesMicroservices orchestration
TerraformInfrastructure configuration
PrometheusLogging handling
GrafanaMonitoring visualization
JenkinsContinuous Integration & Testing
GitHub ActionsContinuous Integration & Testing

#projects #mybmw #bmw #critical techworks #flutter #android #iOS #countly #nest.js