Consulting has been… INTERESTING since I went all-in on SwiftUI.

The economics really work differently, and now I can look at my invoices to prove it. I want to talk about this because the transition is some of the most intriguing and exciting stuff I've ever seen.

No suspense, I'll give you the crux of it immediately and you can read on if the details are interesting to you.

Building apps is faster with SwiftUI.

And I mean "building apps" in the most holistic sense possible here. From idea to ship, the process is at light speed.

And to demonstrate the many pieces of this, I'll tell you a little about how I approach the business.

I can't commit to big jobs ahead of time. Too much risk for all parties. The way I make consulting work for my stress appetite is to progressively de-risk a project in phases.

The early engagement is always small, no matter the budget. Let's make sure we're solving the right problem, let's make sure we're the right team to build a solution.

If we accomplish one phase well, we move on to the next one. Always clear expectations.

Concretely, those phases work out to slices like:

- Rough requirements, research
- Wireframes
- Light visual pass
- Prototype
- Beta
- Release

I got my arts education in film, and I learned pre-production was the altar of any successful project. We build from there.

Problem is, all those phases ADD UP

That's all time someone has to pay for. So building a real app? You need a serious budget to make that work.

It made selling a challenge, because only an organization that was CERTAIN it needed an app—yesterday—could entertain it all.

With SwiftUI, though, the cost of all that early design work collapses.

I go straight to prototype. There's no point even launching Sketch for UI work at the beginning. Just start stubbing it out using SwiftUI

Automatically, you'll get the correct layout behavior and typography

Some time with a pencil and ruler to play with the shapes and get an idea in my head, then boom, let's write the UI.

Now, follow the ripple effects of this.

My early design tool is now capable of outputting production layout code. There's no lag translating screens to real UI.

What's really going to bake your noodle:

Feedback is cheaper with SwiftUI.

See, in the past, the economics pushed people into the process of designing static UI designs first, since it was cheaper to push pixels in Sketch than it was to write layout/drawing code

It made financial sense to use static UI mockups to get feedback on design options FIRST, then once everyone agrees on a direction, use that as as a guide for your custom interface.

But now, with SwiftUI, automation is on your side. Tweak a few modifiers and everything updates.

The change in the economics revealed here is core to this transformation.

In the UIKit age, you were responsible for building a Rube Goldberg machine that could dance with the iOS APIs reliably enough to flip over the dominos you wanted within some margin of error.

THIS WAS POSSIBLE TO DO

There were preferred methods of doing some common things reliably. There was a lot to learn, and a lot to manage, if you wanted to get it right.

So it was a lot of brow sweat and maintenance to keep this stuff going.

SwiftUI, on the other hand, is a lot closer to

- Write an equation that describes your interface
- If you did it right, you'll get that interface
- If you didn't, you can keep tweaking until it's right

No objects occupying an abstract plane you need to manage.

Just describe the rules of your interface, then you'll be shown a result. Keep tweaking until the result matches your goal.

The smarter you are about organizing and modularizing these rules, the more automation and speed you get in iteration and development.

There's still plenty of thoughtful work to do.

You're just getting a lot more for that work.

The difference in complexity feels like

- Building a mechanical jukebox

vs.

- Building a music player in software

And here's the best part:

All this early design work?

Now it's a code snippet library for building the real application. Velocity kicks up because so much of the work builds on itself.

All that prototype UI can be seed crystal for the shipping UI code.

All this means:

Getting to an app you can be proud of is a shorter march at a cheaper price.

I sell my ability to do this work by the hour, so you would THINK that's bad news, right?

But I think it's great for all parties.

Software is never finished, only abandoned.

I think a lot more projects will get the love they need, and at a minimum, that means I break even compared to the old regime.

But I'm an optimist. I think it will work even better than that over the long term.

With more opportunity to really dial in these products to exactly where they need to be, I think more stuff will have legs.

We'll see new entrants be nimble enough to challenge incumbents, and what could be better business than clients experiencing success?

It's all the potential energy of a platform shift, with none of the chaos.

It's still an iOS device, or a Mac. The economics are just way different to solve the same problems.

Apple doesn't want to end up the next Blackberry, anchored by obsolete software and developer tools.

A good question!

Anyone engaging me to build stuff now wouldn’t ship until around the time iOS 14 shipped, so that’s already covering two major versions.

The variation between 13.0-13.4 was definitely a thing I noticed and worth watching out for. https://twitter.com/andyeb/status/1287026895310258177

Even so, for new projects, my advice is always to target only the latest major OS release. The complexity you’ll manage isn’t worth the marginal extra users—thanks to emojis and good infrastructure, iOS update adoption is REALLY aggressive

https://developer.apple.com/support/app-store/

Screenshots and demoing the simulator via video chat, mostly.

For a particularly high fidelity prototype, though, you could distribute it like any other app, using TestFlight or ad hoc. Slightly more friction there, but the other benefits make up for it https://twitter.com/da_vid_off/status/1286936525427683328

Yes, the requirements gathering and research phase is still necessary, but after that, right into the prototype.

This is great for the client because they get further along the process with less money spent, and they see results really quickly. https://twitter.com/charbrew/status/1286935463043846146

It also means you’re immediately de-risking your layout and visual design. If something is HARD TO DO, you’ll find out immediately, without resting a huge chunk of your design on it.

Fewer surprises by removing the division between design and implementation of the UI

Of course, if you know me at all, you know I’m fascinated by the labor implications (practical and political) of automation.

SwiftUI is an enormous swing at automation that, largely, I find to be successful and expressive. You write code, it expands that code into an interface.

Occasionally, developers speak darkly about the day robots come for OUR jobs.

This doesn’t feel quite like that. I do think smaller teams will be able to do more, faster, under this paradigm.

But what’s interesting with app development is that there has always been more to do.

I don’t think knowing how to handle all the edge cases and variations of UITableView’s delegate and data source methods was particularly good or enriching for developers. Just a Rube Goldberg machine to maintain.

Now you can get more quickly to the most unique parts of your work

The key to successful developer platforms is to maximize the time and resources practitioners can apply to the things only their app can do.

The more time you need to waste building a settings form, the less you’ll have to apply to tuning your custom interface elements.