MainActor

MainActor : Contexte d’exécution Swift réservé au thread principal, annotation qui garantit qu’une mise à jour d’interface se fait au bon endroit.

Le mot appartient à la famille « Développement » du lexique. Cette page dit ce qu’il recouvre, comment il se formule dans un cahier des charges, et ce qu’il vaut mieux ne pas écrire.

Pourquoi MainActor compte sur un projet mobile

Dans une équipe mobile, MainActor sert de repère commun entre les développeurs iOS, Android et serveur. Quand le mot n’a pas le même sens des deux côtés, l’intégration se termine en réunion.

Le sujet se présente rarement seul. Il arrive au milieu d’une décision plus large, et c’est à ce moment qu’il faut savoir de quoi on parle.

La traduction en exigences

Dans un cahier des charges, MainActor n’a pas à être imposé ligne à ligne. Ce qui doit être écrit, c’est l’exigence à laquelle ce choix répond et la contrainte qu’il ne doit pas violer.

À écrire noir sur blanc, dans le chapitre qui correspond :

• Les versions minimales d’iOS et d’Android supportées, qui décident des API disponibles.
• Le sort du code : dépôt remis, licences des bibliothèques, cession des droits à la livraison.
• Les bibliothèques tierces autorisées, et qui paie leurs licences dans la durée.
• La procédure de mise à jour de l’application une fois qu’elle est publiée.

Une exigence bien écrite tient en trois lignes et se refuse en une. Si elle ne peut pas être refusée à la recette, elle n’est pas encore écrite.

Le modèle de cahier des charges du guide reprend ces rubriques dans l’ordre attendu par une agence, et la grille de lecture des devis montre à quoi ressemble un chiffrage comparable.

Ce que ça change au moment de la recette

À la recette, MainActor se contrôle avec les mêmes gestes à chaque version. Ce sont ces gestes qu’il faut écrire une fois pour toutes.

• Demander à voir le dépôt de code et son historique, pas une capture d’écran.
• Contrôler la liste des bibliothèques tierces et le régime de leurs licences.
• Suivre soi-même, une fois, la documentation d’installation remise.

Chacun de ces contrôles prend quelques minutes. Les découvrir après la mise en ligne prend des jours.

Ce qui tourne mal le plus souvent

Sur ce point précis, voici ce qui coûte le plus cher aux porteurs de projet, dans l’ordre où on le rencontre.

• Laisser la remise du code hors du contrat, puis découvrir que le dépôt n’est pas transmis.
• Confondre bibliothèque gratuite et bibliothèque sans coût : certaines licences se paient à l’usage.
• Croire qu’un développeur reprend le travail d’un autre sans documentation ni période de recouvrement.
• Traiter la dette technique comme une affaire interne à l’agence : elle sera facturée au suivant.
• Repousser l’arbitrage au sprint suivant, autant de fois qu’il y a de sprints.

Termes liés

Les entrées du glossaire déjà publiées sur des sujets voisins :

• ObservableObject
• Modifier
• encapsulation
• test instrumenté

Questions fréquentes

Que signifie « MainActor » ?

Contexte d’exécution Swift réservé au thread principal, annotation qui garantit qu’une mise à jour d’interface se fait au bon endroit. Le mot est employé tel quel par les équipes francophones. C’est celui à utiliser dans les échanges avec une agence, y compris quand la traduction française existe.

Est-ce que ça change le prix de l’application ?

Rarement seul, souvent en cumul. Ces décisions pèsent surtout sur le coût des évolutions : ce qui est facile à modifier coûte moins cher sur trois ans qu’une économie faite au moment de la construction.

Où placer ce point dans le cahier des charges ?

Dans le chapitre qui correspond à sa nature, jamais dans une ligne fourre-tout. Le modèle de cahier des charges propose les rubriques attendues et l’ordre dans lequel les remplir.

Toutes les définitions publiées sont rassemblées dans l’index du glossaire, classées de A à Z et par famille.