![\"Xcode](\"../assets/images/UIKit2026_1.jpg\")
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.
\n\nThat stuff is obvious. But, what about your app?
\n\n“Hey Siri, what team did I last make a play for in Elite Hoops?”
\n\nHow 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.
\n\nlet concatenatedThoughts = \"\"\"
\nThis 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.
\n\"\"\"
\nFirst 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.
\n\nFirst, 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 {\n static var defaultQuery = TeamEntityQuery()\n static var typeDisplayRepresentation: TypeDisplayRepresentation = .init(stringLiteral: \"Team\")\n \n var displayRepresentation: DisplayRepresentation {\n DisplayRepresentation(title: \"\\(name)\",\n subtitle: \"\\(rosterSize) \\(rosterSize == 1 ? \"player\" : \"players\")\",\n image: DisplayRepresentation.Image(data: logo))\n }\n \n let id: String\n \n @Property(title: \"Team Name\")\n var name: String\n \n @Property(title: \"Roster Size\")\n var rosterSize: Int\n \n @Property(title: \"Roster\")\n var roster: [String]\n}\nFrom 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 {\n func entities(matching string: String) async throws -> [TeamEntity] {\n Logs.appIntents.info(\"TeamEntityQuery: String query for term \\(string)\")\n \n guard let dao = DAO.readOnly else {\n Logs.appIntents.info(\"There is no database available for the intent to read from.\")\n return []\n }\n \n let courts = try await dao.fetchCourtsBy(name: string)\n let entities: [TeamEntity] = try await TeamEntity.fetchData(for: courts)\n return entities\n }\n}\nMore 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 {}\nIn 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.
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.
\n\nYou do so by using a property wrapper above your entity declaration:
\n\n@AppEntity(schema: .messages.message)\nstruct MessageEntity: IndexedEntity {\n // The text content of the message\n @Property(indexingKey: \\.textContent)\n var body: AttributedString?\n}\n…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.
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:
\n\nNSUserActivity: The tried and true API around, since what — iOS 8?, can help with singular content. For example, a photo.
View annotations API: Use this when you’ve got more than one singular thing that’s presented, like a list of stuff.
\nTogether, 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 {\n let practice: Practice\n\n var body: some View {\n VStack {\n StuffAndThings()\n PracticeContainer()\n .userActivity(\"com.example.elitehoops.practice\", \n element: practice.asEntity()) { entity, activity in\n activity.title = practice.title\n activity.appEntityIdentifier = .init(for: entity)\n }\n }\n }\n}\nAnd for view annotations:
\n\nstruct MyPractices: View {\n let practices: [Practice]\n\n var body: some View {\n ForEach(practices) { p in \n PracticeView(practice: p)\n .appEntityIdentifier(\n EntityIdentifier(\n for: PracticeEntity.self,\n identifier: p.id\n )\n )\n }\n }\n}\nFinally, 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:
\n\nstruct ContactEntityQuery: IntentValueQuery {\n func values(for input: [IntentPerson]) async throws -> [ContactEntity] {\n let names = input.map(\\.displayName)\n let descriptor = FetchDescriptor<Contact>()\n let contacts = try model.mainContext.fetch(descriptor)\n let matches = contacts.filter { contact in\n names.contains(where: { name in\n contact.name.localizedStandardContains(name)\n })\n }\n return matches.map(\\.entity)\n }\n}\nHowever, 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:
\n\nextension TeamEntity: Transferable {\n static var transferRepresentation: some TransferRepresentation {\n IntentValueRepresentation(\n exporting: { entity in\n IntentPerson(name: .displayName(entity.name))\n },\n importing: { person in\n ContactEntity(name: person.name.displayString)\n }\n )\n DataRepresentation(exportedContentType: .utf8PlainText) { entity in\n entity.teamSummaryText().data(using: .utf8) ?? .init()\n }\n }\n}\nSo, 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.
\n\nNew 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.
\n\nUntil next time ✌️
", "summary": "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.", "image": "https://swiftjectivec.com/assets/images/logo.png", "date_published": "2026-06-15T00:00:00-05:00", "date_modified": "2026-06-15T00:00:00-05:00", "author": { "name": "Jordan Morgan"}, "tags": ["Siri"]},{ "id": "https://swiftjectivec.com/iOS-27-Notable-UIKit-Additions", "url": "https://swiftjectivec.com/iOS-27-Notable-UIKit-Additions/", "title": "iOS 27: Notable UIKit Additions", "content_html": "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:
\n\n
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.
\n\n![\"Code](\"../assets/images/UIKit2026_3.jpg\")
It used to take so much more work!
\n\nThere’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:
\n\n![\"Xcode](\"../assets/images/UIKit2026_2.jpg\")
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.
\n\nIf 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.
\n\nlet concatenatedThoughts = \"\"\"
\nLooking for the header diffs? Kyle Howells posted them here.
\n\"\"\"
\nThe 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!?
\n\nEach 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.
\n\nnavigationItem.barMinimizeBehavior = .onScrollDown\nnavigationItem.barMinimizationSafeAreaAdjustment = .enabled\nYou 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.
\n\nsaveItem.visibilityPriority = .high\nshareItem.visibilityPriority = .standard\nprintItem.visibilityPriority = UIBarButtonItemVisibilityPriority(lowerThan: .standard)\nDoes 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)\ncolorItem.isPaddingRemoved = true\nApple 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.
\n\nEver 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.
\n\nwindowScene.closureConfirmation = UISceneClosureConfirmation(\n title: \"Unsaved Changes\",\n message: \"Save before closing this window?\",\n actions: [\n UIAlertAction(title: \"Save and Close\", style: .default) { _ in saveDocument() },\n UIAlertAction(title: \"Discard Changes\", style: .destructive) { _ in discardChanges() }\n ]\n)\nA 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:
\n\nlet configuration = UISceneConfiguration(name: \"Presenter Display\")\nlet accessory = UISceneAccessory.externalNonInteractive(sceneConfiguration: configuration)\n\nlet registration = registerSceneAccessory(accessory)\nregistration.isEnabled = registration.isAvailable\nEach 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:
\n\nfunc supportedInterfaceOrientations(\n for windowScene: UIWindowScene\n) -> UIInterfaceOrientationMask {\n .landscape\n}\nThe 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.
\n\nGot 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\"\ntabBarController.setProminentTabIdentifier(\"inbox\", animated: true)\nWhen 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:
\n\ntabBarController.mode = .tabSidebar\ntabBarController.sidebar.preferredPlacement = .sidebar\nChanging 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.
\n\ntabBarController.performBatchUpdates {\n tabBarController.tabs[0].badgeValue = \"3\"\n tabBarController.tabs[1].image = UIImage(systemName: \"star.fill\")\n tabBarController.setProminentTabIdentifier(\"favorites\", animated: false)\n}\nA 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.
\n\nfunc tabBarController(\n _ tabBarController: UITabBarController,\n sidebarAvailabilityDidChange sidebar: UITabBarController.Sidebar\n) {\n tabBarController.navigationItem.leftBarButtonItem = sidebar.isAvailable ? nil : menuButton\n}\nAnd, 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.
\n\nMenu 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.
\n\nlet red = UIAction(\n title: \"Red\",\n image: UIImage(systemName: \"circle.fill\"),\n preferredImageVisibility: .visible\n) { _ in applyColor(.systemRed) }\n\nlet reset = UIAction(\n title: \"Reset Formatting\",\n image: UIImage(systemName: \"textformat\"),\n preferredImageVisibility: .hidden\n) { _ in resetFormatting() }\nI mean…why not? Subtitles!
\n\nlet launchOptions = UIDocumentViewController.LaunchOptions()\nlaunchOptions.subtitle = \"Create and edit presentations\"\n\nlet documentViewController = UIDocumentViewController(launchOptions: launchOptions)\nA 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.
\n\nNot 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.
\n\nUntil next time ✌️
", "summary": "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.", "image": "https://swiftjectivec.com/assets/images/logo.png", "date_published": "2026-06-08T00:00:00-05:00", "date_modified": "2026-06-08T00:00:00-05:00", "author": { "name": "Jordan Morgan"}, "tags": ["UIKit"]},{ "id": "https://swiftjectivec.com/WWDC-2026-The-Pregame-Quiz", "url": "https://swiftjectivec.com/WWDC-2026-The-Pregame-Quiz/", "title": "W.W.D.C. 2026: The Pregame Quiz", "content_html": "Tern up for what! They’ll never Ternus against each other! Okay. Sorry. I’m done now. But it is that time…
\n\nThe 12th annual Swiftjective-C pregame quiz is here!
\n\nThis 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.
\n\nIf you want to warm up first, you’ve got eleven years of quiz backlog to spelunk through:
\n\n![\"WWDC](\"../assets/images/dd2015.png\")
\n ![\"WWDC](\"../assets/images/dd2016.png\")
\n ![\"WWDC](\"../assets/images/dd2017.png\")
\n ![\"WWDC](\"../assets/images/dd2018.png\")
\n ![\"WWDC](\"../assets/images/dd2019.png\")
\n ![\"WWDC](\"../assets/images/dd2020.png\")
\n ![\"WWDC](\"../assets/images/dd2021.png\")
\n ![\"WWDC](\"../assets/images/dd2022.png\")
\n ![\"WWDC](\"../assets/images/dd2023.png\")
\n ![\"WWDC](\"../assets/images/dd2024.png\")
\n ![\"WWDC](\"../assets/images/wwdc2025.jpg\")
\n ![\"WWDC](\"../assets/images/wwdc2026.jpg\")
\n There are three rounds, and the point break down is as follows:
\n\nThe 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.
\n\nNothing 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.
\n\n\n\n\n\n\n\n\n\n\n\nThis year’s spring product and tooling cycle was inspired by…The Matrix? Let’s see who read the footnotes!
\n\n\n\n\n\n\n\n\n\n\n\nThe conference page is glowing, Apple Park attendees are afoot, and Tim Cook has a new title on deck.
\n\n\n\n\n\n\n\n\n\n\n\n👉
\n\n👈
\nW.W.D.C. Pregame Quiz
\nScore
\n\n 0\n /36\n
\nCorrect
\n0/15
\nMissed
\n0
\nRound 1:
\n\nRound 2:
\n\nRound 3:
\n\nThis 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.
\n\nCupertino & 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.
\n\nIn the world of 2026, here’s what I’d love to see:
\n\nIn short, I hope Apple helps me do two things: adopt the latest APIs, and do that quickly. All of the above would help.
\n\nCode 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.
\n\nUntil next time ✌️
", "summary": "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.", "image": "https://swiftjectivec.com/assets/images/logo.png", "date_published": "2026-05-16T00:00:00-05:00", "date_modified": "2026-05-16T00:00:00-05:00", "author": { "name": "Jordan Morgan"}, "tags": ["The Indie Dev Diaries"]},{ "id": "https://swiftjectivec.com/Along-the-Way", "url": "https://swiftjectivec.com/Along-the-Way/", "title": "Along the Way", "content_html": "Do you know Adam Tow?
\n\nIf 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.
\n\nOr, 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.
\n\n…and I, of course, could go on. So many great talks, and even better people.
\n\nThis 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:
\n\n![\"Image](\"../assets/images/ut_3.jpeg\")
\n ![\"Image](\"../assets/images/ut_2.jpeg\")
\n 🥹 They grow up so fast!
\n\nAnd, 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.
\n\nThis 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.
\n\n![\"WWDC](\"../assets/images/ut_1.jpeg\")
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.
\n\nAnd, 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.
\n\nWhere was I going with this again?
\n\nOh 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.
\n\nUntil next time ✌️
", "summary": "Do you know Adam Tow?", "image": "https://swiftjectivec.com/assets/images/logo.png", "date_published": "2026-04-15T00:00:00-05:00", "date_modified": "2026-04-15T00:00:00-05:00", "author": { "name": "Jordan Morgan"}, "tags": ["The Indie Dev Diaries"]},{ "id": "https://swiftjectivec.com/Kids-and-Vibe-Coding-iOS-Apps", "url": "https://swiftjectivec.com/Kids-and-Vibe-Coding-iOS-Apps/", "title": "Kids and Vibe Coding: The Joy of Building", "content_html": "Ah, the joy of building. Lately, my kids have acquired the bug. Now that they are a bit older, they’ve started to somewhat realize what I’m doing all day long, hunched over a brightly lit laptop — pecking away on a keyboard.
\n\nClick clack, clack clack, click click….boom, I made something. An app appears, and now they are at the age where they can comprehend that. And, well, they think that is amazing.
\n\nAnd thus, I’ve started to dip into the realm of kids and vibe coding. At first, I had an outline with something to say on this topic. But, you know what, I just threw it out. Both of my oldest kiddos, Benny (12) and Remy (9), have asked me to help them “make an app”, and we’ve had a blast.
\n\nWhat follows are just random observations in no particular order.
\n\nWhat even is an app to a kid? To them, anything entirely web-based for the whole experience is not an app (I raised them right!), and they were even surprised you could charge money on the web!
\n\nBut, we all start somewhere. And, to that end, they’ve both taken completely different approaches to deciding where they should start. Remy, ever the analytical thinker among my kids, opted to spec it out. Benny? Two sheets to the wind, he just opened up Codex and let it rip. Which leads me to my first observation…
\n\n…and it’s somewhat endearing at the same time. Seeing Remy hunched over the keyboard, pecking away on one hand:
\n\n![\"Remy](\"../assets/images/remy_tcg1.jpg\")
…just tossing Codex the most open-ended instructions imaginable:
\n\n![\"An](\"../assets/images/remy_tcg2.jpg\")
So many questions! What kind of app? Which platform? FIVE BUCKS? We using StoreKit for this, what about paywalls? The seasoned engineer in me reeled, but I wanted them to hit as many bumps and learn how to work around them as they could. Even then, though, they do get “Dad Assists” here and there. And, Remy used his to kickstart his project:
\n\n![\"A](\"../assets/images/remy_tcg3.jpg\")
In this case, I mentioned he might want to say what kind of app it is, punt the money stuff for now, and hint to the LLM which general direction we’re taking things (iOS, minimum target is likely iOS 26).
\n\nWriting prompt cleanups have been fantastic learning and bonding moments. We get to briefly talk about why I wrote something the way I did, I try to gently explain how an LLM works, what they’re good at, what they’re not as good at, etc.
\n\nTo that end, their prompts have improved. But even then…
\n\n…these apps are brutal right now. Remy’s has, like, three search functions - all doing different things. I mean, check this number out:
\n\n![\"Remy's](\"../assets/images/remy_tcg4.jpg\")
It’s easy for us to spot the issues. However, the bit that’s surprised me, though, is that they are…aware of it? Even as a 9 year old. Is this a potential byproduct of growing up in the digital age? They know it doesn’t feel right, and they can’t really say why yet, they just know it feels off.
\n\nThat’s hardly surprising, as design and user experience are things that take years and years to develop.
\n\nThe fact that they now live in a world where they can type in a box and get something working has, quite literally, ignited their creativity, curiosity, and excitement. The boys are huge fans of neal.fun, especially his fantastic auction game:
\n\n![\"neal.fun's](\"../assets/images/remy_tcg5.jpg\")
Remy, unshackled with unimaginable power at his disposal, immediately u-turned on a bug fix and just threw that at Codex and instructed it to add a Pokemon card version in his app. And, it came pretty close one-shotting it:
\n\n![\"Remy's](\"../assets/images/remy_tcg7.jpg\")
This is the good stuff. Being able to think of something fun and have it come to life. It’s the same dopamine hit you get from building with legos, finishing a picture, or generally constructing a thought and turning it into something tangible. While it’s silly in this context, these are the moments that will inspire them to continue.
\n\nThe one ephiphany I’ve had with all of this (aside from how insane it is that my kids can get a functioning app working) is that the skills we have are magnified now, perhaps more than ever. We’ve all been so uneasy about the implication of “anyone can make an app”, we haven’t stopped much to consider that our hard-earned skills are still the thing that makes a good app.
\n\nYou can throw all the skill files you want at an LLM (And you should! They’re great!), but they still have critical limitations. Take text, for example. What would you instinctively do if you have a view whose text was truncated, clipping, or otherwise not fitting into a container?
\n\nThe layman would say, “Can you make this text not clip?” The hardened iOS veteran might say, “Apply a .minimumScaleFactor modifier to this text, and ensure you’re using a Text style and not hard coding the font size.”
\n\nOff the cuff? Visually, you may get the same result at first. But, well — if you know, you know. One is objectively better. And those of us who can speak the language will still be making the best apps. The same skills still win, as I mentioned before, the tools have simply changed. It does, however, highlight my one lingering worry: That the next generation my take an ignorance through obstinance stance towards coding. If the ease of it all could tempt a kid (or anyone) to never bother learning how something truly works, they’d be missing out on some required skills.
\n\nWhile the kids have been using Codex, I think I’d opt to stick them in Bitrig’s nascent mac app. It’s a bit more harnessed, in a good way, and I think the results would be a little better. The app Anything spun something up quick, in Expo. With Codex, I have a ton of credits, so we’ve stuck with that. Personally? I prefer Codex for coding anyways, especially since they put a frontend on top of the CLI. If it becomes a native mac app, I’ll probably never close it.
\n\nBut for them? I can’t stop thinking about how a Macbook Neo with Bitrig would be a fun addition to the Morgan family. You kinda sorta need to make sure these kids don’t blow up your house with this stuff, which, well, depending on your permissions — could certainly happen.
\n\nReflecting on the vibe coding experiences with the kids, I only have one prevailing thought: we are all having so much fun. The kids are becoming increasingly interested in what their dad actually does for a career now. Remy, especially, is getting into it. He’s developed the ineluctable urge to make something. The last two days he has come home from school, it’s “Dad, can I work on my app!?” He even stuck some post-it notes to his closet so he wouldn’t forget what to work on the next day:
\n\n![\"Month](\"../assets/images/remy_tcg6.jpg\")
Until next time ✌️
", "summary": "Ah, the joy of building. Lately, my kids have acquired the bug. Now that they are a bit older, they’ve started to somewhat realize what I’m doing all day long, hunched over a brightly lit laptop — pecking away on a keyboard.", "image": "https://swiftjectivec.com/assets/images/logo.png", "date_published": "2026-04-08T00:00:00-05:00", "date_modified": "2026-04-08T00:00:00-05:00", "author": { "name": "Jordan Morgan"}, "tags": ["A.I."]},{ "id": "https://swiftjectivec.com/The-Abstraction-Layer", "url": "https://swiftjectivec.com/The-Abstraction-Layer/", "title": "The Abstraction Layer", "content_html": "When I first began my degree in the field of CompSci, I picked up a book: “Code”, by Charles Petzold. I don’t distinctly remember if it necessarily changed my life or sparked my love of software development. But, I remember with certainty that it did give me the gift of curiosity.
\n\n![\"Code](\"../assets/images/code_cp.png\")
What was actually happening when I was typing in Visual Basic on some Windows desktop in a computer lab at Ozarks Technical Community College? How did the characters transform and…just…do stuff? I wanted to know, and that book went in on it all. I remember learning about how every computer begins with simple, basic physical states: on and off. Open, and closed. And, of course, 1 or 0.
\n\nFrom there, those binary states can be represented by all sorts of interesting modes: switches, relays, and then transistors. Building on that some more, wire enough of them together and now we get to the interesting stuff. Logic gates, adders, memory, clocks, and eventually down the line — a CPU that can read instructions from memory! And, execute them!
\n\nBut in my day to day? That’s all abstracted away from me, as it should be. It’s just as well, though, since abstractions have long been a core part of our indsutry. In fact, who remembers interviews in the aughts when object orientated programming was king? We had to remember our favorite acronym, A.P.I.E. — abstraction, polymorphism, inheritance, and encapsulation. So, in that sense, code has long been an abstraction layer. It’s one that sits comfortably above the raw hardware, but it’s close enough that, after enough of said translation, it can still make silicon do something real and tangible in the world.
\n\nI’ve been thinking a lot about abstraction layers lately.
\n\nWhat the “abstraction” layer is now, and how we define it, is changing. And, naturally, it has me wondering. With the rise of agentic engineering, I’ve started to consider something I thought impossible only a few years ago:
\n\nIs code going to be abstracted away, entirely, soon?
\n\nAnd, yeah, I realize the word “soon” is doing some heavy lifting here.
\n\nOnce the frontier models improve, how soon until it matters if you read what it outputs? No, seriously, I’m wondering that lately. I know, I know — I KNOW — it’s not there yet. Today. But, I think eventually, it will be. And what does that mean for software engineering? Is it then prompt engineering? Will knowing how the all the pieces fit together matter even more, or less?
\n\nHow much longer is understanding code a competitive advantage? I know it certainly is today. And, lest I’m not making my stance clear enough, you do need to understand code to succeed in my opinion. In 2026, most of us in this field grew up figuring out its intimate inner workings. That’s why those with years of experience are currently building software at a blistering pace. Though, how long will it keep us ahead of everyone else? Because when it becomes abstracted away, well — that’s a different world we’ll live in.
\n\nlet concatenatedThoughts = \"\"\"
\nOf course, we will always need people in the world who understand code. In the same way that we need people in the world who have a professional, expert knowledge of how computers actually work. We can't afford to lose that, obviously, because when one machine drives another — both machines will always need a captain.
\n\"\"\"
\nI’m pondering here, not panicking. We need to remember that abstraction layers are not inherently bad. In fact, by most measures, not only are they incredibly useful — they are necessary. I don’t want to manually tweak logic gates. I want to write code to do it. Years ago, there was undoubtedly a time where writing code woud seem as outlandish as using a chat interface to produce that same code for you.
\n\nNaturally, as the future progresses and technology advances, making software will look different, too. The future of software engineering versus “AI does it all” hopefully will not be a zero-sum game. More abstraction does not automatically mean we need less understanding, but I think it does most likely change “what” is important to understand.
\n\nI don’t know the answer, and to be honest — I’m not scared of the answer, either. I’ve made my way in this industry by being curious. People like to say it’s all changing so fast, and there’s an inordinate amount of AI tooling, advances, or models to learn. I say it’s always been that way. I’ve done well in this career because of adapting to changes. By wondering how logic gates, bits and bytes, and code eventually create a piece of software I made. And whatever the tools and technology become to keep creating those things well and with precision, I’ll keep learning.
\n\nWhen I went back to speak at my community college years ago, I told the prospective students that the only constant in our industry is change. Now, I suppose, never has that been more apt.
\n\nUntil next time ✌️
", "summary": "When I first began my degree in the field of CompSci, I picked up a book: “Code”, by Charles Petzold. I don’t distinctly remember if it necessarily changed my life or sparked my love of software development. But, I remember with certainty that it did give me the gift of curiosity.", "image": "https://swiftjectivec.com/assets/images/logo.png", "date_published": "2026-03-20T00:00:00-05:00", "date_modified": "2026-03-20T00:00:00-05:00", "author": { "name": "Jordan Morgan"}, "tags": ["A.I."]},{ "id": "https://swiftjectivec.com/Agentic-Coding-Codex-Claude-Code-in-Xcode", "url": "https://swiftjectivec.com/Agentic-Coding-Codex-Claude-Code-in-Xcode/", "title": "Agentic Coding in Xcode 26.3 with Claude Code and Codex", "content_html": "I was filled with whimsy watching OpenAI announce their Codex app1 not even two days ago. But life comes at you fast. The very next day, Xcode 26.3 dropped with support for agentic coding.
\n\nAs someone who is truly enjoying using agents to create software, I was ready to dive in. I’ve come to love using agents in Terminal, but I’m always up to try the shiny new thing. And if there’s something Apple does particularly well, it’s typically integrating new shiny things with a refined taste to them.
\n\nHere, I’ll share first impressions, and some important answers to questions I had. Also, I’ll be primarily chatting through the Codex lens.
\n\nAsk three different people how they use agents, and somehow you’ll get sixteen different answers. Me? I rely on the “core pillars”:
\n\nagents.md or claude.md file. Critical to how I work.If Xcode’s integration couldn’t leverage any one of these, I would personally have no reason to use it. I nearly moved on altogether since I realized the star of the show, Apple’s own Xcode MCP implementation, is available for other agents to use:
\n\n# CC:\nclaude mcp add --transport stdio xcode -- xcrun mcpbridge\n\n# Codex:\ncodex mcp add xcode -- xcrun mcpbridge\nStill, the allure of keeping things “in house” is strong. And, Apple is only going to improve their offering. As long as my core pillars were usable, I’d try it out. At first, I thought that wasn’t the case (my skills weren’t showing, for example) but I’m happy to report that it can, and does, use your existing “core pillars” with a little pageantry from your end.
\n\nHere’s what made it all click for me. If you already have Codex installed, think of Xcode’s Codex usage as an entirely fresh install. That makes complete sense when you zoom out and think about it (this Codex is literally for Apple development and nothing else). You can confirm this for yourself by viewing the config.toml for each installation:
![\"Image](\"../assets/images/agentic_apple.jpg\")
\n ![\"Image](\"../assets/images/agentic_mine.jpg\")
\n Apple has honed in their config.toml to supercharge iOS development. Notes on Liquid Glass, call outs for Foundation Models — the list goes on. Though Apple blasts the doors off of their “big” stuff at W.W.D.C., you’d be crazy to think they aren’t paying attention. How we develop software is changing, and internally, it’s clear they are humming along with it. The fact that Xcode 26.3 exists, right now, is proof. They didn’t just cut a new branch once Codex’s macOS app shipped.
A few thoughts on the core pillars:
\n\nIn Apple’s documentation, they hint that each agentic option is customizable. But to what end, it’s not entirely clear:
\n\n![\"Month](\"../assets/images/agentic_docs.jpeg\")
However, opening that up reveals a lot:
\n\n![\"Month](\"../assets/images/agentic_fp.jpeg\")
A skills folder! I simply copied what I had in my existing ~/.codex/skills over there, and I could confirm that Xcode’s Codex could now see them:
![\"Month](\"../assets/images/agentic_skills.jpeg\")
Since we know where the config.toml is at, moving over MCPs should not be a problem, either. Just add them in Apple’s config.toml and you’ll be good to go. What I’m not entirely sure about is how to kick off authentication for some MCPs that may require it. For example, to get Supabase working in Codex, I’d run codex mcp login supabase — but it needs to be ran out of session. But, there is no “out of session” in this case. It may just work, but I’ve not tried it yet.
There’s nothing to say here, it just works.
\n\nSo, how is the actual experience? Well, pretty nice! This is such a tiny thing, but in Terminal — removing a chunk of text sucks. I’m sure there is some keyboard shortcut I’m missing, or some other app I could use like iTerm or what have you, but not being able to use Command+A and then delete a text selection hurts. In Xcode, that’s easily done because the input is no longer running through Terminal, it’s just an AppKit text entry control.
Oh, and it’s pretty! Apple has leaned into a bit of a bolder text for prompt creation, and the colorful “ribbon”, synonymous with Apple Intelligence, is always a joy to look at. It’s also so beautifully native. Codex’s app, while packed full of goodies, just feels…a little ugh, ya know? This surprised me, since their flagship ChatGPT is native and feels incredible to use (complete with Liquid Glass on Tahoe).
\n\nBut there are no free lunches in life. Another Codex installation, another agent to use, another spot you have to maintain skills and MCPs. Surely, the developers behind these agentic tool chains will adopt an open standard so we don’t have to worry about this. In fact, this has already been proposed by OpenAI developers for skills at least (I lost the tweet, but it’s out there).
\n\nWe don’t know which model will “win”, or if one ever will. Personally, I find the competition necessary and good for their target market, developers. I personally hope none of them win and keep pushing each other to be better. But, open standards to control all of the core pillars would be welcome. When I update one skill, I now update it in three different places.
\n\nThis is a fantastic start for Xcode. If you’re late to the Claude Code or Codex scene, this is a wonderful place to start. There’s simply no going back once you learn how to use these tools. Ideas that you wanted to hack on become doable, those dusty side project folders come alive a bit more, and you get ideas out of your head much faster. These are all good things.
\n\nPlus, it makes you wonder what Apple will have for us at this year’s W.W.D.C. — this release is the kind of thing you typically see there. Maybe they felt they had to respond earlier? Maybe it was just ready to go? Maybe they have #EvenMoreCoolThings coming? I dunno, but I’m eager to see.
\n\nIt’s all moving quickly. All the way back in 2020, Mattt sort of saw some of this coming. It’s fun to read that post back, and see how so much of it is happening today. What a time to build!
\n\nUntil next time ✌️
\n\nKind of odd that it’s Electron though, yeah? The ChatGPT flagship app is native, and it feels fantastic in comparison. ↩
\nFirst, let me get straight to it:
\n\nThe Best-in-Class iOS App Book Series is now pay what you want! Pick it up for a minimum of $10 to…whatever you want. Live now!
\n\nI debuted this book series many years ago now, back in 2021!
\n\n\n\n🚀A Best-in-Class App: The Book 🚀
— Jordan Morgan (@JordanMorgan10) February 16, 2021
It's happening, I'm making this now!
✅ In-depth book covering accessibility, core iOS tech, design, user experience and more.
✅ A companion app
✅ Bite sized screencasts
Join the mailing list to follow along: https://t.co/Dc9AcfyUSL pic.twitter.com/S8sm1zPnNg
I had just sold my first somewhat successful app, and figured I’d set out to do what I always wanted to do: write a book series of all that I knew about making iOS apps. The craft, the APIs, the design, the “don’t sleep on this little tweak” kind of stuff.
\n\nAnd, so, I did — though it was a bit grueling.
\n\nIt took over two and a half years, and I released updates every two weeks during that time. But, like I would imagine those who finished a PhD or something, I was (and still am) extremely proud of the effort even though the effort basically swallowed me whole. I wrote over a thousand pages, hundreds of code samples, just as many image assets, kept the mailing list informed of progress, the whole gig. And since then, I’ve kept it up to date with free content drops.
\n\nWhat I couldn’t have imagined, at the time, was where we are today. Right now. The way we learn and do things, and most importantly — develop software, is changing at an unprecedented pace. AI and LLMs are changing our industry in real time. While there is certainly a place for books, YouTube tutorials, and similar content (I don’t think anybody wants those to go away) - I think the desire for a giant reference like mine is reducing a bit.
\n\nAnd that’s okay, but I also want to be realistic about things. And so, with updates slowing, I want to make it’s accessible to anyone who might want it.
\n\nI’ve also had several ideas floating around on what I could do with this content. With five, giant books full of iOS wisdom, plugging it into an LLM, custom GPT, maybe even an MCP, or putting it online digitally to highlight things, even edit it, etc — that could be fun. By far, the largest pain point is updating this thing. It takes hours to do for several reasons. An online-first home for it, with the option to download it still as it is today, would make the barrier to entry for updates much, much more doable for me.
\n\nI’m not really sure what I’ll do with it, but with over 100 updates since 2021, I’ve given this project a lot of me. I’m proud of it, and I’m also happy that whoever wanted it but couldn’t afford it, can do so now.
\n\nUntil next time ✌️
", "summary": "First, let me get straight to it:", "image": "https://swiftjectivec.com/assets/images/logo.png", "date_published": "2026-01-28T00:00:00-06:00", "date_modified": "2026-01-28T00:00:00-06:00", "author": { "name": "Jordan Morgan"}, "tags": ["The Indie Dev Diaries"]},{ "id": "https://swiftjectivec.com/The-Shift-Using-AI-As-A-Developer-Advocate-And-Engineer", "url": "https://swiftjectivec.com/The-Shift-Using-AI-As-A-Developer-Advocate-And-Engineer/", "title": "The Shift", "content_html": "It’s 2026 (in case you didn’t notice). Where have my traditional “Here’s what I did last year, here’s what I wanna do this year!” posts gone? I was able to achieve nearly all my goals in 2025 (the first time that’s happened), and I just sold Elite Soccer Club to a friend, and I’ve got huge plans for 2026!
\n\nWhy haven’t I written about any of it yet?
\n\nWell, because as a once ancient tweet once said, everything just happens so much. And in our industry, I don’t think I’ve ever witnessed so much happening.
\n\nI’ve known AI was helpful and it’s been a daily driver for me for some time now (ever the early adopter). But after seeing good ol’ Steipete and Thomas share more and more about their adventures, I started to dig in some more.
\n\nSkills, rules, plugins, MCPs, different models — I went in. And, coming out the other side, I’m not entirely certain what to think anymore. Excitement? Nervous? Pumped? All of it?
\n\nIt’s all different now, but I do know that if you were already an engineer with experience before this AI boom, there has never been a better time in human history to build stuff.
\n\nIf you knew a little about a tech stack? Well, now you know a lot.
\n\nI’ve been wondering what I am now with AI specifically. How would I describe myself? I don’t fancy myself as a vibe coder, I think we’ve attached a pejorative mindset to that term — one that won’t be shaken anytime soon. I think “Agentic Engineering” fits? Someone who knows what these things can do, and equally as important — how they could bring your house down if you don’t pay attention.
\n\nAt work, I’ve been committing more code to our monorepo, our marketing site, cruising through Next.JS and Astro codebases, all the while doing a bunch of other stuff. And, it’s simply because…now I can.
\n\nNot even a year ago, Xcode stayed open while I cherry picked work over to chatGPT. Now, I have four terminals open - managing my little LLM minions to do my bidding. Sometimes, it feels like I code review for a living. But, I’m enjoying it?
\n\nMy role has even been…impacted…if that’s the best word?, by AI. Developers are watching less YouTube tutorials and are relying on MCP servers for docs. The world is absolutely changing, and it is mind-boggling to be in it while it’s happening.
\n\nWhen your industry shifts seemingly overnight, where does that put you? You either change with it, or open a coffee bar (Dude, I would love to open a coffee bar by the way).
\n\nI think we’re all a bit on edge, to some degree. The thought that, eventually, anybody will be able to make an app is exciting and a bit scary.
\n\nThe barrier used to be building, and that barrier is diminishing. That means, logically, that the best idea, and its execution, its design and UX, how well it solves the problem - those will win more and more. That’s kinda, sorta, mostly true today, but the build aspect is still there right now. You could have the best taste, ideas on superior execution - but you might not be able to build the thing right now. That will change.
\n\nAs such, where does that leave us?
\n\nI can’t say, but I do know that this is true, right now:
\n\nIn short? Go build, and do it now! We’ve got a major head start.
\n\nUntil next time ✌️
", "summary": "It’s 2026 (in case you didn’t notice). Where have my traditional “Here’s what I did last year, here’s what I wanna do this year!” posts gone? I was able to achieve nearly all my goals in 2025 (the first time that’s happened), and I just sold Elite Soccer Club to a friend, and I’ve got huge plans for 2026!", "image": "https://swiftjectivec.com/assets/images/logo.png", "date_published": "2026-01-18T00:00:00-06:00", "date_modified": "2026-01-18T00:00:00-06:00", "author": { "name": "Jordan Morgan"}, "tags": ["A.I."]}] }