Throughout my life, I unconsciously tuned the way I live for the “best” version of Josh. The environments I work in. The tools I obsess over. The routines I keep. The way I recover after social events. The way I hyperfocus. The way I burn out.

But I never fully understood why.

For most of my life, I assumed JoshHoltz.app was running the standard neurotypical operating system. And honestly? For 34 years, things mostly held together.

Until they didn’t.

Recently, the system started crashing harder and harder. Reboot loops. Overclocking. Total freezes. Patch after patch that only made things worse. Something underneath everything wasn’t operating the way I thought it was.

JoshHoltz.app is not running a neurotypical operating system.

And this week, I finally got confirmation of something I think part of me has probably always known.

"I was officially diagnosed with AuDHD (autism + ADHD)."

Suddenly, decades of seemingly disconnected behaviors, struggles, sensitivities, coping mechanisms, hyperfixations, burnout cycles, and “quirks” started resolving into a system diagram that finally made sense.

Discovering the interface/architecture mismatch

We can’t just go from a semi-broken app to a perfectly stable release overnight though. No no no.

First, we apparently need to break the app even more 😅

And honestly, that was probably the hardest part of this journey.

There were both positive and negative cues that eventually pushed me toward getting a serious evaluation.

One of the biggest ones was noticing a recurring pattern: friends casually asking if I was ADHD or AuDHD. One person asking? Whatever. But eventually I realized there was a pattern I might have been ignoring for a very long time.

Which now feels a little ironic.

At the same time, I started noticing myself becoming increasingly overstimulated by things that never used to affect me this intensely:

• sound
• lights
• too many conversations happening at once
• constant notifications
• context switching
• social overload

For the longest time, I genuinely didn’t understand what was happening to me.

But life in your 20s and 30s is very different.

There’s more noise.
More responsibilities.
More unpredictability.
More simultaneous processes running all the time.

And it became much harder to maintain the highly regulated systems and routines I had unconsciously built for myself over the years.

Systems I didn’t realize I deeply depended on to keep JoshHoltz.app stable.

The breaking change

Around September-ish of last year (2025), I decided it was time for a major version update of myself.

I ACTUALLY SCHEDULED AN APPOINTMENT WITH A THERAPIST.

FWIW, that felt like the hardest part at the time.

I was very, very wrong.

I went into that first appointment mostly looking to explore an ADHD diagnosis. I explained where my head was at, how overwhelmed I had been feeling, and how I was struggling with overstimulation that I just couldn’t “shake off” anymore.

I answered a lot of questions about my past, which made sense.

But something felt off.

I kept trying to explain that present-day Josh felt VERY different than past Josh. That was mostly brushed aside, which now feels like the first major red flag that I might have been heading down the wrong diagnostic path.

At that appointment, I was told that what I was experiencing could very well be anxiety.

Which honestly confused me even more.

I worry very little.
I roll with the punches most of the time.
Maybe even too much.

I’m obviously not the medical expert though, so I continued down that path and tried to stay open-minded.

Even while the conversation kept leaning toward anxiety, I still pushed for an ADHD assessment.

I was told there were two options:

• a quicker computerized assessment
• a longer multi-session in-person evaluation

The quick (and cheaper) route seemed reasonable to start with.

So I did it.

The results came back as essentially: “traits of ADHD, but not enough to fully diagnose.”

Honestly, I was disappointed.

It felt like I had mostly been grouped into an “anxiety” bucket instead.

But at that point, I was desperate for relief from the overstimulation and internal chaos I had been experiencing.

So… I started the meds.

I didn’t really know what to expect. But I was willing to try almost anything if it meant stabilizing the system.

And technically… they worked.

The overstimulation from things like lights and sounds became quieter.

But so did everything else.

The meds didn’t just mute external noise.
They muted me.

"The meds didn't just mute external noise. They muted me."

I became way too relaxed.
Way too sleepy.
Way too emotionally flat.

And maybe the weirdest part:

I lost my ability to enjoy building things.

FWIW, I’ve never actually loved “coding itself.” Coding has always been a means to an end for me. I love making things. Building systems. Creating weird ideas and watching them come alive.

But suddenly even that feeling was gone.

The burn and crash

Fast forward to February, and things got really bad.

I’ve learned that if I don’t intentionally schedule long stretches off work way in advance, I simply won’t take them.

Historically, those breaks still involved sitting at a computer doing computer things because… well… I’m a computer person 😅

But this time was different.

I spent almost an entire week unable to leave the couch.

No motivation.
No energy.
No desire to do anything.

Not even the things I normally love doing.

The second week was slightly better, but still deeply not me.

Eventually I needed to take a third week off work.

THIS IS VERY NOT JoshHoltz.app.

Honestly, writing this part now still kind of scares me.

I can’t imagine what it felt like for my teammates and manager hearing that something was this wrong.

And I never want to go back there again.

That was the moment I realized this “major version improvement” I had been chasing was actually moving me further away from myself instead of closer to understanding myself.

I had over-engineered in the completely wrong direction.

This wasn’t the right future for JoshHoltz.app.

My next therapy appointment needed to go very differently.

Revert, research, and rebuild

I’m very bad at explaining how I feel.

(Again, something that makes so much more sense now.)

I spent a solid week rubber ducking with ChatGPT before my next therapy appointment. I gave it context from previous appointments, explained how I was physically feeling, and tried to describe patterns about myself that I liked and didn’t like.

Eventually, we got to the point where it helped me put together a script to request a neuropsychological evaluation.

This is something I genuinely do not think I could have easily done on my own.

Having a robot help organize all of my scattered thoughts, patterns, and experiences into something structured and explainable was incredibly helpful.

The appointment finally came around, and for once things actually felt… easy.

I got exactly what I wanted from that session:

• I wanted off the meds that were changing me
• I wanted further evaluation and answers

Easy peasy!

For now…

Hardest revert ever

I’ve reverted a lot of commits and deployments in my life.

(I’m extremely good at making mistakes and then realizing I made them 😅)

But this revert was different.

I had to taper off the meds slowly, and I was absolutely not prepared for what that process was going to feel like.

This wasn’t a quick rollback.

It was a carefully managed 6-week process filled with physical and mental side effects.

The biggest ones for me were:

• exhaustion
• low motivation
• emotional flatness
• and “brain zaps”

If you’ve never experienced brain zaps before, they’re incredibly weird. The best way I can describe them is:

• a physical zap sensation in your brain
• combined with the feeling of a skipped audio track
• or dropped frames in real life

It’s kind of dizziness.
But also… not really.

Anyway, those 6 weeks obviously affected everything around me:

• personal life
• work
• relationships
• productivity
• energy

I wanted out of the loop badly, but getting out required pushing through one of the hardest transitions I’ve gone through in a long time.

At the exact same time, I was also transitioning at work from Engineering Manager back into an Individual Contributor role.

And honestly? It was kind of my dream role.

I was moving into a much more flexible “free agent” style Developer Experience position where I could build weird things, help developers, experiment more, and operate in ways that fit my brain significantly better.

The timing could not have been worse 😅

I was in the middle of:

• low productivity
• low motivation
• physical side effects
• emotional instability
• burnout recovery

I knew I could do amazing things in this new role.

But I just… couldn’t.

And that disconnect was brutal.

Researching how my brain operates

At the same time, I was also going through the neuropsychological evaluation process.

There was:

1. a long remote intake session
2. a giant in-person testing day
3. a final results appointment

The first appointment was actually kind of… fun?

For the first time in this entire process, I felt like I was talking to someone who genuinely listened and understood me.

She asked questions nobody had asked me before.

And somehow, in a single hour, it felt like we had made more progress than the previous 6 months combined.

The second appointment was… SOMETHING.

It was around 4-ish hours of puzzles, memory tests, attention challenges, pattern recognition, and various forms of “how does this brain actually operate?”

Some parts were really fun.

Others, especially around memory and attention, were honestly pretty defeating.

By the end of it though, I felt strangely optimistic.

Exhausted.
Completely brain-fried.
But optimistic.

For the first time in a long time, it felt like I was actually heading toward answers.

I didn’t know what those answers were going to be yet.

But ANSWERS.

Rebuilding from the results

Today, literally like 5 hours ago as I’m writing this, I got the results.

Waiting for them was brutal.

For two weeks, every possible scenario went through my head.

At the start of the appointment, we talked about how I felt the testing process went. Then we started going through the actual results:

• areas where my brain excelled
• areas where it struggled
• areas where things were inconsistent or all over the place

The overall picture ended up being pretty interesting.

Apparently I’m intelligent (obviously 😉).

I scored very high in:

• visual thinking
• spatial reasoning
• pattern recognition

My working memory was decent.

But my verbal listening and verbal memory scores were… not great.

Which honestly surprised absolutely nobody, including me.

But the bigger conversations ended up being around:

• sensory regulation
• social processing
• overstimulation
• masking
• cognitive fatigue

And then came the final conclusions:

1. Primary autism
2. Secondary ADHD

I was so relieved to finally have an answer.

But honestly… I wasn’t expecting that order.

I had spent months mentally preparing for: “primary ADHD with maybe some autistic traits.”

Not:

1. Autism
2. ADHD

That genuinely surprised me at first.

But the more I sat with it, the more the entire system architecture of my life suddenly started making sense.

The ADHD explained some of the chaos:

• jumping between ideas
• novelty seeking
• hyperfocus spirals
• difficulty regulating attention
• impulsive project energy

But autism explained the structure underneath everything:

• the deep need for predictable systems
• why I unconsciously built highly regulated routines
• sensory overload
• why social interaction can feel both energizing and exhausting
• why I obsess over reducing friction in workflows
• why I need recovery after high-output events
• why I communicate better through systems than raw emotion
• why I’ve spent most of my life designing environments that help stabilize JoshHoltz.app

It also explained something I had never fully understood about myself:

I don’t just like systems.

I depend on them.

"I don't just like systems. I depend on them."

And when enough of those systems break at once, the operating system underneath starts overheating fast.

The beta of JoshHoltz.app 2.0

So… this is where I’m at today.

I’m fully off the medication now, minus a few lingering brain zappies here and there, and I feel like I’m back to the version of JoshHoltz.app that somehow managed to work surprisingly well for 34 years under very specific conditions.

“I’m so back” is the internet phrase, and honestly? Yeah… I do feel that.

But…

That’s not actually good enough for me anymore.

I’m not trying to get back to the old version of myself.

I finally understand the operating system I’m running on now.

JoshHoltz.app 2.0 is being rebuilt for neurodivergent architecture from the start.

And honestly, that changes everything.

YOLO monkey-patching random meds onto the system is probably not the strategy 😅

I need to:

• actually read the docs
• understand the hardware
• talk to people running similar systems
• build healthier defaults
• stop overclocking the operating system until it crashes

This part is going to take time.

But for the first time in a very long time, it actually feels like I’m solving the right problem.

I don’t need to force JoshHoltz.app to run like a neurotypical operating system.

I need to build an environment where this operating system can run efficiently, sustainably, and without constantly overheating itself trying to look “normal.”

Stay tuned for official release

I don’t have an official release date for JoshHoltz.app 2.0.

And honestly, trying to force one probably defeats the point.

Instead, I’m going to do what I do best:

• find patterns
• solve real problems
• build weird things
• accidentally create new problems
• iterate
• have fun doing it

But this time, hopefully in a way that isn’t actively toxic to my mental and physical health.

And genuinely, thank you to my friends, family, coworkers, and the people around me who experienced this whole thing with me.

I know it wasn’t easy.

I disappeared.
I went dark.
I changed.

But looking back now… that version of me was running on a system that was completely overwhelmed and trying desperately to compensate.

I think I finally understand why now.

And honestly?

That feels really good.

This is just my experience. Yours might look completely different — and that’s okay.

I’ve had a stutter since I was about six years old. I hated talking. I hated being the center of attention. I couldn’t speak in front of people. But in 2019, I found the courage to change that. Since then, I’ve spoken at iOS and Swift conferences all over the world. I can’t get enough of this community and sharing my passions with you all.

But beyond that, I have the honor of organizing Deep Dish Swift with my wife, Kari. In 2022, I told her that I may have accidentally started a conference. Without hesitation, she responded, “How can I help?” From that moment, I knew this was going to be something great. She’s also a conference speaker and an engineer, so we aligned on what needed to be done. But she’s the organized one who balances out my chaos. This conference would be nothing without her.

With her help, we’ve had two incredible years of Deep Dish Swift, with a third on the way. There are a lot of challenges in running a conference, but the joy we get from seeing it all come together makes it worth it.

However, there’s one part of organizing a conference that always feels the worst—the CFP (Call for Proposals) process.

The first year of Deep Dish Swift, I did a poor job communicating with speakers whose talks we didn’t accept. I didn’t know exactly what I was doing, so I just used the default response in the CFP system. It wasn’t sincere. It wasn’t me. But I also didn’t know how to do it better. The second year, I wrote something more personal and sincere, but I still don’t think it fully conveyed why and how we select talks.

This year was different. I think I finally understand how we pick talks. This is the email I sent to the speakers whose talks we couldn’t accept this year 👇

Dear Deep Dish CFP Submitter,

This is always the hardest email for me to send, but it’s something I have to do… I regret to inform you that your talk submission(s) for Deep Dish Swift 2025 has not been accepted this year. 😔

As a conference speaker myself, I know how heartbreaking this can be. I really would love to have all of you on the Deep Dish stage. We pour so much time, energy, and hope into crafting a talk submission.

I’ve been thinking about how best to explain how we select talks, and I think I finally have it.

Putting together a speaker lineup is a lot like making a deep dish pizza. We need solid foundational topics and speakers–the crust that holds everything together. We need the classic topics that most conferences have, acting like the cheese and sauce. And then, we need the toppings–those unique, standout ideas that set the conference apart, whether it’s a bold technical deep dive, an unexpected perspective, or something experimental.

There are so many great toppings I’d love to include, but a good pizza isn’t just toppings. A good pizza is balanced, a little unique, and has something for everyone.

So the question isn’t, “How can my talk be better?”–because in most cases, it’s not about quality. Every ingredient in a pizza is great on its own. The better question is, “How can my talk fit into future conferences?”

Some ingredients work well in most pizzas. Some don’t–but when used right, they become the star of the dish. Figure out what kind of ingredient you are and showcase it as soon as possible. Have a couple of different options in mind to improve your chances. You can even reach out to the “chefs” (organizers) before they start planning the next pizza.

I hope this helps clarify why some talks are selected over others. It’s not just about how good a talk is–it’s about how all the talks come together to form something special.

I truly appreciate everyone who submitted talks this year and in previous years. Please don’t stop! There’s always a chance, and always ways to increase that chance. If you’re passionate about speaking, keep showing it. Your special ingredient will find its place.

Hope to see you all on a future Deep Dish stage–or another conference stage–very soon!

Love,
Josh and Kari Holtz

That is all.

Love,
Josh

🍕 Also, please check if Deep Dish Swift if you want to attend a super fun, useful, and welcoming Swift and iOS conference! It’s being help April 27th to April 29th this year in Chicago, IL. It’s our third year and it’s going to be a good one!

Is this thing on?

Okay wow, it’s been nearly 3 years since I last wrote a blog post. I would normaly say here that I’ve been meaning to write more blog posts but that would be a lie. I already get myself into too much trouble working on other things 😅

Are you new here? Wondering what those things are?

The projects I’ll be working on (but not limited to) are:

• Co-founder of Deep Dish Swift
• Lead maintainer of fastlane
• Engineer Manager of Monetization/Paywalls at RevenueCat
• Apps I’ve shipped
  • An Otter RSS
  • ConnectKit
  • What’s My Age Again
  • Oh Crop!
  • Playpen
• Other Stuff
  • DeckUI

But besides that, I also have a family that I love to spend time with that takes priority over all of this.

You aren’t here for that though… you are here because you want to know the madness behind my “Navigation If Needed” SwiftUI view.

👉 BTW, click here to jump to the solution way way way way way way at the bottom.

The Problem

Okay, here is the problem I was running into.

I have a view that has a requirement to show a toolbar with some buttons on it. (See example below)

struct MyViewWithToolbar: View {
    var body: some View {
        VStack {
            Text("This is not a Xib or Storyboard view")
        }
        .toolbar {
            ToolbarItem(placement: .navigationBarTrailing) {
                Button("Restore") {
                    // Restore the user's content
                }
            }
        }
    }
}

Looking at this view, it seems like the toolbar should be visible. However, a toolbar in SwiftUI will only show if the view is in a NavigationView or NavigationStack (which makes sense).

If I was making this view for some of my own apps, I’m 100% in control of the presentation logic so I would know whether I needed to wrap this view in a NavigationView or not.

However, I am making this view for a SDK and I don’t want the user to have to worry about this. I need MyViewWithToolbar to know if it should wrap itself in a NavigationView or not.

The Solution (that I wanted)

I wanted a nice, clean built-in solution to this problem. I was looking if SwiftUI had any way to detect if a view was in a navigation stack or not. Long story short, it doesn’t.

I scoured the web and asked all the AI chat friends that I’ve made and I couldn’t find any “nice” solutions to this. Some suggested to drop down into UIKit and inspect the view hierarchy. I didn’t want to do that. I was looking for a cleaner and pure SwiftUI solution.

The Discovery

After doing hours minutes of research, I concluded that the only pure SwiftUI implementation that could would know anything if a SwiftUI View was in a navigation controller was the .toolbar modifier… but not in the way I wanted. The .toolbar modifier adds the toolbar to a view BUT ONLY if its in a NavigationView or NavigationStack (as I mentioned before).

I started to wonder if I could use the .toolbar modifier as a detector of sorts. The toolbar content can take any view and views have a way to see if they appear so I thought I could use that to my advantage.

Attempt 1: Using onAppear

My first attempt was simple. I wanted to see if using .onAppear would work. I knew that the .toolbar would get conditionally added based on if the view is in a NavigationView or NavigationStack so I added a .onAppear to some content in the toolbar.

Summary… it didn’t work as I hoped. It turned out that the .toolbar would always call .onAppear for the content of the header no matter if it was in a NavigationView or not.

struct Attempt1View: View {

    var body: some View {
        Text("Something")
            .toolbar {
                ToolbarItem(placement: .navigationBarTrailing) {
                    Text("")
                    .onAppear {
                        // I want this to only appear if the view is in a navigation controller
                        print("Please work")
                    }
                }
            }
    }
}

// Goal: I wanted "Please work" to print
// Result: It did print (yay)
struct InNavigationView: View {
    var body: some View {
        NavigationView {
            Attempt1View()
        }
    }
}

// Goal: I wanted "Please work" NOT to print
// Result: It DID print (not yay)
struct NoInNavigationView: View {
    var body: some View {
        Attempt1View()
    }
}

Attempt 2: Using @Environment(.isPresented)

.onAppear was a total lie. It actually isn’t when the view visually appears. I guess its when the view is in some sort of UI hierarchy (not a SwiftUI expert here so take this for what it’s worth).

I did some more Googling StackOverflowing AI-ing and I found I could detect if a view appeared by using the @Environment(\.isPresented) environment variable.

It turns out… this was exactly what I wanted. I ended up creating a navigation detector! 🥳 But like… one that would only tell me if it it detected a navigation view through a print statement 😛 But hey, I could build upon this.

First, here is the IShouldGoToBedView that could do the navigation detection.

struct IShouldGoToBedView: View {
    @Environment(\.isPresented) private var isPresented

    var body: some View {
        Text("")
            .onChange(of: isPresented) { _, isPresented in
            if isPresented {
                print("Please work")
            }
        }
    }
}

struct Attempt2View: View {

    var body: some View {
        Text("Something")
            .toolbar {
                ToolbarItem(placement: .navigationBarTrailing) {
                    IShouldGoToBedView()
                }
            }
    }
}

// Goal: I wanted "Please work" to print
// Result: It did print (yay)
struct InNavigationView: View {
    var body: some View {
        NavigationView {
            Attempt2View()
        }
    }
}

// Goal: I wanted "Please work" NOT to print
// Result: It did NOT print (yay)
struct NoInNavigationView: View {
    var body: some View {
        Attempt2View()
    }
}

The Solution (that I ended up with)

:warning: Warning: This solution is a bit of a hack and I’m so proud of it. I’m sharing it because I didn’t see this solution anywhere else (probably for good reasons) but I think it’s a fun solution and could maybe be helpful to someone else.

Usage

struct ContentView: View {
    var body: some View {
        // This will conditionally add a NavigationView around MyViewWithToolbar if needed
        NavigationViewIfNeeded {
            MyViewWithToolbar()
        }
    }
}

Video Proof

Implementation

// This minimal view does a check if the view is visible rendered
struct ZeroFrameDetectionView: View {
    @Environment(\.isPresented) private var isPresented
    let didDetect: (Bool) -> Void

    @State private var hasReported = false

    var body: some View {
        Rectangle()
            .frame(width: 0, height: 0)
            .onChange(of: isPresented) { newValue in
                if newValue {
                    self.report(true)
                }
            }
            .onAppear {
                // Dispatch once after SwiftUI lay out
                DispatchQueue.main.asyncAfter(deadline: .now() + 0.05) {
                    self.report(false)
                }
            }
    }

    private func report(_ value: Bool) {
        guard !self.hasReported else { return }
        self.hasReported = true
        self.didDetect(value)
    }
}

struct NavigationViewIfNeeded<Content: View>: View {
    enum Status {
        case unknown
        case inNav
        case notInNav
    }

    @State private var status: Status = .unknown

    let content: Content

    init(@ViewBuilder content: () -> Content) {
        self.content = content()
    }

    var body: some View {
        switch status {
        case .unknown:
            // This is where we wait for a (hopefully quick) response
            // if the view is in a navigation view or not
            Rectangle()
                .frame(width: 0, height: 0)
                .toolbar {
                    // Zero-sized detection view:
                    ZeroFrameDetectionView { isInNav in
                        // The first time we know the answer, store it
                        if status == .unknown {
                            status = isInNav ? .inNav : .notInNav
                        }
                    }
                }
        // If the view is in a navigation view, show the content directly
        case .inNav:
            content
                .onAppear {
                    print("✅ IN Navigation")
                }
        // If the view is not in a navigation view, wrap it in a navigation
        case .notInNav:
            if #available(iOS 16.0, macOS 13.0, tvOS 16.0, watchOS 9.0, *) {
                // Using NavigationStack is best generic solution if only need
                // to show a toolbar
                // NavigatonStack toolbars combine nicely in parent NavigationView
                NavigationStack {
                    content
                        .onAppear {
                            print("❌ NOT IN Navigation")
                        }
                }
            } else {
                NavigationView {
                    content
                }
            }
        }
    }
}

Full Test Suite (lol)

struct ContentView: View {
    var body: some View {
        NavigationView {
            VStack {
                NavigationViewIfNeeded {
                    Text("ewfawefaw")
                        .toolbar { // wont show without above ^^
                            Button(action: {

                            }) {
                                Text("Hey")
                            }
                        }
                }
            }
            .toolbar {
                Button(action: {

                }) {
                    Text("And another")
                }
            }
        }
    }
}

The End

This is what it is. Code does what it does. There are guaranteed edge cases in this. The implementation of .toolbar and @Environment(\.isPresented) could change from underneith me.

But I enjoyed problem solving this and I’m don’t hate the solution. I’ve written worse code 🙃

Please let me know your thoughts on this. I’m curious if this is a good solution or if there is a better way to do this. But also PLEASE be nice 😊 As I’ve mentioned, I did this for fun, shared it for knowledge, and warned this is hacky.

That is all.

Love,
Josh

🍕 Also, please check if Deep Dish Swift if you want to attend a super fun, useful, and welcoming Swift and iOS conference! It’s being help April 27th to April 29th this year in Chicago, IL. It’s our third year and it’s going to be a good one!

I gave Hudson my computer to type up his first blog post 🤷‍♂️

Hudson’s First Blog Post

Zzx•¨∫˜˜∫ˆ•≥ …,azaz˘≥………………..///////////////````./`./////////././//////]]]]]/

sxxdsxx.    ˜n

zr zcfgty5ttgfcdx cdvfgryhe5dvzsthy6htgfvcxxdr56r 3

azszxc vjnb ygvc cvbm/,’k;lkjhbvcvbhjij ≈‌gfxdxzzxçgchcgbvxc cfgchvjbknnbhjnhbvcx vgysghfsgvc xcvy78ygfcxddxsz wqwssswssssiiiioiioilz

dxzxdf````````````````zzz n ham   vcxx/.v bnm,a	

xxcx cxztfdxzzdsxzfdxΩxçcv ezxcxvc≈

Happy launch day, What’s My Age Again! 🥳

What is What’s My Age Again?

What’s My Age Again is my solution to me not being able to remember my age. I’m always asking my wife and she doesn’t need that kind of pressure on her. I threw together a quick widget only app in an hour or two 👇

And as I do often, I shared my weird experiment on Twitter 👇 It seemed like it resonated with a handful of people so I decided to polish it and ship it!

I’m constantly asking my wife how old I am so… I made a thing 🙈

“What’s My Age Again” 👇

✨ Configure birthdays in widget (app does nothing)

😅 Also configure family members age! Great for kids when they go from days to weeks to months to years

Maybe launch soon? 🤷‍♂️ pic.twitter.com/WVFsm4Ymfn

— Josh “so many typos” Holtz 💪🚀 (@joshdholtz) February 5, 2022

Why only widgets?

I already debatably stretch myself to thin with fastlane, Indie Dev Monday, other indie apps, and my full-time job at RevenueCat where I really didn’t want to make and maintain another app 😛 Widgets are a simple enough concept to make and maintain and that is all I really wanted to do. They have very little interaction and a simple user interface that doesn’t overwhelm me if and when I want to make changes.

Here are we

This app (if you can call it that) isn’t meant to be some ground breaking huge thing. I wanted this for me but I wanted others to use it (if they wanted to).

Thanks for reading this very short story about What’s My Age Again and I hope that some of you enjoy using this app!

Feel free to tweet me (@joshdholtz) with any feedback, issues, or feature request🥳

This post will briefly show how I have my M1 Mac setup to handle homebrew, zsh, Ruby and Python version managers and how they all interact with Rosetta 💪

TL;DR - The problem was not homebrew or any other tools. I was my weird setup and misunderstanding of how M1 and Rosetta worked 🤷‍♂️

The YouTube Format

There is a YouTube format of this blog post on my YouTube channel over at https://youtu.be/EG-K5n20_HQ 👀

The Problem

I was having mad issues with my develoment environment. Ruby was having issues installing native extensions. Homebrew was having more and more issues installing dependencies for unknown reasons (to me).

Me, M1, and homebrew are just not getting along… again 😭

— Josh “so many typos” Holtz 💪🚀 (@joshdholtz) October 19, 2021

After a day or two of constantly uninstalling and reinstalling homebrew and my other tools, I figured out my issue and my development environment that I wanted to use going forward.

OMG, I finally figured out how to get my M1, homebrew, and Rubies playing nicely 😅

Would anybody like a blog post or video tutorial on how to do this? 🙃

— Josh “so many typos” Holtz 💪🚀 (@joshdholtz) October 19, 2021

It turns out… the root cause of my problem was I was using a build of Alacritty (a terminal ) that was built for Intel so all of my stuff was running in Rosetta without me knowing 🤦‍♂️

Being cognizant of architecture

I would have solved my issues a lot sooner if I knew what architecture my terminal was running in. The options being arm64 or i386.

Zsh prompt

So the first thing I did was add the architecture my terminal was running in into my Zsh prompt. The prompt is the thing the shows before your cursor when you are in a terminal. My prompt already shows the directory I’m in and the git branch of the directory (if I’m in a git repo). I thought it would be cool to also prefix that with the architecture!

This can be done with a custom theme. I was using the robbyrussel theme so I based the joshdholtz theme off of that 💪

Create ~/.oh-my-zsh/themes/joshdholtz.zsh-theme 👇

PROMPT="%(?:%{$fg_bold[green]%}➜ $(arch) :%{$fg_bold[red]%}➜ )"
PROMPT+=' %{$fg[cyan]%}%c%{$reset_color%} $(git_prompt_info)'

ZSH_THEME_GIT_PROMPT_PREFIX="%{$fg_bold[blue]%}git:(%{$fg[red]%}"
ZSH_THEME_GIT_PROMPT_SUFFIX="%{$reset_color%} "
ZSH_THEME_GIT_PROMPT_DIRTY="%{$fg[blue]%}) %{$fg[yellow]%}✗"
ZSH_THEME_GIT_PROMPT_CLEAN="%{$fg[blue]%})"

I modified my ~/.zshrc with ZSH_THEME=joshdholtz 👇

ZSH_DISABLE_COMPFIX=true
export ZSH="/Users/joshholtz/.oh-my-zsh"

# joshdholtz theme shows arch type in the prompt
ZSH_THEME="joshdholtz"
plugins=(git)
source $ZSH/oh-my-zsh.sh

Switching between M1 (arm64) and Rosetta (i386)

It’s important to have a terminal that can run in Rosetta (i386) so that you can build/compile/install things that aren’t able to run on M1 yet. A lot of the suggestions I’ve gotten were to copy Terminal.app and rename it to Rosetta-Terminal.app, click the “Get Info”, and check the Run in Rosetta box.

I don’t like this approach (for me) because I don’t want to have multiple Terminal open that look the exact same. And I don’t expect myself to always be in Rosetta mode. Only when I need it. So I found a way switch my current terminal session using arch --arm64 zsh and arch --x86_64 zsh. These command essentially replace my current Zsh session with one running in the architecture of my chooseing. I used these often enough where I aliased them mzsh (M1/arm64) and ishz (Rosetta/i386). You can see my .zshrc below where I alias these commands.

alias mzsh="arch -arm64 zsh"
alias izsh="arch -x86_64 zsh"

Separate homebrews

The next thing was to have Homebrew installed in M1 and in Rosetta. Homebrew works a little bit differently because M1 Homebrew is installed at in the /opt directory where Rosetta Homebrew is installed in the /usr/local directory.

To handle this for M1, the ran the Homebrew install script in my mzsh session. To handle this for Rosetta, I ran the Homebrew install script in my izsh session.

The tricky part is to re-alias the brew command to point at the correct Homebrew install depending on which architecture you are running in. There is a switch for this also in my .zshrc

if [ "$(uname -p)" = "i386" ]; then
  echo "Running in i386 mode (Rosetta)"
  eval "$(/usr/local/homebrew/bin/brew shellenv)"
  alias brew='/usr/local/homebrew/bin/brew'
else
  echo "Running in ARM mode (M1)"
  eval "$(/opt/homebrew/bin/brew shellenv)"
  alias brew='/opt/homebrew/bin/brew'
fi

Installing Ruby (and other) version managers

Knowing that you are in the correct architecture is key for installing other tools (like version managers).

ruby-install and chruby

My personal favorite Ruby version manager is ruby-install and chruby.

brew install ruby-install
brew install chruby
# put stuff in path in ~/.zshrc that chruby instructions tell you to
ruby-install 3.0
source ~/.zshrc
chruby 3.0

asdf

My next suggestion would be to use asdf. asdf is a complete version manager for multiple runtimes. I use it for Ruby, Python, and NodeJS but it has more.

brew install asdf
# put some stuff in path in ~/.zshrc that asdf instructions tell you to
asdf plugin add ruby
asdf install ruby latest
asdf global ruby latest

But why separate Homebrew installs?

Great question! Most things (that I use) through Homebrew will work perfectly fine on M1 (arm64). However, there are some tools that you need to compile or install that won’t work. We can test this out with Python 2.7.18. Running asdf install python 2.7.18 will fail due to architecture issues on M1. But if you change to Rosetta (using izsh) and run asdf install python 2.7.18, it will succeed 🥳 And now that Python 2.7.18 is compiled and installed from Rosetta, you can actually use it when you are back in M1 (arm64). Just switch back over with mzsh and run python you will see! (But don’t forget to run asdf global python 2.7.18 or asdf local python 2.7.18 first).

Why does this work on M1 (arm64) even though you needed Rosetta for it? Well… here is my understanding of it 😇 Jumping into Rosetta to compile and install it essentially makes an M1/arm64 installation of it after it compiles in the i386 architecture. The M1 Mac don’t have an Intel processor so everything needs to get to an M1 format somehow. So with this above example, we only need Rosetta for the compile and install phase. Now Python 2.7.18 will work anywhere for us!

The End

So yeah, that’s it I think for this post! I just wanted to share my Zsh setup that makes it easy for me to use my M1 and have confidence in building and installing different tools between M1 (arm64) and Rosetta (i386) 😁 I may have some things explained wrong since I wrote this SUPER QUICKLY but hopefully this helps some of you out 🙏

Feel free to tweet me (@joshdholtz) or email me if you have any feedback or questions about this. Thanks for reading and happy Shortcutting!

This whole blog post is centered around my “Cron” Shortcut which you can download here. It takes text formatted like 👇

0 10 * * * Daily Morning Shortcut
0 9 * * 1 Weekly Monday Shortcut
0,30 * * * * Shortcut Every Half Hour

But I recommend you continue reading on 😉

The Problem

Today’s thing was driven by some iOS Shortcuts that I needed to have automated. The three Shortcuts were:

1. Fetch and alert me of the App Store Connect API version every hour (I’m waiting for a big and important update)
2. Tweet the latest Indie Dev Monday article every Monday at 9 am
3. Tweet the number of days since I last started a new Xcode project every day at 11 am

Doesn’t Shortcuts Already Have Automations?

Yes. Yes, it does.

Automating iOS Shortcuts (and soon-to-be macOS Shortcuts in Monterey) to run at a certain time is easy to do. You can configure a Shortcut to run daily, on a specific day of the week, or a specific day of the month. See screenshot below 👇

After setting the schedule, you then need to build your Shortcut but chaining actions together (similar to how you build non-automated Shortcuts). See screenshot below 👇

But it gets tedious if you want to run the same Shortcut multiple times throughout the day. You can’t just reuse the same configuration. You, instead, need to create additional automations.

To get around building the same Shortcut over and over again in each automation, I start off building all my automated Shortcuts as normal, non-automated Shortcuts. This has two benefits.

1. I can test the Shortcut at any time (not just at the scheduled time)
2. I can run and reuse this Shortcut in automations with the “Run Shortcut” action

This approach made it easier to manage and test the Shortcut’s behavior but my automations section started getting out of hand. And once you have a lot of automations, it gets very difficult to see them all and find the correct automation to view or update. There were so many “Run Shortcut” actions but I didn’t know what was being run. This was a side effect of my reuse method from earlier. See screenshot below 👇

I now needed a solution to make both viewing and scheduling new jobs easier and more flexible…

And all the signs pointed to something similar to cron jobs 🤷‍♂️

How Do Cron Jobs Get Scheduled

I’ve been using Unix-like operating systems for the past 17 years for both personal and work. I would often want to automate scripts to run at a certain time (but I don’t remember what specifically for anymore). To do so, I would schedule cron jobs. These jobs are driven by a crontab (cron table). See example below 👇

1 0 * * * printf "" > /var/log/apache/error_log
45 23 * * 6 /home/oracle/scripts/export_dump.sh

The format of this is defined by 👇

# ┌───────────── minute (0 - 59)
# │ ┌───────────── hour (0 - 23)
# │ │ ┌───────────── day of the month (1 - 31)
# │ │ │ ┌───────────── month (1 - 12)
# │ │ │ │ ┌───────────── day of the week (0 - 6) (Sunday to Saturday;
# │ │ │ │ │                                   7 is also Sunday on some systems)
# │ │ │ │ │
# │ │ │ │ │
# * * * * * <command to execute>

This is the perfect user interface for automating jobs. It’s been used since the beginning of time in Unix and I wanted to use it for Shortcuts. I’d easily be able to see all of my scheduled Shortcuts on one screen. It would also be very painless to edit the schedule times or add and remove Shortcuts from the list. Pretty user interfaces are nice and what I would expect from Apple but that’s not what I needed. Most people probably don’t want to use their mobile device as a driver for many time-based automations. I, however, do 🙃

So even though Apple doesn’t give me crontab capabilities for scheduling natively in Shortcuts, I decided I would try to build it myself 💪

Architecting the Cron Job Shortcuts

Instead of using crontab to run a script (like it would on a Unix-like system), I decided to use the crontab syntax to run a Shortcut by name. This is all made possible by the “Run Shortcut” action I talked about earlier. There are two things needed around the crontab to make Shortcuts behave like cron jobs.

1. A system to parse crontab and execute Shortcuts by name
2. A system to regularly run the parsing and execution

The overall flow looks like this 👇

Creating the crontab Shortcut

The system to regularly run the parsing and execution of Shortcuts is going to be driven by Shortcut automations. Previously, I have been defining the specific Shortcut I wanted to run at each time in automations. Instead of doing that, this cron job approach will run the same Shortcut every hour and half hour. The Shortcut will run a new Shortcut named crontab. See screenshot below 👇

Even though real Unix-like cron jobs can be run at any minute, running the crontab Shortcut every hour and half hour gave me enough power and flexibility to cover all of my needs. The crontab Shortcut itself is simple. There is a text action that holds the crontab syntax (as mentioned earlier). This text is passed to another action called cron. See screenshot below 👇

☝️ This is the exact Shortcut automation configuration that I have scheduled on every hour and every half hour. It’s as simple as it can get and doesn’t ever need to be changed.

In this example, “Fetch App Store Connect Version” is run every single hour. “Jobs - New Xcode Project” is run every day at 11 am. “Indie Dev Monday - Tweet” is run only Monday at 10 am.

And that’s it 😉 I mean, that’s not it because the cron Shortcut is complex. I’ll explain that next 😊

ANYWAY… Adjusting the time I want my Shortcuts to run is now really easy! Let’s say I rename “Indie Dev Monday” to “Indie Dev Monday, Wednesday, and Friday”. And let’s say I wanted to change “Fetch App Store Connect Version” to run from every hour to every half hour. All I have to do is change my crontab from…

0 * * * * Fetch App Store Connect Version
0 11 * * * Job - New Xcode Project
* 10 * * 1 Indie Dev Monday - Tweet

to…

0,30 * * * * Fetch App Store Connect Version
0 11 * * * Job - New Xcode Project
* 10 * * 1,3,5 Indie Dev Monday - Tweet

This took all of about 10 seconds 🙌 Adding new automations to run every half would would have required me to make 24 brand new Shortcut automations without the cron job approach 😝

Creating the cron Shortcut

This is a beast of a Shortcut. It has almost 200 actions that do text parsing, date math, validation 🤯 There is a screen recording of the actions in the Shortcut below but I will list out the high level steps below since that’s easier to process 😉

Download “Cron” Shortcut 👉 Click here

1. Accepts text input in crontab syntax
2. Reads crontab line by line and maps to list of dictionaries (easier to look up in further processing)
   1. Splits line by spaces
   2. Maps specific index to a variable (0 is the minute, 1 is the hour, etc)
   3. Verifies Shortcut name exists and errors if it doesn’t
   4. Takes these variables and saves a dictionary
   5. Appends dictionary to list
3. Iterate over crontab list of dictionaries to determine which need to be run
   1. Checks if the day of the week passes
      1. Passes if an exact match or wildcard (*)
   2. Checks if a month passes
      1. Passes if an exact match or wildcard (*)
   3. Checks if the day of the month passes
      1. Passes if an exact match or wildcard (*)
   4. Checks if an hour passes
      1. Passes if an exact match or wildcard (*)
   5. Checks if a minute passes
      1. Passes if an exact match or wildcard (*)
   6. If all passed, appends to list of Shortcuts to run
4. Iterate over Shortcuts to run list and run Shortcuts
   1. Call “Run Shortcut” with the name of Shortcut

And that’s it! That’s the cron Shortcut that does all the heavy lifting 😊 As seen above, it’s broken down into three main parts. The first is mapping the crontab text to a list of dictionaries. The second is taking the full list of Shortcuts and filtering it down to only the Shortcuts that needed to be run at this exact time. The third is executing the Shortcuts.

This was split up this way for a few reasons:

1. Easier to develop and debug the separate parts if something goes wrong
2. Shortcuts can sometimes take minutes to run which would ruin the date math 🤷‍♂️ Moving all the parsing and checking upfront allows the Shortcuts to take however long they need to

I lied, here is a video of the Shortcut if you want to watch it 😉

The Negatives

There are sooooooooo many negatives with this approach 😅

1. Large initial setup of automations running every hour and every half hour

That is 48 automations for my setup! But yours may not need this. Maybe you only care about every hour or only the hours you are awake. You don’t need to set up all the automations for every hour if you aren’t going to use them. I just did because I could

2. Notifications on every run of the crontab automation

Automated Shortcuts will always send you a notification when they are going to be run. It’s nice to know that your automation is going to run but this means I get 48 notifications that say something like “At 8:00 pm, daily - Running your automation” 😛 It’s not useful and some people may find it annoying but I’m fine with it!

3. Shortcuts run sequentially and will stop if one fails

There are some times during the day or week that I will have multiple Shortcuts being run at the same hour. There is no way to kickoff multiple Shortcuts at one time so the Shortcuts need to run sequentially. Sequential is not necessarily bad. It does mean it will take a longer time for all the Shortcuts to finish because they can only run one at a time. The bad comes in if one of them fails. If a Shortcut errors while being executed from “Run Shortcuts”, the whole Shortcut stops. This means any other Shortcut that was supposed to run won’t get run 😔

This isn’t a problem for me since I’ve designed my automated Shortcut in a way where this shouldn’t happen. But it still might 🤷‍♂️

4. Approving Shortcuts to run Shortcuts

I don’t remember if this was added in iOS 14.6 or iOS 15 (Beta) but there are a lot of permission prompts that you will need to accept for your automations to be fully autonomous (that sounds weird 😬). The first time a Shortcut runs a Shortcut with the “Run Shortcut” action, Shortcuts will prompt you for your approval. This is a safety measure of some sort (which I think I approve of) but it does require some user interaction from you the first time.

The End

I do use this every day but this isn’t meant to be the most stable or efficient Shortcut. This is mainly just a fun experiment for me 😇 I wanted to make it easier for me to view and edit my automated Shortcuts while also testing my Shortcut making abilities. I’d say that I succeeded in both of those things ✅

I also wanted another thing to blog about 😉

Feel free to tweet me (@joshdholtz) or email me if you have any feedback or questions about this. Thanks for reading and happy Shortcutting!

Happy launch day, Oh Crop! 🥳

What is Oh Crop?

Oh Crop is my latest iOS app that will crop a photo to look like an emoji either in-app or through a Shortcut action 👇

Why did you make Oh Crop?

It was an accident 🤷‍♂️ It was initially meant to be nothing more than an empty app that had an iOS Shortcut for cropping an image to a circle. I needed this for automating my processes around preparing, writing, and releasing new Indie Dev Monday issues.

Indie Dev Monday is my newsletter that spotlights one or two indie developers every week. The issue contains a profile picture of the indie developers – which I usually pull from Twitter – that gets displayed in both the web version and the email version of the newsletter. The easiest way to have a consistent look between the two versions was to create a circle version of the photo. The first few issues were cropped manually through some tool but I eventually wrote a small Ruby script to download and crop the photo to a circle.

This process was technically working fine but it required that I always had access to my Mac for preparing and releasing issues. This was okay until I became a parent in December of 2020 🥰 Since then, a majority of my issues have been prepped, written, and released from my iPhone – as it was easier to use a phone while walking or rocking a baby than awkwardly using a computer 😛 Even though I was doing this all through my phone, I still had to remote into my Mac to run my automation scripts. I didn’t like having to do that so I decided I want to move everything to iOS Shortcuts.

I had no trouble converting my scripts to Shortcuts and the majority of the Shortcuts used built-in actions provided by iOS. The one action I was struggling to find was cropping an image into a circle. I didn’t have any existing apps installed that could do it and I couldn’t easily find an on the App Store that could do it…

So I decided to make my own 😜

I like to take odd approaches when solving problems. I get a thrill from solving problems (even if the problems are self-inflicted). Cropping an image to a circle is pretty trivial when writing an in iOS… But I wanted to have some fun 😈

What was the solution?

Instead of using code to crop the circle, I decided it would “cool” to use the circle emoji (🔴) to crop the circle.

The steps to do this ended up being:

1. Find the font size needed for the emoji to fill the photo
2. Convert emoji from text into an image
3. Use the emoji image as a mask against an all-white image to create an inverted emoji mask
4. Use the inverted emoji mask against the user-provided photo

The result of this is a photo that looks like the emoji used 😁 In this case… it was just an over-engineered circle.

From there, I decided to try out some other emoji shapes that people might like or use 🟥, 🔷, or ❤️. But then I started to wonder what using other emojis would look like…

The 🐩, 🚽, or 🗑 were some of the first that I used! But I wanted to try them all. My wife and I spent unknown amounts of time trying out all of the emojis 😛 It was hard to pick a favorite because different kinds of photos look better (and worse) with different emojis.

At this point there no functional app and no plans to release the app. It could crop photos to any emoji but I using it only with iOS Shortcuts to crop a photo to a circle with the 🔴 emoji for my Indie Dev Monday issues.

Why did you want to release this app?

Straight up… I wasn’t planning on releasing this at all. I made this app to solve my needs and that is all I wanted from it.

The only reason that pushed me over the edge was how much of a pain it to keep a non App Store version of an app on my phone 😛 It requires the app to be installed as a development build (installed directly through Xcode to my phone) or as a beta app through TestFlight.

The problem with the development build is that it requires valid certificates and provisioning profiles through my Apple developer account. This would be fine if I wasn’t mean to my account 🙃 Because of the nature of my day job (maintaining fastlane), I will often revoke all of my certificates and delete my provisioning profiles. This is fine (for me) unless I have a development build of an app on my devices. When the certificate is revoked or the profile is deleted, the app will no longer run. The only way to get it to run again is to recreate the certificate and profile and manually install a new build. I’m too lazy for that…

Distributing the app as a beta app through TestFlight won’t have any side effects from revoking and deleting certificate and provisioning profile issues but the app version submitted to TestFlight will expire after 90 days. I didn’t want to have to keep uploading new builds just to keep the app alive.

So the only logical thing to do is launch the app on the App Store 😅

However, I have a rule where I won’t launch an app unless it has a good name (which should be a pun) and good looking app icon. On top of this, I also want to use app launches (even for small apps like this one) as a practice ground for leveling up my marketing skills (websites, press kits, graphics, videos, etc).

How did this become Oh Crop?

I needed a name, app icon, and a concept to make this interesting enough to release on the App Store. And the way I got this name is slightly embarrassing. The name “Oh Crop” hit me while I was walking into a bathroom 🤦‍♂️

1. The app was meant for cropping circles so the “Oh” sounds like “O” which looks like a circle
2. “Oh Crop” sounds like the phrase “Oh Crap” which made me giggle ☺️
3. Because of the “Oh Crap” reference, I could make the app icon a really cute version of the 💩 emoji

With the app name and icon figured out, the next steps were to bring “Oh Crop” and “Oh Crap” into the app itself. I wanted to add a level of fun to the app but also something that wasn’t too much work for either me as the developer or the user.

What if… the user could randomly get a 💩 emoji instead of the one this asked for?

I started to hard fall in love with this idea. It was easy to implement and played really well into the “Oh Crop” and “Oh Crap” 😁 Ideas for this started coming fast. This was no longer just an iOS Shortcut app.

I first added a label that showed what odds of success the user had when picking an emoji for their photo. The success rate is based on a random number generator seeded from the day so that it’s the same for every user each day. From here I create a new screen where the user can see a 7-day forecast of the success odds. Users can use this to find the day they had the best chances to successfully crop to emojis.

This decision to have random 💩 emojis backfired when I tried to release a new issue of Indie Dev Monday a few weeks ago. I almost released an issue with a 💩 shaped profile picture of one of my indie devs 😂 After that I decided to add an in-app purchase to unlock the ability to disable the 💩.

After that there was one night where I couldn’t sleep… so I decided to add widgets. I first added a single widget to view the 💩 chance percent. That wasn’t enough so I also added a 7-day forecast widget to go with it. At this point, the app itself still didn’t feel like it had enough substance to it. I wasn’t going to crop photos every day but I wanted to see some of the fun croppings that I created. I added a “widget album” feature. The user can create albums of emojis and photos. A widget can be configured to show a certain album and would rotate through random emoji and photo combinations.

This app was only meant to be an iOS Shortcut that could crop photos to circles. And now that plus this emoji cropper and emoji photo widget thingy. I think after that is where I decided I needed to stop and release this 🤷‍♂️

Here are we

This app isn’t meant to be a serious app. This isn’t meant to be an app that I can make a living off of. This isn’t an app that everyone will enjoy. This app wasn’t ever meant to be used by anybody else.

The result of this accidental app creation was the most inefficient and over-engineered way of cropping an image to a circle. But I don’t care because I had fun making and release this app! Being able to create things like this is why I’m a developer ❤️

Thanks for reading my story about Oh Crop and I hope that some of you enjoy using this app!

Feel free to tweet me (@joshdholtz) or @OhCropTheApp with any feedback, issues, or feature request🥳

fastlane has one main repository under the https://github.com/fastlane/fastlane organization… but that is not the only one. There are about four other repositories that I need to monitor regularly. There is also the https://github.com/fastlane-community organization which contains fastlane plugins and dependencies that fastlane users rely on that needed a new home 😇 There are a total of 19 repositories in there that need some monitoring. Most of these repositories aren’t super active but are still active.

I have GitHub notifications enabled for repositories but it’s very, very easy to let important notifications slip by. I needed a tool that helps me monitor the health of these repositories while also giving my GitHub notifications a supercharged filter to show me notifications that I might have missed.

And that tool is “Gargamel” 😈

Gargamel

Gargamel is a non-opinionated monitoring dashboard powered by a YAML file. It was meant to work only with the GitHub API but actually can work with any API.

That probably doesn’t mean much so keep reading about the requirements, the development decisions, and the product 😉

The Requirements

Gargamel is 100% intended to an app for 100% me 😊 Going into this I did not take anybody’s needs except myself into this. I needed a tool that fit my very specific needs. With that in mind, the first thing I did was put together some quick notes on what I needed to make. But the important part wasn’t what I needed to make… it was also what I didn’t need to make. I wanted to make sure I boxed my expectations into something that didn’t get out of hand 😇 I didn’t want to start polishing the app and making it super performant from the beginning. I wanted something that took me a few partial days of hacking that “just worked”.

## Description
Dashboard to monitor GitHub repositories and associated notifications. Also allows a custom calculated health or warning system when attention is needed.

## MVP
- YAML configuration file
- Repo view
    - Org/name
    - Custom field and value
        - https://stackoverflow.com/a/21233623
- Notification view
    - Group notifications by repo
    - Filter notifications (better than GitHub)
        - Allow batch clearing of notifications
        - Eample
            - Things fastlane bot closed
            - PR status changes
            - PR notifications
            - Issue notifications
            - Discussion notifications

## Things to not care about
- Speed and caching
    - This will not be looked at often (maybe only at start, middle, and end of day)
- Background refresh
    - Might be a long running job because of number of repos and configurations
    - Could run in background but not necessary (especially on iOS)
- Don't make pretty
    - Just work

The Development Decisions

Based upon these requirements I set for myself, I decided Gargamel would:

• Be a SwiftUI app (for macOS and iOS)
  • Rapid development
• Don’t use persistent storage (Core Data)
  • Mapping responses is too much effort for what I wanted
  • Cache will almost always be invalidated
    • Data changes frequently
    • I will only refresh maybe a few times a day
  • Use URLCache with URLSession
    • GitHub API supports ETags
    • Will prevent unnecessary data transfer (quicker response times) if no changes
• Use YAML for configuration
  • No UI needed besides SwiftUI’s TextEditor
  • Very flexible if I run into roadblocks and need to pivot
  • YAML has “anchors” which can be used to reuse basic auth and code definitions
• Run data filtering and view configuration in JavaScriptCore
  • I did not want to hardcode any logic in Swift
  • Each type of view was going to be configured very differently
  • API responses will get fed into a function fun in JavaScript Core
    • Can optionally filter data
    • Return a JavaScript object that configures the few

YAML Configuration

1. YAML drives the views (either a grid or list type)
2. Views have API endpoints that will get requested
3. Views get defined with code sections that will be executed using JavaScriptCore
4. API responses get forwarded and executed in JavaScriptCore
5. SwiftUI renders data return from JavaScriptCore

Here is a simple sample that displays fastlane/fastlane and fastlane/docs in a grid view:

aliases:
  personal_token: &personal_token
    username: "YOUR_GITHUB_USERNAME"
    password: "YOUR_GITHUB_PERSONAL_ACCESS_TOKEN"
  repo_health: &repo_health |
      function(repo, issues, pulls) {
        // Need to filter out pull requests
        issues = issues.filter(function(issue) {
          return !issue.pull_request;
        })

        return {
          “fields”: [
            {
              “name”: “Open Issues”,
              “name_weight”: “bold”,
              “value”: issues.length
            },
            {
              “name”: “Open Pulls”,
              “name_weight”: “bold”,
              “value”: pulls.length
            }
          ]
        };
      }
views:
  -
    name: 👀 fastlane
    type: grid
    items:
      - 
        title: fastlane/fastlane
        subtitle: 
        endpoints:
          -
            endpoint: https://api.github.com/repos/fastlane/fastlane
            basic_auth: *personal_token
          -
            endpoint: https://api.github.com/repos/fastlane/fastlane/issues?state=open&per_page=100
            basic_auth: *personal_token
            all: true
          -
            endpoint: https://api.github.com/repos/fastlane/fastlane/pulls?state=open&per_page=100
            basic_auth: *personal_token
            all: true
        code: *repo_health
      - 
        title: fastlane/docs
        subtitle: 
        endpoints:
          -
            endpoint: https://api.github.com/repos/fastlane/docs
            basic_auth: *personal_token
          -
            endpoint: https://api.github.com/repos/fastlane/docs/issues?state=open&per_page=100
            basic_auth: *personal_token
            all: true
          -
            endpoint: https://api.github.com/repos/fastlane/docs/pulls?state=open&per_page=100
            basic_auth: *personal_token
            all: true
        code: *repo_health

The Product

I’m very happy with what I’ve thrown together with fairly minimal work 😊

I have…

• 2 grid views for the fastlane and Fastlane-community organizations
  • Every repo monitors
    • Number of open issues
    • Number of open PRs
    • Last release
  • Main fastlane/fastlane repository also monitors
    • Number of issues since last release
    • Number of open regressions
    • Number of open regressions since last release
• 5 list views
  • List fastlane/fastlane regression issues
  • List fastlane/fastlane issues with a lot of reactions
  • List fastlane/fastlane notifications that are only PRs
  • List fastlane/fastlane notifications that are only issues
  • List fastlane/fastlane notifications that are only discussions

The grid views are what I was really after when making Gargamel. It’s not super pretty but it allows me to easily see the health of all of fastlane’s parts 😎

The notifications lists aren’t very interactive at the moment and I’m not sure if I will implement anything for them in the future. This is mainly to get my attention to attend to these issues somewhere else. 🤷‍♂️

Side note: I’m currently testing out Lotus for managing GitHub notifications

My YAML Configuration

There is a lot to this YAML file 😬 A lot of it is copy-paste and I may work on finding ways to trim this down in the future but… I don’t expect this to change too often. This file can easily be edited in a text editor (which I don’t want to recreate).

Screenshots

These are screenshots that match the YAML configuration above 👆

fastlane

fastlane-community

fastlane regressions

fastlane big reactions

Notifications - fastlane pull requests

Notificatinos - fastlane issues

Notifications - fastlane discussions

The Future

I’m not exactly sure where I’m going to take Gargamel in the future. I made this for me but I also wanted to share it because I love it 😊 I don’t really want to productize it. That’s a lot of added pressure and I’m not sure I could make everybody happy. I’m thinking of open sourcing it if other find that this would be useful. I don’t want to recruit anybody to help because that is added pressure but I’d be happy if others found excitement in this.

If you see any issues in this article, have any feedback, or would have interest in contributing to Gargamel, please feel free to tweet me at @joshdholtz or email me.

Happy side projecting, everyone! 😜

This blog post is 100% my thoughts and opinions. It does not reflect fastlane’s or Google’s thoughts and opinions.

Also, note that this blog post is not critiquing or complaining about the enforcement of two-step/two-factor. This blog post is only here to help users understand how they could be affected and the options they have.

We good? Let’s get started.

• Introduction
• Comparing “two-step verification” vs “two-factor authentication”?
• So… Will this affect you?
  • Do you already have an Apple ID account with 2SV/2FA enabled?
  • Do you use Xcode and the App Store Connect website?
  • Do you run fastlane locally?
  • Do you run fastlane on a CI?
• Other Changes You Might Need To Make
• If you REALLY need Two-Step Authentication on CI… there are ways 😈

Introduction

Apple is requiring that all Apple ID accounts that sign in to App Store Connect turn on two-step verification or two-factor authentication this month. This is a good move as it does increase the security for all Apple IDs and apps on the App Store. It will however have some negative effects on accounts that are used for automation.

This email was sent out by Apple on November 20th, 2020.

Starting February 2021, additional authentication will be required for all users to sign in to App Store Connect. This extra layer of security for your Apple ID helps ensure that you’re the only person who can access your account. You can enable two-step verification or two-factor authentication now in the Security section of your Apple ID account or the Apple ID section of Settings on your device.

Most users won’t be affected by this. Some users will be mildly annoyed by this. But this change will be crippling to a handful of users.

But which group do you fall in?

I’ve had this question come my way numerous times now so let’s answer it once and for all 😊

Comparing “two-step verification” vs “two-factor authentication”?

We could go into a lot of detail about the differences between two-step verification (2SV) and two-factor authentication (2FA). There are plenty of blog posts that get more technical but we are going to keep it simple today. Below are how most Apple ID accounts will see two-step verification and two-factor authentication.

Two-Step Verification (2SV)

Two-step verification is powered by a phone number. After signing in to your Apple ID account, 6 digit verification code is sent via SMS or phone call. This code will need to be entered into the form into the device you are logging into.

You can also have multiple phone numbers attached to your Apple ID account. This is great if you have a team Apple ID with multiple people that need to sign into it. These phone numbers can be set up on appleid.apple.com. This was the first additional security factor added to the Apple ID account.

Two-Factor Authentication (2FA)

Two-factor authentication might be the form most people are familiar with. After signing in to your Apple ID account, this security method shows a popup on your Apple devices (iPhone, iPad, Apple Watch, Mac) that says something like “Apple ID Sign In Requested” with a location and map of where it’s being signed in from. After you click “Allow”, a 6 digit code appears. This 6 digit code is what you enter on the device your logging in from.

Apple will always attempt the 2FA method first if it’s possible. This security step works great for individual accounts but it less great for Apple IDs that are shared by a team.

Luckily, you can always fall back to 2SV! You will see a button/link that says “Didn’t get a verification code?” that will take you two an option to use a phone number for either SMS or phone call verification.

So… Will this affect you?

I can’t answer this for you but I can help you answer it 😇 I made a flowchart that should lead you to your answer. This flowchart does not cover every use case but it should hopefully be a good compliment to the questions that are about to follow.

Do you already have an Apple ID account with 2SV/2FA enabled?

This new requirement Apple is enforcing this month (February 2021) is for Apple IDs that don’t already have 2SV/2FA enabled. If you already have it then the following reading will just be for your enjoyment 😉

If you don’t have 2SV/2FA enabled, your life will be changing a little bit. Keep reading to figure out how 👇

I have a few Apple IDs that I manage. My Apple ID has had 2SV/2FA enabled for a long time now. But I’ve also managed several Apple IDs that did not have 2SV/2FA enabled. These accounts were used specifically for fastlane automation (locally and on CIs). The passwords were either stored in my local Keychain Access or secure environment variables on the CI. I never had to worry about my automation stalling because these accounts only needed email and a password.

Do you use Xcode and the App Store Connect website?

You will probably only be affected a little bit when using Xcode and the App Store Connect website to upload and release your apps.

Xcode allows you to sign in to your Apple ID through the Preferences window. I don’t remember if signing into your Apple ID through Xcode presents a 2SV/2FA dialog but this might be a place where you see the new security flow.

You will also start seeing the 2SV/2FA prompts when signing into App Store Connect (appstoreconnect.apple.com). As mentioned earlier, you will see a new input for 2SV/2FA codes after entering your email and password. I can never pinpoint the exact session length but you should be able to go between 15 and 30 days without needing to use 2SV/2FA again.

Do you run fastlane locally?

fastlane has historically only offered Apple ID as the only login method when interacting with Apple’s services. There was a recent addition of authenticating with the App Store Connect API Key but the majority of users that are probably questioning 2SV/2FA have not moved over to that yet.

But… if you are still on Apple ID and only run fastlane locally, you will experience a very minor change. The change won’t even be in your day-to-day work. It will just be a few times a month or so 😊

fastlane’s Apple ID login works the same as the web login to App Store Connect website mentioned above. Every 15 to 30 days, fastlane will prompt you for a 2FA code. This will popup that system dialog on your Apple devices. You will simply need to enter that 6 digit code in your CLI.

fastlane also supports 2SV if you don’t want to use 2FA. Instead of entering in the 6 digit code, type in either “sms” or “phone” and fastlane will fallback to using your phone number as the two-step method.

Besides needing to enter this code whenever the sessions expire every few weeks, you really shouldn’t notice any big changes.

Do you run fastlane on a CI?

This is where a majority of the heartaches and headaches will come from 🙃 fastlane is built to run as easily on a CI as it is on a local machine. The enforcing of 2SV/2FA, however, will end up taking down most CIs that use fastlane that use Apple ID authentication. That sounds pretty grim… but it is not the end of the world! There are two solutions for this.

The first is to keep using the Apple ID authentication but with a pre-generated session. The second is to migrate from using Apple ID authentication to App Store Connect API Key authentication.

Keep reading to learn which is best for you (and your team).

Option 1: Keep using Apple ID but with pre-generated session

Apple requiring 2FA/2SV doesn’t mean that you can’t still use your Apple ID to authenticate on a CI. But it does mean that you will have a little bit more maintenance/upkeep to have a valid Apple ID session on your CI.

You previously may have put your Apple ID email address and password in your CI’s secure environment variables. This won’t work anymore. fastlane will attempt to prompt for a 2FA/2SV code which will either halt or fail your CI process. But how do we get around this? The trick is now to generate a session on your local machine.

Instead of setting your Apple ID email and password which creates a new session on your CI, you will instead set the FASTLANE_SESSION variable. So what is this FASTLANE_SESSION value? You can think of it as the cookie that your browser stores when you login into App Store Connect and enter your 2FA/2SV code there. That valid session cookie hangs around for some time (15 to 30 days) and so that you don’t need to log in or enter the 2FA/2SV code again.

We can do something similar with fastlane! All you need to do is run fastlane spaceauth on your local machine. You will need to enter your Apple ID email, password, and 2FA/2SV code. This command will then output the value that you need to use with the FASTLANE_SESSION variable.

It’s more work than you are currently doing but it shouldn’t be a daunting amount of work. The worst part is that you may have to restart your CI job when your existing session expires.

💡 Is it too exhausting navigating the user interfaces of your CI? Well.. your CI might have an API you can use for setting environment variables! You could create a fastlane lane (that you run locally) that generates the FASTLANE_SESSION and programmatically updates it on your CI for you 😉

• Docs on FASTLANE_SESSION
• Docs on pre-generated session

Option 2: Migrate to App Store Connect API Key

This is my recommended approach if you can make this work for you as migrating from Apple ID to the App Store Connect API Key should be a minimal change for most users.

Instead of using the username option or FASTLANE_USER/FASTLANE_PASSWORD environment variables, you would use the api_key or api_key_path options or the APP_STORE_CONNECT_API_KEY or APP_STORE_CONNECT_API_KEY_PATH variables 😊

A majority of the tools/actions have support for these new options/environment variables:

• Tools
  • cert
  • deliver
  • match
  • pilot
  • precheck
  • sigh
• Actions
  • app_store_build_number
  • latest_testflight_build_number
  • register_device
  • register_devices
  • set_changelog

It should be a small code change to make the change over for these tools. I recommend going this route as this uses an official API that is supported and documented by Apple. It’s a more stable path for fastlane to use compared to the Apple ID auth APIs.

• Docs on App Store Connect API

But… if you use the custom Spaceship code, produce, pem, or download_dsyms this may not be the best option for you. These tools cannot be fully supported by the App Store Connect API Key yet. The official APIs for these are not released yet. I don’t know an ETA for these yet but I’m hoping it happens soon 😊

Other Changes You Might Need To Make

Keeping your Apple ID auth with FASTLANE_SESSION or migrating to the App Store Connect API Key might not be enough for you.

Maybe there are some tools you use that aren’t available with App Store Connect API? Maybe you want to move your CI away from using Apple ID and App Store Connect API auth altogether?

Below are some situations you may run into and how to possibly fix them. This isn’t the complete list but I’m hoping it will help you think of other possible solutions 😉

#1: Rethink download_dsyms strategy

Since the announcement of bitcode in Xcode, the download_dsysm has been a crucial action to a lot of users. Sending the bitcode to App Store Connect allows Apple to optimize the binaries for a different distribution of the apps. This makes the binaries slightly different and can make crash logs different. Developers need to pull down these new dSYM files from App Store Connect to properly de-symbolicate their crash logs. The download_dsms is an action that you would run after the build is done processing to download these dSYM files from App Store Connect with your Apple ID.

But now that Apple ID will have 2FA/2SV, you may need to adjust your fastlane setup.

Run locally or in a separate job

In most cases, the dSYM doesn’t need to be downloaded right after a build has finished processing which means that you might not need to run download_dsyms on your normal CI job.

This could instead be run on a separate job that runs once a day or a few times a week. Moving it to a separate job will prevent the job from failing if that FASTLANE_SESSION expiries.

You could also move this to a job that just gets run locally whenever you start your day 🤷‍♂️

Can you disable bitcode? Maybe you don’t need download_dsyms

Or maybe… maybe you don’t even need bitcode?! If you disable bitcode, you can use the dSYMs directly from your Xcode build. Now you don’t even need to worry about download_dsyms action 🤷‍♂️

Just disable bitcode. It has no measurable benefits. (Also, generated dSYMs are often broken/incomplete)

— Peter Steinberger (@steipete) February 13, 2021

#2: Do you even need Apple ID or App Store Connect API Key?

If you aren’t able to make FASTLANE_SESSION work for you or if you can’t use the App Store Connect API Key for some reason, you aren’t stuck! You can still set up a CI that signs and uploads binaries with either of those 😏

If you are making use of match with read-only mode for signing, you don’t need to make use of any auth. gym also does not need any auth to build and sign your app.

If you are uploading your binary to the App Store or TestFlight, you can use either deliver or pilot with FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD. This does not require Apple ID or the App Store Connect API Key.

• Docs on Application Specific Passwords
• Docs on pilot with Application Specific Password

#3: produce and pem won’t fully work with App Store Connect API Key

produce and pem are the last two tools that have not had a big migration over to the new App Store Connect API. The reason being there are currently some App Store Connect APIs missing that makes this possible. Those APIs are:

• Creating push certificates
• Creating apps on App Store (you can create new app identifiers on Developer Portal)

With that being known, produce and pem will still need to use the Apple ID auth for the time being. If you need to use these in your flow, you will need to make use of FASTLANE_SESSION or find a way to split up your jobs.

These tools will be updated as soon as they possibly can when the new APIs become available.

#4: Do you use a shared Apple ID? Add multiple phone numbers for Two-Step Authentication

I’ve mentioned this above a little bit but I just wanted to call this out again. Some users like to run fastlane locally but with a shared Apple ID that is only used for fastlane related things. These Apple IDs will also be subject to the 2FA/2SV requirement.

If you’d like to still use these not like the 2FA/2SV interrupt your workflow, your best bet here is to set multiple phone numbers on this Apple ID which can be used for 2SV. If the user gets hit with needing to use a 2SV, they would need to select their phone number from the list to get the 6 digit code for verification.

#5: You might need to migrate custom Spaceship code

A lot of users take automation into their own hands and use spaceship to handle Developer Portal and App Store Connect APIs directly. In the past, this has all been done with the Spaceship::Portal and Spaceship::Tunes modules. These modules access the legacy API which uses an Apple ID.

There is another module that interacts with the App Store Connect API. That module is the Spaceship::ConnectAPI module. This module takes both either Apple ID auth or App Store Connect API Key auth. The Apple ID auth hits the same private API that the websites use. The API Key auth hits the official API.

If you are running into issues using custom spaceship with Apple ID and 2FA/2SV, you may need to look into migrating your code over to API Key auth with Spaceship::ConnectAPI

• Docs for Spaceship’s App Store Connect

If you REALLY need Two-Step Authentication on CI… there are ways 😈

If you really need to keep using Apple ID, there are ways to programmatically enter your 2FA code. Below is a monkey patch to overwrite the ask_for_2fa_code method instead of spaceship. This method is what would normally prompt for the code via the CLI but you could use this to get the 2FA code from where ever you want.

Spaceship::Client.send(:define_method, :ask_for_2fa_code) do |message|
   some_method_to_get_2fa
end

def some_method_to_get_2fa
  # maybe poll from a message queue
  # maybe poll from a twilio
  # maybe poll from a web form waiting for user input
end

Send 2SV to an Android phone number

I don’t have an Android phone with an active number but this an approach I’ve heard of people doing and that I would like to try. Android allows for the apps to programmatically read SMS messages. With this ability, an Apple 2SV code getting sent to an Android phone can get forward into the fastlane job. This could get forwarded into a message queue that the monkey patch polls for.

There are more than enough ways for this to work but this is one suggested way if you need to keep using your Apple ID in an automated way.

⚠️ I do want to call out that you please assess any potential security issues involved when trying this approach.

That’s All Folks

I mean… I don’t think there is ever an end to different fastlane approaches we can talk about when it comes to mitigating effects from the enforcing of 2FA/2SV. But I think that is all that I can fit into this blog post.

As a reminder, this blog post was not for analyzing or criticizing Apple’s enforcement of 2FA/2SV. It is not my job to judge this and nor should it be. This blog post was simply to inform fastlane users what Two-Factor Authentication and Two-Step Verification mean and different approaches to address issues they may run into when the 2FA/2SV enforcement comes into play.

If you see any issues in this article or have any feedback, please feel free to tweet me at @joshdholtz or email me.

It’s been a pleasure having your attention to the very bottom of this article ❤️ Happy fastlaning!