Ask for Authorization
Like every feature that requires accessing the user’s iPhone, you need to ask for permission.
In our case, we need to ask the user if he wants to receive notifications from your app.
appDelegate, just add these lines:
And don’t forget to import
First, you need to set up the options that your notifications will use.
In my example, I’ve added the options to display an alert, play a sound when the notification is received, and change the badge in the app (the number in the red background on the app icon).
This is just an example. Here’s the list of all the available options you can add.
I strongly recommend you read this because you’ll see all the possibilities available to you with the NotificationCenter.
Then, you ask for authorization to send the notifications. It’ll ask for permission only at the first launch of the app — you don’t have to worry about that.
In my example, I am not handling the rejection of the user. But you can set it to print something on line 28.
Once the user allows you to send notifications, you have to schedule them.
We’ll create a function to schedule notifications in
appDelegate, but it’s up to you to call the function whenever you need it. It depends on your app and your goals.
There are many ways to send notifications. You can send them every week, every month, on a specific date, with specific content, and you can even make them play a sound as they are received by the user.
Here is an example for a weekly notification:
First, you need to check if the user has authorized your app to send notifications.
If you are allowed to send notifications, you then create a trigger from a date component that will be the date in which the user will receive the notification.
In our case, we create a trigger for a specific weekday at a specific time. And we also say that our notification will be repeated every time the current date matches our trigger.
You can use the same method to create a notification at a specific date or every month on a specific day and time.
The possibilities are infinite.
Then, you create the content of the notification.
The title of the notification is what you see at the top. (In the image above, it’s “Ellsworth St”.)
Then there is the body below the title. (Here, it’s “Entrance Door was opened.”)
But you can also add attachments, sounds, a specific badge, a subtitle, and much more.
Again, check out the documentation to see all the possibilities and pick the ones you need.
After that, we set the identifier of the notification: Every pending notification has a unique identifier. It could be anything. It can be as simple as a number. But you have to create one.
Once everything is ready, you take all that stuff and you add it into a
And the last step is adding this request to the NotificationCenter with the add function. It’ll handle errors in its completion handler.
In my example, I also print all the pending notifications if there is no error — but that’s just for debugging purposes. I just want to check that everything has been added correctly.
And that’s it! Your notification is scheduled, and it’s pending — waiting to be sent to the user.
Notifications in Swift aren’t that complex once you’ve understood the process.
The possibilities are huge, and mastering them will open a whole world of new possibilities for your apps.