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:
- Remotely control their vehicle (e.g., turn on/off AC, increase/decrease seat heating, lock/unlock doors) 🔓
- View vehicle information and statistics (e.g., fuel/energy consumption, distance travelled, oil level) 📈
- Plan a trip to a place/POI 🗺️
- Interact with other customers in a private social media 🫂
- Get notified for vehicle events (e.g., when the vehicle requires a new service, points earned for completing a trip) 🔔
and much more.
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
- * User Avatar
- * Account Information Synchronization
- * Vehicle Login
- * My BMW Alexa Skill Integration
- * Deep linking
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:
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.
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.
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:
Technology | Reason |
---|---|
Flutter | Mobile app development |
Kotlin | Native Android plugins development |
Swift | Native iOS plugins development |
Countly | App analytics |
Nest.js | Microservices development |
Docker | Microservices bundling |
Kubernetes | Microservices orchestration |
Terraform | Infrastructure configuration |
Prometheus | Logging handling |
Grafana | Monitoring visualization |
Jenkins | Continuous Integration & Testing |
GitHub Actions | Continuous Integration & Testing |
#projects #mybmw #bmw #critical techworks #flutter #android #iOS #countly #nest.js