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:

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.

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

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.

Click 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.

And 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.

What follows are just random observations in no particular order.

They have no idea what they’re doing

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

But, 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…

The prompts are just brutal

…and it’s somewhat endearing at the same time. Seeing Remy hunched over the keyboard, pecking away on one hand:

…just tossing Codex the most open-ended instructions imaginable:

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:

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

Writing 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.

To that end, their prompts have improved. But even then…

Ohhhh my, the UX

…these apps are brutal right now. Remy’s has, like, three search functions - all doing different things. I mean, check this number out:

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.

That’s hardly surprising, as design and user experience are things that take years and years to develop.

Their imagination is on steroids

The 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:

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:

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.

The skills still pay

The 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.

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

The 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.”

Off 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.

The sweet spot

While 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.

But 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.

Wrapping up

Reflecting 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:

Until next time ✌️

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.

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.

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

But 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.

I’ve been thinking a lot about abstraction layers lately.

What 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:

Is code going to be abstracted away, entirely, soon?

And, yeah, I realize the word “soon” is doing some heavy lifting here.

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

How 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.

I’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.

Naturally, 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.

I 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.

When 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.

Until next time ✌️

I was filled with whimsy watching OpenAI announce their Codex app¹ not even two days ago. But life comes at you fast. The very next day, Xcode 26.3 dropped with support for agentic coding.

As 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.

Here, I’ll share first impressions, and some important answers to questions I had. Also, I’ll be primarily chatting through the Codex lens.

The Critical Infrastructure

Ask three different people how they use agents, and somehow you’ll get sixteen different answers. Me? I rely on the “core pillars”:

1. agents.md: Projects I use all have a lightweight agents.md or claude.md file. Critical to how I work.
2. skills.md: The more nascent skills movement just keeps growing. Vercel, and its successful skills.sh initiative, has only strengthened it. I’ve come to use several skills, and not having those would be a quick stop for me.
3. MCPs: The model context protocol is amazing to interface with services. When they were first announced, I thought of them as nothing more than an API. And, in some ways, that is true. But they aren’t APIs for you or me, they are for agents. Supabase’s MCP has saved me tons of time, “Query all of the basketball drills for this User ID”, “Do I have cascade deletes in place for X or Y”, the list goes on. They are a requirement for my agent use.

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:

# CC:
claude mcp add --transport stdio xcode -- xcrun mcpbridge

# Codex:
codex mcp add xcode -- xcrun mcpbridge

Still, 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.

New Codex

Here’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:

My own config

Apple's config

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:

In Apple’s documentation, they hint that each agentic option is customizable. But to what end, it’s not entirely clear:

However, opening that up reveals a lot:

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:

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.

Odds and ends

So, 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).

But 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).

We 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.

Wrapping up

This 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.

Plus, 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.

It’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!

Until next time ✌️

First, let me get straight to it:

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

So, Why?

I debuted this book series many years ago now, back in 2021!

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.

And, so, I did — though it was a bit grueling.

It 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.

What 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.

And 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.

What’s Next?

I’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.

I’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.

Until next time ✌️