It’s hard not to have tragic copywriting as a programmer. As we stepped into this indie scene, it was (and is) all too common to ship something like this:

Even nearly 15 years (!!!) into this business, I can still fall into this trap. Left to my own devices, I’ll happily ship some gormless button label like “Initiate Sequence”, its copy that reads like it was written for someone who should be code reviewing a recursive function. But instead, most people who use my apps are the everyman, who isn’t serially online chatting about AI agents. Writing for them doesn’t come as naturally. Other than experience and being aware of it, is there a way to audit your interface controls for terrible copywriting?

Turns out, Apple has the answer. And, if you power it up with an agent, it can audit your entire app for you. It all starts with this banger session:

In it, Heej walks through how to craft copy that feels human. That really helps someone understand the impact of a button press, or simply set an expectation of what will happen. This kind of thing is absolutely gold. It is the number one thing I think people like me struggle with. Here’s how I hooked up an agent to learn about that session, and then apply it to one of my apps:

1. Install Sosumi MCP or install the WWDC.ai skill.

   For Sosumi MCP:

   claude mcp add --transport http sosumi https://sosumi.ai/mcp
   

   Or, for the WWDC.ai skill:

   npx skills add https://github.com/superwall/skills --skill wwdc --global --yes --agent claude-code universal
   

2. Have an agent watch that session via whatever you installed on step 1.
3. Then, point it your app and give it context on who your target market is, what your app does, and using its new copywriting knowledge - propose updates to strings throughout.

When I did this, I had fantastic results:

Some of them were so obvious, it hurt. But, this is just a blindspot I have. I’m not great at interface label naming, or naming in general. There’s a lot of talk about where the line should be with creativity and AI, and it’s a necessary discourse. In this case? This is one area where I’m happy to have its help.

Until next time ✌️

Lately, I’ve been thinking a lot about the concept of a user interface. Like, weirdo, existential stuff. Why did we even make them in the first place?

Remember the good old days of Microsoft DOS? Just a welcoming, plain and greenish terminal. Alawys complete with a blinking green cursor inviting you to press enter, and a list of options:

I guess the idea of a user interface is to help people get something done, perform a certain task, accomplish whatever it is they have in mind. And the easiest way to do that, is…well, visually.

Though recently, I’ve started to have a weird realization that maybe the best UI in this world of agents is sometimes… not having one at all. In fact, I dictated this post all in Codex’s mac app (yes, I know — which is a UI! Hang with me though):

Here are few things I would’ve made an admin dashboard, custom interface, or any interface at all for about a year ago:

1. Customizing a server driven “Event” in a bespoke upcoming app.
2. Reviewing feature requests for Elite Hoops.
3. Managing blog posts for the company blog at Superwall.

Of course, in all three instances, I realized each of these things are agent driven processes. So why bother? I just tell the agent what I need. The only UI, at any stage, is the harness running the agent.

So I’m curious — is this a prominent direction the world is headed? I don’t think it’ll go so far to where we get to a place of “An ad-hoc agent and your prompt is the app for the given task”, as some people tend to think. I am, naturally, using an agent, without an extra UI in the target “thing” I’m working on, to produce some sort of output for an existing app.

Buuuuuut, it is also a little bit more in that direction than I would’ve thought. For me, a prompt can have the verisimilitude of an app: it’s a place to express intent, then I make revisions, and finally end up with the thing I wanted. Or maybe DOS had it right all along?

Until next time ✌️

The dawn of a new Siri (AI) looms in the air. When it ships, the promise of just saying what you want done, and having Siri just…do it, should be realistic. Apple, true to their roots of being masterful storytellers in terms of product, had many examples on tap. “Hey Siri, what was the water bottle I was thinking of getting a few months ago?”, and BAM — Siri went through a mountain of personal context, and found the answer.

That stuff is obvious. But, what about your app?

“Hey Siri, what team did I last make a play for in Elite Hoops?”

How do we do that, what’s involved, and how should you think about Siri and your app over the summer? I think I have a fairly good grasp on it, and I’ll summarize it here. I’m skipping deep dives, and just keeping it to a rundown.

First off, the parts involved. The whole process is the same — it’s still app entities for your app’s models, schemas for a particular definition of those if applicable, and a few APIs to make those known to Siri when they are on screen.

App Entity

First, each of your app’s data models that should participate in Shortcuts, an App Intent, or general system-wide intelligence should hav a lightweight AppEntity version. This isn’t the same as the model itself, but a lightweight version of it:

struct TeamEntity: AppEntity {
    static var defaultQuery = TeamEntityQuery()
    static var typeDisplayRepresentation: TypeDisplayRepresentation = .init(stringLiteral: "Team")
    
    var displayRepresentation: DisplayRepresentation {
        DisplayRepresentation(title: "\(name)",
                              subtitle: "\(rosterSize) \(rosterSize == 1 ? "player" : "players")",
                              image: DisplayRepresentation.Image(data: logo))
    }
    
    let id: String
    
    @Property(title: "Team Name")
    var name: String
    
    @Property(title: "Roster Size")
    var rosterSize: Int
    
    @Property(title: "Roster")
    var roster: [String]
}

Surfacing App Entities

From there, Siri needs to be able to find them. There are two routes. First, if a network trip is required or otherwise surfacing content takes more work, then you should use EntityStringQuery:

extension TeamEntityQuery: EntityStringQuery {
    func entities(matching string: String) async throws -> [TeamEntity] {
        Logs.appIntents.info("TeamEntityQuery: String query for term \(string)")
        
        guard let dao = DAO.readOnly else {
            Logs.appIntents.info("There is no database available for the intent to read from.")
            return []
        }
        
        let courts = try await dao.fetchCourtsBy(name: string)
        let entities: [TeamEntity] = try await TeamEntity.fetchData(for: courts)
        return entities
    }
}

More commonly, IndexedEntity is the best path forward. The system automatically indexes this content for you. In fact, most cases just need you to declare conformance:

extension TeamEntity: IndexedEntity {}

In fact, you can simply conform to IndexedEntity directly as opposed to AppEntity. Once you do that, you can identify which parts should be index for search, too, with @Property(indexingKey:).

This is, however, where I’m not entirely sure of the relationships between Siri and your app. If you fill type @Property(indexingKey: \.) — you’ll get a list of autocompleted things you can use here. I believe all of these tie into a predefined App Schema, and the properties within them. So, what if your app doesn’t fit into those? I’m not sure, but I don’t think you can use indexing keys in that case.

App Schemas

Speaking of App Schemas, and their associated domains, are basically juiced up App Intents. Apple has already trained Siri to the moon and back over them, it’ll understand context better, and participate in follow up questions and everything else in-between. They’ve done the work for you. So, if you app fits into one of these schemas, absolutely use it.

You do so by using a property wrapper above your entity declaration:

@AppEntity(schema: .messages.message)
struct MessageEntity: IndexedEntity {
  // The text content of the message
  @Property(indexingKey: \.textContent)
  var body: AttributedString?
}

…where messages is the overall schema, and the message is the domain within it. Xcode will also autocomplete the fields you need to implement a domain. Again, if your app’s data fits into a schema, it’s 100% what you should use. What’s less clear to me is what you can do, or should do, and how far your app can participate with Siri AI if you don’t fit into one of these predefined boxes.

On-screen Awareness

Once you’ve indexed data and exposed it to the system, next you wanna take part in that whole “Yo Siri, tell me about X or Y”, where X or Y is something currently on screen. Two different routes here:

1. NSUserActivity: The tried and true API around, since what — iOS 8?, can help with singular content. For example, a photo.

2. View annotations API: Use this when you’ve got more than one singular thing that’s presented, like a list of stuff.

Together, these tie back to an AppEntity, which means everything is structured in a way Siri can understand. Here’s how they look:

struct MyPractice: View {
    let practice: Practice

    var body: some View {
        VStack {
            StuffAndThings()
            PracticeContainer()
            .userActivity("com.example.elitehoops.practice", 
                          element: practice.asEntity()) { entity, activity in
              activity.title =  practice.title
              activity.appEntityIdentifier = .init(for: entity)
            }
        }
    }
}

And for view annotations:

struct MyPractices: View {
    let practices: [Practice]

    var body: some View {
        ForEach(practices) { p in 
            PracticeView(practice: p)
                .appEntityIdentifier(
                      EntityIdentifier(
                          for: PracticeEntity.self,
                          identifier: p.id
                      )
                )
        }
    }
}

Handle Data Coming In and Out

Finally, getting data out and in. When Siri wants to chain together stuff, like “Hey Siri, email this practice to Jansyn.” — we’ve now got a few moving parts. There’s the “practice”, I need to export my own data, and then there’s the recipient, Mail. To export or import, look no further than Transferable.

There is some nuance depending on the context. If you’re trying to handle an incoming request against some existing content, then you’ll need IntentValueQuery. But, if that request means your app should creating a new model or data, then implement the importing bit when wiring up your transferRepresentation within Transferable.

In Apple’s session, they use this example:

struct ContactEntityQuery: IntentValueQuery {
    func values(for input: [IntentPerson]) async throws -> [ContactEntity] {
      let names = input.map(\.displayName)
      let descriptor = FetchDescriptor<Contact>()
      let contacts = try model.mainContext.fetch(descriptor)
      let matches = contacts.filter { contact in
          names.contains(where: { name in
              contact.name.localizedStandardContains(name)
          })
      }
      return matches.map(\.entity)
    }
}

However, this is the part that feels slightly limiting. It’s typed to handle only an IntentPerson — something the system already defines. As far as I can tell, your app would have to use some value-known intent already, like IntentPerson or something from the App Schemas. Otherwise, you also wouldn’t be able to use IntentValueRepresentation — which is exactly what Siri uses for this type of stuff.

Here’s another example I found in the docs, which handles things bidirectionally:

extension TeamEntity: Transferable {
    static var transferRepresentation: some TransferRepresentation {
        IntentValueRepresentation(
            exporting: { entity in
                IntentPerson(name: .displayName(entity.name))
            },
            importing: { person in
                ContactEntity(name: person.name.displayString)
            }
        )
        DataRepresentation(exportedContentType: .utf8PlainText) { entity in
            entity.teamSummaryText().data(using: .utf8) ?? .init()
        }
    }
}

So, I’m unsure of how to handle this beyond that. If our apps don’t fit into schema, where does that leave us? I haven’t found the answer to that.

Final Thoughts

New Siri looks fantastic. No doubt, integrating it will finally bring us to that “This is what I wanted” phase of the tech. It should be an epochal event for our little digital assistant. For us? The APIs are easy to use, and there isn’t much guesswork. My only question mark is how to best integrate when our data models don’t fit into an App Schema, and if I find concrete answers — I’ll update this post.

Until next time ✌️

Times…they are.concact(.haveBeen) changing. In years past, I’d wait for the “What’s New in UIKit” video to hit towards the end of dub dub week, pour through the new docs to see what was added, and then fumble my way around Xcode to get the first examples of the changes up and running.

And now? Well, I just…kinda, did this:

Within minutes, I now had workable code samples of all the changes, explanations of what they were, and docs. I prayed for days like this, man.

It used to take so much more work!

There’s even a skill for this sort of thing, I have to imagine Cupertino & Friends™️ made it just to throw me a bone for my annual UIKit post:

As of today, the pathway to utilizing UIKit is virtually nothing. I’d argue now is a better time than ever (yes — really!) to give our trusty ol’ UI framework a go in your app. Apple has given access to skills to do it correctly, efficiently, and quickly. So, let’s see what’s new.

If you want to catch up on this series first, you can view the iOS 11, iOS 12, iOS 13, iOS 14, iOS 15, iOS 16, iOS 17, iOS 18, and iOS 26 versions of this article.

Navigation Bar & Bar Buttons

The nav bar and its friends got quite a bit of attention, and to be honest that’s where we will find most of the changes. They adapt to all sorts of sizes and situations…hmmm, I WONDER WHY!?

Navigation Bar Minimization

Docs

Each view controller now gets a say in whether its navigation bar shrinks down as you scroll. It’s a great fit for content-heavy screens where every vertical point counts, while your settings or tool-laden screens can keep the bar pinned right where it is. There’s a companion safe-area API too, which decides whether your content slides up into the space that minimized bar leaves behind.

navigationItem.barMinimizeBehavior = .onScrollDown
navigationItem.barMinimizationSafeAreaAdjustment = .enabled

Bar Button Visibility Priority

Docs

You can now rank your bar button items, so UIKit knows which actions to hang onto longest when space gets tight. Think iPad, Stage Manager, toolbars, resizable windows, FOLDABLES, — anywhere the available bar width is a moving target. The important stuff you tagged sticks around, and the rest dips out.

saveItem.visibilityPriority = .high
shareItem.visibilityPriority = .standard
printItem.visibilityPriority = UIBarButtonItemVisibilityPriority(lowerThan: .standard)

Removed Bar Button Padding

Docs

Does exactly what it says on the tin — strips the default outer padding off a UIBarButtonItem. I guess this one would be handy when your custom bar button view already brings its own inherent spacing, or you just need things to line up a bit tighter. Just keep an eye on your touch targets, the golden 44 point rule applies:

let colorItem = UIBarButtonItem(customView: colorSwatch)
colorItem.isPaddingRemoved = true

Scenes, Windows & Orientation

Apple keeps marching toward a multi-window, resizable, scene-everywhere world, and…yeah, forget it. Because of the foldable that’s coming, that’s why. To wit, device hub makes all of this quick to test out.

Scene Closure Confirmation

Docs

Ever close a window and immediately wish you hadn’t? This lets your app throw up a system confirmation before a scene actually closes, mimicking how several web apps work today. It’s made for multi-window document, editing, or workflow-ish type apps — basically anywhere slamming a window shut could toss out unsaved work or cut off something mid-flight.

windowScene.closureConfirmation = UISceneClosureConfirmation(
    title: "Unsaved Changes",
    message: "Save before closing this window?",
    actions: [
        UIAlertAction(title: "Save and Close", style: .default) { _ in saveDocument() },
        UIAlertAction(title: "Discard Changes", style: .destructive) { _ in discardChanges() }
    ]
)

External Display Scene Accessories

Docs

A view controller can now register a secondary, noninteractive scene built for an external display. Looking at the docs, I think this would be cool for auxiallary presentation screens, dashboards, reference views, or any companion output you’d want to toss up on a connected display where touch input isn’t always required:

let configuration = UISceneConfiguration(name: "Presenter Display")
let accessory = UISceneAccessory.externalNonInteractive(sceneConfiguration: configuration)

let registration = registerSceneAccessory(accessory)
registration.isEnabled = registration.isAvailable

Per-Scene Supported Orientations

Docs

Each window scene can now declare its own supported orientations. So in a multi-window app, your video scene can stay locked to landscape while the browsing or editing scene happily rotates whichever way it likes. This flexibility is great, as I’ve had several times where one-size-fits-all orientation rules didn’t quite apply for the whole app:

func supportedInterfaceOrientations(
    for windowScene: UIWindowScene
) -> UIInterfaceOrientationMask {
    .landscape
}

Tab Bars & Sidebars

The tab bar and sidebar duo (the latter of which ditched the design from iOS 26 i loved 😢) picked up some welcome controls for steering which one shows up, and what gets the spotlight.

Prominent Tab Selection

Docs

Got one tab that matters more than the others? A UITabBarController can now crown a single tab as visually prominent — perfect for a headline action like compose, search, cart, create, or record:

tabBarController.prominentTabIdentifier = "compose"
tabBarController.setProminentTabIdentifier("inbox", animated: true)

Sidebar Preferred Placement

Docs

When only one can win, this lets a tab bar controller say whether it’d rather show up as a sidebar or a tab bar. It’s great for apps that are sidebar-first at heart, but still need to fold down gracefully to a tab bar on more compact devices or…whatever, you know at this point. I’d assume foldables:

tabBarController.mode = .tabSidebar
tabBarController.sidebar.preferredPlacement = .sidebar

Batching Tab Bar Updates

Docs

Changing a whole bunch of tab stuff at once — badges, images, ordering, prominent state — and want to dodge the flicker? Batch it. UIKit folds all of those changes into a single update pass instead of grinding through a separate layout pass for each one.

tabBarController.performBatchUpdates {
    tabBarController.tabs[0].badgeValue = "3"
    tabBarController.tabs[1].image = UIImage(systemName: "star.fill")
    tabBarController.setProminentTabIdentifier("favorites", animated: false)
}

Sidebar Availability Tracking

Docs

A simple read on whether your tab/sidebar interface actually has a sidebar available at the moment. It’s handy for adjusting your supporting UI when that sidebar slides in or out thanks to a size class change, a rotation, or a window resize.

func tabBarController(
    _ tabBarController: UITabBarController,
    sidebarAvailabilityDidChange sidebar: UITabBarController.Sidebar
) {
    tabBarController.navigationItem.leftBarButtonItem = sidebar.isAvailable ? nil : menuButton
}

Bonus Points

And, as always, then there’s the usual grab bag. Here are a few odds and ends that didn’t fit tidly into the stuff above, but are worth a look all the same.

Menu Image Visibility

Docs

Menu elements can now explicitly ask for their images to be shown, hidden, or simply left up to the system. Lean on it when the icon is the information — color swatches, say — or hide them away when icons would only add noise to an otherwise text-heavy menu.

let red = UIAction(
    title: "Red",
    image: UIImage(systemName: "circle.fill"),
    preferredImageVisibility: .visible
) { _ in applyColor(.systemRed) }

let reset = UIAction(
    title: "Reset Formatting",
    image: UIImage(systemName: "textformat"),
    preferredImageVisibility: .hidden
) { _ in resetFormatting() }

Document Launch Screen Subtitle

Docs

I mean…why not? Subtitles!

let launchOptions = UIDocumentViewController.LaunchOptions()
launchOptions.subtitle = "Create and edit presentations"

let documentViewController = UIDocumentViewController(launchOptions: launchOptions)

Final Thoughts

A few years ago, I wondered if UIKit would be deprecated altogether. That would’ve been drastic, sure, but I did wonder. These days, I don’t share the same concern anymore. SwiftUI gets better each year, and yeah — it’ll have top billing. But UIKit is solid, and it appears to be a core part of Apple’s strategy into the future.

Not much changed this year, and not much was added that’s flashy. But, that’s true of iOS 27 in several ways. This year, it’s about getting Siri right, and I think that’s the right move.

Until next time ✌️

Tern up for what! They’ll never Ternus against each other! Okay. Sorry. I’m done now. But it is that time…

The 12th annual Swiftjective-C pregame quiz is here!

This year, I’m rolling with (mostly) 2026 news, updates, and shenanigans. No “Objective-C without the C” questions, or Steve Notes, or other Swiftjective-C staples of year’s past. This edition is all about stuff Cupertino & Friends™️ have shipped, announced, clarified, regulated, re-org’d or otherwise made us all read release notes about this year.

If you want to warm up first, you’ve got eleven years of quiz backlog to spelunk through:

WWDC 2015

WWDC 2016

WWDC 2017

WWDC 2018

WWDC 2019

WWDC 2020

WWDC 2021

WWDC 2022

WWDC 2023

WWDC 2024

WWDC 2025

WWDC 2026

Ground Rules

There are three rounds, and the point break down is as follows:

• Round 1 - 1 point each answer
• Round 2 - 2 points each answer
• Round 3 - 3 points each answer

The last question of each round is an optional wildcard question. Get it right, and your team gets 4 points, but miss it and the team will be deducted 2 points.

Nothing says pre-W.W.D.C. vibes quite like reading support docs, release notes and regulatory compliance copy. With that, let’s emotionally process App Store Connect together.

This year’s spring product and tooling cycle was inspired by…The Matrix? Let’s see who read the footnotes!

The conference page is glowing, Apple Park attendees are afoot, and Tim Cook has a new title on deck.

Answer Key

Round 1:

1. B. The Mobile Software Competition Act. Apple says iOS 26.2 introduced the Japan changes to comply with the MSCA. 1
2. B. Guideline 1.2, User-Generated Content. Random or anonymous chat now gets pulled under that umbrella. 2
3. D. Apps in a bundle no longer need to support the same platform as the primary app for bundles created on February 17, 2026 or later. 3
4. A. The United States and Singapore. Outside those two storefronts, monthly subscriptions can now have a 12-month commitment. 3
5. Wildcard: C. Promo codes for In-App Purchases are no longer supported. Pour one out for the old tiny-code economy. 3

Round 2:

1. C. 256GB. The 17e starts with double the previous generation’s entry storage. 4
2. C. A18 Pro. Yes, the footnote really does say preproduction MacBook Neo systems with Apple A18 Pro. 5
3. D. N1 and C1X. Wi-Fi 7, Bluetooth 6, Thread and cellular modem trivia all in one tidy pair. 6
4. C. Sage. Apple lists MacBook Neo in silver, blush, citrus and indigo, which means Sage is the very tasteful impostor. 5
5. Wildcard: A. A lime and a lemon. Sometimes product marketing is just a tiny citrus FaceTime call on main. 7, 8

Round 3:

1. A. San Pedro Square Market. The 2026 pre-W.W.D.C. community gathering listing puts the ritual right at 87 N San Pedro St, patio and all. 13
2. B. Weezer. W.W.D.C. 2019’s Bash at Discovery Meadow featured the multi-platinum alt-rock heroes themselves. 9
3. A. A mechanical feeding arm controlled with head movements. Ternus’s Penn senior project was built for people with quadriplegia, which is vastly more interesting than another succession answer. 10
4. C. genai.apple.com. A dormant Apple subdomain with “genai” in the name is exactly the kind of nothing that becomes pre-W.W.D.C. something. 11
5. Wildcard: C. Spatial Computing. It sounds like it should be a category, but the 2026 list is Delight and Fun, Inclusivity, Innovation, Interaction, Social Impact, and Visuals and Graphics. 12