Today I’m releasing Arborist 1.1 with support for Grove, a customizable terminal picker, big improvements to iCloud login for licensing, and more.

The first feature request I got for Arborist was support for Grove, which is a tool that I had never heard of but found that it complements Arborist quite nicely. The idea is that Grove can keep your main repo and all the feature branches you’re working on grouped together in a top-level directory, with an optional .groverc file that can define things like branch name prefixing and a set of commands to run when creating a new worktree. I think this would be especially helpful for me since I have a monorepo with mise as my main task runner, and Xcodegen as my project generator. I could see using Grove to have Arborist automatically run mise trust and xcodegen to get my new checkout up and running automatically. It’s been a really fun tool to learn about and I’m really happy with how its integration came together in Arborist.

Another feature request was for being able to customize the terminal application opened when resuming a Claude Code chat. Arborist 1.0 only supported the built-in Terminal.app, and 1.1 adds support for Ghostty and iTerm2 as well. I looked into Prompt support because I love Panic’s apps but it doesn’t appear that there is a way to open a new Prompt window to a location on the file system.

The other major feature that I’ve been able to ship is something I mentioned in my licensing blog post about iCloud. In 1.0, Arborist leaned on the Mac having a logged-in iCloud account in order to purchase a license. In 1.1 I’ve been able to add a web login to any iCloud ID (iCloud is still required to buy) so that you can use Arborist on a Mac that either has no logged in iCloud account or has an account other than the one you bought a license on. This has been helpful to me with my Adobe-issued work machine; once I logged in to my personal iCloud account in Arborist my license instantly activated, which is exactly what I was going for.

I’m very happy with how this release turned out, and there’s more in this release too – bug fixes and smaller tweaks – that you can read about in the full release notes.

TL;DR: My new app Arborist is now available for download and purchase!

Over the years, as my workflows have evolved, my tools have somewhat struggled to keep up. In any project I work in, I like having multiple checkouts — maybe I’m building a feature, fixing a bug, and doing a code review. Not necessarily at the same time (as there lies madness in the multitasking), but in different places on my drive so I don’t have to stash what I’m doing and restore it later. This workflow evolved from multiple clones to git worktrees. Worktrees are great because they let me create a whole new checkout on my local machine without having to wait for a clone. I love how fast they are, and because they all share a common .git root I can easily move between branches and cherry-pick commits if I need to.

All of this came with a cost I wasn’t expecting as I started accumulating non-trivial shell commands to run in my repo: there’s the Python script at work which pulls binary dependencies, or the long fastlane incantation to make a build, and many others. These commands often require context which works well in a single-tree repo, but when I had multiple checkouts or worktrees I’d have to redo the setup for any location I was working in. I started to wonder if there’s some way to manage all this.

That idea has clanked around in my head for a while and finally I have an answer: Arborist. It’s my new Mac app which lets me take control of worktrees across my system and run any command I want. I’ve been building this app and using it every day for a while now; today it’s available for everyone running macOS 15 and above.

I’m really happy with how Arborist has turned out. It’s chock full of features:

• Drag and drop your git repos and it automatically picks up all the associated worktrees and lists them right in the sidebar. The current branch is displayed right under the worktree name.

• Rearrange and collapse sidebar items to get things organized just the way you want.

• Create and delete worktrees with ease. Tower added worktree support a while back and while I have used that feature I haven’t loved it, because it feels like adding a whole new repository. I wanted to make worktree management seamless, and that’s just how it is in Arborist. Also, AI agents love to use worktrees but they name them the same as the repo so I’ve been stuck at times with 3 or 4 identically named locations and I don’t know why each of them is there. I can take the power back with Arborist.

• The middle column is the superpower:

  • The commands area stores any terminal commands that you want to run in your repo, and they’ll work across checkouts. I use this for both quick and longer tasks and it’s the killer feature of the whole app in my view. There’s a small console that pops open and shows the terminal output in real time. It’s fantastic!

  • Tools – at the top of the column – are the apps that you use no matter which repo you’re working in. I’m a big fan of Panic’s Nova for my non-Xcode projects, and I want to be able to open any worktree in Nova with a single click. Arborist lets me do just that.

• The shell environment that both commands and tools run in is fully customizable in Settings, and you can see the environment variables that Arborist uses to run commands and launch tools.

• The inspector pane on the right side gives me details about the checkout I’ve got selected. The best part about it is the conversation recall for that worktree so I can see the sessions I’ve had with Claude or Codex.

  • Clicking on a conversation launches you right back into that conversation. This proved really valuable to me when I couldn’t find a conversation in Codex but I could resume it in Arborist.

  • The sessions are discovered by reading the local files in their known locations, and no data about these conversations ever leaves your machine. Arborist is 100% privacy-focused.

I’ve worked really hard to make Arborist Mac-Assed as well, with good keyboard support and a squircle-free alternate icon to boot (I freaking love that icon and use it myself on my machine). I’ve loved the Mac platform since the early ’90s and I want to make a Mac app that Mac people will love to use.

In my last post, I wrote about using RevenueCat for my licensing. I’m really happy with how that turned out, and I think the ease of tying a license to an iCloud account will make for incredibly smooth transfers to new machines.

Arborist comes with a 14-day free trial, and after that costs $39 for a full-feature license to v1 and all the updates in the v1 family. If and when a v2 comes, there will be a discount available to v1 owners (I don’t know when a v2 will ship, that’s all way in the future at this point).

I hope you give Arborist a try and that it helps you take control of your workflows.

Then came the question: how do I do licensing on my own?

I know there are options out there like Paddle, FastSpring, and Lemon Squeezy that have worked for many apps like mine over the years. But I also wanted something simple for my users. Not to mention Apple Pay was a must-have. I’ve experienced friction more times than I can count when an app doesn’t support Apple Pay, and every time it happens I am ever so slightly less happy with that app because of it. Customers are also more familiar with the smooth in-app purchase experiences provided by the App Store, and if I could achieve something that easy I wanted to do just that.

I also happen to be in a couple of Slack workspaces with the wonderful and friendly Dave DeLong. Dave started working at RevenueCat recently and he also has a passion for good Mac apps. He mentioned in a discussion about Mac app licensing that he would love to work with someone using RevenueCat’s web SDK to power that experience – and my gears started turning.

After collaborating with Dave and some trial and error I was able to land on a somewhat novel – and simple – licensing implementation:

• RevenueCat serves as the source of truth for whether or not a customer is licensed.

• I create RevenueCat customer IDs from local iCloud identifiers (more specifically, calling userRecordID() on my CKContainer in CloudKit).

• When the user makes a purchase, they earn an entitlement that I look for in Arborist to grant them a license.

The big bullet of note there is the second one. I didn’t want to have to spin up a licensing server to send out codes (much less have to store them), and I didn’t want to have an email-based system. I wished for something simple like StoreKit but without using the App Store as a backend. I had to implement some kind of identifier that I could tie easily to a user and I wanted that to be as transparent to the user as possible. Hence, userRecordID() made complete sense. This also allowed for “license sharing” across all of a user’s devices. So as long as a customer is logged in to the same iCloud account on a device that they made a purchase on, they’ll be licensed for Arborist. I like the simplicity there. One other great thing about this is that I don’t have to collect any personally identifying information about my customers directly. Stripe handles the payment process, and the iCloud’s identifiers give nothing away.

The eagle-eyed among you may notice that my entire licensing strategy hinges on the customer being logged in to iCloud. That’s true for my 1.0. I don’t think this is too big of a leap to make for a power-user app like Arborist. But I am working on a way to sign in to iCloud using the web so that folks who don’t have iCloud set up on their machines can still buy a copy. That should land not super long after 1.0, but it does have some more moving parts to it and so I deferred it to post-launch.

Setting up the backend

Getting these details in place was not immediately obvious to me, and I actually went down one path first before partly reverting and going another direction. At first I set up RevenueCat Billing, but that ended up being the route I didn’t want to take. I had never heard the term merchant of record (MoR) before and when I first did I didn’t know it was something to care about (spoiler alert: it very much is). RevenueCat’s product does not take care of being the MoR for me and thus would leave me on the hook for things like taxes and refunds. Being a solo developer embarking on my first direct-sale app this became a dealbreaker.

Thankfully Stripe has a service called Managed Payments which does handle this for me and even better is that RevenueCat plugs right into that system out of the box. So after doing some research it seemed the better way for me to go.

On the RevenueCat side, I will say that I am consistent in forgetting how to set up their chain of values. I have used RevenueCat for Baseplate and Decoder previously but getting set up for Arborist definitely tripped me up.

1. In RevenueCat, create the entitlement that Arborist will look for to ensure the user is licensed for v1.x.

2. Add the product in my Stripe dashboard (ensuring it meets the criteria for managed payments).

3. Back in RevenueCat, I had to set up Stripe as a web provider. There’s a box to check to use Managed Payments when available that I had to check as well.

4. Create the RevenueCat product by importing it from my Stripe web provider.

5. Add a new offering which has the product inside with a lifetime duration. This will give me effectively a one-time purchase (there is a subscription “end date” that comes along in the SDK but it’s for 200 years from now so if a customer needs a refund in 200 years I probably won’t be able to help them).

6. That offering then gets a Web Purchase Link. This URL is what I then use to direct users to purchase in the app. It lets me specify things like the callback URL for when a purchase is complete.

I’m listing these steps as much for your information as I am for Future Me in the hopes that we can all do this a little smoother the next time 😀.

So the whole flow goes from Settings -> License -> Buy -> Safari -> Complete purchase -> Back to Arborist -> Refresh from RevenueCat -> Done. My hope early in the process was to avoid the Safari hopping, but doing so meant that I could not offer Apple Pay. This is a known WebKit bug from 2 years ago about Apple Pay not working in WKWebView. It’s a real bummer because keeping the flow in the app was so smooth when I had it working that way, but I figured the friction of going to Safari to do Apple Pay and then hopping back was much less than having to input all your payment details in the app.

An Aside on Taxes

One thing that has scared the daylights out of me in all this is sales taxes. I’ve never had to collect them before, let alone distribute them back to a government. Throw in dealing with non-US countries and that’s even more terrifying. I was originally looking at Stripe Tax to take care of things for me but something felt strange as I was exploring that route. I couldn’t ever get it working in the sandbox environment and when I did some more research I was still going to have to file on my own. Thankfully I found Managed Payments and from everything I can tell, making Stripe my MoR puts all the burden of these collections and distributions on Stripe. So I’m happy to give them a few extra percent of each sale to handle that for me.

Hooking up the app

The last piece to complete the puzzle is hooking all of this up in the app. It’s important to note that while the RevenueCat SDK is great, it’s also geared towards apps which use StoreKit. For my needs I’m not using StoreKit, so fetching things like my Offering can’t be done with their library. This means that I have to hard-code the URLs I need to hit (and I have both production and sandbox URLs in there for testing). So when a user clicks the buy button, this happens in my licensing view model:

func startCheckout() async {
    guard isStartingCheckout == false else { return }

    isStartingCheckout = true
    actionMessage = nil
    defer { isStartingCheckout = false }

    do {
        let checkoutURL = try await licenseManager.checkoutURL()
        guard NSWorkspace.shared.open(checkoutURL) else {
            throw LicenseCheckoutOpenError.failedToOpenBrowser
        }
        actionMessage = "Checkout opened in your browser."
    } catch {
        displayState = LicenseDisplayState.resolved(
            from: nil,
            previous: displayState,
            error: error
        )
    }
}

There’s some state to handle to show the user that the process has started, we assemble the checkout URL (which looks something like https://pay.rev.cat/{web_link_id}/{user_id}) and that gets kicked out to the system in their browser of choice with the NSWorkspace API call.

When a purchase is successful on the web, RevenueCat’s backend will associate the user ID that I passed in my link above with the entitlement in step 1 above and call back Arborist with the registered deep link I put in the web purchase link. The callback handler then runs a re-fetch of the customer and validates that the entitlement to unlock the license exists:

func handleDeepLinkPurchase() async throws {
    let customerInfo = try await Purchases.shared.customerInfo(fetchPolicy: .fetchCurrent)

    guard
        let entitlement = customerInfo.entitlements[entitlementID],
        entitlement.isActive
    else {
        // Handle a missing entitlement; this means the
        // transaction did not succeed
        return
    }

	// Once we get here we have a validated customer who has
	// made a purchase and the app can be unlocked.
}

Don’t miss the first line of that method: Purchases.shared.customerInfo(fetchPolicy: .fetchCurrent). The fetch policy here is critical because without specifying .fetchCurrent the SDK will return cached data, and if a customer has made a purchase that won’t be reflected instantly like they’ll expect. Instructing the SDK to bust out of its cached data is the thing that will make this process feel seamless to my customers (and yours!).

There’s also code that looks a lot like this which runs on app launch to validate a user against their iCloud ID. If this is their first launch of Arborist and they have bought a license using the same iCloud account on a different Mac then Arborist will be unlocked automatically (there’s no “Restore purchases” button or workflow to even worry about!).

Wrapping Up

I think this process has gone about as smoothly as I could have hoped, given that I have never sold a Mac app directly before. I’ve also never seen anyone attempt to use iCloud as a customer identifier. So there’s still some nerves as I approach July 20, when I’m going to be launching Arborist. I know I’ve done my best to get here and if everything goes sideways on launch day, it’s still just the first day of my journey selling this app.

I want to give a lot of thanks to RevenueCat’s team, particularly Dave DeLong, Ed Shelley, and Delia Behr for being great partners in helping me get set up technically as well as on the content side with this blog post. I’ve long been a fan of RevenueCat’s and for someone running an operation of my size I’ve yet to have to pay them a nickel.

I’ll follow up post-launch with a retrospective for how things have gone and how this licensing plan has worked out. If it’s as transparent as I hope it is I think this will work out nicely.

Boy, was I right. And boy, did it get more complicated than I thought it would.

Honestly, in the whirlwind of emotions I don’t know if I remember all the steps I went though. It did lead to my first Swift Forums post because I was getting crashes I couldn’t make heads or tails of. The first part of it had to deal with Swift’s Docker images (or libraries that I link to in newer versions of Swift, it’s hard for me to tell) using “CPU flags” – a term I’m not familiar with – which my Digital Ocean server doesn’t have.

I was able to solve that by statically linking the Swift standard library in my executable. At least I think that’s what solved it. Then came thread creation crashes, and then Docker permission crashes. What I ended up doing was this:

• Created a new server, and took the opportunity to automate that process. The automation part wasn’t strictly needed, but it’s one of those things that had been in my head a while so I took the chance to do it.

• Simplified my SSL approach. If I was going to create a new server to check if it built there, I would need to update my infrastructure because it built all the SSL pieces for me. I didn’t have a way for it not to do that. Instead I went with Cloudflare and removed SSL from the game entirely. This simplified a lot of my spin up process and made it identical whether in production or locally on my Mac. This was a big win.

• Because It’s Always DNS, I had to point my nameservers at Cloudflare (and Cloudflare at my new server too). My old server was too old – 7 years at this point – so it was time to make the switch there too.

• Once I deployed the new server I got some Swift runtime crashes in my code (a first for this project) and I had to fix that by updating permissions of some mounts that get made in my app’s container. The problem was Maverick couldn’t read the site’s configuration and crashed. Once the permissions were set, my site was happy again.

There are probably steps along the way that I’m missing, but the gist is that my blog is back after a couple of days down. The next time I update the engine I’ll be dang sure to do it on a test server first. Live and learn.

Over the years I’ve always been very impressed when I hear stories of developers building and shipping an app very quickly. But for me that experience had never come together – getting the idea (which I could execute quickly), actually making the app to a standard that I’m happy with as a simple 1.0, updating all the marketing materials, and the 28 other steps that all go in to making a release. It’s a lot of work!

However, on Monday last week things came together. And I’d say it was a highlight of my Christmas break from work.

TL;DR: I’ve got a new Mac app – Decoder. It will use your Mac’s camera to scan any kind of code, barcode, QR code, Starbucks gift card, etc.. Check it out at https://taphouse.io/decoder.

Backstory

My wife Emily had gotten a bill in the mail that had a QR code on it so that you can pay by phone. However (and I’ve had this feeling often as well) entering the data associated with the bill is easier done on the Mac. The problem is that the Mac has no built-in QR code scanner, unlike the iPhone. So I went searching on the App Store for an app that could help her utilize her webcam to scan the code. There are a couple out there but neither seemed all that great.

I’ve been working with AI coding tools more (Claude Code and Codex are my current weapons of choice) and so I created a new git worktree in my monorepo and opened Claude code to it and gave a simple prompt:

I’d like to make a new app for the Mac which turns on the camera and lets the user scan a QR or barcode. Let’s call the app Decoder. Take a look at the pattern of my other apps and make a new one in the Apps directory with an Xcodegen definition file. The app should also follow common Mac patterns and fit in well with the rest of the ecosystem.

Once we have the basic shell up and running we can talk about other features.

The result took just a couple of minutes and out popped an app that interacted with the camera and scanned the code. I showed Emily the app and she confused it with one that I had sent her way (she had already paid the bill, I was just having fun). Her surprised look when I said that I just made this was a lot of fun to see.

Claude’s Initial Output

I have had a bit of experience with Claude over the past year, and I’ve built up a decently extensive set of rules in my .claude folder. But I have to say that the initial output from my meager prompt above was very good. It made an XcodeGen yml manifest similar to my other apps, and I was able to easily generate the project the first time. My monorepo is anything but conventional but it works very well for me. Claude plugged in to it and added the new app structure seamlessly.

The SwiftUI code it produced also was really good. It produced easy to read and reason about views, and the backing models were all in the modern @Observable pattern. I didn’t think it got too clever about anything. As a first examination and running of the output I’m very impressed.

Polishing for Distribution

I figured that it could be fun to see what it might take to get this app on the App Store. There were some missing niceties like history preservation and a nicer UI for when the camera is off. For history between sessions I leaned on the swift-sharing package from Point Free. It added the package to my XcodeGen manifest and integrated it perfectly (I was able to point to my example implementations in Baseplate as a pattern).

Next came the app icon. I’ve used Bakery in the past to make quick icons using SF Symbols, but that’s disallowed in the App Store. Claude can’t create images, but it can create SVGs. Since Decoder is basically a full-window code scanner I came up with the concept of a Mac window with a QR code inside and Claude generated the code to make an SVG. This process actually took quite a few iterations but I got to a place I was happy enough with. The biggest creative change I had to make was putting the macOS window stoplights in the center of the title bar because otherwise Tahoe’s roundrect clipping would slice the red one right off. It took a few iterations to get the sizing correct for Icon Composer so that the SVG would fill the icon but we got there. I’m actually pretty happy with how the icon turned out.

Business Time

While I wanted Decoder to be free, I also knew that having a way to get a few dollars for it would be nice. I’ve used RevenueCat with Baseplate already and I’ve seen other apps implement a tip jar feature so I asked Claude to add a tip jar, with a primary action button in the toolbar. Claude spun for a little bit and did a very nice job of producing a view with buttons that can act as individual “tip” buying buttons, hooked up to RevenueCat (after having added RevenueCat’s SDK to my XcodeGen manifest).

The next step was to add the identifiers for my in-app purchases to App Store Connect and hook them up to the RevenueCat backend. I did these steps by hand because I’m not sure if there’s a way to do them using automation.

Web Updates

The next piece of the puzzle to ship Decoder to the App Store is a website. I have a decent if not overdone process for the taphouse.io website – it’s a Vapor site that could absolutely be static but is not. I use Leaf for the templates and have one shared template for both Baseplate and Scorebook. I didn’t want to go overboard with screenshots so I decided to go with a single, simple one for now.

I have a separate repository for my web services (there’s the website and a small API I run), and I added that working directory to my session with Claude Code. From there I gave it the prompting to look at how my other app pages are set up and to create a page for Decoder. It went to work and reused the template I had for the other apps and made something… okay. But after some iteration I was able to get a new template spun up that Decoder could use. It also added the app to my dropdown listing and updated the home page.

App Review

This project began at about 5pm PST on December 29. By 11am on December 30 I had the app in a good state, tested the in-app purchase flow, and updated my website. I asked Claude to give me the marketing spiel, looked it over, and submitted it for review.

A Brief In-App Purchase Aside

The workflow for adding in-app purchases to an app is strange and easily confusing. I say this having gone through it with Baseplate at the end of 2024, and at Adobe having gone through it with Premiere’s launch in September of last year. In-app purchases (consumable, non-consumable, or subscriptions) need to be approved by Apple before they can be sold in an app and the process for getting them approved gets bundled up with an app’s submission.

After I submitted Decoder for app review I found a couple of bugs that I wanted to take care of. So I did that, made a new build, and developer-rejected the existing build that I had submitted before. This took my app (which also had the 3 tip jar in-app purchases submitted as well) back to the “Prepare for Submission” state. However when I went back to submit the updated build I couldn’t find the 3 tip jar items to add back and looking at their product pages in App Store Connect showed them still waiting for review.

It seems to me that the process of approving an in-app purchase has much less transparency than a regular app. There’s no way to see their review status in the same way as an app, and the fact that bundling the submission with an app but rejecting the app doesn’t affect the in-app purchases is unnerving at best.

It took until January 4 to get the app in to App Review, but once it did the review was just 30 minutes. The in-app purchases for the tip jar got approved (even though they were no longer part of the submission) and Decoder is now for sale!

This project was a lot of fun and seeing how well the tooling like Claude Code can help me put together an app and its marketing material – and in so short an order – was really eye opening. I have started working on another, much more complicated, app that I hope to have progress updates on in the coming months. It will take a lot more time than Decoder did but it also does quite a bit more. I’ve also dusted off an app that I started a few years ago and have been working on it too (I’m writing this post using it in fact) and may be able to polish it up for release.

I’m definitely feeling an energy for building apps of my own that I haven’t felt for a while and I’m excited to see how I can move these projects forward in 2026.

Meet Baseplate! It’s a fun app for LEGO collectors to manage their collections. Over the past few years I’ve gotten pretty heavy into collecting and building and I’ve had a great time getting to know Baseplate. I hope you love it too. Check it out on the App Store!

Baseplate was originally developed by Shihab Mehboob and released earlier this year. I’m super impressed at how he was able to build the app so quickly – and for all of Apple’s platforms (save tvOS). It’s been a lot of fun to dig in to the app and learn from a developer who did the thing that I’ve constantly struggled with: shipping the app!

The whole process of taking the app over has reinvigorated me for my own apps. I have put Scorebook back on the store and am working on updates to it too. I was able to rebuild my Taphouse website using Tailwind CSS as well as the newer version of Vapor. I’ve sorted out some of the things that slow me down such as build and deployment processes and have attempted to take the friction out of building apps as much as I can.

I’m also going to try and market Baseplate better than before. I created a Mastodon profile for it and will be working on features to let users post about their collection super easily.

So go give the app a whirl. I hope you like it!

@Model
final class Company {
    var name: String

    @Relationship(inverse: \Person.company)
    var employees: [Employee] // `Employee` is also a class annotated with @Model
}

My surprises came when I started adding some tests around my new models. For somewhat contrived reasons, let’s say that when a company gets created there is 1 employee.

func test_newCompany_hasEmployeeAttached() throws {
    let company = Company(name: "Great Co.")
    XCTAssertEqual(1, company.employees.count)
}

This test fails in 2 ways:

1. I get a crash at the init on the first line because there is no configured container.

2. I get a crash when accessing the array (which should have 1 auto-inserted value).

I fix the test by adding the container, and then inserting the company in to the container’s context:

func test_newCompany_hasEmployeeAttached() throws {
    let context = // create the container

    let company = Company(name: "Great Co.")
    context.insert(company)

    XCTAssertEqual(1, company.employees.count)
}

What stands out to me is that it sure feels like SwiftData classes are your own classes. But they’re not. They gain a conformance to PersistentModel and have all of their persisted properties rewritten with generated getters and setters. So yeah the class does not inherit from NSManagedObject but it’s also not a class that is unencumbered from implicit behavior to be aware of.

I think this is teaching me that there are nuances to using SwiftData and macros in general.

Now there’s a new journey ahead of me. Today is my last day at Zulily and on Monday I start a new one with Adobe.

A good friend of mine joined Adobe back in September and told me many times that I should apply. I took his advice and my first day is Monday. I’m super pumped that I’ll be working a bunch in SwiftUI – I have much to learn! Everyone I spoke with during my interviews were fantastic. I asked everyone what they liked most about working at Adobe and they all said the people. That everyone is willing to lend a hand when it’s needed. Egos are checked at the door and you work to help your coworkers ship something great. I’m so here for that kind of place.

I’ll miss my colleagues at Zulily but I’m so pleased with how I’ve been able to help out that project over the past couple of years. I know I’m leaving it better than I found it, and that’s not nothing.

Onwards to Adobe!

The week went well over all! It took me what felt like a long time to get used to some of the core concepts like using all the utilities it gives me, but I’m happy with the outcome – even though the results don’t look much different from the previous layout. Once I got my mind around using the configuration file, and then processing my input CSS into my final output things really started clicking. I could use my same fonts, and using the typography plugin I was able to easily just let the system lay out m text way better than I ever could by hand.

I’d be remiss too if I didn’t mention the wonderful Tailwind UI templates that helped me along my way too. They are a really nice way to get started and piece together some super functional sites. I’m not using Vue or React so I had to do some adapting of the HTML templates (and if I need to, I’ll have to write any JavaScript to interact with them by hand).

I also did a bit of refactoring of my leaf templates to simplify them a bit, wrote a couple of new command line utilities to help me make & publish new posts, and put in my first GitHub Action which will publish new posts as I commit them to the repository.

On the whole it’s been a very productive week. My next task will be to upate my Taphouse using Tailwind as well – and I’ll be making heavy use of those Tailwind UI components to get that done.

Let’s start by establishing some principles:

1. Only one version of your app can be on the App Store at any given time.

2. A phased release lets you slowly allow users to auto-update to a new version at a slow percentage.

3. New users and manual updaters can always get your newest version from the App Store.

When you decide to phase a release (Apple Documentation), you’re specifying the percentage of users who will be auto-updated to that release. The cadence is over 7 phases (1%, 2%, 5%, 10%, 20%, 50%, and 100%). Generally one phase equates to one day, but the release can be paused on a phase for up to 30 days. The happy path is making a release that gets phased without problem over 7 days and you’re done.

Let’s run through a scenario where things go on the not-so-happy path and see what happens.

Say we have an app and version 5.1 which is at 100%; new users and all updates will get this version. On Monday we release 5.2 using the phased release. This means that 1% of automatic updates will receive v5.2, but new downloads and manual updates can be performed to get 5.2 as well.

On Tuesday (phase 2, which is 2%) we identify an issue with 5.2 and decide to pause the rollout. This will stop the automatic updates from happening to 5.2 (but again, new users and manual updaters can get it). We identify a fix and submit it with version 5.2.1. That release also gets phased. So what happens now? We’ve had 5.1 available to everyone, 5.2 at a 2% automatic update, and now 5.2.1. Here’s what happens:

• 5.2 gets replaced on the App Store with 5.2.1: new users and manual updaters can only get to 5.2.1.

• 5.2 also completes its phasing, but no additional users can get to it (see principle #1 above).

• 5.2.1 begins a new phase – it does not replace the phasing of 5.2 that we had in place already – and it is at 1% at release.

• There will be some subset of users on version 5.2 who will not be auto-updated to 5.2.1 for “some amount of time”.

  • It is likely possible for a user to have been in the first 1% of 5.2, and also to be in the final 50% of 5.2.1 (the documentation is very unclear about this).

Phased releases can be a great tool to help control the rollout of new versions of your app. Before we had them we just had to make a release that went to everyone and had no control over that cadence at all. But there are some nuances that can easily trip up app developers and their teams alike. I hope this has been a helpful walkthrough in the life of a phased app release and brings clarity to questions that you may have encountered along the way.

At Zulily I have been able to bring the same philosophy (with a few twists, but more on that another time). Our project was started in 2012 and we still have much Objective-C laying around. Since ours is an established project I had to answer the question: Where do I start?

My aim in this post is to answer that question with a few helpful tips that I picked up along the way (with a shout out to the Tuist docs.

Extract Your Build Settings

The first step in de-emphasizing your project file is to remove as much from it as possible. The lowest-hanging fruit are build settings. Thankfully the wonderful BuildSettingsExtractor by James Dempsey is there to help you out. It will examine each target you have and create xcconfig files for each of your target configurations, as well as a shared file that each configuration file imports.

Once you have these files extracted you can attach each file to its correct target configuration using Xcode. I’d even suggest taking this one step further and having a script run to verify no build settings creep back in to your project file.

Clean Up Your Files

The manifest files I described earlier point to globs of files in your repository which will be come sources & resources for Xcode to assemble your targets in their final product form. If you have files strewn all about the repository then it will be difficult to pinpoint exactly what files are contained in any given target. It’s a good idea to determine how you want your target directories to be organized at the end of this project, and start implementing that now.

Here’s how I went about this cleanup at Zulily:

0. The first thing I did was to run the excellent Synx tool on our repo. Our project file version was old enough that Xcode did not move files on disk when we moved them in the project, so things had gotten way out of whack. This tool ensured that we were working with files in their proper places from the start (for the most part).

1. Using Xcode I created the directory structure for each target and started moving files & resources around. Most of our files & folders were a single level deep in their target’s hierarchy so I started by creating the top level Sources directory and moving our sources in there. I would then look back in the Finder and see what files were left over. 95% of the time I could just delete them straight away – if Xcode didn’t know about them then they weren’t affecting our app.

2. Start building the project manifests in parallel to the file reorg. By building the manifests for each target (defining where to find the sources, resources, target build phases, etc) I could ensure that at the end of the day I would have a buildable project from our collective manifests.

3. One of the big things I got from the Tuist docs was to order my operations by target dependency count. I started with targets that had 0 dependencies, got their files organized, and was able to have a project and a building target right away. This helped me gain momentum in the project.

4. Once a target was organized, able to build using the generated project and still in my Xcode project, I made a PR changing just that target in our main branch. I wanted to keep all this churn as incremental as possible rather than dumping a PR that touched literally every file in our repo. So instead of one massive PR I had many smaller (but still big) PRs that landed in sequence before the one which generates our project file landed.

Evaluate Your Options

There are a couple of main tools that can be used to make Xcode project files (without also affecting things like your build system): XcodeGen and Tuist. I’ve now used both, and each has their merits and drawbacks. For Zulily’s project I went with Tuist. The main reason was because of its support for Test Plans (XcodeGen’s support hadn’t landed yet). For my personal projects I’m still using XcodeGen though and don’t have any real plans to make a change at this point. Here’s a rundown of some benefits & drawbacks that I’ve found for each:

XcodeGen

• ↔️ Manifests are all defined in yml or json files.

• ✅ Super fast project generation.

• ✅ Templates greatly enhance flexibility & reuse of things like target definitions.

• ✅ Lightweight app built in Swift with binary releases available for download. It’s super easy to integrate into your repository.

• ❗️ Manifests only have so much flexibility because they aren’t defined in code.

• ❗️ Errors can be hard to debug (yml is a good but somewhat picky format).

Tuist

• ↔️ Manifests are all written in Swift.

• ✅ It’s extremely opinionated but uses those opinions mostly helpfully.

• ✅ You get a framework called ProjectDescriptionHelpers which lets you add whatever helpful code or additions you want to make your manifests as simple as possible.

• ✅ There’s a fantastic community building up around it.

• ✅ Can bundle itself and all of its dependencies with one command, making pinning to any given version (or commit hash) super simple.

• ❗️ Generation is much slower than XcodeGen. This is because Tuist is attempting to do more for you, but sometimes I found that it gets in the way and I have to work around it when the Tuist way of doing things differs from my own.

• ❗️ Errors can also still be hard to debug, because you can’t (currently) pause the debugger when running the manifest generator.

It’s hard for me to prescribe which tool is right for your particular environment. I’ve been an XcodeGen user for a few years now – that’s what Lyft used – and it’s been great. I’ve been diving more into its advanced features and putting more weight on my manifest files and it doesn’t bat an eye. My project generates incredibly fast. My personal projects will likely stay on XcodeGen for a long time.

I’ve also found Tuist to be really nice to work in, and in a future post I want to talk about my Tuist-centered approach to how I’m breaking the Zulily codebase into modules and what that API looks like that I’ve built out in Tuist. I’ve found that having running code, being able to define functions, and the extra things that Tuist gives us at Zulily delivers the power of something like bazel’s BUILD files without the hassle of switching build systems. It’s been the right call for Zulily.

Wrapping Up

Putting in some work at the beginning of your project can pay major dividends. By slimming down your existing project file, and getting your repository structure in place before (or while) building out the manifests to generate your project you are setting yourself up for success. I hope this has been a helpful primer to get you started down the road of generating your Xcode projects!

So I did something fairly rash. I sold it, and all this year I’ve been doing any “real work” from my 11” iPad Pro.

Honestly the whole thing has gone pretty well. Better than I had expected it to. I did get an M1 Mac mini for my office desk (which is outside of my house) and I access it remotely using the wonderful Screens apps by Edovia. I’ve been working on a new cross-platform Mac & iOS app and the lion’s share of that work has happened from my iPad connected to that Mac mini.

None of this would have been possible without last year’s introduction of the Magic Keyboard for iPad Pro. Having a very good keyboard coupled with the fantastic pointer support on the iPad is a game changer. I really do love this accessory. The only thing that I wish was different about this setup would be the front camera. Why is it still on the “top” side, when we all know that these iPads are used in landscape nowadays. The camera should be on the top side when docked in the Magic Keyboard. Oh well.

This is definitely an experiment that I’m happy to have undertaken. I’m excited for new Apple Silicon-powered MacBook Pros (and I’m actually considering getting the much-rumored 14” model instead of another 16” after experiencing the 11” iPad) and this little iPad has been a great companion along the way of that transition.

Let’s start by looking at the existing lineup, shall we?

Desktops

• Mac Pro: Just introduced last year, not often updated in general, and likely the model with the most outstanding questions about what an Apple silicon version might look like.

• iMac: New models were announced last year but they’ve sported the same case design since late 2012 – and even that was a very mild redesign of the 2007 redesign, which itself was a very mild redesign that harkens back to 2004. There are rumors of new iMacs imminently and some evidence of them showing up in benchmarks.

• iMac Pro: Introduced at the end of 2017 with nary an update since, the iMac Pro is an oddity in the current lineup. I hope it’s not a one-hit wonder but an iMac update may fold it in to the more broad lineup.

• Mac mini: It was “updated” this year but that was just a storage bump (having just purchased a new one, it lists itself as a 2018 model). Mac minis are not updated very frequently but it’s due for a bump.

Laptops

• MacBook Pro: MacBook Pro’s have been revised fairly recently, with the 16” model coming at the end of last year, and 13” models coming just a couple of months ago. There are rumors of a 14” MacBook Pro to replace the 13” but I wouldn’t say that these computers are screaming for an update (especially since the butterfly keyboard fiasco is now behind us).

• Macbook Air: These may be the best MacBook Air’s that Apple has ever shipped. They are now retina, with the good keyboard, and at a good price for a configuration suitable for most people. The Air was just updated a couple months ago alongside the MacBook Pro.

So, with that landscape in mind, which is the best candidate for Apple silicon? That’s actually really complicated.

• Apple could wait until this fall and revamp the iMac, bringing its case design forward to the modern age and giving it new life. It’s worth noting that when the Intel transition came about the iMac was the first machine to get the new CPUs – a mere 3 months after its previous revision. If Apple brings out new Intel iMacs this summer don’t be surprised if they revise them again in the Fall with Apple silicon chips.

• One of the big gains from this new architecture is battery life, making the new chips perfect for the MacBook Air. I mean, who wouldn’t want to see an Air with a legit 20 hours of battery life? That seems like a reasonable computer we can see after the transition.

• Apple also in all likelihood wants to show off the power of their new Mac CPUs. The DTK that many developers are playing around with right now has the 2018-era A12z inside, and in emulation mode that is benchmarking comparable to 2015-era Macs. Once we start seeing apps built for Apple silicon and running on 2020-era CPUs I’m guessing the performance is going to be stunning. Even the MacBook Air I just talked about may get performance close to today’s MacBook Pro. Apple surely wouldn’t want its Pro laptops being outperformed by its consumer notebook.

So here’s my prediction:

Apple is going to revise every Mac this fall with Apple silicon – save the Mac Pro. Yes, even the Mac mini will come along for the ride (it’s the chassis for the DTK after all, so it seems simple enough for Apple to put a different board in it with production-ready CPUs on it). I think that Apple becoming their own Mac CPU vendor is going to lend itself to even more secrecy and it seems like they have a lot up their collective sleeves.

Will this happen? I don’t know, and honestly I doubt it. But it’s fun to speculate nonetheless. And it’s also a really fun time to be a Mac user.

It’s going to be fun going back to a place where I already have many friends – and I’ve gotten to meet some of the newer folks over the past couple years of Xcoders meetings. I’m excited to take some of the good things I learned at Lyft and bring them back to zulily.

I’m excited to start this new chapter. Onward!

Last week started like any other work-from-pandemic kind of week, but then came Wednesday. Lyft laid off 17% of its workforce including me. It was pretty shocking – especially at first – but there was actually a calm that came over me pretty quickly about what was happening. Don’t get me wrong: the situation itself was incredibly chaotic between sorting out logistics of what comes next, talking things over with my now-former team (who was entirely blindsided by this), and still having the regular day-to-day things happening around the house like Atticus’s therapies. Life goes on.

In the days since the layoff I’ve come to realize how amazingly blessed I am by the community that Jesus has put around me. Many friends have said incredibly nice things about me in re-tweeting my original post about being laid off. My email inbox blew up from 3 messages on Wednesday morning to over 55 at its peak late Thursday. I’ve already had a few recruiter calls and have more lined up this week. I hope and pray that a new job will come along soon.

In the meantime I’ve got a short contract project to work on with a couple of good friends that I’m super excited about, a calendar that suddenly has become a lot more complicated, and a few things that I need to get listed for sale. Onward to my next adventure!

• In Messages, tapping an http or https link would presumably take you to the browser you’ve set as default. This could be Safari, Chrome, or iCab.

• Tapping a mailto link would open up your email app. There are plenty out there which could supplant the default Mail.app (which is what I use and personally find to be fine).

• Asking Siri to play some music could launch Spotify without having to add “with Spotify” to the end of your query.

And there are many other possibilites here that I won’t bother listing. As a user I think the time is definitely right for Apple to introduce a feature like this. But what about as a developer?

The big question that I have revolves around code that would normally put Safari in your app. The class to do this is SFSafariViewController and it literally puts a Safari view in your app. This allows for the system to use your content blockers and other installed extensions. It also locks the domain to the one provided by the developer when they brought it on screen.

If one of the benefits of setting your default browser to (let’s say) Chrome so you have access to all the Chrome things all the time would it be jarring for a user to see Safari inside of their Twitter app when they tap on a link? Would Apple provide some kind of hook inside of SFSafariViewController to actually show the content of a third-party app like this? If I’ve purposefully gone and set Chrome as my default browser then I sure don’t want Safari ever getting in my way.

There’s also similar code around MFMailComposeViewController for sending emails in apps (I use that in Scorebook) as well as MFMessageComposeViewController for sending iMessage or SMS messages. Would they allow users to pick their email or message client and slide up those experiences as well?

If Apple does allow these third-party apps then it will be the result of a mountain of work touching who knows how many parts of iOS. I’m excited to see what we get in iOS 14 come WWDC this year. We should be hearing logistical details about the conference in just a few weeks. 🍿

If you’ve never seen a diff tool in action (or even heard the term), basically what it does is can take 2 things and tell you the difference between them. Kaleidoscope can diff text files, folder contents in the Finder, git branches, and even images. I use it most frequently in my development workflow when resolving conflicts during code merges but have definitely used its folder support before too. It plugs nicely in to my git app of choice Tower (which I should probably write about too).

I do have a funny story to share about Kaleidoscope in closing. Version 2.0 came out 7 years ago, in early 2013. At that point I was barely writing any code and definitely not professionally. I heard about v2’s release somehow (probably from one of the tech-related Twitter accounts I was following) and Black Pixel was doing some Twitter contests for free copies. I’m a sucker for stuff like that even if I have no idea how to use what I’m winning. I ended up winning a copy and being lost as to what it did. Fast forward a year or so and I’m learning development and see in Tower that it has a way to trigger Kaleidoscope as the diff tool! That was my gateway to a bigger world 🙂

I really hope this new version is a harbinger of things to come and that some day they’ll release a version that I need to pay for. So go check out Kaleidoscope and come to love it as much as I do!

A common anti-pattern is leaving UITableView/UICollectionView cell labels populated with their text content when these cells enter the reuse queue. It is highly likely that once the cells are recycled, the labels’ text value will be different, so storing them is wasteful.

I could have pulled a few more gems from this super helpful post by Rony Fadel, but this first one struck me off the bat. I don’t know how many times I have kept text in a label when I perhaps didn’t need to. I also didn’t know that the right place to nil-out text in reusable views (UI{Table|Collection}ViewCell) is not in their prepareForReuse() method but in the delegate’s didEndDisplaying method instead.

In larger projects with many cell class types this may take some thinking on how to get the message across to a cell type of “time to reset any labels you have”. I know if I were still at zulily this would be something that I’d work to get in place as soon as possible, as I did a lot of really hacky things to collection views in my time there 😀

Prior to the Seattle area getting its first Apple store my family and I went on a vacation to Las Vegas and we went to the Fashion Show Mall so I could see their store. And I had just the question to stump their Geniuses:

I worked at an Apple Authorized Service Center and had been doing service on the iMacs with slot loading optical drives (like the ones pictured above). Whenever I would need to erase a hard drive and restore the operating system I noticed that the desktop wallpaper color matched the color of the case. So a Ruby iMac would get a Ruby colored desktop, and same with Sage green, Indigo blue, and so on. How did they pull this off?

I do also have some inside information to help rule out some possibilities:

• The main logic boards did not know anything about the shell color. There was 1 part per model of iMac and they were not ordered by color of case. These boards hold everything: CPU, graphics, memory, all the ports, all of the guts.

• Same story for the other big board: the analog/video board. It was not ordered by color either.

• The only other real parts inside were the optical and hard drives.

• Except for the speakers.

And that last part is what I think happens. The speakers on these iMacs were colored to match the back case (and you could see them through the translucent base). I think that there was some chip in the speakers that would indicate to the system what color it was and then the system would pull the appropriate wallpaper.

If you or someone you know may happen to know how this worked I would love to know the answer!

PS: Special thanks to the Xcoders group last night for encouraging me to post this after I told the story. It was a ton of fun to speculate together. Community is awesome 🙂

Update 2/15

After a lot of fun discussion and speculation I think Daniel Kennett has the most plausible answer: the color was encoded into the serial number!

VQK? That’s a pink 2nd Gen iPod nano! I spent many years reverse-engineering all things iPod for an app of mine back in the day. pic.twitter.com/Xxg3Yjxnes

— Daniel Kennett (@iKenndac) February 14, 2020

If my memory serves correctly, when we would replace a logic board we would have precisely one opportunity to reset the serial number via a firmware reset tool. I don’t recall what would happen if we failed to update the serial number (and that sure would be a fascinating experiment to run!).

Hopefully this saves future me some time.