---
title: "SwiftUI | Skills We Assign For | Azendo"
description: "SwiftUI for Apple-platform interfaces — the OS version floor, mixing with UIKit, and the Azendo roles assigned for it."
url: "https://azendo.co/skills/swiftui/"
---

[Skills](https://azendo.co/skills/) Mobile platforms and frameworks 

# SwiftUI.

SwiftUI is Apple's declarative UI framework: interfaces are described as a function of state, and the framework handles updating the view hierarchy. It is the default for new Apple-platform work and interoperates with UIKit in both directions.

## Where SwiftUI fits on a long engagement.

The decision that shapes a SwiftUI project is the minimum OS version, because the framework has changed substantially each year. Features available on iOS 17 are absent on iOS 15, and supporting an older floor means either avoiding whole areas of the API or writing availability-conditional code that doubles the surface to test.

SwiftUI is excellent for standard interfaces and still awkward at the edges. Complex list behaviour, fine-grained scroll control and heavily customised navigation are all cases where teams reach back into UIKit through a representable wrapper. That is a normal, supported outcome rather than a failure, and planning for it is more realistic than assuming it away.

## What an assigned team does with SwiftUI.

Because the framework moves every year, a SwiftUI codebase has a maintenance cadence built into it. An app that ignores two OS cycles does not stand still; it accumulates deprecated patterns and misses the platform behaviour users now expect from every other app on their phone.

Interface work is also where design and engineering are least separable, which is why this capacity is usually scoped with a designer on the same agreement under an [outsourced design team](https://azendo.co/services/ux-ui-design/) rather than sequentially.

## What we use SwiftUI for.

* New applications on a current OS floor Building where the framework is strongest, without carrying availability branches for versions few users run.
* Incremental adoption inside a UIKit app New screens in SwiftUI hosted in the existing navigation, so modernisation ships continuously.
* One codebase across Apple platforms Shared interface code for iPhone, iPad and Mac where the product genuinely wants all three.

## How SwiftUI capacity is assigned.

SwiftUI capacity is assigned inside mobile development, most often with design capacity on the same agreement rather than handed over between them.

## Roles we assign SwiftUI for

* [iOS Developer Mobile development](https://azendo.co/services/mobile-development/ios-developer/)

## Service lines it sits in

* [Mobile development](https://azendo.co/services/mobile-development/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in mobile platforms and frameworks

* [UIKit — skill we assign for](https://azendo.co/skills/uikit/)
* [Jetpack Compose — skill we assign for](https://azendo.co/skills/jetpack-compose/)
* [Coroutines — skill we assign for](https://azendo.co/skills/coroutines/)
* [Flutter — skill we assign for](https://azendo.co/skills/flutter/)
* [React Native — skill we assign for](https://azendo.co/skills/react-native/)
* [Expo — skill we assign for](https://azendo.co/skills/expo/)
* [Ionic — skill we assign for](https://azendo.co/skills/ionic/)
* [React Navigation — skill we assign for](https://azendo.co/skills/react-navigation/)

## Tell us what your roadmap needs SwiftUI for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)