Forem: 💻🎮

When should you really delete an app?

💻🎮 — Thu, 16 Oct 2025 06:47:26 +0000

React 16, Node 12, no TypeScript, a single CSS file with 1,500 lines... and of course no functional specs.

That's what our subscription application for TV devices looked like. The majority of the team decided it would be best to start over from scratch.

An application with constraints

Our application allows people to subscribe directly to services on their televisions, such as packages giving access to applications, without needing another device.
The main challenge with this type of device comes from technical constraints that are stricter than on the traditional web. Built-in browsers cannot be updated, which prevents the use of certain recent JavaScript, CSS, or HTML features.

So we are stuck with so-called “old” technologies more out of necessity than choice.

The code reflected these constraints:

React 16, therefore in the React class
No TypeScript
No React Router
CSS styling

For a developer accustomed to modern stacks, this was not at all appealing.

Restarting the project: challenges and constraints

When a new Product Owner took over the project, his first observation was that the application was “too outdated.”
The obvious solution, which was immediately proposed, was to start a new project. It seems easier to start over than to repair what already exists.

But there was a catch: despite numerous UX and architectural proposal meetings, we kept coming back to the same technical constraints.
What's more, the new project would have the same constraints as the old one, but with:

Several months of development
A complete qualification phase
Integration of the company's various teams (sales, support, etc.)
A risk of functional regression
Zero value delivered for the company during this time

One question kept running through my mind: What if we improved what we already had?

The more I compared the models for the new project with what we already had, the less I saw a revolution...
The real question that no one was asking at that moment was:
“Have we really tried to improve what we already have?”

Unfortunately, the answer was no. We had always focused on features, never on continuous improvement of the product.

I pushed this idea, and my superiors followed me.

The strategy: incremental improvement

Phase 1: Design and UX (1 sprint)

We started with what is visible, for example:

Redesign of the background image
Redesign of the buttons
Improvement of UX positioning

The result was already visible when it was presented to the sales team.

Phase 2: Continuous technical improvement (2-3 sprints)

We tackled technical debt in small steps:
Backend:

Migration from Node 12 to Node 22 (progressive, in several stages)
Refactoring of endpoints
Improvement of code structure

Frontend:

Creation of reusable components
Improvement of folder structure

Quality:

Systematic processing of the anomaly backlog
Correction of bugs that had been around for years
Improvement of stability

Phase 3: Measurable results

After several months of this approach:

Technical

Node 12 → 22: successful migration without regression
Reusable components created
Technical documentation

Quality

Bug backlog: reduced by approximately half
Pilot site testing: 0 anomalies reported

Business

Positive user feedback
Sales staff satisfied to see a product improving

Team

Motivation maintained (continuous delivery of value)
Increased skills in refactoring
Pride in seeing the product improve

Lessons learned

1. New things are always more appealing, but they come at a cost

Starting from scratch gives the illusion of building on a solid foundation. In reality:

We always underestimate the time required
We lose the business knowledge hidden in the code
We often repeat the same mistakes
We deliver no value for months

2. Legacy code isn't always bad

Our application was described as “legacy,” which should not be confused with “obsolete”:

It runs on React 16 - This isn't the most recent version, but it's still functional
It worked and had satisfied users
It contained proven business logic
It was stable in production

The real problem was that we never took the time to continuously improve the existing code; we just kept adding features.

3. Technical constraints do not magically disappear

Our main limitation (devices) still existed. Rewriting would not have changed that.

Sometimes the best option is to optimize according to constraints rather than believe in a world without constraints.

Conclusion: Think before starting from scratch

Yes, our application still does not meet the criteria of the latest recommendations for modern JS stacks.

Yes, there is still room for improvement.

But today it is:

More maintainable
More user-friendly
More reliable

And above all: we have delivered concrete improvements at the end of each sprint.

Sometimes, technical debt isn't in the code, but in the time we never devoted to it.

Cover image generated using AI

React Native : comment une simple mise à jour fait tout s'écrouler

💻🎮 — Sat, 16 Aug 2025 16:54:35 +0000

En tant que développeuse full-stack dans une entreprise qui jongle avec plusieurs produits, je travaille principalement sur des applications web. Le mobile n'est pas notre spécialité, et comme souvent, nous faisons les montées de version au dernier moment. C'est dans ce contexe que replonge dans les profondeurs de React Native.
Première appréhension, est ce que le projet rebuild ? Là, j'ai déjà une petite victoire, celui qui a déjà fait du mobile connaît cette joie de voir passer son npm run android et l'application se lance, mais tout ce n'est pas passé comme prévu.
Je souhaite partager avec vous les difficultés rencontrées pendant une semaine dans cet article.

Chronologie : une semaine mouvementée avec React native

Jour 1. La migration Android SDK - L'optimisme du début

Mission : passer d'Android SDK33 à 35 pour supporter Android 15
La première étape semblait simple sur le papier. J'ai attaqué méthodiquement :

Modification du android/build.gradle pour basculer compileSdkVersion et targetSdkVersion vers 35
Mise à jour buildToolsVersion vers "35.0.0"
Upgrade Android Gradle Plugin : 8.2.0 → 8.6.0 (première alerte rouge que j'aurais du voir venir)
Ajout de la propriété magique android.suppressUnsupportedCompileSdk=35 dans gradle.properties

verdict : Build Android réussi ! Je pensais naïvement que ce serait aussi simple que ça.

2. Jour 2 : le château de cartes des dépendances npm commence à vaciller

C'est là que la réalité m'a rattrapé. Les conflits de dépendances ont commencé leur danse infernale :

Voici un exemple d'un de mes nombreux problèmes de la journée :
React 18.2.0 ne voulait plus parler à react-intl@4.5.0 qui réclamait demande React ^16.3.0.

Ma descente aux enfers* :

Premier réflexe : le classique rm -rf node_modules suivi d'une réinstallation
Échec. Tentative avec npm install --legay-peer-deps pour forcer la roue
Miracle : 2266 packages installés ! (avec seulement 62 vulnérabilités comme cadeau bonus)

Jour 3 : Gradle, un vieil ennemi oublié

Au moment où je pensais avoir dompté npm, Gradle s'est rappelé à moi :

" Error resolving plugin [id : 'com.facebook.react.settings'] node_modules/@react-native/gradle-plugin' does not exist"

Le diagnostic : notre React Native 0.71.8 ne connaissant pas ce plugin qui n'existe qu'à partir de la version 0.72+.
A ce moment là j'ai même pensé recommencer l'application de zéro entre les soucis de dépendances et de build, j'étais à deux doigts de faire lancer un npx create-expo-app@latest

La méthodologie : réécriture complète du settings.gradle en remplaçant les références futuristes par la vielle méthode @react-native-community/cli-platform-android

Jour 4 : Jitsi - Le boss final

C'est ici que j'ai compris l'ampleur du désastre :
Oui, Jitsi (Logiciel de visioconférence open source gratuit pour le web et les appareils mobiles) sort des versions régulières, la dernière 11.4.0. Mais entre la théorie et la pratique, il y a un gouffre, faire tourner ces versions avec un projet React native qui a été initié il y a 5 ans.

" Could not resolve com.android.tolls.build:gradle:3.5.3"

La révélation : la version implémentée dans mon projet du SDK Jitsi vivait encore en 2019 avec Android Gradle Plugin 3.5.3, complètement incompatible avec notre stack moderne (SDK35+AGP 8.6.0).
Les repositories Maven refusaient même de répondre à des requêtes aussi lointaines...

L'espoir : du coup, j'ai installé la dernière version du SDK Jitsi et j'ai été heureuse, car un moment, j'avais même réussi à faire monter la version de React native en 0.77.3, mais là retour de la boucle infernale des dépendaces...

Issues :
Après de l'errance sur le web, je tombe sur l'issue qui disait https://github.com/jitsi/jitsi-meet/issues/14912 ne supportait pas les versions React natives supérieures à 0.73.

Jour 5 : les erreurs runtine

Après avoir réussi à compiler (petit miracle même si cela ne marchait pas !), l'application a décidé de me gratifier d'un magnifique :
"Failed to get room and jwt using code : 10208310 [Error: Request failed with status code 500]"
L'origine : une fonction appelée dans le front ne marchait plus, ce n’était même pas lié à la migration. Le backend avait ses propres problèmes...

Cette semaine m'a vraiment fait prendre conscience à quel point c'est compliqué de garder une application mobile à jour, surtout quand ce n'est pas notre cœur de métier. On pense naïvement qu'on va juste mettre à jour une petite dépendance, mais en fait, c'est toute une cascade de changements qui s'enchaîne...

Le plus dur, c'est qu'on touche à cette application de temps en temps seulement. Du coup, à chaque fois qu'on y revient, on se retrouve avec des mois de retard à rattraper d'un coup.

La prochaine fois qu'on me dira " on a juste besoin de mettre à jour le SDK pour publier", je saurai que c'est le début d'une nouvelle aventure, car avec React native il n'y a pas de petites mises à jour juste de grandes batailles... Où je poserai mes vacances à ce moment-là ...

Image de couverture générée à partir d'une IA