Engineering
Studio
By industry · 12
Veodar
Technology · Interfaces for Apple
SwiftUI is the current way to build interfaces on Apple's systems: the screen is described from small pieces and from the state of the data, and it redraws itself when that state changes. We build new interfaces and a component system of your own, and migrate old screens without stopping the app.
Often combined with
Situations
SwiftUI pays off when the app has many screens that must look alike, adapt to whoever uses them and change often without breaking.
Every design tweak means touching several files and testing everything again. With reusable pieces, the change is made in one place and shows on every screen that uses them.
Large text, dark mode, screen reader or right-to-left text. In SwiftUI most of it comes built in if the interface is built properly from the start.
A widget on the home screen, the status of an order on the lock screen or a view on the watch. These are extensions Apple asks to be built with SwiftUI.
There is no need to redo it. New screens are written in SwiftUI and live alongside the old ones, which are replaced one by one when their turn comes.
Services
Four kinds of job. The first two usually go together: the screens come out of the pieces.
Module 1 · FrameLists, forms, detail views and navigation, with their empty, loading and error states, built on the app's real data and tested with large text and in dark mode.
Examples of deliverables
Module 2 · Parts caseYour brand's colors, type, buttons, fields and cards turned into named pieces, documented and with their preview, so every new screen is assembled from them.
Examples of deliverables
Module 3 · Old plateUIKit screens are replaced one by one, starting with the ones that change most. In the meantime both ways of building an interface live in the same app without the user noticing.
Examples of deliverables
Module 4 · PreviewThe information that matters, outside the app: a widget, the tracking of an order on the lock screen or a view on Apple Watch, fed by the same data.
Examples of deliverables
A working example
Working example on made-up data. Here you don't touch the screen, you touch the state: how many orders there are, the text size and dark mode. The screen and the widget recompose themselves from the same description.
The state
Pending orders
The description of the screen
The screen and the widget are drawn in your browser from the description you see beside them; it is not a real app or Apple code. It shows the idea behind it: the interface is a function of the state.
Integration
SwiftUI is the layer you see. Underneath are the app's data and rules, written in Swift, and around it, what already exists.
Where it comes from
Where it goes
How we work and what we deliver
We look at the screens that exist, what they are built with, the minimum iOS version and the design we start from.
We write down which screens and pieces come in, in which order the old ones are migrated and what stays out.
The first pieces and one whole screen working inside your app, on real data.
You test it with large text, in dark mode and with the screen reader, as well as in normal use.
The catalog of pieces with their previews and the rules for building new screens from them.
Questions
Missing yours? Write it to info@veodar.com and we'll reply with a specific question, not a brochure.
No. SwiftUI and UIKit live in the same app: a new SwiftUI screen opens from an old one and the other way round. The usual path is to start with new screens and the ones touched most, and leave the stable ones for later.
SwiftUI has grown with every iOS version, so the minimum version your app supports decides what can be used. We check it at the start against your users' real devices and it is written into the scope.
Yes, and that is where most care goes. Each migrated screen is released separately and compared with the previous one before that one is retired. If something gets worse, we go back without touching the rest.
It shares pieces and rules, but it is not the same screen stretched. Each device has its size and its way of being used, and the interface adapts to that. What doesn't change is the data or the brand look.
Much of the basics is included: the system text size, contrast, the screen reader and dark mode work if the pieces are built the way SwiftUI expects. What doesn't come by itself, reading order or the labels of icon buttons, we review screen by screen.
SwiftUI is only for Apple's systems. On Android the equivalent is Jetpack Compose, which works on the same idea. If the app is on both systems, the design and the names of the pieces are shared even though the code is different.
Updated:
Other technologies
Get started
A few screenshots of the app or the design you have are enough for a first answer.
What helps us assess it
Before you write, see how we price a project or our solutions by department.
Cookies
We store your language and this choice so the site works. With your permission, we measure visits and speed anonymously, with no tracking cookies or advertising.
Cookies
Necessary
Your language, this choice and spam protection on the contact form.
Anonymous measurement
Page views and load times, in aggregate, through Vercel. No cookies, no tracking across sites.