Swiftjective-C: Swift, iOS, SwiftUI, and Indie Development

Now that we’ve seen Apple’s new flagship device, and have the simulator to boot (🥁!), I’ve been diving in on adapting Elite Hoops for the new form factor. As Cupertino & Friends™️ note in their tech talks, we’ve been here before. Over its ~20-year life, we’ve seen the iPhone grow taller, become shorter, lose a home button, gain some ears, and then some. Those of us who’ve been around likely already have developed a precocious ability to listen to Apple to handle these changes, and use Auto Layout/safe area/etc. etc. etc.

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

It’s time for Apple to get into the… fold… with foldables. Anyways, on the day of the announcement, Cupertino and Friends™️ dropped six new videos over developing, designing, and crafting great apps for the nascent device:

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

Ah, Spend Stack. I’m pleased to announce that everyone’s favorite finance app/running total list thingy/do-it-all-calculator-with-1000-use-cases-but-not-one-clearly-defined is coming back from the dead…again! The previous owners, who had let me open source it, have given me back full IP rights. She’s back home:

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

For a long time, the homies and I have joked about starting a podcast.

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

Skills are a paramount puzzle piece to my agent usage. The rub? They are too easily fragmented:

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