Table of Contents

• The Notes
• Personal Takes
• Related Articles

The Notes

Personal Takes

Something that I found interesting about this book is that it seems written for people that don’t like their actual job situation, and that’s not something that happened to me during my 12 years of working in tech.

However, it talks about some interesting points, like the importance of facing your fears, and the relationship between money and time.

Even though I’ve always like being in the tech world, there are some thinking processes that this book triggered on me. For example, during this new era of AI development, my day to day work has changed, it’s more automated, and it doesn’t require as much grind as before (which could also be caused by being inside the industry for many years).

One example of something that used to cause my joy, but now it’s not as much, is the debugging process of a really hard problem. For example, debugging an issue for 3 days, losing my head, only to find out that the answer was a single line of code, was both frustrating and rewarding. Lately, I haven’t had experiences like that, and it’s not as much of a joy.

Another thing to consider regarding Good Work is that it’s not just about the job, but also about the people you work with. I’ve always liked the people I work with, but I think it’s important to consider the environment you work in, and the people you interact with. Having friends at work is always an extra motivation to perform at top level to not let them down. I’ve experienced this first hand over the past few years at different companies.

The book talks about taking some sabbatical time to reflect on your life and career. I honestly never thought about that, given I’ve always enjoyed my job. That’s not to say that I always have fun, I’ve my ups and downs, but I never reached the completely burnout point of thinking about sabbatical time.

The relationship about money and time is something I do think about often, I’m in my early 30s and I know that my energy now is really high, so it’s important to think about enjoying these years and not getting too focused on money. On the other side, compound interest is a topic that I’ve always liked, so turning down money now is not a smart decision. In conclusion, balance is really important, and it’s something that I consider from time to time, I tend to adapt my situation based on the current conditions, and my prediction of the near future.

I do recommend you to read this book, whether you like your current situation or not, given it’ll trigger some deep thinking processes that will benefit you anyways.

Related Articles

• Deep Work
• The Compound Effect
• Die with Zero
• The Joy of Less
• The ONE Thing
• The Great Mental Models - Volume I

This book was a recommendation from my great friend Nico. Go check out his blog if you are into home-automation, electronics, cybersecurity, habits, radio, or to find out about his latest obsession.

Table of Contents

• The Notes
• Personal Takes
• Related Articles

The Notes

Personal Takes

The book was really easy to read, I will continue to read the next volumes in the near future.

I will start applying the Second-Order Thinking model to my daily life. In combination with the Inversion model, I think it will be a great way to get more serious in terms of my diet, exercise, and overall fitness.

Another thing that I will keep in mind is the Causation vs Correlation relation. I will try to avoid making assumptions based on correlation, and instead try to understand the real causation behind it.

Finally, Hanlon's Razor is something that from time to time I forget, in particular, when driving, I tend to always be frustrated about other people’s behavior, but probably 99% of the time it’s not their fault, as they are just doing what they think is best.

Related Articles

• Deep Work
• The Compound Effect
• Die with Zero
• The Joy of Less
• The ONE Thing

Table of Contents

• The Code
  • Usage
• Demo

The Code

Usage

If you build your “loaded” state using parameters, like this:

func charactersView(characters: [CharacterModel]) -> some View {
    ScrollView {
        ForEach(characters, id: \.id) { character in
            ImageAndTextRow(
                imageURLString: character.image,
                title: character.fullName
            )
            .padding(.horizontal, 16)
            .onTapGesture {
                router.push(.character(character))
            }
            Divider()
        }
    }
}

Then you can build your “loading” state using mocked information:

var loadingView: some View {
    charactersView(
        characters: [
            .mock(index: 1),
            .mock(index: 2),
            .mock(index: 3)
        ]
    )
    .skeleton()
    .task {
        await viewModel.fetchCharacters()
    }
}

Demo

Related Articles

• ViewModifiers
• ShrinkModifiers
• SkeletonModifier
• Simple Modularization Setup for a New App
• Centralized Dependencies

Table of Contents

• The Notes
• Personal Takes
• Related Articles

The Notes

Personal Takes

The question I take to ask myself each time I feel I am not giving my best is:

Are you doing this to simply do the best you can do, or are you doing this to do it the best it can be done?

Most of the other advice, even though great, goes in the same line as other Habits books.

Related Articles

• Deep Work
• The Compound Effect
• Die with Zero
• The Joy of Less

We will add some documentation on usage on top of the SwiftUI built-in framework for sheets.

iOS 17.0+

Table of Contents

• The Code
• Usage
  • Boolean-based
  • Enum-based
• @State vs @Observable
• Adding Navigation to the presented sheets
• Related Articles
  • Featured in
  • Related Reading

The Code

Let’s start out with the code:

• In the snippet, we are just adding a ViewModifier + a View extension to add a close button modifier to a Navigation Bar. Nothing Fancy.
• What’s interesting about the snippet is the documentation we added on top of the code.
• Explaining when to go for sheet(isPresented: Boolean) vs sheet(item: Enum).
• It will serve as the base for sheet manipulation for the whole app.

Usage

Boolean-based

If your screen can only present one type of sheet, then the easiest way is to use sheet(isPresented:). We only need to manage one state property, so there is no need for the enum-based approach.

struct SomeScreen: View {
  @State private var isPresentingSheet: Bool = false

  var body: some View {
    Button("Present Sheet") {
      isPresentingSheet = true
    }
    .sheet(isPresented: $isPresentingSheet) {
      Text("Presented sheet")
    }
  }
}

Enum-based

If your screen can present multiple types of sheets, then the best way is to use sheet(item:). We need to manage an enum property, so there is no need for the enum-based approach.

struct SomeScreen: View {
  enum Sheet: String, Identifiable {
    case firstPresentedScreen, secondScreen, thirdScreen
    var id: String { rawValue }
  }
  @State private var presentedSheet: Sheet?

  var body: some View {
    VStack {
      Button("Present Sheet") {
        presentedSheet = .firstPresentedScreen
      }
      Button("Present Second Sheet") {
        presentedSheet = .secondScreen
      }
      Button("Present Third Sheet") {
        presentedSheet = .thirdScreen
      }
    }
    .sheet(item: $presentedSheet) { sheet in
      switch sheet {
      case .firstPresentedScreen:
        Text("First presented screen")
      case .secondScreen:
        Text("Second screen")
      case .thirdScreen:
        Text("Third screen")
      }
    }
  }
}

Something interesting about the sheet(item:) approach is that the system will take care of dismissing the current sheet, if by some reason, another sheet is presented using the same property.

Example:

• SomeScreen’s presentedSheet is set to .firstPresentedScreen
• The FirstPresentedScreen is presented as a sheet
• SomeScreen’s presentedSheet is set to .secondScreen
• The FirstPresentedScreen is dismissed
• The SecondScreen is presented as a sheet

@State vs @Observable

In most cases, managing the state of the sheets directly on the SwiftUI views as a @State property should be enough. However, if there is some business logic involved, it might be a good idea to move the state to an @Observable object. The benefit of the @Observable object is that it can be shared with other views, and it can be used to trigger some actions when the state changes + we could add some unit tests over the logic.

Adding Navigation to the presented sheets

It’s really straight forward to add an stack-based navigation system to the presented sheets. We can just follow the same approach explained in the NavigationRouter article for the Router of the Sheet-presented flow.

Related Articles

• NavigationRouter
• Simple Modularization Setup
• New App Checklist
• ViewStateController
• Enhancing Testability without Protocols

Featured in

• iOS Coffee Break #43
• iOS Dev Weekly #711

Related Reading

• sheet(isPresented:ondismiss:content:)
• sheet(item:ondismiss:content:)

Official Apple Docs

Table of Contents

• String Catalogs
• Handling Plurals
  • Usage
• Related Articles
  • Featured in

String Catalogs

Adding a String Catalog to your app is as simple as creating the file:

For a detailed guide on how to add the localizable extension to String, read this Localization article.

Handling Plurals

Handling plurals has never been easier, the String Catalog has built-in support:

Forget about the if/else statements for good 🙌

Usage

Using it is as straight forward as using the in-line components:

@State private var itemCount = 0
Text("\(itemCount) Books") // 0 Books, 1 Book, 2 Books

Or, if you are using the String extensions from the previous localization article:

@State private var itemCount = 0
Text("books".localized(with: [itemCount])) // 0 Books, 1 Book, 2 Books

Related Articles

• New App - Localization
• AdaptableStack
• Components
• Improve Build Times
• Xcode Templates
• String Extensions
• ViewStateController
• ViewModifiers

Featured in

• iOS Coffee Break #43

(Sorry for the formatting, I’ll try to improve it in the future)

Table of Contents

• The Notes
• My Takes
• Related Articles

The Notes

My Takes

I find this book to be very useful, in particular, the idea that you should focus on deep work instead of shallow work is really interesting for someone like me (a knowledge worker focused on providing value).

I agree with the idea of Quitting Social Media, personally:

• I have been out of Instagram for the last 2 months (and don’t plan on coming back anytime soon).
• I have never had a TikTok account, I have never installed it on my phone
• I only use X to share my articles. I don’t have the app on my phone, and I’m not logged in in the browser.

The downsides I have seen is that I cannot see the tweets/reels/tiktoks that people send in group chats, but I honestly think this has not been a big issue for me.

I have been planning my days for the last couple of weeks and it’s been a really nice practice that have allowed me to accomplish more, to be more mindful about rejecting shallow tasks, and to be more productive overall.

I’ve added the Plan Next Day practice into my workflow (you can read more about it here).

My next reading will be The One Thing. Be on the lookout for the notes if you’re interested!

Related Articles

• The Joy of Less
• Brain Rules
• The Compound Effect
• Excellent Advice for Living
• Die with Zero
• The Charisma Myth
• Hyperfocus
• Streamlining my Life

iOS 17.0+

Table of Contents

• The Code
• Usage
• Find a place to store the routers
• 😡 But you are coupling the views and the navigation!
• Adding some unit tests
• Related Articles
• Related Reading

The Code

Let’s start out with the code:

• We have a generic NavigationRouter
• The class is marked with the @Observable notation
• SwiftUI views can react to changes in the router’s properties.
• The router containts a navigationPath property, which will be an array of Hashable objects.
• We have some UIKit-ish named methods for push, pop, pop(to:), and popToRoot which will manipulate the path array.
• The push method adds a new item to the end of the navigationPath array.
• The pop method removes the last item from the navigationPath array.
• The pop(to:) method removes all items from the navigationPath array, until it finds the given item.
• The popToRoot method removes all items from the navigationPath array.

Usage

Basic usage of this router, will consist on:

1. Create an enum with all possible destinations:

enum Route: Hashable {
    case detail(id: Int)
    case profile
}

2. We need to decide where the router will be stored, for example, if it’s a simple flow, it could live on the first screen. In other cases, we could store it on the app level, or in the first screen of each Tab. It will depend on the requirements:

struct SomeScreen: View {
  @State private var router = NavigationRouter<Route>() // Define the Router
}

3. Then we add a NavigationStack into the body:

var body: some View {
  NavigationStack(path: $router.navigationPath) { // Here we use the navigationPath from the Router
    // Will Fill this on point number 4
  }
}

4. Then, we add the possible navigationDestinations for the flow:

var body: some View {
  NavigationStack(path: $router.navigationPath) {
    BaseScreen()
      .navigationDestination(for: Route.self) { destination in
        switch destination { // We define a destination for each case
        case .detail(id: let id):
            DetailScreen(id: id)
        case .profile:
            ProfileScreen()
        }
      }
  }
}

5. We need to provide a way to share the router with the childs, we can do this using the environment modifier:

var body: some View {
  NavigationStack(path: $router.navigationPath) {
    // content
  }
  .environment(router) // Share the router with the children screens/views.
}

6. Finally, in the child screens, we can access the router via the @Environment modifier:

struct ProfileScreen: View {
  @Environment(NavigationRouter<Route>.self) private var router

  var body: some View {
    Button("Push Detail") {
      router.push(.detail(id: 1))
    }
  }
}

Find a place to store the routers

It’s important to notice, that an app could have multiple routers, one for each tab, or one for each flow.

To this point, each app will have its own way of storing the routers. That way will depend basically on how the navigation happens on the app.

I’d say that the best way is to store the router on the first screen of the flow, or on the first screen of the tab. However, if, for some reason, some screen in the third tab can decide the navigation of another tab, we would need to move the routers up the view hierarchy.

My recommendation would be to store them as low in the view hierarchy as possible for each one, and move them up only if needed by the business decisions.

😡 But you are coupling the views and the navigation!

One of the potential drawbacks of using this system is that the views are now tightly coupled with the navigation.

In any case, I believe this system is so simple that it shouldn’t be a big deal.

If you want to have logic over which view to present next, you can move that logic into a view model, and add unit tests over it.

If your flow is too complex, you could add automated testing, or UI testing, instead of unit testing.

The case in point here, is that this is a simple navigation system, and you probably won’t need anything more complex than this, so starting to geek out on abstractions to make a solution that works well with SwiftUI could be an overkill.

As most times, the rule of starting simple and only adding complexity as needed applies really well to this case.

Adding some unit tests

Finally, we could add some basic unit tests to make sure the navigationPath is being modified correctly:

Related Articles

• Sheets Manipulation
• Simple Modularization Setup
• New App Checklist
• Enhancing Testability without Protocols
• ViewStateController

Related Reading

• NavigationStack
• Migrating from the Observable Object protocol to the Observable macro

This is not a guide on how to set up the process, it’s a guide on wether you should or not do it.

Table of Contents

• Starting point
• Transforming Tokens to code
• The benefits of automating
• The drawbacks of automating
• Should you Automate the process?
  • You maintain only 1 app
  • You maintain multiple apps / SDKs
  • The tokens change too often
• Related Articles
  • Related Reading
  • Featured in

Starting point

The starting point for this post is the assumption that you are working with a Figma design system.

The design system is set up following the standard Design Tokens pattern.

So, it should be possible to use the Design Tokens plugin to export the tokens from Figma to a json file.

Here is a Figma example of a design system.

A side note here: Regardless of automating the process, using semantic names for the tokens is a good practice. i.e.: primary instead of primaryBlue. accent instead of accentRed.

Transforming Tokens to code

The idea of automating the Design System, is that we can transform the tokens from json file directly to iOS/Android/Web code using codegeneration scripts.

Given the json file should be compatible with the Amazon Style Dictionary style, we will be able to use Amazon Repository which contains JavaScript code to generate all the tokens.

It’s important to note that it’s not plug and play, and there is some overhead to make it work for all the platforms.

Once we have valid json files, and the code generation scripts fully setup, we can talk about some benefits and drawbacks.

The benefits of automating

• Consistency: The 3 platforms will have the same tokens, the same names for each token, and the same values.
• Speed: If the designers change the tokens, we can update the values running the codegen again.
• Less Error Prone: We can avoid human-errors when updating the tokens in the code.
• Less Code: We can avoid writing the same code in all the platforms.

The drawbacks of automating

• Buy-In: We need to pitch the idea to the team. Then we need everyone onboard, as this only works if all the parts are in place.
• Cost: We need to invest some time up-front in setting up the process.
• Complexity: We would have a more complex system. We might not need to write the same thing multiple times, but now we have new systems that could fail.
• Maintenance: We would need to maintain the code generation scripts. Who will be responsible for this code if it fails?
• Risk: Can different people maintain the process in the future? This question goes for Devs and Designers alike.

Should you Automate the process?

So, going back to the title of the post, Should you automate the process or not?

For most cases, I lean towards not automating the process. The drawbacks are more strong than the benefits in my personal opinion.

I have seen this process fail, basically, an initial team sets everything up, after some initial setup, the process works fine. Everything is smooth for a while, but then, errors start to pop up. The lead designer might change companies. Now we have a team that does not follow the same process, and the process fails. We end up with a broken process. Then, the devs change companies, the new devs do not know how the entire system work, so they start changing tokens manually. Now we are in the worst world of all, we have a triple discrepancy between: Figma Tokens, the json file, and the codegenerated files.

Let’s go through some scenarios:

You maintain only 1 app

If you/your team are working only on 1 application, the benefits of automating the process are not worth it.

The design system tokens do not change that often, so the overall time spent on creating them at first and then maintaining them up to date is not that big.

You maintain multiple apps / SDKs

If you/your team are working on multiple apps, and the base design system is shared for all of them, then the benefits of automating the process are worth it.

This is the scenario where I would vote for automating the process. Spend the time setting up the process, and the benefits will be huge. Pitch the idea to the team, educate everyone, write documentation on usage, and make sure everyone is on the same page.

Finally, keep an eye on how it evolves, if it becomes too complex, or if the process starts to fail, then it might be time to reevaluate the process.

The tokens change too often

If the design team tends to change the token regularly (strange, but could happen), then you should consider the automation, as the benefits outweigh the drawbacks.

Related Articles

• Simple Modularization Setup
• UI vs API Models
• New App Checklist

Related Reading

• Atomic Design Book by Brad Frost

Featured in

• Those Who Swift #211

We’ll build upon the Simple Modularization post. In that repo, we added a lane to run all the tests of all the modules. Now, we will add a lane to only run the tests for the modules with changes, to speed up the process and improve the developer experience.

This will also save up precious CI time, as developers will get test failures on their machines, without the need to wait for the CI to run all the tests.

Table of Contents

• Gathering the changed packages
• Running the tests
• Related Articles
• Featured in

Gathering the changed packages

The first thing we need to do, is to add a method to check the diff between the current branch and the base branch.

We can do this by executing a really simple shell command:

git diff --name-only origin/main

This will return a list of files that have changed between the current branch and the base branch.

Example:

• Packages/CoreLayer/APIModels/Sources/APIModels/APIModel.swift

Then we need to extract the Scheme for the changed package and store all the changes packages.

Running the tests

For this, we can leverage the test_all_packages lane that we already have, but modify it to receive an array of packages.

Check the complete diff in this commit.

> bundle exec fastlane test_changed_packages
---------------------------
--- Step: shell command ---
---------------------------
🔍 Found 1 changed packages: CoreLayer/APIModels
--------------------------------------------------
--- Step: Switch to ios test_all_packages lane ---
--------------------------------------------------
Cruising over to lane 'ios test_all_packages' 🚖
🚀 Running tests for specified packages: CoreLayer/APIModels
▶️ Testing APIModels...
▸ Test Succeeded
✅ APIModels: 1/1 tests passed
   Coverage: ⚠️ No coverage data

📊 Test Results Summary
✅ Passed: 1 packages, 1 tests
  • APIModels - 1/1 tests
    Coverage: ⚠️ No coverage data

📈 Overall Statistics
Total tests: 1
Passed: 1
Failed: 0
🎉 All tests passed successfully!
Cruising back to lane 'ios test_changed_packages' 🚘
fastlane.tools finished successfully 🎉

With this new test_changed_packages lane, we can now speed up development, run the tests more often, and save valuable CI time.

Related Articles

• Simple Modularization Setup
• My Xcode Setup and Shortcuts
• New App Checklist

Featured in

• TestableApple #55