Appels VoIP et releases : fiabiliser les frontières natives

Les appels entrants et les releases automatisées ont un point commun : ils traversent des frontières que JavaScript ne maîtrise pas seul. L’OS doit pouvoir réveiller une app ; un pipeline doit produire puis tester le bon binaire. Deux retours d’expérience montrent les responsabilités à conserver explicitement.

Fishjam : une interface système pour les appels

Software Mansion présente une alternative à react-native-callkeep (nouvelle fenêtre) intégrée à Fishjam. Elle relie CallKit sur iOS et Telecom sur Android à une API React Native utilisable avec Expo ou un projet bare. La gestion de la sonnerie système et l’entrée dans une room restent deux étapes distinctes.

Le choix implique une architecture média : ce n’est pas uniquement un remplacement de composant visuel dans un pipeline WebRTC arbitraire. Avant une migration, inventorier notifications, signalisation, état de l’appel et permissions. Sur Android, l’interaction avec la bibliothèque de notifications déjà installée mérite un essai spécifique.

Les scénarios importants commencent hors de l’écran de conversation : appareil verrouillé, app en arrière-plan, appel accepté puis connexion média échouée, ou appel annulé avant réponse. Le résultat doit être cohérent dans l’interface système comme dans l’app.

SWSH : valider le binaire avant la distribution

Le cas SWSH publié par Expo (nouvelle fenêtre) décrit environ 300 builds mensuels sur son propre matériel, une base React Native pour plusieurs cibles et des tests de bout en bout avant distribution. L’équipe conserve des services EAS pour différentes étapes de livraison et le suivi après release.

L’enseignement réutilisable n’est pas qu’il faudrait tous auto-héberger les builds. Il faut connaître le coût dominant : attente de compilation, opérations manuelles, capacité des runners ou tests insuffisants. L’hébergement local déplace la responsabilité de disponibilité et de maintenance vers l’équipe.

Une preuve adaptée à chaque frontière

Pour la VoIP, une capture d’un écran ouvert ne démontre pas le réveil depuis le verrouillage. Pour une release, un bundle compilé ne démontre pas qu’un login fonctionne dans le binaire signé.

Une revue utile précise donc l’état initial, la cible et le build réellement testés. Garder un parcours court et reproductible au début permet d’étendre la couverture progressivement : d’abord une plateforme et un appel entrant, puis les annulations, la seconde plateforme et les interruptions.