I’ve posted about Swift Accelerator, the app development class where we teach teens to build with Xcode for iOS; the final project is to build and release an app on the App Store.
That last bit is, understandably, a struggle! Building an entire production-ready app, that App Store Review deems ready to release, for use by anyone in the world, is no mean feat. But with agentic coding tools, the students (who are supposed to work in groups) can probably each finish one version of the app individually in a tiny fraction of the time it used to take.
So I’ve been wondering, for over a year now, what happens to the last 60-80 hours of our class, which we’ve carved out for building and releasing their apps. Students should still spend time ideating and researching, for sure. They could still spend time prototyping in Figma (but wouldn’t it be faster to just make app prototypes in Xcode?). And what happens when they finish, in an hour, what they used to have to struggle through for days and weeks?
I came across this article which might point the way to some answers:
The Death of Good Enough by iOS engineer paularambles
It’s about how agentic coding tools might finally be able to relieve the tension between “aahhh just make it work” and “but but but it’s not good enough yet”:
When you’re an iOS engineer at a small startup that ships on a daily basis, you don’t get a sprint to build a playful celebration animation. You get a concept, a deadline, and the animation gets cut, or worse, it ships as a fade-in and everyone agrees that’s fine. And over time you end up with the version of your app where everything works but nothing delights.
That era is ending. Shipping no longer requires sacrificing craft for speed.
And how “perfect” might no longer be the enemy of “good”:
We’ve always been told “don’t let perfect be the enemy of good.” That made sense when “perfect” cost a sprint, and “good” cost an afternoon, but when “perfect” costs an hour, and “good” costs five minutes, maybe it’s time to retire that saying. We don’t have to agonise over whether something is worth attempting, instead we can just try it, and if it doesn’t work, we can try something else. We always wanted to build the delightful version, and now we can, while having the most fun we’ve had building software.
(Great article! Click through for some cool SpriteKit animations that Claude Code generated.)
I think I’ll have to come back to this article often with my teaching team in the coming months (class starts tomorrow!). For us as a class, maybe the bottleneck shifts from “how can we build it” to “how can we perfect it”? This has so many second-order effects, like individual motivation, group dynamics, and for me, whether they’re actually learning (when building comes from deciding, and not coding). That’s a lot to figure out as a teacher, but I haven’t been this excited about teaching coding in many, many years.