“Part time” means less salary. I’m punished for keeping me healthy and productive. I could easily “work” 40 hours per week by jeopardizing my productivity, my health and my social life. I choose not to do that.

With only 8 more hours free time I wrote several books, spoke at conferences and published some apps. I’m spending more time with my children and I’m trying to be a better partner to my wife.

What could I do with 12 more hours for myself and my family? What kind of a dad could I be with so much time? How would our society look like if more people would only work the hours they are productive? I guess we would be happier and probably way worse customers.

How about you? How many of your work hours per day are actually needed for your output? Let me know on Mastodon.

I try not to use AI for coding. It’s getting harder every day because people believe that they can save truck loads of money when everyone is reading code instead of writing code.

For me there are several reasons to avoid this new kind of software development. Some very important, some less so. Here are the most important reasons for me sorted by importance.

1. I love coding

I’m one of the few people who loves coding. Even writing the 100th implementation of a table view or setting up a views layout in code gives me joy. My brain rewards me with dopamine when I write boilerplate code.

I guess the reason for this is that occasionally while typing a boring implementation of a boring table view again I have an idea what could be improved. This is rare but when it happens I’m exited for days. Situations like this feel awesome. If this ever happened to you, I guess you know what I mean.

All this joy evaporates when an agent suggests code. I have less good ideas when reading the code of others. Sometimes I learn something but it’s more like learning in school or university. It’s nice but it fails to even remotely compare to the feeling of creating something elegant by myself.

I get (even more) grumpy if I don’t write code regularly. Then my wife asks me to write some code to brighten my mood. I’m not making this up!

“Grumpy. Angry. Stupid. How long since last sleep code, question?”

2. Environmental impact

Coding agents need lots of energy and water. This energy and water consumption has a huge negative impact on the environment. What use has a boring and bad application or service on a planet where nothing grows anymore? We have to solve very demanding and complex problems before we can use AI for coding.

I have two children and even before everyone stopped caring about the environment because they are to lazy to write code themselves, I has afraid of their future.

3. Modern colonialism

All current models have been trained with stolen data and labor. All profits flow to the rich and wealthy. People have been and are right now exploited by AI companies to make the wealthy richer.

This is wrong and by using these agents trained with stolen data and labor I am wrong as well.

4. The end of learning

I learn by doing. When I stop coding, I stop learning about code. Learning is slow. It took me years to become an acceptable coder. And I need constant practice to keep my skills.

A few years ago I realized that creating table view using diffable data sources was hard. I had to look up the same thing each and every time. So I forced myself to do lots and lots of table views with diffable data sources. After a while I got it. I was able to use this API without opening the documentation. And this was the moment when I developed my own ideas how to improve the API for diffable data sources. I was able to create helper extensions to make the usage easier. Without doing the hard work I would never achieved this understanding.

5. Bad results

Over the last few weeks I used coding agents. Results are underwhelming. Sometimes the agents tells me that I could improve my code. Sometimes the results are trash. At best the result is what I would have written but without the joy.

As always with conmen if you experience problems like this it’s either your fault or the next snake oil (model) will fix all your problems. Just keep using it.

6. Good ideas aren’t quick

Our brains need time to come up with good solutions. And often we need to make mistakes and figure out the problems ourselves to come up with even better solutions. Without this slow process the solutions can’t be good.

7. (Future) costs

At the moment all AI usage is heavily subsidised. Anthropic, GitHub and OpenAI are gambling, that we are soon not able or willing anymore to write code ourselves. They will have to charge 10x or even 20x when the VC money runs out. OpenAI already started and failed to add ads into ChatGPT.

Why should I buy myself into addiction?

8. Last but not least: It’s against the natural order of things.

I’ve come up with a set of rules that describe our reactions to technologies:

1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works.
2. Anything that’s invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it.
3. Anything invented after you’re thirty-five is against the natural order of things.

– Douglas Adams

This new user interface is garbage. It gets worse when you realize that this had to be implemented by a person working on Xcode. This poor person had to build a user interface that is clearly designed for a bad toy software into a software they have to use every day.

So I assumed the reason has to be that it’s easier to build bad user interfaces in SwiftUI on the Mac. To proof me wrong I build the Behavior settings user interface from Xcode 16 myself using SwiftUI.

It turned out, I indeed was wrong.
Kind of.

It is very easy to build the user interface from Xcode 16 using SwiftUI. Even a person like me, who hates and avoids SwiftUI with a passion can build a usable user interface with it.

(I ignored data handling and there is a bug that the selection of the table on the left side isn’t shown, but apart from that, this seems to work.)

So the question is, why did Apple choose to build such a horrible user interface?

What do you think?

Let me know on Mastodon.

Apple, if you need that code, my DM are open. ;)

(No AI was used to write this post.)

To me it looks like landscape on iOS simulator (or maybe even on the real device) is some kind of hack. First I tried to rotate and shift the frames but this didn’t work. It turned out that the elements would have to be shifted by different amounts.

Next I tried to check how Apple solved this in their demo project. They didn’t. The demo project had the same problem.

OK, next idea: Accessibility Inspector. Turns out, if the source is set to the host Mac, I see the same problem.

But if I change the source to the iOS simulator, the frames are correct.

OK…

At the moment I have no idea how I could change the host in my tool to get the same behavior. I might still release the app with this little flaw.

If you know how to fix this, hints would be highly appreciated!

Until next time, have a nice day, week and month.

(No AI was used to write this post.)

But when the external trackpad is switched off, I need to use the trackpad of my MacBook to control the iOS simulator. I tried apps like Homerow or Shortcat but these do not find all elements in the iOS simulator. In addition, as they need accessibility access to my Mac I might not be able to use them on my work Mac (because they can work like keyloggers).

I’m a developer. So the natural conclusion could be that I have to build such a tool myself. And this is what I tried. I’m not done yet and it’s still not clear if I will succeed. Especially as I face some strange problems right now. But these will be discussed in a later post. This post is about how I build the tool and what it can do at the moment.

Demo

SwiftUI or AppKit?

SwiftUI is a scam.
– Dominik Hauser

I don’t like SwiftUI. So I use AppKit. This comes with another advantage. I can write the code in Objective-C. This is a good thing because I like and miss Objective-C a lot.

In addition the Accessibility API is C-based. Such APIs are easier to use in Objective-C than in Swift.

How this works

Most Mac apps have some kind of accessibility support. For example native controls like buttons or text fields expose themselves to the accessibility system. Screenreaders or other accessibility tools can find those user interface elements. Apps can hook into this system.

In the accessibility API the user interface elements have different roles. For example an NSButton has the role AXButton. Elements can be grouped into AXGroups. A tool can ask the accessibility system for the AXChildren of a accessibility element. And this is what I tried first.

Here is the process. First the app searches for running iOS simulators and takes the first it finds. (I might improve that in the future and let the user select from a list of simulators.)

- (void)findSimulators {
    NSArray<NSRunningApplication *> *applications = [[NSWorkspace sharedWorkspace] runningApplications];
    NSMutableArray<NSString *> *names = [[NSMutableArray alloc] init];
    NSMutableArray<NSRunningApplication *> *simulators = [[NSMutableArray alloc] init];
    for (NSRunningApplication *application in applications) {
        if ([application.bundleIdentifier isEqualToString:@"com.apple.iphonesimulator"]) {
            NSLog(@"simulator: %@", application);

            [simulators addObject:application];

            [names addObject:application.localizedName];
        }
    }

    NSRunningApplication *simulator = simulators.firstObject;
    self.simulatorRef = AXUIElementCreateApplication(simulator.processIdentifier);
    self.simulator = simulator;
    NSLog(@"applicationRef: %@", self.simulatorRef);

    [simulator addObserver:self forKeyPath:@"ownsMenuBar" options:NSKeyValueObservingOptionNew context:nil];
}

Then the app searches for the NSWindow (role AXWindow) and asks it for it’s children. To find the children of an AXElement (in this case an AXWindow) I use methods from a demo project provided by Apple.

+ (NSArray<NSValue *> *)childrenOfUIElement:(AXUIElementRef)element {
    CFArrayRef children = nil;

    children = (__bridge CFArrayRef)([UIElementUtilities valueOfAttribute:NSAccessibilityChildrenAttribute ofUIElement:element]);

    return (__bridge NSArray<NSValue *> *)(children);
}

+ (id)valueOfAttribute:(NSString *)attribute ofUIElement:(AXUIElementRef)element {
    CFTypeRef result = nil;
    NSArray *attributeNames = [UIElementUtilities attributeNamesOfUIElement:element];

    if (attributeNames) {
        if ( [attributeNames indexOfObject:(NSString *)attribute] != NSNotFound
                &&
        	AXUIElementCopyAttributeValue(element, (CFStringRef)attribute, &result) == kAXErrorSuccess
        ) {
        }
    }
    return (__bridge id)(result);
}

Unfortunately there is a bug in the Accessibility API. If the app recursively asks the AXElements for their children it does not find all elements. For example in the following screenshot the navigation bar items (back button and the button on the right) are missing.

After some digging and debugging I found out that the navigation bar is exposed as an AXGroup but with no children. To make sure it’s not a bug in my code I used Shortcat with the same result.

A different approach

The I tried to define a grid and ask accessibility to find all the elements on the grid cross sections. This worked but took significantly longer. First I was willing to accept the worse performance but then I had an idea. What if I use the quick method first and for all the AXGroup with zero children I then use the grid method. This worked. The tool now quickly finds all user interface elements. Hooray!

More problems

The tools works well unless the simulator is in landscape. For some strange reason the frames of the elements are all wrong in this case. I’ll discuss that in a future post.

Until then, have a nice day, week and month.

(No AI was used to write this post.)

I’ve come up with a set of rules that describe our reactions to technologies:

1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works.
2. Anything that’s invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it.
3. Anything invented after you’re thirty-five is against the natural order of things.

– Douglas Adams

I try to avoid AI where ever I can. I ecpecially don’t use it for development tasks. And here is why.

I’m older than thirty-five

So, AI is against the natural order of things.

Good solutions need time

The AI can’t come up with good solutions. It just presents one solution it figured out by adding strings to other strings. I have to figure out if it is a good solution. To figure that out, I need time. I need to think. I need to wrap my head around the problem I try to solve. Figuring out if something works is way harder if I didn’t come up with the solution myself. Most people use just the solution the AI presents and don’t care if it’s a good solution. I don’t like that.

The joy of using my brain

I like using my brain. Figuring something out gives me a dopamine kick. Finally finding a good solution for a problem is the reason why I love coding. Why should I let the AI have all the fun.

Selling cheap

Each input trains the AI. By using AI I help it to finally replace me in my job. I don’t like that.

Environment

AI is destroying the planet faster than my brain does.

Society

AI helps rich people to get free labor from poor people. In this scenario I’m on the side of the poor people. The rich are too rich already. I’m not willing to help make them richer. More than I do already. (Written on a MacBook…)

You

What about you? Do you use AI? Why? Why not?

Fortunately for us, the amazing John Holdsworth wrote a packaged that adds hot reloading to SwiftUI projects. Even better, it’s suprisingly easy to add to your project.

Method One: Swift Package

First, we need to add the following two Swift packages to the project:

• HotReloading
• HotSwiftUI

When asked, only add the HotReloading package product to your target:

Next add -Xlinker -interposable to ‘Other Linker Flags’ in the build settings of the target:

In this method you need to remember to remove the hot reloadng package before you upload your app to App Store Connect.

Method Two: Injection III

You still need to add the HotSwiftUI package to your project. Again add -Xlinker -interposable to ‘Other Linker Flags’ in the build settings of the target:

Next load the latest release of the Inject III app and start it.

Setup your view

In the view file you are currently working on, add the following import:

@_exported import HotSwiftUI

Next, erase the type of the root view using .eraseToAnyView():

var body: some View {
  // Your SwiftUI code...
  .eraseToAnyView()
}

Finally add the following line to your view struct:

@ObserveInjection var redraw

Build and run your app on the Simulator, change some code and save the file. The changes are magically compiled and injected into the running app:

Conclusion

Hot reloading does not work all the time. Sometimes you need to recompile using Xcode. But most of the times it works suprisingly well. Give it a try and see how amazing this is.

And if you like it and it helps in your daily work, consider becomming a sponsor of the project on GitHub.

Thanks for reading!

Along the way I decided to add another widget so the name of the extension didn’t match anymore and I had to rename it.

First I feared that this could be as difficult as renaming a project in Xcode. But it turned out that I just had to replace all the occurrences of the old name.

For now I’ll keep the names of the entitlement files as they have been. This is a problem for future Dominik. :)

Demo code doesn’t need to be good. If you are wondering, this is not how to write unit tests when you are not demonstrating. Try to only have one assertion in a test method.

I got several answers that it’s not practical to write a test for each small little detail one wants to test and that it’s better to test several things in one test if possible. I totally disagree. It might be OK to have several asserts in one test but this should be an exception. Especially in the case of the test code from the WWDC session, I would rather have several tests.

This is the code that was shown in the video:

func testExtractEventCount () throws {
    
    let providerClass = ServerBackedEventProvider.self 

    // Simple cases
    XCTAssertEqual(providerClass.extractEventCount(from: "0 records"), 0)
    XCTAssertEqual(providerClass.extractEventCount(from: "1 record"), 1)
    XCTAssertEqual(providerClass.extractEventCount(from: " 1 record(s)"), 1)
    XCTAssertEqual(providerClass.extractEventCount(from: "25 records"), 25)
    XCTAssertEqual(providerClass.extractEventCount(from:"50 records"), 50)
    
    // Cases we expect parsing to return nil
    XCTAssertNil(providerClass.extractEventCount(from: "NaN records") )
    XCTAssertNil(providerClass.extractEventCount(from: ""))
    XCTAssertNil(providerClass.extractEventCount(from: "jUnKdAtA"))
}

In the demo code is a bug and therefore this test fails in the line extracting from “0 records” and from “50 records”. With the information from this test, the engineer can fix the bug quickly.

But if this test would fail on Xcode Cloud, the engineer would only see the following:

testExtractEventCount(): XCTAssertEqual failed: ("nil") is not equal to ("Optional(0)")

Not really helpful in my opinion. Critical information is missing:

• What was tested?
• What was the precondition?
• What did we expect?

I would split the test assertions into several tests. Testing for the extraction from “0 records” would then look like this:

func test_extractEventCount_whenInputIs0Records_shouldExtractO() throws {
    // given
    let sut = SeverBackedEventProvider.self

    // when
    let result = sut.extractEventCount(from: "0 records")

    // then
    XCTAssertEqual(result, 0)
}

In case of a failure of this test we would see in the test result the following:

text_extractEventCount_whenInputIs0Records_shouldExtractO(): XCTAssertEqual failed: ("nil") is not
equal to ("Optional(0)")

Without looking at the test code, I already know what exactly failed. Tests should help my future self and my coworkers to find the reason for the failure as quick as possible. This is the main feature a test should have. Personally I find the failure message of the second test way better and looking at the test I do better understand its purpose and why it was written.

What do you think? Which of these tests is better? Let me know on Twitter.