Status
Open to senior, lead and staff iOS roles, full‑time or contract. Remote, from Skopje.
Skopje

I’ve worked on iOS since 2014.

I started at a small agency in Skopje, writing Objective-C for clients, and was leading client projects within two years. At WS Audiology my work grew from my own code to how a whole team builds, first as tech lead, then as product architect. Since then I’ve worked on BeReal’s Memories squad and on a business banking app, and I make my own apps.

Sasho Jadrovski, laughing

Principles

  1. Architecture should make the next change cheap.

    I look at where the boundaries should sit and which decisions will be expensive to undo, and I spend the effort there. I only add abstraction the current work needs, because every layer has a cost. If something depends on people being careful, I change the design: at Widex I reworked the navigation layer so nobody had to clean up after it by hand.

    Filip LazovHead of Shared Product Services, Widex

    “I even remember once he improved the codebase where the navigation quality matched that of the best Apple engineers.”

    Read Filip’s review
  2. Code should read like a book.

    The same kind of file has the same structure, and each type has one reason to change. Standards that matter live in lint rules and review, so they don’t rely on memory. I fix what’s out of place in the file I’m in, and a real issue found in review gets fixed now.

    Christian SchmidtManaged me at WS Audiology (Widex)

    “His dedication to clean, readable, and guideline-compliant code has made him a cornerstone of our team, playing a pivotal role in defining and upholding our coding standards.”

    Read Christian’s review
  3. Correctness comes before convenience.

    I reproduce a bug and find its cause before changing anything, and a fix has to explain the bug. Tests cover the behaviour that matters. At Widex that meant unit and UI test suites kept green across long-lived release branches.

    Internal reviewWillowTree

    “He owned the issue and followed through completely on it.”

    Read the internal reviews
  4. Apple’s pattern is the default.

    If code departs from what Apple documents, I fix it. When Apple’s sources and a blog disagree, Apple’s win. A new dependency has to earn its place.

  5. Feel is a feature.

    I build designs down to the motion, and performance work has to keep the look people already have. If a design fights the platform, I say so early and bring an alternative.

  6. The hard part is rarely the code.

    It’s deciding what to build, and what to leave out. I look at cost against value, and I raise it early when a feature could be simpler.

    Court BlufordProduct Owner, Virginia Lottery mobile app

    “He has a great way of breaking down complex topics and guiding conversations in a way that moves everyone forward.”

    Read Court’s review
  7. Big changes are planned so they can ship.

    Small phases, tests first, refactoring kept apart from new behaviour. I raise risks, delays and costs early, while there’s still time to act on them.

    Court BlufordProduct Owner, Virginia Lottery mobile app

    “…the way he communicated with cross-functional teams, stayed cool under pressure, and always kept the big picture in mind.”

    Read Court’s review
  8. I evolve standards with the team that has to live with them.

    At Widex I was technical lead of an iOS team that grew to 15 engineers, evolved our architecture and coding standards with them, ran knowledge sharing and built our hiring process with the chapter lead. In reviews I ask questions before I state opinions, and I coach people to find the answer themselves.

    Christian SchmidtManaged me at WS Audiology (Widex)

    “…he’s also an exceptional teacher and mentor.”

    Read Christian’s review

How I work

  1. 1

    Assess

    I learn how the app is built and why, then write down where it’s fragile and what matters most.

    A written assessment

  2. 2

    Decide

    We agree what to build, what to leave out and what it will cost.

    A plan in phases

  3. 3

    Build

    I take on the hard parts myself and set the patterns others can build on.

    Reviewed code and shared patterns

  4. 4

    Ship

    Each phase is small enough to review, test and roll back.

    Releases covered by QA

  5. 5

    Look after it

    I follow crash reports and real usage, fix things at the root and write down what I learn.

    A healthy app, and a team that doesn’t depend on me

With AI

I use Claude Code every day. It lets me go further on my own, and I still read what goes in. Agents get a narrow brief, and I check their diffs against what I expected. Decisions and merges stay with me.

What I’m looking for

Senior, lead or staff iOS. Big team or small, product or client work. What matters most to me is how the app feels and how well the team builds it.

Details

  • ToolsXcode, Instruments, Swift Package Manager, RocketSim, SwiftLint, fastlane, Figma, Claude Code, Fork, Ghostty.
  • EducationBSc, Information Science and Computer Engineering, Faculty of Computer Science and Engineering, Ss. Cyril and Methodius University, Skopje, 2014.
  • LanguagesMacedonian (native), English (full professional).

The full history is on the Work page and in my CV.

Personal

I’ve been building things on the internet since high school. In 2010 my friend Nikola and I started бркај работа, a Macedonian entertainment portal, and it became one of the top ten in the country.

Outside work I play guitar, mostly rock and metal, and in high school I was the second guitar in a metal band.

Open to senior, lead and staff iOS roles.

Full-time or contract. Remote, from Skopje, overlapping with Europe and US mornings.

hello@jadrovski.com·CV·Home