Corporate cross-platform mobile app

Itransition used Flutter to develop a cross-platform app that streamlines corporate discounts provision and digitizes event registration. 80% of employees have downloaded the app, 95% of users are satisfied with it, and 20% more employees are using discounts.

Home
Portfolio
Corporate cross-platform mobile app

Context

Itransition is a geographically distributed company of 3,000+ employees in 10+ countries with a complex internal structure and multiple media web apps and social media platforms containing information on work and recreational activities like employee certifications, qualifications, events, and corporate discounts.

Over the years, Itransition has partnered with many companies to offer discounts on education, eating out, travel, fitness, entertainment, and other services. The 200+ discounts were listed on corporate social media and in our wiki, but it was difficult for users to track their relevance. We also had many recurring events attended by 1,000+ people in one location simultaneously. Therefore, we wanted to organize easy ticket dissemination and employee identification at the event, as well as automate and digitize discounts provision.

Itransition team developed an Android app to test the concept and then added an iOS version to cover the whole user base. The feedback we received from 85% of users was to develop a single app that would unite all the functionality of the apps in one solution. The goal of the app was to make business processes more effective and improve user experience by providing seamless updates on the go.

Solution

We created a cross-platform Flutter app to centralize all content on discounts and offers, serve as a ticket system during events, and mirror our corporate web apps with information on salaries, vacations, employee profiles, benefits, and corporate merchandise.

Itransition App is available for download and access by company employees. We've also developed an admin panel for supporting the app and providing access to app users. The admin panel users are admins with access rights to modules and super admins who give out access rights to regular admins. The business owner of the app is the PR department that pitches new features and modules to the development team.

The first developed modules are the events and discounts modules, with plans to add the employee profile, benefits, vacation, salary, and merch modules in the future. The existing and planned modules contain data from corporate web systems such as the employee portal, benefits wiki, and discounts social media page.

The events module allows users to track corporate events, register for them, scan the personal QR code at the event for employee verification, check location information, look up the location on the map, check the event shuttle schedule for commute, and so on.

The discounts module contains information on the partnerships and discounts in the following categories: auto, children, food delivery, health, eating out, shopping, education, entertainment, beauty, sports, building supplies, and tourism. The home page contains a favorites tab, the digital version of the Itransition discount card, and filters. Users can set the view of their discounts by category, alphabetic order, or on the map.

Analytics

The project team uses app analytics to gather feedback and develop the most necessary new modules, plan strategic app development, choose the most requested features for each module, and improve the overall user experience. To track metrics, we selected Google Analytics for its rich functionality in building graphics for intuitive analytics.

Besides Google Analytics metrics like user number, age demographics, geolocation, and operating systems, we collect complex metrics to track the app’s popularity and relevance, speed up processes, and save resources and costs on event organization and discounts. We also use metrics to perfect the app and make development decisions that predict arising user needs.

App usage metrics	Business insights
Active daily/weekly/monthly users	App relevance and helpfulness
Session depth Average session time Average number of screens per session	App simplicity and ease of use User engagement and stickiness
User paths Path patterns Time on page	Navigation ease of use
User retention Events per session	App relevance and popularity
Event demographics Event location	User demographics of corporate events
Devices, OS, and versions	Future development priorities correction

To plan future development, meet user needs, and correct our priorities, we pay attention to metrics like the most popular app features, features added to Favorites, churn rate, and user retention rate. We also track the acceleration of processes, such as time saved on event registration. With the company growing worldwide, we track the used languages to prioritize localization efforts.

Besides business metrics, we collect technical ones such as the number of crash-free users to assess app performance and crash issues, find crash causes, and provide fixes and workarounds.

Some of the metric calculations had to be customized by the business analytics team. To calculate the churn rate, we devised a workaround using GA API and local storage. The system displays the churn rate for the following periods: day, week, month, and year. We also had to calculate the metrics for user retention by time period. The system compares the number of active users at the beginning and the end of a given period and calculates the retention rate using the formula: ‘active users’ / ’day 1 users’ x 100.

Technologies & tools

Itransition's team developed a Flutter frontend featuring a Dart backend. We chose Flutter since it’s best for business apps not featuring resource-intensive operations, such as AR/VR. We also discovered the following Flutter advantages:

A single code base for frontend web development, allowing us to support frontend development for web app development which we can add to the future Itransition app suite of mobile and web apps.
Ability to use Dart for both frontend and backend development, allowing us to cover the whole project (the frontend/backend client and the admin client) with only one team.
Fast-growing technology with constantly emerging improvements and libraries, allowing us to add new features to the app and realize new ideas fast.
Native look and feel even on older versions of Android and iOS, enabling us to give all our users the same seamless experience.
118,000 of documentation on pub.dev, with constant knowledge base updates available to us to grow our skill pool.
An ecosystem of 2,000 ready-to-use packages that can be used out of the box.

Besides Dart, we use native code for push notifications, following Apple and Google requirements.

Since the backend of the previous apps was written in Firebase, we used Firebase libraries on Dart to communicate with backend sources and download discounts from stores. For localization, we used standard Flutter localization. For some non-Firebase requests, we utilized Dio, an HTTP client for Dart that supports Interceptors, Global configuration, FormData, Request Cancellation, File downloading, and Timeout, which allows us to perform all those actions without having to write a separate manager and saves us time and money. To store data locally in the database, we use the SQFlite library.

We chose an architecture with low connectivity as we plan to add more modules for scaling up the app. The selected architecture allows us to effortlessly connect or disconnect modules depending on the region and set up customizations based on the data loaded to the database. We used GetIt as a Service Locator. We also ensured that each layer is independent from each other, which makes the development, adding new modules, and scaling up the app easier and faster.

The team used Flutter best practices for the development process. We set up CI on the project for automation and minimizing manual effort. The team performed static analysis of Dart code using Dart Analyzer. We also run unit and integration tests. After these steps were successful and we received approval, we proceeded to merge. The app beta testing was performed by Itransition’s specialists with minor bugs discovered and fixed, after which the app went into production. The lack of major bugs was guaranteed by test automation and high-quality testing during development.

For authorization, we used Microsoft Authentication Library (MSAL) which turned out to be a challenge, particularly when introducing the support of null safety, during which all libraries had to be moved to be supported by it. In the first three months of the update, the move did not happen fully, with MSAL failing to be moved entirely. It resulted in the FirebaseAuth library conflicting with MSAL. Itransition’s team solved this challenge by setting up libraries, setting up which libraries should MSAL use, and preventatively solving conflicts.

Security

Only our corporate employees can log into the app under an MSAL account, which has its own security measures. All data is only accessed via Microsoft Graph, a secure gateway to data and intelligence.

To provide maximum security of applications and code, we implemented obfuscation (for Android), secure key storage, and additional device checks (specific for iOS and Android). Obfuscation allows us to “confuse” and “replace” the code to make it difficult to reuse during decompilation. Since iOS features default protection, we used this security method for Android, implementing it using Flutter ARB (Application Resource Bundle) files instead of APK files.

For key storage, we utilized a built-in secure key storage system for iOS (Keychain) and for Android (Keystore) via the Flutter_secure_storage implementation method. The key is available only to the application, but not to the user.

Other security checks included checking the device for root/jailbreak using the trust_fall package. The team checked whether the device is JailBroken (rooted) on iOS/Android, is real or an emulator, or can mock its location. For Android, we also checked whether the application is running on external storage.

To provide Flutter-specific security measures to protect personal user data against application file decompiling, MITM attacks, and device rooting, we followed the recommendations below in the native parts of the application:

Use only secure local storage depending on the platform
Do not store critical user data in code
Do not use "self-written" algorithms
Do not transmit critical user data openly
Do not store critical user data locally

The team also paid special attention to the security level of the libraries in use, as well as data storage. So, we checked libraries for obfuscation possibilities, made sure traffic didn't go through them, and ensured safe data storage inside them. For data storage we used Flutter Secure Storage which provides an API to store data in a secure way, transforming into Keychain (iOS) and EngryptedSharedPreference (Android) on the native code level.