// Written by // // Read it in about 5 minutes // RE: Siri

This post is brought to you by Clerk. Add secure, native iOS authentication in minutes with Clerk’s pre-built SwiftUI components.

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.

let concatenatedThoughts = """

This is based off of having on seen this WWDC session, so I might be missing some context. Though, from what I've seen, this is where the goods are at.

"""

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

···
// Written by // // Read it in about 5 minutes // RE: UIKit

This post is brought to you by Clerk. Add secure, native iOS authentication in minutes with Clerk’s pre-built SwiftUI components.

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:

Xcode Agentic Prompting for UIKit iOS 27 Changes.

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.

Code catalog of UIKit changes in iOS27.

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:

Xcode Skill for UIKit.

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.

let concatenatedThoughts = """

Looking for the header diffs? Kyle Howells posted them here.

"""

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!?

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)

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)
}

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.

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

···
// Written by // // Read it in about 10 minutes // RE: Trivia

This post is brought to you by Clerk. Add secure, native iOS authentication in minutes with Clerk’s pre-built SwiftUI components.

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:

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.

Round 1 - App Store Paperwork Speedrun

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.

Question 1

In 2026, Apple detailed changes to iOS in Japan that created new options for developers, including alternative marketplaces and payment options. Which law are those changes designed to comply with?

Question 2

The App Review Guidelines got a February 2026 clarification that apps with random or anonymous chat are subject to which guideline?

Question 3

Before February 17, 2026, an App Store bundle had a very hall-monitor rule: every included app had to support the same platform as the primary app. For new bundles, what did Apple stop requiring?

Question 4

Apple's new monthly subscription with a 12-month commitment is basically an annual plan masquerading as a monthly sub. But, to me, that's not the oddest bit, it's the availability. Developers can offer it almost everywhere, but not in two storefronts. Which two are left out?

Wildcard

In March 2026, Apple quietly retired a tiny App Store Connect lever that developers used when they wanted to hand out a free in-app thing without creating a whole campaign around it. What went away?

Round 2 - Hardware and Tooling Side Quests

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

Question 1

iPhone 17e starts at the same $599 price as its predecessor, but Apple doubled the entry storage. What storage capacity does it start with?

Question 2

Apple's March 2026 retail update says the new fanless MacBook Neo starts at $599 and, somehow, runs on an iPhone chip. Which chip powers it?

Question 3

Hardware nerd alert question. The 2026 iPad Air with M4 brought two Apple-designed connectivity chips to the Air line. Which pair was it?

Question 4

MacBook Neo's color lineup looks like Apple put an iMac G3, some Starburst and a $599 price point in the same room. iPhone 5c vibes! Which of these is not one of the official colors?

Wildcard

Still on the Neo, Apple's marketing went fully TikTok fever dream for it: fruit, FaceTime and a laptop color called Citrus doing a lot of emotional work. And, I kinda dig it? In the clip that made r/apple take notice, which two fruits FaceTimed each other?

Round 3 - Coming Bright Up

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

Question 1

As we all converge for dub dub, there is a central rally point in San Jose where the Apple developer diaspora seems to materialize before the week kicks off. Where are the hallowed grounds where everyone first meets on Saturday, and sometimes Sunday, before W.W.D.C.?

Question 2

The last fully in-person San Jose dub dub before everything became a browser tab was W.W.D.C. 2019. At the Thursday night Bash in Discovery Meadow, which band took the stage and turned a field of badge-wearing developers into the world's most type-safe alt-rock crowd?

Question 3

Before John Ternus was demoing titanium and starring in everyone's Apple succession takes, his Penn senior project already had very Apple-coded hardware-meets-human-need feel. What did he build?

Question 4

This year's pre-W.W.D.C. tea-leaf reading has not been subtle: glowing Swift birds, Siri rings and now Apple DNS archaeology. A few weeks before the keynote, which dormant Apple subdomain kicked off another round of "oh, so it is AI season" chatter?

Wildcard

The Apple Design Awards are basically Cupertino's annual "yes, we noticed your pixels" ceremony. This year's finalists span six categories, but one of these is not on the 2026 list. Which one is the beautiful impostor?

👉

👈

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
···
// Written by // // Read it in about 1 minutes // RE: The Indie Dev Diaries

This post is brought to you by Clerk. Add secure, native iOS authentication in minutes with Clerk’s pre-built SwiftUI components.

This W.W.D.C. will probably be unlike any other. Things are going a bit wild lately, and even ardent A.I. detractors would likely concede that’s undeniably true now. The way we work compared to a year ago is drastically different. And, even six months ago? Might as well be a lifetime.

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

···
// Written by // // Read it in about 3 minutes // RE: The Indie Dev Diaries

This post is brought to you by Clerk. Add secure, native iOS authentication in minutes with Clerk’s pre-built SwiftUI components.

Do you know Adam Tow?

If not, you definitely should - he has some fantastic stories to tell. Did you know he once ran into Steve Jobs at a Sushi takeout restaurant which later led to a fairly in-depth email exchange between the two of them about the Newton? Or, that he organized a Newton protest outside of Apple? I learned all this from this recent talk at Deep Dish Swift 26’, and it was a delight.

Or, how about our favorite neighborhood alternative App Store developer Riley? He has battled Apple tooth and nail, and somehow came out on the other side. Armed with the wit and determination only found in a man who has the patience to actually make another App Store, his recount of how it was all finally approved is simply hilarious. In short, he basically gave Apple an ultimatum on which of his two apps they should accept during a long notarization process. I won’t spoil it, you should just watch the talk. Especially if you’ve ever been burned by App Review, you’ll find a little poetic justice somewhere in there.

…and I, of course, could go on. So many great talks, and even better people.

This week, I began to realize I’ve…kinda been around the iOS scene awhile now? Ya know? Like, I’m not new here anymore. If you will allow it, here’s how my oldest looked when I first started on Spend Stack, and what he looks like now:

Image 1
Image 2
Tiny Benny
Not-Tiny Benny

🥹 They grow up so fast!

And, as the years tick on, as they do for all of us, life thankfully starts to arm you with more wisdom, perspectives on life, and new angles to look at things. In an industry where, currently, everything is changing, we tend to forget the best part of any app — it’s the person behind it.

This is the primary reason I lament Apple’s modern approach to W.W.D.C. — the community is fractured at the one single time during the year when it should be united most. Going to Apple Park, I’m sure, is a fantastic experience for the few who win the lottery. Though, it’s nothing compared to when seemingly every single person in this industry was in one central place.

WWDC 2019.

AltConf going on next door, running down the halls of San Jose convention center, packed with iOS developers, designers, and Apple employees — you just can’t beat it. Every year, I plead with Apple on the developer survey to go back to this. I don’t think they ever will, though. And that’s a shame, because the relationships you formed, the people you met, the kind folks at Apple you could network with, all of those things could change the trajectory of your career. The best parts I’m talking about.

And, it’s the same still with social media. Twitter, in the before times, was a community and it felt like we were all there. Now, that’s obviously fractured too. Some are on Mastodon, others on Threads, a few kicking around on BlueSky, more still on X, etc. It’s changed quite a bit. For me? It was surreal to realize how others associate me with certain chapters of my career. Some personally know me from Spend Stack. Others, it’s the book series. Yet again, there’s more who associate me with Alyx or Elite Hoops. And, yeah, some hotshot bros know me as a vibe coder noob apparently. And honestly? I enjoy meeting every single one of them.

Where was I going with this again?

Oh yes — the people! The relationships. Events, social media, the places we can go, the way dub dub is held — all of that stuff will always change. No matter the landscape, though, I would encourage you to get around your people at least once a year if you can. Your other indie friends, the ones who work at giant companies, new kids on the scene eager to learn and show off their app. We don’t wake up and decide to start in this career just to met new people, it’s not why we do this, but it is certainly the best part.

Until next time ✌️

···