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.

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.