Static and Dynamic Notification in WatchOS with SwiftUI, without Notification Scene

First of all, the notification on Apple watch occur in two stages - the Short looks and the Long looks - the short look appears on wrist raise and contains brief but meaningful information about the notification. The lowering of the user’s wrist causes the short look to disappear.

Short Looks

Short looks appear briefly, giving the user just enough time to see what the notification is about and which app sent it. Apple Watch defines the appearance of short looks, incorporating the title of the notification along with your app’s name and icon into the UI.

Long Looks

Long looks provide more detail about an incoming notification. The long look appears when the user’s wrist remains raised or when the user taps the short look. Long looks are dismissed automatically when the user’s wrist is lowered. The user can also dismiss them manually. Custom long looks come in static and dynamic versions. The static interface lets you display a notification’s message along with other static text and imagery. The dynamic interface gives you access to the notification’s full content and offers more options for configuring the look of the interface.The content area of the static and dynamic long looks is fully customizable, but the overall structure of the interface is not. The system-provided sash at the top displays the app icon and name. You can customize the sash’s color or give it a blurred appearance. Buttons for custom actions appear below the content area. The system always adds a Dismiss button to your interface and places it after your custom buttons.

iOS has a framework called UserNotifications, that does pretty much exactly what you expect: lets us create notifications to the user that can be shown on the lock screen. We have two types of notifications to work with, and they differ depending on where they were created: local notifications are ones we schedule locally, and remote notifications (commonly called push notifications) are sent from a server somewhere.

Remote notifications require a server to work, because you send your message to Apple’s push notification service (APNS), which then forwards it to users. But local notifications are nice and easy in comparison, because we can send any message at any time as long as the user allows it.

Now after you understand which and how notification work, we can talk about coding it.

First step is to create a project without Notification Scene

Next step is to “import UserNotification” in ContentView (in your Main View, or where you want to implement your custom notification) and go to request authorization (in this case we use a VStack to implement the Button for authorization).

If the user grants permission, then we’re all clear to start scheduling notifications. Even though notifications might seem simple, Apple breaks them down into three parts to give it maximum flexibility:

• The content is what should be shown, and can be a title, subtitle, sound, image, and so on.
• The trigger determines when the notification should be shown, and can be a number of seconds from now, a date and time in the future, or a location.
• The request combines the content and trigger, but also adds a unique identifier so you can edit or remove specific alerts later on. If you don’t want to edit or remove stuff, use UUID().uuidString to get a random identifier.

When you’re just learning notifications the easiest trigger type to use is UNTimeIntervalNotificationTrigger, which lets us request a notification to be shown in a certain number of seconds from now. So, next step is to create a second Button in the VStack, to introduce the trigger for notification:

Now if you run your app in the iOS Simulator, press the first button to request notification permission, then press the second to add an actual notification. Once your notification has been added press the Digital Crown(Home Button). After a few seconds have passed the device should wake up with a sound, and show our message!