{"id":53059,"date":"2026-09-01T16:09:17","date_gmt":"2026-09-01T20:09:17","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=53059"},"modified":"2026-09-01T16:09:17","modified_gmt":"2026-09-01T20:09:17","slug":"tipkit-for-the-real-world","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2026\/09\/01\/tipkit-for-the-real-world\/","title":{"rendered":"TipKit for the Real World"},"content":{"rendered":"

Craig Hockenberry<\/a>:<\/p>\n

\n

Then, when you look at the sample code<\/a>, it’s all SwiftUI. At least the sample compiles and runs because it uses a completely different syntax than what was shown at WWDC.<\/p>\n

[…]<\/p>\n

Eventually I stumbled upon TipUIPopoverViewController<\/a> which inherits from UIViewController. That should work! […] But it didn’t: the close button on the popover didn’t work<\/a>.<\/p>\n

[…]<\/p>\n

Until you realize that any changes you make are stored in a SQLite database<\/a>, debugging is very confusing. It’s 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

[…]<\/p>\n

Unfortunately, that sample code doesn’t scale well. If you have a view with multiple tips, you’re going to be littering your code with tip instances, observation tasks, and popover controllers. It’s a mess and a clear sign that the TipKit developers didn’t think much about UIKit.<\/p>\n<\/blockquote>\n\n

Fatbobman<\/a>:<\/p>\n

\n

In the previous article, we introduced the basic usage of TipKit. In this article, we will discuss some advanced topics related to TipKit, such as how to fully customize Tip views (not using TipView and popoverTip), how to use TipKit with UIKit, and how TipKit can share data across different applications, as well as how to reuse Tip declaration code. Additionally, we will attempt to address some common questions and concerns about TipKit.<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n