Make no mistake, I’m proud! It’s super awesome! But, here’s what I’ve learned:

You hit the fabled #TenKMRRClub before you actually hit the revenue mark. Because, if you’re somewhat close, then you’ve probably already figured out the hard parts of getting there. And for most of us (and there are several, rocketship exceptions), it’s the most boring process in the world:

• You find a pain point. You solve it.
• The first few versions aren’t fantastic, but if people are paying for it, then BAM! You’re onto something.
• Then, as the years go by, you simply don’t quit.
• With a gut intuition, and keeping a sharp eye on your sector, and the people in it, you make the thing better.

And I’m telling you, that’s really it. It’s boring. It’s a process of waking up, and making the product slightly better than it was the day before. I could go on about marketing tips, customer acquisition, measuring ARPU, the lot of it.

But, when I sat down to write this, and I thought to myself, “What would Jordan, three years ago just getting started with Elite Hoops, want to know?”

And the answer? Man, it kinda sucks.

You mean to tell me you simply just keep making the thing better!?

Well, yeah. I do. It’s the best advice I can give, and so many people don’t do it. If people pay for your solution, then where there is smoke, there is fire. So just keep feeding the fire, and you’ll survive:

• The highs and lows.
• The copycats.
• The occasional one star review or refund request.
• The App Store submission that goes nowhere.
• The Reddit comment that swears, with the utmost righteous, unwavering conviction, that there is no possible way your app warrants a…gasp!…SubScriPtiOn!
• The realizations that there’s always a bigger fish, and your success seems diminutive to someone else who may have started last week.
• The fight to constantly resist gilding the lily, and focus on the things that actually might move the needle.

And, eventually, one day you wake up and it just…all kinda works? And, that’s boring, and it’s also true. Three years, tons of iteration, tons of tiny little improvements, the occasional big improvements, and lots of love.

That’s the most boring way possible to 10k MRR.

Until next time ✌️

Epilogue: As an aside, this marks the end of publicly sharing revenue. It started, and has always been, about feeding into the community which has given so much to me. I wanted to give back. Though, as Elite Hoops starts entering big boy “Uh, oh - this is a thing now” territory, I think it’s best to keep the books to myself now. However, being helpful and sharing stuff is something I want to always embody. I plan on sharing more on how to run this type of business, in lieu of raw numbers, and I think that’s just as useful.

My god this is such a good speech that every SWE needs to hear. You know what? Every person should hear it

Keep the happy memories, eyes on the reality, be excited about the future. That’s the best that anyone can do pic.twitter.com/KKFUXfesFb

— Scott (@scottstts) September 25, 2026

I’ve gotta say, I agree with him. It is over. The whole writing code by hand thing. And, probably like many of you, I’ve had a cavalcade of feelings about it.

I vividly remember when I realized it, too. It was summer of 2025 when Claude Code first was making waves. At that time, I was developing Alyx, trying to hit the iOS 26 release. After carefully reviewing some documentation and watching a W.W.D.C. session, I handcrafted Alyx’s first app intent.

And that was it.

I pointed Claude at what I made, and it proceeded to develop the other 49 intents. I played product manager and code reviewer. Claude did the grunt work.

Initially, this made me feel useless. The craft I’d spent years honing? A large language model could not only do it, but in several cases, it could do it better. Let alone faster.

Then, over the months, I learned to embrace it. Figure out its nuances, little levers to pull and buttons to push. As time went on, I became a bit more comfortable. All the while feeling a bit uneasy about it, like I was giving up my automony and expertise to this mythical CLI tool. But I didn’t want to give it up, either. It was an odd stockholm syndrome type of situation.

Still later — acceptance. Software Engineering? It is irreversibly different. There is no going back, and the toothpaste is not going back in the bottle.

Which brings me to today. And, now? Joy. I think that’s something a lot of us are missing in this whole thing. We were there when it was done by hand, and now we’re literally living in, and experiencing in real-time, the next tipping point in our craft. How awesome is that!

Has our industry always not been about dealing with change: the new tools, APIs, languages, models, architecture, the way we do things? The best engineers I’ve ever known have always embraced it, and they are right now.

I’ve always leaned on being an optimist, it feels like a waste of time and a life to really be anything else. And, I feel optimistic as a builder of things. That’s what we are now more than ever, and the tools and the means to get to the “thing” have dramatically changed.

So yeah — it’s over. And when things are over, something else begins.

Until next time ✌️

And so, after playing around with the device and coming up with a design plan, there’s one word I keep returning to: expressivity. This device allows you to express what you already offer in new and, in many cases, better ways. Much like when adapting an app for iPad, you don’t gate features by device, you let them grow and mature with the form factor.

Here’s a preview of what I’ve done. But first, you need to set your codebase up a little. Let’s start with a few things that may screw you if you’ve put these types of things off:

• Using device idiom checks.
• Relying on UIScreen.main — it’s going to be deprecated soon.
• Not supporting landscape orientation.
• Using .leading / .trailing toolbar placements for close buttons. Use ToolbarItem(placement: .cancellationAction).
• Not relying on size classes.

All of those will torch you here, but luckily, there’s a built-in skill to help with all of this: app-resizability. It’ll help you address each issue listed above.

Now, let’s get to the design changes, pose by pose:

Closed

The closed pose will be easiest for most of us. It’s basically a chonky iPhone:

Here, you’re mainly looking at bars: navigation bars, tab bars, toolbars — that kind of thing. That’s because of the nascent vertical bar setup, and the fact that the system will sometimes need to overflow items. The question you need to ask is: what’s most important, is there anything that should always show, and what can be over…flown (is that a word?).

Things that need to stick around? Use the .topBarPinnedTrailing placement. Do you want it to win out over other things when an overflow is needed? Reach for .visibilityPriority(.high). Or, overflow ahead of time with ToolbarOverflowMenu.

Opened

This is where the fun starts, and we get an opportunity to express existing features differently. Here, someone is viewing a public play. But — I’ve got more room to play with! So, let’s make use of it:

Using the new ArrangementView, along with @Environment(\.toolbarVerticalEdge), there’s an opportunity for more data density. And, that’s what you’re seeing here: let’s show the play notes or its attachments — stuff that supports the primary view. Because now, there’s more room for it.

I think this is where the bulk of your work comes for iPhone Duo. Don’t simply aim for making your app work on it, make it freakin’ baller! And, I think this is one way you can do it. Another example:

The play designer in Elite Hoops is where the bulk of coaches spend their time. It has several tools, but needs to keep the focus on the court, and where players should be. With Duo, I’m able to make two critical improvements: space out those tools in the toolbox, and make them bigger.

Continuing the theme of data density, and the ability to spread it out — let’s look at the changes for when a coach is running practice:

Here, I’m able to make the important things stand out a little more. How much time is left in this drill? What’s next? What are the drill’s steps? It’s all made a bit easier to parse on Duo.

The part that I am currently undecided on, however, is how liberally to deploy these arrangement view refactors. Do I always leave them in, and let iOS decide? That’s one part I’ve not yet worked out.

Rotated

For rotations, I’ve found that my existing size-class-based decisions (in terms of how to present things) held up remarkably well. For example, for the digital whiteboard, it now takes advantage of Duo’s real estate to expand and have a richer area for coaches to mark up with their Apple Pencils:

Not much to say here, I’ve found that it essentially mirrors what your iPad implementation does today. As it should.

Folded

For folded situations, there wasn’t much to address. It leverages the arrangement view in most cases, and in some cases, it doesn’t, on purpose. I’m in love with how it looks, though. For example, here’s the play designer from earlier:

One thing I want to emphasize is that the system does the right thing nearly every time, as long as you didn’t reinvent the wheel. Things like the new reserved area and staying away from the fold in these folded situations — the system does all the work. Let it.

Revisiting old assumptions

Designing for iPhone Duo already pushed me to make some navigational improvements for Elite Hoops that I’ve wanted since launch: using a split view. I’ve put this off more times than I can count, but it fit in with all of the other work I was already doing:

Plus, I had to revisit UI that looked great on modern iPhones but was no longer at home on Duo. For example, these bottom rounded corners look quite nice and are concentric with iPhones, but they look out of place on Duo in my opinion:

You’ll quickly find places where you should’ve used a Label with an image and title. I cleaned up all such instances so that they show correctly in overflow menus with a more descriptive string supporting what the action will do.

Final thoughts

And that’s a wrap. If there’s one thing the iPhone Duo has been for me, it’s fun. I have to get one of these! It’s a business expense, after all. Sometimes there’s a serendipitous moment where what you want and what you need end up being the same thing, I guess. The Duo is an exciting little device to design for, and it’s not every day we get new form factors to bring about some fresh new ideas or new angles.

Until next time ✌️

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

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

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

Until next time ✌️

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

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

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

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

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

Here’s to new, old beginnings!

Until next time ✌️

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

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

So, introducing…

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

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

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

Until next time ✌️

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

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

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

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

Here’s the technical breakdown.

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

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

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

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

Until next time ✌️

Even nearly 15 years (!!!) into this business, I can still fall into this trap. Left to my own devices, I’ll happily ship some gormless button label like “Initiate Sequence”, its copy that reads like it was written for someone who should be code reviewing a recursive function. But instead, most people who use my apps are the everyman, who isn’t serially online chatting about AI agents. Writing for them doesn’t come as naturally. Other than experience and being aware of it, is there a way to audit your interface controls for terrible copywriting?

Turns out, Apple has the answer. And, if you power it up with an agent, it can audit your entire app for you. It all starts with this banger session:

In it, Heej walks through how to craft copy that feels human. That really helps someone understand the impact of a button press, or simply set an expectation of what will happen. This kind of thing is absolutely gold. It is the number one thing I think people like me struggle with. Here’s how I hooked up an agent to learn about that session, and then apply it to one of my apps:

1. Install Sosumi MCP or install the WWDC.ai skill.

   For Sosumi MCP:

   claude mcp add --transport http sosumi https://sosumi.ai/mcp
   

   Or, for the WWDC.ai skill:

   npx skills add https://github.com/superwall/skills --skill wwdc --global --yes --agent claude-code universal
   

2. Have an agent watch that session via whatever you installed on step 1.
3. Then, point it your app and give it context on who your target market is, what your app does, and using its new copywriting knowledge - propose updates to strings throughout.

When I did this, I had fantastic results:

Some of them were so obvious, it hurt. But, this is just a blindspot I have. I’m not great at interface label naming, or naming in general. There’s a lot of talk about where the line should be with creativity and AI, and it’s a necessary discourse. In this case? This is one area where I’m happy to have its help.

Until next time ✌️

Remember the good old days of Microsoft DOS? Just a welcoming, plain and greenish terminal. Alawys complete with a blinking green cursor inviting you to press enter, and a list of options:

I guess the idea of a user interface is to help people get something done, perform a certain task, accomplish whatever it is they have in mind. And the easiest way to do that, is…well, visually.

Though recently, I’ve started to have a weird realization that maybe the best UI in this world of agents is sometimes… not having one at all. In fact, I dictated this post all in Codex’s mac app (yes, I know — which is a UI! Hang with me though):

Here are few things I would’ve made an admin dashboard, custom interface, or any interface at all for about a year ago:

1. Customizing a server driven “Event” in a bespoke upcoming app.
2. Reviewing feature requests for Elite Hoops.
3. Managing blog posts for the company blog at Superwall.

Of course, in all three instances, I realized each of these things are agent driven processes. So why bother? I just tell the agent what I need. The only UI, at any stage, is the harness running the agent.

So I’m curious — is this a prominent direction the world is headed? I don’t think it’ll go so far to where we get to a place of “An ad-hoc agent and your prompt is the app for the given task”, as some people tend to think. I am, naturally, using an agent, without an extra UI in the target “thing” I’m working on, to produce some sort of output for an existing app.

Buuuuuut, it is also a little bit more in that direction than I would’ve thought. For me, a prompt can have the verisimilitude of an app: it’s a place to express intent, then I make revisions, and finally end up with the thing I wanted. Or maybe DOS had it right all along?

Until next time ✌️

That stuff is obvious. But, what about your app?

“Hey Siri, what team did I last make a play for in Elite Hoops?”

How do we do that, what’s involved, and how should you think about Siri and your app over the summer? I think I have a fairly good grasp on it, and I’ll summarize it here. I’m skipping deep dives, and just keeping it to a rundown.

First off, the parts involved. The whole process is the same — it’s still app entities for your app’s models, schemas for a particular definition of those if applicable, and a few APIs to make those known to Siri when they are on screen.

App Entity

First, each of your app’s data models that should participate in Shortcuts, an App Intent, or general system-wide intelligence should hav a lightweight AppEntity version. This isn’t the same as the model itself, but a lightweight version of it:

struct TeamEntity: AppEntity {
    static var defaultQuery = TeamEntityQuery()
    static var typeDisplayRepresentation: TypeDisplayRepresentation = .init(stringLiteral: "Team")
    
    var displayRepresentation: DisplayRepresentation {
        DisplayRepresentation(title: "\(name)",
                              subtitle: "\(rosterSize) \(rosterSize == 1 ? "player" : "players")",
                              image: DisplayRepresentation.Image(data: logo))
    }
    
    let id: String
    
    @Property(title: "Team Name")
    var name: String
    
    @Property(title: "Roster Size")
    var rosterSize: Int
    
    @Property(title: "Roster")
    var roster: [String]
}

Surfacing App Entities

From there, Siri needs to be able to find them. There are two routes. First, if a network trip is required or otherwise surfacing content takes more work, then you should use EntityStringQuery:

extension TeamEntityQuery: EntityStringQuery {
    func entities(matching string: String) async throws -> [TeamEntity] {
        Logs.appIntents.info("TeamEntityQuery: String query for term \(string)")
        
        guard let dao = DAO.readOnly else {
            Logs.appIntents.info("There is no database available for the intent to read from.")
            return []
        }
        
        let courts = try await dao.fetchCourtsBy(name: string)
        let entities: [TeamEntity] = try await TeamEntity.fetchData(for: courts)
        return entities
    }
}

More commonly, IndexedEntity is the best path forward. The system automatically indexes this content for you. In fact, most cases just need you to declare conformance:

extension TeamEntity: IndexedEntity {}

In fact, you can simply conform to IndexedEntity directly as opposed to AppEntity. Once you do that, you can identify which parts should be index for search, too, with @Property(indexingKey:).

This is, however, where I’m not entirely sure of the relationships between Siri and your app. If you fill type @Property(indexingKey: \.) — you’ll get a list of autocompleted things you can use here. I believe all of these tie into a predefined App Schema, and the properties within them. So, what if your app doesn’t fit into those? I’m not sure, but I don’t think you can use indexing keys in that case.

App Schemas

Speaking of App Schemas, and their associated domains, are basically juiced up App Intents. Apple has already trained Siri to the moon and back over them, it’ll understand context better, and participate in follow up questions and everything else in-between. They’ve done the work for you. So, if you app fits into one of these schemas, absolutely use it.

You do so by using a property wrapper above your entity declaration:

@AppEntity(schema: .messages.message)
struct MessageEntity: IndexedEntity {
  // The text content of the message
  @Property(indexingKey: \.textContent)
  var body: AttributedString?
}

…where messages is the overall schema, and the message is the domain within it. Xcode will also autocomplete the fields you need to implement a domain. Again, if your app’s data fits into a schema, it’s 100% what you should use. What’s less clear to me is what you can do, or should do, and how far your app can participate with Siri AI if you don’t fit into one of these predefined boxes.

On-screen Awareness

Once you’ve indexed data and exposed it to the system, next you wanna take part in that whole “Yo Siri, tell me about X or Y”, where X or Y is something currently on screen. Two different routes here:

1. NSUserActivity: The tried and true API around, since what — iOS 8?, can help with singular content. For example, a photo.

2. View annotations API: Use this when you’ve got more than one singular thing that’s presented, like a list of stuff.

Together, these tie back to an AppEntity, which means everything is structured in a way Siri can understand. Here’s how they look:

struct MyPractice: View {
    let practice: Practice

    var body: some View {
        VStack {
            StuffAndThings()
            PracticeContainer()
            .userActivity("com.example.elitehoops.practice", 
                          element: practice.asEntity()) { entity, activity in
              activity.title =  practice.title
              activity.appEntityIdentifier = .init(for: entity)
            }
        }
    }
}

And for view annotations:

struct MyPractices: View {
    let practices: [Practice]

    var body: some View {
        ForEach(practices) { p in 
            PracticeView(practice: p)
                .appEntityIdentifier(
                      EntityIdentifier(
                          for: PracticeEntity.self,
                          identifier: p.id
                      )
                )
        }
    }
}

Handle Data Coming In and Out

Finally, getting data out and in. When Siri wants to chain together stuff, like “Hey Siri, email this practice to Jansyn.” — we’ve now got a few moving parts. There’s the “practice”, I need to export my own data, and then there’s the recipient, Mail. To export or import, look no further than Transferable.

There is some nuance depending on the context. If you’re trying to handle an incoming request against some existing content, then you’ll need IntentValueQuery. But, if that request means your app should creating a new model or data, then implement the importing bit when wiring up your transferRepresentation within Transferable.

In Apple’s session, they use this example:

struct ContactEntityQuery: IntentValueQuery {
    func values(for input: [IntentPerson]) async throws -> [ContactEntity] {
      let names = input.map(\.displayName)
      let descriptor = FetchDescriptor<Contact>()
      let contacts = try model.mainContext.fetch(descriptor)
      let matches = contacts.filter { contact in
          names.contains(where: { name in
              contact.name.localizedStandardContains(name)
          })
      }
      return matches.map(\.entity)
    }
}

However, this is the part that feels slightly limiting. It’s typed to handle only an IntentPerson — something the system already defines. As far as I can tell, your app would have to use some value-known intent already, like IntentPerson or something from the App Schemas. Otherwise, you also wouldn’t be able to use IntentValueRepresentation — which is exactly what Siri uses for this type of stuff.

Here’s another example I found in the docs, which handles things bidirectionally:

extension TeamEntity: Transferable {
    static var transferRepresentation: some TransferRepresentation {
        IntentValueRepresentation(
            exporting: { entity in
                IntentPerson(name: .displayName(entity.name))
            },
            importing: { person in
                ContactEntity(name: person.name.displayString)
            }
        )
        DataRepresentation(exportedContentType: .utf8PlainText) { entity in
            entity.teamSummaryText().data(using: .utf8) ?? .init()
        }
    }
}

So, I’m unsure of how to handle this beyond that. If our apps don’t fit into schema, where does that leave us? I haven’t found the answer to that.

Final Thoughts

New Siri looks fantastic. No doubt, integrating it will finally bring us to that “This is what I wanted” phase of the tech. It should be an epochal event for our little digital assistant. For us? The APIs are easy to use, and there isn’t much guesswork. My only question mark is how to best integrate when our data models don’t fit into an App Schema, and if I find concrete answers — I’ll update this post.

Until next time ✌️