Comment créer un rappel local dans une app iOS ? Tutoriel débutant étudiant 2026

Votre rappel n’apparaît pas, ou vous ne savez pas par où commencer dans Swift ?

La voie la plus simple consiste à demander l’autorisation, préparer le contenu et le déclencheur, puis vérifier le résultat ainsi que le comportement en cas de refus. Un rappel local est planifié sur l’appareil ; il ne remplace pas une notification envoyée par un serveur.

Ce guide s’adresse aux étudiants qui ajoutent des rappels à une app de tâches, de cours ou de révision, ainsi qu’aux débutants qui découvrent Swift et iOS.
Si vous travaillez surtout sous Windows ou sur un ordinateur d’école verrouillé, vous verrez aussi à quel moment un environnement Mac compatible devient nécessaire pour construire et vérifier le projet avec Xcode.

Avant le code : choisir entre rappel local et notification distante

Commencez par écrire le message que votre app doit afficher et le moment auquel il doit être proposé. Pour un cours, cela peut être « Réviser le chapitre » à l’heure choisie par l’étudiant. Si l’app doit seulement rappeler à cet utilisateur une tâche déjà enregistrée sur son appareil, une notification locale est généralement le point de départ le plus direct.

Une notification distante répond à un autre besoin : un serveur envoie un message à l’appareil, par exemple pour signaler une mise à jour qui ne dépend pas d’une tâche planifiée localement. Les deux mécanismes peuvent afficher une notification, mais leur origine et leur logique ne sont pas les mêmes. La documentation User Notifications d’Apple distingue la gestion des notifications par l’app et les moyens de les présenter.

Votre app doit-elle demander l’autorisation avant de programmer un rappel ? Oui, si elle veut présenter des notifications soumises à l’autorisation de l’utilisateur. Expliquez d’abord leur utilité dans le contexte de l’app, puis utilisez l’API prévue ; Apple décrit cette demande et les autorisations possibles dans son guide consacré à l’autorisation des notifications.

Ne demandez pas la permission par réflexe au lancement si l’utilisateur ne comprend pas encore la fonction. Dans une app de révision, vous pouvez expliquer que les alertes servent à retrouver les sessions choisies, puis proposer l’activation au moment où cette fonction est utilisée. Si la personne refuse, les tâches et le calendrier doivent rester consultables : le refus n’est pas une panne de l’app.

Attention : une notification locale n’est pas une garantie d’affichage à une minute précise. Le système gère la demande et sa présentation ; votre exercice doit vérifier la configuration et le résultat dans l’environnement réel, sans promettre une ponctualité absolue.

Au moment de la demande : présenter la permission et gérer un refus

Une demande d’autorisation constitue une décision de l’utilisateur, pas une simple étape technique. L’API requestAuthorization permet à l’app de demander les options pertinentes, par exemple les alertes, les sons ou les pastilles. Consultez la documentation de cette API et demandez uniquement ce qui correspond à la fonction que vous développez.

Avec Swift, votre logique doit tenir compte du résultat : ne programmez pas l’interface comme si l’accord était acquis. Si l’accès est accordé, vous pouvez poursuivre le scénario de rappel. Dans le cas contraire, affichez une explication sobre, gardez la tâche accessible et indiquez où l’utilisateur pourra revoir ses préférences s’il le souhaite. Évitez de bloquer l’écran ou d’afficher un message d’erreur qui laisserait croire que l’app ne fonctionne plus.

Que faire si l’utilisateur refuse les notifications ? Continuez à fournir la fonction principale sans alerte. Vous pouvez afficher les échéances dans une liste ou un calendrier intégré à l’app ; si la personne veut changer son choix, expliquez qu’elle peut examiner les réglages de notification de l’appareil. Ne relancez pas la demande comme si un refus signifiait une erreur de programmation.

Pour adapter l’interface à l’état courant, interrogez les réglages plutôt que de supposer qu’ils n’ont pas changé. Apple documente la lecture de cet état avec getNotificationSettings. Cela vous permet de distinguer une autorisation disponible d’un réglage qui ne permet pas l’affichage attendu, et de guider l’utilisateur sans prétendre modifier ses choix à sa place.

Dans le code : assembler le contenu et le déclencheur

Une notification associe un contenu et une condition de déclenchement. Le contenu porte notamment le titre et le texte ; le déclencheur décrit quand la demande doit être traitée. Pour une tâche de révision, le titre peut indiquer le cours et le texte préciser l’action attendue. Écrivez un message reconnaissable même si l’utilisateur ne se souvient plus de l’écran qui l’a créé.

La procédure Apple de planification d’une notification locale décrit la préparation d’un contenu, d’un déclencheur et d’une demande à remettre au système. L’exemple ci-dessous utilise un délai de 60 secondes afin de faciliter un essai rapide ; la référence Apple à UNTimeIntervalNotificationTrigger documente ce type de déclencheur. Ce délai est un choix de démonstration, pas une promesse de livraison à la seconde près.

import UserNotifications

func programmerRappelDeTest() async throws {
    let centre = UNUserNotificationCenter.current()

    let autorise = try await centre.requestAuthorization(
        options: [.alert, .sound, .badge]
    )

    guard autorise else {
        return
    }

    let contenu = UNMutableNotificationContent()
    contenu.title = "Révision"
    contenu.body = "Pensez à relire vos notes de cours."
    contenu.sound = .default

    let declencheur = UNTimeIntervalNotificationTrigger(
        timeInterval: 60,
        repeats: false
    )

    let demande = UNNotificationRequest(
        identifier: "rappel-revision-test",
        content: contenu,
        trigger: declencheur
    )

    try await centre.add(demande)
}

Dans votre projet, appelez cette fonction depuis un parcours où la personne comprend pourquoi une permission est demandée, et traitez les erreurs renvoyées par les opérations asynchrones. Pour une vraie app de cours, ne gardez pas un délai de test comme logique définitive : reliez le déclencheur à la date choisie par l’utilisateur et vérifiez que cette date correspond au besoin du projet.

Où régler le texte et l’heure ? Le titre et le corps se règlent dans l’objet de contenu ; le moment se règle dans le déclencheur. Un déclencheur fondé sur un intervalle et un déclencheur fondé sur des éléments de calendrier ne décrivent pas la même intention : choisissez selon que vous voulez un délai à partir de maintenant ou une échéance associée à une date et une heure.

À l’exécution : comparer l’affichage au premier plan et en arrière-plan

Une demande ajoutée avec succès ne suffit pas à valider l’expérience. Vérifiez le scénario depuis l’interface de votre app, puis observez ce qui se passe lorsque l’app n’est plus au premier plan. Lorsqu’elle est utilisée, le comportement de présentation dépend du traitement configuré par l’app ; la documentation Apple sur la gestion des notifications et des actions associées explique le rôle du délégué et la décision de présentation.

En pratique, ne concluez pas « le rappel ne marche pas » après un seul essai. Contrôlez d’abord que l’autorisation permet la présentation, que le déclencheur correspond à l’heure attendue et que les réglages système n’empêchent pas l’affichage. Ensuite, refaites l’essai avec l’app en arrière-plan. Ce parcours sépare les erreurs de programmation des choix de présentation et des réglages de l’appareil.

Pour rendre le test utile, consignez ce que vous observez : la demande a-t-elle été ajoutée sans erreur ? Le contenu est-il celui de la tâche ? L’app était-elle ouverte ou en arrière-plan ? Le résultat doit être formulé selon le système et les réglages réellement testés, pas comme une règle universelle valable dans toutes les situations.

Avant de rendre le projet : suivre le bon parcours de vérification

Utilisez cette liste dans l’ordre, et conservez une trace de votre environnement de test afin de pouvoir expliquer votre résultat à votre enseignant ou à votre équipe :

• Vérifiez que la fonction est utile au scénario du projet et que l’utilisateur comprend son intérêt.
• Demandez l’autorisation au moment approprié, puis traitez explicitement l’accord comme le refus.
• Confirmez que le titre et le texte décrivent bien la tâche choisie.
• Contrôlez que le déclencheur représente la bonne intention : délai de test ou échéance sélectionnée.
• Vérifiez que l’app peut encore afficher les tâches sans autorisation.
• Testez la présentation avec l’app ouverte, puis en arrière-plan, en notant les conditions observées.
• Après une modification des réglages, relisez l’état d’autorisation et recommencez le parcours utile.

Votre prochaine étape dépend du livrable demandé :

• Si le cours exige seulement la logique et l’interface, commencez par valider le parcours utilisateur et le traitement des deux résultats de permission.
• Si le cours exige une construction et une exécution iOS avec Xcode, utilisez un environnement Mac compatible pour compiler et effectuer l’essai ; un poste Windows seul ne remplace pas cette étape de construction sur Mac.
• Si l’exercice dépend d’un message déclenché par un événement serveur, revenez à la conception : une notification locale n’est pas le bon mécanisme pour cette partie.
• Si vous n’avez pas accès à un Mac, commencez par examiner les solutions de Mac à distance et leurs modalités, puis choisissez selon la durée du cours et les vérifications réellement exigées.

Cette grille évite de louer ou d’acheter une machine avant de savoir si le cours impose effectivement une compilation iOS. Elle évite aussi l’erreur inverse : conclure que l’app est validée parce que son écran s’affiche, alors que le projet doit encore être construit et que le rappel doit être essayé dans un environnement Mac.

Pour choisir votre environnement : privilégier le besoin réel

Vous devez utiliser Xcode, mais votre ordinateur principal est sous Windows ? Si la consigne porte sur la compilation et l’exécution d’une app iOS, prévoyez un passage par un Mac compatible. Si votre cours se limite pour le moment à la conception d’un écran ou à une première étude de Swift, vérifiez la consigne avant de modifier votre équipement.

L’achat d’un Mac est cohérent si vous en avez besoin régulièrement, si vous souhaitez travailler localement sans dépendre d’une connexion distante ou si votre projet exige des périphériques physiques. À l’inverse, pour une séance de construction et de validation liée à un cours, louer un environnement Mac peut éviter d’acheter une machine avant de connaître la suite de votre parcours. Vous pouvez consulter les offres MacDate et comparer leur adéquation avec votre tâche, sans confondre l’accès à un Mac avec une garantie sur le comportement des notifications.

Un poste distant dépend de la connexion et ne remplace pas un appareil physique lorsqu’un cours exige un essai matériel particulier. Un ordinateur personnel peut aussi être plus pratique pour un travail quotidien long. Le bon choix est donc conditionnel : si le projet exige Xcode et que vous n’avez pas de Mac disponible, examinez une solution Mac temporaire ; si vous devez développer durablement ou connecter du matériel, évaluez d’abord l’intérêt d’un Mac local.

Le rappel local lui-même reste un exercice de conception autant que de code : demandez une permission compréhensible, programmez un contenu pertinent et vérifiez ce que l’app fait lorsque l’autorisation manque. En suivant ces étapes, vous pourrez expliquer clairement ce que votre test prouve — et ce qu’il ne prouve pas — avant de remettre votre projet.