A short introduction to notifications
Notifications are part of iOS for a long time, but iOS 10 brings us a way to present custom notifications to the user.
Say, for example, that there is a large bubble gum store. When a client walks into a shop to buy a jar of bubble gums, user’s device that runs the BestBubblegums(tm) app, can get a notification with a picture of bubble gum saying that there is a discount if you buy 100 pieces or more. We need a way to inform bubble gum buyer of this so that he becomes inspired to buy the product.
Before iOS 10 we could inform our user’s only by sounds, app icon badges and alerts. That’s not very engaging in today’s emoticon-based bubble gum mobile world. In order to show our product to the user, we would have to open the app when the user interacts with the notification.
iOS 8 added interactivity and color-coded actions.
iOS 8 brought the possibility of attaching actions to notifications. Actions could be from liking a post, accepting attendance to an event to actions that requires opening an app and then performing some action. That was very handy to users because they can make decisions right from the notification view.
One thing that is also new since iOS 8 is the push notification payload size. Since iOS 8 and the later notification payload is increased from 256 bytes to 2 kilobytes, making notifications more versatile. We could use the notification payload, for example, to send headlines of all topics our user has subscribed to. Or we can send a list of users that started following post our user has made, without making calls to backend infrastructure, after push notification is received.
In iOS 10 notifications are way richer than they were in iOS 8. They can contain images, video and animations, so we can create more compelling notifications.
To see an extended notification, user needs to swipe down on the notification, which is on Springboard, or 3D touch on it. If the notification is on a lock screen, user needs to long press or swipe left to see revealed controls.
Notifications can be remote and local, and the latter is what this blog is about. We will briefly mention remote notifications, called push notifications. They are called push notifications because some remote infrastructure sends them to the device. In other words, the server sends notification and a device responds.
Apple has their own service for pushing notifications to devices which is called Apple Push Notification Service, or APNS. Remote notifications are first sent by our server, which notifies APNS which then delivers notification to a device. The client needs to have an infrastructure that can support scheduling push notifications. This is usually performed by the backend that services the application, but can also be delegated to other providers.
In contrast, local notifications are scheduled on users device and will be delivered to the user, depending on the way that they are scheduled.
Because notification content can be customised, we can make more interesting notifications, for example, we could put animated image and play music.
In custom notification, developers can use almost all UIViewController capabilities to create engaging content for the user.
Custom notifications can contain images, video, sound and custom generated content. Gif images are also supported as attachments, not as image in UIImageView. Adding gesture recognizers or UIResponder controls to view won’t work because processing touches is not available in content extension. Adding actions, which will appear as buttons below the notification content extension view, can guide user decision making. Rotating device also rotates notification view, so that needs to be taken into account when setting up autolayout constraints.