DEV Community: Daniel Tavares

Wishes From AI

Daniel Tavares — Thu, 20 Jun 2024 13:59:34 +0000

This is a submission for the Twilio Challenge

What I Built

I built Wishes from AI, an innovative app designed to generate personalized celebration messages using AI and Twilio’s powerful communication APIs. This app allows users to create heartfelt messages for various occasions, such as birthdays, anniversaries, and other special events, and send them as voice messages to friends and family.

Demo

youtube.com

Screenshots

Twilio and AI

I leveraged Twilio’s Voice API, phone number validation, and OpenAI’s text generation capabilities to create an integrated solution for sending personalized voice messages. Here’s how it works:

Message Generation: Users input their message or use the app to generate a random message using OpenAI. This ensures that even users who are unsure of what to say can send meaningful messages.
AI Voice Generation: The app uses PlayHT to convert the text message into a natural-sounding voice message. There is support for normal and cloned voices for even more fun.
Phone Number Validation: Before sending the message, the app uses Twilio’s Lookup API to validate the recipient’s phone number, ensuring that messages are sent to valid numbers.
Twilio Integration: The generated voice message is uploaded to Firebase, and a URL is generated. Twilio’s Voice API is then used to make a call to the recipient, playing the voice message.

By integrating Twilio’s capabilities, the app ensures reliable and clear communication, making each celebration special and memorable.

Additional Prize Categories

• Twilio Times Two: The app extensively uses Twilio’s Voice API to deliver voice messages and the Lookup API for phone number validation.
• Impactful Innovators: By making it easier to send personalized celebration messages, the app helps people stay connected and celebrate important moments despite physical distances.
• Entertaining Endeavors: The integration with OpenAI and PlayHT (normal and parody voices) to generate random and fun messages adds an element of surprise and entertainment for users.

Further Notes

Currently using Twillio sandbox account (not tested it live)
Apple sign in with firebase
Scheduled celebrations cloud functions (future work)
More cloned voices (future work)
Redesign (I'm not a designer, so future work)
Privacy and Firebase App Check and api's lifted to the cloud (future work)
Twillio apis: https://lookups.twilio.com/v2/PhoneNumbers + https://api.twilio.com/2010-04-01/Accounts/xxx/Calls.json

Crash Course: Automating .xccrashpoint Exports in MacOS

Daniel Tavares — Thu, 09 May 2024 07:38:25 +0000

As a developer, encountering crashes in your applications is inevitable, and efficiently handling these incidents is crucial for maintaining software quality. Recently, I found myself in a scenario where I needed to export and provide a .xccrashpoint file to a third-party company for further analysis. This requirement quickly turned into a technical adventure, leading me to explore the capabilities of Automator on MacOS to streamline this process.

In this blog post, I will guide you through the steps of creating an Automator script that simplifies the task of exporting .xccrashpoint files. Whether you're looking to enhance your workflow or just curious about automation in MacOS, this post will provide valuable insights into the power of Automator and how it can be applied to real-world development challenges.

What is a .xccrashpoint?

An .xccrashpoint file is an integral part of Apple’s Xcode development environment, specifically designed to capture detailed information about crashes that occur within iOS, macOS, tvOS, or watchOS applications. These files are generated automatically by Xcode when an app crashes during development or testing. They contain critical data such as the state of the application at the time of the crash, stack traces, and other diagnostic information that can be used to analyze and fix bugs.

You can export an .xccrashpoint directly from Xcode. If you open the contents of that folder you will see something like this.

As you can see there are a few .crash files inside the /Logs folder. These files can be read easily and are not dependant on an Xcode.

Bash script to extract those files

With the help of our good old ChatGPT we managed to create a bash script that will go inside an .xccrashpoint and extract/zip those files for us.



#!/bin/bash

# ANSI color codes for coloring the output
RED='\033[0;31m'
GREEN='\033[0;32m'
NC='\033[0m' # No Color, to reset to the default terminal color

# Verify that a directory has been provided as an argument
if [ $# -eq 0 ]; then
    echo -e "${RED}Usage: $0 <directory>${NC}"
    exit 1
fi

# Assign the first argument as the directory
DIRECTORY="$1"

# Make sure the directory path does not end with a slash for consistency
DIRECTORY="${DIRECTORY%/}"

# Extract the base name for the zip file without the .xccrashpoint extension
BASENAME=$(basename "$DIRECTORY")
BASENAME="${BASENAME%.xccrashpoint}"

# Define the output zip file's name, based on the modified base name
ZIPFILE="${BASENAME}.zip"

# Print the directory being searched
echo "Searching in: $DIRECTORY"

# List .crash files to be zipped
echo "Files found:"
find "$DIRECTORY" -type f -name '*.crash'

# Change to the directory where .crash files are found
cd "$DIRECTORY"

# Use find to locate all .crash files and zip them without the directory path
find . -type f -name '*.crash' -exec zip -j "../$ZIPFILE" '{}' +

# Check if the zip operation was successful
if [ -f "../$ZIPFILE" ]; then
    echo -e "${GREEN}All .crash files have been successfully zipped into ../${ZIPFILE}.${NC}"
else
    echo -e "${RED}No .crash files were found to zip or there was an error in zipping.${NC}"
fi

When you run this script you should end up with a zip file containing all the crash files.

Going a step further

Being able to run a script is fine, but what about going a step further and creating an automator workflow to simplify this process.

Overview of macOS Automator

Automator is a powerful tool included with macOS that allows users to automate repetitive tasks without the need for complex programming skills. It provides a simple, graphical user interface where you can build workflows using a variety of actions that perform specific tasks. These workflows can be saved as applications, services, or quick actions that can be triggered with a click or automatically in response to certain events.

Benefits of Using Automator

Efficiency and Time Savings: Automator significantly reduces the time required to perform routine tasks. By automating sequences of actions that you perform frequently, you can focus on more important aspects of your work.
Ease of Use: With its drag-and-drop interface, Automator makes it accessible for non-programmers to create complex automations. This simplicity empowers more users to take advantage of automation technologies.

Customization: Automator offers extensive customization options, allowing users to tailor actions according to their specific needs. Whether it's organizing files, resizing images, or automating backups, Automator can handle a wide range of tasks.
Integration with macOS: Since Automator is a native tool, it integrates seamlessly with other macOS applications and features. This integration enhances workflow compatibility and reliability across the system.

Cost-Effective: As a built-in feature of macOS, Automator comes at no additional cost to the user, making it a cost-effective solution for automation compared to third-party software.

Automating the zipping of an .xccrashpoint

You can create Quick Actions that can be used in finder to perform tasks.

The workflow will look something like this:

Make sure you set:

Workflow receives current: files or folders
In: Finder

Drag a Run shell script and enter the following code.



#!/bin/bash

# Log file location
LOGFILE="$HOME/Desktop/automator_log.txt"

# Write the date and time to the log file
echo "Running script at $(date)" >> "$LOGFILE"

# Initialize a variable to store file names
zipped_files=""

for f in "$@"
do
    echo "Received: $f" >> "$LOGFILE"
    if [[ -d "$f" && "$f" == *.xccrashpoint ]]; then
        DIRECTORY="$f"
        DIRECTORY="${DIRECTORY%/}"  # Remove any trailing slash

        BASENAME=$(basename "$DIRECTORY")
        BASENAME="${BASENAME%.xccrashpoint}"

        # Define the output zip file's name, saved in the same parent directory as the .xccrashpoint folder
        ZIPFILE="${DIRECTORY%/*}/${BASENAME}.zip"  # Modify this line

        echo "Zipping files from $DIRECTORY into $ZIPFILE..." >> "$LOGFILE"

        # Navigate to the directory where .crash files are found
        cd "$DIRECTORY"

        # Use find to locate all .crash files, add them to the zip, and collect their names
        file_list=$(find . -type f -name '*.crash' -exec echo '{}' \;)
        zipped_files+="$file_list\n"  # Append found files to the zipped_files string
        echo "$file_list" | xargs zip -j "$ZIPFILE"  # Zip the files

        # Check if the zip operation was successful
        if [ -f "$ZIPFILE" ]; then
            echo "Successfully zipped into $ZIPFILE" >> "$LOGFILE"
            echo "$ZIPFILE|$zipped_files"  # Output the zip path and zipped files for AppleScript
        else
            echo "Failed to create zip file" >> "$LOGFILE"
        fi

        # Change back to the original directory
        cd - > /dev/null
    else
        echo "Not a .xccrashpoint directory: $f" >> "$LOGFILE"
    fi
done

The code for LOGFILE is optional, I only used it so help me debug.

Once that workflow is saved you should now be able to use as a quick action.

Next steps

I believe the next step would be to create an SwiftUI Mac app to make this even better. Stay tuned for Part 2.

Navigating through the complexities of software crashes and ensuring the continuity of development processes can be daunting. With the Automator workflows outlined in this post, I hope to have demonstrated a straightforward and powerful method to not only manage but also automate the handling of .xccrashpoint files. This not only saves time but also enhances the efficiency of your development workflow.

Embracing automation in development isn't just about reducing manual effort; it's about empowering developers to focus more on creative solutions rather than repetitive tasks. As you incorporate these automation techniques into your own projects, I encourage you to explore further and customize them to better fit your needs.

I am eager to hear about your experiences and any additional tips or insights you might have on using Automator or handling .xccrashpoint files. Feel free to share your thoughts and feedback in the comments below. If there’s enough interest, I’ll consider expanding on this topic with a follow-up post or even starting a series on automation in development environments.

Thank you for reading, and happy automating!

Unlock Efficient CI/CD: How YAML Anchors Transform Your Bitrise Setup

Daniel Tavares — Tue, 07 May 2024 09:11:49 +0000

In the fast-paced world of software development, efficiency is king. Whether you're building mobile apps or managing backend services, streamlining your processes can dramatically improve your productivity and reduce time-to-market. This is where YAML, a straightforward yet powerful configuration language, comes into play, especially when used in conjunction with Bitrise, a leading Continuous Integration and Continuous Deployment (CI/CD) platform designed specifically for mobile app development.

YAML's simplicity and human-readable format make it an ideal choice for configuring complex workflows. When paired with Bitrise, it enables developers to create reusable, easy-to-understand pipelines that automate the build, test, and deployment processes. This synergy not only simplifies the initial setup but also enhances ongoing workflow management, ensuring that updates, adjustments, and scaling are just as efficient as initial configurations.

In this blog post, we'll dive deep into the world of YAML and explore how using anchoring and other advanced features can transform your Bitrise workflows. By the end of this post, you'll understand how to leverage YAML to optimize your mobile development processes, making them more efficient and error-free. Let's get started on maximizing your productivity with Bitrise and YAML.

*Sample Workflow (Unoptimised) *

---
format_version: '8'
default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git

project_type: ios
workflows:
  primary:
    steps:
      - activate-ssh-key@4:
          run_if: '{{getenv "SSH_RSA_PRIVATE_KEY" | ne ""}}'

      - git-clone@6: {}

      - cache-pull@2: {}

      - certificate-and-profile-installer@1: {}

      - xcode-test@3:
          inputs:
            - project_path: "$BITRISE_PROJECT_PATH"
            - scheme: "$BITRISE_SCHEME"
            - simulator_os_version: "latest"
            - simulator_device: iPhone 11 Pro Max

      - xcode-build-for-simulator@0:
          inputs:
            - project_path: "$BITRISE_PROJECT_PATH"
            - scheme: "$BITRISE_SCHEME"
            - simulator_device: iPhone 11 Pro Max

      - cache-push@2:
          inputs:
            - cache_paths: |-
                ./Pods -> ./Podfile.lock
                ./Carthage -> ./Cartfile.resolved

      - slack@3:
          inputs:
            - webhook_url: "$SLACK_WEBHOOK_URL"
            - channel: "#builds"
            - message: "Build finished successfully!"

As you can see there are a few steps in this primary workflow. The more workflows you have with similar steps the bigger your yaml will get.

Anchoring in YAML

YAML, or "YAML Ain't Markup Language", is a human-readable data serialization format. It is commonly used for configuration files and in applications where data is being stored or transmitted. One of the most powerful features of YAML is its support for anchors and aliases, which allow for the reuse of defined content across multiple parts of the document, significantly reducing repetition and making maintenance easier.

Defining Anchors and Aliases

Anchors in YAML are defined by using the & symbol followed by a name, and they mark a section of the document for future reference. Aliases, on the other hand, are references to these anchors, made using the * symbol followed by the name of the anchor they refer to.

How Anchors and Aliases Help

Anchors and aliases are particularly useful in large configuration files with repeated structures or values. They not only keep the YAML file DRY (Don't Repeat Yourself), but they also simplify updates: change the value at the anchor, and all associated aliases automatically get updated. This is invaluable in environments like CI/CD workflows where multiple, slightly different configurations might be used repeatedly.

Simple Examples of YAML Anchors and Aliases

Here’s a simple example to illustrate how anchors and aliases work in YAML:


# Define an anchor for a reusable component
reusable_settings: &default_settings
  check_interval: 60
  start_on_boot: true
  retry_limit: 5

# Using alias to reuse the settings
service_one:
  <<: *default_settings
  name: "Service One"

service_two:
  <<: *default_settings
  name: "Service Two"
  check_interval: 90  # Override the check_interval for this service only

In this example, reusable_settings is defined with an anchor &default_settings. It is then used in the configurations for service_one and service_two using the alias **default_settings. The <<: *default_settings* syntax is a special merge key indicating that the elements defined in the anchor should be merged into the current map.

For service_two, you can see how easy it is to override a specific setting (check_interval) that was included via an alias, demonstrating how flexible this feature can be.

Applying Anchors and Aliases in Bitrise YAML Configurations

When applied to Bitrise YAML configurations, anchors and aliases can manage repeated patterns like environment variables, build settings, or even entire workflows efficiently. This allows developers to simplify complex CI/CD configurations and ensure consistency across different stages of the development and deployment process.

Using anchors and aliases effectively can lead to cleaner, more manageable, and less error-prone configuration files, making it a best practice worth adopting in your Bitrise YAML configurations.

Here is a revised version of our bitrise yaml using 2 workflows.

format_version: '8'
default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git

steps:
  - step: &xcode-test
      xcode-test@3:
          inputs:
            - project_path: "$BITRISE_PROJECT_PATH"
            - scheme: "$BITRISE_SCHEME"
            - simulator_os_version: "latest"
            - simulator_device: iPhone 11 Pro Max
  - step: &xcode-build-for-sim
      xcode-build-for-simulator@0:
          inputs:
            - project_path: "$BITRISE_PROJECT_PATH"
            - scheme: "$BITRISE_SCHEME"
            - simulator_device: iPhone 11 Pro Max
  - step: &cache-push
      cache-push@2:
          inputs:
            - cache_paths: |-
                ./Pods -> ./Podfile.lock
                ./Carthage -> ./Cartfile.resolved
  - step: &slack-message
      slack@3:
          inputs:
            - webhook_url: "$SLACK_WEBHOOK_URL"
            - channel: "#builds"
            - message: "Build finished successfully!"


project_type: ios
workflows:
  primary:
    steps:
      - activate-ssh-key@4:
          run_if: '{{getenv "SSH_RSA_PRIVATE_KEY" | ne ""}}'
      - git-clone@6: {}
      - cache-pull@2: {}
      - certificate-and-profile-installer@1: {}
      - *xcode-test
      - *xcode-build-for-sim
      - *cache-push
      - *slack-message
  secondary:
    steps:
      - activate-ssh-key@4:
          run_if: '{{getenv "SSH_RSA_PRIVATE_KEY" | ne ""}}'
      - git-clone@6: {}
      - cache-pull@2: {}
      - certificate-and-profile-installer@1: {}
      - *xcode-test
      - *xcode-build-for-sim
      - *cache-push
      - *slack-message

The use of YAML in conjunction with Bitrise offers a robust framework for automating and optimizing CI/CD pipelines, especially for mobile app development. By incorporating YAML's anchoring and aliasing features, developers can greatly reduce redundancy within their configuration files, leading to cleaner, more manageable, and more reliable setups.

We encourage you to experiment with these YAML techniques in your projects. Start small by refactoring a single workflow, see the benefits, and gradually expand your use of these features. As you become more comfortable with YAML's capabilities, you'll find that many aspects of your CI/CD process can be optimized, not just by automating tasks, but by organizing them more effectively as well.

Happy coding, and may your builds always be successful!

If let shorthand project wide refactoring using Xcode regex search & replace.

Daniel Tavares — Thu, 09 Jun 2022 13:08:11 +0000

Swift 5.7 introduced this beauty (if let shorthand)
https://github.com/apple/swift-evolution/blob/main/proposals/0345-if-let-shorthand.md

You can leverage the power of regex in Xcode search and replace bar to refactor your projects codebase.

Search:

if let (\w+) = (\1) \{

Replace:

if let $1 \{

Easier SwiftUI animations with AnimatedState property wrapper.

Daniel Tavares — Tue, 01 Jun 2021 09:41:26 +0000

To animate something SwiftUI you have a couple of choices, implicit and explicit animations. Implicit animations are done view view modifiers .animation(.easeIn) and explicitly ones are declare inside the animation block withAnimation.

I often use explicit animation and therefore I am always setting the values of a State property inside the animation block.

struct ExplicityAnimationExample: View {
    @State var scaleSquare = false
    var body: some View {
        Rectangle()
        .fill(Color.red)
        .frame(width: 100, height: 100)
        .scaleEffect(scaleSquare ? 2 : 1)
        .onAppear {
            withAnimation(.spring()) {
                scaleSquare.toggle()
            }
        }
    }
}

The same thing can be achieved by implicitly adding the animation after the scaleEffect modifier

struct ExplicityAnimationExample2: View {
    @State var scaleSquare = false
    var body: some View {
        Rectangle()
        .fill(Color.red)
        .frame(width: 100, height: 100)
        .scaleEffect(scaleSquare ? 2 : 1)
        .animation(.spring())
        .onAppear {
            scaleSquare.toggle()
        }
    }
}

This saves you wrapping the content inside the withAnimation block.

The more views you have that require animation the more state changes and view modifiers you will need.

struct ExplicityAnimationExample3: View {
    @State var scaleSquare = false
    @State var scaleSquare2 = false
    var body: some View {
        VStack(spacing: 150) {
            Rectangle()
            .fill(Color.red)
            .frame(width: 100, height: 100)
            .scaleEffect(scaleSquare ? 2 : 1)
            .animation(.spring())

            Rectangle()
            .fill(Color.blue)
            .frame(width: 100, height: 100)
            .scaleEffect(scaleSquare ? 2 : 1)
            .animation(.spring().speed(0.5))
        }

        .onAppear {
            scaleSquare.toggle()
            scaleSquare2.toggle()
        }
    }
}

I find it particular difficult to maintain this is in a nice way, due to the fact that you change state in one place and you have to find the the corresponding animation that matches said change.

So I created a new property wrapper to solve this problem.

I call it AnimatedState.

You can declare the state and animation that you want like so:

@AnimatedState(
        value: false,
        animation: .spring()
    ) var scaleSquare

Now if you change that value it will automatically animate with the given animation.

Here is the final version

struct AnimatedStateExample: View {
    @AnimatedState(
        value: false,
        animation: .spring()
    ) var scaleSquare


    @AnimatedState(
        value: false,
        animation: .spring().speed(0.5)
    ) var scaleSquare2

    var body: some View {
        VStack(spacing: 150) {
            Rectangle()
            .fill(Color.red)
            .frame(width: 100, height: 100)
            .scaleEffect(scaleSquare ? 2 : 1)

            Rectangle()
            .fill(Color.blue)
            .frame(width: 100, height: 100)
            .scaleEffect(scaleSquare2 ? 2 : 1)
        }

        .onAppear {
            scaleSquare.toggle()
            scaleSquare2.toggle()
        }
    }
}

This eliminate the animation modifier for each square or saves you writing the with animation block every time you need to change state.

Hope this is useful for people.

AnimatedState Gist
Animating Views and Transitions

Creating a MacOS command line tool to dynamically generate PreviewDevice devices for SwiftUI

Daniel Tavares — Mon, 17 May 2021 08:37:46 +0000

When you want to preview your SwiftUI view on different devices, you need to use the previewDevice view modifier like so:



MyView()
 .previewDevice(PreviewDevice(rawValue: "iPhone 12 Pro Max"))
 .previewDisplayName("iPhone 12 Pro Max")

If you set the preview device to nil, Xcode will automatically choose the appropriate device based on your current target.

When creating a PreviewDevice manually, you will need to set the rawValue string to the correct device name. Failing to do so will generate an error in the preview window.

A way to avoid having to manually enter the rawValue yourself is to use the Preview UI.

I particular don't like hardcoded values/nor using the ui, so I thought I would create a utility to generate strongly typed values to make my life easier.

Our goal is to be able to do this:



Content().preview(on: .iPhoneSE2ndGeneration)

Creating a Command Line Tool.

Step 1

New > Project > MacOS > Command Line Tool

Step 2: Retrieve a list of the available simulators.

We can achieve this using simctl



xcrun simctl list --json devices available

The nice thing about this command is that you can pass in json so it would make it easier to parse it in swift.

Step 3: Generating our models.

For me the go to place is QuickType. It makes it easier to convert JSON into gorgeous, typesafe code in any language. (As they put it)

Step 4: Executing shell commands from swift.

I'm using ShellOut made by John Sundel. It wraps shell commands into a lovely wrapper that makes it easier and delightful to use it.



let output = try shellOut(to: "xcrun simctl list --json devices available")

Step 5: Parsing

Once we retrieve the json above, we will need to decode into our model.



let deviceTypes = try JSONDecoder().decode(SimCTL.self, from: data)

The current json structure is held in a variable var devices: [String: [Device]], where the key is the runtime value (com.apple.CoreSimulator.SimRuntime.iOS-14-4). We are interested in the flat list of devices here so we can generate the final swift file. So we will parse that our selves during decoding.



public init(from decoder: Decoder) throws {
    let container = try decoder.container(keyedBy: CodingKeys.self)
    devices = try container.decode([String: [Device]].self, forKey: CodingKeys.devices)
    supportedDevices = devices
        .filter({ !$0.value.isEmpty })
        .map({ $0.value })
        .flatMap({ $0 })
}

Step 6: Generating our swift file

Once we retrieve the available devices, parsed them and have our models in place, it's time to generate our final output file. First we need to create a template string and inject the list of devices dynamically.

This is what the final file looks like:



let template =
"""extension PreviewDevice {
    {{DYNAMIC CONTENT HERE}}
}

struct PreviewDeviceModifier: ViewModifier {
    let previewDevice: PreviewDevice

    func body(content: Content) -> some View {
        content
            .previewDevice(previewDevice)
            .previewDisplayName(previewDevice.rawValue)
    }
}

public extension View {
    func preview(on previewDevice: PreviewDevice) -> some View {
        self.modifier(
            PreviewDeviceModifier(
                previewDevice: previewDevice
            )
        )
    }
}
"""

Step 7: Injecting the string



let deviceTypes = try JSONDecoder().decode(SimCTL.self, from: data)
let finalOutput = String(format: template, "\(deviceTypes)")

If you are wondering how we've managed to pass the variable deviceTypes and somehow generated static let appleWatchSeries540mm = Self(rawValue: "Apple Watch Series 5 - 40mm"), let me show you.

You can extend String to allow custom interpolation of values. So we can do this:



extension String.StringInterpolation {
    mutating func appendInterpolation(_ value: SimCTL) {
        let devicesString = value
            .supportedDevices
            .map({ "static let \($0.name.camelized) = Self(rawValue: \"\($0.name)\")"  })
            .joined(separator: "\n\t")

        appendLiteral(devicesString)
    }
}

Notice how we've extended the appendInterpolation and added SimCTL for the value parameter. Doing so allow us to control what will be appended to the final string result.

Final Step: Generating the final file

The last piece of the puzzle is to generate that file. I'm using Files, another open source project by John Sundel.



let folder = Folder.current

        let file = try folder.createFile(named: "PreviewDeviceUtils.swift")

        try file.write(finalOutput)

Conclusion

I think I've achieve our initial goal, albeit pointless as you can do all this using the UI. But hopefully we've managed to learn a few things along the way and now we can generate many more utility apps. This could also be done using a MacOS app, which I will probably attempt to develop and see what we can learn from it.

Source Code

Simpler way to deal with hardcoded ViewModifers values in SwiftUI

Daniel Tavares — Mon, 10 May 2021 11:04:28 +0000

How often do you you have to deal with 2 values based on a condition in your SwiftUI views?

.background(isShowingSomething ? Color.red : Color.blue)
.font(isShowingSomething ? .title : .callout).padding(isShowingSomething ? 20 : 50)

This can become cumbersome specially if you have a lot of view modifiers that rely on said values.

struct NonToggledExampleView: View {
    @State var isShowingMenu = false

    var body: some View {
        ZStack {
            if isShowingMenu {
                Color.red.edgesIgnoringSafeArea(.all)
            } else {
                Color.blue.edgesIgnoringSafeArea(.all)
            }

            VStack {
                Text("Hello from Toggled")
                    .font(isShowingMenu ? .title : .callout)
                Button(action: {
                    isShowingMenu.toggle()
                }, label: {
                    Text("Toggle Me")
                })
            }.background(isShowingMenu ? Color.yellow : Color.green)
        }
    }
}

In order to update those values you will need to navigate your code, remember what they are and update accordingly. Resume preview and you are on your way.

One way of simplifying this is to extract those values into variables.

private var backgroundColorOn = Color.red
private var backgroundColorOff = Color.blue

This will grow exponentially the more options you have.

Introducing Toggled

We can do better than this, so I've created Toggled. Toggled allows you to specify both values at initialization in order to make it easy to write/read/update your SwiftUI hardcoded values.

struct ToggledExampleView: View {
    @State var isShowingMenu = false
    @State var backgroundColor = Toggled<Color>(values: (on: .red, off: .blue))
    @State var font = Toggled<Font>(values: (on: .title, off: .callout))
    @State var stackBackgroundColor = Toggled<Color>(values: (on: .yellow, off: .green))
    @State var stackPadding = Toggled<CGFloat>(values: (on: 20, off: 0))

    var body: some View {
        ZStack {
            backgroundColor.value(state: isShowingMenu)
                .edgesIgnoringSafeArea(.all)
            VStack {
                Text("Hello from Toggled")
                    .fixedSize()
                    .font(font.value(state: isShowingMenu))
                Button(action: {
                    withAnimation {
                        isShowingMenu.toggle()
                    }
                }, label: {
                    Text("Toggle Me")
                })
            }
            .padding(stackPadding.value(state: isShowingMenu))
            .background(stackBackgroundColor.value(state: isShowingMenu))
        }
    }
}

Source Code

protocol ToggleInterface {
    associatedtype ValueType
    var values: (on: ValueType, off: ValueType) { get set }
    func value(state: Bool) -> ValueType
}

struct Toggled<T>: ToggleInterface {
    typealias ValueType = T
    var values: (on: T, off: T)
    func value(state: Bool) -> T {
        guard state else {
            return values.off
        }
        return values.on
    }
}

Using toggled will eliminate the need for the ternary/if when you want to use the value, it makes it easier to reason with the options you have in your view and also you can make it dynamic by turning into a binding.

Futher improvements

We could take this a step further and create some sort of utility to dynamically change those values at run time.

DebugToggledViewRangeValue(title: "$stackPadding", toggled: $stackPadding, range: 0...100)

struct DebugToggledViewColor: View {
    var title: String
    var toggled: Binding<Toggled<Color>>

    var body: some View {
        VStack(spacing: 0) {
            Text(title)
         HStack {
            ColorPicker("On", selection: toggled.onValue)
            Spacer()
            ColorPicker("Off", selection: toggled.offValue)
        }
        }
    }
}

struct DebugToggledViewRangeValue<T>: View where T : BinaryFloatingPoint, T.Stride : BinaryFloatingPoint {
    var title: String
    var toggled: Binding<Toggled<T>>
    var range: ClosedRange<T>

    var body: some View {
        VStack(spacing: 0) {
            Text(title)
            HStack {
                VStack {
                    Text("On")
                    Slider(value: toggled.onValue, in: range)
                }
                VStack {
                    Text("Off")
                    Slider(value: toggled.offValue, in: range)
                }
            }
        }
    }
}

extension Binding where Value: ToggleInterface {
    var onValue: Binding<Value.ValueType> {
        return Binding<Value.ValueType> {
            wrappedValue.values.on
        } set: { newValue in
            wrappedValue.values.on = newValue
        }
    }

    var offValue: Binding<Value.ValueType> {
        return Binding<Value.ValueType> {
            wrappedValue.values.off
        } set: { newValue in
            wrappedValue.values.off = newValue
        }
    }
}

Love to hear your thoughts and feedback.

GIST

Easy SwiftUI View bindings Using OptionSet and Sourcery

Daniel Tavares — Fri, 07 May 2021 08:32:16 +0000

Have you ever had a SwiftUI view with lots of toggles?

struct LotsOfStateView: View {
    //1
    @State var showBackground = false
    //2
    @State var showBorder = false
    //3
    @State var reduceMotionEnabled = false
    //4
    @State var largeFont = false
    //5
    @State var receiveEmailNotifications = false

    var body: some View {
        VStack {
            Toggle(isOn: $showBackground) {
                Text(LocalizedStringKey("Show Background"))
            }
            Toggle(isOn: $showBorder) {
                Text(LocalizedStringKey("Show Border"))
            }
            Toggle(isOn: $reduceMotionEnabled) {
                Text(LocalizedStringKey("Reduce Motion Enabled"))
            }
            Toggle(isOn: $largeFont) {
                Text(LocalizedStringKey("Large Font"))
            }
            Toggle(isOn: $receiveEmailNotifications) {
                Text(LocalizedStringKey("Receive Notifications"))
            }
        }
        .padding()
        .font(.system(size: 22, weight: .light, design: .rounded))
    }
}

Dealing with those toggles is pretty straight forward task, but it can become cumbersome the more you add.

A technique of reducing the amount of Bool values is to compact them into one storage unit. We can essentially convert them into a series of zeros and ones. Sounds familiar?

There are only 10 types of people in the world – those who understand binary, and those who don’t.

So if we were to convert the @State above to something more manageable we could use Swift's OptionSet. They are very similar to enums.

I'm sure you have set a reminder before. If you set the frequency of the reminder (Monday, Wednesday and Saturday) for example. You are essentially creating a set of 3 values.

This basic idea of being able to create a combination of desired values is perfect to remove the amount of boilerplate state we have in your view.

If we were to convert the above @State into an OptionSet we could do this:

struct Options: OptionSet {
    var rawValue: UInt
    static let none = Self([])
    static let showBackground = Self(rawValue: 1 << 0)
    static let showBorder = Self(rawValue: 1 << 1)
    static let reduceMotionEnabled = Self(rawValue: 1 << 2)
    static let largeFont = Self(rawValue: 1 << 3)
    static let receiveEmailNotifications = Self(rawValue: 1 << 4)
}

Then in our views we could remove all the @State in favour of one.

@State var viewOptions = Options.none

If you look at the rawValue of the OptionSet, it's an UInt. You are essentially storing the union of values into 1 single storage value. (Series of 101001, on/off)

This is what your view would look like.

struct LessStateVariablesView: View {
    @State var viewOptions = Options.none

    var body: some View {
        ZStack {
            if $viewOptions.bindValue(.showBackground) {
                Color.red.edgesIgnoringSafeArea(.all)
            }
            VStack {
                Toggle(isOn: $viewOptions.bind(.showBackground)) {
                    Text(LocalizedStringKey("Show Background"))
                }
                Toggle(isOn: $viewOptions.bind(.showBorder)) {
                    Text(LocalizedStringKey("Show Border"))
                }
                Toggle(isOn: $viewOptions.bind(.reduceMotionEnabled)) {
                    Text(LocalizedStringKey("Reduce Motion Enabled"))
                }
                Toggle(isOn: $viewOptions.bind(.largeFont)) {
                    Text(LocalizedStringKey("Large Font"))
                }
                Toggle(isOn: $viewOptions.bind(.receiveEmailNotifications)) {
                    Text(LocalizedStringKey("Receive Notifications"))
                }
            }
            .padding()
            .font(.system(size: 22, weight: .light, design: .rounded))
        }
    }
}

As you can see, we've shifted all the previous @State and encapsulated into an OptionSet. The behaviour is exactly the same but instead of having 5 bools, we have 1 and all the true and false is stored as 1 single UInt.

Converting an OptionSet into Binding

Now that we have our options, we need a way of interacting with them in our SwiftUI View. If you wanted to use a toggle for example we need a Binding.

A property wrapper type that can read and write a value owned by a source of truth.

Binding is a struct with a Generic value Value, so we could write an extension in order to interact with our new OptionSet.

extension Binding where Value: OptionSet, Value == Value.Element {
    func bindedValue(_ options: Value) -> Bool {
        return wrappedValue.contains(options)
    }

    func bind(
        _ options: Value,
        animate: Bool = false
    ) -> Binding<Bool> {
        return .init { () -> Bool in
            self.wrappedValue.contains(options)
        } set: { newValue in
            let body = {
                if newValue {
                    self.wrappedValue.insert(options)
                } else {
                    self.wrappedValue.remove(options)
                }
            }
            guard animate else {
                body()
                return
            }
            withAnimation {
                body()
            }
        }
    }
}

By doing so we can now plug it in our SwiftUI view.

We have now access to bindedValue to pull out its Bool representation and also bind where you can pass to the Toggle to update its value. There is also a convenient animate option in order to animate its changes.

Removing Boiler Plate (Sourcery to the rescue)

Writing an OptionSet is fairly trivial, but I often forget the syntax and the correct rawValue needed for each item.

I have created an Stencil template file which can be used with Sourcery in order to make creating those OptionSet very simple and easy.

Sourcery is a code generator for Swift language, built on top of Apple's own SwiftSyntax. It extends the language abstractions to allow you to generate boilerplate code automatically.
Sourcery

What we can do now is to create an enum with your cases and make sure you conform to OptionsBinding.

protocol OptionsBinding {}

enum MyEnum: OptionsBinding {
    case showBackground
    case showBorder
    case reduceMotionEnabled
    case largeFont
    case receiveEmailNotifications
}

Sourcery will then extend that enum and add the equivalent OptionSet for you.

extension MyEnum {
    struct Options: OptionSet {
        var rawValue: UInt
        static let none = Self([])
        static let showBackground = Self(rawValue: 1 << 0)
        static let showBorder = Self(rawValue: 1 << 1)
        static let reduceMotionEnabled = Self(rawValue: 1 << 2)
        static let largeFont = Self(rawValue: 1 << 3)
        static let receiveEmailNotifications = Self(rawValue: 1 << 4)
    }
}

Now you are free to use MyEnum.Options wherever you need.

I hope this will help some folks to reduce some of the Bool boilerplate in your views and also make it easy to reason with your options by having a nice enum to use.

Stencil template

{% for type in types.enums where type.cases.count > 0 and type.based.OptionsBinding or type|annotated:"OptionsBinding" %}
extension {{ type.name }} {
    struct Options: OptionSet {
        var rawValue: UInt
        static let none = Self([])
        {% for i in 0...type.cases.count %}
            {% if not forloop.last %}
        static let {{type.cases[i].name}} = Self(rawValue: 1 << {{i}})
      {% endif %}
    {% endfor %}
    }
}
{% endfor %}

extension Binding where Value: OptionSet, Value == Value.Element {
    func bindValue(_ options: Value) -> Bool {
        return wrappedValue.contains(options)
    }

    func bind(
        _ options: Value,
        animate: Bool = false
    ) -> Binding<Bool> {
        return .init { () -> Bool in
            self.wrappedValue.contains(options)
        } set: { newValue in
            let body = {
                if newValue {
                    self.wrappedValue.insert(options)
                } else {
                    self.wrappedValue.remove(options)
                }
            }
            guard animate else {
                body()
                return
            }
            withAnimation {
                body()
            }
        }
    }
}

References / Useful Links

Source Code
Custom OptionSet
OptionSet
Sourcery