\n<\/p>\n
On a Monday morning, I thought I\u2019d take a crack at implementing tips in one of my apps. There were some gestures and other features that customers weren\u2019t finding and explaining those things with tips would be helpful. I expected the task to take about a day.<\/p>\n
It ended up taking a week.<\/p>\n
Why so long?<\/p>\n
Well, the first problem is when you watch the introduction video from WWDC \u201923<\/a> you\u2019ll see outdated code throughout the presentation. TipsCenter doesn\u2019t exist. Configuration is completely different. And there is no mention of UIKit.<\/p>\n Then, when you look at the sample code<\/a>, it\u2019s all SwiftUI. At least the sample compiles and runs because it uses a completely different syntax than what was shown at WWDC.<\/p>\n But the fact remained: I had UIKit views where I wanted to display tips. And there wasn\u2019t any information on how to accomplish that. Did Apple really release a framework that didn\u2019t work on the code we\u2019ve been crafting for the past 20 years?<\/p>\n Tips are something you want to add to existing code. And UIKit is the most likely case there: you\u2019re not going to rewrite your views in SwiftUI just to explain some features. The biggest failure with the TipKit introduction is that it ignored the past and how apps have historically been built.<\/p>\n Eventually I stumbled upon TipUIPopoverViewController <\/a>which inherits from UIViewController. That should work!<\/p>\n And it did.<\/p>\n But it didn\u2019t: the close button on the popover didn\u2019t work<\/a>. And my first day was over.<\/p>\n This is the point where you start to learn that a Tip is a dynamic state machine that\u2019s mostly out of your control. My problem was understanding how that state machine interacted with my own code (and its state).<\/p>\n Eventually, you also learn that the Tip\u2019s state is persisted. Until you realize that any changes you make are stored in a SQLite database<\/a>, debugging is very confusing. It\u2019s also easy for your own state to get out-of-sync with the Tip state: there is not a single source of truth.<\/p>\n Your first task will be to figure out how to get the Tip close buttons to work. The sample code for TipUIPopoverViewController<\/a> hints at what you need to do: implement an asynchronous task that monitors the state of the tip. When that tip gets into the right state, it\u2019s your job to both present and dismiss the popover view controller.<\/p>\n Unfortunately, that sample code doesn\u2019t scale well. If you have a view with multiple tips, you\u2019re going to be littering your code with tip instances, observation tasks, and popover controllers. It\u2019s a mess and a clear sign that the TipKit developers didn\u2019t think much about UIKit.<\/p>\n My solution is a TipPresenter<\/a> class. It\u2019s instantiated by your view controller, starts an observation task, and then presents or dismisses a popover as the Tip\u2019s state changes. It significantly reduces the clutter, makes refactoring views\/tips easier<\/a>, and it even works from Objective-C code (yes, some of us still have that).<\/p>\n One thing to keep in mind when you\u2019re using TipPresenter: the observation task is a strong reference with weak references to a view and controller. Make sure you call stop() as you clean up your view<\/a>: if you\u2019ve ever used a notification observer, you\u2019ll know the pattern and why you need it \ud83d\ude42<\/p>\n Another pattern emerged once I had a convenient way to present tips: view updates and tip updates go hand in hand.<\/p>\n Most of our UIKit apps rely on a Model-View-Controller architecture. The model gets updated, changes propagate to the controller, which uses a view to display the new information. Every UIViewController has something like an updateView()<\/a>.<\/p>\n You\u2019ll quickly find that your model changes will need something that moves state to the tip presenter. Whenever updateView() gets called, you\u2019ll also call updateTips()<\/a>.<\/p>\n I\u2019ve been referencing a Tipster project repository<\/a> throughout this post. Feel free to download and experiment. If your UIViewControllers are written in Swift, check out PresentedViewController<\/a>. If you\u2019re working with Objective-C, take a look at LegacyViewController<\/a>. The ToggleTipPresenter<\/a> is used in both view controllers.<\/p>\n The TipKitHelper<\/a> file contains the Tip definitions, the TipPresenters, and the configuration helper class (which also has Objective-C members). Also of note: this code is compatible with iOS 17 and later.<\/p>\n I\u2019m not thrilled with the need to have separate implementations of the TipPresenter classes, but since Tip is a struct that can\u2019t be bridged to Objective-C, it has to be that way. <\/p>\n To quickly find important stuff in the project, search for As you get more familiar with TipKit, I highly recommend this article<\/a> on Fatbobman\u2019s Blog \u2013 it digs into the more advanced aspects of TipKit and includes an example of how to do an inline tip with UIView or NSView.<\/p>\n Armed with this code and information, adding TipKit to your UIKit app should take less than a week. Maybe even just a single day like I initially thought!<\/p>\n<\/p><\/div>\nNOTE:<\/code>. There is also a lot of debugLog()<\/a> in the code to help you see what\u2019s going on from the Xcode console.<\/p>\n