1. Design for iPhone Duo
2. Prepare your app for iPhone Duo
3. Raise the bar with iPhone Duo
4. Strike a pose with adaptive layouts on iPhone Duo
5. Leverage multiple displays and scenes on iPhone Duo
6. Build a great camera experience for iPhone Duo

And there’s some ground to cover, because it seems like this thing can contort your app’s layout about 7,000 different ways:

I’ve only watched one, and the other five are next for me to marathon, but in the interim I had Astra check out each one because I’m excited and impatient. Here’s what it thinks the critical things to know are, with the obvious caveat that this is at the discretion of an agent.

Until next time ✌️

If you need a refresher, Spend Stack was my first indie darling. It was well received among press and had a few fans over at Apple, but I never could quite figure out what exactly it was (spoiler, I still haven’t) or how to monetize it. It was originally sold around the covid-era, with a blog post from me covering the details here:

And, so it is, nearly six years later, I guess Spend Stack has a new home, again. Which is back home! For now, I’m not going to change much about it, here’s my plan:

1. This thing is old. Most of it is in Objective-C. I have Codex on a loop modernizing it now. I’ll get it buiding in a Swift-first rewrite.
2. Then, I’ll integrate modern APIs such as GRDB and CKSyncEngine.
3. I’ll make the app free (it launched as a paid up front app), with an optional $9.99/yr sub for cloud sync.
4. And once it’s stable, I’ll open it up for TestFlight.

It warms my heart that, years and years later, I’ll still get a random, out-of-the-blue Spend Stack message from someone. I don’t know where it goes from here, but I can bring it back as it once was without too much hassle in the age of agents. And, if we’ve become internet friends post-Spend Stack era, here’s most of what I wrote about it if you’d like to catch up:

• Introducing Spend Stack
• A Best In Class App: Spend Stack Checkup
• Creating a Retail Demo for Apple
• The Big Update
• Spend Stack: Year One
• A New Home for Spend Stack
• Remembering My First App
• So Long, Old Friend
• Spend Stack is Now Open Source

Here’s to new, old beginnings!

Until next time ✌️

Spoiler: we will never actually start a podcast. But, it would be fun though.

The idea of a podcast is tantilizing. I love talking shop, writing about indie life, or chatting with anyone about the ongoings of our insane vocation. And while I’ve written on this blog for years now, I do love talkin’.

So, introducing…

Short form video essays/journals/episode/talk show??? from me over indie stuff. So, MRR, web to app, how to manage time as a parent with side projects, that kind of stuff. You can watch the first episode wherever is best for you:

1. X
2. Threads
3. Instagram
4. Episode Directory

And, as linked above, I’ll keep that evergreen page up to date here with each new episode. I hope you’ll follow along, and feel free to shoot over any questions or suggestions for topics.

Until next time ✌️

1. You could be using different agents. Claude, unlike other agents, looks at its own spot for skills. Everything else uses an open standard, ~/.agents/skills.
2. Then, there’s different machines you could be running. Symlinking is great, but run npx skills update on your MacBook at home and then your MacBook on the go is now stale.
3. Each harness seems to want to funnel you into different paths for installing skills.

Is there an open standard to solve? Surely, if there is, it would have to be cloud based. For example, at Superwall, we simply have GitHub repo for proprietary, shared skills. So, I’ve adopted that same pattern for two things:

1. The skills I’ve personally made, and just as important…
2. Skills I’ve installed via Vercel’s skills.sh.

The whole process hinges on three skills: push-my-skills, pull-my-skills, and sync-npx-skills. So, uhhh, naturally - I made a Windows XP recreation to show you how the process works. You got two computers, each needing to be current on 3rd party skills from skills.sh, and my own personal ones. Click on any of the skill buttons below to see how they operate:

Here’s the technical breakdown.

For the skills that I’ve made… …one GitHub repo is the source of truth; so everything inside ~/.agents/skills is merely an installed copy. On one Mac, push-my-skills refreshes those copies, commits my changes and pushes them to GitHub in one shot. On another, pull-my-skills pulls that repo and reinstalls the same skills for every agent. Now, my personal skills are source controlled and current across machines.

But, that’s just half of it. Third-party skills actually use a shared manifest instead…

…so sync-npx-skills compares that manifest against the Mac’s last sync and its current npx lock file, determining whether a difference was made here, or on another machine. Local additions and removals are published; which means remote changes are applied so each Mac eventually converges on the same set of skills without manually copying folders around.

At this point, I have to ask: Did I solve the problem? Absolutely. Did I engineer myself into a small pyrrhic victory along the way? Also absolutely maybe yes! My hope is that an open standard arrives tomorrow, and makes all of this gloriously obsolete. Until then, at least both Macs agree on what skills they have.

Until next time ✌️

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 ✌️

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 ✌️

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 ✌️

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 ✌️

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

Cupertino & Friends™️ would do well to adapt to a rapidly changing landscape. I’m hopeful they will, too, if recent trends are any indication. We received agentic support in Xcode not long ago, something typically reserved #ForTheKeynote.

In the world of 2026, here’s what I’d love to see:

• The usual fare: Video sessions, in-depth deep dives, the works. Let’s not forget that Apple has done a fantastic job at packaging these now. Closed captions, links to demo projects, and other relevant materials are all tidy and available in the developer app. But in today’s world, stopping here would be a missed opportunity.
• Skills: Consider this — each dub dub session which presents a new API comes packaged with a skill. That would be incredible. In fact, Apple has kinda sorta already done this, but it was tucked away deep in the file system. Don’t make me poke around, link a skill with each dub dub session.
• MCP: Depending on who you ask, MCPs are amazing or terrible token wasters on their way out. Regardless, I’d love a direct, official line to Apple’s docs. For now, ex-Apple employee and NSHipter stalwart Mattt has the best solution with sosumi.
• Xcode: And, Xcode should lean into agentic engineering, whatever that looks like. I still use an IDE quite frequently, and that’s certainly true of iOS development. There is not one piece of software I could ship that hasn’t had my fingerprints on it. Little tweaks, the UI and UX, all layers I am unwilling to concede to AI.

In short, I hope Apple helps me do two things: adopt the latest APIs, and do that quickly. All of the above would help.

Code and implementation were always the time sink. They don’t have to be anymore. If using agents puts you in a state of torpor, that’s a shame. Instead, use them to get into a loop of build, review, and refine as quickly as you can so that you can make your apps the absolute best they can be. Let me stand up a working draft, and then let me make it great.

Until next time ✌️