Articles
In my software factory series, raising expectations leads to a question: how much human attention does a useful result take? Explaining, steering, reviewing, correcting, and verifying all count.
I have always encouraged modular architecture. Clear ownership and explicit contracts make changes easier to understand, implementations easier to replace, and independent work easier to do in parallel. Focused modules also support focused tests and reuse of unchanged build artifacts, shortening the feedback loop.
In my software factory series, I want to make higher expectations concrete. If coding agents can multiply what we achieve, then at least doubling our output is a bar worth discussing seriously.
In my software factory series, I turn observations about where my attention goes into tools. My approach is straightforward: define the inputs and expected result, let an agent build a useful version, and improve it through real work. I'm comfortable keeping the implementation rough and vibe coded in a controlled environment.
Many developers are still uncertain about coding agents. The “engineers are cooked” refrain does little to help. Fast demos are exciting, but they leave an important question open: how do you use these tools to build production software well and still enjoy your craft?
The iOS community deserves tooling designed for how we increasingly work: several coding agents editing, generating, linting, building, testing, and merging throughout the day. In that workflow, “written in Swift” tells me very little about whether a tool is a good choice. I care about the correctness of its output and how quickly I can get the next useful result.
Our iOS app occasionally logged users out for no visible reason. Nothing in the logs pointed to a bug. The refresh endpoint answered, the tokens were valid, the session was gone anyway.
I run practically every agentic coding session in a separate Git worktree. Each worktree gets a dedicated iOS simulator. All simulators share one OAuth session.
Tuist module cache is great. But treating it as one magic switch is where the pain starts.
The current shift toward AI-assisted software delivery is often framed through an individual lens. Will engineers lose relevance? Will coding still matter?
A client showed us their designs. Among them, an animated globe. Core to the UI delightfulness, technically non-trivial, the kind of thing that usually gets a "we'll figure it out during development" footnote in proposals. I decided to check how hard it actually was.
Most people treat promotions like gifts. They say yes immediately, afraid the offer might disappear. Then six months later they're drowning in a role they never properly understood, working for someone they wouldn't have chosen, wondering what went wrong.
You can read dozens of leadership books and still not know whether your boss is any good. Most frameworks are either too abstract ("be authentic!") or too narrow ("here's how to run a 1:1"). Here is a list of traits I actually look for when evaluating leaders - whether I'm hiring, promoting, or figuring out if the person above me is worth following.
Leadership development focuses on charisma, empathy, vision, communication. All important. But they miss the foundation: logical consistency.
You hire people you think are great performers. Their performance turns out average.
Simon Sinek's "Start With Why" is one of the most influential business ideas of the last decade. If you've been told to paint the vision first and work backward from there, to inspire people with the future before worrying about details, you're following advice that sounds transformative but often paralyzes organizations in practice.
Leaders love to give HR teams ambitious missions. Build culture. Create belonging. Drive engagement. HR believes it. They run employee surveys, launch initiatives, mediate problems between people and managers. They work hard. They mean well.
If you're a CEO who genuinely values collaborative strategy and thoughtful decision-making, but you keep watching months pass with no real progress, you might be facing something uncomfortable to recognize: your greatest strengths as a leader might be exactly what's creating paralysis in your organization.
If you're trying to build team trust with personality color tests or vulnerability workshops, I have some uncomfortable news for you.
If you've learned to delegate well, asking clearly, giving context, setting reasonable deadlines, but your team is still burning out, the problem probably isn't in how you're asking for work.
When people talk about modular architecture, they usually mention the same benefits: faster builds, easier testing, clearer ownership. All true. But there's one scenario where modularization quietly proves its worth, and it rarely comes up in architecture discussions: Merging two applications into one.
After years of building mobile apps, I've found that the most valuable analytics use cases are often the least obvious at first glance. The events that matter most are usually not the ones your analytics SDK gives you out of the box. They're the ones that help you understand silent failures, quantify technical tradeoffs, and recover data your backend model never thought it would need.
Have you ever felt the ineffectiveness of a team whose member you are? Have you struggled that the team’s decisions are not the same as yours and you didn’t understand that? Maybe you felt that all the team members point in different directions.
Have you ever wondered what we do as software development teams or what is our long-term purpose? Having such a perspective on why we do things as a team is extremely powerful but sometimes difficult to define.
XcodeGen is a tool for improving the generation of .xcodeproj files and their maintenance over time. By defining a simple YAML manifest you get a whole .xcodeproj in seconds. But that’s not everything! There is one more built-in feature — dependency graphs. In this article, I would like to cover possible use cases of a such graph.
Several times in my “leadership career” I heard an opinion that the team I lead is not “my team”.
When it comes to modularisation on Apple platforms, development teams point must deal with adding a new module at some point. In this article, I would like to present my approach to automating this work.
Every development team that works with the product has a Product Manager. Sometimes it’s a Manager that works on a daily basis with a team, sometimes it’s a guy that catches up with the team once per week. Whatever the relation is this person usually tells the team what to do next and why it matters. Sounds familiar?
A typical iOS project based on the Combine framework at some point defines interfaces that are represented by ‘AnyPublisher’ or ‘AnySubscriber’.
Supporting people's growth is probably one of my favorite team leader “duties”. When writing this article I’ve been a leader for more than 2 years and I must say, I’ve been doing it wrong for most of this time…
Hey, today I would like to say a few words about my experiences with testing applications. It's a compilation of what I've tried so far with tests through many languages and technologies but especially related to the ones from Apple.
Welcome back to the story of iOS CI at AppUnite company.
It's almost the end of 2019 - exactly 3 years after the U.S. presidential election and maybe America isn't made great again but we all need to admit that it was a pretty good electoral slogan.
Some time ago, when I started working with Reactive Programming concept for developing iOS applications I struggled a lot with testing such products.
A Product Owner doesn’t see any business value in adding automated tests to a project - this problem concerns many projects and software developers.
In this article I want to share my experience with building dependencies by using Carthage. First of all, Carthage shines with simplicity. It's very simple to start using some external dependency in a Xcode project just by adding proper line into Cartfile and running carthage update. But as we all know, life is brutal and sometimes we need to consider more complex examples.