The Strangler Fig pattern 🧬

What is it? 🤔

This pattern is kind of a proxy: it intercepts clients requests, map them and redirects them from a legacy dependency (application or service) to its newer version.

When should you use it? ⌚

1. You need to migrate a service from one version to another
2. You have a client application which is complicated to update (too complex, too big, knowledge lacking, etc.)
3. You want to avoid disruptions and reduce the risks

When could it goes wrong? 😱

1. It’s impossible to map a Legacy request or a New response
2. It’s impossible to intercept all clients requests
3. The New dependency haven’t access to the same resources as the Legacy dependency (as different or not synchronized data stores for example)

Our use case at AVIV 🔍

Who is AVIV? 🤔

The AVIV Group is one of the world’s largest digital real estate tech companies, present across our key markets in France, Belgium and Germany. It includes some leading brands, like SeLoger 🇫🇷, Immowelt 🇩🇪, Immoweb 🇧🇪, Meilleurs Agents 🇫🇷 or also Homeday 🇩🇪.

Our company’s mission is to unlock everyone’s perfect place.

Our use case 🧐

Our Data team developed multiple internal APIs, for example to expose market insights, valuation models, a geographic referential, etc. Some months ago, they had to upgrade theses APIs to a second version without backward compatibility and are now maintaining both versions, but it’s costly 💸

The problem was that a lot of our micro-services in Meilleurs Agents stack were using them and also that we hadn’t the workforce (one team) nor the time (one month) to update all usages: the work was way too big! 😱

Our use case was a perfect application for the Strangler Fig pattern ✅

How we used it at AVIV 🧭

First step: a simple proxy 👮

We started by building a very simple proxy application: it intercepts all client requests and redirects them to the legacy system.

It allowed us to:

1. Check that all client requests are going through the proxy: none should be missed
2. Give visibility on load per endpoint: requests per second, response time, real usage, etc.
3. Ensure our proxy can handle the needed load

Second step: an hidden mapper 🤫

Then, we started to map the legacy requests (and obviously the newer responses) in the background: it has no impact on “visible” behavior!

After we call the new dependency, we compare both responses: the Legacy one and the Mapped one. If they are not the same, we log the differences.

We need to implement the mapping for all used endpoints of the Legacy dependency.

It allowed us to:

1. Develop without any risk
2. Test our mappers in real environment to ensure that the Mapped response is the same as the Legacy one
3. Ensure our New dependency is ready to handle all the new load coming with this migration

Third step: migrate endpoints one by one ⤵️

Once an endpoint has been tested, we simply configure our Proxy to return the Mapped response instead of the Legacy one. We did it one by one in order to limit the risks. If something goes wrong, we can quickly rollback to return the Legacy response again.

We can optionally continue to call the Legacy dependency in the background for monitoring purposes, or simply stop it.

Fourth step: cleanup 🧹

Once all the endpoints are migrated, you can remove all dead code in your proxy: background tasks, calls to Legacy dependency, responses comparison, etc. The goal here is to have the lightest Proxy possible.

Final step: legacy dependency removal 🗑️

Then here we are, the culmination of all this work: you can finally decommission the Legacy dependency 🙌

Final thoughts

We were in a really hard situation, but we did it! 🏆And the Strangler Fig pattern was a game changer for us 🦸

We avoided to update a lot of applications, from front-end to the databases, and we were able to deploy it really smoothly, one endpoint after another. Plus, a great advantage of this pattern is that we have all mappings centralized in one place, helping checks and acting like an “how-to-migrate” documentation.

But we also encountered some difficulties:

• Some responses were difficult to map (outdated data, different geographic referential, different ordering, different default values, etc.), but without this pattern, it would have been the same.
• The proxy is intensively used and we needed to focus on performances and availability on multiple levels: hardware resources, CI/CD, technologies selection, gunicorn/uvicorn configuration for FastAPI, etc.
• And finally, one very specific case: the calls to the dependencies needed to be internal but are on a different cloud provider, forcing us to split the proxy in two parts.

Even if the Strangler Fig pattern isn’t ideal as a long-term solution (for performance and cost reasons), we didn’t plan to remove it for now. But it enables us to upgrade client applications one by one if we want to.

Resources

1. Strangler Fig pattern description in Microsoft’s website
2. Martin Fowler’s blog post about Strangler Fig pattern application

Modernize without breaking everything — the Strangler Fig pattern in action! was originally published in AVIV Product & Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is fine to go through all of this by hand when you have to define a single form in our app, but what if you have multiple forms ? Not 2 or 3, but more like 5 or 10 ?

For sure, you don’t want to redo everything every time… right?

In the iOS dev team at AVIV, we develop our features using The Composable Architecture (aka TCA). At the time I write this article, there are no tools to define a form in TCA, so we had to come up with a solution on our own.

Note: We won’t dive into how TCA works. But if you’d like to know more about it, here is a good talk to present it.

By talking about unifying form validation, what am I talking about and what am I not talking about ?

The tool we developed focuses on defining the model and the validation rules for a given form.
It doesn’t help to define the UI side.

TCA has a clear separation between the view and the logic, such that we allow any kind of view to represent the form we define on the logic side. That’s really helpful if you want to quickly iterate over the look of the form for example.

The main issues we faced while developing our forms without being unified were:

• validation trigger inconsistency
  sometimes the validation was triggered every time the value changed (while in other forms it was only when the focus changed), or when submitting the whole form
• code duplication
  to validate the whole form after the user taps on the submit button, we always need to go through each field and validate it
• basically reinventing the wheel on every form
• no proper way of testing the validation behaviour (or it should have been, once again, duplicated for every form)

So how did we solve these problems?
By creating what we called a FormValidationReducer and few other helping units.

How to use the FormValidation

Here is a code example of using the FormValidationReducer.
It looks heavy but don’t worry, I will explain each part after

@Reducer
struct MyFormReducer {
  struct State {
    var username: ValidatableField<String> = ""
    var password: ValidatableField<String> = ""
  }
 
  enum Action: BindableAction {
    case binding(BindingAction<State>)
    case sendFormButtonTap
    case formValidationSucceed
  }
 
  var body: some ReducerOf<Self> {
    BindingReducer()
 
    FormValidationReducer(
      userAction: \.sendFormButtonTap,
      onSucceed: .formValidationSucceed,
      fields: [
        FieldValidation(
          name: \.username,
          rules: [
            .nonEmpty("Username is required"),
            .length(min: 5, "Username is too short, at least 5 characters needed")
          ]
        ),
        FieldValidation(
          name: \.password,
          rules: [
            .nonEmpty("Password is required"),
            .length(min: 8, "Password needs to be at least 8 characters long"),
            .containsAtLeast(1, .uppercase, "Password should contain at least 1 uppercased character"),
            .containsAtLeast(1, .digit, "Password should contain at least 1 digit"),
            .disallowed(.specialCharacters, "Password can't contain special characters")
          ]
        )
      ]
    )
 
    Reduce { state, action in
      switch action {
      case .formValidationSucceed:
        // do anything upon form being successfully validated
        return .none
      }
    }
  }
}

As you can see, to define a form, we add the FormValidationReducer in the corresponding form’s reducer.

FormValidationReducer parameters

User action

The first parameter to send to the FormValidationReducer is userAction.

This is a KeyPath to the action that is sent by the View when the user initiate the form’s validation process. Usually by tapping a “Send” button at the bottom of the form.

On Succeed

The next parameter corresponds to the action that is expected to be sent by the FormValidationReducer when the form validation succeeds.

That is, to allow the feature to react to the form successful validation and do additional work. Usually sending the form’s information to a back-end server.

Fields

Last but not least, we need to pass the various field information to validate in the form.

Each field is represented by a FieldValidation value type that lets the FormValidationReducer to know:

- which data in the State to validate, by using a KeyPath to the State’s value
- which rules to run over the grabbed value, by using a list of Rule value types

In our example, we want to validate both the username and the password.

A note on the fields type:
In the above example, you may have noticed that the username and password are of type ValidatableField<String>.

This value type was added as a kind of “syntactic sugar”, to make both the State and the FieldValidation lighter to use.

To see how, let’s show both types as if we were not using the ValidatableField type:

// MyFormReducer.State
struct State {
  var username = ""
  var password = ""
 
  var usernameError: String?
  var passwordError: String?
}

// MyFormReducer.body
var body: some ReducerOf<Self> {
  BindingReducer()
 
  FormValidationReducer(
    userAction: \.sendFormButtonTap,
    onSucceed: .formValidationSucceed,
    fields: [
      FieldValidation(
        name: \.username,
        error: \.usernameError,
        rules: [ … ]
      ),
      FieldValidation(
        name: \.password,
        error: \.passwordError,
        rules: [ … ]
      )
    ]
  )
 
  Reducer { state, action in … }
}

As you can see, by not using the ValidatableField type, we would have to write every time both the field’s value information (i.e. var username, field: \.username) and their error value counterpart (i.e. var usernameError: String?, error: \.usernameError).
That rang a bell to us as if the two values “field” and “fieldError” wanted to always be treated together. That’s exactly what the ValidatableField<T> does! Here is its basic declaration:

struct ValidatableField<Value> {
  var value: Value
  var error: String?
}

Error handling

As you may have already guessed from the example, the FormValidationReducer makes it easy to handle validation failures.

Because we require to have a KeyPath to the fieldError state, we make sure that no field is left with hidden validation failures. The FormValidationReducer is responsible for grabbing the error message from the failing Rule, and set it the corresponding fieldError state.

Testing

Because the FormValidationReducer is a reducer, it’s pretty easy to test its behaviour in unit tests.

All you have to do is to initialise a TestStore with your form’s Reducer and the state you want to check, send the userAction and assert that you either:

- receive the onSuccess action if you expect the validation to succeed
- receive the new state with the corresponding errors in expected failed fields

Conclusions

Thanks to that FormValidationReducer, we are able to:

- declaratively define a form and its fields to validate
- enforce a single validation behaviour, because the validation logic is defined in the FormValidationReducer itself

For a more in-depth talk on how we came up with this reducer and how it works under the hood, you can:

• watch a talk I made for the SwiftConnection on Youtube

• reach to our public repository, that open-sources the presented form validation code, and ships an example project you can play with.

https://github.com/Aviv-public/swift-form-validation

Unifying form validation using TCA was originally published in AVIV Product & Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

A few years ago, my ex-CTO, Erwan Ripoll, made me discover the world of accessibility. It hit me hard. I always wanted to make great apps as an iOS developer — fine tune the user experience, design, fluidity and ease of use. However, I never gave much of thought to accessibility — or rather my definition of accessibility was flawed. Today, (like it happened to me) I’d like to reshape your perceptions about accessibility!

We often hear about accessibility nowadays. It has become a buzz word. The question is, what really lies behind it? What does it mean?
Why should we care? And is it really important for mobile apps?

These are questions I asked myself over the years — and here’s what I found out…

What is (digital) accessibility?

There’s a definition about accessibility I really like to give as it usually shatters — right of the bat — the conception people tend to have about it.

Accessibility is the practice of ensuring that we create products that can be used by anyone regardless of their capabilities.

You read it right — it’s a practice, a practice we must learn and get better at. But moreover it’s about creating products for everyone… and I’ll come back to that soon enough!

“Disability” you said?

When people think about accessibility, they tend to have another definition of it; one tied to disability. Fair enough! But what is a disability? Well… once again, there’s more to it than we could think.

We can define a disability as an illness, injury or condition that makes it difficult for someone to do the things that other people do.

And of course, first things that come to mind are the most obvious disabilities like being in a wheelchair, being blind, and being deaf, while there are many other kind of visible — and mostly invisible — disabilities, like being colorblind, having arthritis or having dyslexia, just to name a few.

It impacts a lot of people

Not only most disabilities are invisible, but most of them are not permanent. Coming back to our initial and most obvious examples when it comes to disability: wheelchairs, blindness, deafness — those are permanent disabilities which people cannot recover from.

What people are usually not aware of is that disabilities come in 3 forms of temporality:

1. Permanent (e.g. having an amputated arm)
2. Temporary (e.g. having a broken arm in a cast)
3. Situational (e.g. holding a child in one’s arms)

The context is different but the result is the same: a person is disabled (e.g. cannot use their arm) whether the handicap is permanent, temporary or depending on the situation.

According to the World Health Organization, about 16% of the global population experience significant disability (source). And this is not factoring in all temporary and situational disabilities.

There are many many people temporarily disabled and even more situationally disabled. For instance, someone might struggle to read a screen under bright sunlight, type on a keyboard with a broken arm, or hear a phone call in a noisy crowd.

Data, data, data!

At AVIV Group, we decided to look into how many of our mobile users are actually using accessibility features on their phone and the result is staggering!

• 1/3 of our users on iOS are not using the default font size
• 40% are using dark mode
• Between 29% and 47% are using an accessibility feature

You can find similar numbers over the internet. A good website I recommend with tons of stats and great info on accessibility is https://appt.org/en/stats.

When you build for accessibility, everyone benefits

Without delving into how to concretely make accessible products, I’d like to showcase how building for accessibility benefits everyone.

At heart, accessibility is a key piece of usability and is an inherent part of it.

Not caring about accessibility is degrading your product’s usability — and working on usability without thinking about accessibility means you are not taking into account how people might use your app in different situations/context (remember situational disabilities?).

I like to give a non-digital example of how a simple accessibility feature can benefit everyone: an entrance ramp.

Imagine standing in front of a grocery store. To enter, you have two options: take the steps leading to the entrance or use the gently sloping ramp nearby. While this is a feature made initially for disabled people in wheelchairs, it actually benefits many more people: elders, parents with their babies in a stroller, cyclists, delivery persons with heavy packages to carry.

Accessibility features tend to have far more reach than their original intention. The entrance ramp is a great example of that, but we can look at many more digital examples…

Text size

Making your interface adapt to the user’s preferred text size is key. While the obvious use case here is for users with low vision (or dyslexia, low attention span, etc.) to increase the text size, we can clearly see that 12% of users also take advantage of such feature to decrease the text size in order to see more on screen.

Dark mode

Dark mode quickly gained in popularity a few years ago although being at its core an accessibility feature. Lots of users are using it. Almost 40% on iOS. Sometimes full time and sometimes based on the time of day. Who likes to be dazzled by the screen brightness of their phone — in light mode — at night before going to sleep? No one. That’s why so many people are using dark mode.

Subtitles

Subtitles are now everywhere, and people use them on a daily basis, whether they are deaf or not. They make it easy to follow some content in a noisy environment or follow your favorite Netflix show in its original language while having the subtitles in their own language. Most social media apps even autoplay the videos in silent with subtitles enabled.

These are just a few examples that building for accessibility benefits everyone.

Conclusion

Accessibility is not only about disability. It is mainly about making products usable by everyone. The features we must support may appear to serve only a small group of people, yet they often have a far-reaching impact, because many individuals live with permanent disabilities, and an even larger number experience temporary or situational limitations.

In the end, I strongly believe that:

We are personally responsible for becoming more ethical than the
society we grew up in.
 — Eliezer Yudkowsky

We should stop seeing accessibility as a chore for a minority of our users. Accessibility is about tailoring your products to everyone. It’s about pushing the boundaries of what’s possible. It’s caring about your users. It’s wanting to deliver a great user experience. It’s about innovation.

Let’s start embracing accessibility today!

Embracing accessibility was originally published in AVIV Product & Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Say goodbye to copy-pasting text between apps!

With iOS 18, Apple’s new Translation API brings translation seamlessly into the user experience.

Users do not have to copy and paste a text from an app to a translation apps anymore. They will be able to translate a text directly within the app elegantly.

Moreover, they'll be able to replace any text in the app. This includes any field or label. Sequentially or all at once.

I’ll walk you through some experiments with this powerful API and showcase a demo app that illustrates how some made up real-world scenarios can benefit from these features.

We can demonstrate the APIs capabilities in three main categories:

System UI

Using Apple native tools to translate text in Translation in-app popup and optionally replace the original text in the app.

• Overlay Translation
• Replace Translation

Custom UI

Translate a text or a batch of those and tailor your UI as you see fit.

• Single String
• Batch of Strings
• Batch as a sequence

Availability

Checks the availability of translations based on user preferences, device settings, and installed language packs.

• Language availability
• Prepare for Translation

Plus, I'll share with you what you should expect and what I encountered unexpectedly.

Let's jump in.

Requirements

• A real device (Translation API is not supported on simulated devices. Also not on Preview)
• iOS 18.0 +
• Xcode 16.0 +
• Apple's Translate app has to be installed on the device. Since iOS 14, it's installed automatically.

Demo project

Here you can download the demo app and run it on Xcode.

Features are developed using both just a view and with a view model to provide flexibility on implementation.

https://github.com/Aviv-public/apples-translation-api-demo

System UI

Overlay Translation

• Opens an overlay of Apple’s Translate app within our app.
• Just like copying and pasting a text to the Translate app.
• User can pick any source and target language they want in the overlay sheet.

In this example, we showcase a legal disclaimer page. Let's pretend that, to comply with local law, the particular disclaimer below must be displayed in the local language. However, to simplify the experience for our international users, we also offer a convenient button that provides a quick translation, allowing users to easily understand the content in their preferred language

struct LegalDisclaimerDemoView: View {
    let legalTextTitle = "Nutzungsbedingungen"
    let legalText = "Diese App dient ausschließlich ..."

    var textToBeTranslated: String {
        legalTextTitle + "\n" + legalText
    }

    @State var isTranslationOverlayPresented = false

    var body: some View {
        ...

        Text(verbatim: legalText)
            // Presents the sheet binding it to a boolean 
            // just like presenting a sheet
            // Add the source String as the text argument.
            .translationPresentation(
                isPresented: $isTranslationOverlayPresented,
                text: textToBeTranslated
            )

        ...
        .overlay(alignment: .topTrailing) {
            Button {
                // Show translate overlay
                isTranslationOverlayPresented = true
            } label: {
                Image(systemName: "translate")
            }
        }
        ...
    }
}

Replace Translation

• Opens an overlay of Apple’s Translate app within our app. Same as the prior feature.
• User can pick any source and target language they want in the overlay sheet.
• Now presents an option called “Replace with Translation” to replace the text within the app.
• Replacing the translated String is up to the developer.

In this example, we present a real estate property detail page. The description was filled in French by the seller. We provide a button to see a translation of this description, and elegantly replace it inside of our app. Notice how the description turns into English.

struct PropertyDetailDemoView: View {
    ...

    @State private var isTranslationOverlayPresented = false

    var body: some View {
        ...
        .translationPresentation(
            isPresented: $isTranslationOverlayPresented,
            text: viewModel.property.description
        ) { translatedText in
            ...
            // Replace the translatedText here
            viewModel.propertyDescription = translatedText
        }
        ... 
        Button {
            isTranslationOverlayPresented = true
        } label: {
            Image(systemName: "translate")
        }
    }
}

Custom UI

Doesn’t present and overlay view from the system. User doesn’t have to leave the app. We have the ultimate freedom to display translations.

• It’s up to developer to display the translation.
• It’s technically a Task. Which means it’s asynchronous. Has a delay, and can fail.

The API works with a couple of extra objects:

TranslationSession

• A class that performs translations between a pair of languages.
• It uses a configuration to define the source and target languages.
• We obtain an instance of this class inside the closure by adding the view modifier .translationTask(_:action:) to a SwiftUI view.
• It contains the methods we need to translate a source text.
• All translations using the TranslationSession class are processed on the user’s device. Apple may collect API usage and performance metrics including the app bundle ID and the original and translated language, but this data does not include the original or translated content.

TranslationSession.Configuration

• Specifies the source and target languages to use in a translation session. Default initialisation allows system to detect source and target language automatically.
• When you pass this configuration into the .translationTask(_:action:) function, the framework uses the configuration you initialised for the translation.

Locale.Language

• A type that represents a language, as used in a locale.

Single String

• Pass the text and receive a response that contains translated text.

Here, we have a contact form to reach out to a seller. The user wrote their message in English. We give them a kind reminder saying that the seller of the property is from Italy. Sending the message in Italian may help them in their effort to get the best deal. They see the translation in a sheet, if they use it, the app replaces the message with the translated one.

struct ContactSellerView: View {
    ...
    @State private var message: String =
    """
    Hello, 
    I'm interested in your property. I like what you did with the interior design. I love the neighborhood and the location. But I'm looking for an at least 10% discount on the deal. Is it acceptable to you? Please let me know. 
    Thanks!
    """
    ...

    @State private var configuration: TranslationSession.Configuration?
    @State private var translatedMessage: String = ""
    @State private var isTranslationSheetPresent: Bool = false

    var body: some View {
        ...

        Button {
            triggerTranslation()
        } label: {
            HStack {
                Text("See how it looks in 🇮🇹")
            }
        }
        // Once the configuration property detects a change, 
        // it triggers a new session. 
        .translationTask(configuration) { session in
            do {
                // Use the session the task provides to translate the text.
                let response = try await session.translate(message)
                // Update the view with the translated result.
                translatedMessage = response.targetText
                isTranslationSheetPresent = true
            } catch {
                // Handle any errors.
            }
        }
        ...
    }

    private func triggerTranslation() {
        guard configuration == nil else {
            // Call .invalidate() method to trigger the translation again 
            // with the same configuration instance
            configuration?.invalidate()
            return
        }

        // Create a new configuration for the translation session.
        // This configuration will target Italian as the target language.
        configuration = .init(target: .init(identifier: "it"))
    }
}

Batch of Strings

• Send an array of String in order, receive an array of translated String in the same order.

Here's a survey for a property detail page. The real estate agency is curious about how satisfied was the interested party about the details. The survey statements were provided by the agent, so they are in Dutch. We provide them a way to translate all those statements. Once the user taps on the translate button, all statements turn into the language of users location, in this case German.

import SwiftUI
import Translation

struct SurveyPageView: View {
    // Statement about the satisfaction on the property detail page in Dutch
    @State var statements = [
        "De details van het eigendom waren duidelijk.",
        "De foto’s van het eigendom waren van goede kwaliteit.",
        ...
    ]

    @State private var configuration: TranslationSession.Configuration?

    var body: some View {
            ...

            Button {
                triggerTranslation()
            } label: {
                Image(systemName: "translate")
            }

            ...

            .translationTask(configuration) { session in
                await translateAllAtOnce(using: session)
            }

            ...
        }
    }

    ...

    private func triggerTranslation() {
        guard configuration == nil else {
            configuration?.invalidate()
            return
        }

        // Default initializer allows device to detect the source language 
        // and the target language.
        // Target language is based on user's region by default.
        configuration = .init()
    }

    private func translateAllAtOnce(using session: TranslationSession) async {
        // Translate all statements at once
        Task { @MainActor in
            let requests: [TranslationSession.Request] = statements.map {
                // Map each item into a request.
                TranslationSession.Request(sourceText: $0)
            }

            do {
                let responses = try await session.translations(from: requests)
                withAnimation {
                    statements = responses.map {
                        // Update each item with the translated result.
                        $0.targetText
                    }

                    ...
                }
            } catch {
                // Handle any errors.
            }
        }
    }
}

Batch as a sequence

• An array of “translation requests” can be send sequentially. Then the result can be processed as they are being received.
• Order of receiving is not guaranteed. But can be tracked with index using clientIdentifier property.
• Can be useful for translating a set of very large texts.

Here we have an agents page and reviews given by customers. They're in French. When the blue button is tapped, we translate every review one by one to the primary language, which is German. When it's tapped again they're translated into English. which is the second preferred language of user's device.

struct RealEstateAgentProfileView: View {
    ...
    // Customer reviews with dates and reviewer names
    @State var reviews: [Review] = .reviews

    ...

    @State private var configuration: TranslationSession.Configuration?

    var body: some View {
        ...
        Button {
            triggerTranslation()
        } label: {
            Image(systemName: "translate")
        }
        ...
        .translationTask(configuration) { session in
            await translateSequence(session)
        }
        ...
    }

    private func triggerTranslation() {
        guard configuration == nil else {
            configuration?.invalidate()
            return
        }

        // In default, source language will be detected as French
        // since the review texts are in French.
        // Target language is user's region, in this case German.
        // When same configuration is used, then the source language is German,
        // and the target language will the user's prefered language, 
        // in this case English.
        configuration = .init()
    }

    private func translateSequence(_ session: TranslationSession) async {
        Task { @MainActor in
            // Create an array of requests. Use the index of the review array 
            // as the client identifier.
            let requests: [TranslationSession.Request] =  reviews.enumerated().map { (index, review) in
                .init(sourceText: review.text, clientIdentifier: "\(index)")
            }

            do {
                // Translate the batch of requests.
                // For each response received, update the corresponding review in the array.
                for try await response in session.translate(batch: requests) {
                    guard let index = Int(response.clientIdentifier ?? "") else { continue }
                    withAnimation {
                        // The client identifier is used to match the response to the original reviews
                        reviews[index].text = response.targetText
                    }
                }
            } catch {
                // Handle error
            }
        }
    }
}

Availability

Available languages

You can see the availability of languages the API offers. LanguageAvailability().status(_ from: _to:) checks to see if a specific language pairing is installed and ready for translation.

• .installed supports, has been downloaded and made ready for use in a translation.
• .supported supports but can’t yet use. Only after it downloads and installs.
• .unsupported doesn’t support.

@Observable
class LanguageAvailabilityViewModel {
    var isTranslationSupported: Bool?
    ...

    func checkLanguageSupport(from source: Locale.Language, to target: Locale.Language) async {
        let availability = LanguageAvailability()
        let status = await availability.status(from: source, to: target)

        switch status {
        case .installed, .supported:
            isTranslationSupported = true
        case .unsupported:
            isTranslationSupported = false
        @unknown default:
            print("Not supported")
        }
    }
}

Prepare languages

• Displays a sheet asking the user’s permission to start downloading the language pairing. So that the above translation features can be ready from the get going.
• Useful to prepare the device for translations.
• If user is faced with any of above features before their device has the necessary language packs, the device will automatically ask to download languages.

struct PrepareTranslationView: View {
    @State private var configuration = TranslationSession.Configuration(
        source: Locale.Language(identifier: "pt_BR"),
        target: Locale.Language(identifier: "ko_KR")
    )

    @State private var buttonTapped = false

    var body: some View {
        ...
        Button(
            action: {
                configuration.invalidate()
                buttonTapped = true
            }
        ) {
            Text("Download language packs")
        ...
        }
        ...
        .translationTask(configuration) { session in
            if buttonTapped {
                do {
                    // This will present the sheet to 
                    // download the required language packs.
                    try await session.prepareTranslation()
                } catch {
                    // Handle any errors.
                }
            }
        }
        ..
    }
    ...
}

In default configuration, …

• If the language of the source text is detected to be the user's region, then the target defaults to device’s preferred language.
• If the source is not the same with the region, the target defaults to the region’s language.
• If the source and target language pairing isn’t available on the device, user will be prompted with an overlay asking to download it.
• If the translation intend is unclear from the APIs perspective, user will be prompted with an overlay asking to pick a source language from the list.

It was unexpected when I saw, that …

• When the Translate app isn't installed on the device, features do not work as expected. For instance, when you try to use Custom UI features, the API throws error. But System UI features work just fine. So, Translate app is better be installed on user's device, or you may face with unexpected behaviours.
• There is no way to check beforehand, whether the user has the Translation app on their device or not.
• In default, if the target isn't specified in the configuration, target language is set to the device's region. I would expect it to be the devices preferred language, which wasn't the case.

User's Permission …

Is required by Apple’s Translate app (not the app utilising the Translation API) for the first time:

• to read user input for translations, and
• to download source and target language when translation is being used.

Advantages

• Translates any text in the app.
• Very easy to use and implement.
• Translation are done on device. So, it's more secure and apart from downloading language pairings does not require constant internet connection.
• You can expand and limit available languages in your app.
• A large set of language availability.
• Emojis do not distract translations.
• Apple’s own API. Support in future is pretty much guaranteed.
• Already downloaded languages can be present in the device and can be utilised by the API.
• The API is smart enough to determine source and target languages, if a specific configuration isn’t passed as an argument.

Disadvantages

• Can redirect user out of your apps.
• Translations are provided by Apple. No any other translation API can be injected.
• The algorithm of the translation is a black box. You will have no control over the translated text. They can get wrong.
• Only available after iOS 18. No backward availability.
• Internet connection is required for the first usage. Language pairings have to be downloaded.
• Custom UI features do not work without the Translate app.

Conclusion

Easy to implement. Definitely an easy win for any text in your apps that get translated frequently by users. This can be a great addition to any app.

I hope that this article will be useful to you.

Have a great one, cheers! ✌️

References:

• Meet the Translation API — WWDC24 — Videos — Apple Developer
• Translating text within your app | Apple Developer Documentation

iOS 18 — Apple's Translation API was originally published in AVIV Product & Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

As AI technology continues to evolve, the way we interact with machines is undergoing significant changes. At latest OpenAI’s DevDay, the company behind the well-known ChatGPT and GPT models announced a public beta of their new Realtime API, alongside several other updates.

This release introduces a new approach to voice-powered experiences by enabling low-latency, speech-to-speech interactions. A key advantage comes from combining this with the existing Function Calling feature, which enhances real-time, responsive user experiences.

In this blog post, we’ll discuss how this combination improves both developer capabilities and user interactions, offering new opportunities for voice-first applications.

The Power of Realtime Speech-to-Speech: What’s New?

Previously, developers had to use multiple models to achieve speech-to-speech functionality: transcribing audio with tools like Whisper, sending the transcription to a GPT model, and then using text-to-speech tools for playback. This process often introduced delays and impacted the fluidity of conversations.

The new Realtime API addresses this issue by streaming audio inputs and outputs with near-human response times. This allows for more natural conversations, where users can engage without noticeable interruptions. Built on the GPT-4o model, the API supports real-time conversations while maintaining the expressive qualities of speech.

Enter Function Calling: Structured, Dynamic Intelligence

Now, consider combining the real-time capabilities of the Realtime API with OpenAI’s Function Calling feature. This feature allows developers to define APIs or functions that GPT can trigger based on the context of a conversation. Tasks like booking appointments, retrieving data, or interacting with external services can be completed seamlessly in real time.

This combination transforms voice assistants from simple conversational bots into more capable virtual agents, offering hands-free, task-driven experiences.

How Function Calling and Realtime API Improve User Experience

By integrating both the Realtime API and function calling, developers can create voice-first applications that engage users more effectively. Here are some key benefits:

• Conversational and Task-Oriented: Users can perform tasks like booking appointments or checking schedules within the same conversation, without switching between different interactions.
• Hands-Free Convenience: Tasks like controlling smart devices or checking information can be completed without interrupting the conversation flow.
• Real-Time Personalization: Function calling can trigger APIs to fetch user-specific data, providing real-time, personalized responses.
• Latency-Free Integration: The Realtime API minimizes delays, enhancing interactions in time-sensitive situations, such as customer support or telemedicine.
• Natural Conversations: The API allows for more human-like conversations by managing interruptions and maintaining a natural flow, improving the overall user experience.

My Experiment: Setting Up a Speech-to-Speech Assistant

To test the combination of OpenAI’s Realtime API and Function Calling, I used the OpenAI Realtime Console as a foundation by forking it for the proof of concept.

Idea was to build something that lools like this:

Setting the Stage: Getting Started with the OpenAI Realtime Console

The OpenAI Realtime Console is a powerful interface for experimenting with the Realtime API. It allows developers to interact with speech input, trigger custom functions, and manage API sessions effortlessly.

Setting up the Console
The console is built as a React project. Simply clone the github repository and install dependencies using npm install.

Additionaly you may want to use the provided relay server, mostly if you want to :

• Hide API credentials if you would like to ship an app to play with online
• Handle certain calls you would like to keep secret (e.g. instructions) on the server directly
• Restrict what types of events the client can receive and send

In that case, you’ll need to add an .env file with you OpenAI api key and path to your relay server url at the root of the project.

Adding your custom “function calling” tool

This process is simple. In the ConsolePage.tsx file under src/pages, look for the client.addTool method. Remove the existing set_memory and get_weather functions, and add your own by providing a JSON OpenAPI definition for your custom function and available parameters as the first argument, followed by your function code as the second argument.

This is for instance one of the example tool provided with the codebase.

client.addTool(
      {
        name: 'get_weather',
        description:
          'Retrieves the weather for a given lat, lng coordinate pair. Specify a label for the location.',
        parameters: {
          type: 'object',
          properties: {
            lat: {
              type: 'number',
              description: 'Latitude',
            },
            lng: {
              type: 'number',
              description: 'Longitude',
            },
            location: {
              type: 'string',
              description: 'Name of the location',
            },
          },
          required: ['lat', 'lng', 'location'],
        },
      },
      async ({ lat, lng, location }: { [key: string]: any }) => {
        setMarker({ lat, lng, location });
        setCoords({ lat, lng, location });
        const result = await fetch(
          `https://api.open-meteo.com/v1/forecast?latitude=${lat}&longitude=${lng}&current=temperature_2m,wind_speed_10m`
        );
        const json = await result.json();
        const temperature = {
          value: json.current.temperature_2m as number,
          units: json.current_units.temperature_2m as string,
        };
        const wind_speed = {
          value: json.current.wind_speed_10m as number,
          units: json.current_units.wind_speed_10m as string,
        };
        setMarker({ lat, lng, location, temperature, wind_speed });
        return json;
      }
    );

Make sure your function returns a JSON object so the assistant can provide accurate answers based on the user’s request.

Providing the assistant with instructions

In the conversation_config.jsfile, you can customize the system settings for your chatbot, including details about its personality and behavior.

export const instructions = `System settings:
Tool use: enabled.

Instructions:
- You are an artificial intelligence agent responsible for helping test realtime voice capabilities
- Please make sure to respond with a helpful voice via audio
- Be kind, helpful, and curteous
- It is okay to ask the user questions
- Use tools and functions you have available liberally, it is part of the training apparatus
- Be open to exploration and conversation
- Remember: this is just for fun and testing!

Personality:
- Be upbeat and genuine
- Try speaking quickly as if excited
`;

Running the app

If you decided to use the relay server, start by running it using the following npm run relay command and then run the app with npm start . And that’s it!

The caveats

While the tool is easy to set up, keep in mind that the API is still in beta, and the console has a few bugs. For example, at the time of writing, if you use the relay server, you’ll need to apply a patch (as outlined in a GitHub issue) to ensure function calls work correctly.

Another consideration is the current cost of audio input and output. Currently, audio input is estimated at 6¢ per minute, and output at 24¢ per minute. And this really quickly adds up, so make sure you define limits accordingly. Hopefully, these costs will decrease over time, similar to other OpenAI APIs.

Conclusion: Elevating the Future of Voice Applications

OpenAI’s Realtime API and Function Calling provide new tools for designing voice-first applications. With these features, developers can create more interactive, task-oriented agents that facilitate seamless, natural conversations. As more developers adopt these tools, we can expect further advancements in voice-powered applications that offer more intuitive and personalized experiences.

Enhancing User Experience with OpenAI’s Realtime API and Function Calling: A Seamless… was originally published in AVIV Product & Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Before we dive into the intricacies of reusable reducers, it’s important to note that this article is tailored for readers who already have a good understanding of the Composable Architecture (TCA). If you’re new to this framework/architecture, you may find it beneficial to familiarise yourself with it before proceeding.

When do we use the Higher-Order Reducers?

When we want to extract a common logic across actions, we create a private function and use that method. But, what about common logic across features?

My first intuition would be to create a dependency that has a name like “SomethingManager”, or “SomethingDoer” whose method takes the necessary arguments, then achives the desired objective, possibly returns a type. And that seems perfectly fine. But, I don't ever see myself overriding this dependency in testing, preview or any other environment, so a dependency feels like an overkill here. So, is there any other alternative?

By taking the inspiration from BindingReducer in TCA framework, I want to show you how you can create a Higher-Order Reducer that is sharable across any domain. This will take our reducer's capabilities one step further.

A real world case

An actual requirement urged us to find a solution with a custom Higher-Order Reducer. One of our form pages in our app has many fields where we need to validate each field with each keystroke and also with the submit action. We find the most optimal solution by intercepting the binding actions and a submit action that parent reducer uses, then finally do the validation and return error messages if needed. Now we are able to use this validation reducer in any other form that needs it!

What's the objective?

We are going to:

• Create a reducer that can intercept certain actions, and mutate the parent's state,
• make it so that the reducer is reusable in any other feature,
• move any logic from the parent reducer into the Higher-Order Reducer that was otherwise bound to the feature.

In this article, we are also going to utilise KeyPaths from Swift and CaseKeyPaths from TCA.

In the end, the body inside our feature's reducer will look like this:

@Reducer
struct FeatureReducer {
  ...

    var body: some ReducerOf<Self> {
      ...
  
      HigherOrderReducer(
        input: \.someProperty,
        output: \.someOtherProperty,
        triggerAction: \.someAction
      )
      
      ...
    }
  
  ...
}

If that's something you're interested, let's refresh our memory by covering some bases first.

KeyPaths

KeyPaths offer a flexible and type-safe mechanism for working with properties, whether accessing them directly, using them as parameters in functions.

To put it in simpler words, you define KeyPaths by saying “Here’s a key where I expect a property, from a certain type, that returns a certain type”. You can write onto or read from these properties.

\Root.someProperty, \.id , \.self , etc.

KeyPaths are already being used extensively by Swift and SwiftUI. You may remember them from ForEach view where you provide a KeyPath for id argument.

ForEach(
  _ data: Data, 
  id: KeyPath<Data.Element, ID>, 
  content: @escaping (Data.Element) -> Content
)

Plus, this concept is gaining more popularity. It’s definitely worth mastering in order to advance in Swift language.

More information on that can be found below links:

• KeyPath by Apple
• The power of KeyPaths in Swift by Sundell

CaseKeyPaths

Unfortunately, a structure like KeyPath did not exist for enum cases where we want pass actions which are exclusively enums. Not until, a new concept is introduced by TCA developers to address the missing part. It's called CaseKeyPath from CasePaths library by PointFree. It allows us to pass enum cases just like KeyPaths. It looks like this:

\.view.didTapButton

Delicious!

More information on CaseKeyPaths can be found below:

• SwiftCasePaths by PointFree

Fun fact

Here's what a CasePath looked like before the introduction of CaseKeyPath.

/Action.view.didTapButton

In order to pass a CasePath like the above the initialiser had to look like this:

init(toViewAction: @escaping (Action) -> ViewAction?) {
  self.toViewAction = toViewAction
}

It was essentially a closure where it takes parent action as argument and expects to return another action. As of today, this is how the framework still works behind the counter. But it seems this usage is bound to be deprecated.

Higher-Order Reducer

In Swift, “higher order” typically refers to functions or closures that either accept other functions/closures as parameters, or return functions/closures as output. These higher-order functions allow for more flexibility and composability in code, as they can manipulate or encapsulate behaviour.

In earlier days (mid-2019), that was exactly what it looked like in TCA as well. It meant a reducer function that returns a reducer function.

func higherOrderReducer(
  _ reducer: @escaping (inout AppState, AppAction) -> Void
) -> (inout AppState, AppAction) -> Void {

  return { state, action in
    // do some computations with state and action
    reducer(&state, action)
    // inspect what happened to state?
  }
}

Over years of transformation, in TCA context, it refers to reducers that are shareable, reusable, can handle an objective, and can be built on top of our apps. One of the most important example is the BindingReducer().

How would Higher-Order Reducers help us?

Managing complexity

In large applications, managing state and actions can get really complex. They help address this problem by allowing you to break down the state management logic into smaller, more manageable units. This makes it easier to understand, maintain, and modify the codebase as your application grows.

Reusability

They enable you to encapsulate common patterns or behaviours within reusable bodies. This promotes code reuse across different parts of your application, reducing duplication and ensuring consistency in how state is managed.

Testing

You can write unit tests for individual reducers. By this way we can ensure that each piece of state management logic behaves as expected in isolation.

Tutorial

Project Setup

Create a new project using Xcode. Minimum requirements for this project is as below:

• Xcode 15.3
• Swift 5.9
• Minimum deployment target: iOS 17.0
• TCA: 1.10.0

Once packages are resolved. Give it a run. You may be asked to enable macros by Xcode. Go ahead and enable them. Then we're good to go.

User story

I have come up with a user story for us to start exercising. It’s just a fictional one to keep things as simple as possible for us to step into the concept.

I want to be able to enter a text into a field. When I tap onto the button, I want to see that same text in uppercased form below. I want to be able to long press and copy the uppercased text. This logic has to be reusable. We’ll call this feature Shouting text.

The logic is to take a string as input and return an uppercased string as output after a certain trigger action.

Shouting text

First, create a reducer for our feature. Name it ShoutingText.swift . Copy and paste below code to this file.

import ComposableArchitecture

@Reducer
struct ShoutingText {
    @ObservableState
    struct State {
        var text: String = ""
        var uppercasedText: String = ""
    }
    
    enum Action: BindableAction {
        case didTapShoutButton
        case binding(BindingAction<State>)
    }
    
    var body: some ReducerOf<Self> {
        BindingReducer()

        Reduce { state, action in
            switch action {
            case .didTapShoutButton:
                // Here's the state mutating logic that
                // we want to move to the new reducer.
                state.uppercasedText = state.text.uppercased()
                return .none
            case .binding:
                return .none
            }
        }
    }
}

Second, create a new file called ShoutingTextView.swift then copy and paste below code inside.

import ComposableArchitecture
import SwiftUI

struct ShoutingTextView: View {
    @Bindable var store: StoreOf<ShoutingText>
    
    var body: some View {
        Form {
            Section {
                TextField(
                    "what do you mean",
                    text: $store.text
                )
                .textFieldStyle(.plain)

                Button {
                    store.send(.didTapShoutButton)
                } label: {
                    Image(systemName: "person.wave.2.fill")
                }
            }

            Text(store.uppercasedText)
                .textSelection(.enabled)
        }
        .navigationTitle("Shout it!")
    }
}

#Preview {
    NavigationStack {
        ShoutingTextView(
            store: Store(
                initialState: ShoutingText.State(),
                reducer: ShoutingText.init
            )
        )
    }
}

When you run the preview you should see a screen like below.

Try and type something to the text field and tap onto the button below. See the text being uppercased.

If everything is in order, it means our base code is ready.

Creating a Higher-Order Reducer

These are not so different from typical feature reducers. They just don't have to possess a State struct and an Action enum.

Create a new file called UppercasedReducer.swift, then copy and paste below code inside.

import ComposableArchitecture

// 1
@Reducer
struct UppercasedReducer<State, Action, UppercaseAction> where Action: CasePathable {
    // 2
    private let keyPathToText: KeyPath<State, String>
    private let keyPathToUppercasedText: WritableKeyPath<State, String>
    private let caseKeyPathToAction: CaseKeyPath<Action, UppercaseAction>

    init(
        input keyPathToText: KeyPath<State, String>,
        output keyPathToUppercasedText: WritableKeyPath<State, String>,
        triggerAction caseKeyPathToAction: CaseKeyPath<Action, UppercaseAction>
    ) {
        self.keyPathToText = keyPathToText
        self.keyPathToUppercasedText = keyPathToUppercasedText
        self.caseKeyPathToAction = caseKeyPathToAction
    }

    // 3
    func reduce(into state: inout State, action: Action) -> Effect<Action> {
        if action[case: caseKeyPathToAction] != nil {
            state[keyPath: keyPathToUppercasedText] = state[keyPath: keyPathToText].uppercased()
        }
        return .none
    }
}

Let's see what's happening here:

1. UppercasedReducer is the Reducer that will do the job. Thanks to @Reducer macro, we're free from filling in some boilerplate code, such as conformances.
   Plus, it's generic. Which mean its properties will be inferred by the types of properties from whichever Reducer uses it when initialised.
   State is the parent state. Action is the parent action. UppercaseAction is the sub action of the parent action we want to intercept and mutate the state with.
   In order to take advantage of CaseKeyPaths, the Action generic parameter has to conform to CasePathable protocol.
2. keyPathToText is a KeyPath to the text we want to turn into uppercase. It's read only. The root is the parent state and the value is a String.
   keyPathToUppercasedText is a WritableKeyPath to the final text we want to display on the screen. It's needs to be writable because we have to replace what's there after mutation. The root is the parent state and the value is a String.
   caseKeyPathToAcion is a CaseKeyPath to the action we want to intercept and make the state mutation. The root is the parent action and the value is an enum case of that action.
3. Here's the reduce function that will do the mutation. We employ an if statement to determine if the action that is subscripted with the caseKeyPathToAction is not nil. This serves as our interception mechanism for actions.
   If the condition holds true, we proceed to replace the property referenced by keyPathToUppercasedText in the parent state with the property referenced by keyPathToText within the same parent, right after applying the .uppercased() method. Subsequently, we conclude the operation by returning the .none effect.

Usage of the Higher-Order Reducer

Return to ShoutingText.swift file and initialise the our new UppercasedReducer inside the body. Since we have no particular side effect to run, go ahead and remove the other Reduce initialiser.

import ComposableArchitecture

@Reducer
struct ShoutingText {
    ...
    
    var body: some ReducerOf<Self> {
        BindingReducer()

        UppercasedReducer(
            input: \.text,
            output: \.uppercasedText,
            triggerAction: \.didTapShoutButton
        )
    }
}

Thanks to @Reducer macro right above ShoutingText reducer, we don't have to explicitly conform the Action enum of the feature to CasePathable protocol. It's already covered! You can expand the macro to see conformances above there.

And that’s it. Run the app and see the reducer is doing its job!

The end product hasn't changed a bit, but the underlying difference is huge. Now we have a reducer that is easily sharable. We won't have to repeat this logic anywhere in our code base. Lovely.

Congratulations on completing the above journey through the exercise using KeyPaths and CaseKeyPaths in the Composable Architecture!

By following along with this article, you’ve taken a solid step towards developing reusable reducers in your app.

On top of my mind, here are some examples where Higher-Order Reducer can be useful:

• Logging
• Tracking events
• State property validations, filters, etc.

Let me know if you can think of any other use case!

Keep exploring, experimenting, and pushing the boundaries of what’s possible with the Composable Architecture.

Cheers!

Higher-Order Reducers with KeyPath and CaseKeyPath in the Composable Architecture was originally published in AVIV Product & Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

At AVIV, we consistently seek ways to enhance our developers’ experience working on our apps (SeLoger, Immoweb, Immowelt, and Immonet). Compilation time is no exception. Our latest efforts were concentrated on optimizing the compilation time for the white-label features/packages that our apps currently use.

Before attempting to improve compile time, we initiated the process by assessing areas for potential improvement. We employed various methods to accomplish this.

Xcode Build Timeline

We first used Xcode Build Timeline to identify potential bottlenecks that were taking too long to compile. Cleaning our build folder in between builds is crucial so that you can compare them with the performance optimizations you have implemented.

Assets

We identified that on a fresh build, our asset catalog was taking 19 seconds to build and was blocking compilation.

We have a large number of icons imported from Figma, and currently, not all of them are used as not all white-label features have been developed yet.

This issue is still in progress, and we are considering the following alternatives:

• Should we only import assets that are currently needed?
• Should we create a catalog per theme so that each module imports only the necessary assets?

It’s worth noting that this issue only affects fresh builds, so is it a genuine concern? Maybe not.

SwiftLint

In our effort to make our build times faster, we discovered that SwiftLint was running twice for every dependency when building our project.

Firstly, we observed its presence in the build phases of our project, and then we identified it as a SwiftLint plugin in the manifest file (Package.swift) for each package:

for target in package.targets {
    target.plugins = target.plugins ?? []
    target.plugins!.append(.swiftLint)
}

This redundancy meant that SwiftLint was executed once by the target and once more for each dependency, doubling its impact on our build times.

This issue is still under consideration, and we are exploring two alternatives:

• Should we only run SwiftLint on commit?
• Should we remove SwiftLint from our dependencies?

Build Timing Summary

We used Build Timing Summary, but we did not identify any areas for improvement here.

Build time compiler flags

We used -Xfrontend -warn-long-function-bodies=200 and -Xfrontend -warn-long-expression-type-checking=200 to gather warnings from the compiler whenever a function or type check takes more than 200 ms.

To set this up, we updated the manifest file (Package.swift) for each package. We enabled our flags in the Swift build settings of each target within a package.

for target in package.targets {
    target.swiftSettings = target.swiftSettings ?? []
    target.swiftSettings!.append(
        .unsafeFlags([
            "-Xfrontend", "-warn-long-function-bodies=200",
            "-Xfrontend", "-warn-long-expression-type-checking=200"
        ])
    )
}

When we use the -Xfrontend flag with unsafeFlags in a Swift Package Manager configuration, we are providing additional flags that will be passed to the Swift compiler frontend during the build process. This is useful for making certain adjustments or optimizations specific to the compiler's behavior.

Compiling our packages enabled us to pinpoint significant areas for improvement. Our UI white-label features, which are powered by TCA, presented an opportunity to optimize our build time. First, it’s important to note that we follow the performance guidelines outlined by Point-Free.

Type inference with EmptyReducer

Having a view that displays multiple steps could result in the following reducer:

It took 19 seconds for the code to compile from a cleaned build folder. At some point, the build failed because the compiler was unable to type-check this expression in reasonable amount of time.

We updated the code to provide explicit types to the EmptyReducer, which includes some generics:

It took 100ms for the code to compile from a cleaned build folder.

Type inference with XCTestDynamicOverlay unimplemented method

Before TCA 1.5, adding a test value to a dependency could result in the use of the unimplemented method.

static let test: Self = .init(
    load: unimplemented(),
    loadProjectType: unimplemented(),
    store: unimplemented(),
    delete: unimplemented(),
    userType: unimplemented(),
    setNonOwner: unimplemented()
)

With this test value, it took 3 minutes for the code to compile from a cleaned build folder.

We updated the code to provide an explicit type for the test value:

static let test: Self = {
    let load: @Sendable () -> OwnerProject? = unimplemented(placeholder: nil)
    let loadProjectType: @Sendable () -> OwnerProject.ProjectType? = unimplemented(placeholder: nil)
    let store: @Sendable (OwnerProject) -> Void = unimplemented()
    let delete: @Sendable () -> Void = unimplemented()
    let userType: @Sendable () -> UserType = unimplemented()
    let setNonOwner: @Sendable () -> Void = unimplemented()

    return .init(
            load: load,
            loadProjectType: loadProjectType,
            store: store,
            delete: delete,
            userType: userType,
            setNonOwner: setNonOwner
    )
}()

With this test value, it took less than 10ms for the package to compile from a cleaned build folder.

Since TCA 1.5, the @DependencyClientmacro automatically provides a public initializer for all endpoints along with a default ‘unimplemented’ value for each endpoint.

static let test = OwnerProjectStore()

With this test value, compilation time also reduced to less than 10 ms from a cleaned build folder.

Conclusion

Our exploration revealed several areas where compile times could be improved.

Generics can sometimes contribute to longer compile times, especially when used extensively or in complex ways, as TCA uses them in its stores and reducers.

Updating TCA to the latest version and leveraging its new features improved our build compile time in certain areas without requiring additional code.

As we continue to refine our build process, we remain vigilant in our efforts to find the best approaches for compilation efficiency and deliver a smoother development experience.

We conducted our optimizations with valuable insights gained from following the guidance provided in this informative article.

Kudos to Adrien Simon, Omar Belhaouss, and Daniel Ahlborn, who also contributed to these enhancements.

How did we enhance our app’s compile time? was originally published in AVIV Product & Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

In today’s ever-changing software development landscape, code quality is a must-have requirement. At AVIV Group, we are committed to delivering exceptional applications to our customers by ensuring a shared responsibility for quality. To achieve agility, speed, and reliability: static code analysis is essential.

Integrating code analysis tools into your Continuous Integration and Continuous Delivery/Deployment (CI/CD) pipeline is an effective way to catch code issues early and ensure the health of your codebase.

In this blog, we will explore together how to seamlessly integrate SonarCloud, a popular cloud-based code analysis platform, with one of the leading CI/CD tools, CircleCI.

Sound interesting? Let’s get started!

What is Static Code Analysis?

Static code analysis is a technique that involves examining the source code of a software application without executing it. It aims to identify issues, potential problems, code smells, and violations of coding standards by analyzing the code’s structure, syntax, and dependencies.

Importance of Static Code Analysis

One of the most crucial aspects of static code analysis is the ability to catch issues early in development. This early detection reduces the cost and effort required for fixing issues later in the development cycle, which can be more challenging to address.

Static code analysis consistently enforces coding standards and best practices across the entire codebase. It checks for issues like code complexity, naming conventions, code duplication, and adherence to coding guidelines.

By maintaining a high level of code quality, development teams can produce more readable, maintainable, and reliable software.

By automating code analysis, development teams can focus on writing code and delivering features rather than manually reviewing every line of code. This automation streamlines the development process, increases productivity, and allows developers to spend more time on creative problem-solving.

After learning about static code analysis, let’s explore SonarCloud, the static analysis tool, and how it fits into the development lifecycle.

How SonarCloud fits into agile development

SonarCloud’s static code analysis capabilities enable Agile teams to detect code issues, bugs and smells early in development. This early detection helps teams address problems before they accumulate; reducing technical debt.

SonarCloud allows teams to set custom quality gates based on their specific project requirements. This flexibility ensures that code meets predefined quality criteria before it can be considered “done”.

SonarCloud supports a wide range of programming languages, including but not limited to Java, JavaScript, TypeScript, Python, and C#. SonarCloud also supports IaC, such as Terraform code, making it suitable for diverse software development environments.

SonarCloud seamlessly integrates with CI/CD pipelines, automatically analysing code changes as they are committed. This automation ensures that code quality checks are integral to every build, preventing the introduction of low-quality code.

As a cloud-based service, SonarCloud does not require teams to set up and maintain on-premises infrastructure for code analysis. This simplifies adoption and scalability.

Integrate SonarCloud with the CI/CD Pipeline

Let’s look at how to integrate SonarCloud with CircleCI, step-by-step seamlessly.

Prerequisites

Before we proceed, make sure you have the following prerequisites in place:

1. A GitHub repository with your codebase.
2. An account on SonarCloud (https://sonarcloud.io).
3. A CircleCI account (https://circleci.com).

Step 1. Log in to your SonarCloud account. Create a new project and follow the setup instructions to obtain a unique project key and token as shown in the following image.

Configure the project with the code changes settings e.g. the previous version of the codebase, as shown in the following image.

To ensure the effective use of SonarCloud, 5 essential things should be configured:

1. Organization: each SonarCloud organization represents a corresponding organization on the repository platform side.
2. Projects: each imported repository becomes a SonarCloud project.
3. Rules: rules are executed on source code to generate issues. There are four types of rules: Code smell, Bug, Vulnerability, and Security hotspot.

4. Quality Profiles: SonarCloud provides a default quality profile called the Sonar Way profile for each language, activating rules that should apply to most projects. This profile is marked with the “built-in” tag in the interface. If no other profile is explicitly defined at the project level, the default profile for the language will be used.

New profiles can be created in two ways:

• Copying an existing profile and adjusting the copy.
• Extending an existing profile.

5. Quality Gates: These are defined at the organization level and applied at the project level. Each project has one quality gate assigned from among those defined in the organization.

After configuring the project, you will be redirected to the project page, including the analysis results, as shown in the following image.

After running the first scan, you can find the Quality Gate status, but it will display the results after the following scan, as shown in the following image.

You can see the result if you create a new PR (Pull Request), as shown in the following image.

Then, the status will be updated with details such as Reliability, Maintainability, and other statistics, as shown in the following image.

You can also find the recent analysis activity on the project, as shown in the following image.

The SonarCloud bot will also be enabled in the PR view to get the results on every code change, as shown in the following image.

You can also click on the details to redirect to the page, as shown in the following image.

There is another way to enable SonarCloud with your GitHub project by enabling SonarCloud GitHub App, as shown in the following image.

Select your GitHub organization or account, as shown in the following image.

Select the repositories you want to scan, as shown in the following image.

Save the changes to enable SonarCloud on the project.

Now, let’s configure CircleCI to run SonarCloud as a part of the CI/CD pipeline.

Disabling automatic analysis on the project is recommended because it will be run via the CircleCI from the Project Administration; select Analysis Method, as shown in the following image.

And disable the Automatic Analysis, as shown in the following image.

Set up CircleCI environment variables for your SonarCloud token and any other sensitive information you may have; you can find the steps in your SonarCloud project, as shown in the following image.

Create a CircleCI context, and name it SonarCloud, as shown in the following image.

Add an Environment Variable, and name it SONAR_TOKEN as shown in the following image.

Create a configuration file in the project's root directory and name it sonar-project.properties, which will include the sonar.projectKey and sonar.organization, as shown in the following image.

In your project’s .circleci/config.yml file, you’ll need to add the necessary steps to integrate SonarCloud.

Here’s an example configuration:

version: 2.1
jobs:
  build:
    docker:
      - image: circleci/node:14
    steps:
      - checkout
      - run:
          name: Install dependencies and build project
          command: npm install
      - sonarcloud/scan
orbs:
  sonarcloud: sonarsource/sonarcloud@1.0.3
workflows:
  main:
    jobs:
      - build:
          context: SonarCloud

Commit and push the updated .circleci/config.yml file to your GitHub repository, triggering your CircleCI pipeline automatically, as shown in the following image.

After completing the CI/CD pipeline, visit your SonarCloud project dashboard to view code analysis results, including code quality metrics, security vulnerabilities, and code smells, as shown in the following image.

Congratulations, you configured your first project to run static analysis with the CircleCI CI/CD pipeline.

Extra point: Using SonarLint for real-time code analysis within the IDEs

SonarLint is a lightweight code analysis tool that provides real-time code analysis directly within integrated development environments (IDEs).

SonarLint is integrated into popular IDEs such as Visual Studio Code, Visual Studio, IntelliJ IDEA, and more. Developers can install and configure the SonarLint plugin specific to their IDE.

Once installed, SonarLint performs real-time code analysis as developers write or modify code. It highlights code issues, bugs, code smells, and security vulnerabilities directly within the IDE, offering instant feedback, as shown in the following image.

Conclusion

Static code analysis plays a vital role in achieving these objectives. By automating the analysis of code for issues, enforcing coding standards, and detecting security vulnerabilities, static code analysis tools enable development teams to produce higher-quality, more secure, and maintainable software.

Integrating SonarCloud with your CircleCI CI/CD pipeline is a powerful way to automate code analysis and ensure consistent code quality and security in your software projects.

Resources

• Online Code Review as a Service Tool, SonarQube Cloud (Formerly SonarCloud)
• CircleCI Developer Hub - sonarsource/sonarcloud

Thank you for reading!

If you’re interested in joining our Aviv family, you can always find exciting opportunities here: https://careers.smartrecruiters.com/avivgroup

Good luck and happy testing!

Elevating Code Quality: The Power of Static Code Analysis in Modern Software Development was originally published in AVIV Product & Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Even though it may seem like a long event, the truth is that time there will fly by!

First, let me explain the genesis of our travel:

Last year, AVIV, (the company I work for as a frontend software developer) brought together a small team of colleagues to participate in re:Invent. Fun fact : AVIV is a younger company that gathered leading European brands in the real estate space. Now, we form a new big family, and that’s a bit what our team looked like at the start of our travels! Yann, backend engineer from Seloger, Jean-Christophe, product manager from Immoweb, Dennis, devops, Cemal, head of devops & Micha, software architect from Immowelt, Laura, data engineering manager, David, head of geo data engineering and myself, from Meilleurs Agents, as all new AVIVers going to rock Las Vegas together.

Most of us didn’t know each other when we started, and none of us had ever participated in re:Invent. We didn’t speak the same language, we didn’t come from the same companies and we didn’t do the same job. So we faced some challenges right from the start… Yet, magic happened! Not only did we all have an incredible experience, attended plenty of talks, but we came back together as #oneteam friends.

Long story short:

We might have found a little recipe that works, and it seemed like a good idea to share it (because a year ago, we looked on the internet for good advice to organize our trip, just like you).

Our four main topics :

1. Travel & accommodation

2. AWS, the event

3. Fun & Tourism

4. People

1. Travel & accommodations :

We will start with the most urgen…

Take a day off before it starts to check out the place

If possible, join the venue two days before the start of re:Invent, this allows you to check in at the hotel with peace of mind, and to have a full day to get your bearings and prepare for the week, including :

Keep some time off to visit the city

There are a few must-sees in Las Vegas, and don’t count too much on the downtime between talks to do them, nor in your evenings which will also be busy. A first day there allows you to visit, and spot from afar, the hotels hosting the conferences, which you will have plenty of time to see afterwards. So say hello to them from afar, and save your time for the rest of the city.

Pick up your badge the day before it starts

It worth it for two reasons :

A/ There are fewer people the day before, so you’ll waste less time waiting in line.

B/ You’ll save yourself a significant amount of stress for the first day of the event.

Plan some extra room in your luggage

This one was a really good tip that I was given: you will receive an unimaginable quantity of goodies (despite yourself). So to avoid having to wear 1 week of clothes on you on the return plane, plan some space for goodies right away.

Take some painkillers

Carry everything that can save your life, or at least your day! (anti-migraine, throat lozenges, eye drops) As if you were going into the desert. Oh well, actually…

Pick your hotel to not be too far away from attending places

You will spend a considerable amount of time commuting from point A to point B. Whether walking, taxi or shuttle, take this into consideration, it feels good, especially at the end of the day, to be able to return easily into your cosy bed.

You’ll walk a lot, pick your shoes wisely and take a light backpack to carry your daily stuff

There’s really no point in taking out your fancy clothes even if we’re thinking of palaces and casinos. The idea is to survive a week of alternating time between walking in a crowd, or sitting still. And believe me, it is a sport! Comfortable and practical clothes, sneakers, t-shirts, a sweatshirt for when it’s cold, a backpack (but no need to bring a water bottle, you will find one quickly — for free).

2. AWS, the event

Schedule is key !

Start with picking the talks you want to attend and add them to your personal agenda (there are several instances of each. Try to gather talks in the same place as much as possible, distances become painfull across a few days). You’ll also attend labs, workshops - for those: take your laptop. But honestly, for other talks, just don’t take it, it will be useless (and heavy).

Download the mobile app

…And charge your phone to 100% everyday, you’ll need it all day long. Take your charger in the backpack or an external battery, you will find sockets everywhere. So then there’s no need to save your battery, you can take photos as much as you want :-).

Do not miss keynotes and be early to attend them

Honestly, these are pretty incredible moments to experience. First of all, if you arrive early you will be well seated, and you will enjoy the concert which precedes the talk. I advise you participate in as many keynotes as possible, even if you like a topic less. It is the speaker who makes the difference. My preference was the one of CTO Werner Vogels, I watched the replay twice from home after the event. This guy is really something !

About keynotes: if you’re not super comfortable with English, you can grab a translation headphone when entering the room.

Visit (several times) the Partners Village

It’s fun and interesting : you’ll meet 1:1 with people working from companies you’re probably using the services/tools of (or want to). It’s a perfect time to ask technical or commercial questions and have a valuable conversation. That’s also the place you’ll get all the goodies.

Food won’t be an issue, you’ll get more than you can dream of !

There will be food and drink everywhere and all the time. Don’t bother with takeaway food, and don’t waste time looking for somewhere to eat outside. The buffets are good and generous, it’s very well organized, no waiting time and you can take a lunchbox if you are in a hurry. AND the menu changes every day (vegetarian, kosher options, etc).

But if you really want to eat an American-style burger or pizza… the city is fast food heaven for your late evenings.

Are you lost? No, you’re not.

There are hundreds of volunteers who know the hotels by heart to show you the way, they are very recognizable, and installed at strategic points. Go see them, it gives them sincere pleasure to repeat for the 1000th time where BALLROOM C is, even if it is right behind you… There are maps, signs, screens, and even old-fashioned arrows everywhere too. We tried to get lost for fun, we NEVER got there.

3. Fun & Tourism

Our very special bullet-list of stuff you don’t want to miss :

• The Bellagio fountain runs a light show several times during the evening, it’s very pretty!
• The Golden Nugget, aka the oldest casino in the city, for a jazz evening and an old fashioned cocktail.
• Wedding chapel: what can sound more like Vegas than being married by Elvis? On the other hand, for your information, if you are going to get married for a laugh, don’t forget… you will indeed be married (legally, and officially, in several states of America).
• Fremont Street, in old Vegas, and its psychedelic LED ceiling.
• The famous Big Roller Coaster at the New York Hotel.
• The second floor of the Venetian Hotel, with its indoor reproduction of Venice and its canals (yes, there are gondolas on the water, and you can even ride them).
• Residencies shows of artists like Ru Paul or… Céline Dion. (it might be too late for the tickets there though).
• There’ll be corporate events organised, try to get invitations (that’s how we played golf on a rooftop at the MGM hotel).
• AWS organises a race - if you’re a runner, take your running shoes.
• You’ll be in Vegas, try just a little bit of gambling!

4.People

Pick your travel friends wisely ;-)

For this advice, we played it “do as I say, not as I do”, but guilty in charge, I have great colleagues (are you looking for work? We’re hiring!). No kidding, it’s all about planning, talking about organisation with your travel mates before your departure can help a lot.

Network!

You’ll have 1000 opportunities to meet people, go ahead, go say hi, sit with strangers at lunchtime, don’t be shy if you need some info/help. My biggest laugh was in the shuttle that took us back after the evening party, it felt like a school bus, with people singing and shouting jokes at the assembly, those moments are precious. The volunteers, employees, partners as well as the locals are very welcoming and friendly, don’t miss an opportunity to chat.

I think that with all of this, you are ready to succeed in your journey and experience an incredible re:Invent. We wish you make the most of it. As we mentioned previously, it goes by very quickly but it’s an experience you won’t forget!

And let’s share your personal best tips to the tech world when you’re back :-).

The ultimate guide to the AWS re:Invent was originally published in AVIV Product & Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

It has been proven many times: a design system is a powerful asset that facilitates the seamless scaling of product design and development.

But imagine taking it a step further, by integrating UX content guidelines and fixed UI content into its components.

With a well-rounded design system that incorporates content, the product team can realise efficiency gains, and designers can concentrate on their core challenges. Simultaneously, UX Writers can maintain design consistency without the burden of repetitive microcopy tasks.

In this article, I’ll share my personal journey, spanning a year and a half at AVIV Group. I’ll take you through the process of creating a Content Design System from scratch, all while operating as a solo UX Writer. I’ll also recount the experience of expanding our team to a skilled group of UX Writers, allowing us to scale our Content Design System, in close collaboration with the Design System team.

Let’s explore the impact of content within design systems, grounded in real-world experiences!

Unlocking the power of a Content Design System

Design will never exist without words, and words will never exist without design.

Think of them as a dynamic duo that makes our digital products tick. But with words scattered everywhere, it’s crucial to have some rules in place to use them consistently and efficiently. This is where a Content Design System comes into play.

So, what’s a Content Design System?

It’s like a helpful guide, not just for UX writers but for everyone involved in creating content — designers, writers, Product Managers, you name it. It gives us patterns for content, a style guide, and resources to ensure our content is accessible and inclusive.

Why is this important?

Well, it keeps things consistent, saves us time, and lets us focus on the more complex stuff.

As I mentioned earlier, it’s a smart move for UX writers to invest time in building these guidelines. It might take a bit of effort upfront, but it pays off big time down the road. It makes integrating simple text (like buttons) a breeze and keeps everything looking and sounding the same.

But creating a content design system isn’t a walk in the park. It takes time, experience, and a good amount of data about the content you’re dealing with. This ensures that the guidelines and examples you end up with, not only work well but also deliver a fantastic user experience.

Getting Started with integrating Content into a Design System

At AVIV, (a prop-tech company with a European presence in Real Estate) our focus largely revolves around white label products. This means we create one design in English and then adapt and localise it for various markets and brands. With this context in mind, our attention naturally turned toward developing guidelines for addressing users in the realm of white label products.

Starting from scratch, the task of building a Content Design System can seem quite daunting, especially as a solo UX Writer within a team of over 300 product professionals!

Prioritisation became key.

My approach was to begin somewhere tangible, and that’s where the content scorecard came into play. I stumbled upon this practical tool while reading ‘Strategic Writing for UX’ by Torrey Podmajersky. It provided a simple yet effective means of measuring content effectiveness and improving the user experience. It proved valuable for conducting content audits and assessing the quality of flows during UX Writing reviews with designers and product managers.

In fact, I even created a Content scorecard template for broader use!

With the content scorecard, I had established initial guidelines related to usability and tone of voice. It served as a clear and efficient resource for crafting UX content that was accessible, concise, and clear. It also delved into the nuts and bolts of writing, covering concepts, vocabulary, syntax, punctuation, and capitalisation.

After putting it to the test, I was ready to take the next leap — integrating content guidelines into our Design System. This required collaboration with the Design System team to find the best way forward. We decided to create dedicated content documentation space within Zeroheight as a central tool.

Our goal extended beyond documentation; we aimed to gain insights into how designers utilised the Design System and what content-related support they required. We reached a consensus to provide content guidelines for components that needed them the most, including buttons, dropdowns, and info states — elements commonly used by designers.

In the world of a truly integrated Design System, content becomes an integral part of the components themselves. The idea was to seamlessly link documentation, components, and prioritise tasks based on the specific needs of designers.

Defining Content Guidelines: a closer look

To ensure everyone grasped the essence of our Content Design System, I kicked off by introducing its core concepts, delving into UX Writing, and providing a clear roadmap for effectively utilising the system.

The journey began with a section dedicated to UX Writing principles. Here, I emphasised the fundamental aspects of being clear, concise, and conversational in our content. To make these principles crystal clear, I peppered the text with numerous concrete and illustrated examples of the content actually present in our products. These real-life ‘Do and Don’t’ examples helped drive home the importance of these principles.

In the pursuit of consistency, I crafted two crucial sections:

• Content Patterns: as my time at AVIV progressed, I began to collect questions from designers about content. Many of these revealed opportunities to establish content patterns — golden formulas for certain types of messages and concrete examples for maintaining consistency, particularly in areas like error messages, success notifications, numbers, push notifications, and feedback messages.
• UX Glossary: this section was particularly challenging. I linked our Content Design System to a Google Sheet that we update monthly to keep pace with our progress. This sheet houses a comprehensive list of words, localised in our four main languages and linked to our localisation tool. This dynamic approach ensures cross-team consistency and efficiency.

In addition to these core sections, I worked closely with our Accessibility expert to create a dedicated section on accessibility and inclusion. Here, I curated a wealth of resources to ensure readability, accessibility for screen readers, inclusivity (covering antiracist and gender-inclusive language), and other resources that contribute to a more inclusive and user-friendly experience.

Scaling up a Content Design System

With an initial version of our Content Design System in place, the natural question was how to continually enhance it. Simultaneously, I expanded our UX Writing team by bringing in two new members, and together, we embarked on a journey to scale up the Content Design System.

Here’s how we did it:

1. Building a backlog for continuous improvement: we initiated the process by creating a backlog of page ideas to further develop the Content Design System. To ensure steady progress, we set an ambitious goal of creating one new page or documentation per UX Writer each month, aiming to elevate our system to the next level.
2. Collaborative monthly reviews: each month, our team comes together to brainstorm and decide what to add to the backlog and what needs prioritisation based on the specific needs of our designers. This collaborative approach keeps us agile and aligned with evolving requirements.
3. Alignment with branding: we maintain close collaboration with the brand department to establish a unified voice for AVIV and its various brands. Ensuring alignment in voice and tone is critical for a seamless user experience.
4. Communication and awareness: we’ve put significant effort into ensuring that everyone within the organisation is not only aware of the Content Design System but also knows how to use it effectively. We utilise a dedicated Slack channel for UX Writing to keep everyone informed about updates. Additionally, we share updates in the Design System Slack channel. We also take advantage of opportunities like design and product all-hands meetings and reviews to showcase our work and solicit feedback. Lastly, the UX Writing team has been integrated of every design critiques, a great opportunity to give our insights and remind designers about the existance of the Content Design System!
5. Training sessions: to foster understanding and competence in UX Writing, we conduct training sessions for designers and product managers interested in enhancing their skills in this domain. These sessions serve as a valuable platform to introduce the Content Design System and the wealth of resources it offers.
6. UX Writing Checklist: to streamline the integration of UX Writing principles into the design process, I conceived a concise UX Writing checklist. This checklist serves as an accessible entry point to the Content Design System. Designers can conveniently use it as a component directly within Figma, facilitating seamless integration into their design workflows.

If you’re interested in having your own customisable UX Writing checklist, you can find it!

Next Steps and closing thoughts

As we look ahead, our primary focus is on scaling our Content Design System to greater heights. We aim to provide crystal-clear guidelines not only for white-label products but also for each distinct brand, integrating more UI content directly into components in multiple languages, and crafting templates to streamline localisation efforts.

Moreover, we’re eager to gauge the success of our Content Design System through key performance indicators. While we currently rely on qualitative feedback and insights, we’re keen to quantify the impact by assessing consistency across products and measuring the efficiency gains for our designers.

In the grander scheme of things, dedicating time to implement a Content Design System has proven to be a highly rewarding experience and a strategic investment for our UX Writers. It champions consistency, elevates the overall quality of the user experience, and provides an invaluable opportunity to step back from day-to-day tasks to document essential guidelines. It’s also a great asset when onboarding new UX Writers, enabling them to quickly adapt to the company’s unique voice and style.

Moreover, it fosters cross-team alignment and strengthens collaboration with stakeholders, including designers, product managers, accessibility experts, and, naturally, the Design System team.

If you’re looking to elevate your design team’s capabilities, I strongly recommend starting the process of setting up a Content Design System sooner rather than later.

Finally, if you want to embark on the journey of crafting a robust Content Design System for your organisation, don’t hesitate to reach out!

What I learned implementing UX Writing in a Design System was originally published in AVIV Product & Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.