Category
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.
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.
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.
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.
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.
A typical iOS project based on the Combine framework at some point defines interfaces that are represented by ‘AnyPublisher’ or ‘AnySubscriber’.
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.