This is a question I've asked myself when I was younger and started to get into Financial Independence literature.

I had one important realisation:

In-fact engineers have very high earning potential, we can get to the level where we are able to charge more than 100$ per hour!

I spent the next decade working on tools and techniques that can save engineering time and ended up speaking at over 50 conferences and open sourcing over 20 projects to solve this exact problem!

What if I told you that you could save hours of development time every week?

Introducing Swifty Stack - Video Course

Today I'm launching a new Indie product, a video course that will help you master the most efficient frameworks, tools, and techniques to accelerate your app creations like never before.

I tried to make Swifty Stack as universal as possible, so that regardless of what kind of product you are working on, or what architecture you decided to use for it you could use tools, frameworks and techniques that I mention in this course.

I also made this course as succinct and focused as I could, giving you a high level overview of things that could improve different aspects of creating applications. All of the things that I'm talking about in the course I've used myself either in commercial projects for my clients or my indie apps.

Head to the website to get the course now:

Swifty Stack

Master the most efficient frameworks, tools, and techniques to accelerate your app creations like never before.

Open Website

Building upon the foundation of the draggable overlay button detailed in the first part of this series, we now move forward to constructing the actual developer tool. This next phase involves diving into the intricacies of the SpyDashboardModel core and designing core model objects like tags, categories, integrations, and entries.

As Swift developers, we often require easily accessible developer tools.
Similar to my LifetimeTracker, you might desire a draggable button that can be pinned to screen edges and is responsive to screen changes.

This series of articles aims to guide you through the process of creating a new dev tool and we'll start with just that: an overlay button that acts as an access point to a tool that we will be developing in the subsequent articles. Our primary target platforms are iOS and macOS.

In a world obsessed with hustling, the concept of Financial Independence and Retire Early (FIRE) is a refreshing perspective on life and finances. It's about taking control of your financial destiny and living a life fueled by passion and choice rather than obligation. This is my personal account of achieving financial independence as a programmer and how you can do it too.

What is Financial Independence?

Financial independence is the status of having enough income to pay one's living expenses for the rest of one's life without having to be employed or dependent on others. This idea of becoming financially self-sufficient is appealing to many, but how can it be achieved? There are different paths to financial independence and your strategy may depend on your lifestyle preferences, income level, and savings rate.

Within the FIRE movement, there are two primary paths: Fat FIRE and Lean FIRE.

Fat FIRE implies aiming for a more traditional lifestyle, generally necessitating a high salary and aggressive savings and investment strategies. It’s for those who don’t want to reduce their current standard of living but still want to retire early.

On the other hand, Lean FIRE requires minimalist living and extreme savings, living on $25,000 or less per year. This may involve a frugal lifestyle, but it also promises an earlier exit from the workforce.

What is your target FI number?

The basic principle of calculating your FI number revolves around the '25 times rule' and the '4% rule'. The '25 times rule' suggests that you need to have saved at least 25 times your annual expenses to retire. The '4% rule' states that you can withdraw 4% of your portfolio each year in retirement without exhausting your funds.

There are online calculators like FireCalc that can help you determine your unique FI number, taking into account your current savings, annual spending, and other important factors.

My Journey Towards Financial Independence

I began my journey towards financial independence at an early age. I started coding for cash before I even entered university. Although my earnings were modest, I adopted a frugal lifestyle to save and invest every penny I earned.

In the subsequent years, I juggled a full-time job, consulting, and even blogging. My work hours soared to 60-80 hours a week. Despite the grueling work schedule, I remained steadfast in my pursuit of financial independence.

When I started earning more, I resisted the urge to inflate my lifestyle. I maintained my frugal lifestyle and limited my spending to just 8-20% of my income, saving and investing the rest. I kept my focus on experiences over material possessions, avoiding unnecessary consumerism.

Along the way, I made savvy investment choices. I invested in rental properties, always ensuring that I negotiated hard and only bought properties that were a real steal. By the time I was 29, I had achieved lean financial independence.

Beyond Lean FIRE: Preparing for a Family

After achieving Lean FIRE, I realized that my financial goals needed to evolve as I was preparing for a new chapter in my life – starting a family. This realization required me to shift my strategy from Lean FIRE to accumulating more wealth to secure my future family's financial stability.

Despite this shift, the freedom that comes with financial independence remains. The luxury of choice is still mine. I can still afford to say 'no' to work engagements that don't excite me and even take on more risks knowing that my basic needs are already met.

Reach FI and then what?

Achieving financial independence doesn't mean you have to stop working. In fact, most people in the FIRE community continue to work in some capacity because they enjoy it, not because they have to.

Personally, I love programming and creating. It's been a part of my life since I was 8 years old, and I can't imagine giving it up. But, having achieved financial independence, I now have the freedom to pick and choose the projects that I want to work on. I no longer have to say 'yes' to every client or job offer. I can prioritize projects that excite me and align with my personal goals.

Leverage your privilege to secure your future

As programmers, we are often in a unique (and privileged) position. Our skills are in demand and we tend to earn relatively high salaries early in our careers. This offers an incredible opportunity to accelerate our journey towards financial independence.

The key is to start early, live frugally, and invest wisely. Choose a path - Lean FIRE or Fat FIRE - that aligns with your lifestyle and goals. Learn to strike a balance between the pursuit of wealth and the joy of living.

Remember, financial independence is not just about amassing wealth. It's about understanding the value of your time and energy. It's about gaining the freedom to choose - to say no to anything that doesn't add value to your life.

Building financial independence as a programmer is a journey. But it's a journey well worth taking.

Resources

Here are some books and blogs that have guided me on my journey towards financial independence:

Books:

1. Your Money Or Your Life
2. Rich Dad, Poor Dad
3. Die With Zero

Blogs:

1. Mr. Money Mustache
2. Mad Fientist

For over a decade, I've lived a double life - an open-source advocate, innovator, and full-time professional. As an active member of the tech community, these dual roles are quite common. Inevitably, questions like "How do you find the time?" or "Do you even sleep?" arise. For 13 years, I found myself deeply entrenched in "Hustle Culture," clocking 60-80h work weeks. But it took a year of peak earnings and a shortage of joyful memories to make me question this lifestyle: I was working hard, but was I truly living?

The Lure of Overwork in the Tech Industry

In the tech world, overwork is often presented as a rite of passage. The promise of success is dangled like a carrot, implying a direct correlation between hours worked and rewards gained. This approach not only leads to burnout but also robs us of valuable life experiences. Our lives start to resemble an unending to-do list, as we continuously chase the next project or the next innovation.

This concept is thoroughly dissected in Alex Soojung-Kim Pang's "Rest: Why You Get More Done When You Work Less", where he illustrates how the most successful people, many from the tech industry, leverage rest as a strategy for accomplishment.

A Paradigm Shift for Tech Professionals

There is an alternative to this relentless grind. I made the conscious decision to shift gears. I began working less and focusing more on the essential tasks. This approach, often referred to as lifestyle design, prioritizes personal well-being over mindless hustle. After all, what use is success if we're too exhausted to enjoy it?

"Essentialism: The Disciplined Pursuit of Less" by Greg McKeown is a worthwhile read for anyone in tech. It hammers home the importance of doing less but doing it better, providing invaluable insights for anyone feeling overwhelmed by their workload.

The Value of Rest and Leisure for Creatives

In our pursuit of the next big thing, it's easy to overlook the value of rest and leisure. These elements are not only essential for recharging our batteries but also foster creativity and productivity. Striking a balance between work, rest, and play isn't laziness—it's a proactive approach to creating a fulfilling life.

In "Play: How it Shapes the Brain, Opens the Imagination, and Invigorates the Soul," Dr. Stuart Brown explores the connection between play and creativity, shedding light on why many successful tech companies promote a playful work environment.

The Result

The result of this shift? Improved life satisfaction, a thriving spirit, and a more efficient work rhythm that doesn't rely on relentless grind.

The Law of Diminishing Returns and Productivity

A key principle underlying this shift is the "Law of Diminishing Returns." In the tech industry, we often push ourselves to the limit, working extra hours to meet deadlines or perfect projects. But beyond a certain point, working more doesn't equate to better results. It leads to stress, fatigue, and reduced productivity, as explored in "Scarcity: Why Having Too Little Means So Much" by Sendhil Mullainathan and Eldar Shafir.

However, it's important to remember that this isn't solely an individual problem - it extends to how we manage teams in the tech industry. When managers push their teams towards overwork, it's often a shortsighted endeavor. While it might lead to short-term gains, in the long run, it costs more. Team members burn out and the recovery process can be lengthy. Ultimately, this leads to decreased productivity, morale, and even turnover, which all negatively affect a company's bottom line.

Challenging the Hustle Culture in Tech

So, it's time we challenged the status quo. Overwork isn't a badge of honor; it's a health hazard. Let's question the hustle culture endemic in our industry. The next time you're asked, "When do you find the time?" or "Do you ever sleep?" consider responding with, "I make time, and yes, I prioritize sleep." Because you are not a machine, and your worth isn't defined by your productivity.

A Call to Balance for Tech Professionals

Let's champion balance, rest, and intentional living in the tech industry. We are human beings, not productivity machines. I'd love to hear your thoughts on this, especially if you've had similar experiences. Let's change the narrative together.

Remember, effective work in tech isn't about working harder, but smarter.

PS. To all my fellow engineers working on Apple platforms! I've spent over a decade crafting tools and techniques to boost developer efficiency. Used by more than 80,000 teams worldwide—including at Apple, Disney, and Airbnb—these resources can revolutionize your workflow. Why work harder when you can work smarter? Bring more balance to your life and make your off-time more enjoyable. Check out my tools or hire me and let's redefine the future of work together.

As a Swift consultant, I always look for ways to optimize clients' code and improve efficiency. I recently built a prototype for The Browser Company that tracks changes in Swift properties and implements a memoization system.

This system re-executes complex computation scopes only when necessary, avoiding redundant re-computations and returning cached values when no property changes have been made.

In this article, I'll walk you through the inner workings of this prototype and demonstrate how it can enhance your Swift coding experience.

Here's a final demo from this series where you can see that it will re-compute just the selected Scopes depending on which properties in State I mutate.

As a software engineer, burnout can be a shared experience due to the demanding nature of the job. I've experienced burnout several times throughout my career, and I've learned that it's crucial to prioritize self-care and find a healthy work-life balance.

Here are six strategies that have helped me avoid burnout and maintain a healthy work-life balance.

Realistic Goals

Setting realistic goals is essential to avoid feeling overwhelmed and burning out.

Even if I'm building a new personal application, I break it down into more minor features and more manageable tasks that could be finished within a set timeframe. This can help manage workload and avoid feeling overwhelmed by the work left to do.

For guidance on how to do this effectively, I recommend checking out "Getting Things Done: The Art of Stress-Free Productivity" by David Allen and "Atomic Habits: An Easy & Proven Way to Build Good Habits & Break Bad Ones" by James Clear.

Workload management

Managing your workload is crucial to avoid burnout. Prioritize your tasks based on their urgency and importance. Use project management tools like Trello or Asana to help you manage your workload effectively.

When working on a complex project with several deadlines, I used project management tools to help me prioritize my tasks. This allowed me to break down the project into smaller tasks and track my progress, which helped me manage my workload effectively.

For further reading on this topic, I recommend checking out "Deep Work: Rules for Focused Success in a Distracted World" by Cal Newport and "Essentialism: The Disciplined Pursuit of Less" by Greg McKeown.

Effective work

In addition to managing your workload, it's important to work efficiently and prioritize your tasks effectively. One technique I've found helpful is the philosophy of "One Thing." This philosophy, popularized by Gary Keller and Jay Papasan in their book "The One Thing: The Surprisingly Simple Truth Behind Extraordinary Results" involves focusing on the most important task that will impact your goals most.

When you're feeling overwhelmed or burnt out, trying to tackle everything on your to-do list at once can be tempting. But you can achieve more excellent results in less time by prioritizing the most critical task and focusing all your energy on completing it.

For example, if you're working on a project with several deadlines, it's easy to get caught up in completing all tasks simultaneously. However, by focusing on the one most important task to complete the project, you can make significant progress and reduce your stress levels.

In addition to helping you work more efficiently, the "One Thing" philosophy can help you avoid burnout by helping you prioritize your tasks and avoid feeling overwhelmed. Focusing on the most important task allows you to progress on your goals while avoiding the stress of doing too much at once.

Breaks

Taking breaks is essential to recharge your batteries and avoid burnout. Step away from your computer and engage in activities that help you relax and recharge, like taking a walk, meditating, or listening to music.

I worked on Headspace, but nowadays, I use Calm for my mindfulness routine.

For further reading on the benefits of taking breaks, I recommend checking out "The Power of Full Engagement: Managing Energy, Not Time, is the Key to High Performance and Personal Renewal" by Jim Loehr and Tony Schwartz and "Rest: Why You Get More Done When You Work Less" by Alex Soojung-Kim Pang.

One example is when I sometimes work on a project for 10+ hours without taking a break, even if I'm in the flow at that moment. It has brutal repercussions the next day. I usually feel like a zombie. Instead, if I break my work into 60-90 min blocks with 10-15-minute breaks, I can keep myself productive the whole week.

Self-Care

Practicing self-care is crucial to avoid burnout. Take care of your physical and mental health by eating well, getting enough sleep, exercising regularly, and engaging in activities that bring you joy and relaxation.

When I wasn't taking care of myself as well as I could be and didn't eat well, I wasn't very productive. When I started doing bodybuilding at a pro level, although it's hard physically, it helped me feel more energized and effective, improving my work performance.

For further reading on this topic, I recommend checking out "The Happiness Advantage: How a Positive Brain Fuels Success in Work and Life" by Shawn Achor and "The Body Keeps the Score: Brain, Mind, and Body in the Healing of Trauma" by Bessel van der Kolk.

Boundaries

Setting boundaries is crucial to maintain a healthy work-life balance. Be clear about your working hours and ensure you have time for activities outside of work.

Sometimes I see people put in overtime because of imposter syndrome. It's a familiar feeling among software engineers. Recognize that everyone experiences imposter syndrome at some point in their career. I often do, even though I've achieved a lot in my career, and one would think it should be enough, but our mind likes to play tricks on our perception of ourselves.

Talk to your peers, mentors, or a therapist to help you develop strategies to overcome these feelings.

One example is when I used overwork as a badge of honor when I was younger, working 60-80 hours per week. I realized this was not a healthy way to live and that I needed to set boundaries. I learned to relax and enjoy the non-productive time, even though it took some time to stop hearing a voice in my head, 'you could be doing something more productive' when I just wanted to play some games or chill with music.

Related book "The Imposter Syndrome Remedy: A 30-Day Action Plan to Stop Feeling Like a Fraud" by Emee Vida Estacio

Summary

In summary, burnout is a common experience for software engineers due to the demanding nature of the job.

Setting realistic goals, managing workload, taking breaks, practicing self-care, and setting boundaries are crucial to avoid burnout. These strategies help to maintain a healthy work-life balance, avoid feeling overwhelmed, and prevent burnout.

By prioritizing self-care and finding a healthy work-life balance, software engineers can continue to perform at a high level without sacrificing their mental and physical health.

The team at The Browser Company is a major adopter of The Composable Architecture (TCA) framework. Based on our team's experiences and insights from the wider community, I've developed a new set of best practices that can benefit your TCA projects.

Here are some of the key practices to consider using in your projects.

Reducers

• To adhere to the boundaries approach, it's best to name your view actions based on "what happened" rather than their expected effect. For instance, you should use .didTapIncrementButton instead of .incrementCount. This approach enables you to add logic to the action while still keeping it true to its name. Additionally, this practice encourages keeping business logic in the reducer instead of letting it slip into the view layer.

• Try to avoid performing expensive operations in Reducers.
  • Reducers run on the main thread, and such operations can cause lag or even freeze the UI. Instead, consider leveraging .task / EffectTask and environment clients, which allow you to perform these operations off the main thread. By doing so, you can ensure that your app remains responsive and performant.

return .task { 
  .reducer(.onResultsUpdated(await self.search(query: query)) 
}

• When nilling out state, it's important to unregister any long-running effects to prevent memory leaks and bugs. To do this, you can use the .cancellable method to cancel any ongoing effects before the state is deallocated. By doing so, you can ensure that your app remains memory-efficient and stable.
• When using concatenate and merge methods, it's important to consider their differences. The concatenate method will wait for previous effects to complete before running the next ones, while the merge method runs effects in parallel. However, it's important to note that relying on concatenate can become problematic when using other actions that might introduce delays in the future, such as animations. This can also delay any following effects. Therefore, it's often better to use the merge method to ensure that effects run in parallel and prevent delays that could impact the user experience.

• Avoid high-frequency actions like Timers hitting your reducer to check something. Instead, perform the work in the tasks or env clients and only send back actions when actual work on State needs to be performed.
  • An example might be mouse move handlers. When we track mouse movement, we often do so, waiting for some condition to be true. Best to check that condition in the views code and then only pipe the edge condition/events into TCA.

• Don't use actions for sharing logic. They are not methods.
  • Sending actions is not as lightweight as calling a method on a type.
  • Each (async) action causes rescoping and equality checks across our application
  • Only exception for now: .delegate() actions
  • Instead, use mutating methods on State objects
    • Currently exploring the alternative of extending ReducerProtocol implementations with functions that take inout State variable. This allows accessing the Reducers dependencies without passing them into helper methods.

• When possible, it's best to use feature state instead of projected state (computed properties) in your app. It can help you avoid unnecessary computation and improve your app's performance.
  • For instance, in your AppReducer, it's better to use localWindows instead of the windows computed property, if available. By doing so, you can avoid computing the windows property every time it's accessed, reducing the load on the main thread and improving overall app performance.

• When using onChange reducers, it's important to be careful and mindful of where you add them in the reducer composition. This is because onChange reducers only work at a specific level of the reducer composition.
  • If you're experiencing issues with onChange reducers not working, it's likely that they are added at the wrong level of reducer. For example, you may be observing at the Feature level, but the mutation occurs at the App level. To resolve this issue, make sure that you add the onChange reducers at the appropriate level of reducer composition to ensure that they function as intended.

• When observing child feature actions, use delegate actions from our boundaries convention.

State Modeling

• Be extra careful with code inside the scope functions, e.g., computing child state.
  • Those calls happen for every action sent to the system, so they must be fast.
    • Try to avoid calculations. Even O(n) complexity will cause issues in hot paths for large sidebars.
  • Either pre-compute heavy data or make the view layer calculate it if needed
  • Be especially careful when using computed properties, as they can be expensive due to the same problems as normal scope. Other than being in the hot-path, they often might re-create objects each time they are called.
• Make state optional when possible and leverage ifLet and optional pullbacks to avoid performing unnecessary work.
  • E.g., The command bar was not optional, so its state/reducer and view layer side effects would run even when it wasn't visible.
• UI State doesn’t always need to persist.
  • E.g., sidebar hover used to be a state property, but it only needs to live at View Layer.
• Be careful when updating persisted state objects. They might require migrations. Make sure to add tests to avoid user data loss.
• Avoid referring to userDefaults in scoping function. They should use the current State and not refer to anything else.
• Projected state initializers should be as fast as possible, usually just initializers without any computations.

Testing

• Use prepareDependencies and always use initialState explicitly
  • That allows state initializers to leverage test @Dependency values e.g. UUID generator.

// Don't
let windows = WindowsState.stub(windows: [.init(window)], sidebar: .stub(globalSidebarContainer: sidebar))
let store = TestStore(
  initialState: windows,
  prepareDependencies: {
    $0.uuid = .incrementing
  }
)

// Do
let store = TestStore(
  initialState: .stub(windows: ...),
  prepareDependencies: {
    $0.uuid = .incrementing
  }
)

Dependencies

• Use structs for clients with mutable var instead of protocols

  • Protocol-oriented interfaces for clients are discouraged in our codebase

    // Don't
    protocol AudioPlayer {
      func loop(_ url: URL) async throws
      func play(_ url: URL) async throws
      func setVolume(_ volume: Float) async
      func stop() async
    }
    
    // Do
    struct AudioPlayerClient {
      var loop: (_ url: URL) async throws -> Void
      var play: (_ url: URL) async throws -> Void
      var setVolume: (_ volume: Float) async -> Void
      var stop: () async -> Void
    }
    

    This allows us to describe the bare minimum of the dependency in tests. For example, suppose that one user flow of the feature you are testing invokes the play endpoint, but you don’t think any other endpoint will be called. Then you can write a test that overrides only one endpoint and uses the default .failing version for all the others. By doing so, you can ensure that your tests are focused and efficient, making it easier to identify and resolve any issues that arise.

    let model = withDependencies {
      $0.audioPlayer.play = { _ in await isPlaying.setValue(true) }
    } operation: {
      FeatureModel()
    }
    

• Use placeholders in unimplemented failing stubs where the endpoints returns a value.

  • This allows your test suite to continue running even if a failure occurs. If an issue is detected, it's reported via XCTFail along with the name of the endpoint that caused the failure. This is preferable to a fatalError, which can cause the test to crash and drop into the debugger, interrupting the rest of the test suite.

    // DON'T
    searchHistory: unimplemented("\(Self.self).searchHistory")
    
    // DO
    searchHistory: unimplemented("\(Self.self).searchHistory", placeholder: [])
    

View layer

• Use the new observe: ViewState initializer as it forces you to create ViewState

// DON'T
viewStore = .init(store.scope(state: \.overlayViewState))

// DO
viewStore = .init(store, observe: \.overlayViewState)

• No need to create a ViewStore if you only need to send one-off actions, e.g., ViewStore(store.stateless).send(.action)
  • Note that we use .stateless variant, which skips temp ViewStore from taking part in the update pipeline.

• Always scope down your ViewStore scopes to the minimal amount your View needs by introducing local ViewState for it, as this avoids unnecessary diffing and view reloads
  • Either only add actively observing properties to ViewState or consider creating multiple different ViewStores for more complex use-cases

• Besides a view-lifecycle action (e.g. viewDidAppear, or even better, bind it to the lifetime of the view via a task), there should be no other action sent into the store on appear or load. Especially for tableview cells, this can lead to a ton of actions being sent into the store on appearance, e.g. onHover(false)
• Mind that subscribing to a ViewStore’s publisher triggers synchronously. So when in AppKit, consider adding a dropFirst when subscribing to viewStore changes, in case it's only about reacting to changes.

Bugs & Workarounds

• If you break auto-completion in ReducerProtocol bodies, the workaround is to add explicit type to your definitions, e.g., Reduce<State, Action> {
• If the same or compiler errors happen when using WithViewStore either add explicit type in the body, e.g., WithViewStore(self.store) { (viewStore: ViewStoreOf<Feature> in) or introduce @ObservedObject var viewStore: ViewStoreOf<Feature> instead of the WithViewStore wrapper.

Conclusion

The Browser Company is a major adopter of The Composable Architecture (TCA) framework. We have shared best practices based on our team's experiences and insights from the wider community.

These practices are designed to help you optimize the performance and stability of your TCA projects and make them more maintainable in the long term. By adopting these practices, you can build high-quality TCA projects that meet your users' needs and exceed their expectations.

References:

• Community Tips and Tricks
• Official TCA performance recommendations
• Additional reading on PointFree Dependencies system

Last time, we established a foundational architecture for composable and self-contained widgets. This week, we will convert that prototype into a data-driven structure.

To enhance the development experience, we will integrate live reload functionality by utilizing the FileWatcher library.

Furthermore, we will implement an automated registration system using Sourcery to ensure that newly added widgets are immediately available for use within the project.

This series of articles will explore a component-based architecture, in which each component or widget is self-contained, allowing for quick scaling of a project by adding more engineers.

This type of architecture has been used in several client projects, such as powering generic list content at The New York Times and creating new home widgets at The Browser Company.

Requirements

At the end of the series, we'll have an architecture in which

• Widgets are self-contained and can be worked on in isolation
• Adding new widgets doesn't require any manual labor from the developers
• We support the rapid development of new and existing widgets
• Widgets can be driven via data

Here are a couple of my favorite debugging tricks and tips I use while working on Swift projects.

Configure your .lldbinit

First, most of us want to work with Swift, not Objective-C, but depending on your project setup, you might have Objective-C enabled by default. We have 2 options:

1. We can manually change the language during the lldb session by callingsettings set target.language swift
2. We can create a .lldbinit file in our home directory and add it there to be the default for all debugging sessions e.g. echo 'settings set target.language swift' > ~/.lldbinit followed by chmod +x ~/.lldbinit

Furthermore, .lldbinit is a great place to add additional things that you'll be using across your projects. Here is a part of mine:

settings set target.language swift

breakpoint set -r NSWindow.initialFirstResponder --one-shot true --auto-continue true
breakpoint command add
e import AppKit
e import Foundation
e func $vc<T>(_ input: T) -> NSViewController { unsafeBitCast(input, to: NSViewController.self) }
e func $view<T>(_ input: T) -> NSView { unsafeBitCast(input, to: NSView.self) }
DONE

breakpoint set -n UIApplicationMain --one-shot true --auto-continue true
breakpoint command add
e import UIKit
e import Foundation
e func $vc<T>(_ input: T) -> UIViewController { unsafeBitCast(input, to: UIViewController.self) }
e func $view<T>(_ input: T) -> UIView { unsafeBitCast(input, to: UIView.self) }
DONE

This allows me to use memory address to get info about my types easily:

po $vc(0x128027ad400)

Notes:

• Using $ for variable and function names is how we get those things available outside of just the current expression context, from Apple:

If the first character of your user defined variable is a $, then the variable's value will be available in future expressions, otherwise it will just be available in the current expression.

• We configure the initial breakpoint as a trigger for adding new functions into the system. Otherwise, they wouldn't work since expressions aren't evaluated as part of lldb initialization due to lack of stack frames
• I work in both Mac and iOS context so I set 2 separate breakpoints and variants of the common functions I use

Leverage frame variables

Most Swift engineers are used to using print object or po for short, but there is an alternative that often works faster and works in cases when po might fall short: frame variable or v

The short alias was added back in Xcode 10.2, and here's Apple note about it

The LLDB debugger has a new command alias, v, for the “frame variable” command to print variables in the current stack frame. Because it bypasses the expression evaluator, v can be a lot faster and should be preferred over p or po.
https://developer.apple.com/documentation/xcode_release_notes/xcode_10_2_release_notes

Here's an example:

You can add additional flags to it to get even more information by adding -O option to it.

Use expressions

The aforementioned po is an alias for a e -O – which will evaluate the object and try to call description method on it if it exists, it will evaluate the given expression and then try calling description method on it.

But expressions are more valuable than that, and it would be worth using them directly instead of relying on po.

We can interact with our system by leveraging e or expression, this can be very convenient when dealing with variables:

e var $vc = self.controller
e $vc.view.layer.borderColor = CGColor.red
e CATransation.flush() // Refresh the core animation screen without having to end debugging session

Observe the system

We can leverage breakpoints for many things, from changing default inputs into fields (e.g. login forms):

To using debugger commands to build symbolic breakpoint chains, e.g.

breakpoint set --name "[CommandBarInputContainer layout]"

Would create a breakpoint on the layout call of my NSView, now this would be too frequent, but I could set it up as part of another breakpoint execution, e.g. when the user changes the text input.

I could also use --one-shot true to only execute the breakpoint once per trigger.

Watch variable change

We can add breakpoints when a variable changes, either through Xcode UI or lldb command:

watchpoint set variable self.homeViewController

Then whenever that variable changes, Xcode will stop our debugging session and give us info like this:

We can then print and interact with that value

po value
▿ Optional<NSViewController>
  ▿ some : <HomeButton.HomeViewController: 0x13407cf3ac0>

What are your favorites?

Let me know what your favorite tips or lldb commands are!

In previous articles, I discussed Testability and API Boundries when using The Composable Architecture. This week I will dive into performance and a design pattern you might consider: multi-store. This pattern can improve performance and enforce rigid API boundaries.

How are actions processed in TCA?

TCA implements a Unidirectional Data Flow (UDF). Using a UDF ensures that events and data in your application moves in a consistent and predictable manner. Following this pattern can reduce data inconsistencies because the source of truth for your application is the same throughout the whole application.

UDF in TCA

In TCA, the State managed by the root Store is the source of truth for your application. As different parts of the application need less and less of the overall application state, you use scope functions for whittling the State down into smaller components. One interesting aspect of the State is that it is not required to be Equatable , and there is no dependency graph through the application that is maintained automatically by TCA.

Why is this important?

Whenever we process actions in TCA, the architecture has to assume that the Root State has changed, and call all of our scope functions again and again.

Those scoping functions will be called tens of thousands of times during user sessions, and as such, you need to be careful what code you put in them. You should avoid any calculations in that function and have as simple operations as possible.

Even sending a no-op action into TCA system will use significant cpu / main thread processing time because of all the scoping calls.

Last week I spoke at NSSpainX to talk about how to use Composable Architecture in larger projects, the kind of issues you might run into and how you can work around them.

Mentioned articles are:
- Exhaustive testing in TCA
- TCA Action Boundaries
- TCA Action Boundries - Convenience

My talk from AppDevConNL is now available to watch to anyone interested.

Why should developer experience be one of the cornerstones of your architecture design?

How to evaluate problem areas you see in day-to-day development to assess whether they could be solved at a scale of your team/company or the whole community?

It's a practical look at tools and techniques that I used with many of my clients to save months of work and enable much faster iteration speeds.