Tech Radar Transverse

At Theodo, we use a lean approach with continuous deployments and chunked tasks that can be completed in a day, avoiding batch effects. Trunk-based development, where developers frequently merge their changes into the main branch, is at the heart of our process, but remains difficult to apply in the mobile space due to store validation cycles.

Feature toggles are essential for efficient workflow and finegrained control of applications in production. There are several types of feature toggles, including authorization toggles and A/B test toggles, which have a specific business purpose. Release toggles and operational toggles facilitate lean development practices.

Release toggles, which are built directly into code, allow features under construction to be merged without being activated for end users. This facilitates continuous integration and limits the number of branches and environments required for development. Operational toggles, which can be configured remotely and retrieved at runtime, allow a problematic or obsolete feature to be quickly disabled without requiring a new deployment. This increased flexibility is critical for responding quickly to production incidents and maintaining application stability.

Feature toggles add complexity to code, especially when they are interdependent, multiplying possible test scenarios. To prevent this from becoming unmanageable, it's important to follow certain best practices:

• To avoid the interdependence of toggles, it is advisable not to associate several toggles with the same functionality. In addition, it is essential to unit-test the different paths that toggled code can take, to ensure that every possible combination works correctly. During deployment, it's also a good idea not to change the state of too many toggles at the same time, to limit the risk of conflicts and regressions.

• To ensure efficient continuous integration, it's a good idea to change a release toggle to an operational toggle when a feature is ready to be deployed. This maintains the toggle's functional continuity, facilitating tests, updates and deployments without major disruption.

• Documenting toggles is essential for longterm maintenance. The lifespan of toggles can vary from a few weeks to several years, and without proper documentation it can be difficult for developers to understand their use and condition.

• Knowing the status of toggles in production is also critical. To this end, it is important to version release toggles to ensure deterministic application builds. An interactive operational toggle console, such as Firebase Remote Config, can be used to monitor and modify toggle status in real time.

• Finally, choosing an appropriate update frequency on the application side for dynamic toggles helps maintain the ability to respond quickly in the event of an incident.

How do you know if your application is performing well? This is a complex question, not least because of the multiplicity of metrics (FPS, TTI, RAM...) and the non-determinism of measurements.

Flashlight, which we are developing, aims to be the answer to this question for Android. Flashlight gives your app a real-time performance score, without any preconfiguration in the app. So, unlike most existing tools, even production apps are supported, regardless of their technology.

To go one step further, Flashlight can run your e2e tests multiple times, aggregating different metrics and averaging the results into a report with an assigned score. Advantages over other tools: this score provides an easy-to-understand overview of performance, and the comparison view lets you assess the impact of a change in the application. At its core, Flashlight is open source. That means you can take measurements locally with your own device, but there's also a cloud version that runs on a real Android device and can be integrated with a CI to get a score on a regular basis. However, you'll have to provide it with your own E2E tests (only Maestro is supported), which can be tedious.

We use Flashlight as an indicator in performance improvement tasks, which has allowed us to improve the scrolling fluidity of a React Native app or reduce the startup time of a Flutter app.

Flashlight has also allowed us to avoid performance regressions in our projects, for example by detecting abnormal CPU consumption after installing an SDK.

Finally, Flashlight is used in conjunction with Meta to monitor the performance of the React Native framework.

Writing a REST API client by hand is a time-consuming task that adds little value to users. This time, which is not spent on more creative or useful pursuits, is often a source of frustration for developers. What's more, the repetitive nature of this task can lead to distractions and errors in translating API specifications into working code.

Tools such as OpenAPI Generator* help solve these problems. This approach automatically generates client code from API specifications without any manual intervention.

This practice has a few limitations:

• Generation tools don't always support the entire OpenAPI specification, as in the case of oneOf/allOf when generating Dart clients.
• The generated code may be incorrect or incomplete, particularly when the generator is confronted with specifications that are partial or out of phase with the actual implementation of the specified API.

However, this latter limitation actually paves the way for better collaboration and understanding between development teams. Knowing that their specifications will be used to automatically generate client code, back-end developers are encouraged to adhere strictly to OpenAPI standards and provide clear, concise specifications. This improves the quality of generated code, documentation, and API maintainability, and fosters a culture of collaboration and quality within teams.

Designers are increasingly incorporating animation into their interfaces to enhance the perceived quality of a product and evoke emotion in users.

However, creating animations with code is challenging for mobile developers due to the complexity of synchronizing multiple elements and managing a large amount of code. The variety of platforms and frameworks also makes it difficult to create consistent, reusable animations.

Another approach is to integrate animated assets, but most existing solutions don't allow direct code interaction with animations, making it impossible (or very difficult) to respond to user interactions and changes in application state. Rive is a solution that responds to these needs by providing a detailed understanding of the production process for digital interfaces, by proposing a unified production pipeline between designers and developers.

• On the design side, Rive eliminates the need to use multiple tools such as Illustrator or After Effect. The editor allows you to design and animate within the same interface and facilitates the transfer of assets.
• On the technical side, Rive reduces the number of roundtrips with designers, eliminates the problem of corrupted files and simplifies the integration of interactive animations with integrated state machines. Rive makes collaboration between designers and developers smoother, reduces errors and speeds up the production process.

Animations created with Rive can respond to clicks, movement, or state changes based on the data they receive, providing a dynamic and immersive user experience. Rive optimizes its files to be up to 10 times lighter than Lottie files. What's more, it limits the impact on the codebase by integrating the state machine directly into the file.

The Rive tool positions itself as a strong competitor to other animation creation solutions thanks to its better performance and more developed APIs. Because the rendering engine and players are open source, they offer greater flexibility and adaptability to meet specific project needs.

We're always looking for tools that simplify backend development while providing robust functionality. Supabase caught our eye as an open-source backendas-a-service (BaaS) platform that simplifies the integration of complex authentication systems and the management of backend infrastructure.

Supabase stands out for its use of PostgreSQL, which provides flexibility for complex queries and data management. Its authentication system is highly configurable, supporting email/passwords, magic links, and third-party providers. The quality of its SDKs ensures smooth development on multiple platforms, and its integration with frontend frameworks improves developer accessibility.

Supabase makes it possible to write serverless edge functions and fine-tune security management with Denobased RLS. This improves performance, security and scalability, making it ideal for the needs of modern applications. Supabase's self-hosting capabilities potentially offer total control over data and infrastructure, addressing the need for confidentiality and customization.

Given these strengths, we place Supabase in the Adopt category. Its robust functionality, ease of use, and open-source nature make it an excellent choice for developers. In addition to simplifying back-end development, Supabase offers advanced features that are essential for largescale applications.

The challenge of ensuring the consistency of a mobile application's user interface is a headache for all developers. This difficulty is compounded by the variety of devices (phones, tablets, TVs, ...), orientations, and screen sizes, making manual regression testing nearly impossible. Snapshotting UI provides a modern solution to these challenges.

UI Snapshotting captures snapshots of your application's UI in various states and stores them in your codebase. When a change is made, these snapshots are compared to the current UI to detect any unintentional changes.

We have used Snapshotting UI on several platforms, each with a different level of maturity:

• Flutter: The most advanced, offering integrated snapshot testing with Flutter Goldens. This does not require emulators, making testing extremely fast.
• Native Android: We use the Paparazzi library, which captures UI snapshots and tests regressions without using emulators.
• Native iOS: Although the swift-snapshot-testing library relies on simulators, it's fast enough to have minimal impact on our CI.
• React Native: This platform lacks a mature solution. UI snapshot testing requires additional configuration and generally relies on end-to-end testing on emulators in conjunction with jest-imagesnapshot.

A major challenge we've encountered is the inconsistency of snapshots between different CPU architectures, simulators, and operating systems, which can lead to inconsistencies in the CI environment. To mitigate this, we can reduce the precision of the configuration to get consistent snapshots on the CI.

‍

In the book Dantotsu Radical Quality, Sadao Nomura suggests classifying defects according to their stage of detection rather than their severity or urgency. We expanded on his ideas in The Lean Tech Manifesto, suggesting five stages of defect detection:

A - Detected before release by the developer

B - Detected before reaching an internal customer (code reviews and continuous integration)

C - Detected before release (functional reviews)

D - Detected after release but before receiving a complaint (continuous deployment and monitoring)

E - Detected by a user

This approach contrasts sharply with current industry practice, where defects are ranked by severity and only the most critical are handled and analyzed. Early detection and discussion of bugs has several advantages:

• Bugs caught early are fresh in the minds of those who introduced them, making it easier for them to explain their misunderstandings and learn from their mistakes.
• We avoid situations where the person who introduced the bug has already left, preventing any learning
• Even minor bugs are often associated with misunderstandings that can lead to more serious problems. Addressing the causes of small bugs improves the overall stability of the application.

At Theodo, we have gradually expanded our analysis from D and E bugs to include earlier detection stages. We have also focused on reducing the total number of late discovered bugs (D and E) to detect them earlier. We believe that an increase in early-stage detections is positive if it helps reduce the number of late-stage detections. This has several advantages:

• The team addresses obstacles earlier in the project, improving overall productivity.
• We reduce the cost of fixing defects.
• The team generates knowledge faster.
• The quality of the final product is improved.

Performing E2E testing for mobile applications, especially for React Native and Flutter, is tedious. Appium (and Detox) have their strengths, but they are often complex to use, not very intuitive, and can be difficult to automate in CI/CD.

Maestro is a new, highly effective mobile UI testing framework. While it's not as comprehensive as Appium, its minimal setup and quick implementation make it an ideal choice for those new to E2E testing. You can run your first test in as little as 15 minutes. Maestro also includes a graphical interface (Maestro Studio) that lets you visually select UI elements and provides suggestions on how to interact with those elements in your tests. What's more, Maestro has its own built-in cloud service called Maestro Cloud.

No need to set up simulators, just upload your application and tests and they take care of the rest (reports, parallel execution, intermittent error prevention, screen recordings, logs, etc.).

‍

In 2024, mobile application security is more of a priority than ever, in the face of constantly evolving threats. With 7 billion subscriptions to mobile networks, and a third of businesses experiencing downtime or data loss due to compromises on mobile devices, it's essential for developers to integrate security right from the design phase of their applications.

OWASP's Mobile Application Security Verification Standard (MASVS), a must have standard for mobile application security, has recently evolved into versions 2.0 and 2.1. MASVS 1.5 consisted of 84 checkpoints divided into 7 categories covering critical areas such as data storage, authentication, and network communications.

MASVS version 2.0 has made significant simplifications, eliminated redundancies and adopted standardized terminology such as OSCAL. The result is a streamlined list of 22 control points that provides a clearer, more concise approach.

One of the major innovations in MASVS 2.0 is the introduction of MAS profiles. These profiles configure security tests according to the specific requirements of the application, considering its level of sensitivity. The associated tests are described in detail in the Testing Guide (MASTG), which provides practical technical advice for validating the 22 security checkpoints.

Version 2.1 adds the MASVS- PRIVACY category to the standard, which is essential to help developers comply with privacy regulations such as the RGPD.

During feature development, code review is critical to ensuring quality and adherence to team standards. However, systematic review can slow developers down.

To avoid this, Rouan Wilsenach suggests an approach called "ship, show, ask". For every change, you have three options:

• Ship: create an advanced branch without proofreading for minor, standardized changes.
• Show: create a branch with a pull-request and merge without waiting for proofreading for changes that are not critical but require proofreading later; also, for changes made in a team (pair or mob programming).
• Ask: create a branch with a pull-request and wait for proof-reading before merging for critical or uncertain changes requiring a colleague's opinion. We talked about this practice last year, and it’s now part of our standards. We have reduced the time spent on code reviews without reducing the quality of the code.

Like code review, pair/ mob programming, ship/show/ask is a means of communication between a manager and an employee. It's up to the Tech Lead to use this method wisely to ensure code consistency, developer progress, and the team's ability to deliver features quickly. It's the Tech Lead's responsibility to define rules to improve quality.

Managing a growing technical team can be challenging. As it grows, with multiple projects, different technologies, and different contexts, it becomes difficult to ensure that everyone is focused on what's most important, and even more difficult to ensure cross-team collaboration and knowledge sharing. Each engineering manager works hard with his or her team, while others face the same problems on the other side of the open space.

The Weekly Engineering Review is a ritual that brings together all the company's engineering managers and staff engineers. The principle is strongly inspired by Amazon's Weekly Business Review. The goal is to ensure strong alignment of all technical leaders around common performance metrics and to foster knowledge sharing and collaboration across teams. The meeting is structured around a set of KPIs that aggregate the performance of all technical teams in different areas: delivery, quality, team health... The KPIs are contextual, so they can and should evolve over time to reflect current challenges and align with the company's business interests. The weekly aspect allows each technical leader to maintain a strong focus on the goals and helps them align the day-to-day work of their teams with them. A manager is assigned to each KPI to ensure that data is collected, that the KPI is updated each week before the meeting, and to comment on deviations. Finally, the WER is structured by a facilitator who ensures that each KPI is prepared and that the meeting runs smoothly. At Theodo Apps, we implemented the WER 6 months ago. We've been tracking KPIs such as the number of unresolved bugs, the cost of each screen developed in our projects, the number of CFPs sent by our engineers to conferences, the number of inter-team learning exchanges, and the number of engineers who attended bootcamps or training courses.

After a few months of WER operation, we have seen a mixed impact. Some KPIs, such as training attendance or the number of defects analyzed by team leaders to better understand the root cause of defects, have increased. Other KPIs, such as the number of CFPs sent, have not changed significantly.

Regardless of its direct impact, the WER is proving to be an effective means of creating a true team of technical leaders who previously worked in silos. Feedback from all participants has been very positive about the sense of team spirit created.

When developing for Kotlin Multiplatform (KMP), developers must juggle between Android Studio for Kotlin and Xcode for Swift, which disrupts workflow, increases context switching, and can lead to synchronization conflicts when editing files in both editors. Fleet, an IDE from JetBrains, was created to facilitate the use of KMP. It solves these problems by allowing developers to manage code from both languages in a single IDE without the need to use other editors.

As a trusted provider of tools such as IntelliJ and Android Studio, JetBrains ensures greater efficiency for cross- platform developers with Fleet. The IDE offers features like auto-completion and code navigation that surpass even Xcode. However, Fleet is still in its early stages and has several limitations, including a lack of features and stability issues. For example, you can't add plugins, which means you can't use Copilot, but JetBrains offers an AI-based auto-completion alternative.

A few years ago, Progressive Web Apps (PWAs) were all the rage. Some even went so far as to predict the end of mobile apps, and some case studies made a compelling case for PWAs.

But while universal apps have matured, PWAs have never really taken off. Their adoption has been hampered by a lack of support on iOS, discoverability issues, difficulty gaining user trust, and a lack of functionalities for developers.

The fact that the PWA Summit has only been held twice, and not again in 2024, is a sign that PWAs are losing momentum. Some players are still using them successfully, and new PWAs are being introduced regularly, but we believe they no longer represent a solid mobile strategy.