General

Principal Software Engineer @ Just Eat Takeaway. iOS Infrastructure Engineer. Based in London.

A design to implement a simple, generic and decentralised manager for CLI tools from the perspective of a Swift dev.

Overview It's common for iOS teams to rely on various CLI tools such as SwiftLint, Tuist, and Fastlane. These tools are often installed in different ways. The most common way is to use Homebrew, which is known to lack version pinning and, as Pedro puts it: Homebrew is not able to install and activate multiple versions of the same tool I also fundamentally dislike the tap system for installing dependencies from third-party repositories. Although I don't have concrete data, I feel that most development teams profoundly dislike Homebrew when used beyond the simple installation of individual tools from the command line and the brew taps system is cumbersome and bizarre enough to often discourage developers from using it. Alternatives to manage sets of CLI tools that got traction in the past couple of years are Mint and Mise. As Pedro again says in his article about Mise: The first and most core feature of Mise is the ability to install and activate dev tools. Note that we say "activate" because, unlike Homebrew, Mise differentiates between installing a tool and making a specific version of it available. While beyond the scope of this article, I recommend a great article about installing Swift executables from source with Mise by Natan Rolnik. In this article I describe a CLI tool manager very similar to what I've implemented for my team. I'll simply call it "ToolManager". The tool is designed to: Support installing any external CLI tool distributed in zip archives Support activating specific versions per project Be decentralised (requiring no registry) I believe the decentralisation is an interesting aspect and makes the tool reusable in any development environment. Also, differently from the design of mise and mint, ToolManager doesn't build from source and rather relies on pre-built executables. In the age of GenAI, it's more important than ever to develop critical thinking and learn how to solve problems. For this reason, I won't show the implementation of ToolManager, as it's more important to understand how it's meant to work. The code you'll see in this article supports the overarching design, not the nitty-gritty details of how ToolManager's commands are implemented. If, by the end of the article, you understand how the system should work and are interested in implementing it (perhaps using GenAI), you should be able to convert the design to code fairly easily—hopefully, without losing the joy of coding. I myself am considering implementing ToolManager as an open source project later, as I believe it might be very helpful to many teams, just as its incarnation was (and continues to be) for the platform team at JET. There doesn't seem to be an existing tool with the design described in this article. A different title could have reasonably placed this article in "The easiest X" "series" (1, 2, 3, 4), if I may say so. Design The point here is to learn what implementing a tool manager entails. I'll therefore describe the MVP of ToolManager, leaving out details that would make the design too straightforward to implement. The tool itself is a CLI and it's reasonably implemented in Swift using ArgumentParser like all modern Swift CLI tools are. In its simplest form, ToolManager exposes 3 commands: install: download and installs the tools defined in a spec file (Toolfile.yml) at ~/.toolManager/tools optionally validating the checksum creates symlinks to the installed versions at $(PWD)/.toolManager/active uninstall: clears the entire or partial content of ~/.toolManager/tools clears the content of $(PWD)/.toolManager/active version: returns the version of the tool The install commands allows to specify the location of the spec file using the --spec flag, which defaults to Toolfile.yml in the current directory. The installation of ToolManager should be done in the most raw way, i.e. via a remote script. It'd be quite laughable to rely on Brew, wouldn't it? This practice is commonly used by a variety of tools, for example originally by Tuist (before the introduction of Mise) and... you guessed it... by Brew. We'll see below a basic script to achieve so that you could host on something lik AWS S3 with the desired public permissions. The installation command would be: curl -Ls 'https://my-bucket.s3.eu-west-1.amazonaws.com/install_toolmanager.sh' | bash The version of ToolManager must be defined in the .toolmanager-version file in order for the installation script of the repo to work: echo "1.2.0" > .toolmanager-version ToolManager manages versions of CLI tools but it's not in the business of managing its own versions. Back in the day, Tuist used to use tuistenv to solve this problem. I simply avoid it and have single version of ToolManager available at /usr/local/bin/ that the installation script overrides with the version defined for the project. The version command is used by the script to decide if a download is needed. There will be only one version of ToolManager in the system at a given time, and that's absolutely OK. At this point, it's time to show an example of installation script: #!/bin/bash set -euo pipefail # Fail fast if essential commands are missing. command -v curl >/dev/null || { echo "curl not found, please install it."; exit 1; } command -v unzip >/dev/null || { echo "unzip not found, please install it."; exit 1; } readonly EXEC_NAME="ToolManager" readonly INSTALL_DIR="/usr/local/bin" readonly EXEC_PATH="$INSTALL_DIR/$EXEC_NAME" readonly HOOK_DIR="$HOME/.toolManager" readonly REQUIRED_VERSION=$(cat .toolmanager-version) # Exit if the version file is missing or empty. if [[ -z "$REQUIRED_VERSION" ]]; then echo "Error: .toolmanager-version not found or is empty." >&2 exit 1 fi # Exit if the tool is already installed and up to date. if [[ -f "$EXEC_PATH" ]] && [[ "$($EXEC_PATH version)" == "$REQUIRED_VERSION" ]]; then echo "$EXEC_NAME version $REQUIRED_VERSION is already installed." exit 0 fi # Determine OS and the corresponding zip filename. case "$(uname -s)" in Darwin) ZIP_FILENAME="$EXEC_NAME-macOS.zip" ;; Linux) ZIP_FILENAME="$EXEC_NAME-Linux.zip" ;; *) echo "Unsupported OS: $(uname -s)" >&2; exit 1 ;; esac # Download and install in a temporary directory. TMP_DIR=$(mktemp -d) trap 'rm -rf "$TMP_DIR"' EXIT # Ensure cleanup on script exit. echo "Downloading $EXEC_NAME ($REQUIRED_VERSION)..." DOWNLOAD_URL="https://github.com/MyOrg/$EXEC_NAME/releases/download/$REQUIRED_VERSION/$ZIP_FILENAME" curl -LSsf --output "$TMP_DIR/$ZIP_FILENAME" "$DOWNLOAD_URL" unzip -o -qq "$TMP_DIR/$ZIP_FILENAME" -d "$TMP_DIR" # Use sudo only when the install directory is not writable. SUDO_CMD="" if [[ ! -w "$INSTALL_DIR" ]]; then SUDO_CMD="sudo" fi echo "Installing $EXEC_NAME to $INSTALL_DIR..." $SUDO_CMD mkdir -p "$INSTALL_DIR" $SUDO_CMD mv "$TMP_DIR/$EXEC_NAME" "$EXEC_PATH" $SUDO_CMD chmod +x "$EXEC_PATH" # Download and source the shell hook to complete installation. echo "Installing shell hook..." mkdir -p "$HOOK_DIR" curl -LSsf --output "$HOOK_DIR/shell_hook.sh" "https://my-bucket.s3.eu-west-1.amazonaws.com/shell_hook.sh" # shellcheck source=/dev/null source "$HOOK_DIR/shell_hook.sh" echo "Installation complete." You might have noticed that: the required version of ToolManager (defined in .toolmanager-version) is downloaded from the release from the corresponding GitHub repository if missing locally. The ToolManager repo should have a GHA workflow in place to build, archive and upload the version. a shell_hook script is downloaded and run to insert the following line in the shell profile: [[ -s "$HOME/.toolManager/shell_hook.sh" ]] && source "$HOME/.toolManager/shell_hook.sh". This allows switching location in the terminal and loading the active tools for the current project. Showing an example of shell_hook.sh is in order: #!/bin/bash # Overrides 'cd' to update PATH when entering a directory with a local tool setup. # Add the project-specific bin directory to PATH if it exists. update_tool_path() { local tool_bin_dir="$PWD/.toolManager/active" if [[ -d "$tool_bin_dir" ]]; then export PATH="$tool_bin_dir:$PATH" fi } # Redefine 'cd' to trigger the path update after changing directories. cd() { builtin cd "$@" || return update_tool_path } # --- Installation Logic --- # The following function only runs when this script is sourced by an installer. install_hook() { local rc_file case "${SHELL##*/}" in bash) rc_file="$HOME/.bashrc" ;; zsh) rc_file="$HOME/.zshrc" ;; *) echo "Unsupported shell for hook installation: $SHELL" >&2 return 1 ;; esac # The line to add to the shell's startup file. local hook_line="[[ -s \"$HOME/.toolManager/shell_hook.sh\" ]] && source \"$HOME/.toolManager/shell_hook.sh\"" # Add the hook if it's not already present. if ! grep -Fxq "$hook_line" "$rc_file" &>/dev/null; then printf "\n%s\n" "$hook_line" >> "$rc_file" echo "Shell hook installed in $rc_file. Restart your shell to apply changes." fi } # This check ensures 'install_hook' only runs when sourced, not when executed. if [[ "${BASH_SOURCE[0]}" != "$0" ]]; then install_hook fi Now that we have a working installation of ToolManager, let define our Toolfile.yml in our project folder: --- tools: - name: PackageGenerator binaryPath: PackageGenerator version: 3.3.0 zipUrl: https://github.com/justeattakeaway/PackageGenerator/releases/download/3.3.0/PackageGenerator-macOS.zip - name: SwiftLint binaryPath: swiftlint version: 0.57.0 zipUrl: https://github.com/realm/SwiftLint/releases/download/0.58.2/portable_swiftlint.zip - name: ToggleGen binaryPath: ToggleGen version: 1.0.0 zipUrl: https://github.com/TogglesPlatform/ToggleGen/releases/download/1.0.0/ToggleGen-macOS-universal-binary.zip - name: Tuist binaryPath: tuist version: 4.48.0 zipUrl: https://github.com/tuist/tuist/releases/download/4.54.3/tuist.zip - name: Sourcery binaryPath: bin/sourcery version: 2.2.5 zipUrl: https://github.com/krzysztofzablocki/Sourcery/releases/download/2.2.5/sourcery-2.2.5.zip The install command of ToolManager loads the Toolfile at the root of the repo and for each defined dependency, performs the following: checks if the version of the dependency already exists on the machine if it doesn’t exist, downloads it, unzips it, and places the binary at ~/.toolManager/tools/ (e.g. ~/.toolManager/tools/PackageGenerator/3.3.0/PackageGenerator) creates a symlink to the binary in the project directory from .toolManager/active (e.g. .toolManager/active/PackageGenerator) After running ToolManager install (or ToolManager install --spec=Toolfile.yml), ToolManager should produce the following structure ~ tree ~/.toolManager/tools -L 2 ├── PackageGenerator │   └── 3.3.0 ├── Sourcery │   └── 2.2.5 ├── SwiftLint │   └── 0.57.0 ├── ToggleGen │   └── 1.0.0 └── Tuist    └── 4.48.0 and from the project folder ls -la .toolManager/active <redacted> PackageGenerator -> /Users/alberto/.toolManager/tools/PackageGenerator/3.3.0/PackageGenerator <redacted> Sourcery -> /Users/alberto/.toolManager/tools/Sourcery/2.2.5/Sourcery <redacted> SwiftLint -> /Users/alberto/.toolManager/tools/SwiftLint/0.57.0/SwiftLint <redacted> ToggleGen -> /Users/alberto/.toolManager/tools/ToggleGen/1.0.0/ToggleGen <redacted> Tuist -> /Users/alberto/.toolManager/tools/Tuist/4.48.0/Tuist Bumping the versions of some tools in the Toolfile, for example SwiftLint and Tuist, and re-running the install command, should result in the following: ~ tree ~/.toolManager/tools -L 2 ├── PackageGenerator │   └── 3.3.0 ├── Sourcery │   └── 2.2.5 ├── SwiftLint │   ├── 0.57.0 │   └── 0.58.2 ├── ToggleGen │   └── 1.0.0 └── Tuist    ├── 4.48.0    └── 4.54.3 ls -la .toolManager/active <redacted> PackageGenerator -> /Users/alberto/.toolManager/tools/PackageGenerator/3.3.0/PackageGenerator <redacted> Sourcery -> /Users/alberto/.toolManager/tools/Sourcery/2.2.5/Sourcery <redacted> SwiftLint -> /Users/alberto/.toolManager/tools/SwiftLint/0.58.2/SwiftLint <redacted> ToggleGen -> /Users/alberto/.toolManager/tools/ToggleGen/1.0.0/ToggleGen <redacted> Tuist -> /Users/alberto/.toolManager/tools/Tuist/4.54.3/Tuist CI Setup On CI, the setup is quite simple. It involves 2 steps: install ToolManager install the tools The commands can be wrapped in GitHub composite actions: name: Install ToolManager runs: using: composite steps: - name: Install ToolManager shell: bash run: curl -Ls 'https://my-bucket.s3.eu-west-1.amazonaws.com/install_toolmanager.sh' | bash name: Install tools inputs: spec: description: The name of the ToolManager spec file required: false default: Toolfile.yml runs: using: composite steps: - name: Install tools shell: bash run: | ToolManager install --spec=${{ inputs.spec }} echo "$PWD/.toolManager/active" >> $GITHUB_PATH simply used in workflows: - name: Install ToolManager uses: ./.github/actions/install-toolmanager - name: Install tools uses: ./.github/actions/install-tools with: spec: Toolfile.yml CLI tools conformance ToolManager can install tools that are made available in zip files, without the need of implementing any particular spec. Depending on the CLI tool, the executable can be at the root of the zip archive or in a subfolder. Sourcery for example places the executable in the bin folder. - name: Sourcery binaryPath: bin/sourcery version: 2.2.5 zipUrl: https://github.com/krzysztofzablocki/Sourcery/releases/download/2.2.5/sourcery-2.2.5.zip GitHub releases are great to host releases as zip files and that's all we need. Ideally, one should decorate the repositories with appropriate release workflows. Following is a simple example that builds a macOS binary. It could be extended to also create a Linux binary. name: Publish Release on: push: tags: - '*' env: CLI_NAME: my-awesome-cli-tool permissions: contents: write jobs: build-and-archive: name: Build and Archive macOS Binary runs-on: macos-latest steps: - name: Checkout repository uses: actions/checkout@v4 - name: Setup Xcode uses: maxim-lobanov/setup-xcode@v1 with: xcode-version: '16.4' - name: Build universal binary run: swift build -c release --arch arm64 --arch x86_64 - name: Archive the binary run: | cd .build/apple/Products/Release/ zip -r "${{ env.CLI_NAME }}-macOS.zip" "${{ env.CLI_NAME }}" - name: Upload artifact for release uses: actions/upload-artifact@v4 with: name: cli-artifact path: .build/apple/Products/Release/${{ env.CLI_NAME }}-macOS.zip create-release: name: Create GitHub Release needs: [build-and-archive] runs-on: ubuntu-latest steps: - name: Download CLI artifact uses: actions/download-artifact@v4 with: name: cli-artifact - name: Create Release and Upload Asset uses: softprops/action-gh-release@v2 with: files: "${{ env.CLI_NAME }}-macOS.zip" A note on version pinning Dependency management systems tend to use a lock file (like Package.resolved in Swift Package manager, Podfile.lock in the old days of CocoaPods, yarn.lock/package-lock.json in JavaScript, etc.). The benefits of using a lock file are mainly 2: Reproducibility It locks the exact versions (including transitive dependencies) so that every team member, CI server, or production environment installs the same versions. Faster installs Dependency managers can skip version resolution if a lock file is present, using it directly to fetch the exact versions, improving speed. We can remove the need for lock files if we pin the versions in the spec (the file defining the tools). If version range operators like the CocoaPods' optimistic operator ~> and the SPM's .upToNextMajor and similar one didn't exist, usages of lock files would lose its utility. While useful, lock files are generally annoying and can create that odd feeling of seeing unexpected updates in pull requests made by others. ToolManager doesn't use a lock file; instead, it requires teams to pin their tools' versions, which I strongly believe is a good practice. This approach comes at the cost of teams having to keep an eye out for patch releases and not leaving updates to the machine, which risks pulling in dependencies that don't respect Semantic Versioning (SemVer). Support for different architectures This design allows to support different architectures. Some CI workflows might only need a Linux runner to reduce the burden on precious macOS instances. Both macOS and Linux can be supported with individual Toolfile that can be specified when running the install command. # on macOS ToolManager install --spec=Toolfile_macOS # on Linux ToolManager install --spec=Toolfile_Linux Conclusion The design described in this article powers the solution implemented at JET and has served our teams successfully since October 2023. JET has always preferred to implement in-house solutions where possible and sensible, and I can say that moving away from Homebrew was a blessing. With this design, the work usually done by a package manager and a central spec repository is shifted to individual components that are only required to publish releases in zip archives, ideally via a release workflow. By decentralising and requiring version pinning, we made ToolManager a simple yet powerful system for managing the installation of CLI tools.

A quick guide to setting up a Swift Package Registry with Artifactory to speed up builds and streamline dependency management.

Introduction It's very difficult to have GenAI not hallucinate when in comes to Swift Package Registry. No surprise there: the feature is definitely niche, has not been vastly adopted and there's a lack of examples online. As Dave put it, Swift Package Registries had an even rockier start compared to SPM. I've recently implemented a Swift Package Registry on Artifactory for my team and I thought of summarising my experience here since it's still fresh in my head. While some details are left out, the happy path should be covered. I hope with this article to help you all indirectly by providing more material to the LLMs overlords. Problem The main problem that led us to look into Swift Package Registry is due to SPM deep-cloning entire Git repositories for each dependency, which became time-consuming. Our CI jobs took a few minutes just to pull all the Swift packages. For dependencies with very large repositories, such as SendbirdUIKit (which is more than 2GB), one could rely on pre-compiled XCFrameworks as a workaround. Airbnb provides a workaround via the SPM-specific repo for Lottie. A Swift Registry allows to serve dependencies as zip artifacts containing only the required revision, avoiding the deep clone of the git repositories. What is a Swift Package Registry? A Swift Package Registry is a server that stores and vends Swift packages by implementing SE-0292 and the corresponding specification. Instead of relying on Git repositories to source our dependencies, we can use a registry to download them as versioned archives (zip files). swift-package-manager/Documentation/PackageRegistry/PackageRegistryUsage.md at main · swiftlang/swift-package-manager The Package Manager for the Swift Programming Language - swiftlang/swift-package-manager GitHubswiftlang The primary advantages of using a Swift Package Registry are: Reduced CI/CD Pipeline Times: by fetching lightweight zip archives from the registry rather than cloning the entire repositories from GitHub. Improved Developer Machine Performance: the same time savings on CI are reflected on the developers' machines during dependency resolution. Availability: by hosting a registry, teams are no longer dependent on the availability of external source control systems like GitHub, but rather on internal ones (for example, self-hosted Artifactory). Security: injecting vulnerabilities in popular open-source projects is known as a supply chain attack and has become increasingly popular in recent years. A registry allows to adopt a process to trust the sources published on it. Platforms Apple has accepted the Swift Registry specification and implemented support to interact with registries within SPM but has left the implementation of actual registries to third-party platforms. Apple is not in the business of providing a Swift Registry. The main platform having adopted Swift Registries is Artifactory. Artifactory, Your Swift Package Repository JFrog now offers the first and only Swift binary package repository, enabling developers to use JFrog Artifactory for resolving Swift dependencies instead of enterprise source control (Git) systems. JFroggiannit although AWS CodeArtifact, Cloudsmith and Tuist provide support too: New – Add Your Swift Packages to AWS CodeArtifact | Amazon Web Services Starting today, Swift developers who write code for Apple platforms (iOS, iPadOS, macOS, tvOS, watchOS, or visionOS) or for Swift applications running on the server side can use AWS CodeArtifact to securely store and retrieve their package dependencies. CodeArtifact integrates with standard developer tools such as Xcode, xcodebuild, and the Swift Package Manager (the swift […] Amazon Web ServicesSébastien Stormacq Private, secure, hosted Swift registry Cloudsmith offers secure, private Swift registries as a service, with cloud native performance. Book a demo today. Cloudsmith Announcing Tuist Registry We’re thrilled to announce the launch of the Tuist Registry – a new feature that optimizes the resolution of Swift packages in your projects. TuistMarek Fořt The benefits are usually appealing to teams with large apps, hence it's reasonable to believe that only big companies have looked into adopting a registry successfully. Artifactory Setup Let's assume a JFrog Artifactory to host our Swift Package Registry exists at https://packages.acme.com. Artifactory support local, remote, and virtual repositories but a realistic setup consists of only local and virtual repositories. Source: Artifactory Local Repositories are meant to be used for publishing dependencies from CI pipelines. Virtual Repositories are instead meant to be used for resolving (pulling) dependencies on both CI and the developers' machines. Remote repositories are not really relevant in a typical Swift Registry setup. Following the documentation at https://jfrog.com/help/r/jfrog-artifactory-documentation/set-up-a-swift-registry, let's create 2 repositories with the following names: local repository: swift-local virtual repository: swift-virtual Local Setup To pull dependencies from the Swift Package Registry, we need to configure the local environment. 1. Set the Registry URL First, we need to inform SPM about the existence of the registry. We can do this on a per-project basis or globally for the user account. From a package's root directory, run the following command. This will create a .swiftpm/configuration/registries.json file within your project folder. swift package-registry set "https://packages.acme.com/artifactory/api/swift/swift-virtual" The resulting registries.json file will look like this: { "authentication": {}, "registries": { "[default]": { "supportsAvailability": false, "url": "https://packages.acme.com/artifactory/api/swift/swift-virtual" } }, "version": 1 } To set the registry for all your projects, use the --global flag. swift package-registry set --global "https://packages.acme.com/artifactory/api/swift/swift-virtual" This will create the configuration file at ~/.swiftpm/configuration/registries.json. Xcode projects don't support project-level registries nor (in my experience) support scopes other than the default one (i.e. avoid using the --scope flag). 2. Authentication To pull packages, authenticating with Artifactory is usually required. It's reasonable though that your company allows all artifacts from Artifactory to be read without authentication as long as one is connected to the company VPN. In cases where authentication is required, SPM uses a .netrc file in the home directory to find credentials for remote servers. This file is a standard way to handle login information for various network protocols. Using a token generated from the Artifactory dashboard, the line to add to the .netrc file would be: machine packages.acme.com login <your_artifactory_username> password <your_artifactory_token> Alternatively, it's possible to log in using the swift package-registry login command. This command securely stores your token in the system's keychain. swift package-registry login "https://packages.acme.com/artifactory/api/swift/swift-virtual" \ --token <token> # or swift package-registry login "https://packages.acme.com/artifactory/api/swift/swift-virtual" \ --username <username> \ --password <token_treated_as_password> CI/CD Setup On CI, the setup is slightly different as the goals are: to resolve dependencies in CI/CD jobs to publish new package versions in CD jobs for both internal and external dependencies The steps described for the local setup are valid for the resolution on CI too. The interesting part here is how publishing is done. I will assume the usage of GitHub Actions. 1. Retrieving the Artifactory Token The JFrog CLI can be used via the setup-jfrog-cli action to authenticate using the most appropriate method. You might want to wrap the action in a custom composable one exporting the token as the output of a step: TOKEN=$(jf config export) echo "::add-mask::$TOKEN" echo "artifactory-token=$TOKEN">> "$GITHUB_OUTPUT" 2. Logging into the Registry The CI job must log in to the local repository (swift-local) to gain push permissions. The token retrieved in the previous step is used for this purpose. swift package-registry login \ "https://packages.acme.com/artifactory/api/swift/swift-local" \ --token ${{ steps.get-token.outputs.artifactory-token }} 3. Publishing Packages Swift Registry requires archives created with the swift package archive-source command from the dependency folder. E.g. swift package archive-source -o "Alamofire-5.10.2.zip" We could avoid creating the archive and instead download it directly from GitHub releases. curl -L -o Alamofire-5.10.1.zip \ https://github.com/Alamofire/Alamofire/archive/refs/tags/5.10.1.zip Uploading the archive can then be done by using the JFrog CLI that needs customization via the setup-jfrog-cli action. If going down this route, the upload command would be: jf rt upload Alamofire-5.10.1.zip \ https://packages.acme.com/artifactory/api/swift/swift-local/acme/Alamofire/Alamofire-5.10.1.zip There is a specific structure to respect: <REPOSITORY>/<SCOPE>/<NAME>/<NAME>-<VERSION>.zip which is the last part of the above URL: swift-local/acme/Alamofire/Alamofire-5.10.1.zip Too bad that using the steps above causes a downstream problem with SPM not being able to resolve the dependencies in the registry. I tried extensively and couldn't find the reason why SPM wouldn't be happy with how the packages were published. I might have missed something but eventually I necessarily had to switch to use the publish command. Using the swift package-registry publish command instead, doesn't present this issue hence it's the solution adopted in this workflow. swift package-registry publish acme.Alamofire 5.10.1 \ --url https://packages.acme.com/artifactory/api/swift/swift-local \ --scratch-directory $(mktemp -d) To verify the upload and indexing succeeded, check that the uploaded *.zip artifact is available and that the .swift exists (indication that the indexing has occurred). If the specific structure is not respected, the .swift folder wouldn't be generated. Consuming Packages from the Registry Packages The easiest and only documented way to consume a package from a registry is via a Package. In the Package.swift file, declare dependencies using the .package(id:from:) syntax to declare a registry-based dependency. The id is a combination of the scope and the package name. ... dependencies: [ .package(id: "acme.Alamofire", from: "5.10.1"), ], targets: [ .target( name: "MyApp", dependencies: [ .product(name: "Alamofire", package: "acme.Alamofire"), ] ), ... ] ) Run swift package resolve or simply build the Package in Xcode to pull the dependencies. You might bump into transitive dependencies (i.e. dependencies listed in the Package.swift files of the packages published on the registry) pointing to GitHub. In this case, it'd be great to instruct SPM to use the corresponding versions on the registry. The --replace-scm-with-registry flag is designed to work for the entire dependency graph, including transitive dependencies. The cornerstone of associating a registry-hosted package with its GitHub origin is the package-metadata.json file. This file allows to provide essential metadata about the packages at the time of publishing (the --metadata-path flag of the publish command defaults to pacakge-metadata.json). Crucially, it includes a field to specify the source control repository URLs. When swift package resolve --replace-scm-with-registry is executed, SPM queries the configured registry. The registry then uses the information from the package-metadata.json to map the package identity to its corresponding GitHub URL, enabling a smooth and transparent resolution process. The metadata file must conform to the JSON schema defined in SE-0391. It is recommended to include all URL variations (e.g., SSH, HTTPS) for the same repository. E.g. { "repositoryURLs": [ "https://github.com/Alamofire/Alamofire", "https://github.com/Alamofire/Alamofire.git", "git@github.com:Alamofire/Alamofire.git" ] } Printing the dependencies should confirm the source of the dependencies: swift package show-dependencies --replace-scm-with-registry When loading a package with Xcode, the flag can be enabled via an environment variable in the scheme IDEPackageDependencySCMToRegistryTransformation=useRegistryIdentityAndSources Too bad that for packages, the schemes won't load until SPM completes the resolution hence running the following from the terminal would address the issue: defaults write com.apple.dt.Xcode IDEPackageDependencySCMToRegistryTransformation useRegistryIdentityAndSources that can be unset with: defaults delete com.apple.dt.Xcode IDEPackageDependencySCMToRegistryTransformation Xcode It's likely that you'll want to use the registry from Xcode projects for direct dependencies. If using the Tuist registry, it seems you would be able to leverage a Package Collection to add dependencies from the registry from the Xcode UI. Note that until Xcode 26 Beta 1, it's not possible to add registry dependencies directly in the Xcode UI, but if you use Tuist to generate your project (as you should), you can use the Package.registry (introduced with https://github.com/tuist/tuist/pull/7225). E.g. let project = Project( ... packages: [ .registry( identifier: "acme.Alamofire", requirement: .exact(Version(stringLiteral: "5.10.1")) ) ], ... ) If not using Tuist, you'd have to rely on setting IDEPackageDependencySCMToRegistryTransformation either as an environment variable in the scheme or globally via the terminal. You can also use xcodebuild to resolve dependencies using the correct flag: xcodebuild \ -resolvePackageDependencies \ -packageDependencySCMToRegistryTransformation useRegistryIdentityAndSources Conclusions We’ve found that using an in-house Swift registry drastically reduces dependency resolution time and size on disk by downloading only the required revision instead of the entire, potentially large, Git repository. This improvement benefits both CI pipelines and developers’ local environments. Additionally, registries help mitigate the risk of supply chain attacks. As of this writing, Swift registries are not widely adopted, which is reflected in the limited number of platforms that support them. It also shows various bugs I myself bumped into when using particular configurations. source: https://forums.swift.org/t/package-registry-support-in-xcode/73626/19 It's unclear whether adoption will grow and uncertain if Apple will ever address the issues reported by the community, but when a functioning setup is put in place, registries offer an efficient and secure alternative to using XCFrameworks in production builds and reduce both memory and time footprints.

How Just Eat Takeaway.com leverage AWS, Packer, Terraform and GitHub Actions to manage a CI stack of macOS runners.

Originally published on the Just Eat Takeaway Engineering Blog. How Just Eat Takeaway.com leverage AWS, Packer, Terraform and GitHub Actions to manage a CI stack of macOS runners. Problem At Just Eat Takeaway.com (JET), our journey through continuous integration (CI) reflects a landscape of innovation and adaptation. Historically, JET’s multiple iOS teams operated independently, each employing their distinct CI solutions. The original Just Eat iOS and Android teams had pioneered an in-house CI solution anchored in Jenkins. This setup, detailed in our 2021 article, served as the backbone of our CI practices up until 2020. It was during this period that the iOS team initiated a pivotal migration: moving from in-house Mac Pros and Mac Minis to AWS EC2 macOS instances. Fast forward to 2023, a significant transition occurred within our Continuous Delivery Engineering (CDE) Platform Engineering team. The decision to adopt GitHub Actions company-wide has marked the end of our reliance on Jenkins while other teams are in the process of migrating away from solutions such as CircleCI and GitLab CI. This transition represented a fundamental shift in our CI philosophy. By moving away from Jenkins, we eliminated the need to maintain an instance for the Jenkins server and the complexities of managing how agents connected to it. Our focus then shifted to transforming our Jenkins pipelines into GitHub Actions workflows. This transformation extended beyond mere tool adoption. Our primary goal was to ensure that our macOS instances were not only scalable but also configured in code. We therefore enhanced our global CI practices and set standards across the entire company. Desired state of CI As we embarked on our journey to refine and elevate our CI process, we envisioned a state-of-the-art CI system. Our goals were ambitious yet clear, focusing on scalability, automation, and efficiency. At the time of implementing the system, no other player in the industry seemed to have implemented the complete solution we envisioned. Below is a summary of our desired CI state: Instance setup in code: One primary objective was to enable the definition of the setup of the instances entirely in code. This includes specifying macOS version, Xcode version, Ruby version, and other crucial configurations. For this purpose, the HashiCorp tool Packer, emerged once again as an ideal solution, offering the flexibility and precision we required. IaC (Infrastructure as Code) for macOS instances: To define the infrastructure of our fleet of macOS instances, we leaned towards Terraform, another HashiCorp tool. Terraform provided us with the capability to not only deploy but also to scale and migrate our infrastructure seamlessly, crucially maintaining its state. Auto and Manual Scaling: We wanted the ability to dynamically create CI runners based on demand, ensuring that resources were optimally utilized and available when needed. To optimize resource utilization, especially during off-peak hours, we desired an autoscaling feature. Scaling down our CI runners on weekends when developer activity is minimal was critical to be cost-effective. Automated Connection to GitHub Actions: We aimed for the instances to automatically connect to GitHub Actions as runners upon deployment. This automation was crucial in eliminating manual interventions via SSH or VNC. Multi-Team Use: Our vision included CI runners that could be easily used by multiple teams across different time zones. This would not only maximize the utility of our infrastructure but also encourage reuse and standardization. Centralized Management via GitHub Actions: To further streamline our CI processes, we intended to run all tasks through GitHub Actions workflows. This approach would allow the teams to self-serve and alleviate the need for developers to use Docker or maintain local environments. Getting to the desired state was a journey that presented multiple challenges and constant adjustments to make sure we could migrate smoothly to a new system. Instance setup in code We implemented the desired configuration with Packer leveraging a number of Shell Provisioners and variables to configure the instance. Here are some of the configuration steps: Set user password (to allow remote desktop access) Resize the partition to use all the space available on the EBS volume Start the Apple Remote Desktop agent and enable remote desktop access Update Brew & Install Brew packages Install CloudWatch agent Install rbenv/Ruby/bundler Install Xcode versions Install GitHub Actions actions-runner Copy scripts to connect to GitHub Actions as a runner Copy daemon to start the GitHub Actions self-hosted runner as a service Set macos-init modules to perform provisioning of the first launch While the steps above are naturally configuration steps to perform when creating the AMI, the macos-init modules include steps to perform once the instance becomes available. The create_ami workflow accepts inputs that are eventually passed to Packer to generate the AMI. packer build \ --var ami_name_prefix=${{ env.AMI_NAME_PREFIX }} \ --var region=${{ env.REGION }} \ --var subnet_id=${{ env.SUBNET_ID }} \ --var vpc_id=${{ env.VPC_ID }} \ --var root_volume_size_gb=${{ env.ROOT_VOLUME_SIZE_GB }} \ --var macos_version=${{ inputs.macos-version}} \ --var ruby_version=${{ inputs.ruby-version }} \ --var xcode_versions='${{ steps.parse-xcode-versions.outputs.list }}' \ --var gha_version=${{ inputs.gha-version}} \ bare-metal-runner.pkr.hcl Different teams often use different versions of software, like Xcode. To accommodate this, we permit multiple versions to be installed on the same instance. The choice of which version to use is then determined within the GitHub Actions workflows. The seamless generation of AMIs has proven to be a significant enabler. For example, when Xcode 15.1 was released, we executed this workflow the same evening. In just over two hours, we had an AMI ready to deploy all the runners (it usually takes 70–100 minutes for a macOS AMI with 400GB of EBS volume to become ready after creation). This efficiency enabled our teams to use the new Xcode version just a few hours after its release. IaC (Infrastructure as Code) for macOS instances Initially, we used distinct Terraform modules for each instance to facilitate the deployment and decommissioning of each one. Given the high cost of EC2 Mac instances, we managed this process with caution, carefully balancing host usage while also being mindful of the 24-hour minimum allocation time. We ultimately ended up using Terraform to define a single infrastructure (i.e. a single Terraform module) defining resources such as: aws_key_pair, aws_instance, aws_ami aws_security_group, aws_security_group_rule aws_secretsmanager_secret aws_vpc, aws_subnet aws_cloudwatch_metric_alarm aws_sns_topic, aws_sns_topic_subscription aws_iam_role, aws_iam_policy, aws_iam_role_policy_attachment, aws_iam_instance_profile A crucial part was to use count in aws_instance, setting the value of a variable passed in from deploy_infra workflow. Terraform performs the necessary scaling upon changing the value. We have implemented a workflow to perform Terraform apply and destroy commands for the infrastructure. Only the AMI and the number of instances are required as inputs. terraform ${{ inputs.command }} \ --var ami_name=${{ inputs.ami-name }} \ --var fleet_size=${{ inputs.fleet-size }} \ --auto-approve Using the name of the AMI instead of the ID allows us to use the most recent one that was generated, useful in case of name clashes. variable "ami_name" { type = string } variable "fleet_size" { type = number } data "aws_ami" "bare_metal_gha_runner" { most_recent = true filter { name = "name" values = ["${var.ami_name}"] } ... } resource "aws_instance" "bare_metal" { count = var.fleet_size ami = data.aws_ami.bare_metal_gha_runner.id instance_type = "mac2.metal" tenancy = "host" key_name = aws_key_pair.bare_metal.key_name ... } Instead of maintaining multiple CI instances with varying software configurations, we concluded that it’s simpler and more efficient to have a single, standardised setup. While teams still have the option to create and deploy their unique setups, a smaller, unified system allows for easier support by a single global configuration. Auto and Manual Scaling The deploy_infra workflow allows us to scale on demand but it doesn’t release the underlying dedicated hosts which are the resources that are ultimately billed. The autoscaling solution provided by AWS is great for VMs but gets sensibly more complex when actioned on dedicated hosts. Auto Scaling groups on macOS instances would require a Custom Managed License, a Host Resource Group and, of course, a Launch Template. Using only AWS services appears to be a lot of work to pull things together and the result wouldn’t allow for automatic release of the dedicated hosts. AirBnb mention in their Flexible Continuous Integration for iOS article that an internal scaling service was implemented: An internal scaling service manages the desired capacity of each environment’s Auto Scaling group. Some articles explain how to set up Auto Scaling groups for mac instances (see 1 and 2) but after careful consideration, we agreed that implementing a simple scaling service via GitHub Actions (GHA) was the easiest and most maintainable solution. We implemented 2 GHA workflows to fully automate the weekend autoscaling: Upscaling workflow to n, triggered at a specific time at the beginning of the working week Downscaling workflow to 1, triggered at a specific time at the beginning of the weekend We retain the capability for manual scaling, which is essential for situations where we need to scale down, such as on bank holidays, or scale up, like on release cut days, when activity typically exceeds the usual levels. Additionally, we have implemented a workflow that runs multiple times a day and tries to release all available hosts without an instance attached. This step lifts us from the burden of having to remember to release the hosts. Dedicated hosts take up to 110 minutes to move from the Pending to the Available state due to the scrubbing workflow performed by AWS. Manual scaling can be executed between the times the autoscaling workflows are triggered and they must be resilient to unexpected statuses of the infrastructure, which thankfully Terraform takes care of. Both down and upscaling are covered in the following flowchart: The autoscaling values are defined as configuration variables in the repo settings: It usually takes ~8 minutes for an EC2 mac2.metal instance to become reachable after creation, meaning that we can redeploy the entire infrastructure very quickly. Automated Connection to GitHub Actions We provide some user data when deploying the instances. resource "aws_instance" "bare_metal" { ami = data.aws_ami.bare_metal_gha_runner.id count = var.fleet_size ... user_data = <<EOF { "github_enterprise": "<GHE_ENTERPRISE_NAME>", "github_pat_secret_manager_arn": ${data.aws_secretsmanager_secret_version.ghe_pat.arn}, "github_url": "<GHE_ENTERPRISE_URL>", "runner_group": "CI-MobileTeams", "runner_name": "bare-metal-runner-${count.index + 1}" } EOF The user data is stored in a specific folder by macos-init and we implement a module to copy the content to ~/actions-runner-config.json. ### Group 10 ### [[Module]] Name = "Create actions-runner-config.json from userdata" PriorityGroup = 10 RunPerInstance = true FatalOnError = false [Module.Command] Cmd = ["/bin/zsh", "-c", 'instanceId="$(curl http://169.254.169.254/latest/meta-data/instance-id)"; if [[ ! -z $instanceId ]]; then cp /usr/local/aws/ec2-macos-init/instances/$instanceId/userdata ~/actions-runner-config.json; fi'] RunAsUser = "ec2-user" which is in turn used by the configure_runner.sh script to configure the GitHub Actions runner. #!/bin/bash GITHUB_ENTERPRISE=$(cat $HOME/actions-runner-config.json | jq -r .github_enterprise) GITHUB_PAT_SECRET_MANAGER_ARN=$(cat $HOME/actions-runner-config.json | jq -r .github_pat_secret_manager_arn) GITHUB_PAT=$(aws secretsmanager get-secret-value --secret-id $GITHUB_PAT_SECRET_MANAGER_ARN | jq -r .SecretString) GITHUB_URL=$(cat $HOME/actions-runner-config.json | jq -r .github_url) RUNNER_GROUP=$(cat $HOME/actions-runner-config.json | jq -r .runner_group) RUNNER_NAME=$(cat $HOME/actions-runner-config.json | jq -r .runner_name) RUNNER_JOIN_TOKEN=` curl -L \ -X POST \ -H "Accept: application/vnd.github+json" \ -H "Authorization: Bearer $GITHUB_PAT"\ $GITHUB_URL/api/v3/enterprises/$GITHUB_ENTERPRISE/actions/runners/registration-token | jq -r '.token'` MACOS_VERSION=`sw_vers -productVersion` XCODE_VERSIONS=`find /Applications -type d -name "Xcode-*" -maxdepth 1 \ -exec basename {} \; \ | tr '\n' ',' \ | sed 's/,$/\n/' \ | sed 's/.app//g'` $HOME/actions-runner/config.sh \ --unattended \ --url $GITHUB_URL/enterprises/$GITHUB_ENTERPRISE \ --token $RUNNER_JOIN_TOKEN \ --runnergroup $RUNNER_GROUP \ --labels ec2,bare-metal,$RUNNER_NAME,macOS-$MACOS_VERSION,$XCODE_VERSIONS \ --name $RUNNER_NAME \ --replace The above script is run by a macos-init module. ### Group 11 ### [[Module]] Name = "Configure the GHA runner" PriorityGroup = 11 RunPerInstance = true FatalOnError = false [Module.Command] Cmd = ["/bin/zsh", "-c", "/Users/ec2-user/configure_runner.sh"] RunAsUser = "ec2-user" The GitHub documentation states that it’s possible to create a customized service starting from a provided template. It took some research and various attempts to find the right configuration that allows the connection without having to log in in the UI (over VNC) which would represent a blocker for a complete automation of the deployment. We believe that the single person who managed to get this right is Sébastien Stormacq who provided the correct solution. The connection to GHA can be completed with 2 more modules that install the runner as a service and load the custom daemon. ### Group 12 ### [[Module]] Name = "Run the self-hosted runner application as a service" PriorityGroup = 12 RunPerInstance = true FatalOnError = false [Module.Command] Cmd = ["/bin/zsh", "-c", "cd /Users/ec2-user/actions-runner && ./svc.sh install"] RunAsUser = "ec2-user" ### Group 13 ### [[Module]] Name = "Launch actions runner daemon" PriorityGroup = 13 RunPerInstance = true FatalOnError = false [Module.Command] Cmd = ["sudo", "/bin/launchctl", "load", "/Library/LaunchDaemons/com.justeattakeaway.actions-runner-service.plist"] RunAsUser = "ec2-user" Using a daemon instead of an agent (see Creating Launch Daemons and Agents), doesn’t require us to set up any auto-login which on macOS is a bit of a tricky procedure and is best avoided also for security reasons. The following is the content of the daemon for completeness. <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>com.justeattakeaway.actions-runner-service</string> <key>ProgramArguments</key> <array> <string>/Users/ec2-user/actions-runner/runsvc.sh</string> </array> <key>UserName</key> <string>ec2-user</string> <key>GroupName</key> <string>staff</string> <key>WorkingDirectory</key> <string>/Users/ec2-user/actions-runner</string> <key>RunAtLoad</key> <true/> <key>StandardOutPath</key> <string>/Users/ec2-user/Library/Logs/com.justeattakeaway.actions-runner-service/stdout.log</string> <key>StandardErrorPath</key> <string>/Users/ec2-user/Library/Logs/com.justeattakeaway.actions-runner-service/stderr.log</string> <key>EnvironmentVariables</key> <dict> <key>ACTIONS_RUNNER_SVC</key> <string>1</string> </dict> <key>ProcessType</key> <string>Interactive</string> <key>SessionCreate</key> <true/> </dict> </plist> Not long after the deployment, all the steps above are executed and we can appreciate the runners appearing as connected. Multi-Team Use We start the downscaling at 11:59 PM on Fridays and start the upscaling at 6:00 AM on Mondays. These times have been chosen in a way that guarantees a level of service to teams in the UK, the Netherlands (GMT+1) and Canada (Winnipeg is on GMT-6) accounting for BST (British Summer Time) and DST (Daylight Saving Time) too. Times are defined in UTC in the GHA workflow triggers and the local time of the runner is not taken into account. Since the instances are used to build multiple projects and tools owned by different teams, one problem we faced was that instances could get compromised if workflows included unsafe steps (e.g. modifications to global configurations). GitHub Actions has a documentation page about Hardening self-hosted runners specifically stating: Self-hosted runners for GitHub do not have guarantees around running in ephemeral clean virtual machines, and can be persistently compromised by untrusted code in a workflow. We try to combat such potential problems by educating people on how to craft workflows and rely on the quick redeployment of the stack should the instances break. We also run scripts before and after each job to ensure that instances can be reused as much as possible. This includes actions like deleting the simulators’ content, derived data, caches and archives. Centralized Management via GitHub Actions The macOS runners stack is defined in a dedicated macOS-runners repository. We implemented GHA workflows to cover the use cases that allow teams to self-serve: create macOS AMI deploy CI downscale for the weekend* upscale for the working week* release unused hosts* * run without inputs and on a scheduled trigger The runners running the jobs in this repo are small t2.micro Linux instances and come with the AWSCLI installed. An IAM instance role with the correct policies is used to make sure that aws ec2 commands allocate-hosts, describe-hosts and release-hosts could execute and we used jq to parse the API responses. A note on VM runners In this article, we discussed how we’ve used bare metal instances as runners. We have spent a considerable amount of time investigating how we could leverage the Virtualization framework provided by Apple to create virtual machines via Tart. If you’ve grasped the complexity of crafting a CI system of runners on bare metal instances, you can understand that introducing VMs makes the setup sensibly more convoluted which would be best discussed in a separate article. While a setup with Tart VMs has been implemented, we realised that it’s not performant enough to be put to use. Using VMs, the number of runners would double but we preferred to have native performance as the slowdown is over 40% compared to bare metal. Moreover, when it comes to running heavy UI test suites like ours, tests became too flaky. Testing the VMs, we also realised that the standard values of Throughput and IOPS on the EBS volume didn’t seem to be enough and caused disk congestion resulting in an unacceptable slowdown in performance. Here is a quick summary of the setup and the challenges we have faced. Virtual runners require 2 images: one for the VMs (tart) and one for the host (AMI). We use Packer to create VM images (Vanilla, Base, IDE, Tools) with the software required based on the templates provided by Tart and we store the OCI-compliant images on ECR. We create these images on CI with dedicated workflows similar to the one described earlier for bare metal but, in this case, macOS runners (instead of Linux) are required as publishing to ECR is done with tart which runs on macOS. Extra policies are required on the instance role to allow the runner to push to ECR (using temporary_iam_instance_profile_policy_document in Packer’s Amazon EBS). Apple set a limit to the number of VMs that can be run on an instance to 2, which would allow to double the size of the fleet of runners. Creating AMIs hosting 2 VMs is done with Packer and steps include cloning the image from ECR and configuring macos-init modules to run daemons to run the VMs via Tart. Deploying a virtual CI infrastructure is identical to what has already been described for bare metal. Connecting to and interfacing with the VMs happens from within the host. Opening SSH and especially VNC sessions from within the bare metal instances can be very confusing. The version of macOS on the host and the one on the VMs could differ. The version used on the host must be provided with an AMI by AWS, while the version used on the VMs is provided by Apple in IPSW files (see ipsw.me). The GHA runners run on the VMs meaning that the host won’t require Xcode installed nor any other software used by the workflows. VMs don’t allow for provisioning meaning we have to share configurations with the VMs via shared folders on the host with the — dir flag which causes extra setup complexity. VMs can’t easily run the GHA runner as a service. The svc script requires the runner to be configured first, an operation that cannot be done during the provisioning of the host. We therefore need to implement an agent ourselves to configure and connect the runner in a single script. To have UI access (a-la VNC) to the VMs, it’s first required to stop the VMs and then run them without the --no-graphics flag. At the time of writing, copy-pasting won’t work even if using the --vnc or --vnc-experimental flags. Tartelet is a macOS app on top of Tart that allows to manage multiple GitHub Actions runners in ephemeral environments on a single host machine. We didn’t consider it to avoid relying on too much third-party software and because it doesn’t have yet GitHub Enterprise support. Worth noting that the Tart team worked on an orchestration solution named Orchard that seems to be in its initial stage. Conclusion In 2023 we have revamped and globalised our approach to CI. We have migrated from Jenkins to GitHub Actions as the CI/CD solution of choice for the whole group and have profoundly optimised and improved our pipelines introducing a greater level of job parallelisation. We have implemented a brand new scalable setup for bare metal macOS runners leveraging the HashiCorp tools Packer and Terraform. We have also implemented a setup based on Tart virtual machines. We have increased the size of our iOS team over the past few years, now including more than 40 developers, and still managed to be successful with only 5 bare metal instances on average, which is a clear statement of how performant and optimised our setup is. We have extended the capabilities of our Internal Developer Platform with a globalised approach to provide macOS runners; we feel that this setup will stand the test of time and serve well various teams across JET for years to come.

Prelude

Fastlane is widely used by iOS teams all around the world. It became the standard de facto to automate common tasks such as building apps, running tests, and uploading builds to App Store Connect. Fastlane has been recently moved under the Mobile Native Foundation which is amazing as Google

Prelude Fastlane is widely used by iOS teams all around the world. It became the standard de facto to automate common tasks such as building apps, running tests, and uploading builds to App Store Connect. Fastlane has been recently moved under the Mobile Native Foundation which is amazing as Google wasn't actively maintaining the project. At Just Eat Takeaway, we have implemented an extensive number of custom lanes to perform domain-specific tasks and used them from our CI. The major problem with Fastlane is that it's written in Ruby. When it was born, using Ruby was a sound choice but iOS developers are not necessarily familiar with such language which represents a barrier to contributing and writing lanes. While Fastlane.swift, a version of Fastlane in Swift, has been in beta for years, it's not a rewrite in Swift but rather a "solution on top" meaning that developers and CI systems still have to rely on Ruby, install related software (rbenv or rvm) and most likely maintain a Gemfile. The average iOS dev knows well that Ruby environments are a pain to deal with and have caused an infinite number of headaches. In recent years, Apple has introduced technologies that would enable a replacement of Fastlane using Swift: Swift Package Manager (SPM) Swift Argument Parser (SAP) Being myself a big fan of CLI tools written in Swift, I soon started maturing the idea of a Fastlane rewrite in Swift in early 2022. I circulated the idea with friends and colleagues for months and the sentiment was clear: it's time for a fresh simil-Fastlane tool written in Swift. Journey Towards the end of 2022, I was determined to start this project. I teamed up with 2 iOS devs (not working at Just Eat Takeaway) and we started working on a design. I was keen on calling this project "Swiftlane" but the preference seemed to be for the name "Interstellar" which was eventually shortened into "Stellar". Fastlane has the concept of Actions and I instinctively thought that in Swift-land, they could take the form of SPM packages. This would make Stellar a modular system with pluggable components. For example, consider the Scan action in Fastlane. It could be a package that solely solves the same problem around testing. My goal was not to implement the plethora of existing Fastlane actions but rather to create a system that allows plugging in any package building on macOS. A sound design of such system was crucial. The Stellar ecosystem I had in mind was composed of 4 parts: Actions Actions are the basic building blocks of the ecosystem. They are packages that define a library product. An action can do anything, from taking care of build tasks to integrating with GitHub. Actions are independent packages that have no knowledge of the Stellar system, which treats them as pluggable components to create higher abstractions. Ideally, actions should expose an executable product (the CLI tool) using SAP calling into the action code. This is not required by Stellar but it’s advisable as a best practice. Official Actions would be hosted in the Stellar organisation on GitHub. Custom Actions could be created using Stellar. Tasks Tasks are specific to a project and implemented by the project developers. They are SAP ParsableCommand or AsyncParsableCommand which use actions to construct complex logic specific to the needs of the project. Executor Executor is a command line tool in the form of a package generated by Stellar. It’s the entry point to the user-defined tasks. Invoking tasks on the Executor is like invoking lanes in Fastlane. Both developers and CI would interface with the Executor (masked as Stellar) to perform all operations. E.g. stellar setup_environment --developer-mode stellar run_unit_tests module=OrderHistory stellar setup_demo_app module=OrderHistory stellar run_ui_tests module=OrderHistory device="iPhone 15 Pro" Stellar CLI Stellar CLI is a command line tool that takes care of the heavy lifting of dealing with the Executor and the Tasks. It allows the integration of Stellar in a project and it should expose the following main commands: init: initialise the project by creating an Exectutor package in the .stellar folder build: builds the Executor generating a binary that is shared with the team members and used by CI create-action: scaffolding to create a new action in the form of a package create-task: scaffolding to create a new task in the form of a package edit: opens the Executor package for editing, similar to tuist edit This design was presented to a restricted group of devs at Just Eat Takeaway and it didn't take long to get an agreement on it. It was clear that once Stellar was completed, we would have integrated it in the codebase. Wider design I believe that a combination of CLI tools can create complex, templateable and customizable stacks to support the creation and growth of iOS codebases. Based on the experience developed at JET working on a large modular project with lots of packages, helper tools and optimised CI pipelines, I wanted Stellar to be eventually part of a set of tools taking the name “Stellar Tools” that could enable the creation and the management of large codebases. Something like the following: Tuist: generates projects and workspaces programmatically PackageGenerator: generates packages using a DSL Stacker: creates a modular iOS project based on a DSL Stellar: automate tasks Workflows: generates GitHub Actions workflows that use Stellar From my old notes: Current state After a few months of development within this team (made of devs not working at Just Eat Takeaway), I realised things were not moving in the direction I desired and I decided it was not beneficial to continue the collaboration with the team. We stopped working on Stellar mainly due to different levels of commitment from each of us and focus on the wrong tasks signalling a lack of project management from my end. For example, a considerable amount of time and effort went into the implementation of a version management system (vastly inspired by the one used in Tuist) that was not part of the scope of the Stellar project. The experience left me bitter and demotivated, learning that sometimes projects are best started alone. We made the repo public on GitHub aware that it was far from being production-ready but in my opinion, it's no doubt a nice, inspiring, MVP. GitHub - StellarTools/Stellar Contribute to StellarTools/Stellar development by creating an account on GitHub. GitHubStellarTools GitHub - StellarTools/ActionDSL Contribute to StellarTools/ActionDSL development by creating an account on GitHub. GitHubStellarTools The intent was then to progress on my own or with my colleagues at JET. As things evolved in 2023, we embarked on big projects that continued to evolve the platform such as a massive migration to GitHub Actions. To this day, we still plan to remove Fastlane as our vision is to rely on external dependencies as little as possible but there is no plan to use Stellar as-is. I suspect that, for the infrastructure team at JET, things will evolve in a way that sees more CLI tools being implemented and more GitHub actions using them.

CloudWatch is great for observing and monitoring resources and applications on AWS, on premises, and on other clouds.

While it's trivial to have the agent running on Linux, it's a bit more involved for mac instances (which are commonly used as CI workers). The support was

CloudWatch is great for observing and monitoring resources and applications on AWS, on premises, and on other clouds. While it's trivial to have the agent running on Linux, it's a bit more involved for mac instances (which are commonly used as CI workers). The support was announced in January 2021 for mac1.metal (Intel/x86_64) and I bumped into some challenges on mac2.metal (M1/ARM64) that the team at AWS helped me solve (see this issue on the GitHub repo). I couldn't find other articles nor precise documentation from AWS which is why I'm writing this article to walk you through a common CloudWatch setup. The given code samples are for the HashiCorp tools Packer and Terraform and focus on mac2.metal instances. I'll cover the following steps: install the CloudWatch agent on mac2.metal instances configure the CloudWatch agent create a CloudWatch dashboard setup CloudWatch alarms setup IAM permissions Install the CloudWatch agent The CloudWatch agent can be installed by downloading the pkg file listed on this page and running the installer. You probably want to bake the agent into your AMI, so here is the Packer code for mac2.metal (ARM): # Install wget via brew provisioner "shell" { inline = [ "source ~/.zshrc", "brew install wget" ] } # Install CloudWatch agent provisioner "shell" { inline = [ "source ~/.zshrc", "wget https://s3.amazonaws.com/amazoncloudwatch-agent/darwin/arm64/latest/amazon-cloudwatch-agent.pkg", "sudo installer -pkg ./amazon-cloudwatch-agent.pkg -target /" ] } For the agent to work, you'll need collectd (https://collectd.org/) to be installed on the machine, which is usually done via brew. Brew installs it at /opt/homebrew/sbin/. This is also a step you want to perform when creating your AMI. # Install collectd via brew provisioner "shell" { inline = [ "source ~/.zshrc", "brew install collectd" ] } Configure the CloudWatch agent In order to run, the agent needs a configuration which can be created using the wizard. This page defines the metric sets that are available. Running the wizard with the command below will allow you to generate a basic json configuration which you can modify later. sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard The following is a working configuration for Mac instances so you can skip the process. { "agent": { "metrics_collection_interval": 60, "run_as_user": "root" }, "metrics": { "aggregation_dimensions": [ [ "InstanceId" ] ], "append_dimensions": { "AutoScalingGroupName": "${aws:AutoScalingGroupName}", "ImageId": "${aws:ImageId}", "InstanceId": "${aws:InstanceId}", "InstanceType": "${aws:InstanceType}" }, "metrics_collected": { "collectd": { "collectd_typesdb": [ "/opt/homebrew/opt/collectd/share/collectd/types.db" ], "metrics_aggregation_interval": 60 }, "cpu": { "measurement": [ "cpu_usage_idle", "cpu_usage_iowait", "cpu_usage_user", "cpu_usage_system" ], "metrics_collection_interval": 60, "resources": [ "*" ], "totalcpu": false }, "disk": { "measurement": [ "used_percent", "inodes_free" ], "metrics_collection_interval": 60, "resources": [ "*" ] }, "diskio": { "measurement": [ "io_time", "write_bytes", "read_bytes", "writes", "reads" ], "metrics_collection_interval": 60, "resources": [ "*" ] }, "mem": { "measurement": [ "mem_used_percent" ], "metrics_collection_interval": 60 }, "netstat": { "measurement": [ "tcp_established", "tcp_time_wait" ], "metrics_collection_interval": 60 }, "statsd": { "metrics_aggregation_interval": 60, "metrics_collection_interval": 10, "service_address": ":8125" }, "swap": { "measurement": [ "swap_used_percent" ], "metrics_collection_interval": 60 } } } } I have enhanced the output of the wizard with some reasonable metrics to collect. The configuration created by the wizard is almost working but it's lacking a fundamental config to make it work out-of-the-box: the collectd_typesdb value. Linux and Mac differ when it comes to the location of collectd and types.db, and the agent defaults to the Linux path even if it was built for Mac, causing the following error when trying to run the agent: ======== Error Log ======== 2023-07-23T04:57:28Z E! [telegraf] Error running agent: Error loading config file /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml: error parsing socket_listener, open /usr/share/collectd/types.db: no such file or directory Moreover, the /usr/share/ folder is not writable unless you disable SIP (System Integrity Protection) which cannot be done on EC2 mac instances nor is something you want to do for security reasons. The final configuration is something you want to save in System Manager Parameter Store using the ssm_parameter resource in Terraform: resource "aws_ssm_parameter" "cw_agent_config_darwin" { name = "/cloudwatch-agent/config/darwin" description = "CloudWatch agent config for mac instances" type = "String" value = file("./cw-agent-config-darwin.json") } and use it when running the agent in a provisioning step: resource "null_resource" "run_cloudwatch_agent" { depends_on = [ aws_instance.mac_instance ] connection { type = "ssh" agent = false host = aws_instance.mac_instance.private_ip user = "ec2-user" private_key = tls_private_key.mac_instance.private_key_pem timeout = "30m" } # Run CloudWatch agent provisioner "remote-exec" { inline = [ "sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c ssm:${aws_ssm_parameter.cw_agent_config_darwin.name}" ] } } Create a CloudWatch dashboard Once the instances are deployed and running, they will send events to CloudWatch and we can create a dashboard to visualise them. You can create a dashboard manually in the console and once you are happy with it, you can just copy the source code, store it in a file and feed it to Terraform. Here is mine that could probably work for you too if you tag your instances with the Type set to macOS: { "widgets": [ { "height": 15, "width": 24, "y": 0, "x": 0, "type": "explorer", "properties": { "metrics": [ { "metricName": "cpu_usage_user", "resourceType": "AWS::EC2::Instance", "stat": "Average" }, { "metricName": "cpu_usage_system", "resourceType": "AWS::EC2::Instance", "stat": "Average" }, { "metricName": "disk_used_percent", "resourceType": "AWS::EC2::Instance", "stat": "Average" }, { "metricName": "diskio_read_bytes", "resourceType": "AWS::EC2::Instance", "stat": "Average" }, { "metricName": "diskio_write_bytes", "resourceType": "AWS::EC2::Instance", "stat": "Average" } ], "aggregateBy": { "key": "", "func": "" }, "labels": [ { "key": "Type", "value": "macOS" } ], "widgetOptions": { "legend": { "position": "bottom" }, "view": "timeSeries", "stacked": false, "rowsPerPage": 50, "widgetsPerRow": 1 }, "period": 60, "splitBy": "", "region": "eu-west-1" } } ] } You can then use the cloudwatch_dashboard resource in Terraform: resource "aws_cloudwatch_dashboard" "mac_instances" { dashboard_name = "mac-instances" dashboard_body = file("./cw-dashboard-mac-instances.json") } It will show something like this: Setup CloudWatch alarms Once the dashboard is up, you should set up alarms so that you are notified of any anomalies, rather than actively monitoring the dashboard for them. What works for me is having alarms triggered via email when the used disk space is going above a certain level (say 80%). We can use the cloudwatch_metric_alarm resource. resource "aws_cloudwatch_metric_alarm" "disk_usage" { alarm_name = "mac-${aws_instance.mac_instance.id}-disk-usage" comparison_operator = "GreaterThanThreshold" evaluation_periods = 30 metric_name = "disk_used_percent" namespace = "CWAgent" period = 120 statistic = "Average" threshold = 80 alarm_actions = [aws_sns_topic.disk_usage.arn] dimensions = { InstanceId = aws_instance.mac_instance.id } } We can then create an SNS topic and subscribe all interested parties to it. This will allow us to broadcast to all subscribers when the alarm is triggered. For this, we can use the sns_topic and sns_topic_subscription resources. resource "aws_sns_topic" "disk_usage" { name = "CW_Alarm_disk_usage_mac_${aws_instance.mac_instance.id}" } resource "aws_sns_topic_subscription" "disk_usage" { for_each = toset(var.alarm_subscriber_emails) topic_arn = aws_sns_topic.disk_usage.arn protocol = "email" endpoint = each.value } variable "alarm_subscriber_emails" { type = list(string) } If you are deploying your infrastructure via GitHub Actions, you can set your subscribers as a workflow input or as an environment variable. Here is how you should pass a list of strings via a variable in Terraform: name: Deploy Mac instance env: ALARM_SUBSCRIBERS: '["user1@example.com","user2@example.com"]' AMI: ... jobs: deploy: ... steps: - name: Terraform apply run: | terraform apply \ --var ami=${{ env.AMI }} \ --var alarm_subscriber_emails='${{ env.ALARM_SUBSCRIBERS }}' \ --auto-approve Setup IAM permissions The instance that performs the deployment requires permissions for CloudWatch, System Manager, and SNS. The following is a policy that is enough to perform both terraform apply and terraform destroy. Please consider restricting to specific resources. { "Version": "2012-10-17", "Statement": [ { "Sid": "CloudWatchDashboardsPermissions", "Effect": "Allow", "Action": [ "cloudwatch:DeleteDashboards", "cloudwatch:GetDashboard", "cloudwatch:ListDashboards", "cloudwatch:PutDashboard" ], "Resource": "*" }, { "Sid": "CloudWatchAlertsPermissions", "Effect": "Allow", "Action": [ "cloudwatch:DescribeAlarms", "cloudwatch:DescribeAlarmsForMetric", "cloudwatch:DescribeAlarmHistory", "cloudwatch:DeleteAlarms", "cloudwatch:DisableAlarmActions", "cloudwatch:EnableAlarmActions", "cloudwatch:ListTagsForResource", "cloudwatch:PutMetricAlarm", "cloudwatch:PutCompositeAlarm", "cloudwatch:SetAlarmState" ], "Resource": "*" }, { "Sid": "SystemsManagerPermissions", "Effect": "Allow", "Action": [ "ssm:GetParameter", "ssm:GetParameters", "ssm:ListTagsForResource", "ssm:DeleteParameter", "ssm:DescribeParameters", "ssm:PutParameter" ], "Resource": "*" }, { "Sid": "SNSPermissions", "Effect": "Allow", "Action": [ "sns:CreateTopic", "sns:DeleteTopic", "sns:GetTopicAttributes", "sns:GetSubscriptionAttributes", "sns:ListSubscriptions", "sns:ListSubscriptionsByTopic", "sns:ListTopics", "sns:SetSubscriptionAttributes", "sns:SetTopicAttributes", "sns:Subscribe", "sns:Unsubscribe" ], "Resource": "*" } ] } On the other hand, to send logs to CloudWatch, the Mac instances require permissions given by the CloudWatchAgentServerPolicy: resource "aws_iam_role_policy_attachment" "mac_instance_iam_role_cw_policy_attachment" { role = aws_iam_role.mac_instance_iam_role.name policy_arn = "arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy" } Conclusion You have now defined your CloudWatch dashboard and alarms using "Infrastructure as Code" via Packer and Terraform. I've covered the common use case of instances running out of space on disk which is useful to catch before CI starts becoming unresponsive slowing your team down.

Overview

Amazon Web Services (AWS) provides EC2 Mac instances commonly used as CI workers. Configuring them can be either a manual or an automated process, depending on the DevOps and Platform Engineering experience in your company. No matter what process you adopt, it is sometimes useful to log into the

Overview Amazon Web Services (AWS) provides EC2 Mac instances commonly used as CI workers. Configuring them can be either a manual or an automated process, depending on the DevOps and Platform Engineering experience in your company. No matter what process you adopt, it is sometimes useful to log into the instances to investigate problems. EC2macConnector is a CLI tool written in Swift that simplifies the process of connecting over SSH and VNC for DevOps engineers, removing the need of updating private keys and maintaining the list of IPs that change across deployment cycles. Connecting to EC2 Mac instances without EC2macConnector AWS documentation describes the steps needed to allow connecting via VNC: Start the Apple Remote Desktop agent and enable remote desktop access on the instance Set the password for the ec2-user user on the instance to allow connecting over VNC Start an SSH session Connect over VNC Assuming steps 1 and 2 and done, steps 3 and 4 are usually manual and repetitive: the private keys and IPs usually change across deployments which could happen frequently, even daily. Here is how to start an SSH session in the terminal binding a port locally: ssh ec2-user@<instance_IP> \ -L <local_port>:localhost:5900 \ -i <path_to_privae_key> \ To connect over VNC you can type the following in Finder → Go → Connect to Server (⌘ + K) and click Connect: vnc://ec2-user@localhost:<local_port> or you could create a .vncloc file with the following content and simply open it: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "<http://www.apple.com/DTDs/PropertyList-1.0.dtd>"> <plist version="1.0"> <dict> <key>URL</key> <string>vnc://ec2-user@localhost:<local_port></string> </dict> </plist> If you are a system administrator, you might consider EC2 Instance Connect, but sadly, in my experience, it's not a working option for EC2 Mac instances even though I couldn't find evidence confirming or denying this statement. Administrators could also consider using Apple Remote Desktop which comes with a price tag of $/£79.99. Connecting to EC2 Mac instances with EC2macConnector EC2macConnector is a simple and free tool that works in 2 steps: the configure command fetches the private keys and the IP addresses of the running EC2 Mac instances in a given region, and creates files using the said information to connect over SSH and VNC: ec2macConnector configure \ --region <aws_region> \ --secrets-prefix <mac_metal_private_keys_prefix> Read below or the README for more information on the secrets prefix value. the connect command connects to the instances via SSH or VNC. ec2macConnector connect --region <aws_region> <fleet_index> ec2macConnector connect --region <aws_region> <fleet_index> --vnc 💡 Connecting over VNC requires an SSH session to be established first. As with any tool written using ArgumentParser, use the --help flag to get more information. Requirements There are some requirements to respect for the tool to work: Permissions EC2macConnector requires AWS credentials either set as environment variables (AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY) or configured in ~/.aws/credentials via the AWS CLI. Environment variables take precedence. The user must be granted the following permissions: ec2:DescribeInstances secretsmanager:ListSecrets secretsmanager:GetSecretValue EC2 instances The EC2 Mac instances must have the EC2macConnector:FleetIndex tag set to the index of the instance in the fleet. Indexes should start at 1. Instances that don't have the said tag will be ignored. Secrets and key pairs formats EC2macConnector assumes that the private key for each instance key pair is stored in SecretsManagers. The name of the key pair could and should be different from the secret ID. For example, the instance key pair should include an incremental number also part of the corresponding secret ID. Consider that the number of Mac instances in an AWS account is limited and it's convenient to refer to them using an index starting at 1. It's good practice for the secret ID to also include a nonce as secrets with the same name cannot be recreated before the deletion period has elapsed, allowing frequent provisioning-decommissioning cycles. For the above reasons, EC2macConnector assumes the following formats are used: instance key pairs: <keypair_prefix>_<index_of_instance_in_fleet> e.g. mac_instance_key_pair_5 secret IDs: <secrets_prefix>_<index_of_instance_in_fleet>_<nonce> e.g. private_key_mac_metal_5_dx9Wna73B EC2macConnector Under the hood The configure command: downloads the private keys in the ~/.ssh folder creates scripts to connect over SSH in ~/.ec2macConnector/<region>/scripts creates vncloc files to connect over VNC in ~/.ec2macConnector/<region>/vnclocs ➜ .ec2macConnector tree ~/.ssh /Users/alberto/.ssh ├── mac_metal_1_i-08e4ffd8e9xxxxxxx ├── mac_metal_2_i-07bfff1f52xxxxxxx ├── mac_metal_3_i-020d680610xxxxxxx ├── mac_metal_4_i-08516ac980xxxxxxx ├── mac_metal_5_i-032bedaabexxxxxxx ├── config ├── known_hosts └── ... The connect command: runs the scripts (opens new shells in Terminal and connects to the instances over SSH) opens the vncloc files ➜ .ec2macConnector tree ~/.ec2macConnector /Users/alberto/.ec2macConnector └── us-east-1 ├── scripts │   ├── connect_1.sh │   ├── connect_2.sh │   ├── connect_3.sh │   ├── connect_4.sh │   └── connect_5.sh └── vnclocs ├── connect_1.vncloc ├── connect_2.vncloc ├── connect_3.vncloc ├── connect_4.vncloc └── connect_5.vncloc

I previously wrote about JustTweak here. It's the feature flagging mechanism we've been using at Just Eat Takeaway.com to power the iOS consumer apps since 2017. It's proved to be very stable and powerful and it has evolved over time. Friends have heard

I previously wrote about JustTweak here. It's the feature flagging mechanism we've been using at Just Eat Takeaway.com to power the iOS consumer apps since 2017. It's proved to be very stable and powerful and it has evolved over time. Friends have heard me promoting it vehemently and some have integrated it with success and appreciation. I don't think I've promoted it in the community enough (it definitely deserved more) but marketing has never been my thing. Anyway, JustTweak grew old and some changes were debatable and not to my taste. I have then decided to use the knowledge of years of working on the feature flagging matter to give this project a new life by rewriting it from scratch as a personal project. And here it is: Toggles. I never tweeted about this side project of mine 😜 It's like JustTweak (feature flagging), but sensibly better. https://t.co/bdGWuUyQEU #Swift #iOS #macOS — Alberto De Bortoli (@albertodebo) March 23, 2023 Think of JustTweak, but better. A lot better. Frankly, I couldn't have written it better. Here are the main highlights: brand new code, obsessively optimized and kept as short and simple as possible extreme performances fully tested fully documented performant UI debug view in SwiftUI standard providers provided demo app provided ability to listen for value changes (using Combine) simpler APIs ToggleGen CLI, to allow code generation ToggleCipher CLI, to allow encoding/decoding of secrets JustTweakMigrator CLI, to allow a smooth transition from JustTweak Read all about it on the repo's README and on the DocC page. It's on Swift Package Index too. Toggles – Swift Package Index Toggles by TogglesPlatform on the Swift Package Index – Toggles is an elegant and powerful solution to feature flagging for Apple platforms. Learn more There are plans (or at least the desire!) to write a backend with Andrea Scuderi. That'd be really nice! @albertodebo This wasn't planned! It looks like we need to build the backend for #Toggles with #Breeze! pic.twitter.com/OxNovRl70L — andreascuderi (@andreascuderi13) March 26, 2023

In this article, we’ll discuss the way our mobile teams have evolved the Continuous Integration (CI) stack over the recent years.

Originally published on the Just Eat Takeaway Engineering Blog. Overview In this article, we’ll discuss the way our mobile teams have evolved the Continuous Integration (CI) stack over the recent years. We don’t have DevOps engineers in our team and, until recently, we had adopted a singular approach in which CI belongs to the whole team and everyone should be able to maintain it. This has proven to be difficult and extremely time-consuming. The Just Eat side of our newly merged entity has a dedicated team providing continuous integration and deployment tools to their teams but they are heavily backend-centric and there has been little interest in implementing solutions tailored for mobile teams. As is often the case in tech companies, there is a missing link between mobile and DevOps teams. The iOS team is the author and first consumer of the solution described but, as you can see, we have ported the same stack to Android as well. We will mainly focus on the iOS implementation in this article, with references to Android as appropriate. 2016–2020 Historically speaking, the iOS UK app was running on Bitrise because it was decided not to invest time in implementing a CI solution, while the Bristol team was using a Jenkins version installed by a different team. This required manual configuration with custom scripts and it had custom in-house hardware. These are two quite different approaches indeed and, at this stage, things were not great but somehow good enough. It’s fair to say we were still young on the DevOps front. When we merged the teams, it was clear that we wanted to unify the CI solution and the obvious choice for a company of our size was to not use a third-party service, bringing us to invest more and more in Jenkins. Only one team member had good knowledge of Jenkins but the rest of the team showed little interest in learning how to configure and maintain it, causing the stack to eventually become a dumping ground of poorly configured jobs. It was during this time that we introduced Fastlane (making the common tasks portable), migrated the UK app from Bitrise to Jenkins, started running the UI tests on Pull Requests, and other small yet sensible improvements. 2020–2021 Starting in mid-2020 the iOS team has significantly revamped its CI stack and given it new life. The main goals we wanted to achieve (and did by early 2021) were: Revisit the pipelines Clear Jenkins configuration and deployment strategy Make use of AWS Mac instances Reduce the pool size of our mac hardware Share our knowledge across teams better Since the start of the pandemic, we have implemented the pipelines in code (bidding farewell to custom bash scripts), we moved to a monorepo which was a massive step ahead and began using SonarQube even more aggressively. We added Slack reporting and PR Assigner, an internal tool implemented by Andrea Antonioni. We also automated the common release tasks such as cutting and completing a release and uploading the dSYMS to Firebase. We surely invested a lot in optimizing various aspects such as running the UI tests in parallel, making use of shallow repo cloning, We also moved to not checking in the pods within the repo. This, eventually, allowed us to reduce the number of agents for easier infrastructure maintenance. Automating the infrastructure deployment of Jenkins was a fundamental shift compared to the previous setup and we have introduced AWS Mac instances replacing part of the fleet of our in-house hardware. CI system setup Let’s take a look at our stack. Before we start, we’d like to thank Isham Araia for having provided a proof of concept for the configuration and deployment of Jenkins. He talked about it at https://ish-ar.io/jenkins-at-scale/ and it represented a fundamental starting point, saving us several days of researching. Triggering flow Starting from the left, we have our repositories (plural, as some shared dependencies don’t live in the monorepo). The repositories contain the pipelines in the form of Jenkinsfiles and they call into Fastlane lanes. Pretty much every action is a lane, from running the tests to archiving for the App Store to creating the release branches. Changes are raised through pull requests that trigger Jenkins. There are other ways to trigger Jenkins: by user interaction (for things such as completing a release or archiving and uploading the app to App Store Connect) and cron triggers (for things such as building the nightly build, running the tests on the develop branch every 12 hours, or uploading the PACT contract to the broker). Once Jenkins has received the information, it will then schedule the jobs to one of the agents in our pool, which is now made up of 5 agents, 2 in the cloud and 3 in-house mac pros. Reporting flow Now that we’ve talked about the first part of the flow, let’s talk about the flow of information coming back at us. Every PR triggers PR Assigner, a tool that works out a list of reviewers to assign to pull requests and notifies engineers via dedicated Slack channels. The pipelines post on Slack, providing info about all the jobs that are being executed so we can read the history without having to log into Jenkins. We have in place the standard notification flow from Jenkins to GitHub to set the status checks and Jenkins also notifies SonarQube to verify that any change meets the quality standards (namely code coverage percentage and coding rules). We also have a smart lambda named SonarQubeStatusProcessor that reports to GitHub, written by Alan Nichols. This is due to a current limitation of SonarQube, which only allows reporting the status of one SQ project to one GitHub repo. Since we have a monorepo structure we had to come up with this neat customization to report the SQ status for all the modules that have changed as part of the PR. Configuration Let’s see what the new interesting parts of Jenkins are. Other than Jenkins itself and several plugins, it’s important to point out JCasC and Job DSL. JCasC stands for Jenkins Configuration as Code, and it allows you to configure Jenkins via a yaml file. The point here is that nobody should ever touch the Jenkins settings directly from the configuration page, in the same way, one ideally shouldn’t apply configuration changes manually in any dashboard. The CasC file is where we define the Slack integration, the user roles, SSO configuration, the number of agents and so on. We could also define the jobs in CasC but we go a step further than that. We use the Job DSL plugin that allows you to configure the jobs in groovy and in much more detail. One job we configure in the CasC file though is the seed job. This is a simple freestyle job that will go pick the jobs defined with Job DSL and create them in Jenkins. Deployment Let’s now discuss how we can get a configured Jenkins instance on EC2. In other words, how do we deploy Jenkins? We use a combination of tools that are bread and butter for DevOps people. The commands on the left spawn a Docker container that calls into the tools on the right. We start with Packer which allows us to create the AMI (Amazon Machine Image) together with Ansible, allowing us to configure an environment easily (much more easily than Chef or Puppet). Running the create-image command the script will: 1. Create a temporary EC2 instance 2. Connect to the instance and execute an ansible playbook Our playbook encompasses a number of steps, here’s a summary: install the Jenkins version for the given Linux distribution install Nginx copy the SSL cert over configure nginx w/ SSL termination and reverse proxy install the plugins for Jenkins Once the playbook is executed, Packer will export an AMI in EC2 with all of this in it and destroy the instance that was used. With the AMI ready, we can now proceed to deploy our Jenkins. For the actual deployment, we use Terraform which allows us to define our infrastructure in code. The deploy command runs Terraform under the hood to set up the infrastructure, here’s a summary of the task: create an IAM Role + IAM Policy configure security groups create the VPC and subnet to use with a specific CIDER block and the subnet create any private key pair to connect over SSH deploy the instance using a static private IP (it has to be static otherwise the A record in Route53 would break) copy the JCasC configuration file over so that when Jenkins starts it picks that up to configure itself The destroy command runs a “terraform destroy” and destroys everything that was created with the deploy command. Deploy and destroy balance each other out. Now that we have Jenkins up and running, we need to give it some credentials so our pipelines are able to work properly. A neat way of doing this is by having the secrets (SSH keys, Firebase tokens, App Store Connect API Key and so forth) in AWS Secrets Manager which is based on KMS and use a Jenkins plugin to allow Jenkins to access them. It’s important to note that developers don’t have to install Packer, Ansible, Terraform or even the AWS CLI locally because the commands run a Docker container that does the real work with all the tools installed. As a result, the only thing one should have installed is really Docker. CI agents Enough said about Jenkins, it’s time to talk about the agents.As you probably already know, in order to run tests, compile and archive iOS apps we need Xcode, which is only available on macOS, so Linux or Windows instances are not going to cut it. We experimented with the recently introduced AWS Mac instances and they are great, ready out-of-the-box with minimal configuration on our end. What we were hoping to get to with this recent work was the ability to leverage the Jenkins Cloud agents. That would have been awesome because it would have allowed us to: let Jenkins manage the agent instances scale the agent pool according to the load on CI Sadly we couldn't go that far. Limitations are: the bootstrapping of a mac1.metal takes around 15 minutes reusing the dedicated host after having stopped an instance can take up to 3 hours — during that time we just pay for a host that is not usable When you stop or terminate a Mac instance, Amazon EC2 performs a scrubbing workflow on the underlying Dedicated Host to erase the internal SSD, to clear the persistent NVRAM variables, and if needed, to update the bridgeOS software on the underlying Mac mini. This ensures that Mac instances provide the same security and data privacy as other EC2 Nitro instances. It also enables you to run the latest macOS AMIs without manually updating the bridgeOS software. During the scrubbing workflow, the Dedicated Host temporarily enters the pending state. If the bridgeOS software does not need to be updated, the scrubbing workflow takes up to 50 minutes to complete. If the bridgeOS software needs to be updated, the scrubbing workflow can take up to 3 hours to complete. Source: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-mac-instances.html In other words: scaling mac instances is not an option and leaving the instances up 24/7 seems to be the easiest option. This is especially valid if your team is distributed and jobs could potentially run over the weekend as well, saving you the hassle of implementing downscaling ahead of the weekend. There are some pricing and instance allocation considerations to make. Note that On-Demand Mac1 Dedicated Hosts have a minimum host allocation and billing duration of 24 hours. “You can purchase Savings Plans to lower your spend on Dedicated Hosts. Savings Plans is a flexible pricing model that provides savings of up to 72% on your AWS compute usage. This pricing model offers lower prices on Amazon EC2 instances usage, regardless of instance family, size, OS, tenancy or AWS Region.” Source: https://aws.amazon.com/ec2/dedicated-hosts/pricing/ The On-Demand rate is $1.207 per hour. I’d like to stress that no CI solution comes for free. I’ve often heard developers indicating that Travis and similar products are cheaper. The truth is that the comparison is not even remotely reasonable: virtual boxes are incredibly slow compared to native Apple hardware and take ridiculous bootstrapping times. Even the smallest projects suffer terribly. One might ask if it’s at least possible to use the same configuration process we used for the Jenkins instance (with Packer and Ansible) but sadly we hit additional limitations: Apple requires 2FA for downloading Xcode via xcode-version Apple requires 2FA for signing into Xcode The above pretty much causes the configuration flow to fall apart making it impossible to configure an instance via Ansible. Cloud agents for Android It was a different story for Android, in which we could easily configure the agent instance with Ansible and therefore leverage the Cloud configuration to allow automatic agent provisioning. This configuration is defined via CasC as everything else. To better control EC2 usage and costs, a few settings come in handy: minimum number of instances (up at all times) minimum number of spare instances (created to accommodate future jobs) instance cap: the maximum number of instances that can be provisioned at the same time idle termination time: how long agents should be kept alive after they have completed the job All of the above allow for proper scaling and a lot less maintenance compared to the iOS setup. A simple setup with 0 instances up at all times allows saving costs overnight and given that in our case the bootstrapping takes only 2 minutes, we can rely on the idle time setting. Conclusions Setting up an in-house CI is never a straightforward process and it requires several weeks of dedicated work. After years of waiting, Apple has announced Xcode Cloud which we believe will drastically change the landscape of continuous integration on iOS. The solution will most likely cause havoc for companies such as Bitrise and CircleCI and it’s reasonable to assume the pricing will be competitive compared to AWS, maybe running on custom hardware that only Apple is able to produce. A shift this big will take time to occur, so we foresee our solution to stay in use for quite some time. We hope to have inspired you on how a possible setup for mobile teams could be and informed you on what are the pros & cons of using EC2 mac instances.

We have presented our modular iOS architecture in a previous article and I gave a talk at Swift Heroes 2020 about it. In this article, we’ll analyse the challenges we faced to have the modular architecture integrated with our CI pipelines and the reasoning behind migrating to a monorepo.

Originally published on the Just Eat Takeaway Engineering Blog. We have presented our modular iOS architecture in a previous article and I gave a talk at Swift Heroes 2020 about it. In this article, we’ll analyse the challenges we faced to have the modular architecture integrated with our CI pipelines and the reasoning behind migrating to a monorepo. The Problem Having several modules in separate repositories brings forward 2 main problems: Each module is versioned independently from the consuming app Each change involves at least 2 pull requests: 1 for the module and 1 for the integration in the app While the above was acceptable in a world where we had 2 different codebases, it soon became unnecessarily convoluted after we migrated to a new, global codebase. New module versions are implemented with the ultimate goal of being adopted by the only global codebase in use, making us realise we could simplify the change process. The monorepo approach has been discussed at length by the community for a few years now. Many talking points have come out of these conversations, even leading to an interesting story as told by Uber. In short, it entails putting all the code owned by the team in a single repository, precisely solving the 2 problems stated above. Monorepo structure The main advantage of a monorepo is a streamlined PR process that doesn’t require us to raise multiple PRs, de facto reducing the number of pull requests to one. It also simplifies the versioning, allowing module and app code (ultimately shipped together) to be aligned using the same versioning. The first step towards a monorepo was to move the content of the repositories of the modules to the main app repo (we’ll call it “monorepo” from now on). Since we rely on CocoaPods, the modules would be consumed as development pods. Here’s a brief summary of the steps used to migrate a module to the monorepo: Inform the relevant teams about the upcoming migration Make sure there are no open PRs in the module repo Make the repository read-only and archive it Copy the module to the Modules folder of the monorepo (it’s possible to merge 2 repositories to keep the history but we felt we wanted to keep the process simple, the old history is still available in the old repo anyway) Delete the module .git folder (or it would cause a git submodule) Remove Gemfile and Gemfile.lock fastlane folder, .gitignore file, sonar-project.properties, .swiftlint.yml so to use those in the monorepo Update the monorepo’s CODEOWNERS file with the module codeowners Remove the .github folder Modify the app Podfile to point to the module as a dev pod and install it Make sure all the modules’ demo apps in the monorepo refer to the new module as a dev pod (if they depend on it at all). The same applies to the module under migration. Delete the CI jobs related to the module Leave the podspecs in the private Specs repo (might be needed to build old versions of the app) The above assumes that CI is configured in a way that preserves the same integration steps upon a module change. We’ll discuss them later in this article. Not all the modules could be migrated to the monorepo, due to the fact the second-level dependencies need to live in separate repositories in order to be referenced in the podspec of a development pod. If not done correctly, CocoaPods will not be able to install them. We considered moving these dependencies to the monorepo whilst maintaining separate versioning, however, the main problem with this approach is that the version tags might conflict with the ones of the app. Even though CocoaPods supports tags that don’t respect semantic versioning (for example prepending the tag with the name of the module), violating it just didn’t feel right. EDIT: we’ve learned that it’s possible to move such dependencies to the monorepo. This is done not by defining :path=> in the podspecs but instead by doing so in the Podfile of the main app, which is all Cocoapods needs to work out the location of the dependency on disk. Swift Package Manager considerations We investigated the possibility of migrating from CocoaPods to Apple’s Swift Package Manager. Unfortunately, when it comes to handling the equivalent of development pods, Swift Package Manager really falls down for us. It turns out that Swift Package Manager only supports one package per repo, which is frustrating because the process of working with editable packages is surprisingly powerful and transparent. Version pinning rules While development pods don’t need to be versioned, other modules still need to. This is either because of their open-source nature or because they are second-level dependencies (referenced in other modules’ podspecs). Here’s a revised overview of the current modular architecture in 2021. We categorised our pods to better clarify what rules should apply when it comes to version pinning both in the Podfiles and in the podspecs. Open-Source pods Our open-source repositories on github.com/justeat are only used by the app. Examples: JustTweak, AutomationTools, Shock Pinning in other modules’ podspec: NOT APPLICABLE open-source pods don’t appear in any podspec, those that do are called ‘open-source shared’ Pinning in other modules’ Podfile (demo apps): PIN (e.g. AutomationTools in Orders demo app’s Podfile) Pinning in main app’s Podfile: PIN (e.g. AutomationTools) Open-Source shared pods The Just Eat pods we put open-source on github.com/justeat and are used by modules and apps. Examples: JustTrack, JustLog, ScrollingStackViewController, ErrorUtilities Pinning in other modules’ podspec: PIN w/ optimistic operator (e.g. JustTrack in Orders) Pinning in other modules’ Podfile (demo apps): PIN (e.g. JustTrack in Orders demo app’s Podfile) Pinning in main app’s Podfile: DON’T LIST latest compatible version is picked by CocoaPods (e.g. JustTrack). LIST & PIN if the pod is explicitly used in the app too, so we don’t magically inherit it. Internal Domain pods Domain modules (yellow). Examples: Orders, SERP, etc. Pinning in other modules’ podspec: NOT APPLICABLE domain pods don’t appear in other pods’ podspecs (domain modules don’t depend on other domain modules) Pinning in other modules’ Podfile (demo apps): PIN only if the pod is used in the app code, rarely the case (e.g. Account in Orders demo app’s Podfile) Pinning in main app’s Podfile: PIN (e.g. Orders) Internal Core pods Core modules (blue) minus those open-source. Examples: APIClient, AssetProvider Pinning in other modules’ podspec: NOT APPLICABLE core pods don’t appear in other pods’ podspecs (core modules are only used in the app(s)) Pinning in other modules’ Podfile (demo apps): PIN only if pod is used in the app code (e.g. APIClient in Orders demo app’s Podfile) Pinning in main app’s Podfile: PIN (e.g. NavigationEngine) Internal shared pods Shared modules (green) minus those open-source. Examples: JustUI, JustAnalytics Pinning in other modules’ podspec: DON’T PIN (e.g. JustUI in Orders podspec) Pinning in other modules’ Podfile (demo apps): PIN (e.g. JustUI in Orders demo app’s Podfile) Pinning in main app’s Podfile: PIN (e.g. JustUI) External shared pods Any non-Just Eat pod used by any internal or open-source pod. Examples: Usabilla, SDWebImage Pinning in other modules’ podspec: PIN (e.g. Usabilla in Orders) Pinning in other modules’ Podfile (demo apps): DON’T LIST because the version is forced by the podspec. LIST & PIN if the pod is explicitly used in the app too, so we don’t magically inherit it. Pinning is irrelevant but good practice. Pinning in main app’s Podfile: DON’T LIST because the version is forced by the podspec(s). LIST & PIN if the pod is explicitly used in the app too, so we don’t magically inherit it. Pinning is irrelevant but good practice. External pods Any non-Just Eat pod used by the app only. Examples: Instabug, GoogleAnalytics Pinning in other modules’ podspec: NOT APPLICABLE external pods don’t appear in any podspec, those that do are called ‘external shared’ Pinning in other modules’ Podfile (demo apps): PIN only if the pod is used in the app code, rarely the case (e.g. Promis) Pinning in main app’s Podfile: PIN (e.g. Adjust) Pinning is a good solution because it guarantees that we always build the same software regardless of new released versions of dependencies. It’s also true that pinning every dependency all the time makes the dependency graph hard to keep updated. This is why we decided to allow some flexibility in some cases. Following is some more reasoning. Open-source For “open-source shared” pods, we are optimistic enough (pun intended) to tolerate the usage of the optimistic operator ~> in podspecs of other pods (i.e Orders using JustTrack) so that when a new patch version is released, the consuming pod gets it for free upon running pod update. We have control over our code and, by respecting semantic versioning, we guarantee the consuming pod to always build. In case of new minor or major versions, we would have to update the podspecs of the consuming pods, which is appropriate. Also, we do need to list any “open-source shared” pod in the main app’s Podfile only if directly used by the app code. External We don’t have control over the “external” and “external shared” pods, therefore we always pin the version in the appropriate place. New patch versions might not respect semantic versioning for real and we don’t want to pull in new code unintentionally. As a rule of thumb, we prefer injecting external pods instead of creating a dependency in the podspec. Internal Internal shared pods could change frequently (not as much as domain modules). For this reason, we’ve decided to relax a constraint we had and not to pin the version in the podspec. This might cause the consuming pod to break when a new version of an “internal shared” pod is released and we run pod update. This is a compromise we can tolerate. The alternative would be to pin the version causing too much work to update the podspec of the domain modules. Continuous Integration changes With modules in separate repositories, the CI was quite simply replicating the same steps for each module: install pods run unit tests run UI tests generated code coverage submit code coverage to SonarQube Moving the modules to the monorepo meant creating smart CI pipelines that would run the same steps upon modules’ changes. If a pull request is to change only app code, there is no need to run any step for the modules, just the usual steps for the app: If instead, a pull request applies changes to one or more modules, we want the pipeline to first run the steps for the modules, and then the steps for the app: Even if there are no changes in the app code, module changes could likely impact the app behaviour, so it’s important to always run the app tests. We have achieved the above setup through constructing our Jenkins pipelines dynamically. The solution should scale when new modules are added to the monorepo and for this reason, it’s important that all modules: respect the same project setup (generated by CocoaPods w/ the pod lib create command) use the same naming conventions for the test schemes (UnitTests/ContractTests/UITests) make use of Apple Test Plans are in the same location ( ./Modules/ folder). Following is an excerpt of the code that constructs the modules’ stages from the Jenkinsfile used for pull request jobs. scripts = load "./Jenkins/scripts/scripts.groovy" def modifiedModules = scripts.modifiedModulesFromReferenceBranch(env.CHANGE_TARGET) def modulesThatNeedUpdating = scripts.modulesThatNeedUpdating(env.CHANGE_TARGET) def modulesToRun = (modulesThatNeedUpdating + modifiedModules).unique() sh "echo \"List of modules modified on this branch: ${modifiedModules}\"" sh "echo \"List of modules that need updating: ${modulesThatNeedUpdating}\"" sh "echo \"Pipeline will run the following modules: ${modulesToRun}\"" for (int i = 0; i < modulesToRun.size(); ++i) { def moduleName = modulesToRun[i] stage('Run pod install') { sh "bundle exec fastlane pod_install module:${moduleName}" } def schemes = scripts.testSchemesForModule(moduleName) schemes.each { scheme -> switch (scheme) { case "UnitTests": stage("${moduleName} Unit Tests") { sh "bundle exec fastlane module_unittests \ module_name:${moduleName} \ device:'${env.IPHONE_DEVICE}'" } stage("Generate ${moduleName} code coverage") { sh "bundle exec fastlane generate_sonarqube_coverage_xml" } stage("Submit ${moduleName} code coverage to SonarQube") { sh "bundle exec fastlane sonar_scanner_pull_request \ component_type:'module' \ source_branch:${env.BRANCH_NAME} \ target_branch:${env.CHANGE_TARGET} \ pull_id:${env.CHANGE_ID} \ project_key:'ios-${moduleName}' \ project_name:'iOS ${moduleName}' \ sources_path:'./Modules/${moduleName}/${moduleName}'" } break; case "ContractTests": stage('Install pact mock service') { sh "bundle exec fastlane install_pact_mock_service" } stage("${moduleName} Contract Tests") { sh "bundle exec fastlane module_contracttests \ module_name:${moduleName} \ device:'${env.IPHONE_DEVICE}'" } break; case "UITests": stage("${moduleName} UI Tests") { sh "bundle exec fastlane module_uitests \ module_name:${moduleName} \ number_of_simulators:${env.NUMBER_OF_SIMULATORS} \ device:'${env.IPHONE_DEVICE}'" } break; default: break; } } } and here are the helper functions to make it all work: def modifiedModulesFromReferenceBranch(String referenceBranch) { def script = "git diff --name-only remotes/origin/${referenceBranch}" def filesChanged = sh script: script, returnStdout: true Set modulesChanged = [] filesChanged.tokenize("\n").each { def components = it.split('/') if (components.size() > 1 && components[0] == 'Modules') { def module = components[1] modulesChanged.add(module) } } return modulesChanged } def modulesThatNeedUpdating(String referenceBranch) { def modifiedModules = modifiedModulesFromReferenceBranch(referenceBranch) def allModules = allMonorepoModules() def modulesThatNeedUpdating = [] for (module in allModules) { def podfileLockPath = "Modules/${module}/Example/Podfile.lock" def dependencies = podfileDependencies(podfileLockPath) def dependenciesIntersection = dependencies.intersect(modifiedModules) as TreeSet Boolean moduleNeedsUpdating = (dependenciesIntersection.size() > 0) if (moduleNeedsUpdating == true && modifiedModules.contains(module) == false) { modulesThatNeedUpdating.add(module) } } return modulesThatNeedUpdating } def podfileDependencies(String podfileLockPath) { def dependencies = [] def fileContent = readFile(file: podfileLockPath) fileContent.tokenize("\n").each { line -> def lineComponents = line.split('\\(') if (lineComponents.length > 1) { def dependencyLineSubComponents = lineComponents[0].split('-') if (dependencyLineSubComponents.length > 1) { def moduleName = dependencyLineSubComponents[1].trim() dependencies.add(moduleName) } } } return dependencies } def allMonorepoModules() { def modulesList = sh script: "ls Modules", returnStdout: true return modulesList.tokenize("\n").collect { it.trim() } } def testSchemesForModule(String moduleName) { def script = "xcodebuild -project ./Modules/${moduleName}/Example/${moduleName}.xcodeproj -list" def projectEntitites = sh script: script, returnStdout: true def schemesPart = projectEntitites.split('Schemes:')[1] def schemesPartLines = schemesPart.split(/\n/) def trimmedLined = schemesPartLines.collect { it.trim() } def filteredLines = trimmedLined.findAll { !it.allWhitespace } def allowedSchemes = ['UnitTests', 'ContractTests', 'UITests'] def testSchemes = filteredLines.findAll { allowedSchemes.contains(it) } return testSchemes } You might have noticed the modulesThatNeedUpdating method in the code above. Each module comes with a demo app using the dependencies listed in its Podfile and it’s possible that other monorepo modules are listed there as development pods. This not only means that we have to run the steps for the main app, but also the steps for every module consuming modules that show changes. For example, the Orders demo app uses APIClient, meaning that pull requests with changes in APIClient will generate pipelines including the Orders steps. Pipeline parallelization Something we initially thought was sensible to consider is the parallelisation of the pipelines across different nodes. We use parallelisation for the release pipelines and learned that, while it seems to be a fundamental requirement at first, it soon became apparent not to be so desirable nor truly fundamental for the pull requests pipeline. We’ll discuss our CI setup in a separate article, but suffice to say that we have aggressively optimized it and managed to reduce the agent pool from 10 to 5, still maintaining a good level of service. Parallelisation sensibly complicates the Jenkinsfiles and their maintainability, spreads the cost of checking out the repository across nodes and makes the logs harder to read. The main benefit would come from running the app UI tests on different nodes. In the WWDC session 413, Apple recommends generating the .xctestrun file using the build-for-testing option in xcodebuild and distribute it across the other nodes. Since our app is quite large, such file is also large and transferring it has its costs, both in time and bandwidth usage. All things considered, we decided to keep the majority of our pipelines serial. EDIT: In 2022 we have parallelised our PR pipeline in 4 branches: Validation steps (linting, Fastlane lanes tests, etc.) App unit tests App UI tests (short enough that there's no need to share .xctestrun across nodes) Modified modules unit tests Modified modules UI tests Conclusions We have used the setup described in this article since mid-2020 and we are very satisfied with it. We discussed the pipeline used for the pull requests which is the most relevant one when it comes to embracing a monorepo structure. We have a few more pipelines for various use cases, such as verifying changes in release branches, keeping the code coverage metrics up-to-date with jobs running of triggers, archiving the app for internal usage and for App Store. We hope to have given you some useful insights on how to structure a monorepo and its CI pipelines, especially if you have a structure similar to ours.

Problem

I wrote the first version of iHarmony in 2008. It was the very first iOS app I gave birth to, combining my passion for music and programming. I remember buying an iPhone and my first Mac with the precise purpose of jumping on the apps train at a time

Problem I wrote the first version of iHarmony in 2008. It was the very first iOS app I gave birth to, combining my passion for music and programming. I remember buying an iPhone and my first Mac with the precise purpose of jumping on the apps train at a time when it wasn't clear if the apps were there to stay or were just a temporary hype. But I did it, dropped my beloved Ubuntu to join a whole new galaxy. iHarmony was also one of the first 2000 apps on the App Store. Up until the recent rewrite, iHarmony was powered by a manually crafted database containing scales, chords, and harmonization I inputted. What-a-shame! I guess it made sense, I wanted to learn iOS and not to focus on implementing some core logic independent from the platform. Clearly a much better and less error-prone way to go would be to implement an algorithm to generate all the entries based on some DSL/spec. It took me almost 12 years to decide to tackle the problem and I've recently realized that writing the algorithm I wanted was harder than I thought. Also thought was a good idea give SwiftUI a try since the UI of iHarmony is extremely simple but... nope. Since someone on the Internet expressed interest 😉, I wrote this article to explain how I solved the problem of modeling music theory concepts in a way that allows the generation of any sort of scales, chords, and harmonization. I only show the code needed to get a grasp of the overall structure. I know there are other solutions ready to be used on GitHub but, while I don't particularly like any of them, the point of rewriting iHarmony from scratch was to challenge myself, not to reuse code someone else wrote. Surprisingly to me, getting to the solution described here took me 3 rewrites and 2 weeks. Solution The first fundamental building blocks to model are surely the musical notes, which are made up of a natural note and an accidental. enum NaturalNote: String { case C, D, E, F, G, A, B } enum Accidental: String { case flatFlatFlat = "bbb" case flatFlat = "bb" case flat = "b" case natural = "" case sharp = "#" case sharpSharp = "##" case sharpSharpSharp = "###" func applyAccidental(_ accidental: Accidental) throws -> Accidental {...} } struct Note: Hashable, Equatable { let naturalNote: NaturalNote let accidental: Accidental ... static let Dff = Note(naturalNote: .D, accidental: .flatFlat) static let Df = Note(naturalNote: .D, accidental: .flat) static let D = Note(naturalNote: .D, accidental: .natural) static let Ds = Note(naturalNote: .D, accidental: .sharp) static let Dss = Note(naturalNote: .D, accidental: .sharpSharp) ... func noteByApplyingAccidental(_ accidental: Accidental) throws -> Note {...} } Combinations of notes make up scales and chords and they are... many. What's fixed instead in music theory, and therefore can be hard-coded, are the keys (both major and minor) such as: C major: C, D, E, F, G, A, B A minor: A, B, C, D, E, F, G D major: D, E, F#, G, A, B, C# We'll get back to the keys later, but we can surely implement the note sequence for each musical key. typealias NoteSequence = [Note] extension NoteSequence { static let C = [Note.C, Note.D, Note.E, Note.F, Note.G, Note.A, Note.B] static let A_min = [Note.A, Note.B, Note.C, Note.D, Note.E, Note.F, Note.G] static let G = [Note.G, Note.A, Note.B, Note.C, Note.D, Note.E, Note.Fs] static let E_min = [Note.E, Note.Fs, Note.G, Note.A, Note.B, Note.C, Note.D] ... } Next stop: intervals. They are a bit more interesting as not every degree has the same types. Let's split into 2 sets: 2nd, 3rd, 6th and 7th degrees can be minor, major, diminished and augmented 1st (and 8th), 4th and 5th degrees can be perfect, diminished and augmented. We need to use different kinds of "diminished" and "augmented" for the 2 sets as later on we'll have to calculate the accidentals needed to turn an interval into another. Some examples: to get from 2nd augmented to 2nd diminished, we need a triple flat accidental (e.g. in C major scale, from D♯ to D♭♭ there are 3 semitones) to get from 5th augmented to 5th diminished, we need a double flat accidental (e.g. in C major scale, from G♯ to G♭there are 2 semitones) We proceed to hard-code the allowed intervals in music, leaving out the invalid ones (e.g. Interval(degree: ._2, type: .augmented)) enum Degree: Int, CaseIterable { case _1, _2, _3, _4, _5, _6, _7, _8 } enum IntervalType: Int, RawRepresentable { case perfect case minor case major case diminished case augmented case minorMajorDiminished case minorMajorAugmented } struct Interval: Hashable, Equatable { let degree: Degree let type: IntervalType static let _1dim = Interval(degree: ._1, type: .diminished) static let _1 = Interval(degree: ._1, type: .perfect) static let _1aug = Interval(degree: ._1, type: .augmented) static let _2dim = Interval(degree: ._2, type: .minorMajorDiminished) static let _2min = Interval(degree: ._2, type: .minor) static let _2maj = Interval(degree: ._2, type: .major) static let _2aug = Interval(degree: ._2, type: .minorMajorAugmented) ... static let _4dim = Interval(degree: ._4, type: .diminished) static let _4 = Interval(degree: ._4, type: .perfect) static let _4aug = Interval(degree: ._4, type: .augmented) ... static let _7dim = Interval(degree: ._7, type: .minorMajorDiminished) static let _7min = Interval(degree: ._7, type: .minor) static let _7maj = Interval(degree: ._7, type: .major) static let _7aug = Interval(degree: ._7, type: .minorMajorAugmented) } Now it's time to model the keys (we touched on them above already). What's important is to define the intervals for all of them (major and minor ones). enum Key { // natural case C, A_min // sharp case G, E_min case D, B_min case A, Fs_min case E, Cs_min case B, Gs_min case Fs, Ds_min case Cs, As_min // flat case F, D_min case Bf, G_min case Ef, C_min case Af, F_min case Df, Bf_min case Gf, Ef_min case Cf, Af_min ... enum KeyType { case naturalMajor case naturalMinor case flatMajor case flatMinor case sharpMajor case sharpMinor } var type: KeyType { switch self { case .C: return .naturalMajor case .A_min: return .naturalMinor case .G, .D, .A, .E, .B, .Fs, .Cs: return .sharpMajor case .E_min, .B_min, .Fs_min, .Cs_min, .Gs_min, .Ds_min, .As_min: return .sharpMinor case .F, .Bf, .Ef, .Af, .Df, .Gf, .Cf: return .flatMajor case .D_min, .G_min, .C_min, .F_min, .Bf_min, .Ef_min, .Af_min: return .flatMinor } } var intervals: [Interval] { switch type { case .naturalMajor, .flatMajor, .sharpMajor: return [ ._1, ._2maj, ._3maj, ._4, ._5, ._6maj, ._7maj ] case .naturalMinor, .flatMinor, .sharpMinor: return [ ._1, ._2maj, ._3min, ._4, ._5, ._6min, ._7min ] } } var notes: NoteSequence { switch self { case .C: return .C case .A_min: return .A_min ... } } At this point we have all the fundamental building blocks and we can proceed with the implementation of the algorithm. The idea is to have a function that given a key a root interval a list of intervals it works out the list of notes. In terms of inputs, it seems the above is all we need to correctly work out scales, chords, and - by extension - also harmonizations. Mind that the root interval doesn't have to be part of the list of intervals, that is simply the interval to start from based on the given key. Giving a note as a starting point is not good enough since some scales simply don't exist for some notes (e.g. G♯ major scale doesn't exist in the major key, and G♭minor scale doesn't exist in any minor key). Before progressing to the implementation, please consider the following unit tests that should make sense to you: func test_noteSequence_C_1() { let key: Key = .C let noteSequence = try! engine.noteSequence(customKey: key.associatedCustomKey, intervals: [._1, ._2maj, ._3maj, ._4, ._5, ._6maj, ._7maj]) let expectedValue: NoteSequence = [.C, .D, .E, .F, .G, .A, .B] XCTAssertEqual(noteSequence, expectedValue) } func test_noteSequence_withRoot_C_3maj_majorScaleIntervals() { let key = Key.C let noteSequence = try! engine.noteSequence(customKey: key.associatedCustomKey, rootInterval: ._3maj, intervals: [._1, ._2maj, ._3maj, ._4, ._5, ._6maj, ._7maj]) let expectedValue: NoteSequence = [.E, .Fs, .Gs, .A, .B, .Cs, .Ds] XCTAssertEqual(noteSequence, expectedValue) } func test_noteSequence_withRoot_Gsmin_3maj_alteredScaleIntervals() { let key = Key.Gs_min let noteSequence = try! engine.noteSequence(customKey: key.associatedCustomKey, rootInterval: ._3maj, intervals: [._1aug, ._2maj, ._3dim, ._4dim, ._5aug, ._6dim, ._7dim]) let expectedValue: NoteSequence = [.Bs, .Cs, .Df, .Ef, .Fss, .Gf, .Af] XCTAssertEqual(noteSequence, expectedValue) } and here is the implementation. Let's consider a simple case, so it's easier to follow: key = C major root interval = 3maj interval = major scale interval (1, 2maj, 3min, 4, 5, 6maj, 7min) if you music theory allowed you to understand the above unit tests, you would expect the output to be: E, F♯, G, A, B, C♯, D (which is a Dorian scale). Steps: we start by shifting the notes of the C key to position the 3rd degree (based on the 3maj) as the first element of the array, getting the note sequence E, F, G, A, B, C, D; here's the first interesting bit: we then get the list of intervals by calculating the number of semitones from the root to any other note in the sequence and working out the corresponding Interval: 1_perfect, 2_minor, 3_minor, 4_perfect, 5_perfect, 6_minor, 7_minor; we now have all we need to create a CustomKey which is pretty much a Key (with notes and intervals) but instead of being an enum with pre-defined values, is a struct; here's the second tricky part: return the notes by mapping the input intervals. Applying to each note in the custom key the accidental needed to match the desired interval. In our case, the only 2 intervals to 'adjust' are the 2nd and the 6th intervals, both minor in the custom key but major in the list of intervals. So we have to apply a sharp accidental to 'correct' them. 👀 I've used force unwraps in these examples for simplicity, the code might already look complex by itself. class CoreEngine { func noteSequence(customKey: CustomKey, rootInterval: Interval = ._1, intervals: [Interval]) throws -> NoteSequence { // 1. let noteSequence = customKey.shiftedNotes(by: rootInterval.degree) let firstNoteInShiftedSequence = noteSequence.first! // 2. let adjustedIntervals = try noteSequence.enumerated().map { try interval(from: firstNoteInShiftedSequence, to: $1, targetDegree: Degree(rawValue: $0)!) } // 3. let customKey = CustomKey(notes: noteSequence, intervals: adjustedIntervals) // 4. return try intervals.map { let referenceInterval = customKey.firstIntervalWithDegree($0.degree)! let note = customKey.notes[$0.degree.rawValue] let accidental = try referenceInterval.type.accidental(to: $0.type) return try note.noteByApplyingAccidental(accidental) } } } It's worth showing the implementation of the methods used above: private func numberOfSemitones(from sourceNote: Note, to targetNote: Note) -> Int { let notesGroupedBySameTone: [[Note]] = [ [.C, .Bs, .Dff], [.Cs, .Df, .Bss], [.D, .Eff, .Css], [.Ds, .Ef, .Fff], [.E, .Dss, .Ff], [.F, .Es, .Gff], [.Fs, .Ess, .Gf], [.G, .Fss, .Aff], [.Gs, .Af], [.A, .Gss, .Bff], [.As, .Bf, .Cff], [.B, .Cf, .Ass] ] let startIndex = notesGroupedBySameTone.firstIndex { $0.contains(sourceNote)}! let endIndex = notesGroupedBySameTone.firstIndex { $0.contains(targetNote)}! return endIndex >= startIndex ? endIndex - startIndex : (notesGroupedBySameTone.count - startIndex) + endIndex } private func interval(from sourceNote: Note, to targetNote: Note, targetDegree: Degree) throws -> Interval { let semitones = numberOfSemitones(from: sourceNote, to: targetNote) let targetType: IntervalType = try { switch targetDegree { case ._1, ._8: return .perfect ... case ._4: switch semitones { case 4: return .diminished case 5: return .perfect case 6: return .augmented default: throw CustomError.invalidConfiguration ... case ._7: switch semitones { case 9: return .minorMajorDiminished case 10: return .minor case 11: return .major case 0: return .minorMajorAugmented default: throw CustomError.invalidConfiguration } } }() return Interval(degree: targetDegree, type: targetType) } the Note's noteByApplyingAccidental method: func noteByApplyingAccidental(_ accidental: Accidental) throws -> Note { let newAccidental = try self.accidental.apply(accidental) return Note(naturalNote: naturalNote, accidental: newAccidental) } and the Accidental's apply method: func apply(_ accidental: Accidental) throws -> Accidental { switch (self, accidental) { ... case (.flat, .flatFlatFlat): throw CustomError.invalidApplicationOfAccidental case (.flat, .flatFlat): return .flatFlatFlat case (.flat, .flat): return .flatFlat case (.flat, .natural): return .flat case (.flat, .sharp): return .natural case (.flat, .sharpSharp): return .sharp case (.flat, .sharpSharpSharp): return .sharpSharp case (.natural, .flatFlatFlat): return .flatFlatFlat case (.natural, .flatFlat): return .flatFlat case (.natural, .flat): return .flat case (.natural, .natural): return .natural case (.natural, .sharp): return .sharp case (.natural, .sharpSharp): return .sharpSharp case (.natural, .sharpSharpSharp): return .sharpSharpSharp ... } With the above engine ready (and 💯﹪ unit tested!), we can now proceed to use it to work out what we ultimately need (scales, chords, and harmonizations). extension CoreEngine { func scale(note: Note, scaleIdentifier: Identifier) throws -> NoteSequence {...} func chord(note: Note, chordIdentifier: Identifier) throws -> NoteSequence {...} func harmonization(key: Key, harmonizationIdentifier: Identifier) throws -> NoteSequence {...} func chordSignatures(note: Note, scaleHarmonizationIdentifier: Identifier) throws -> [ChordSignature] {...} func harmonizations(note: Note, scaleHarmonizationIdentifier: Identifier) throws -> [NoteSequence] {...} } Conclusions There's more to it but with this post I only wanted to outline the overall idea. The default database is available on GitHub at albertodebortoli/iHarmonyDB. The format used is JSON and the community can now easily suggest additions. Here is how the definition of a scale looks: "scale_dorian": { "group": "group_scales_majorModes", "isMode": true, "degreeRelativeToMain": 2, "inclination": "minor", "intervals": [ "1", "2maj", "3min", "4", "5", "6maj", "7min" ] } and a chord: "chord_diminished": { "group": "group_chords_diminished", "abbreviation": "dim", "intervals": [ "1", "3min", "5dim" ] } and a harmonization: "scaleHarmonization_harmonicMajorScale4Tones": { "group": "group_harmonization_harmonic_major", "inclination": "major", "harmonizations": [ "harmonization_1_major7plus", "harmonization_2maj_minor7dim5", "harmonization_3maj_minor7", "harmonization_4_minor7plus", "harmonization_5_major7", "harmonization_6min_major7plus5sharp", "harmonization_7maj_diminished7" ] } Have to say, I'm pretty satisfied with how extensible this turned out to be. Thanks for reading 🎶

Localizations, locales, timezones, date and currency formatting... it's shocking how easy is to forget how they work and how to use them correctly. In this article, I try to summarize the bare minimum one needs to know to add internationalization support to an iOS app.

In this article, I try to summarize the bare minimum one needs to know to add internationalization support to an iOS app. Localizations, locales, timezones, date and currency formatting... it's shocking how easy is to forget how they work and how to use them correctly. After years more than 10 years into iOS development, I decided to write down a few notes on the matter, with the hope that they will come handy again in the future, hopefully not only to me. TL;DR From Apple docs: Date: a specific point in time, independent of any calendar or time zone; TimeZone: information about standard time conventions associated with a specific geopolitical region; Locale: information about linguistic, cultural, and technological conventions for use in formatting data for presentation. Rule of thumb: All DateFormatters should use the locale and the timezone of the device; All NumberFormatter, in particular those with numberStyle set to .currency (for the sake of this article) should use a specific locale so that prices are not shown in the wrong currency. General notes on formatters Let's start by stating the obvious. Since iOS 10, Foundation (finally) provides ISO8601DateFormatter, which, alongside with DateFormatter and NumberFormatter, inherits from Formatter. Formatter locale property timeZone property ISO8601DateFormatter ❌ ✅ DateFormatter ✅ ✅ NumberFormatter ✅ ❌ In an app that only consumes data from an API, the main purpose of ISO8601DateFormatter is to convert strings to dates (String -> Date) more than the inverse. DateFormatter is then used to format dates (Date -> String) to ultimately show the values in the UI. NumberFormatter instead, converts numbers (prices in the vast majority of the cases) to strings (NSNumber/Decimal -> String). Formatting dates 🕗 🕝 🕟 It seems the following 4 are amongst the most common ISO 8601 formats, including the optional UTC offset. A: 2019-10-02T16:53:42 B: 2019-10-02T16:53:42Z C: 2019-10-02T16:53:42-02:00 D: 2019-10-02T16:53:42.974Z In this article I'll stick to these formats. The 'Z' at the end of an ISO8601 date indicates that it is in UTC, not a local time zone. Locales Converting strings to dates (String -> Date) is done using ISO8601DateFormatter objects set up with various formatOptions. Once we have a Date object, we can deal with the formatting for the presentation. Here, the locale is important and things can get a bit tricky. Locales have nothing to do with timezones, locales are for applying a format using a language/region. Locale identifiers are in the form of <language_identifier>_<region_identifier> (e.g. en_GB). We should use the user's locale when formatting dates (Date -> String). Consider a British user moving to Italy, the apps should keep showing a UI localized in English, and the same applies to the dates that should be formatted using the en_GB locale. Using the it_IT locale would show "2 ott 2019, 17:53" instead of the correct "2 Oct 2019 at 17:53". Locale.current, shows the locale set (overridden) in the iOS simulator and setting the language and regions in the scheme's options comes handy for debugging. Some might think that it's acceptable to use Locale.preferredLanguages.first and create a Locale from it with let preferredLanguageLocale = Locale(identifier: Locale.preferredLanguages.first!) and set it on the formatters. I think that doing so is not great since we would display dates using the Italian format but we won't necessarily be using the Italian language for the other UI elements as the app might not have the IT localization, causing an inconsistent experience. In short: don't use preferredLanguages, best to use Locale.current. Apple strongly suggests using en_US_POSIX pretty much everywhere (1, 2). From Apple docs: [...] if you're working with fixed-format dates, you should first set the locale of the date formatter to something appropriate for your fixed format. In most cases the best locale to choose is "en_US_POSIX", a locale that's specifically designed to yield US English results regardless of both user and system preferences. "en_US_POSIX" is also invariant in time (if the US, at some point in the future, changes the way it formats dates, "en_US" will change to reflect the new behaviour, but "en_US_POSIX" will not), and between machines ("en_US_POSIX" works the same on iOS as it does on OS X, and as it it does on other platforms). Once you've set "en_US_POSIX" as the locale of the date formatter, you can then set the date format string and the date formatter will behave consistently for all users. I couldn't find a really valid reason for doing so and quite frankly using the device locale seems more appropriate for converting dates to strings. Here is the string representation for the same date using different locales: en_US_POSIX: May 2, 2019 at 3:53 PM en_GB: 2 May 2019 at 15:53 it_IT: 2 mag 2019, 15:53 The above should be enough to show that en_US_POSIX is not what we want to use in this case, but it has more to do with maintaining a standard for communication across machines. From this article: "[...] Unless you specifically need month and/or weekday names to appear in the user's language, you should always use the special locale of en_US_POSIX. This will ensure your fixed format is actually fully honored and no user settings override your format. This also ensures month and weekday names appear in English. Without using this special locale, you may get 24-hour format even if you specify 12-hour (or visa-versa). And dates sent to a server almost always need to be in English." Timezones Stating the obvious one more time: Greenwich Mean Time (GMT) is a time zone while Coordinated Universal Time (UTC) is a time standard. There is no time difference between them. Timezones are fundamental to show the correct date/time in the final text shown to the user. The timezone value is taken from macOS and the iOS simulator inherits it, meaning that printing TimeZone.current, shows the timezone set in the macOS preferences (e.g. Europe/Berlin). Show me some code Note that in the following example, we use GMT (Greenwich Mean Time) and CET (Central European Time), which is GMT+1. Mind that it's best to reuse formatters since the creation is expensive. class CustomDateFormatter { private let dateFormatter: DateFormatter = { let dateFormatter = DateFormatter() dateFormatter.dateStyle = .medium dateFormatter.timeStyle = .short return dateFormatter }() private let locale: Locale private let timeZone: TimeZone init(locale: Locale = .current, timeZone: TimeZone = .current) { self.locale = locale self.timeZone = timeZone } func string(from date: Date) -> String { dateFormatter.locale = locale dateFormatter.timeZone = timeZone return dateFormatter.string(from: date) } } let stringA = "2019-11-02T16:53:42" let stringB = "2019-11-02T16:53:42Z" let stringC = "2019-11-02T16:53:42-02:00" let stringD = "2019-11-02T16:53:42.974Z" // The ISO8601DateFormatter's extension (redacted) // internally uses multiple formatters, each one set up with different // options (.withInternetDateTime, .withFractionalSeconds, withFullDate, .withTime, .withColonSeparatorInTime) // to be able to parse all the formats. // timeZone property is set to GMT. let dateA = ISO8601DateFormatter.date(from: stringA)! let dateB = ISO8601DateFormatter.date(from: stringB)! let dateC = ISO8601DateFormatter.date(from: stringC)! let dateD = ISO8601DateFormatter.date(from: stringD)! var dateFormatter = CustomDateFormatter(locale: Locale(identifier: "en_GB"), timeZone: TimeZone(identifier: "GMT")!) dateFormatter.string(from: dateA) // 2 Nov 2019 at 16:53 dateFormatter.string(from: dateB) // 2 Nov 2019 at 16:53 dateFormatter.string(from: dateC) // 2 Nov 2019 at 18:53 dateFormatter.string(from: dateD) // 2 Nov 2019 at 16:53 dateFormatter = CustomDateFormatter(locale: Locale(identifier: "it_IT"), timeZone: TimeZone(identifier: "CET")!) dateFormatter.string(from: dateA) // 2 nov 2019, 17:53 dateFormatter.string(from: dateB) // 2 nov 2019, 17:53 dateFormatter.string(from: dateC) // 2 nov 2019, 19:53 dateFormatter.string(from: dateD) // 2 nov 2019, 17:53 Using the CET timezone also for ISO8601DateFormatter, the final string produced for dateA would respectively be "15:53" when formatted with GMT and "16:53" when formatted with CET. As long as the string passed to ISO8601DateFormatter is in UTC, it's irrelevant to set the timezone on the formatter. Apple suggests to set the timeZone property to UTC with TimeZone(secondsFromGMT: 0), but this is irrelevant if the string representing the date already includes the timezone. If your server returns a string representing a date that is not in UTC, it's probably because of one of the following 2 reasons: it's not meant to be in UTC (questionable design decision indeed) and therefore the timezone of the device should be used instead; the backend developers implemented it wrong and they should add the 'Z 'at the end of the string if what they intended is to have the date in UTC. In short: All DateFormatters should have timezone and locale set to .current and avoid handling non-UTC string if possible. Formatting currencies € $ ¥ £ The currency symbol and the formatting of a number should be defined via a Locale, and they shouldn't be set/changed on the NumberFormatter. Don't use the user's locale (Locale.current) because it could be set to a region not supported by the app. Let's consider the example of a user's locale to be en_US, and the app to be available only for the Italian market. We must set a locale Locale(identifier: "it_IT") on the formatter, so that: prices will be shown only in Euro (not American Dollar) the format used will be the one of the country language (for Italy, "12,34 €", not any other variation such as "€12.34") class CurrencyFormatter { private let locale: Locale init(locale: Locale = .current) { self.locale = locale } func string(from decimal: Decimal, overriddenCurrencySymbol: String? = nil) -> String { let formatter = NumberFormatter() formatter.numberStyle = .currency if let currencySymbol = overriddenCurrencySymbol { // no point in doing this on a NumberFormatter ❌ formatter.currencySymbol = currencySymbol } formatter.locale = locale return formatter.string(from: decimal as NSNumber)! } } let itCurrencyFormatter = CurrencyFormatter(locale: Locale(identifier: "it_IT")) let usCurrencyFormatter = CurrencyFormatter(locale: Locale(identifier: "en_US")) let price1 = itCurrencyFormatter.string(from: 12.34) // "12,34 €" ✅ let price2 = usCurrencyFormatter.string(from: 12.34) // "$12.34" ✅ let price3 = itCurrencyFormatter.string(from: 12.34, overriddenCurrencySymbol: "₿") // "12,34 ₿" ❌ let price4 = usCurrencyFormatter.string(from: 12.34, overriddenCurrencySymbol: "₿") // "₿ 12.34" ❌ In short: All NumberFormatters should have the locale set to the one of the country targeted and no currencySymbol property overridden (it's inherited from the locale). Languages 🇬🇧 🇮🇹 🇳🇱 Stating the obvious one more time, but there are very rare occasions that justify forcing the language in the app: func setLanguage(_ language: String) { let userDefaults = UserDefaults.standard userDefaults.set([language], forKey: "AppleLanguages") } The above circumvents the Apple localization mechanism and needs an app restart, so don't do it and localize the app by the book: add localizations in Project -> Localizations; create a Localizable.strings file and tap the localize button in the inspector; always use NSLocalizedString() in code. Let's consider this content of Localizable.strings (English): "kHello" = "Hello"; "kFormatting" = "Some formatting 1. %@ 2. %d."; and this for another language (e.g. Italian) Localizable.strings (Italian): "kHello" = "Ciao"; "kFormatting" = "Esempio di formattazione 1) %@ 2) %d."; Simple localization Here's the trivial example: let localizedString = NSLocalizedString("kHello", comment: "") If Locale.current.languageCode is it, the value would be 'Ciao', and 'Hello' otherwise. Formatted localization For formatted strings, use the following: let stringWithFormats = NSLocalizedString("kFormatting", comment: "") String.localizedStringWithFormat(stringWithFormats, "some value", 3) As before, if Locale.current.languageCode is it, value would be 'Esempio di formattazione 1) some value 2) 3.', and 'Some formatting 1) some value 2) 3.' otherwise. Plurals localization For plurals, create a Localizable.stringsdict file and tap the localize button in the inspector. Localizable.strings and Localizable.stringsdict are independent, so there are no cross-references (something that often tricked me). Here is a sample content: <dict> <key>kPlurality</key> <dict> <key>NSStringLocalizedFormatKey</key> <string>Interpolated string: %@, interpolated number: %d, interpolated variable: %#@COUNT@.</string> <key>COUNT</key> <dict> <key>NSStringFormatSpecTypeKey</key> <string>NSStringPluralRuleType</string> <key>NSStringFormatValueTypeKey</key> <string>d</string> <key>zero</key> <string>nothing</string> <key>one</key> <string>%d object</string> <key>two</key> <string></string> <key>few</key> <string></string> <key>many</key> <string></string> <key>other</key> <string>%d objects</string> </dict> </dict> </dict> Localizable.stringsdict undergo the same localization mechanism of its companion Localizable.strings. It's mandatory to only implement 'other', but an honest minimum includes 'zero', 'one', and 'other'. Given the above content, the following code should be self-explanatory: let localizedHello = NSLocalizedString("kHello", comment: "") // from Localizable.strings let stringWithPlurals = NSLocalizedString("kPlurality", comment: "") // from Localizable.stringsdict String.localizedStringWithFormat(stringWithPlurals, localizedHello, 42, 1) With the en language, the value would be 'Interpolated string: Hello, interpolated number: 42, interpolated variable: 1 object.'. Use the scheme's option to run with a specific Application Language (it will change the current locale language and therefore also the output of the DateFormatters). If the language we've set or the device language are not supported by the app, the system falls back to en. References https://en.wikipedia.org/wiki/ISO_8601 https://nsdateformatter.com/ https://foragoodstrftime.com/ https://epochconverter.com/ So... that's all folks. 🌍

The journey towards a modular architecture taken by the Just Eat iOS team.

The journey we took to restructure our mobile apps towards a modular architecture. Originally published on the Just Eat Engineering Blog. Overview Modular mobile architectures have been a hot topic over the past 2 years, counting a plethora of articles and conference talks. Almost every big company promoted and discussed modularization publicly as a way to scale big projects. At Just Eat, we jumped on the modular architecture train probably before it was mainstream and, as we'll discuss in this article, the root motivation was quite peculiar in the industry. Over the years (2016-2019), we've completely revamped our iOS products from the ground up and learned a lot during this exciting and challenging journey. There is so much to say about the way we structured our iOS stack that it would probably deserve a series of articles, some of which have previously been posted. Here we summarize the high-level iOS architecture we crafted, covering the main aspects in a way concise enough for the reader to get a grasp of them and hopefully learn some valuable tips. Modular Architecture Lots of information can be found online on modular architectures. In short: A modular architecture is a software design technique that emphasizes separating the functionality of a program into independent, interchangeable modules, such that each one contains everything necessary to execute only one aspect of the desired functionality. Note that modular design applies to the code you own. A project with several third-party dependencies but no sensible separation for the code written by your team is not considered modular. A modular design is more about the principle rather than the specific technology. One could achieve it in a variety of ways and with different tools. Here are some key points and examples that should inform the decision of the ifs and the hows of implementing modularization: Business reasons The company requires that parts of the codebase are reused and shared across projects, products, and teams; The company requires multiple products to be unified into a single one. Tech reasons The codebase has grown to a state where things become harder and harder to maintain and to iterate over; Development is slowed down due to multiple developers working on the same monolithic codebase; Besides reusing code, you need to port functionalities across projects/products. Multiple teams The company structured teams following strategic models (e.g. Spotify model) and functional teams only work on a subset of the final product; Ownership of small independent modules distributed across teams enables faster iterations; The much smaller cognitive overhead of working on a smaller part of the whole product can vastly simplify the overall development. Pre-existing knowledge Members of the team might already be familiar with specific solutions (Carthage, CocoaPods, Swift Package Manager, manual frameworks setup within Xcode). In the case of a specific familiarity with a system, it's recommended to start with it since all solutions come with pros and cons and there's not a clear winner at the time of writing. Modularizing code (if done sensibly) is almost always a good thing: it enforces separation of concerns, keeps complexity under control, allows faster development, etc. It has to be said that it's not necessarily what one needs for small projects and its benefits become tangible only after a certain complexity threshold is crossed. Journey to a new architecture In 2014, Just Eat was a completely different environment from today and back then the business decided to split the tech department into separate departments: one for UK and one for the other countries. While this was done with the best intentions to allow faster evolution in the main market (UK), it quickly created a hard division between teams, services, and people. In less than 6 months, the UK and International APIs and consumer clients deeply diverged introducing country-specific logic and behaviors. By mid-2016 the intent of "merging back" into a single global platform was internally announced and at that time it almost felt like a company acquisition. This is when we learned the importance of integrating people before technology. The teams didn’t know each other very well and became reasonably territorial on their codebase. It didn’t help that the teams span multiple cities. It's understandable that getting to an agreement on how going back to a single, global, and unified platform took months. The options we considered spanned from rewriting the product from scratch to picking one of the two existing ones and make it global. A complete rewrite would have eventually turned out to be a big-bang release with the risk of regressions being too high; not something sensible or safe to pursue. Picking one codebase over the other would have necessarily let down one of the two teams and caused the re-implementation of some missing features present in the other codebase. At that time, the UK project was in a better shape and new features were developed for the UK market first. The international project was a bit behind due to the extra complexity of supporting multiple countries and features being too market-specific. During that time, the company was also undergoing massive growth and with multiple functional teams having been created internally, there was an increasing need to move towards modularization. Therefore, we decided to gradually and strategically modularize parts of the mobile products and onboard them onto the other codebase in a controlled and safe way. In doing so, we took the opportunity to deeply refactor and, in the vast majority of the cases, rewrite parts in their entirety enabling new designs, better tests, higher code coverage, and - holistically - a fully Swift codebase. We knew that the best way to refactor and clean up the code was by following a bottom-up approach. We started with the foundations to solve small and well-defined problems - such as logging, tracking, theming - enabling the team to learn to think modular. We later moved to isolating big chunks of code into functional modules to be able to onboard them into the companion codebase and ship them on a phased rollout. We soon realized we needed a solid engine to handle run-time configurations and remote feature flagging to allow switching ON and OFF features as well as entire modules. As discussed in a previous article, we developed JustTweak to achieve this goal. At the end of the journey, the UK and the International projects would look very similar, sharing a number of customizable modules, and differing only in the orchestration layer in the apps. The Just Eat iOS apps are far bigger and more complex than they might look at first glance. Generically speaking, merging different codebases takes orders of magnitude longer than separating them, and for us, it was a process that took over 3 years, being possible thanks to unparalleled efforts of engineers brought to work together. Over this time, the whole team learned a lot, from the basics of developing code in isolation to how to scale a complex system. Holistic Design 🤘 The following diagram outlines the modular architecture in its entirety as it is at the time of writing this article (December 2019). We can appreciate a fair number of modules clustered by type and the different consumer apps. Modular iOS architecture - holistic design Whenever possible, we took the opportunity to abstract some modules having them in a state that allows open-sourcing the code. All of our open-source modules are licensed under Apache 2 and can be found at github.com/justeat. Apps Due to the history of Just Eat described above, we build different apps per country per brand from different codebases All the modularization work we did bottom-up brought us to a place where the apps differ only in the layer orchestrating the modules. With all the consumer-facing features been moved to the domain modules, there is very little code left in the apps. Domain Modules Domain modules contain features specific to an area of the product. As the diagram above shows, the sum of all those parts makes up the Just Eat apps. These modules are constantly modified and improved by our teams and updating the consumer apps to use newer versions is an explicit action. We don't particularly care about backward compatibility here since we are the sole consumers and it's common to break the public interface quite often if necessary. It might seem at first that domain modules should depend on some Core modules (e.g. APIClient) but doing so would complicate the dependency tree as we'll discuss further in the "Dependency Management" section of this article. Instead, we inject core modules' services, simply making them conformant to protocols defined in the domain module. In this way, we maintain a good abstraction and avoid tangling the dependency graph. Core & Shared modules The Core and Shared modules represent the foundations of our stack, things like: custom UI framework theming engine logging, tracking, and analytics libraries test utilities client for all the Just Eat APIs feature flagging and experimentation engine and so forth. These modules - which are sometimes also made open-source - should not change frequently due to their nature. Here backward compatibility is important and we deprecate old APIs when introducing new ones. Both apps and domain modules can have shared modules as dependencies, while core modules can only be used by the apps. Updating the backbone of a system requires the propagation of the changes up in the stack (with its maintenance costs) and for this reason, we try to keep the number of shared modules very limited. Structure of a module As we touched on in previous articles, one of our fundamental principles is "always strive to find solutions to problems that are scalable and hide complexity as much as possible". We are almost obsessed with making things as simple as they can be. When building a module, our root principle is: Every module should be well tested, maintainable, readable, easily pluggable, and reasonably documented. The order of the adjectives implies some sort of priority. First of all, the code must be unit tested, and in the case of domain modules, UI tests are required too. Without reasonable code coverage, no code is shipped to production. This is the first step to code maintainability, where maintainable code is intended as "code that is easy to modify or extend". Readability is down to reasonable design, naming convention, coding standards, formatting, and all that jazz. Every module exposes a Facade that is very succinct, usually no more than 200 lines long. This entry point is what makes a module easily pluggable. In our module blueprint, the bare minimum is a combination of a facade class, injected dependencies, and one or more configuration objects driving the behavior of the module (leveraging the underlying feature flagging system powered by JustTweak discussed in a previous article). The facade should be all a developer needs to know in order to consume a module without having to look at implementation details. Just to give you an idea, here is an excerpt from the generated public interface of the Account module (not including the protocols): public typealias PasswordManagementService = ForgottenPasswordServiceProtocol & ResetPasswordServiceProtocol public typealias AuthenticationService = LoginServiceProtocol & SignUpServiceProtocol & PasswordManagementService & RecaptchaServiceProtocol public typealias UserAccountService = AccountInfoServiceProtocol & ChangePasswordServiceProtocol & ForgottenPasswordServiceProtocol & AccountCreditServiceProtocol public class AccountModule { public init(settings: Settings, authenticationService: AuthenticationService, userAccountService: UserAccountService, socialLoginServices: [SocialLoginService], userInfoProvider: UserInfoProvider) public func startLogin(on viewController: UIViewController) -> FlowCoordinator public func startResetPassword(on viewController: UIViewController, token: Token) -> FlowCoordinator public func startAccountInfo(on navigationController: UINavigationController) -> FlowCoordinator public func startAccountCredit(on navigationController: UINavigationController) -> FlowCoordinator public func loginUsingSharedWebCredentials(handler: @escaping (LoginResult) -> Void) } Domain module public interface example (Account module) We believe code should be self-descriptive and we tend to put comments only on code that really deserves some explanation, very much embracing John Ousterhout's approach described in A Philosophy of Software Design. Documentation is mainly relegated to the README file and we treat every module as if it was an open-source project: the first thing consumers would look at is the README file, and so we make it as descriptive as possible. Overall design We generate all our modules using CocoaPods via $ pod lib create which creates the project with a standard template generating the Podfile, podspec, and demo app in a breeze. The podspec could specify additional dependencies (both third-party and Core modules) that the demo app's Podfile could specify core modules dependencies alongside the module itself which is treated as a development pod as per standard setup. The backbone of the module, which is the framework itself, encompasses both business logic and UI meaning that both source and asset files are part of it. In this way, the demo apps are very much lightweight and only showcase module features that are implemented in the framework. The following diagram should summarize it all. Design of a module with Podfile and podspec examples Demo Apps Every module comes with a demo app we give particular care to. Demo apps are treated as first-class citizens and the stakeholders are both engineers and product managers. They massively help to showcase the module features - especially those under development - vastly simplify collaboration across Engineering, Product, and Design, and force a good mock-based test-first approach. Following is a SpringBoard page showing our demo apps, very useful to individually showcase all the functionalities implemented over time, some of which might not surface in the final product to all users. Some features are behind experiments, some still in development, while others might have been retired but still present in the modules. Every demo app has a main menu to: access the features force a specific language toggle configuration flags via JustTweak customize mock data We show the example of the Account module demo app on the right. Domain modules demo apps Internal design It's worth noting that our root principle mentioned above does not include any reference to the internal architecture of a module and this is intentional. It's common for iOS teams in the industry to debate on which architecture to adopt across the entire codebase but the truth is that such debate aims to find an answer to a non-existing problem. With an increasing number of modules and engineers, it's fundamentally impossible to align on a single paradigm shared and agreed upon by everyone. Betting on a single architectural design would ultimately let down some engineers who would complain down the road that a different design would have played out better. We decided to stick with the following rule of thumb: Developers are free to use the architectural design they feel would work better for a given problem. This approach brought us to have a variety of different designs - spanning from simple old-school MVC, to a more evolved VIPER - and we constantly learn from each other's code. What's important at the end of the day is that techniques such as inversion of control, dependency injection, and more generally the SOLID principles, are used appropriately to embrace our root principle. Dependency Management We rely heavily on CocoaPods since we adopted it in the early days as it felt like the best and most mature choice at the time we started modularizing our codebase. We think this still holds at the time of writing this article but we can envision a shift to SPM (Swift Package Manager) in 1-2 years time. With a growing number of modules, comes the responsibility of managing the dependencies between them. No panacea can cure dependency hell, but one should adopt some tricks to keep the complexity of the stack under reasonable control. Here's a summary of what worked for us: Always respect semantic versioning; Keep the dependency graph as shallow as possible. From our apps to the leaves of the graph there are no more than 2 levels; Use a minimal amount of shared dependencies. Be aware that every extra level with shared modules brings in higher complexity; Reduce the number of third-party libraries to the bare minimum. Code that's not written and owned by your team is not under your control; Never make modules within a group (domain, core, shared) depend on other modules of the same group; Automate the publishing of new versions. When a pull request gets merged into the master branch, it must also contain a version change in the podspec. Our continuous integration system will automatically validate the podspec, publish it to our private spec repository, and in just a matter of minutes the new version becomes available; Fix the version for dependencies in the Podfile. Whether it is a consumer app or a demo app, we want both our modules and third-party libraries not to be updated unintentionally. It's acceptable to use the optimistic operator for third-party libraries to allow automatic updates of new patch versions; Fix the version for third-party libraries in the modules' podspec. This guarantees that modules' behavior won't change in the event of changes in external libraries. Failing to do so would allow defining different versions in the app's Podfile, potentially causing the module to not function correctly or even to not compile; Do not fix the version for shared modules in the modules' podspec. In this way, we let the apps define the version in the Podfile, which is particularly useful for modules that change often, avoiding the hassle of updating the version of the shared modules in every podspec referencing it. If a new version of a shared module is not backward compatible with the module consuming it, the failure would be reported by the continuous integration system as soon as a new pull request gets raised. A note on the Monorepo approach When it comes to dependency management it would be unfair not to mention the opinable monorepo approach. Monorepos have been discussed quite a lot by the community to pose a remedy to dependency management (de facto ignoring it), some engineers praise them, others are quite contrary. Facebook, Google, and Uber are just some of the big companies known to have adopted this technique, but in hindsight, it's still unclear if it was the best decision for them. In our opinion, monorepos can sometimes be a good choice. For example, in our case, a great benefit a monorepo would give us is the ability to prepare a single pull request for both implementing a code change in a module and integrating it into the apps. This will have an even greater impact when all the Just Eat consumer apps are globalized into a single codebase. Onwards and upwards Modularizing the iOS product has been a long journey and the learnings were immense. All in all, it took more than 3 years, from May 2016 to October 2019, always balancing tech and product improvements. Our natural next step is unifying the apps into a single global project, migrating the international countries over to the UK project to ultimately reach the utopian state of having a single global app. All the modules have been implemented in a fairly abstract way and following a white labeling approach, allowing us to extend support to new countries and onboard acquired companies in the easiest possible way.

Implementing Authorization on mobile can be tricky. Here are some recommendations to avoid common issues.

Originally published on the Just Eat Engineering Blog.

Overview

Modern mobile apps are more complicated than they used to be back in the early days and developers have to face a variety of interesting problems.

Implementing Authorization on mobile can be tricky. Here are some recommendations to avoid common issues. Originally published on the Just Eat Engineering Blog. Overview Modern mobile apps are more complicated than they used to be back in the early days and developers have to face a variety of interesting problems. While we've put in our two cents on some of them in previous articles, this one is about authorization and what we have learned by handling JWT on mobile at Just Eat. When it comes to authorization, it's standard practice to rely on OAuth 2.0 and the companion JWT (JSON Web Token). We found this important topic was rarely discussed online while much attention was given to new proposed implementations of network stacks, maybe using recent language features or frameworks such as Combine. We'll illustrate the problems we faced at Just Eat for JWT parsing, usage, and (most importantly) refreshing. You should be able to learn a few things on how to make your app more stable by reducing the chance of unauthorized requests allowing your users to virtually always stay logged in. What is JWT JWT stands for JSON Web Token and is an open industry standard used to represent claims transferred between two parties. A signed JWT is known as a JWS (JSON Web Signature). In fact, a JWT has either to be JWS or JWE (JSON Web Encryption). RFC 7515, RFC 7516, and RFC 7519 describe the various fields and claims in detail. What is relevant for mobile developers is the following: JWT is composed of 3 parts dot-separated: Header, Payload, Signature. The Payload is the only relevant part. The Header identifies which algorithm is used to generate the signature. There are reasons for not verifying the signature client-side making the Signature part irrelevant too. JWT has an expiration date. Expired tokens should be renewed/refreshed. JWT can contain any number of extra information specific to your service. It's common practice to store JWTs in the app keychain. Here is a valid and very short token example, courtesy of jwt.io/ which we recommend using to easily decode tokens for debugging purposes. It shows 3 fragments (base64 encoded) concatenated with a dot. eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE1Nzc3NTA0MDB9.7hgBhNK_ZpiteB3GtLh07KJ486Vfe3WAdS-XoDksJCQ The only field relevant to this document is exp (Expiration Time), part of Payload (the second fragment). This claim identifies the time after which the JWT must not be accepted. In order to accept a JWT, it's required that the current date/time must be before the expiration time listed in the exp claim. It's accepted practice for implementers to consider for some small leeway, usually no more than a few minutes, to account for clock skew. N.B. Some API calls might demand the user is logged in (user-authenticated calls), and others don't (non-user-authenticated calls). JWT can be used in both cases, marking a distinction between Client JWT and User JWT we will refer to later on. The token refresh problem By far the most significant problem we had in the past was the renewal of the token. This seems to be something taken for granted by the mobile community, but in reality, we found it to be quite a fragile part of the authentication flow. If not done right, it can easily cause your customers to end up being logged out, with the consequent frustration we all have experienced as app users. The Just Eat app makes multiple API calls at startup: it fetches the order history to check for in-flight orders, fetches the most up-to-date consumer details, etc. If the token is expired when the user runs the app, a nasty race condition could cause the same refresh token to be used twice, causing the server to respond with a 401 and subsequently logging the user out on the app. This can also happen during normal execution when multiple API calls are performed very close to each other and the token expires prior to those. It gets trickier if the client and the server clocks are sensibly off sync: while the client might believe to be in possession of a valid token, it has already expired. The following diagram should clarify the scenario. Common misbehavior I couldn't find a company (regardless of size) or indie developer who had implemented a reasonable token refresh mechanism. The common approach seems to be: to refresh the token whenever an API call fails with 401 Unauthorized. This is not only causing an extra call that could be avoided by locally checking if the token has expired, but it also opens the door for the race condition illustrated above. Avoid race conditions when refreshing the token 🚦 We'll explain the solution with some technical details and code snippets but what what's more important is that the reader understands the root problem we are solving and why it should be given the proper attention. The more we thought about it, we more we convinced ourselves that the best way to shield ourselves from race conditions is by using threading primitives when scheduling async requests to fetch a valid token. This means that all the calls would be regulated via a filter that would hold off subsequent calls to fire until a valid token is retrieved, either from local storage or, if a refresh is needed, from the remote OAuth server. We'll show examples for iOS, so we've chosen dispatch queues and semaphores (using GCD); fancier and more abstract ways of implementing the solution might exist - in particular by leveraging modern FRP techniques - but ultimately the same primitives are used. For simplicity, let's assume that only user-authenticated API requests need to provide a JWT, commonly put in the Authorization header: Authorization: Bearer <jwt-token> The code below implements the "Get valid JWT" box from the following flowchart. The logic within this section is the one that must be implemented in mutual exclusion, in our solution, by using the combination of a serial queue and a semaphore. Here is just the minimum amount of code (Swift) needed to explain the solution. typealias Token = String typealias AuthorizationValue = String struct UserAuthenticationInfo { let bearerToken: Token // the JWT let refreshToken: Token let expiryDate: Date // computed on creation from 'exp' claim var isValid: Bool { return expiryDate.compare(Date()) == .orderedDescending } } protocol TokenRefreshing { func refreshAccessToken(_ refreshToken: Token, completion: @escaping (Result<UserAuthenticationInfo, Error>) -> Void) } protocol AuthenticationInfoStorage { var userAuthenticationInfo: UserAuthenticationInfo? func persistUserAuthenticationInfo(_ authenticationInfo: UserAuthenticationInfo?) func wipeUserAuthenticationInfo() } class AuthorizationValueProvider { private let authenticationInfoStore: AuthenticationInfoStorage private let tokenRefreshAPI: TokenRefreshing private let queue = DispatchQueue(label: <#label#>, qos: .userInteractive) private let semaphore = DispatchSemaphore(value: 1) init(tokenRefreshAPI: TokenRefreshing, authenticationInfoStore: AuthenticationInfoStorage) { self.tokenRefreshAPI = tokenRefreshAPI self.authenticationInfoStore = authenticationInfoStore } func getValidUserAuthorization(completion: @escaping (Result<AuthorizationValue, Error>) -> Void) { queue.async { self.getValidUserAuthorizationInMutualExclusion(completion: completion) } } } Before performing any user-authenticated request, the network client asks an AuthorizationValueProvider instance to provide a valid user Authorization value (the JWT). It does so via the async method getValidUserAuthorization which uses a serial queue to handle the requests. The chunky part is the getValidUserAuthorizationInMutualExclusion. private func getValidUserAuthorizationInMutualExclusion(completion: @escaping (Result<AuthorizationValue, Error>) -> Void) { semaphore.wait() guard let authenticationInfo = authenticationInfoStore.userAuthenticationInfo else { semaphore.signal() let error = // forge an error for 'missing authorization' completion(.failure(error)) return } if authenticationInfo.isValid { semaphore.signal() completion(.success(authenticationInfo.bearerToken)) return } tokenRefreshAPI.refreshAccessToken(authenticationInfo.refreshToken) { result in switch result { case .success(let authenticationInfo): self.authenticationInfoStore.persistUserAuthenticationInfo(authenticationInfo) self.semaphore.signal() completion(.success(authenticationInfo.bearerToken)) case .failure(let error) where error.isClientError: self.authenticationInfoStore.wipeUserAuthenticationInfo() self.semaphore.signal() completion(.failure(error)) case .failure(let error): self.semaphore.signal() completion(.failure(error)) } } } The method could fire off an async call to refresh the token, and this makes the usage of the semaphore crucial. Without it, the next request to AuthorizationValueProvider would be popped from the queue and executed before the remote refresh completes. The semaphore is initialised with a value of 1, meaning that only one thread can access the critical section at a given time. We make sure to call wait at the beginning of the execution and to call signal only when we have a result and therefore ready to leave the critical section. If the token found in the local store is still valid, we simply return it, otherwise, it's time to request a new one. In the latter case, if all goes well, we persist the token locally and allow the next request to access the method, in the case of an error, we should be careful and wipe the token only if the error is a legit client error (2xx range). This includes also the usage of a refresh token that is not valid anymore, which could happen, for instance, if the user resets the password on another platform/device. It's critical to not delete the token from the local store in the case of any other error, such as 5xx or the common Foundation's NSURLErrorNotConnectedToInternet (-1009), or else the user would unexpectedly be logged out. It's also important to note that the same AuthorizationValueProvider instance must be used by all the calls: using different ones would mean using different queues making the entire solution ineffective. It seemed clear that the network client we developed in-house had to embrace JWT refresh logic at its core so that all the API calls, even new ones that will be added in the future would make use of the same authentication flow. General recommendations Here are a couple more (minor) suggestions we thought are worth sharing since they might save you implementation time or influence the design of your solution. Correctly parse the Payload Another problem - even though quite trivial and that doesn't seem to be discussed much - is the parsing of the JWT, that can fail in some cases. In our case, this was related to the base64 encoding function and "adjusting" the base64 payload to be parsed correctly. In some implementations of base64, the padding character is not needed for decoding, since the number of missing bytes can be calculated but in Foundation's implementation it is mandatory. This caused us some head-scratching and this StackOverflow answer helped us. The solution is - more officially - stated in RFC 7515 - Appendix C and here is the corresponding Swift code: func base64String(_ input: String) -> String { var base64 = input .replacingOccurrences(of: "-", with: "+") .replacingOccurrences(of: "_", with: "/") switch base64.count % 4 { case 2: base64 = base64.appending("==") case 3: base64 = base64.appending("=") default: break } return base64 } The majority of the developers rely on external libraries to ease the parsing of the token, but as we often do, we have implemented our solution from scratch, without relying on a third-party library. Nonetheless, we feel JSONWebToken by Kyle Fuller is a very good one and it seems to implement JWT faithfully to the RFC, clearly including the necessary base64 decode function. Handle multiple JWT for multiple app states As previously stated, when using JWT as an authentication method for non-user- authenticated calls, we need to cater for at least 3 states, shown in the following enum: enum AuthenticationStatus { case notAuthenticated case clientAuthenticated case userAuthenticated } On a fresh install, we can expect to be in the .notAuthenticated state, but as soon as the first API call is ready to be performed, a valid Client JWT has to be fetched and stored locally (at this stage, other authentication mechanisms are used, most likely Basic Auth), moving to the .clientAuthenticated state. Once the user completes the login or signup procedure, a User JWT is retrieved and stored locally (but separately to the Client JWT), entering the .userAuthenticated, so that in the case of a logout we are left with a (hopefully still valid) Client JWT. In this scenario, almost all transitions are possible: A couple of recommendations here: if the user is logged in is important to use the User JWT also for the non-user-authenticated calls as the server may personalise the response (e.g. the list of restaurants in the Just Eat app) store both Client and User JWT, so that if the user logs out, the app is left with the Client JWT ready to be used to perform non-user-authenticated requests, saving an unnecessary call to fetch a new token Conclusion In this article, we've shared some learnings from handling JWT on mobile that are not commonly discussed within the community. As a good practice, it's always best to hide complexity and implementation details. Baking the refresh logic described above within your API client is a great way to avoid developers having to deal with complex logic to provide authorization, and enables all the API calls to undergo the same authentication mechanism. Consumers of an API client, should not have the ability to gather the JWT as it’s not their concern to use it or to fiddle with it. We hope this article helps to raise awareness on how to better handle the usage of JWT on mobile applications, in particular making sure we always do our best to avoid accidental logouts to provide a better user experience.

At Just Eat we have experimentation and feature flagging at our heart and we've developed a component, named JustTweak, to make things easier on iOS.

How the iOS team at Just Eat built a scalable open-source solution to handle local and remote flags. Originally published on the Just Eat Engineering Blog. Overview At Just Eat we have experimentation at our heart, and it is very much dependent on feature flagging/toggling. If we may be so bold, here's an analogy: feature flagging is to experimentation as machine learning is to AI, you cannot have the second without the first one. We've developed an in-house component, named JustTweak, to handle feature flags and experiments on iOS without the hassle. We open-sourced JustTweak on github.com in 2017 and we have been evolving it ever since; in particular, with support for major experimentation platforms such as Optimizely and Firebase Remote Config. JustTweak has been instrumental in evolving the consumer Just Eat app in a fast and controlled manner, as well as to support a large number of integrations and migrations happening under the hood. In this article, we describe the feature flagging architecture and engine, with code samples and integration suggestions. What is feature flagging Feature flagging, in its original form, is a software development technique that provides an alternative to maintaining multiple source-code branches, so that a feature can be tested even before it is completed and ready for release. Feature flags are used in code to show/hide or enable/disable specific features at runtime. The technique also allows developers to release a version of a product that has unfinished features, that can be hidden from the user. Feature toggles also allow shorter software integration cycles and small incremental versions of software to be delivered without the cost of constant branching and merging - needless to say, this is crucial to have on iOS due to the App Store review process not allowing continuous delivery. A boolean flag in code is used to drive what code branch will run, but the concept can easily be extended to non-boolean flags, making them more of configuration flags that drive behavior. As an example, at Just Eat we have been gradually rewriting the whole application over time, swapping and customizing entire modules via configuration flags, allowing gradual switches from old to new features in a way transparent to the user. Throughout this article, the term 'tweaks' is used to refer to feature/configuration flags. A tweak can have a value of different raw types, namely Bool, String, Int, Float, and Double. Boolean tweaks can be used to drive features, like so: let isFeatureXEnabled: Bool = ... if isFeatureXEnabled { // show feature X } else { // don't show feature X } Other types of tweaks are instead useful to customise a given feature. Here is an example of configuring the environment using tweaks: let publicApiHost: String = ... let publicApiPort: Int? = ... let endpoint = Endpoint(scheme: "https", host: publicApiHost, port: publicApiPort, path: "/restaurant/:id/menu") // perform a request using the above endpoint object Problem The crucial part to get right is how and from where the flag values (isFeatureXEnabled, publicApiHost, and publicApiPort in the examples above) are fetched. Every major feature flagging/experimentation platform in the market provides its own way to fetch the values, and sometimes the APIs to do so significantly differ (e.g. Firebase Remote Config Vs Optimizely). Aware of the fact that it’s increasingly difficult to build any kind of non-trivial app without leveraging external dependencies, it's important to bear in mind that external dependencies pose a great threat to the long term stability and viability of any application. Following are some issues related to third-party experimentation solutions: third-party SDKs are not under your control using third-party SDKs in a modular architected app would easily cause dependency hell third-party SDKs are easily abused and various areas of your code will become entangled with them your company might decide to move to a different solution in the future and such switch comes with costs depending on the adopted solution, you might end up tying your app more and more to the platform-specific features that don't find correspondence elsewhere it is very hard to support multiple feature flag providers For the above reasons, it is best to hide third-party SDKs behind some sort of a layer and to implement an orchestration mechanism to allow fetching of flag values from different providers. We'll describe how we've achieved this in JustTweak. A note on the approach When designing software solutions, a clear trait was identified over time in the iOS team, which boils down to the kind of mindset and principle been used: Always strive to find solutions to problems that are scalable and hide complexity as much as possible. One word you would often hear if you were to work in the iOS team is 'Facade', which is a design pattern that serves as a front-facing interface masking more complex underlying or structural code. Facades are all over the place in our code: we try to keep components' interfaces as simple as possible so that other engineers could utilize them with minimal effort without necessarily knowing the implementation details. Furthermore, the more succinct an interface is, the rarer the possibility of misusages would be. We have some open source components embracing this approach, such as JustPersist, JustLog, and JustTrack. JustTweak makes no exception and the code to integrate it successfully in a project is minimal. Sticking to the above principle, the idea behind JustTweak is to have a single entry point to gather flag values, hiding the implementation details regarding which source the flag values are gathered from. JustTweak to the rescue JustTweak provides a simple facade interface interacting with multiple configurations that are queried respecting a certain priority. Configurations wrap specific sources of tweaks, that are then used to drive decisions or configurations in the client code. You can find JustTweak on CocoaPods and it's on version 5.0.0 at the time of writing. We plan to add support for Carthage and Swift Package Manager in the future. A demo app is also available for you to try it out. With JustTweak you can achieve the following: use a JSON local configuration providing default tweak values use a number of remote configuration providers, such as Firebase and Optmizely, to run A/B tests and feature flagging enable, disable, and customize features locally at runtime provide a dedicated UI for customization (this comes particularly handy for features that are under development to showcase the progress to stakeholders) Here is a screenshot of the TweakViewController taken from the demo app. Tweak values changed via this screen are immediately available to your code at runtime. Stack setup The facade class previously mentioned is represented by the TweakManager. There should only be a single instance of the manager, ideally configured at startup, passed around via dependency injection, and kept alive for the whole lifespan of the app. Following is an example of the kind of stack implemented as a static let. static let tweakManager: TweakManager = { // mutable configuration (to override tweaks from other configurations) let userDefaultsConfiguration = UserDefaultsConfiguration(userDefaults: .standard) // remote configurations (optional) let optimizelyConfiguration = OptimizelyConfiguration() let firebaseConfiguration = FirebaseConfiguration() // local JSON configuration (default tweaks) let jsonFileURL = Bundle.main.url(forResource: "Tweaks", withExtension: "json")! let localConfiguration = LocalConfiguration(jsonURL: jsonFileURL) // priority is defined by the order in the configurations array // (from highest to lowest) let configurations: [Configuration] = [userDefaultsConfiguration, optimizelyConfiguration, firebaseConfiguration, localConfiguration] return TweakManager(configurations: configurations) }() ``` JustTweak comes with three configurations out-of-the-box: UserDefaultsConfiguration which is mutable and uses UserDefaults as a key/value store LocalConfiguration which is read-only and uses a JSON configuration file that is meant to be the default configuration EphemeralConfiguration which is simply an instance of NSMutableDictionary Besides, JustTweak defines Configuration and MutableConfiguration protocols you can implement to create your own configurations to fit your needs. In the example project, you can find a few example configurations which you can use as a starting point. You can have any source of flags via wrapping it in a concrete implementation of the above protocols. Since the protocol methods are synchronous, you'll have to make sure that the underlying source has been initialised as soon as possible at startup. All the experimentation platforms provide mechanisms to do so, for example here is how Optimizely does it. The order of the objects in the configurations array defines the configurations' priority. The MutableConfiguration with the highest priority, such as UserDefaultsConfiguration in the example above, will be used to reflect the changes made in the UI (TweakViewController). The LocalConfiguration should have the lowest priority as it provides the default values from a local JSON file. It's also the one used by the TweakViewController to populate the UI. When fetching a tweak, the engine will inspect the chain of configurations in order and pick the tweak from the first configuration having it. The following diagram outlines a possible setup where values present in Optimizely override others in the subsequent configurations. Eventually, if no override is found, the local configuration would return the default tweak baked in the app. Structuring the stack this way brings various advantages: the same engine is used to customise the app for development, production, and test runs consumers only interface with the facade and can ignore the implementation details new code put behind flags can be shipped with confidence since we rely on a tested engine ability to remotely override tweaks de facto allowing to greatly customise the app without the need for a new release TweakManager gets populated with the tweaks listed in the JSON file used as backing store of the LocalConfiguration instance. It is therefore important to list every supported tweak in there so that development builds of the app can allow tweaking the values. Here is an excerpt from the file used in the TweakViewController screenshot above. { "ui_customization": { "display_red_view": { "Title": "Display Red View", "Description": "shows a red view in the main view controller", "Group": "UI Customization", "Value": false }, ... "red_view_alpha_component": { "Title": "Red View Alpha Component", "Description": "defines the alpha level of the red view", "Group": "UI Customization", "Value": 1.0 }, "label_text": { "Title": "Label Text", "Description": "the title of the main label", "Group": "UI Customization", "Value": "Test value" } }, "general": { "greet_on_app_did_become_active": { "Title": "Greet on app launch", "Description": "shows an alert on applicationDidBecomeActive", "Group": "General", "Value": false }, ... } } Testing considerations We've seen that the described architecture allows customization via configurations. We've shown in the above diagram that JustTweak can come handy when used in conjunction with our AutomationTools framework too, which is open-source. An Ephemeral configuration would define the app environment at run-time greatly simplifying the implementation of UI tests, which is well-known to be a tedious activity. Usage The two main features of JustTweak can be accessed from the TweakManager. Checking if a feature is enabled // check for a feature to be enabled let isFeatureXEnabled = tweakManager.isFeatureEnabled("feature_X") if isFeatureXEnabled { // show feature X } else { // hide feature X } Getting and setting the value of a flag for a given feature/variable. JustTweak will return the value from the configuration with the highest priority that provides it, or nil if none of the configurations have that feature/variable. // check for a tweak value let tweak = tweakManager.tweakWith(feature: <#feature_key#>, variable: <#variable_key#>") if let tweak = tweak { // tweak was found in some configuration, use tweak.value } else { // tweak was not found in any configuration } The Configuration and MutableConfiguration protocols define the following methods: func tweakWith(feature: String, variable: String) -> Tweak? func set(_ value: TweakValue, feature: String, variable: String) func deleteValue(feature: String, variable: String) You might wonder why is there a distinction between feature and variable. The reason is that we want to support the Optimizely lingo for features and related variables and therefore the design of JustTweak has to necessarily reflect that. Other experimentation platforms (such as Firebase) have a single parameter key, but we had to harmonise for the most flexible platform we support. Property Wrappers With SE-0258, Swift 5.1 introduces Property Wrappers. If you haven't read about them, we suggest you watch the WWDC 2019 "Modern Swift API Design talk where Property Wrappers are explained starting at 23:11. In short, a property wrapper is a generic data structure that encapsulates read/write access to a property while adding some extra behavior to augment its semantics. Common examples are @AtomicWrite and @UserDefault but more creative usages are up for grabs and we couldn't help but think of how handy it would be to have property wrappers for feature flags, and so we implemented them. @TweakProperty and @OptionalTweakProperty are available to mark properties representing feature flags. Here are a couple of examples, making the code so much nicer than before. @TweakProperty(fallbackValue: <#default_value#>, feature: <#feature_key#>, variable: <#variable_key#>, tweakManager: tweakManager) var isFeatureXEnabled: Bool @TweakProperty(fallbackValue: <#default_value#>, feature: <#feature_key#>, variable: <#variable_key#>, tweakManager: tweakManager) var publicApiHost: String @OptionalTweakProperty(fallbackValue: <#default_value_or_nil#>, feature: <#feature_key#>, variable: <#variable_key#>, tweakManager: tweakManager) var publicApiPort: Int? Mind that by using these property wrappers, a static instance of TweakManager must be available. Update a configuration at runtime JustTweak comes with a ViewController that allows the user to edit the tweaks while running the app. That is achieved by using the MutableConfiguration with the highest priority from the configurations array. This is de facto a debug menu, useful for development and internal builds but not to include in release builds. #if DEBUG func presentTweakViewController() { let tweakViewController = TweakViewController(style: .grouped, tweakManager: tweakManager) // either present it modally or push it on a UINavigationController } #endif Additionally, when a value is modified in any MutableConfiguration, a notification is fired to give the clients the opportunity to react and reflect changes in the UI. override func viewDidLoad() { super.viewDidLoad() NotificationCenter.defaultCenter().addObserver(self, selector: #selector(updateUI), name: TweakConfigurationDidChangeNotification, object: nil) } @objc func updateUI() { // update the UI accordingly } A note on modular architecture It's reasonable to assume that any non-trivial application approaching 2020 is composed of a number of modules and our Just Eat iOS app surely is too. With more than 30 modules developed in-house, it's crucial to find a way to inject flags into the modules but also to avoid every module to depend on an external library such as JustTweak. One way to achieve this would be: define one or more protocols in the module with the set of properties desired structure the modules to allow dependency injection of objects conforming to the above protocol implement logic in the module to consume the injected objects For instance, you could have a class wrapping the manager like so: protocol ModuleASettings { var isFeatureXEnabled: Bool { get } } protocol ModuleBSettings { var publicApiHost: String { get } var publicApiPort: Int? { get } } import JustTweak public class AppConfiguration: ModuleASettings, ModuleBSettings { static let tweakManager: TweakManager = { ... } @TweakProperty(...) var isFeatureXEnabled: Bool @TweakProperty(...) var publicApiHost: String @OptionalTweakProperty(...) var publicApiPort: Int? } Future evolution With recent versions of Swift and especially with 5.1, developers have a large set of powerful new tools, such as generics, associated types, opaque types, type erasure, etc. With Combine and SwiftUI entering the scene, developers are also starting adopting new paradigms to write code. Sensible paths to evolve JustTweak could be to have the Tweak object be generic on TweakValue have TweakManager be an ObservableObject which will enable publishing of events via Combine, and use @EnvironmentObject to ease the dependency injection in the SwiftUI view hierarchy. While such changes will need time to be introduced since our contribution to JustTweak is in-line with the evolution of the Just Eat app (and therefore a gradual adoption of SwiftUI), we can't wait to see them implemented. If you desire to contribute, we are more than happy to receive pull requests. Conclusion In this article, we illustrated how JustTweak can be of great help in adding flexible support to feature flagging. Integrations with external providers/experimentation platforms such as Optimizely, allow remote override of flags without the need of building a new version of the app, while the UI provided by the framework allows local overrides in development builds. We've shown how to integrate JustTweak in a project, how to setup a reasonable stack with a number of configurations and we’ve given you some guidance on how to leverage it when writing UI tests. We believe JustTweak to be a great tool with no similar open source alternatives nor proprietary ones and we hope developers will adopt it more and more.

How the iOS team at Just Eat built a scalable architecture to support navigation and deep linking.

Originally published on the Just Eat Engineering Blog.

In this article, we propose an architecture to implement a scalable solution to Deep Linking on iOS using an underlying Flow Controller-based architecture, all powered

How the iOS team at Just Eat built a scalable architecture to support navigation and deep linking. Originally published on the Just Eat Engineering Blog. In this article, we propose an architecture to implement a scalable solution to Deep Linking on iOS using an underlying Flow Controller-based architecture, all powered by a state machine and the Futures & Promises paradigm to keep the code more readable. At Just Eat, we use a dedicated component named NavigationEngine that is domain-specific to the Just Eat apps and their use cases. A demo project named NavigationEngineDemo that includes the NavigationEngine architecture (stripped out of many details not necessary to showcase the solution) is available on GitHub. Overview Deep linking is one of the most underestimated problems to solve on mobile. A naïve explanation would say that given some sort of input, mobile apps can load a specific screen, but it only has practical meaning when combined with Universal Links on iOS and App Links on Android. In such cases, the input is a URL that would load a web page on the companion website. Let's use an example from Just Eat: opening the URL https://www.just-eat.co.uk/area/ec4m-london on a web browser would load the list of restaurants in the UK London area for the postcode EC4M. Deep linking to the mobile apps using the same URL should give a similar experience to the user. In reality, the problem is more complex than what it seems at first glance; non-tech people - and sometimes even developers - find it hard to grasp. Loading a web page in a browser is fundamentally different from implementing dedicated logic on mobile to show a UIViewController (iOS) or Activity (Android) to the user and populate it with information that will most likely be gathered from an API call. The logic to perform deep linking starts with parsing the URL, understanding the intent, constructing the user journey, performing the navigation to the target screen passing the info all the way down, and ultimately loading any required data asynchronously from a remote API. On top of all this, it also has to consider the state of the app: the user might have previously left the app in a particular state and dedicated logic would be needed to deep link from the existing to the target screen. A scenario to consider is when the user is not logged in and therefore some sections of the app may not be available. Deep linking can actually be triggered from a variety of sources: Safari web browser any app that allows tapping on a link (iMessage, Notes, etc.) any app that explicitly tries to open the app using custom URL schemes the app itself (to perform jumps between sections) TodayExtension Shortcut items (Home Screen Quick Actions) Spotlight items It should be evident that implementing a comprehensive and scalable solution that fully addresses deep linking is far from being trivial. It shouldn't be an after-thought but rather be baked into the app architecture from the initial app design. It should also be quite glaring what the main problem that needs to be solved first is: the app Navigation. Navigation itself is not a problem with a single solution (if it was, the solution would be provided by Apple/Google and developers would simply stick to it). A number of solutions were proposed over the years trying to make it simpler and generic to some degree - Router, Compass, XCoordinator to name just a few open-source components. I proposed the concept of Flow Controllers in my article Flow Controllers on iOS for a better navigation control back in 2014 when the community had already (I believe) started shifting towards similar approaches. Articles such as Improve your iOS Architecture with FlowControllers (by Krzysztof Zabłocki), A Better MVC, Part 2: Fixing Encapsulation (by Dave DeLong), Flow Coordinators in iOS (by Dennis Walsh), and even as recently as 2019, Navigation with Flow Controllers (by Majid Jabrayilov) was published. To me, all the proposals share one main common denominator: flow controllers/coordinator and their API are necessarily domain-specific. Consider the following methods taken from one of the articles mentioned above referring to specific use cases: func showLoginViewController() { ... } func showSignupViewController() { ... } func showPasswordViewController() { ... } With the support of colleagues and friends, I tried proposing a generic and abstract solution but ultimately hit a wall. Attempts were proposed using enums to list the supported transitions (as XCoordinator shows in its README for instance) or relying on meta-programming dark magic in Objective-C (which is definitely the sign of a terrible design), neither of which satisfied me in terms of reusability and abstraction. I ultimately realized that it's perfectly normal for such problem to be domain-specific and that we don't necessarily have to find abstract solutions to all problems. Terminology For clarity on some of the terminology used in this article. Deep Linking: the ability to reach specific screens (via a flow) in the app either via a Deep Link or a Universal Link. Deep Link: URI with custom scheme (e.g. just-eat://just-eat.co.uk/login, just-eat-dk://just-eat.co.uk/settings) containing the information to perform deep linking in the app. When it comes to deep links, the host is irrelevant but it's good to keep it as part of the URL since it makes it easier to construct the URL using URLComponents and it keeps things more 'standard'. Universal Link: URI with http/https scheme (e.g. https://just-eat.co.uk/login) containing the information to perform deep linking in the app. Intent: the abstract intent of reaching a specific area of the app. E.g. goToOrderDetails(OrderId). State machine transition: transitions in the state machine allow navigating to a specific area in the app (state) from another one. If the app is in a state where the deep linking to a specific screen should not be allowed, the underlying state machine should not have the corresponding transition. Solution NavigationEngine is the iOS module (pod) used by the teams at Just Eat, that holds the isolated logic for navigation and deep linking. As mentioned above, the magic sauce includes the usage of: FlowControllers to handle the transitions between ViewControllers in a clear and pre-defined way. Stateful state machines to allow transitions according to the current application state. More information on FSM (Finite State Machine) here and on the library at The easiest State Machine in Swift. Promis to keep the code readable using Futures & Promises to help avoiding the Pyramid of doom. Sticking to such a paradigm is also a key aspect for the whole design since every API in the stack is async. More info on the library at The easiest Promises in Swift. a pretty heavy amount of 🧠 NavigationEngine maintains separation of concerns between URL Parsing, Navigation, and Deep Linking. Readers can inspect the code in the NavigationEngineDemo project that also includes unit tests with virtually 100% code coverage. Following is an overview of the class diagram of the entire architecture stack. Architecture class diagram While the navigation is powered by a FlowController-based architecture, the deep linking logic is powered by NavigationIntentHandler and NavigationTransitioner (on top of the navigation stack). Note the single entry point named DeepLinkingFacade exposes the following API to cover the various input/sources we mentioned earlier: public func handleURL(_ url: URL) -> Future<Bool> public func openDeepLink(_ deepLink: DeepLink) -> Future<Bool> public func openShortcutItem(_ item: UIApplicationShortcutItem) -> Future<Bool> public func openSpotlightItem(_ userActivity: NSUserActivityProtocol) -> Future<Bool> Here are the sequence diagrams for each one. Refer to the demo project to inspect the code. Navigation As mentioned earlier, the important concept to grasp is that there is simply no single solution to Navigation. I've noticed that such a topic quickly raises discussions and each engineer has different, sometimes strong opinions. It's more important to agree on a working solution that satisfies the given requirements rather than forcing personal preferences. Our NavigationEngine relies on the following navigation rules (based on Flow Controllers): FlowControllers wire up the domain-specific logic for the navigation ViewControllers don't allocate FlowControllers Only FlowControllers, AppDelegate and similar top-level objects can allocate ViewControllers FlowControllers are owned (retained) by the creators FlowControllers can have children FlowControllers and create a parent-child chain and can, therefore, be in a 1-to-many relationship FlowControllers in parent-child relationships communicate via delegation ViewControllers have weak references to FlowControllers ViewControllers are in a 1-to-1 relationship with FlowControllers All the FlowController domain-specific API must be future-based with Future<Bool> as return type Deep linking navigation should occur with no more than one animation (i.e. for long journeys, only the last step should be animated) Deep linking navigation that pops a stack should occur without animation In the demo project, there are a number of *FlowControllerProtocols, each corresponding to a different section/domain of the hosting app. Examples such as RestaurantsFlowControllerProtocol and OrdersFlowControllerProtocol are taken from the Just Eat app and each one has domain specific APIs, e.g: func goToSearchAnimated(postcode: Postcode?, cuisine: Cuisine?, animated: Bool) -> Future<Bool> func goToOrder(orderId: OrderId, animated: Bool) -> Future<Bool> func goToRestaurant(restaurantId: RestaurantId) -> Future<Bool> func goToCheckout(animated: Bool) -> Future<Bool> Note that each one: accepts the animated parameter returns Future<Bool> so that flow sequence can be combined Flow controllers should be combined sensibly to represent the app UI structure. In the case of Just Eat we have a RootFlowController as the root-level flow controller orchestrating the children. A FlowControllerProvider, used by the NavigationTransitioner, is instead the single entry point to access the entire tree of flow controllers. NavigationTransitioner provides an API such as: func goToLogin(animated: Bool) -> Future<Bool> func goFromHomeToSearch(postcode: Postcode?, cuisine: Cuisine?, animated: Bool) -> Future<Bool> This is responsible to keep the underlying state machine and what the app actually shows in sync. Note the goFromHomeToSearch method being verbose on purpose; it takes care of the specific transition from a given state (home). One level up in the stack, NavigationIntentHandler is responsible for combining the actions available from the NavigationTransitioner starting from a given NavigationIntent and creating a complete deep linking journey. It also takes into account the current state of the app. For example, showing the history of the orders should be allowed only if the user is logged in, but it would also be advisable to prompt the user to log in in case he/she is not, and then resume the original action. Allowing so provides a superior user experience rather than simply aborting the flow (it's what websites achieve by using the referring URL). Here is the implementation of the .goToOrderHistory intent in the NavigationIntentHandler: case .goToOrderHistory: switch userStatusProvider.userStatus { case .loggedIn: return navigationTransitioner.goToRoot(animated: false).thenWithResult { _ -> Future<Bool> in self.navigationTransitioner.goToOrderHistory(animated: true) } case .loggedOut: return navigationTransitioner.requestUserToLogin().then { future in switch future.state { case .result: return self.handleIntent(intent) // go recursive default: return Future<Bool>.futureWithResolution(of: future) } } } Since in the design we make the entire API future-based, we can potentially interrupt the deep linking flow to prompt the user for details or simply gather missing information from a remote API. This is crucial and allows us to construct complex flows. By design, all journeys start by resetting the state of the app by calling goToRoot. This vastly reduces the number of possible transitions to take care of as we will describe in more detail in the next section dedicated to the underlying state machine. State Machine As you might have realized by now, the proposed architecture makes use of an underlying Finite State Machine to keep track of the state of the app during a deep linking journey. Here is a simplified version of the state machine configurations used in the Just Eat iOS apps. In the picture, the red arrows are transitions that are available for logged in users only, the blue ones are for logged out users only, while the black ones can always be performed. Note that every state should allow going back to the .allPoppedToRoot state so that, regardless of what the current state of the app is, we can always reset the state and perform a deep linking action starting afresh. This drastically simplifies the graph, avoiding unnecessary transitions such as the one shown in the next picture. Notice that intents (NavigationIntent) are different from transitions (NavigationEngine.StateMachine.EventType). An intent contains the information to perform a deep linking journey, while the event type is the transition from one FSM state to another (or the same). NavigationTransitioner is the class that performs the transitions and applies the companion navigation changes. A navigation step is performed only if the corresponding transition is allowed and completed successfully. If a transition is not allowed, the flow is interrupted, reporting an error in the future. You can showcase a failure in the demo app by trying to follow the Login Universal Link (https://just-eat.co.uk/login) after having faked the login when following the Order History Universal Link (https://just-eat.co.uk/orders). Usage NavigationEngineDemo includes the whole stack that readers can use in client projects. Here are the steps for a generic integration of the code. Add the NavigationEngine stack (NavigationEngineDemo/NavigationEngine folder) to the client project. This can be done by either creating a dedicated pod as we do at Just Eat or by directly including the code. Include Promis and Stateful as dependencies in your Podfile (assuming the usage of Cocoapods). Modify according to your needs, implement classes for all the *FlowControllerProtocols, and connect them to the ViewControllers of the client. This step can be quite tedious depending on the status of your app and we suggest trying to mimic what has been done in the demo app. Add CFBundleTypeRole and CFBundleURLSchemes to the main target Info.plist file to support Deep Links. E.g. <key>CFBundleURLTypes</key> <array> <dict> <key>CFBundleTypeRole</key> <string>Editor</string> <key>CFBundleURLSchemes</key> <array> <string>je-internal</string> <string>justeat</string> <string>just-eat</string> <string>just-eat-uk</string> </array> </dict> </array> Add the applinks (in the Capabilities -> Associated Domains section of the main target) you'd like to support. This will allow iOS to register the app for Universal Links on the given domains looking for the apple-app-site-association file at the root of those domains once the app is installed. E.g. Implement concrete classes for DeepLinkingSettingsProtocol and UserStatusProviding according to your needs. Again, see the examples in the demo project. The internalDeepLinkSchemes property in DeepLinkSettingsProtocol should contain the same values previously added to CFBundleURLSchemes, while the universalLinkHosts should contain the same applinks: values defined in Capabilities -> Associated Domains. Setup the NavigationEngine stack in the AppDelegate's applicationDidFinishLaunching. To some degree, it should be something similar to the following: var window: UIWindow? var rootFlowController: RootFlowController! var deepLinkingFacade: DeepLinkingFacade! var userStatusProvider = UserStatusProvider() let deepLinkingSettings = DeepLinkingSettings() func applicationDidFinishLaunching(_ application: UIApplication) { // Init UI Stack let window = UIWindow(frame: UIScreen.main.bounds) let tabBarController = TabBarController.instantiate() // Root Flow Controller rootFlowController = RootFlowController(with: tabBarController) tabBarController.flowController = rootFlowController // Deep Linking core let flowControllerProvider = FlowControllerProvider(rootFlowController: rootFlowController) deepLinkingFacade = DeepLinkingFacade(flowControllerProvider: flowControllerProvider, navigationTransitionerDataSource: self, settings: deepLinkingSettings, userStatusProvider: userStatusProvider) // Complete UI Stack window.rootViewController = tabBarController window.makeKeyAndVisible() self.window = window } Modify NavigationTransitionerDataSource according to your needs and implement its methods. You might want to have a separate component and not using the AppDelegate. extension AppDelegate: NavigationTransitionerDataSource { func navigationTransitionerDidRequestUserToLogin() -> Future<Bool> { <#async logic#> } ... } Implement the entry points for handling incoming URLs/inputs in the AppDelegate: func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool { // from internal deep links & TodayExtension deepLinkingFacade.openDeeplink(url).finally { future in <#...#> } return true } func application(_ application: UIApplication, continue userActivity: NSUserActivity, restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void) -> Bool { switch userActivity.activityType { // from Safari case NSUserActivityTypeBrowsingWeb: if let webpageURL = userActivity.webpageURL { self.deepLinkingFacade.handleURL(webpageURL).finally { future in <#...#> } return true } return false // from Spotlight case CSSearchableItemActionType: self.deepLinkingFacade.openSpotlightItem(userActivity).finally { future in let originalInput = userActivity.userInfo![CSSearchableItemActivityIdentifier] as! String <#...#> } return true default: return false } } func application(_ application: UIApplication, performActionFor shortcutItem: UIApplicationShortcutItem, completionHandler: @escaping (Bool) -> Void) { // from shortcut items (Home Screen Quick Actions) deepLinkingFacade.openShortcutItem(shortcutItem).finally { future in let originalInput = shortcutItem.type <#...#> completionHandler(future.hasResult()) } } N.B. Since a number of tasks are usually performed at startup (both from cold and warm starts), it's suggested to schedule them using operation queues. The deep linking task should be one of the last tasks in the queue to make sure that dependencies are previously set up. Here is the great Advanced NSOperations talk by Dave DeLong from WWDC15. The UniversalLinkConverter class should be modified to match the paths in the apple-app-site-association, which should be reachable at the root of the website (the associated domain). It should be noted that if the app is opened instead of the browser, it would be because the Universal Link can be handled; and redirecting the user back to the web would be a fundamental mistake that should be solved by correctly defining the supported paths in the apple-app-site-association file. To perform internal app navigation via deep linking, the DeeplinkFactory class should be used to create DeepLink objects that can be fed into either handleURL(_ url: URL) or openDeepLink(_ deepLink: DeepLink). In-app testing The module exposes a DeepLinkingTesterViewController that can be used to easily test deep linking within an app. Simply define a JSON file containing the Universal Links and Deep Links to test: { "universal_links": [ "https://just-eat.co.uk/", "https://just-eat.co.uk/home", "https://just-eat.co.uk/login", ... ], "deep_links": [ "JUSTEAT://irrelev.ant/home", "justeat://irrelev.ant/login", "just-eat://irrelev.ant/resetPassword?resetToken=xyz", ... ] } Then feed it to the view controller as shown below. Alternatively, use a storyboard reference as shown in the demo app. let deepLinkingTesterViewController = DeepLinkingTesterViewController.instantiate() deepLinkingTesterViewController.delegate = self let path = Bundle.main.path(forResource: "deeplinking_test_list", ofType: "json")! deepLinkingTesterViewController.loadTestLinks(atPath: path) and implement the DeepLinkingTesterViewControllerDelegate extension AppDelegate: DeepLinkingTesterViewControllerDelegate { func deepLinkingTesterViewController(_ deepLinkingTesterViewController: DeepLinkingTesterViewController, didSelect url: URL) { self.deepLinkingFacade.handleURL(universalLink).finally { future in self.handleFuture(future, originalInput: universalLink.absoluteString) } } } Conclusion The solution proposed in this article has proven to be highly scalable and customizable. We shipped it in the Just Eat iOS apps in March 2019 and our teams are gradually increasing the number of Universal Links supported as you can see from our apple-app-site-association. Before implementing and adopting NavigationEngine, supporting new kinds of links was a real hassle. Thanks to this architecture, it is now easy for each team in the company to support new deep link journeys. The declarative approach in defining the API, states, transitions, and intents forces a single way to extend the code which enables a coherent approach throughout the codebase.

Performant, sleek and elegant.

The author discusses challenges managing side projects, specifically updating SignalPath to Swift 6. They encountered errors related to multiple notification observations but resolved them by shifting to publishers, avoiding sendable closure issues. Although the new approach risks background thread notifications, the compiler is satisfied with the adjustments made to the code.

I have a couple of side projects going on, although it is always a challenge to find time of them. One of them, SignalPath, is what I created back in 2015. Currently, I have been spending some time to bump the Swift version to 6 which brought a quite a list of errors. In many places I had code what dealt with observing multiple notifications, but of course Swift 6 was not happy about it. This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters let handler: (Notification) -> Void = { [weak self] notification in self?.keyboardInfo = Info(notification: notification) } let names: [Notification.Name] = [ UIResponder.keyboardWillShowNotification, UIResponder.keyboardWillHideNotification, UIResponder.keyboardWillChangeFrameNotification ] observers = names.map({ name -> NSObjectProtocol in return NotificationCenter.default.addObserver(forName: name, object: nil, queue: .main, using: handler) // Converting non-sendable function value to '@Sendable (Notification) -> Void' may introduce data races }) view raw Observer.swift hosted with ❤ by GitHub After moving all of the notification observing to publishers instead, I can ignore the whole sendable closure problem all together. This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters Publishers.Merge3( NotificationCenter.default.publisher(for: UIResponder.keyboardWillShowNotification), NotificationCenter.default.publisher(for: UIResponder.keyboardWillHideNotification), NotificationCenter.default.publisher(for: UIResponder.keyboardWillChangeFrameNotification) ) .map(Info.init) .assignWeakly(to: \.keyboardInfo, on: self) .store(in: &notificationCancellables) view raw Observer.swift hosted with ❤ by GitHub Great, compiler is happy again although this code could cause trouble if any of the notifications are posted from a background thread. But since this is not a case here, I went for skipping .receive(on: DispatchQueue.main). Assign weakly is a custom operator and the implementation looks like this: This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters public extension Publisher where Self.Failure == Never { func assignWeakly<Root>(to keyPath: ReferenceWritableKeyPath<Root, Self.Output>, on object: Root) -> AnyCancellable where Root: AnyObject { return sink { [weak object] value in object?[keyPath: keyPath] = value } } } view raw Combine+Weak.swift hosted with ❤ by GitHub If this was helpful, please let me know on Mastodon@toomasvahter or Twitter @toomasvahter. Feel free to subscribe to RSS feed. Thank you for reading. Support me on Patreon Donate with Paypal Buy me a coffee

AnyClass is a protocol all classes conform to and it comes with a feature I was not aware of. But first, how to I ended up with using AnyClass. While working on code using CoreData, I needed a way to enumerate all the CoreData entities and call a static function on them. If that function […]

AnyClass is a protocol all classes conform to and it comes with a feature I was not aware of. But first, how to I ended up with using AnyClass. While working on code using CoreData, I needed a way to enumerate all the CoreData entities and call a static function on them. If that function is defined, it runs an entity specific update. Let’s call the function static func resetState(). It is easy to get the list of entity names of the model and then turn them into AnyClass instances using the NSClassFromString() function. This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters let entityClasses = managedObjectModel.entities .compactMap(\.name) .compactMap { NSClassFromString($0) } view raw AnyClass.swift hosted with ❤ by GitHub At this point I had an array of AnyClass instances where some of them implemented the resetState function, some didn’t. While browsing the AnyClass documentation, I saw this: You can use the AnyClass protocol as the concrete type for an instance of any class. When you do, all known @objcclass methods and properties are available as implicitly unwrapped optional methods and properties, respectively. Never heard about it, probably because I have never really needed to interact with AnyClass in such way. Therefore, If I create an @objc static function then I can call it by unwrapping it with ?. Without unwrapping it safely, it would crash because Department type does not implement the function. This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters class Department: NSManagedObject { } class Employee: NSManagedObject { @objc static func resetState() { print("Resetting Employee") } } // This triggers Employee.resetState and prints the message to the console for entityClass in entityClasses { entityClass.resetState?() } view raw AnyClass.swift hosted with ❤ by GitHub It has been awhile since I wrote any Objective-C code, but its features leaking into Swift helped me out here. Reminds me of days filled with respondsToSelector and performSelector. If this was helpful, please let me know on Mastodon@toomasvahter or Twitter @toomasvahter. Feel free to subscribe to RSS feed. Thank you for reading. Support me on Patreon Donate with Paypal Buy me a coffee

Xcode 16 introduces a new execution engine for Previews, enhancing project configuration support and improving performance by up to 30%. However, it wraps SwiftUI views in AnyView for debug builds, which can hinder optimization. Users can override this behavior with a custom build setting to maintain performance in debugging.

Loved to see this entry in Xcode 16’s release notes: Xcode 16 brings a new execution engine for Previews that supports a larger range of projects and configurations. Now with shared build products between Build and Run and Previews, switching between the two is instant. Performance between edits in the source code is also improved for many projects, with increases up to 30%. It has been difficult at times to use SwiftUI previews when they sometimes just stop working with error messages leaving scratch head. Turns out, it comes with a hidden cost of Xcode 16 wrapping views with AnyView in debug builds which takes away performance. If you don’t know it only affects debug builds, one could end up on journey of trying to improve the performance for debug builds and making things worse for release builds. Not sure if this was ever mentioned in any of the WWDC videos, but feels like this kind of change should have been highlighted. As of Xcode 16, every SwiftUI view is wrapped in an AnyView _in debug builds only_. This speeds switching between previews, simulator, and device, but subverts some List optimizations. Add this custom build setting to the project to override the new behavior: `SWIFT_ENABLE_OPAQUE_TYPE_ERASURE=NO` Wrapping in Equatable is likely to make performance worse as it introduces an extra view in the hierarchy for every row. Curt Clifton on Mastodon Fortunately, one can turn off this if this becomes an issue in debug builds. If this was helpful, please let me know on Mastodon@toomasvahter or Twitter @toomasvahter. Feel free to subscribe to RSS feed. Thank you for reading. Support me on Patreon Donate with Paypal Buy me a coffee

Swift’s foundation library provides a sorted(by:) function for sorting arrays. The areInIncreasingOrder closure needs to return true if the closure’s arguments are increasing, false otherwise. How to use the closure for sorting by multiple criteria? Let’s take a look at an example of sorting an array of Player structs. As said before, the closure should […]

Swift’s foundation library provides a sorted(by:) function for sorting arrays. The areInIncreasingOrder closure needs to return true if the closure’s arguments are increasing, false otherwise. How to use the closure for sorting by multiple criteria? Let’s take a look at an example of sorting an array of Player structs. Sort by score in descending order Sort by name in ascending order Sort by id in ascending order This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters struct Player { let id: Int let name: String let score: Int } extension Player: CustomDebugStringConvertible { var debugDescription: String { "id=\(id) name=\(name) score=\(score)" } } let players: [Player] = [ Player(id: 0, name: "April", score: 7), Player(id: 1, name: "Nora", score: 8), Player(id: 2, name: "Joe", score: 5), Player(id: 3, name: "Lisa", score: 4), Player(id: 4, name: "Michelle", score: 6), Player(id: 5, name: "Joe", score: 5), Player(id: 6, name: "John", score: 7) ] view raw Sort.swift hosted with ❤ by GitHub As said before, the closure should return true if the left element should be ordered before the right element. If they happen to be equal, we should use the next sorting criteria. For comparing strings, we’ll go for case-insensitive sorting using Foundation’s built-in localizedCaseInsensitiveCompare. This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters let sorted = players.sorted { lhs, rhs in if lhs.score == rhs.score { let nameOrdering = lhs.name.localizedCaseInsensitiveCompare(rhs.name) if nameOrdering == .orderedSame { return lhs.id < rhs.id } else { return nameOrdering == .orderedAscending } } else { return lhs.score > rhs.score } } print(sorted.map(\.debugDescription).joined(separator: "\n")) // id=1 name=Nora score=8 // id=0 name=April score=7 // id=6 name=John score=7 // id=4 name=Michelle score=6 // id=2 name=Joe score=5 // id=5 name=Joe score=5 // id=3 name=Lisa score=4 view raw Sort.swift hosted with ❤ by GitHub If this was helpful, please let me know on Mastodon@toomasvahter or Twitter @toomasvahter. Feel free to subscribe to RSS feed. Thank you for reading. Support me on Patreon Donate with Paypal Buy me a coffee

DateFormatter is used for converting string representation of date and time to a Date type and visa-versa. Something to be aware of is that the conversion loses microseconds precision. This is extremely important if we use these Date values for sorting and therefore ending up with incorrect order. Let’s consider an iOS app which uses […]

DateFormatter is used for converting string representation of date and time to a Date type and visa-versa. Something to be aware of is that the conversion loses microseconds precision. This is extremely important if we use these Date values for sorting and therefore ending up with incorrect order. Let’s consider an iOS app which uses API for fetching a list of items and each of the item contains a timestamp used for sorting the list. Often, these timestamps have the ISO8601 format like 2024-09-21T10:32:32.113123Z. Foundation framework has a dedicated formatter for parsing these strings: ISO8601DateFormatter. It is simple to use: This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters let formatter = ISO8601DateFormatter() formatter.formatOptions = [.withInternetDateTime, .withFractionalSeconds] let date = formatter.date(from: "2024-09-21T10:32:32.113123Z") print(date?.timeIntervalSince1970) // 1726914752.113 view raw ISO8601.swift hosted with ❤ by GitHub Great, but there is on caveat, it ignores microseconds. Fortunately this can be fixed by manually parsing microseconds and adding the missing precision to the converted Date value. Here is an example, how to do this using an extension. This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters extension ISO8601DateFormatter { func microsecondsDate(from dateString: String) -> Date? { guard let millisecondsDate = date(from: dateString) else { return nil } guard let fractionIndex = dateString.lastIndex(of: ".") else { return millisecondsDate } guard let tzIndex = dateString.lastIndex(of: "Z") else { return millisecondsDate } guard let startIndex = dateString.index(fractionIndex, offsetBy: 4, limitedBy: tzIndex) else { return millisecondsDate } // Pad the missing zeros at the end and cut off nanoseconds let microsecondsString = dateString[startIndex..<tzIndex].padding(toLength: 3, withPad: "0", startingAt: 0) guard let microseconds = TimeInterval(microsecondsString) else { return millisecondsDate } return Date(timeIntervalSince1970: millisecondsDate.timeIntervalSince1970 + microseconds / 1_000_000.0) } } view raw ISO8601.swift hosted with ❤ by GitHub That this code does is first converting the string using the original date(from:) method, followed by manually extracting digits for microseconds by handling cases where there are less than 3 digits or event there are nanoseconds present. Lastly a new Date value is created with the microseconds precision. Here are examples of the output (note that float’s precision comes into play). This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters let dateStrings = [ "2024-09-21T10:32:32.113Z", "2024-09-21T10:32:32.1131Z", "2024-09-21T10:32:32.11312Z", "2024-09-21T10:32:32.113123Z", "2024-09-21T10:32:32.1131234Z", "2024-09-21T10:32:32.11312345Z", "2024-09-21T10:32:32.113123456Z" ] let dates = dateStrings.compactMap(formatter.microsecondsDate(from:)) for (string, date) in zip(dateStrings, dates) { print(string, "->", date.timeIntervalSince1970) } /* 2024-09-21T10:32:32.113Z -> 1726914752.113 2024-09-21T10:32:32.1131Z -> 1726914752.1130998 2024-09-21T10:32:32.11312Z -> 1726914752.1131198 2024-09-21T10:32:32.113123Z -> 1726914752.113123 2024-09-21T10:32:32.1131234Z -> 1726914752.113123 2024-09-21T10:32:32.11312345Z -> 1726914752.113123 2024-09-21T10:32:32.113123456Z -> 1726914752.113123 */ view raw ISO8601.swift hosted with ❤ by GitHub If this was helpful, please let me know on Mastodon@toomasvahter or Twitter @toomasvahter. Feel free to subscribe to RSS feed. Thank you for reading. Support me on Patreon Donate with Paypal Buy me a coffee

It is not often when we need to wrap an async function with a completion handler. Typically, the reverse is what happens. This need can happen in codebases where the public interface can’t change just right now, but internally it is moving towards async-await functions. Let’s jump in and see how to wrap an async […]

It is not often when we need to wrap an async function with a completion handler. Typically, the reverse is what happens. This need can happen in codebases where the public interface can’t change just right now, but internally it is moving towards async-await functions. Let’s jump in and see how to wrap an async function, an async throwing function and an async throwing function what returns a value. To illustrate how to use it, we’ll see an example of how a PhotoEffectApplier type has a public interface consisting of completion handler based functions and how it internally uses PhotoProcessor type what only has async functions. The end result looks like this: This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters struct PhotoProcessor { func process(_ photo: Photo) async throws -> Photo { // … return Photo(name: UUID().uuidString) } func setConfiguration(_ configuration: Configuration) async throws { // … } func cancel() async { // … } } public final class PhotoEffectApplier { private let processor = PhotoProcessor() public func apply(effect: PhotoEffect, to photo: Photo, completion: @escaping (Result<Photo, Error>) -> Void) { Task(operation: { try await self.processor.process(photo) }, completion: completion) } public func setConfiguration(_ configuration: Configuration, completion: @escaping (Error?) -> Void) { Task(operation: { try await self.processor.setConfiguration(configuration) }, completion: completion) } public func cancel(completion: @escaping (Error?) -> Void) { Task(operation: { await self.processor.cancel() }, completion: completion) } } view raw PhotoEffectApplier.swift hosted with ❤ by GitHub In this example, we have all the interested function types covered: async, async throwing and async throwing with a return type. Great, but let’s have a look at these Task initializers what make this happen. The core idea is to create a Task, run an operation, and then make a completion handler callback. Since most of the time we need to run the completion on the main thread, then we have a queue argument with the default queue set to the main thread. This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters extension Task { @discardableResult init<T>( priority: TaskPriority? = nil, operation: @escaping () async throws -> T, queue: DispatchQueue = .main, completion: @escaping (Result<T, Failure>) -> Void ) where Success == Void, Failure == any Error { self.init(priority: priority) { do { let value = try await operation() queue.async { completion(.success(value)) } } catch { queue.async { completion(.failure(error)) } } } } } view raw AsyncThrowsValue.swift hosted with ❤ by GitHub This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters extension Task { @discardableResult init( priority: TaskPriority? = nil, operation: @escaping () async throws -> Void, queue: DispatchQueue = .main, completion: @escaping (Error?) -> Void ) where Success == Void, Failure == any Error { self.init(priority: priority) { do { try await operation() queue.async { completion(nil) } } catch { queue.async { completion(error) } } } } } view raw AsyncThrows.swift hosted with ❤ by GitHub This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters extension Task { @discardableResult init( priority: TaskPriority? = nil, operation: @escaping () async -> Void, queue: DispatchQueue = .main, completion: @escaping () -> Void ) where Success == Void, Failure == Never { self.init(priority: priority) { await operation() queue.async { completion() } } } } view raw Async.swift hosted with ❤ by GitHub If this was helpful, please let me know on Mastodon@toomasvahter or Twitter @toomasvahter. Feel free to subscribe to RSS feed. Thank you for reading. Support me on Patreon Donate with Paypal Buy me a coffee

After a couple of years, I tend to get tired of looking at the same colour scheme in Xcode. Then I spend quite a bit of time looking for a new theme and then coming back with empty hands. Material default has served me for a while, but it never felt like a perfect colour […]

After a couple of years, I tend to get tired of looking at the same colour scheme in Xcode. Then I spend quite a bit of time looking for a new theme and then coming back with empty hands. Material default has served me for a while, but it never felt like a perfect colour scheme for me. Therefore, I decided to take on a road of creating a new colour scheme on my own which is going to be named as “Augmented Code (Dark)”. It is available for Xcode and iTerm 2. Download it from here: GitHub If this was helpful, please let me know on Mastodon@toomasvahter or Twitter @toomasvahter. Feel free to subscribe to RSS feed. Thank you for reading. Support me on Patreon Donate with Paypal Buy me a coffee

Observation framework came out along with iOS 17 in 2023. Using this framework, we can make objects observable very easily. Please refer to @Observable macro in SwiftUI for quick recap if needed. It also has a function withObservationTracking(_:onChange:) what can be used for cases where we would want to manually get a callback when a tracked […]

Observation framework came out along with iOS 17 in 2023. Using this framework, we can make objects observable very easily. Please refer to @Observable macro in SwiftUI for quick recap if needed. It also has a function withObservationTracking(_:onChange:) what can be used for cases where we would want to manually get a callback when a tracked property is about to change. This function works as a one shot function and the onChange closure is called only once. Note that it is called before the value has actually changed. If we want to get the changed value, we would need to read the value on the next run loop cycle. It would be much more useful if we could use this function in a way where we could have an observation token and as long as it is set, the observation is active. Here is the function with cancellation support. This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters func withObservationTracking( _ apply: @escaping () -> Void, token: @escaping () -> String?, willChange: (@Sendable () -> Void)? = nil, didChange: @escaping @Sendable () -> Void ) { withObservationTracking(apply) { guard token() != nil else { return } willChange?() RunLoop.current.perform { didChange() withObservationTracking( apply, token: token, willChange: willChange, didChange: didChange ) } } } view raw Observation.swift hosted with ❤ by GitHub The apply closure drives which values are being tracked, and this is passed into the existing withObservationTracking(_:onChange:) function. The token closure controls if the change should be handled and if we need to continue tracking. Will and did change are closures called before and after the value has changed. Here is a simple example where we have a view which controls if the observation should be active or not. Changing the value in the view model only triggers the print lines when observation token is set. This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters struct ContentView: View { @State private var viewModel = ViewModel() @State private var observationToken: String? var body: some View { VStack { Text(viewModel.title) Button("Add") { viewModel.add() } Button("Start Observing") { guard observationToken == nil else { return } observationToken = UUID().uuidString observeAndPrint() } Button("Stop Observing") { observationToken = nil } } .padding() } func observeAndPrint() { withObservationTracking({ _ = viewModel.title }, token: { observationToken }, willChange: { [weak viewModel] in guard let viewModel else { return } print("will change \(viewModel.title)") }, didChange: { [weak viewModel] in guard let viewModel else { return } print("did change \(viewModel.title)") }) } } @Observable final class ViewModel { var counter = 0 func add() { counter += 1 } var title: String { "Number of items: \(counter)" } } view raw ContentView.swift hosted with ❤ by GitHub If this was helpful, please let me know on Mastodon@toomasvahter or Twitter @toomasvahter. Feel free to subscribe to RSS feed. Thank you for reading. Support me on Patreon Donate with Paypal Buy me a coffee

It took a long time, I mean years, but it finally happened. I stumbled on a struct which had a property of the same type. At first, it is kind of interesting that the replies property compiles fine, although it is a collection of the same type. I guess it is so because array’s storage […]

It took a long time, I mean years, but it finally happened. I stumbled on a struct which had a property of the same type. This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters struct Message { let id: Int // This is OK: let replies: [Message] // This is not OK // Value type 'Message' cannot have a stored property that recursively contains it let parent: Message? } view raw Struct.swift hosted with ❤ by GitHub At first, it is kind of interesting that the replies property compiles fine, although it is a collection of the same type. I guess it is so because array’s storage type is a reference type. The simplest workaround is to use a closure for capturing the actual value. This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters struct Message { let id: Int let replies: [Message] private let parentClosure: () -> Message? var parent: Message? { parentClosure() } } view raw Struct2.swift hosted with ❤ by GitHub Or we could go for using a boxed wrapper type. This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters struct Message { let id: Int let replies: [Message] private let parentBoxed: Boxed<Message>? var parent: Message? { parentBoxed?.value} } class Boxed<T> { let value: T init(value: T) { self.value = value } } view raw Struct3.swift hosted with ❤ by GitHub Or if we prefer property wrappers, using that instead. This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters struct Message { let id: Int let replies: [Message] @Boxed var parent: Message? } @propertyWrapper class Boxed<Value> { var value: Value init(wrappedValue: Value) { value = wrappedValue } var wrappedValue: Value { get { value } set { value = newValue } } } view raw Struct4.swift hosted with ❤ by GitHub Then there are also options like changing the struct into class instead, but that is something to consider. Or finally, creating a All in all, it is fascinating how something simple like this actually has a pretty complex background. If this was helpful, please let me know on Mastodon@toomasvahter or Twitter @toomasvahter. Feel free to subscribe to RSS feed. Thank you for reading. Support me on Patreon Donate with Paypal Buy me a coffee

In addition to scroll related view modifiers covered in the previous blog post, there is another one for detecting scroll view phases aka the state of the scrolling. The new view modifier is called onScrollPhaseChange(_:) and has three arguments in the change closure: old phase, new phase and a context. ScrollPhase is an enum with […]

In addition to scroll related view modifiers covered in the previous blog post, there is another one for detecting scroll view phases aka the state of the scrolling. The new view modifier is called onScrollPhaseChange(_:) and has three arguments in the change closure: old phase, new phase and a context. ScrollPhase is an enum with the following values: animating – animating the content offset decelerating – user interaction stopped and scroll velocity is decelerating idle – no scrolling interacting – user is interacting tracking – potential user initiated scroll event is going to happen The enum has a convenience property of isScrolling which is true when the phase is not idle. ScrollPhaseChangeContext captures additional information about the scroll state, and it is the third argument of the closure. The type gives access to the current ScrollGeometry and the velocity of the scroll view. Here is an example of a scroll view which has the new view modifier attached. This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters struct ContentView: View { @State private var scrollState: ( phase: ScrollPhase, context: ScrollPhaseChangeContext )? let data = (0..<100).map({ "Item \($0)" }) var body: some View { NavigationStack { ScrollView { ForEach(data, id: \.self) { item in Text(item) .frame(maxWidth: .infinity) .padding() .background { RoundedRectangle(cornerRadius: 8) .fill(Color.cyan) } .padding(.horizontal, 8) } } .onScrollPhaseChange { oldPhase, newPhase, context in scrollState = (newPhase, context) } Divider() VStack { Text(scrollStateDescription) } .font(.footnote.monospaced()) .padding() } } private var scrollStateDescription: String { guard let scrollState else { return "" } let velocity: String = { guard let velocity = scrollState.context.velocity else { return "none" } return "\(velocity)" }() let geometry = scrollState.context.geometry return """ State at the scroll phase change Scrolling=\(scrollState.phase.isScrolling) Phase=\(scrollState.phase) Velocity \(velocity) Content offset \(geometry.contentOffset) Visible rect \(geometry.visibleRect.integral) """ } } view raw ScrollPhase.swift hosted with ❤ by GitHub If this was helpful, please let me know on Mastodon@toomasvahter or Twitter @toomasvahter. Feel free to subscribe to RSS feed. Thank you for reading. Support me on Patreon Donate with Paypal Buy me a coffee

Recent content on Benoit Pasquier

It feels like it was yesterday when I became an engineering manager but it has been almost a year. I want to take this time to reflect on the challenges and learnings from this journey.

The journey from individual contributor to engineering manager isn’t always straightforward. Today, I’ll share what it means to become an engineering manager from my point of view, and a few important points to be aware of before making this transition.

It’s been a while since I haven’t posted anything on my website, it’s because there have been a few changes in 2022 that kept me away from writing. It’s time to resume it.

Security is a big topic in software engineering but how does it apply to mobile development? We care about user experience or mobile performance, security issues are rarely prioritized. This week, I’ll share how to integrate security tools into your CI pipeline to stay aware of your codebase health.

I was reading this week about “10x engineer” and what it means in the tech industry. If the title can be questionable, I wanted to reflect on its definition and what it can mean in mobile engineering.

For most mobile engineers, the end game is to release our own apps. For the few projects that make it to the App Store, it can be pretty hard to keep them alive over time. Eventually, the question comes up: should I remove my app from the App Store? Today, I’ll share about the thought process that makes me sunset one.

Memory management is a big topic in Swift and iOS development. If there are plenty of tutorials explaining when to use weak self with closure, here is a short story when memory leaks can still happen with it.

In iOS development, content alignment and spacing is something that can take a lot of our time. Today, let’s explore how to set constraint with UIKit, update them and resolve constraint conflicts.

Most of people don’t know but I’ve been blogging for some time now. Actually, tomorrow will be ten years. Today is a good time to take a walk on memory lane.

Opening an app from an URL is such a powerful iOS feature. Its drives users to your app, and can create shortcuts to specific features. This week, we’ll dive into deep linking on iOS and how to create an URL scheme for your app.

I’ve been exploring more and more tooling around iOS ecosystem. One tool I really enjoy using those days is Github Action as a continuous integration for my projects. Today we’ll dive into tips and tweaks to make the most of it.

When it comes to iOS development, everybody have their own favorite language and framework: Swift, Objective-C, SwiftUI, React-Native, Flutter and so on. Unlike most of my previous post, today we’re going to leverage some iOS tooling for cross platforms technology: fastlane and Flutter.

Between banking and crypto apps, it’s quite often we interact with currency inputs on daily basis. If creating a localized UITextField can already be tricky in UIKit, I was wondering how hard it would be to do a similar one in SwiftUI. Let’s see today how to create a localized currency TextField in SwiftUI.

Like many developers, I use open source tools on daily basis. Recently, I’ve got the chance to create one for other teammates and try to think about what I should consider before launching it. Today I share this checklist.

A big part of the developer journey is make sure our code behaves as expected. It’s best practice to setup tests that allow us to test quickly and often that nothing is broken. If unit testing is common practice to check the business logic, we can also extend it to cover some specific UI behaviors. Let’s how to unit test views and gesture in UIKit.

When we talk about modular app, we rarely mention how complex it can be over time and get out of hand. In most cases, importing frameworks into one another is a reasonable solution but we can do more. Let’s explore how with dependency inversion in Swift and how to create order into our components.

For the past few years, I had the opportunity to mentor new joiners through different roles. In some aspects, I could see myself in them the same way I started years back: eager to prove themselves, jumping on the code and hacking around.

I tried to think about what I learnt the hard way since my first role in the tech industry and how could I help them learn the easy way.

Recently, I’ve been more and more curious about web experience through mobile apps. Most of web browser apps look alike, I was wondering how could I recreate one with WebKit and SwiftUI. Let’s dive in.

To move an existing iOS app codebase to SwiftUI can quickly become a challenge if we don’t scope the difficulties ahead. After covering the navigation and design layer last week, it’s time to dive deeper into the logic and handle the code migration for a database and the user preferences.

If SwiftUI is great for many things, migrating completely an existing app codebase to it can be really tricky. In a series of blog posts, I’ll share how to migrate an iOS app written in Swift with UIKit to SwiftUI. Today, let’s start with the navigation and the UI components with storyboards.

Did you ever have to share your screen and camera together? I recently did and it was that easy. How hard could it be to create our own? Today, we’ll code our own webcam utility app for macOS in SwiftUI.

It’s been almost two years that Combine has been introduced to the Apple developer community. As many developer, you want to migrate your codebase to it. You don’t want to be left behind but you’re not sure where to start, maybe not sure if you want to jump to SwiftUI either. Nothing to worry, let’s see step by step how to migrate an iOS sample app using UIKit and RxSwift to Combine.

Displaying dates or times is a very common requirement for many apps, often using a specific date formatter. Let’s see what SwiftUI brings to the table to make it easier for developers.

When creating new features, it’s really important to think about how our users will use it. Most of the time, the UI is straightforward enough. However, sometimes, you will want to give some guidance, to highlight a button or a switch, with a message attached. Today, we’ll create a reusable and adaptable overlay in Swift to help onboard mobile users for any of your features.

Close to the end of the year, I tend to list what I’ve accomplished but also what didn’t go so well, to help me see what can I do better next year. With couple days early, it’s time to look back at 2020.

A question that comes back often when using Coordinator pattern in iOS development is how to pass data between views. Today I’ll share different approaches for a same solution, regardless if you are using MVVM, MVC or other architectural design pattern.

One reason I like so much working on native mobile apps is to deliver the user experience based on their region and location. Although, for every update, it can be painful for developers to recapture screenshots foreach available language. Today, I’ll share how to automate this with UI tests and Xcode tools.

I’ve been experiencing more and more with SwiftUI and I really wanted to see what we can do with video content. Today I’ll share my findings, showing how to play video using AVFoundation in SwiftUI, including some mistakes to avoid.

With Mac Catalyst and SwiftUI support for macOS, Apple has been pushing new tools to the community for the past couple years to create new services on Mac computers. Does it mean you should do too? Here are couple things to consider first.

Designing a watchOS app in Swift always felt to be quite tricky. I could spend hours tweaking redoing layout and constraints. With SwiftUI supporting watchOS, I wanted to have a new try at it, releasing a standalone app for Apple Watch.

Shortly stepping back from coding for a week and reading about the community, I realized it how easy it is to be crushed by anxiety: I see so many great things happening every day, things I want to be part of, but at the same time getting anxiety to be good enough. This is my thoughts of how to face the impostor syndrome.

In the last couple years, Apple has made some good efforts to improve their testing tools. Today, I’ll walk you through some tips to make sure your test suite run at their best capacity.

A recurring challenge in programming is accessing a shared resource concurrently. How to make sure the code doesn’t behave differently when multiple thread or operations tries to access the same property. In short, how to protect from a race condition?

About a month ago, it became possible to run Swift code on AWS Lambda. I was really interesting to try and see how easy it would be to deploy small Swift functions as serverless application. Let’s see how.

Even though the iOS ecosystem is growing further every day from Objective-C, some companies still heavily rely on it. A week away for another wave of innovation from WWDC 2020, I thought it would be interesting to dive back into Objective-C starting with a MVVM pattern implementation.

Since January, I’ve been slowing down blogging for couple reasons: I started doubting about myself and the quality of my content but I also wanted to focus more on some fundamentals I felt I was missing. So I committed to a “100 day challenge” coding challenge, focused on data structure and algorithm in Swift.

Following up previous articles about common data structure in Swift, this week it’s time to cover the Tree, a very important concept that we use everyday in iOS development. Let’s dive in.

Recently, I was looking into a bug where the UITabBar was inconsistently disappearing on specific pages. I tried different approaches but I couldn’t get where it got displayed and hidden. That’s where I thought about KVO.

After covering last week how to code a Queue in Swift, it sounds natural to move on to the Stack, another really handy data structure which also find his place in iOS development. Let’s see why.

Recently revisiting computer science fundamentals, I was interested to see how specific data structure applies to iOS development, starting this week one of most common data structure: the queue.

When I started this blog in 2012, it was at first to share solution to technical problem I encountered on my daily work, to give back to the community. Over the years, I extended the content to other projects and ideas I had. Nowadays, I get more and more feedbacks on it, sometimes good, sometimes bad, either way something always good to learn from.

Last year, I shared a solution to tackle A/B testing on iOS in swift. Now that we have SwiftUI, I want to see if there is a better way to implement A/B testing. Starting from the same idea, I’ll share different implementations to find the best one.

For quite some time now, I’ve been developing an interest to data analysis to find new ways to improve mobile app. I’ve recently found some time to experiment neural language processing for a very specific usecase related to my daily work, sentiment analysis of customer reviews on fashion items.

With SwiftUI being recently introduced, I was curious if we could take advantage of SwiftUI preview to speed up testing localization and make sure your app looks great for any language.

Introduced in 2019, Apple made UI implementation much simpler with With SwiftUI its UI declarative framework. After some time experiencing with it, I’m wondering today if MVVM is still the best pattern to use with. Let’s see what has changed, implementing MVVM with SwiftUI.

When asked about data structure and algorithm for an iOS development role, there is always this idea that it’s not a knowledge needed. Swift got already native data structure, right? Isn’t the rest only UI components? That’s definitely not true. Let’s step back and discuss about data structure and algorithm applied to iOS development.

For last couple years, I’ve been experimenting different architectures to understand pros and cons of each one of them. Redux architecture is definitely one that peek my curiosity. In this new post, I’ll share my finding pairing Redux with MVVM, another pattern I’m familiar with and more importantly why you probably shouldn’t pair them.

There is a believe that any software developer must contribute or have a side project to work on. Even if it’s great to have, I think there is something bigger at stake doing that.

Over time, any code base grows along with the project evolves and matures. It creates two main constraints for developers: how to have a code well organized while keeping a build time as low as possible. Let’s see how a modular architecture can fix that.

I have been interested in analytics tools for a while, especially when it’s applied to mobile development. Over the time, I saw many code mistakes when implementing an analytical solution. Some of them can be easily avoided when developer got the right insights, let’s see how.

Over the time, I spent quite some time building different apps and projects. Here is the list of the one that became something. Lighthouse is a webapp written in Swift to test universal link configuration. Driiing, a running companion app to signal runners coming to pedestrians. Appy, an iOS app that takes helps you quit your bad habit. Square is an resizing tool for app icons written in Rust. Japan Direct, an itinerary app for iOS to visit Japan like a local.

I recently tried to be more active in the iOS community. Becoming speaker and talks to events is my next challenged. Here is the list of talks I’ve made so far. My very first one was recently at iOS meetup Singapore in July 2019, talking about scalability of an iOS app along with your team. You can read more about this whole new journey here. I also got chance to be part of iOS Conf SG 2021, an online version of the very popular international event iOS Conf SG.

Since Xcode 7, iOS developers can generate a code coverage for their app: a report showing which area of their app is covered by unit tests. However, this is isn’t always accurate, let’s see why you should not base your code health only on code coverage.

It has been a while since I wanted to create something helpful to others, not than just another random app. Then I found out there were not so many great sobriety apps, so I launched one. Here is Appy, to help you quit your bad habits.

With iOS13, Apple is introducing “Sign In with Apple”, an authentication system that allows user create an account for your app based on their Apple ID. Let’s see how to integrate it in your app and be ready for iOS13 launch.

I have been a bit more quite for the past couple weeks to take a break of my weekly routine of blogging. It’s not because I was lazy, but I wanted to take time to digest WWDC. At the same time I had other running projects, one was my first talk at an iOS meetup. Here is couple tips I would have love to hear earlier.

One debate over the past year in the iOS ecosystem was the around functional reactive framework like RxSwift or ReactiveCocoa. This year at WWDC2019, Apple took position on it and released their own functional reactive programming framework, here is Combine.

I have been recently asked to review an iOS application to see how healthy was the code base, if it follows the best practices and how easy it would be to add new features to it. If I review some code on daily basis for small pull requests, analyzing one whole app at once is quite different exercise. Here is some guidelines to help doing that analysis.

After weeks experimenting different patterns and code structures, I wanted to go further in functional reactive programming and see how to take advantage of it while following Coordinator pattern. This post describes how integrate RxSwift with Coordinator pattern and which mistakes to avoid.

If you are not familiar with it, Redux a Javascript open source library designed to manage web application states. It helps a lot to make sure your app always behaves as expected and makes your code easier to test. ReSwift is the same concept but in Swift. Let’s see how.

We often talk about scalability of iOS app but not much about the project itself or the team. How to prepare your project to move from 2 developers to 6? How about 10 or 20 more? In that research, I’ve listed different tools to prepare your team and project to scale.

For the past months, I keep going further in RxSwift usage. I really like the idea of forwarding events through different layers but the user interface stays sometimes a challenge. Today, I’ll describe how to use RxDataSources to keep things as easy as possible.

Even if I usually stay focus on the customer facing side of mobile development, I like the idea of writing backend api with all the security that Swift includes. Starting small, why not using Swift Server for our UI Tests to mock content and be at the closest of the real app.

I love developing new iOS apps and create new products. However, regardless of the project, it often need a team to mix the required skills: design, coding, marketing. Although, this less and less true, so let’s see how to bootstrap your iOS app.

Not that long ago, I wrote how to pair RxSwift with MVVM architecture in an iOS project. Even if I refactored my code to be reactive, I omitted to mention the unit tests. Today I’ll show step by step how to use RxTest to unit test your code.

For years now, the whole iOS community has written content about the best way to improve or replace the Apple MVC we all started with, myself included. MVC, MVVM, MVP, VIPER? Regardless the type of snake you have chosen, it’s time to reflect on that journey.

After introducing how to implement Coordinator pattern with an MVVM structure, it feels natural for me to go further and cover some of the blank spots of Coordinator and how to fix along the way.

Couple weeks ago, I heard somebody talking about A/B testing in iOS and how “mobile native A/B testing is hard to implement”. It didn’t sound right to me. So I build a tiny framework for that in Swift. Here is Reversi.

I was recently searching for onboarding journey in iOS, that succession of screens displayed at the first launch of a freshly installed mobile app. But regardless how beautiful the design can be, why so many people are tempted to skip it. I listed things to consider while creating an onboarding journey for your iOS app.

After some times creating different iOS apps following an MVVM pattern, I’m often not sure how to implement the navigation. If the View handles the rendering and user’s interactions and the ViewModel the service or business logic, where does the navigation sit? That’s where Coordinator pattern takes place.

Last year, I launched with a friend Japan Direct, an itinerary app for Japan travellers. Even if the first version came up quite quickly, I kept iterate but always staying focus on customer feedback first. Almost a year later, it’s good time for synthesis, see what worked and how we created a customer focused app.

Apple introduced in iOS8 trait variations that let developers create more adaptive design for their mobile apps, reducing code complexity and avoiding duplicated code between devices. But how to take advantage of variations for UICollectionView?

This post will cover how to setup variations via Interface Builder as well but also programatically, using AutoLayout and UITraitVariation with a UICollectionView to create a unique adaptive design.

For last couple weeks, I’ve worked a lot about how to integrate RxSwift into an iOS project but I wasn’t fully satisfied with the view model. After reading many documentation and trying on my side, I’ve finally found a structure I’m happy with.

Since WWDC18, Apple made it way easier to developers to create model for machine learning to integrate iOS apps. I have tried myself in the past different models, one for face detection and create another with Tensorflow to fashion classification during a hackathon. Today I’ll share with you how I create a model dedicated to fashion brands.

It took me quite some time to get into Reactive Programming and its variant adapted for iOS development with RxSwift and RxCocoa. However, being fan of MVVM architecture and using an observer design pattern with it, it was natural for me to revisit my approach and use RxSwift instead. Thats what I’m going to cover in this post.

The delegation pattern is one of the most common design pattern in iOS. You probably use it on daily basis without noticing, every time you create a UITableView or UICollectionView and implementing their delegates. Let’s see how it works and how to implement it in Swift.

Part of the journey in software development is testability. Regarding mobile development, testability for your iOS app goes through UI testing. Let’s see different way to inspect any UI elements and prepare your iOS app for UI automation testing.

While wishing a happy new year around me, people helped me realised how many good things happened to me this year. Funny enough, while listing my goals for 2019, I found the matching list for 2018 and here is what really happened.

From my first year studying computer science, I’ve always wanted to do more on my free time and create simple projects that could be useful for others. I won’t lie, I wish I was able to monetize them but regardless the outcome, learning was always part of the journey.

During this year, I have blogged quite a bit about code architecture in Swift and I’ve realized that I didn’t explain much about which design pattern to use with it. In a series of coming posts, I will cover different design patterns, starting now with observer.

For a while now, I really wanted to work on a machine learning project, especially since Apple let you import trained model in your iOS app now. Last September, I took part of a 24h hackathon for an e-commerce business, that was my chance to test it. The idea was simple: a visual search app, listing similar products based on a picture.

It has been couple months since my last post and despite the idea, a lot of things kept me busy far from blogging. Looking back, it all articulates around the same idea: why it’s important to always keep your skills sharp.

Couple months ago, I’ve built an app and released it on the App Store. Since published, I really wanted to see how it lives and understand how to make it grow. Ideally, I wanted to know if there is a product / market fit. In the article, I describe each steps and ideas that helped my app grow and what I learnt from it.

Most of mobile apps interact at some point with remote services, fetching data from an api, submitting a form… Let’s see how to use Codable in Swift to easily encode objects and decode JSON in couple lines of codes.

I recently went for a Swift conference and UI automation testing was one of the subject. I already mentioned it with Appium in the past but I think it’s time to go back to it and explain why today I still prefer using Apple’s testing framework instead.

I recently implemented 3D touch for an app and I was very interested about home screen quick actions. If it can be a good way to improve user experience, it doesn’t mean your app always needs it. In this article, I explain how to add home screen shortcut for your app in Swift but mostly why can justify implementing it.

I recently realised that my first blog post was 6 years ago. It’s a good occasion for me to do a little retrospective and share what I learnt from blogging over the years.

If you care about user experience, error handling is a big part you have to cover. We can design how an mobile app looks like when it works, but what happen when something goes wrong. Should we display an alert to the user? Can the error stay silent? And mostly how to implement it the best way with your current design pattern? Let’s see our options while following MVVM pattern.

The best way to learn and become more creative as a developer is to focus on a side project. A really good friend coming back from Japan came to me with an idea when I needed that side project. This is how we created Japan Direct, from the idea to the App Store in almost no time.

For the last couple weeks, I tried to step back on my development to analyse what is time consuming in mobile development. I realised that most of new views are based on same approach, reimplementing an similar structure around a UICollectionView or UITableView.

What if I can have a more generic approach where I can focus only on what matters, the user experience. That’s what I tried to explore in this article.

Last couple weeks, I have traveled with only my iPhone with me and I realised how many apps I daily used still relying on their websites. Even with the right iOS app installed, I had to browse on Safari app to get specific details. That is why it’s so important to support universal links in iOS. Let me show you how.

Enumerations have changed a lot between Objective-C and Swift. We can easily forget how useful and powerful it can. I wanted to get back to it through simple examples to make the most of it.

Firebase is a set of tools introduced by Google to build better mobile apps. I worked with this many times and even if it’s straight forward to integrate, here are couple advices of implementation to make the most of it.

I recently followed a growth marketing course, introducing mindset and methodology to make a company grow. I learnt a lot from it and since, I try to apply this knowledge on a daily basis. After more reflection on it, a lot of ideas looked very similar to software development job, this is the part I would like to share.

When I started coding years ago, it was all about object oriented programming. With Swift, a new approach came up, making the code even easier to reuse and to test, Protocol-Oriented Programming.

If you have an iOS app, you might have integrated external libraries and tools to help you getting your product ready faster. However your iOS architecture and swift code shouldn’t depend on those libraries.

The best part of continuous integration is the ability to automatically run tests and build apps, ready to be deployed. However, automatic build doesn’t mean smart or optimised build. Here are some tips I collected along the way to speed up delivery process.

To be sure new code won’t break old one already implemented, it’s best practice to write unit tests. When it comes to app architectures, it can be a challenge to write those tests. Following an MVVM pattern, how to unit test a view and its viewModel? That’s what I would like to cover here using dependency injection.

Creating a new app often raise the question of what architecture to choose, which pattern would fit best. In this post, I show how to implement an MVVM pattern around a sample app in Swift.

In 2017, I managed to run about 750 miles (1200 km), it’s 250 miles more than the year before. I know it because Strava tracked it for me. I’m such a fan of their product than using it becomes part of my routine and my training. Although, during that journey, I always missed numbers that talked to me. That is how I created Kronos.

Starting a new year is always exciting. Most of us have new resolutions and a bucket list we want to accomplish for 2018 but it’s quite often that as soon something go wrong, the whole list goes wrong. Here is some advices to keep track on it.

For the last couple months, I observed Today extensions of some of iOS apps I daily use to see when those widgets are useful and how to justify developing one. Here are my conclusions.

With iOS11, Apple introduced the ability to integrate machine learning into mobile apps with Core ML. As promising as it sounds, it also has some limitations, let’s discover it around a face detection sample app.

I always thought a good way to stay motivated and look forward is to have goal you can accomplish in a short term, about 3 to 12 months maximum. It’s at least the way I dealt with my life after being graduated.

Embedding web into native apps is a frequent approach to quickly add content into a mobile app. It can be for a contact form but also for more complex content to bootstrap a missing native feature. But you can go further and build a two bridge between Web and Mobile using JavaScript and Swift.

Most of apps use HTTPS request to access data, and because of SSL encryption, it can be tough to debug it from iOS apps that are already on the App Store. Charles is the perfect tool to help you inspect your HTTPS requests.

Libraries and external dependencies have always been a good way to avoid developers recreate something already existing. It’s also a good way to help each other and leaving something reusable. CocoaPods is the most used tool to manage dependencies around Xcode projects. Let’s see how to create your own private pod.

Starting 2017, I decided that this year would be mine. It doesn’t mean everything would be given, but I would stay open to new opportunities and stay actor of my life, be what I want to be. Half way, here is time for reflection.

Configuring a continuous integration can be tricky for mobile apps. Let’s see how quick it is to build an Android app with Bitbucket Pipeline and deliver it with App Center app (ex HockeyApp).

Recently, I got a reminder that my domain name and shared host would eventually expire this summer. I always had a WordPress for my website and thought it was time to move on for something easier to maintain. Here is how I managed to migrate my WordPress blog to a static website with Hugo on AWS.

This year, I finally signed up for a marathon and the way I use running apps and their services have clearly changed. Giving the best user experience around those services is essential to make the app useful. Here is my feedback as a mobile developer during my last 10 weeks training.

Technology has never been as important as today in politics. Everything is related to numeric data. If we only analyze news around US elections in 2016, it was mostly about email hacks, fake news in daily news feed, or online surveys. Concerned about French elections 2017, I wanted to be a bit more active and do something related the last one: to online surveys.

In my current role at Qudini, I started as an iOS developer. My main task was to create and improve our mobile products for iOS devices based on what was already done on Android. However I wanted to be more efficient in my job and I thought it could be by impacting more users through Android development. Once our iOS apps were at the same level as the Android one, I push the idea that it would be better I start doing Android too. Here is my feedback after 6 months developing on Android.

Recently, I got the chance to integrate feature flags into a mobile app I work on. The idea of feature flag is simple, it lets you enable and manage features in your mobile app remotely without requiring a new release. Let see the benefice of it and how integrate a feature flag solution like Apptimize’s one.

Couple months ago, I’ve tried to set a mobile testing environment with Appium and one of the best tools to execute these tests was SauceLabs, a cloud platform dedicated for testing. SauceLabs is pretty easy to use but here is couple tricks to make even easier.

Continuous integration and continuous delivery is something I wanted to do a while ago, specially since Apple accelerated its approval process to publish new apps on its mobile store. It can now takes less than a day to have an update available for your mobile users: continuous integration and continuous delivery makes more sense than ever on mobile apps.

Working as a mobile developer, I created multiple apps during last couple years for companies I worked for, and eventually for personal projects. At the beginning, I though the goal for any developer was the release itself: shipping code and moving on, but I quickly found out that it was more frustrating than everything to stop here. That’s how I started thinking about what should be the next step and if a developer can actually do marketing and how.

I recently finished Growth Hacking Marketing by Ryan Holiday and learn a lot of things about it. Some of them remembered me the way I found my job in London and how I tweaked my LinkedIn profile to fit the targeted audience.

Sens’it is small tracker developed by Sigfox and given for free during events to let people test the Sigfox low frequency IoT network. Let’s see how to create an iOS app in Swift based on Sens’it api.

Couple years ago, I worked on a mobile app linked to video and audio recording. I quickly see that, once the user agreed for permissions, it can be easy to track personal data without user noticed it. Let see how limit mobile app permissions to maintain user privacy.

Appium is an UI automation testing framework, helping developers to automatically test their app. This tool can be really powerful but my experience with it let me think it’s not enough accurate to be used everyday and at its full potential.

During WWDC2015, Apple announced big stuff, but they also released awesome features for developers. One of them was dedicated to UI Testing. Working around UI Automation test, I’ve just discovered last Xcode 7 and how life is going to be easier with their last feature for that.

Recently I worked on a small iOS mobile project around Javascript. I wanted to load web content from iOS with Javascript inside and get callbacks from Javascript into iOS, to save native data and transmit it to an other controller if needed. The second part was also to call Javascript methods from iOS part.

Philips created few years ago Ambilight, a TV with a dynamic lights on it back. With two friends, we wanted to design an app with a similar function based on connected light bulb during an hackathon. Here is what we have done in 24h hours of code, let’s meet AmbiMac.

HealthKit is a powerful tool if you want to create an iOS mobile app based on health data. However, it’s not only for body measurements, fitness or nutrition; it’s also sleep analysis. In this HealthKit tutorial, I will show you how to read and write some sleep data and save them in Health app.

UPDATE - April 2020: Originally written for Swift 1.0, then 2.0, I’ve updated this post for latest Swift 5.1 version and Xcode 11.3.

I work with CodeIgniter almost exclusively on API, but sometimes it can help on short-lived websites. Rewrite url is a good thing to know if you want to optimize SEO for your key pages of a website. That’s what I want to show you and how it’s easy to set it up.

Pour la fin de mes études, j’ai choisi de rédiger mon mémoire sur les objets connectés et plus précisément sur le développement de services numériques autour de ces objets. Ce travail de fond m’a permis de prendre du recul sur mon travail mais c’était aussi l’occasion de trouver une définition de ce qu’est un développeur d’objet connecté.

En Octobre dernier, j’avais travaillé sur le cocktailMaker, un objet connecté facilitant la création de cocktails. Voulant pousser le concept un peu plus loin, je me suis inscrit au startup weekend de Novembre organisé à l’EM Lyon pour découvrir les aspects marketing et business qui me manque aujourd’hui. Retour sur ces 54h de travail acharné.

Ces temps ci, il y a beaucoup de bruits autour des objets connectés. Tous les jours, on découvre de nouveaux articles sur des objets connectés annoncés sur le marché ou financés sur des plateformes de “crowdfunding”. On a bien moins d’informations sur toutes les difficultés liées autour de ces projets innovants. Voici mes conclusions sur les recherches que j’ai faites à ce sujet.

L’année dernière à cette même période, j’ai participé au Fhacktory, ce hackathon nouvelle génération né à Lyon, avec une application mobile dédiée à la chute libre. Cette année, j’ai pu à nouveau monter sur le podium de cet évènement en développement un objet connecté, le CocktailMaker. Retour sur ce week-end 100% hack.

Sur la place des objets connectés, Jawbone est rapidement devenu un pilier du “quantified-self” (auto-mesure) avec ses bracelets UP et UP24. Je vous propose un décryptage des leurs dernières évolutions afin de rester à la pointe du “wearable”.

De plus en plus de montres connectées font leur apparition, mais d’après moi, la plupart passe à côté de l’essentiel: la montre reste l’un des seuls accessoires masculin, il faut donc la rendre élégante en respectant sa forme historique. C’est pourquoi, je m’intéresse dans cet article principalement aux montres “habillées” et en attendant la sortie de celle d’Apple, je vous propose un comparatif entre la montre connectée de Motorola et celle de Withings, fraichement annoncée.

Ne voulant pas me limiter à mon background technique, j’essaie de plus en plus de développer des notions d’entrepreneuriat dans l’idée d’être plus utile dans mon analyse technique et de continuer la reflexion autour de différents développement d’applications dans une start-up. L’idée est de ne pas se limiter au développement demandé, mais d’essayer d’appréhender toute la chaine de réflexion, à savoir du besoin de clients jusqu’à l’utilisation d’un nouveau service/produit développé et de voir comment celui-ci est utilisé et ce qu’il faut améliorer.

Pour cela, et avec les conseils avisés d’un ami , Maxime Salomon, j’ai commencé à lire The Lean Startup de Eric Ries. Ce livre aborde de nombreux sujets autour de l’entrepreneuriat, du marketing ainsi que de développement de produit à proprement parlé. L’idée est de proposer un cycle itératif de développement pouvant permettre de mesurer rapidement différents paramètres pour faire évoluer un produit en fonction de nouvelles données.

Etant d’un formation plus scientifique, j’ai ce besoin de mettre en pratique ce dont il est question pour mieux comprendre la solution proposée, j’ai aussi un besoin de me documenter sur les différents termes employés pour ne pas passer à côté du sujet, c’est pourquoi je prends mon temps pour lire ce livre, mais je vous propose mon retour d’expérience sur mes premiers acquis et comment j’essaie de les mettre en pratique.

Nous découvrons chaque jour de plus en plus d’objets connectés, ils se divisent en plusieurs catégories comme la santé, la musique, la lumière, etc. Une bonne partie se retrouve aussi dans le tracking d’activité comme le bracelet Jawbone UP. Etant intéressé de connaitre les performances de ces objets connectés dit “wearable”, je vous propose mon retour d’experience sur le bracelet UP24 ainsi que les services proposés autour.

Soundcloud est une des plus grosses plateformes de musique indépendante, c’est plus de 200 millions d’utilisateurs pour ce réseau sociale basé sur le partage musicale. Certains artistes ne publient leurs musiques que sur cette plateforme. C’est aussi la place pour des novices qui veulent essayer leurs titres et se faire connaitre. Vous pouvez aussi  y retrouver des discours, des podcasts et tout autres types de contenu audio.

Dans cette optique de toujours avoir de la bonne musique, Soundcloud est disponible sur toutes les plateformes (web et mobile) et l’écoute est gratuite. Pour une utilisation encore plus variée de leur service, SoundCloud propose une API ainsi que de nombreux SDK (Javascript, Ruby, Python, PHP, Cocoa et Java). Nous allons voir ensemble comment intégrer SoundCloud dans une application mobile iPhone.

Passer un entretien pour un poste est toujours un peu stressant. Suivant comment ce stress est géré, la personne peut donner une image de quelqu’un qui n’est pas sûre de soi par ses gestes (tremblement, bafouillement, se frotter les mains) ou par ses mots (ne pas finir ses phrases, phrases à rallonge trop complexe, etc). Difficile dans ces cas là de donner la meilleure image de soi pour montrer qu’on est travailleur, motivé et prêt à l’emploi.

Je vous propose par mon retour d’experience quelques conseils simples.

Après avoir travaillé avec les technologies Deezer, nous allons voir quels outils sont proposés par Spotify pour une intégration web ou mobile. Spotify proposant une écoute gratuite sur son client ordinateur et depuis peu sur mobile (parsemé de publicité), il se démarque de Deezer qui nécessite d’avoir un compte Premium pour une utilisation sur smartphone.  L’intégration pour les développeurs est aussi différente, mais à quelle mesure? C’est ce que nous allons voir.

Les objets connectės sont de plus en plus présents chez nous. On y retrouve des produits comme des ampoules, des enceintes audio ainsi que des prises intelligentes. On y retrouve aussi des produits plus innovants comme le pèse personne de Withings, la balle de Sphero, la lampe connectée “holî” ou encore le capteur pour plante de Parrot.

C’est dans cette optique là que l’entreprise Direct Energie a organisée un hackathon autour des objets connectés pour présenter différentes solutions autour de la maîtrise d’énergie et des objets intelligents.

C’est en tant que support technique sur le produit “holî” et son SDK que j’y ai participé, afin d’aider les développeurs à se familiariser avec l’outil. Ayant fait un hackathon du côté développeur, c’est un nouveau retour d’expérience cette fois ci du côté partenaire.

Au jour d’aujourd’hui, les jeux vidéos sont de plus en plus présent. Avec l’univers du smartphone, il est de plus en plus facile d’embarquer des jeux vidéos avec nous et ce partout.

Plusieurs jeux ont eu un tel succès qu’il reste difficile d’ignorer cet utilisation de nos téléphones en tant que console. A n’en citer que quelques-uns: DoodleJump, AngryBird ou encore le fameux CandyCrush.

Depuis la sortie d’iOS7, Apple a rajouté un framework de jeu vidéo 2D directement dans son SDK: SpriteKit. Nous allons voir ensemble comment l’utiliser.

Un hackathon est l’équivalent d’un marathon sur le domaine du développement informatique. Bien connu sous le système de “Startup Weekend”, ce principe a été adapté dans l’informatique au développement de projet en un temps donné. Le but est de monter en un weekend une équipe qui évoluera autour d’une idée et proposera une solution à un problème. J’ai récemment participé à l’un d’entre eux, le Fhactory: un hackathon se définissant “100% hack, 0% bullshit” et voici mon retour d’expérience.

Deezer étant l’une des plus grosse plateforme d’écoute et de partage de musique, il est intéressant de voir comment se servir des différents outils qu’il nous met à disposition à savoir son API de recherche de morceau et ses différents SDK pour une intégration web ou mobile.

Nous allons voir ensemble, comment les utiliser, à quelles fins et quelles en sont les limites. Pour le SDK, je ne m’intéresserai qu’à celui pour iOS.

En lançant le portail web de météo Weather, mon idée était d’en faire un support pour une version mobile. En effet l’intérêt pour des données météorologiques est de rester nomade et suivre son utilisateur. En intégrant différentes notions associées à la chute libre et avec l’aide de la Fédération Française de Parachutisme, voici iJump: l’application mobile pour les parachutistes.

Il y a maintenant 6 mois, j’ai commencé une formation afin de devenir enseignant sur les languages Cocoa et Objective-C.

Cette formation a compris plusieurs étapes, chacune finissant par un examen afin de passer à la suivante:

• Une partie pédagogique au cours de laquelle nous sommes évalués sur notre capacité à communiquer un message, à faire comprendre une technologie, à la gestion de notre temps de parole ainsi qu’à la tenue une classe.
• Une partie technique où l’évaluation se portait exclusivement sur la connaissance des technologies auxquelles je m’étais proposé. Pour ma part, cela m’a permis de revoir les fondements de Cocoa ainsi que de l’historique la société NeXT.

Voici mes différents retours sur ma première experience de formateur.

Introduction:

Sencha est un framework HTML5 pour créer des application mobiles multiplateformes. L’intérêt de celui-ci est de faire, à partir d’un projet HTML et de code JSON, une même application mobile sur plusieurs plateformes, un gain de temps incroyable si le code s’y tient. Nous allons voir les premiers pas d’une application à partir de Sencha.

Le nouveau système d’exploitation Windows 8 va de paire avec la mise à jour de son système sur mobile: Windows Phone 8.

Voici une petite introduction à MVVM Light Toolkit, un jeu de composant se basant sur une structure Model-View-ViewModel sur les frameworks XAML/C#,  pouvant être utilisé pour un développement sur Windows Phone 8.

Contexte:

Ayant récemment été initié à la chute libre, cette discipline est largement dépendante de la météo.

Malheureusement, trouver la météo en temps en “temps réel” suivant son centre de saut n’est pas chose aisé. Même à 10km de son centre de saut, la différence météorologique peut être significative quant à la pratique du parachutisme.

C’est pourquoi j’ai décidé de developper un portail web permettant de consulter le dernier relevé météo de n’importe quel centre de saut en France, datant de moins de 12h.

Introduction:

Un ORM (Object-relational mapping) est utilisé dans la programmation orienté objet afin de créer virtuellement un modèle en se basant sur une base de donnée. Cela évite de devoir écrire les requêtes dans la base de donnée soit même, un vrai gain de temps.

Introduction

La synchronisation de données en ligne est une pratique courante afin d’avoir un contenu mis à jour à chaque utilisation (applications d’informations, de news et autres).

Trouver un moyen simple d’embarquer ces données avant une synchronisation en ligne est intéressant, permettant une utilisation de l’application même si les données ne sont pas à jour.

Travaillant en Objective-C sur des applications mobiles pour iphone/ipad, nous allons voir comment utiliser Restkit à ces fins.

Après avoir fini ma première année d’étude en informatique, j’ai eu l’idée de réaliser un site internet pour une première experience professionnelle à mon compte.

Des idées à l’étude:

Après quelques idées ainsi que des conseils avisés d’un jeune entrepreneur, j’ai décidé de choisir la branche du tourisme et plus précisément le domaine de l’hotellerie de plein air.

En effet, ce domaine est peu exploité sur internet alors que le nombre de réservation de séjour en camping continuait d’augmenter.

Quand on est développeur web, il arrive qu’on travaille sur plusieurs projets en même temps et qu’on conserve d’anciens projets sans les supprimer.

En utilisant MAMP sous MAC OS X, il faut accéder à l’url exacte du dossier pour pouvoir accéder au site web, il n’existe pas par défaut une page qui indexe les dossiers contenus dans le dossier de développement.

C’est là que j’ai eu l’idée de développer un petit portail en php qui listerait les dossiers contenus dans mon dossier de développement, cela éviterait de devoir se rappeler du nom du projet ainsi que du chemin exacte pour y accéder.

Le principe de réécriture d’urls permet de “transformer” les urls pour référencer plus simplement des pages clés d’un site internet. Pour cela on utilise le fichier htaccess, un fichier caché situé à la racine du dossier de l’application.

Nous allons voir comment est géré par défaut les urls dans le framework CodeIgniter et comment les modifier pour éviter de perdre le référencement déjà acquis sur un site web.

CodeIgniter est un framework php open source basé sur une architecture MVC.

Rappel:

L’architecture MVC (Modèle – Vue – Controller) permet d’organiser plus simplement une application.

• Modèle : type de données, objet
• Vue: interface avec l’utilisateur
• Contrôleur: traitement des données, gestion des évènements.

Un framework est un kit qui permet de créer la base d’une application plus rapidement et avec une structure plus solide.

Présentation:

CodeIgniter a pour avantage d’être libre mais surtout d’être plus léger comparé aux autres frameworks php connus. Il possède un “guide utilisateur” (en ligne sur le site officiel et localement dans le dossier téléchargé) plus que complet qui propose de nombreux exemples d’applications. La mise en place est intuitive et aucune configuration n’est nécessaire pour une utilisation simple.

Tips, Tricks, and Techniques on using Cascading Style Sheets.

Parallax is a pattern in which different elements of a webpage move at varying speeds as the user scrolls, creating a three-dimensional, layered appearance. It once required JavaScript. Now we have scroll-driven animations in CSS, which is free from the main-thread blocking that can plague JavaScript animations.

Bringing Back Parallax With Scroll-Driven CSS Animations originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

For a period in the 2010s, parallax was a guaranteed way to make your website “cool”. Indeed, Chris Coyier was writing about it as far back as 2008. For those unfamiliar with the concept, parallax is a pattern in which different elements of a webpage move at varying speeds as the user scrolls, creating a three-dimensional, layered appearance. A true parallax effect was once only achievable using JavaScript. However, scroll-driven animations have now given us a CSS-only solution, which is free from the main-thread blocking that can plague JavaScript animations. Parallax may have become a little cliché, but I think it’s worth revisiting with this new CSS feature. Note: Scroll-driven animations are available on Chrome, Edge, Opera, and Firefox (behind a feature flag) at the time of writing. Use a supported browser when following this tutorial. Starting code In this example, we will apply parallax animations to the background and icons within the three “hero” sections of a universe-themed webpage. We’ll start with some lightly styled markup featuring alternating hero and text sections while including some space-related nonsense as placeholder content. Adding initial animations Let’s add an animation to the background pattern within each hero section to modify the background position. @keyframes parallax { from { background-position: bottom 0px center; } to { background-position: bottom -400px center; } } section.hero { /* previous code */ + animation: parallax 3s linear; } Here we use the keyframes CSS rule to create a start and end position for the background. Then we attach this animation to each of our hero sections using the animation property. By default, CSS animations are duration-based and run when the specified selector is loaded in the DOM. If you refresh your browser, you will see the animation running for three seconds as soon as the page loads. We do not want our animation to be triggered immediately. Instead, we intend to use the page’s scroll position as a reference to calculate the animation’s progress. Scroll-driven animations provide two new animation timeline CSS functions. These additions, view() and scroll(), tell the browser what to reference when calculating the progress of a CSS animation. We will use the view() function later, but for now, let’s focus on scroll(). The scroll progress timeline couples the progression of an animation to the user’s scroll position within a scroll container. Parameters can be included to change the scroll axis and container element, but these are not necessary for our implementation. Let’s use a scroll progress timeline for our animation: section.hero { /* previous code */ - animation: parallax 3s linear; + animation: parallax linear; + animation-timeline: scroll(); } If you refresh the page, you will notice that as you scroll down, the position of the background of each hero section also changes. If you scroll back up, the animation reverses. As a bonus, this CSS animation is handled off the main thread and thus is not subject to blocking by any JavaScript that may be running. Using the view progress timeline Now let’s add a new parallax layer by animating the header text and icons within each hero section. This way, the background patterns, headers, and main page content will all appear to scroll at different speeds. We will initially use the scroll() CSS function for the animation timeline here as well. @keyframes float { from { top: 25%; } to { top: 50%; } } .hero-content { /* previous code */ + position: absolute; + top: 25%; + animation: float linear; + animation-timeline: scroll(); } That’s not quite right. The animation for the sections further down the page is nearly done by the time they come into view. Luckily, the view animation timeline solves this problem. By setting the animation-timeline property to view(), our animation progresses based on the position of the subject within the scrollport, which is the part of the container that is visible when scrolling. Like the scroll animation timeline, scrolling in reverse will also reverse the animation. Let’s try changing our animation timeline property for the hero text: .hero-content { /* previous code */ - animation-timeline: scroll(); + animation-timeline: view(); } That looks pretty good, but there is a problem with the header content flashing into the view when scrolling back up the document. This is because the view timeline is calculated based on the original, pre-animation positioning of the subject element. We can solve this by adding an inset parameter to the view() function. This adjusts the size of the container in which the animation will take place. According to MDN’s documentation, the “inset is used to determine whether the element is in view which determines the length of the animation timeline. In other words, the animation lasts as long as the element is in the inset-adjusted view.” So, by using a negative value, we make the container larger than the window and trigger the animation to start a little before and end a little after the subject is visible. This accounts for the fact that the subject moves during the animation. - animation-timeline: view(); + animation-timeline: view(-100px); Now both the text and background animate smoothly at different speeds. Adjusting animations using animation ranges So far, we have employed both scroll and view progress timelines. Let’s look at another way to adjust the start and end timing of the animations using the animation-range property. It can be used to modify where along the timeline the animation will start and end. We’ll start by adding a view() timeline animation to the #spaceship emoji: @keyframes launch { from { transform: translate(-100px, 200px); } to { transform: translate(100px, -100px); } } #spaceship { animation: launch; animation-timeline: view(); } Again, we see the emoji returning to its 0% position once its original unanimated position is outside of the scrollport. As discussed before, animations are based on the original pre-animation position of the subject. Previously, we solved this by adding an inset parameter to the view() function. We can also adjust the animation range and tell our animation to continue beyond 100% of the animation timeline without having to manipulate the inset of the view timeline itself. #spaceship { animation: launch; animation-timeline: view(); + animation-range: 0% 120%; } Now the animation continues until we have scrolled an extra 20% beyond the calculated scroll timeline’s normal endpoint. Let’s say that we want to add an animation to the #comet emoji, but we don’t want it to start animating until it has passed 4rem from the bottom of the scrollport: @keyframes rotate { from { transform: rotate(0deg) translateX(100px); } to { transform: rotate(-70deg) translateX(0px); } } #comet { animation: rotate linear; transform-origin: center 125px; animation-timeline: view(); animation-range: 4rem 120%; } Here we see the “delayed” animation in action: We can also combine animation ranges to run completely different animations at different points within the same timeline! Let’s illustrate this by combining animation ranges for the #satellite icon at the top of the page. The result is that the first animation runs until the icon passes 80% of the scrollport, then the second animation takes over for the final 20%. @keyframes orbit-in { 0% { transform: rotate(200deg); } 100% { transform: rotate(0deg); } } @keyframes orbit-out { 0% { transform: translate(0px, 0px); } 100% { transform: translate(-50px, -15px); } } #satellite { animation: orbit-in linear, orbit-out ease; animation-timeline: view(); animation-range: 0% 80%, 80% 110%; } Fallbacks and accessibility Our webpage features numerous moving elements that may cause discomfort for some users. Let’s consider accessibility for motion sensitivities and incorporate the prefers-reduced-motion CSS media feature. There are two possible values: no-preference, and reduce. If we want to fine-tune the webpage with animations disabled by default and then enhance each selector with animations and associated styles, then we can use no-preference to enable them. @media (prefers-reduced-motion: no-preference) { .my-selector { position: relative; top: 25%; animation: cool-animation linear; animation-timeline: scroll(); } } For us, however, the webpage content and images will still all be visible if we disable all animations simultaneously. This can be done concisely using the reduce option. It’s important to note that this sort of blanket approach works for our situation, but you should always consider the impact on your specific users when implementing accessibility features. @media (prefers-reduced-motion: reduce) { .my-selector { animation: none !important; } } In addition to considering accessibility, we should also take into account that scroll-driven animations are not supported by all browsers at the time of writing. If we care a lot about users seeing our animations, we can add a polyfill (direct link) to extend this functionality to currently unsupported browsers. This, however, will force the animation to run on the main thread. Alternatively, we could decide that performance is important enough to skip the animations on unsupported browsers, thereby keeping the main thread clear. In this case, we can use the @supports selector and include the styles only on supported browsers. Here is the final code with everything, including the polyfill and reduced motion fallback: Conclusion There we go, we just re-created a classic web effect with scroll-driven animations using scroll and view progress timelines. We also discussed some of the parameters that can be used to adjust animation behavior. Whether or not parallax is your thing, I like the idea that we can use a modern approach that is capable of doing what we could before… only better with a dash of progressive enhancement. More information Unleash the Power of Scroll-Driven Animations animation-timeline (CSS-Tricks) CSS scroll-driven animations (MDN) Scroll-driven Animations Demo Site (Bramus) Bringing Back Parallax With Scroll-Driven CSS Animations originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Today, I want to discuss a couple of patterns for naming color palettes that the community is using, and how I propose we can improve, so we achieve both flexibility and beauty.

Thinking Deeply About Theming and Color Naming originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

As a front-end developer, I’ve been pretty curious about how other people code up their websites. So I tend to poke my head into design systems whenever I find one. Then, late last year, a conversation with Geoff Graham set me off thinking even deeper about theming websites. (If you don’t know that dude, he’s the chief editor of this site, so that guy’s a pretty big deal, too.) So I’ve been watching, pondering, and exploring: How can we create better themes? How can we allow increased flexibility in theming? How can we allow more colors to be used so that sites can be more alive and dimensional instead of being so flat all the time? Today, I want to discuss a couple of patterns that the community is using, and how I propose we can improve, so we achieve both flexibility and beauty. Hope you’re ready to go on a wild ride with me! Color Palettes Let’s begin from the beginning. After all, how can you discuss theming without including colors into the site? I think this problem is pretty much solved by now. Everyone has adopted systems that allows for various hues — along with multiple tints and shades — that can give some life to the design. We don’t need to go very far to see this trend happening. For example, Tailwind CSS includes a ton of colors and their respective tones. Open Props by Adam Argyle provides even more tones, up to 13 per color. And Pico CSS ups the ante by introducing 19 different tones per color. Er… this is not a race, so the number of tones doesn’t really matter. What’s important is you get sufficient color tones to create subtle effects for various parts of the design. Designing Your Own Palette Color palettes provided by these libraries and frameworks can be good starting points, but I’d argue that you almost never want to use them. Why? Because colors create differentiation; differentiation creates distinction; distinction creates identity. You probably know this is true without me telling you. Sites that use Bootstrap, look like Bootstrap. Sites that use Tailwind, look like Tailwind. Sites that use shadcn, look like that too… Of course there are makers who can break the mould, use Tailwind, and make it completely not like Tailwind. But that’s because they tweak many things. Color is one of these things — one of the most important ones — but other important pieces include typography, spacing, the roundness of your corners… and many others. Covering those is a story for another day, and perhaps best covered by Jack McDade who teaches Radical Design. So, if you don’t wanna drown in the sea of sameness — looking like everyone else — creating your own color palettes is a first step forward. Now, you may be anxious about creating color palettes because there’s been lots of writing about the amount of work that goes into creating accessible color palettes, so that might sound like a daunting task. Plus, anything related to accessibility carries “Big Potential Consequences” and “Highly Shameful When Done Incorrectly,” so that can add extra pressure on you. Throw all those pressures away. Don’t be scared. Because if you want to create a corner of the internet that looks like you (or your company), breathes like you, acts like you, and exudes fun like you do, then gotta do what you gotta do. There are only two words you have to remember. Just two words. Sufficient contrast. And you’re set for accessibility (design-wise, at least). That’s it. Designing Color Palettes by Hand I tend to design color palettes by hand — in Figma — when I design my websites. This seems to be the most natural process for me. (Or maybe I’m just influenced by how Jack designs stuff 🙃). If you do this, there’s no need to stress about filling up tones from 50 to 950. That’s because you’ll have no idea what colors would look nice before you fit them into the design. Stressing over tones is putting the cart before the horse. Here’s a decent example. When I designed Splendid Labz, I omitted a ton of color tones. Here’s an example of the pink color variables for the site. Notice I skipped values between 50 and 400? Well, I didn’t need ’em. Notice I added 200d and 600d? Well, I kinda wanted a desaturated (or muted) variant of these colors… which… could not be captured the existing systems. So I added d for desaturated 🙃. You can see the results of that yourself. It’s not too shabby in my opinion — with splashes of color that perhaps bring some joy to your face when you scroll through the site. You get the drift, yeah? It’s not too hard. So, don’t be scared and give that a try. Designing Color Palettes Programmatically If you’re the kinda person that prefers generating colors programmatically (and of course you can hand-tweak them afterwards if you desire), here are a few generators you may fancy: RampenSau Perceptual Palettes Accessible Palette Generator Of these, I highly recommend checking out @meodai‘s RampenSau because he’s really knowledgeable about the color space and does incredible work there. (Use the monochromatic feature to make this easy.) 🎉 Just released RampenSau v1.0.0 on npm and GitHub! 🎢🐷 After some Easter weekend coding, the color palette generation library is now stable with improved docs and APIs. Generate beautiful color ramps for your data viz, design work, or generative art! meodai.github.io/rampensau/ [image or embed] — David Aerne (@meodai.bsky.social) April 21, 2025 at 3:55 PM Using the Color Palettes A thousand words later, we’re finally getting to the meat of this article. 😅 With a seemingly unlimited amount of options given by the color palettes, it makes sense to assume that we can use them however we want — but when it comes to application, most systems seem to fall short. (Even short is generous. They actually seem to be severely restricted.) For example, DaisyUI seems to support only two tones per color… Pico CSS, a system with one of the most options, on first glance, limits to 10 possible variants “semantic class names“. But if you look deeper, we’re still looking at about two tones per “thing”: Primary (one tone) Background and background hover (two tones) Border and border hover (two tone) Underline (is this the same as border? More on this below.) And so on… Which brings me to one very important and very puzzling question: If colors are so important, why do these frameworks allow only the utilization of so few colors? I can’t answer this question because I’m not the creators behind those systems, but I’d guess these might be the possible causes: These system designers might not be as sensitive to colors as visual designers. Semantic class name confusion. Values were simply meant as guidelines. The second one a serious, and limiting, issue that we can deal with today. As for the first, I’m not saying I’m a great designer. I’m simply saying that, with what I know and have discovered, something seems to be amiss here. Anyway, let’s talk about the second point. Semantic Class Name Confusion Observing the “semantic class names” these systems use actually unveil underlying confusion about what “semantic” means to the web development community. Let’s go back to my remark about the --pico-primary-underline variable earlier with Pico CSS. But if you look deeper, we’re still looking at about two tones per “thing” Primary (one tone) Background and background hover (two tones) Border and border hover (two tones) Underline (is this the same as border? More on this below) And so on… Isn’t that an interesting remark? (I ask this question because underline and border can use the same color to create a unifying effect). From what we can see here, the term “semantic” actually means two things conflated into one: An order of hierarchy (primary, secondary, tertiary, etc) The “thing” it was supposed to style This gets even more confusing because the order of hierarchy can now be split into two parts: A color-specific order (so primary means red, secondary means blue, and so on) A use-case specific order (so a heavy button might be primary, while a light button might be secondary) Okay. I can hear you say “naming is hard.” Yes, that’s the common complaint. But “naming is hard” because we conflate and reduce things without making distinctions. I propose that: We keep the hierarchy (primary, secondary, tertiary) to the color hue. We name the strength, “oomph,” or weight of the button with a verb that describes their relative weight or appearance, like outline, light, heavy, ghost, etc. We can create the appearance variations easily with something I call The Pigment System. But perhaps that’s an article for another day. Anyway, by creating this separation, we can now create a wealth amount of color combinations without being restricted by a single hierarchical dimension. Moving on… The Second Problem With Semantics Using the same example (just for simplicity, and definitely not trying to bash Pico CSS because I think they’re doing a really good job in their own right), we see that semantics are conflated by stating its hierarchy along what its supposed to style. Examples are: --pico-primary-background --pico-primary-border These two properties result in a problem when designing and developing the site later. If you consider these questions, you’d see the problems too: First: By using --pico-primary-background… Does it mean we only have one main background color? What if we need other colors? Do we use --pico-secondary-background? What if we need more? Do we use tertiary (3rd), quaternary (4th), quinary (5th), and senary (6th) for other colors? Second: What if we have variants of the same color? Do we use things like --pico-primary-background-1, 2, 3, and so on? Third: Now, what if I need the same color for the --pico-primary-background and the --pico-primary-border of the same component? But I’d need another color for a second one? This starts getting confusing and “semantics” begins to lose its meaning. What Semantics Actually Mean Consulting Etymology and the dictionary gives us clues about how to actually be semantic — and keep meaning. Two things we can see here: Semantics mean to indicate by a sign. It can be related to meaning or logic. What I’m noticing is that people generally ascribe “semantics” to words, as if only words can convey meanings and numbers cannot… But what if we broaden our scope and view numbers as semantic too — since we know 100 is a much lighter tint and 900 is a dark shade, isn’t that semantics showing through numbers? Better Semantics We already have a perfectly usable semantic system — using numbers — through the color palettes. This is highly semantic! What we simply need is to adjust it such that we can use the system to easily theme anything. How? Simple. I made the argument above that the hierarchy (primary, secondary, etc.) should be used to refer to the colors. Then, if you have use pink color as your main (hence primary) color… You can simply set another color, say orange as your secondary color! (Duh? Yeah, it’s obvious in hindsight.) Implementing this into our code, we can do a one-to-one port between hierarchy and hues. If you do this via CSS, it can be manual and not very fun… .theme-pink { --color-primary-100: var(--color-pink-100); --color-primary-200: var(--color-pink-200); --color-primary-300: var(--color-pink-300); /* and so on ...*/ --color-secondary-100: var(--color-orange-100); --color-secondary-200: var(--color-orange-200); --color-secondary-300: var(--color-orange-300); /* and so on ...*/ } With Sass, you can run a quick loop and you’ll get these values quickly. $themes: ( pink: ( primary: pink, secondary: orange ) ); $color-tones: 100, 200, 300, 400, 500, 600, 700, 800, 900; @each $theme-name, $theme-colors in $themes { .theme-#{$theme-name} { @each $tone in $color-tones { --color-primary-#{$tone}: var(--color-#{map-get($theme-colors, primary)}-#{$tone}); --color-secondary-#{$tone}: var(--color-#{map-get($theme-colors, secondary)}-#{$tone}); } } } For Tailwind users, you could do a loop via a Tailwind plugin in v3, but I’m not quite sure how you would do this in v4. // The plugin code const plugin = require('tailwindcss/plugin') module.exports = plugin(function ({ addUtilities, theme }) { const splendidThemes = theme('splendidThemes', {}) const palette = theme('colors') // Collect all unique tone keys used by any color in any theme const allTones = new Set() Object.values(splendidThemes).forEach(themeConfig => { Object.values(themeConfig).forEach(colorName => { if (palette[colorName]) { Object.keys(palette[colorName]).forEach(tone => allTones.add(tone)) } }) }) const utilities = {} Object.entries(splendidThemes).forEach(([themeName, themeConfig]) => { const themeClass = {} Object.entries(themeConfig).forEach(([role, colorName]) => { if (!palette[colorName]) return allTones.forEach(tone => { if (palette[colorName][tone] !== undefined) { themeClass[`--color-${role}-${tone}`] = `var(--color-${colorName}-${tone})` } }) }) utilities[`.theme-${themeName}`] = themeClass }) addUtilities(utilities) }) // Using it in Tailwind v3 module.exports = { plugins: [ require('path-to-splendid-themes.js') ] theme: { splendidThemes: { pink: { primary: 'pink', secondary: 'orange' }, blue: { primary: 'blue', secondary: 'purple', tertiary: 'orange' } } }, } Will this generate a lot of CSS variables? Yes. But will in affect performance? Maybe, but I’d guess it won’t affect performance much, since this code is just a couple of bytes more. (Images, by contrast, weigh thousands of times more than these variables do.) And now we no longer need to worry about knowing whether background-1 or background-2 is the right keyword. We can simply use the semantic numerals in our components: .card { background-color: var(--color-primary-500) } .card-muted { background-color: var(--color-primary-700); } One More Note on Semantics I think most frameworks get it right by creating component-level semantics. This makes a ton of sense. For example, with Pico CSS, you can do this: In your own creations, you might want to reduce the amount of namespaces (so you write less code; it’s less tedious, yeah?): .card-namespaced { --card-header-bg: var(--color-primary-600); } .card-without-namespace { --header-bg: var(--color-primary-600); } No “extra semantics” or even “namespacing” needed when the project doesn’t require it. Feel free to Keep It Simple and Sweet. This brings me to a separate point on component vs global variables. Global Variables Some variables should be global because they can propagate through the entirety of your site without you lifting a finger (that is, once you design the CSS variables appropriately). An example of this with borders: :root { --border-width: 1px; --border-style: solid; --border-color: var(--color-neutral-700); } You can change the global --border-color variable and adjust everything at once. Great! To use this sorta thing, you have to build your components with those variables in mind. .card { border: var(--border-width) var(--border-style) var(--border-color); } This can be easily created with Tailwind utilities or Sass mixins. (Tailwind utilities can be convenient Sass mixins). @utility border-scaffold { border: var(--border-width) var(--border-style) var(--border-color); border-radius: var(--radius); } Then we can easily apply them to the component: .card { @apply border-scaffold; } To change the theme of the card, we can simply change the --border-color variable, without needing to include the card-border namespace. .card-red { --border-color: var(--color-red-500); } This way, authors get the ability to create multiple variations of the component without having to repeat the namespace variable. (See, even the component namespace is unnecessary.) .pico-card-red { --pico-card-background-color: var(--color-red-500); } .card-red { --bg-color: var(--color-red-500); } Now, I know we’re talking about colors and theming, and we segued into design systems and coding… but can you see that there’s a way to create a system that makes styling much easier and much more effective? Well, I’ve been pondering this kinda thing a lot over at Splendid Labz, specifically in Splendid Styles. Take a look if you are interested. Enough tooting my own horn! Let’s go back to theming! I think here are some other values that you might want to consider in your global variables: :root { --border-width: ...; --border-style: ...; --border-color: ...; --outline-width: ...; --outline-style: ...; --outline-focus-color: ...; --outline-offset: ...; --transition-duration: ...; --transition-delay: ...; --transition-easing: ...; } How Important is All of This? It depends on what you need. People who need a single theme can skip the entire conversation we hashed out above because they can just use the color palettes and call it a day. .card { background: var(--color-pink-500); color: var(--color-pink-900); } For those who need multiple themes with a simple design, perhaps the stuff that Pico CSS, DaisyUI, and other frameworks have provided is sufficient. What it takes to create a DaisyUI Theme. Side Rant: Notice that DaisyUI contains variables for --color-success and --color-danger? Why? Isn’t it obvious and consistent enough that you can use --color-red for errors directly in your code? Why create an unnecessary abstraction? And why subject yourself to their limitations? Anyway, rant end. You get my point. For those who want flexibility and lots of possible color shades to play with, you’ll need a more robust system like the one I suggested. This whole thing reminds me of Jason’s Cohen’s article, “Rare things become common at scale”: what is okay at a lower level becomes not okay at a larger scale. So, take what you need. Improve what you wish to. And may this help you through your development journey. If you wanna check out what I’ve created for my design system, head over to Splendid Styles. The documentation may still be lacking when this post gets published, but I’m trying to complete that as soon as I can. And if you’re interested in the same amount of rigour I’ve described in this article — but applied to CSS layouts — consider checking out Splendid Layouts too. I haven’t been able to look back after I started using it. Have fun theming! Thinking Deeply About Theming and Color Naming originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Is there a way to build demos that do not break when the services they rely on fail? How can we ensure educational demos stay available for as long as possible?

Keeping Article Demos Alive When Third-Party APIs Die originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

After four years, the demos in my “Headless Form Submission with the WordPress REST API” article finally stopped working. The article includes CodePen embeds that demonstrate how to use the REST API endpoints of popular WordPress form plugins to capture and display validation errors and submission feedback when building a completely custom front-end. The pens relied on a WordPress site I had running in the background. But during a forced infrastructure migration, the site failed to transfer properly, and, even worse, I lost access to my account. Sure, I could have contacted support or restored a backup elsewhere. But the situation made me wonder: what if this had not been WordPress? What if it were a third-party service I couldn’t self-host or fix? Is there a way to build demos that do not break when the services they rely on fail? How can we ensure educational demos stay available for as long as possible? Or is this just inevitable? Are demos, like everything else on the web, doomed to break eventually? Parallels with software testing Those who write tests for their code have long wrestled with similar questions, though framed differently. At the core, the issue is the same. Dependencies, especially third-party ones, become hurdles because they are outside the bounds of control. Not surprisingly, the most reliable way to eliminate issues stemming from external dependencies is to remove the external service entirely from the equation, effectively decoupling from it. Of course, how this is done, and whether it’s always possible, depends on the context. As it happens, techniques for handling dependencies can be just as useful when it comes to making demos more resilient. To keep things concrete, I’ll be using the mentioned CodePen demos as an example. But the same approach works just as well in many other contexts. Decoupling REST API dependencies While there are many strategies and tricks, the two most common approaches to breaking reliance on a REST API are: Mocking the HTTP calls in code and, instead of performing real network requests, returning stubbed responses Using a mock API server as a stand-in for the real service and serving predefined responses in a similar manner Both have trade-offs, but let’s look at those later. Mocking a response with an interceptor Modern testing frameworks, whether for unit or end-to-end testing, such as Jest or Playwright, offer built-in mocking capabilities. However, we don’t necessarily need these, and we can’t use them in the pens anyway. Instead, we can monkey patch the Fetch API to intercept requests and return mock responses. With monkey patching, when changing the original source code isn’t feasible, we can introduce new behavior by overwriting existing functions. Implementing it looks like this: const fetchWPFormsRestApiInterceptor = (fetch) => async ( resource, options = {} ) => { // To make sure we are dealing with the data we expect if (typeof resource !== "string" || !(options.body instanceof FormData)) { return fetch(resource, options); } if (resource.match(/wp-json\/contact-form-7/)) { return contactForm7Response(options.body); } if (resource.match(/wp-json\/gf/)) { return gravityFormsResponse(options.body); } return fetch(resource, options); }; window.fetch = fetchWPFormsRestApiInterceptor(window.fetch); We override the default fetch with our own version that adds custom logic for specific conditions, and otherwise lets requests pass through unchanged. The replacement function, fetchWPFormsRestApiInterceptor, acts like an interceptor. An interceptor is simply a pattern that modifies requests or responses based on certain conditions. Many HTTP libraries, like the once-popular axios, offer a convenient API to add interceptors without resorting to monkey patching, which should be used sparingly. It’s all too easy to introduce subtle bugs unintentionally or create conflicts when managing multiple overrides. With the interceptor in place, returning a fake response is as simple as calling the static JSON method of the Response object: const contactForm7Response = (formData) => { const body = {} return Response.json(body); }; Depending on the need, the response can be anything from plain text to a Blob or ArrayBuffer. It’s also possible to specify custom status codes and include additional headers. For the CodePen demo, the response might be built like this: const contactForm7Response = (formData) => { const submissionSuccess = { into: "#", status: "mail_sent", message: "Thank you for your message. It has been sent.!", posted_data_hash: "d52f9f9de995287195409fe6dcde0c50" }; const submissionValidationFailed = { into: "#", status: "validation_failed", message: "One or more fields have an error. Please check and try again.", posted_data_hash: "", invalid_fields: [] }; if (!formData.get("somebodys-name")) { submissionValidationFailed.invalid_fields.push({ into: "span.wpcf7-form-control-wrap.somebodys-name", message: "This field is required.", idref: null, error_id: "-ve-somebodys-name" }); } // Or a more thorough way to check the validity of an email address if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(formData.get("any-email"))) { submissionValidationFailed.invalid_fields.push({ into: "span.wpcf7-form-control-wrap.any-email", message: "The email address entered is invalid.", idref: null, error_id: "-ve-any-email" }); } // The rest of the validations... const body = !submissionValidationFailed.invalid_fields.length ? submissionSuccess : submissionValidationFailed; return Response.json(body); }; At this point, any fetch call to a URL matching wp-json/contact-form-7 returns the faked success or validation errors, depending on the form input. Now let’s contrast that with the mocked API server approach. Mocked API server with serverless Running a traditionally hosted mock API server reintroduces concerns around availability, maintenance, and cost. Even though the hype around serverless functions has quieted, we can sidestep these issues by using them. And with DigitalOcean Functions offering a generous free tier, creating mocked APIs is practically free and requires no more effort than manually mocking them. For simple use cases, everything can be done through the Functions control panel, including writing the code in the built-in editor. Check out this concise presentation video to see it in action: For more complex needs, functions can be developed locally and deployed using doctl (DigitalOcean’s CLI). To return the mocked response, it’s easier if we create a separate Function for each endpoint, since we can avoid adding unnecessary conditions. Fortunately, we can stick with JavaScript (Node.js), and starting with nearly the same base we used for contactForm7Response: function main(event) { const body = {}; return { body }; } We must name the handler function main, which is invoked when the endpoint is called. The function receives the event object as its first argument, containing the details of the request. Once again, we could return anything, but to return the JSON response we need, it’s enough to simply return an object. We can reuse the same code for creating the response as-is. The only difference is that we have to extract the form input data from the event as FormData ourselves: function main(event) { // How do we get the FormData from the event? const formData = new FormData(); const submissionSuccess = { // ... }; const submissionValidationFailed = { // ... }; if (!formData.get("somebodys-name")) { submissionValidationFailed.invalid_fields.push({ // ... }); } // Or a more thorough way to check the validity of an email address if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(formData.get("any-email"))) { submissionValidationFailed.invalid_fields.push({ // ... }); } // The rest of the validations... const body = !submissionValidationFailed.invalid_fields.length ? submissionSuccess : submissionValidationFailed; return { body }; } As far as converting the data, serverless functions typically expect JSON inputs, so for other data types an extra parsing step is required. As it happens, the forms in the CodePen demos are submitted as multipart/form-data. Without any libraries, we can convert a multipart/form-data string into a FormData by taking advantage of the Response API’s capabilities: async function convertMultipartFormDataToFormData(data) { const matches = data.match(/^\s*--(\S+)/); if (!matches) { return new FormData(); } const boundary = matches[1]; return new Response(data, { headers: { "Content-Type": `multipart/form-data; boundary=${boundary}` } }).formData(); } The code is mostly focused on extracting the boundary variable. This is typically autogenerated, for example, when submitting a form in a browser. The submitted raw data is available via event.http.body, but since it’s base64-encoded, we need to decode it first: async function main(event) { const formData = await convertMultipartFormDataToFormData( Buffer.from(event?.http?.body ?? "", "base64").toString("utf8") ); // ... const body = !submissionValidationFailed.invalid_fields.length ? submissionSuccess : submissionValidationFailed; return { body }; } And that’s it. With this approach, all that’s left is to replace calls to the original APIs with calls to the mocked ones. Closing thoughts Ultimately, both approaches help decouple the demos from the third-party API dependency. In terms of effort, at least for this specific example, they seem comparable. It’s hard to beat the fact that there’s no external dependency with the manual mocking approach, not even on something we somewhat control, and everything is bundled together. In general, without knowing specific details, there are good reasons to favor this approach for small, self-contained demos. But using a mocked server API also has its advantages. A mocked server API can power not only demos, but also various types of tests. For more complex needs, a dedicated team working on the mocked server might prefer a different programming language than JavaScript, or they might opt to use a tool like WireMock instead of starting from scratch. As with everything, it depends. There are many criteria to consider beyond what I’ve just mentioned. I also don’t think this approach necessarily needs to be applied by default. After all, I had the CodePen demos working for four years without any issues. The important part is having a way to know when demos break (monitoring), and when they do, having the right tools at our disposal to handle the situation. Keeping Article Demos Alive When Third-Party APIs Die originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

I went on to figure out how make masonry work today with other browsers. I'm happy to report I've found a way — and, bonus! — that support can be provided with only 66 lines of JavaScript.

Making a Masonry Layout That Works Today originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Many CSS experts have weighed heavily on possible syntaxes for a new masonry layout feature last year. There were two main camps and a third camp that strikes a balance between the two: Use display: masonry Use grid-template-rows: masonry Use item-pack: collapse I don’t think they’ve came up with a resolution yet. But you might want to know that Firefox already supports the masonry layout with the second syntax. And Chrome is testing it with the first syntax. While it’s cool to see native support for CSS Masonry evolving, we can’t really use it in production if other browsers don’t support the same implementation… So, instead of adding my voice to one of those camps, I went on to figure out how make masonry work today with other browsers. I’m happy to report I’ve found a way — and, bonus! — that support can be provided with only 66 lines of JavaScript. In this article, I’m gonna show you how it works. But first, here’s a demo for you to play with, just to prove that I’m not spewing nonsense. Note that there’s gonna be a slight delay since we’re waiting for an image to load first. If you’re placing a masonry at the top fold, consider skipping including images because of this! Anyway, here’s the demo: What in the magic is this?! Now, there are a ton of things I’ve included in this demo, even though there are only 66 lines of JavaScript: You can define the masonry with any number of columns. Each item can span multiple columns. We wait for media to load before calculating the size of each item. We made it responsive by listening to changes with the ResizeObserver. These make my implementation incredibly robust and ready for production use, while also way more flexible than many Flexbox masonry knockoffs out there on the interwebs. Now, a hot tip. If you combine this with Tailwind’s responsive variants and arbitrary values, you can include even more flexibility into this masonry grid without writing more CSS. Okay, before you get hyped up any further, let’s come back to the main question: How the heck does this work? Let’s start with a polyfill Firefox already supports masonry layouts via the second camp’s syntax. Here’s the CSS you need to create a CSS masonry grid layout in Firefox. .masonry { display: grid; grid-template-columns: repeat( auto-fit, minmax(min(var(--item-width, 200px), 100%), 1fr) ); grid-template-rows: masonry; grid-auto-flow: dense; /* Optional, but recommended */ } Since Firefox already has native masonry support, naturally we shouldn’t mess around with it. The best way to check if masonry is supported by default is to check if grid-template-rows can hold the masonry value. function isMasonrySupported(container) { return getComputedStyle(container).gridTemplateRows === 'masonry' } If masonry is supported, we’ll skip our implementation. Otherwise, we’ll do something about it. const containers = document.querySelectorAll('.masonry') containers.forEach(async container => { if (isMasonrySupported(container)) return }) Masonry layout made simple Now, I want to preface this segment that I’m not the one who invented this technique. I figured out this technique when I was digging through the web, searching for possible ways to implement a masonry grid today. So kudos goes to the unknown developer who developed the idea first — and perhaps me for understanding, converting, and using it. The technique goes like this: We set grid-auto-rows to 0px. Then we set row-gap to 1px. Then we get the item’s height through getBoundingClientRect. We then size the item’s “row allocation” by adding the height the column-gap value together. This is really unintuitive if you’ve been using CSS Grid the standard way. But once you get this, you can also grasp how this works! Now, because this is so unintuitive, we’re gonna take things step-by-step so you see how this whole thing evolves into the final output. Step by step First, we set grid-auto-rows to 0px. This is whacky because every grid item will effectively have “zero height”. Yet, at the same time, CSS Grid maintains the order of the columns and rows! containers.forEach(async container => { // ... container.style.gridAutoRows = '0px' }) Second, we set row-gap to 1px. Once we do this, you begin to notice an initial stacking of the rows, each one one pixel below the previous one. containers.forEach(async container => { // ... container.style.gridAutoRows = '0px' container.style.setProperty('row-gap', '1px', 'important') }) Third, assuming there are no images or other media elements in the grid items, we can easily get the height of each grid item with getBoundingClientRect. We can then restore the “height” of the grid item in CSS Grid by substituting grow-row-end with the height value. This works because each row-gap is now 1px tall. When we do this, you can see the grid beginning to take shape. Each item is now (kinda) back at their respective positions: containers.forEach(async container => { // ... let items = container.children layout({ items }) }) function layout({ items }) { items.forEach(item => { const ib = item.getBoundingClientRect() item.style.gridRowEnd = `span ${Math.round(ib.height)}` }) } We now need to restore the row gap between items. Thankfully, since masonry grids usually have the same column-gap and row-gap values, we can grab the desired row gap by reading column-gap values. Once we do that, we add it to grid-row-end to expand the number of rows (the “height”) taken up by the item in the grid: containers.forEach(async container => { // ... const items = container.children const colGap = parseFloat(getComputedStyle(container).columnGap) layout({ items, colGap }) }) function layout({ items, colGap }) { items.forEach(item => { const ib = item.getBoundingClientRect() item.style.gridRowEnd = `span ${Math.round(ib.height + colGap)}` }) } And, just like that, we’ve made the masonry grid! Everything from here on is simply to make this ready for production. Waiting for media to load Try adding an image to any grid item and you’ll notice that the grid breaks. That’s because the item’s height will be “wrong”. It’s wrong because we took the height value before the image was properly loaded. The DOM doesn’t know the dimensions of the image yet. To fix this, we need to wait for the media to load before running the layout function. We can do this with the following code (which I shall not explain since this is not much of a CSS trick 😅): containers.forEach(async container => { // ... try { await Promise.all([areImagesLoaded(container), areVideosLoaded(container)]) } catch(e) {} // Run the layout function after images are loaded layout({ items, colGap }) }) // Checks if images are loaded async function areImagesLoaded(container) { const images = Array.from(container.querySelectorAll('img')) const promises = images.map(img => { return new Promise((resolve, reject) => { if (img.complete) return resolve() img.onload = resolve img.onerror = reject }) }) return Promise.all(promises) } // Checks if videos are loaded function areVideosLoaded(container) { const videos = Array.from(container.querySelectorAll('video')) const promises = videos.map(video => { return new Promise((resolve, reject) => { if (video.readyState === 4) return resolve() video.onloadedmetadata = resolve video.onerror = reject }) }) return Promise.all(promises) } Voilà, we have a CSS masnory grid that works with images and videos! Making it responsive This is a simple step. We only need to use the ResizeObserver API to listen for any change in dimensions of the masonry grid container. When there’s a change, we run the layout function again: containers.forEach(async container => { // ... const observer = new ResizeObserver(observerFn) observer.observe(container) function observerFn(entries) { for (const entry of entries) { layout({colGap, items}) } } }) This demo uses the standard Resize Observer API. But you can make it simpler by using the refined resizeObserver function we built the other day. containers.forEach(async container => { // ... const observer = resizeObserver(container, { callback () { layout({colGap, items}) } }) }) That’s pretty much it! You now have a robust masonry grid that you can use in every working browser that supports CSS Grid! Exciting, isn’t it? This implementation is so simple to use! Masonry grid with Splendid Labz If you’re not adverse to using code built by others, maybe you might want to consider grabbing the one I’ve built for you in Splendid Labz. To do that, install the helper library and add the necessary code: # Installing the library npm install @splendidlabz/styles /* Import all layouts code */ @import '@splendidlabz/layouts'; // Use the masonry script import { masonry } from '@splendidlabz/styles/scripts' masonry() One last thing: I’ve been building a ton of tools to help make web development much easier for you and me. I’ve parked them all under the Splendid Labz brand — and one of these examples is this masonry grid I showed you today. If you love this, you might be interested in other layout utilities that makes layout super simple to build. Now, I hope you have enjoyed this article today. Go unleash your new CSS masonry grid if you wish to, and all the best! Making a Masonry Layout That Works Today originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Do we invent or discover CSS tricks? Lee Meyer discusses how creative limitations, recursive thinking, and unexpected combinations lead to his most interesting ideas.

How to Discover a CSS Trick originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Do we invent or discover CSS tricks? Michelangelo described his sculpting process as chiseling away superfluous material to reveal the sculpture hidden inside the marble, and Stephen King says his ideas are pre-existing things he locates and uncovers “like fossils in the ground.” Paragraph one is early for me to get pretentious enough to liken myself to those iconic creative forces, but my work on CSS-Tricks feels like “discovering,” not “inventing,” secret synergies between CSS features, which have been eyeing each other from disparate sections of the MDN web docs and patiently waiting for someone to let them dance together in front of the world. Matchmaking for CSS features A strategy for finding unexpected alliances between CSS features to achieve the impossible is recursive thinking, which I bring to the CSS world from my engineering background. When you build recursive logic, you need to find an escape hatch to avoid infinite recursion, and this inception-style mindset helps me identify pairings of CSS features that seem at odds with each other yet work together surprisingly well. Take these examples from my CSS experiments: What if view-timeline took control of the thing that triggers view-timeline? This led to a pairing between view-timeline and position: fixed. These two features are like a bickering yet symbiotic “odd couple” at the heart of my web-slinger.css library for scroll-triggered animations in pure CSS. What if keyframe animations could trigger other keyframe animations? This idea led to a throuple comprised of keyframe animations, style queries, and animation-play-state, which together can simulate collision detection in CSS. What if scroll-state:(scrollable: value) could control which directions are scrollable? That question led to a scrollytelling version of a “Choose Your Own Adventure,” which — wait, I haven’t published that one yet, but when I do, try to look surprised. Accepting there is nothing new under the sun Indeed, Mark Twain thought new ideas don’t exist — he described them as illusions we create by combining ideas that have always existed, turning and overlaying them in a “mental kaleidoscope” to “make new and curious combinations.” It doesn’t mean creating is easy. No more than a safe can be cracked just by knowing the possible digits. This brings back memories of playing Space Quest III as a kid because after you quit the game, it would output smart-aleck command-line messages, one of which was: “Remember, we did it all with ones and zeros.” Perhaps the point of the mock inspirational tone is that we likely will not be able to sculpt like Michelangelo or make a bestselling game, even if we were given the same materials and tools (is this an inspirational piece or what?). However, understanding the limits of what creators do is the foundation for cracking the combination of creativity to open the door to somewhere we haven’t been. And one truth that helps with achieving magic with CSS is that its constraints help breed creativity. Embracing limitations Being asked “Why would you do that in CSS when you could just use JavaScript?” is like if you asked me: “Why would you write a poem when it’s easier to write prose?” Samuel Coleridge defined prose as “words in their best order,” but poetry as “the best words in the best order.” If you think about it, the difference between prose and poetry is that the latter is based on increased constraints, which force us to find unexpected connections between ideas. Similarly, the artist Phil Hansen learned that embracing limitation could drive creativity after he suffered permanent nerve damage in his hand, causing it to jitter, which prevented him from drawing the way he had in the past. His early experiments using this new mindset included limiting himself to creating a work using only 80 cents’ worth of supplies. This dovetails with the quote from Antoine de Saint-Exupéry often cited in web design, which says that perfection is achieved when there is nothing left to take away. Embracing nothingness The interesting thing about web design is how much it blends art and science. In both art and science, we challenge assumptions about whether commonsense relationships of cause and effect truly exist. Contrary to the saying in vernacular that “you can’t prove a negative,” we can. It’s not necessarily harder than proving a positive. So, in keeping with the discussion above of embracing limitations and removing the superfluous until a creation reveals itself, many of my article ideas prove a negative by challenging the assumption that one thing is necessary to produce another. Maybe we don’t need JavaScript to produce a Sudoku solver, a Tinder-style swiper, or a classic scroll-driven animation demo. Maybe we don’t need checkbox hacks to make CSS games. Maybe we don’t need to hack CSS at all to recreate similar effects to what’s possible in browsers that support the CSS if() function. Maybe I can impart web dev wisdom on CSS-Tricks without including CSS at all, by sharing the “source code” of my thought process to help make you a better developer and a better person. Going to extremes Sometimes we can make a well-worn idea new again by taking it to the extreme. Seth Godin coined the term “edgecraft” to describe a technique for generating ideas by pushing a competitive advantage as far to the edge as the market dares us to go. Similarly, sometimes you can take an old CSS feature that people have seen before, but push it further than anyone else to create something unique. For example: CSS-Tricks covered checkbox hacks and radio button hacks back in 2011. But in 2021, I decided to see if I could use hundreds of radio button hacks using HTML generated with Pug to create a working Sudoku app. At one point, I found out that Chrome dev tools can display an infinite spinner of death when you throw too much generated CSS at it, which meant I had to limit myself to a 4×4 Sudoku, but that taught me more about what CSS can do and what it can’t. The :target selector has existed since the 2000s. But in 2024, I took it to the extreme by using HAML to render the thousands of possible states of Tic Tac Toe to create a game with a computer opponent in pure CSS. At one point, CodePen refused to output as much HTML as I had asked it to, but it’s a fun way for newcomers to learn an important CSS feature; more engaging in my opinion than a table of contents demo. Creating CSS outsider art Chris Coyier has written about his distaste for the gatekeeping agenda hidden behind the question of whether CSS is a programming language. If CSS isn’t deemed as “real” programming, that can be used as an excuse to hold CSS experts in less esteem than people who code in imperative languages, which leads to unfair pay and toxic workplace dynamics. But maybe the other side always seems greener due to the envy radiating from the people on that side, because as a full-stack engineer who completed a computer science degree, I always felt left out of the front-end conversations. It didn’t feel right to put “full stack developer” on my résumé when the creation of everything users can see in a web app seemed mysterious to me. And maybe it wasn’t just psychosomatic that CSS made my head hurt compared to other types of coding because research indicates if you do fMRIs on people who are engaged in design tasks, you see that design cognition appears to involve a unique cognitive profile compared to conventional problem-solving, reflected in the areas of the brain that light up on the fMRIs. Studies show that the brain’s structure changes as people get better at different types of jobs. The brain’s structural plasticity is reminiscent of the way different muscles grow more pronounced with different types of exercise, but achieving what some of my colleagues could with CSS when my brain had been trained for decades on imperative logic felt about as approachable as lifting a car over my head. The intimidation I felt from CSS started to change when I learned about the checkbox hack because I could relate to hiding and showing divs based on checkboxes, which was routine in my work in the back of the front-end. My designer workmate challenged me to make a game in one night using just CSS. I came up with a pure text adventure game made out of radio button hacks. Since creative and curious people are more sensitive to novel stimuli, the design experts on my team were enthralled by my primitive demo, not because it was cutting-edge gameplay but because it was something they had never seen before. My engineering background was now an asset rather than a hindrance in the unique outsider perspective I could bring to the world of CSS. I was hooked. The hack I found to rewire my brain to become more CSS-friendly was to find analogies in CSS to the type of problem-solving I was more familiar with from imperative programming: CSS custom properties are like reactive variables in Vue. The :target selector in CSS is like client-side routing in a single-page application. The min() and max() functions in CSS can be used to simulate some of the logical operations we take for granted in imperative programming. So if you are still learning web development and CSS (ultimately, we are all still learning), instead of feeling imposter syndrome, consider that the very thing that makes you feel like an outsider could be what enables you to bring something unique to your usage of CSS. Finding the purpose Excited as I was when my CSS hacking ended up providing the opportunity to publish my experiments on CSS-Tricks, the first comment on the first hack I published on CSS-Tricks was a generic, defeatist “Why would you do that?” criticism. The other comments popped up and turned out to be more supportive, and I said in a previous article that I’ve made my peace with the fact that not everybody will like my articles. However, this is the second article in which I’ve brought up the critical comment from back in 2021. Hmm… Surely it wasn’t the reason I didn’t write another CSS-Tricks article for years. And it’s probably a coincidence that when I returned to CSS-Tricks last year, my first new article was a CSS hack that lends itself to accessibility after the person who left the negative comment about my first article seemed to have a bee in their bonnet about checkbox hacks breaking accessibility, even in fun CSS games not intended for production. Then again, limiting myself to CSS hacking that enables accessibility became a source of inspiration. We can all do with a reminder to at all times empathize with users who require screen readers, even when we are doing wacky experimental stuff, because we need to embrace the limitations not just of CSS but of our audience. I suppose the reason the negative comment continues to rankle with me is that I agree that clarifying the relevance and purpose of a CSS trick is important. And yet, if I’m right in saying a CSS trick is more like something we discover than something we make, then it’s like finding a beautiful feather when we go for a walk. At first, we pick it up just because we can, but if I bring you with me on the journey that led to the discovery, then you can help me decide whether the significance is that the feather we discovered makes a great quill or reveals that a rare species of bird lives in this region. It’s a journey versus destination thing to share the failures that led to compromises and the limitations I came up against when pushing the boundaries of CSS. When I bring you along on the route to the curious item I found, rather than just showing you that item, then after we part ways, you might retrace the steps and try a different fork in the path we followed, which could lead you to discover your own CSS trick. How to Discover a CSS Trick originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Brad Frost introduced the “Atomic Design” concept wayyyy back in 2013. He even wrote a book on it. And we all took notice, because that term has been part of our lexicon ever since.

It’s a nice way …

Atomic Design Certification Course originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Brad Frost introduced the “Atomic Design” concept wayyyy back in 2013. He even wrote a book on it. And we all took notice, because that term has been part of our lexicon ever since. It’s a nice way to divide web designs into separate layers of concern, leaning into biology terms to help scope their context by size: Atoms Molecules Organisms Templates Pages Atoms are part of molecules, which are part of organisms, which make up templates, which become full-blown pages. It’s composable design that’s centered on consistency, reusability, and maintainability. Beautiful. We’ve covered this a bunch over the years. Want to get fully versed in how it works? If so, you’re in luck because Brad and his brother, Ian, are in the process of publishing an entire online course about Atomic Design. It’s in presale for $50 (with discounts for teams). Normally, I like to jump into a course and check it out before sharing it. But this is Brad and all he does is wonderful things. For example: The guy arranged his very own concert! He inspires folks to live creatively and authentically with his Wake Up Excited! podcast. There’s another podcast where he encourages designers and developers to Open Up! about their careers and what drives them. I get to participate in that one! Dude is a solid drummer who records himself playing along to his favorite albums, completely unrehearsed. He’s got a crap ton of tracks he writes and records as well. Oh, and his newsletter is pretty awesome, too. And I’m sure I’m leaving out more things he has floating around the web, but you get the point: he’s incredibly knowledgeable on the topic, is a highly-effective educator and speaker, and most importantly, has an infectious positive posture about him. I know the Atomic Design course will be just as awesome. Preordered! Atomic Design Certification Course originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Chrome 139 is experimenting with Open UI’s proposed Interest Invoker API, which would be used to create tooltips, hover menus, hover cards, quick actions, and other types of UIs for showing more information with hover interactions.

A First Look at the Interest Invoker API (for Hover-Triggered Popovers) originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Chrome 139 is experimenting with Open UI’s proposed Interest Invoker API, which would be used to create tooltips, hover menus, hover cards, quick actions, and other types of UIs for showing more information with hover interactions. The Interest Invoker API makes these components declarative and hover-triggered, meaning that you create them with HTML, and then the web browser handles the mouseenter and mouseleave events for you, sans JavaScript. You’d use it like this: <a interestfor="target-id">Interest trigger</a> <div id="target-id" popover>Interest target</div> It’s not stated anywhere that they must be declared as popovers, but they do bake the right accessibility hints in. I want to spend a little time looking at the pieces of this feature, how they‘re used as currently proposed, and offer a few thoughts based on my experience playing with them. Ready to dive in? The interest trigger The trigger is what the user will hover (or long-press on touchscreen devices) to reveal the interest target. I’d call it an “invoker,” but to avoid confusing it with the Invoker Commands API (which is kind of similar), I’ll stick with “trigger” or “interest trigger” for now. The interest trigger can be: a link (<a>), a button (<button>), or an image map area (<area>). And it should have the interestfor attribute whose value should reference the id of the interest target. Here are examples for each supported element: <!-- Link --> <a interestfor="link">Interest trigger</a> <div id="link" popover>Interest target</div> <!-- Button --> <button interestfor="button">Interest trigger</button> <div id="button" popover>Interest target</div> <!-- Image map --> <img src="" alt="" usemap="#map"> <map name="map"> <area interestfor="area" shape="" coords="" alt=""> </map> <div id="area" popover>Interest target</div> If the interest target is a popover (like it is in the examples above), then the interestfor attribute replaces the popovertarget attribute that’s normally required for declarative popovers. So, instead of this: <!-- Button --> <button popovertarget="button">Interest trigger</button> <div id="button" popover>Interest target</div> …we’re looking at this: <!-- Button --> <button interestfor="button">Interest trigger</button> <div id="button" popover>Interest target</div> The interest target The interest target is what’s revealed when the user hovers (or long-presses) the interest trigger. Again, this should be a popover, and it’s important to use the right type of popover because they have different functional and accessibility behaviors. popover attributes that are valueless, empty, or use the auto keyword can be dismissed lightly, i.e., using the esc key, or by clicking outside of the popover. When opened, these popovers close all hint and other auto popovers (at least, the ones that aren’t nested). <div id="target-id" popover>Interest target</div> <!-- Equivalent to --> <div id="target-id" popover="">Interest target</div> <!-- Equivalent to --> <div id="target-id" popover="auto">Interest target</div> hint popovers (the newest type of popovers) can also be dismissed lightly, but only close other hint popovers when opened: <div id="target-id" popover="hint">Interest target</div> manual popovers do their own thing. They can’t be dismissed lightly, don’t tell other popovers what to do, and we can have more than one of them open at a time. They’re suuuper chill. <div id="target-id" popover="manual">Interest target</div> However, Open UI’s explainer and Chrome’s current implementation suggest that interest targets disappear on mouseleave regardless of the type of popover we’re working with. But redefining popover behavior in this context (or any context) feels wrong to me. If the interest target’s popover attribute is set to manual, for example, shouldn’t it persist after mouseleave? Open UI discusses browsers baking the accessibility in depending on the popover type, which justifies interest invokers building off of popovers, but I think accessibility should depend on the content (unless overwritten using ARIA attributes) rather than the popover type. In short, it seems like interest invokers are designed to be used with popovers but for all the wrong reasons (in my opinion anyway). That said, it’s early days still. Interest invokers are very experimental and it’s certainly possible that I’m overlooking something. They’re otherwise straightforward, which is on-brand for Open UI (look at the Customizable Select, after all). They take commonly-used JavaScript-powered components (such as exclusive accordions, invoker commands, and yes, popovers) and make them possible with declarative HTML. That said, there are some JavaScript events that we can use, too. Let’s take a look at those. Interest invoker JavaScript events While I imagine that you’d only need to listen for the interest and loseinterestevents for certain edge cases, JavaScript events for these new declarative HTML features are fairly standard, and they’re there should you need them: interestTrigger.addEventListener("interest", () => { /* User showed interest */ }); interestTrigger.addEventListener("loseinterest", () => { /* User lost interest */ }); But what does “interest” mean, exactly? That’s worth digging into next. Interest delay (and the CSS of it all) You’ve probably noticed that when you show or lose interest, there’s a short delay in the popover showing or hiding itself. This is extremely annoying at first, but when you actually start to build with interest invokers, you realize how necessary it is. Here’s the demo again, so you can try it out (in Chrome 139 or Canary for now): One problem is that if you accidentally mouseleave the interest trigger and the target (which can be very easy to do when the target is too small), then it all disappears. This is even more annoying, but luckily the hide delay allows you some recovery time. Similarly, the show delay offers keyboard and screen reader users the opportunity to skip the interest target, while also preventing it from being triggered accidentally with a mouse pointer. Having said that, if the interest target is unobtrusive, then removing the show delay shouldn’t cause any harm. You could also remove the hide delay for keyboard and screen reader users, who aren’t likely to “lose interest” accidentally. We can do this by setting two new CSS properties, interest-show-delay and interest-hide-delay, to 0. The default is 0.5s and is set on the interest trigger (but not the interest target): /* If unobtrusive */ .unobtrusive[interestfor] { interest-show-delay: 0; } /* If keyboard-focused on a trigger */ [interestfor]:focus-visible { interest-hide-delay: 0; } /* If keyboard-focused within a target of interest, or target of partial interest (these are always keyboard-triggered), the interest trigger that currently has interest or partial interest has the hide delay removed */ body:has(:target-of-interest :focus-visible, :target-of-partial-interest) [interestfor]:where(:has-interest, :has-partial-interest) { interest-hide-delay: 0; } Note: Interest delays are currently buggy, especially with unitless values. Sometimes they work, sometimes they don’t. About those pseudo-selectors, though… Basically, when navigating to an interest trigger using a keyboard or screen reader whose target contains more focusable elements, this is referred to as showing “partial” interest. (I would’ve gone with “potential interest” personally, but I digress.) When this happens, the interest target’s focusable elements actually aren’t focusable (making it easy to skip them, if needed) unless the user hits the option+up/alt+up keyboard shortcut or equivalent screen reader hotkey. There’s even a message that we can customize by targeting :target-of-partial-interest::after: :target-of-partial-interest::after { content: "Press ⌥↑ to activate."; } While you probably shouldn’t change the message content (since it displays the correct keyboard shortcut for the user’s device by default), we can style it by selecting this way. The user agent also throws this in: :target-of-partial-interest { interactivity: not-keyboard-focusable; } The not-keyboard-focusable value is new, and prevents the keyboard focus (like tabindex="-1" but for CSS, which is super interesting in its own right). A full breakdown because, frankly, that was a lot: :has-interest: Triggers with “mouse interest” :has-partial-interest: Triggers with “keyboard interest” :target-of-interest: Targets with mouse interest :target-of-partial-interest: Targets with keyboard interest :target-of-partial-interest::after: The message displayed when targets have keyboard interest interest-show-delay: The <time> before which the interest target appears interest-hide-delay: The <time> before which the interest target disappears interest-delay: Shorthand for interest-show-delay and interest-hide-delay It works with anchors, too Nothing really new here as far as what we’ve already discussed, but I find it cool that we can use anchor elements declaratively just like interest invokers: Conclusion On the surface, interest invokers are simply hover-triggered popovers, but touchscreen devices have never handled hovering well. In addition, hovering is susceptible to human-error, and we certainly don’t want to force keyboards and screen readers to tab into a minefield of focusables. There’s a lot to consider, and Open UI have done a wonderful job of ensuring that user agents do the lion’s share of it. But there’s still more to consider. For example, how exactly would we open interest targets on touchscreen devices? Long-press + “View more info” from the context menu seems to be the best approach at the moment, but that’s a tough one! And, as we’ve discussed, there’s a lot for us to consider, too, such as those delay timings and how interest invokers should be styled. What should interest triggers and targets look like when they have interest? What about the hotkey instruction? We’re talking about some new concepts here, that might require new UX conventions. Honorable mention: We’re also getting interactivity: not-keyboard-focusable out of this, which could help us to build keyboard-friendlier components with CSS. There’s a lot to love here, and I just know that people are going to create incredible tooltips and hover cards and more with this. A First Look at the Interest Invoker API (for Hover-Triggered Popovers) originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Focus trapping is about managing focus within an element, such that focus always stays within it. The whole process sounds simple in theory, but it can quite difficult to build in practice, mostly because of the numerous parts to you got to manage.

A Primer on Focus Trapping originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Focus trapping is a term that refers to managing focus within an element, such that focus always stays within it: If a user tries to tab out from the last element, we return focus to the first one. If the user tries to Shift + Tab out of the first element, we return focus back to the last one. This whole focus trap thing is used to create accessible modal dialogs since it’s a whole ‘nother trouble to inert everything else — but you don’t need it anymore if you’re building modals with the dialog API (assuming you do it right). Anyway, back to focus trapping. The whole process sounds simple in theory, but it can quite difficult to build in practice, mostly because of the numerous parts to you got to manage. Simple and easy focus trapping with Splendid Labz If you are not averse to using code built by others, you might want to consider this snippet with the code I’ve created in Splendid Labz. The basic idea is: We detect all focusable elements within an element. We manage focus with a keydown event listener. import { getFocusableElements, trapFocus } from '@splendidlabz/utils/dom' const dialog = document.querySelector('dialog') // Get all focusable content const focusables = getFocusableElements(node) // Traps focus within the dialog dialog.addEventListener('keydown', event => { trapFocus({ event, focusables }) }) The above code snippet makes focus trapping extremely easy. But, since you’re reading this, I’m sure you wanna know the details that go within each of these functions. Perhaps you wanna build your own, or learn what’s going on. Either way, both are cool — so let’s dive into it. Selecting all focusable elements I did research when I wrote about this some time ago. It seems like you could only focus an a handful of elements: a button input textarea select details iframe embed object summary dialog audio[controls] video[controls] [contenteditable] [tabindex] So, the first step in getFocusableElements is to search for all focusable elements within a container: export function getFocusableElements(container = document.body ) { return { get all () { const elements = Array.from( container.querySelectorAll( `a, button, input, textarea, select, details, iframe, embed, object, summary, dialog, audio[controls], video[controls], [contenteditable], [tabindex] `, ), ) } } } Next, we want to filter away elements that are disabled, hidden or set with display: none, since they cannot be focused on. We can do this with a simple filter function. export function getFocusableElements(container = document.body ) { return { get all () { // ... return elements.filter(el => { if (el.hasAttribute('disabled')) return false if (el.hasAttribute('hidden')) return false if (window.getComputedStyle(el).display === 'none') return false return true }) } } } Next, since we want to trap keyboard focus, it’s only natural to retrieve a list of keyboard-only focusable elements. We can do that easily too. We only need to remove all tabindex values that are less than 0. export function getFocusableElements(container = document.body ) { return { get all () { /* ... */ }, get keyboardOnly() { return this.all.filter(el => el.tabIndex > -1) } } } Now, remember that there are two things we need to do for focus trapping: If a user tries to tab out from the last element, we return focus to the first one. If the user tries to Shift + Tab out of the first element, we return focus back to the last one. This means we need to be able to find the first focusable item and the last focusable item. Luckily, we can add first and last getters to retrieve these elements easily inside getFocusableElements. In this case, since we’re dealing with keyboard elements, we can grab the first and last items from keyboardOnly: export function getFocusableElements(container = document.body ) { return { // ... get first() { return this.keyboardOnly[0] }, get last() { return this.keyboardOnly[0] }, } } We have everything we need — next is to implement the focus trapping functionality. How to trap focus First, we need to detect a keyboard event. We can do this easily with addEventListener: const container = document.querySelector('.some-element') container.addEventListener('keydown', event => {/* ... */}) We need to check if the user is: Pressing tab (without Shift) Pressing tab (with Shift) Splendid Labz has convenient functions to detect these as well: import { isTab, isShiftTab } from '@splendidlabz/utils/dom' // ... container.addEventListener('keydown', event => { if (isTab(event)) // Handle Tab if (isShiftTab(event)) // Handle Shift Tab /* ... */ }) Of course, in the spirit of learning, let’s figure out how to write the code from scratch: You can use event.key to detect whether the Tab key is being pressed. You can use event.shiftKey to detect if the Shift key is being pressed Combine these two, you will be able to write your own isTab and isShiftTab functions: export function isTab(event) { return !event.shiftKey && event.key === 'Tab' } export function isShiftTab(event) { return event.shiftKey && event.key === 'Tab' } Since we’re only handling the Tab key, we can use an early return statement to skip the handling of other keys. container.addEventListener('keydown', event => { if (event.key !== 'Tab') return if (isTab(event)) // Handle Tab if (isShiftTab(event)) // Handle Shift Tab /* ... */ }) We have almost everything we need now. The only thing is to know where the current focused element is at — so we can decide whether to trap focus or allow the default focus action to proceed. We can do this with document.activeElement. Going back to the steps: Shift focus if user Tab on the last item Shift focus if the user Shift + Tab on the first item Naturally, you can tell that we need to check whether document.activeElement is the first or last focusable item. container.addEventListener('keydown', event => { // ... const focusables = getFocusableElements(container) const first = focusables.first const last = focusables.last if (document.activeElement === last && isTab(event)) { // Shift focus to the first item } if (document.activeElement === first && isShiftTab(event)) { // Shift focus to the last item } }) The final step is to use focus to bring focus to the item. container.addEventListener('keydown', event => { // ... if (document.activeElement === last && isTab(event)) { first.focus() } if (document.activeElement === first && isShiftTab(event)) { last.focus() } }) That’s it! Pretty simple if you go through the sequence step-by-step, isn’t it? Final callout to Splendid Labz As I resolve myself to stop teaching (so much) and begin building applications, I find myself needing many common components, utilities, even styles. Since I have the capability to build things for myself, (plus the fact that I’m super particular when it comes to good DX), I’ve decided to gather these things I find or build into a couple of easy-to-use libraries. Just sharing these with you in hopes that they will help speed up your development workflow. Thanks for reading my shameless plug. All the best for whatever you decide to code! A Primer on Focus Trapping originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

A versal letters is a typographic flourish found in illuminated manuscripts and traditional book design, where it adds visual interest and helps guide a reader’s eye to where they should begin.

Getting Creative With Versal Letters originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

A while back, our man Geoff Graham treated us to a refresher on the CSS initial-letter property, but how can you style drop and initial caps to reflect a brand’s visual identity and help to tell its stories? Here’s how I do it in CSS by combining ::first-letter and initial-letter with other unexpected properties, including border-image, and clip-path. Patty Meltt is an up-and-coming country music sensation. My brief: Patty Meltt is an up-and-coming country music sensation, and she needed a website to launch her new album. She wanted it to be distinctive-looking and memorable, so she called Stuff & Nonsense. Patty’s not real, but the challenges of designing and developing sites like hers are. First, a drop cap recap. Chris Coyier wrote about drop caps several years ago. They are a decorative letter at the beginning of a paragraph, often spanning several lines of text. It’s a typographic flourish found in illuminated manuscripts and traditional book design, where it adds visual interest and helps guide a reader’s eye to where they should begin. Study manuscripts from the Middle Ages onwards, and you’ll find hand-decorated illuminated capitals. The artists who made these initial letters were fabulously called “illuminators.” These medieval versals went beyond showing someone where to start reading; historiated letters also illustrated the stories, which was especially useful since most people in the Middle Ages couldn’t read. A basic drop cap On the web, drop caps can improve readability and reflect a brand’s visual identity. A brief refresher on properties and values In CSS, drop caps are created using the ::first-letter pseudo-element in combination with initial-letter. As you might expect, ::first-letter targets the very first letter of a block of text, enabling you to style it independently from the rest of a paragraph. The first number sets how many lines tall the letter appears, and the second controls its baseline alignment — that is, which line of text the bottom of the cap sits on. p::first-letter { -webkit-initial-letter: 3 3; initial-letter: 3 3; } Because browser support still varies, it’s common to include both the unprefixed and -webkit- prefixed properties for maximum compatibility. And speaking of browser support, it’s also sensible to wrap the initial-letter property inside an @supports CSS at-rule so we can check for browser support and provide a fallback, if needed: @supports (initial-letter:2) or (-webkit-initial-letter:2) { p::first-letter { -webkit-initial-letter: 3 3; initial-letter: 3 3; } } The initial-letter property automatically calculates the font size to match the number of lines a drop cap spans. On its own, this can make for quite a first impression. However, drop caps really start to come to life when you combine initial-letter with other CSS properties. Tip: Interactive examples from this article are available in my lab. Shadows Text shadows applied to first letters (live demo) When I want to lift a drop cap off the page, I can add a single text-shadow. Shadows can be colourful and don’t have to be black. I created a full live demo you can check out. p::first-letter { /* ... *// text-shadow: 6px 6px 0 #e6d5b3; } But why use just one shadow when two hard-edged shadows will turn a cap into a classic graphic typographic element? p::first-letter { /* ... */ text-shadow: -6px -6px 0 #7d6975, 6px 6px 0 #e6d5b3; } Examples showing unstyled, single text shadow, and two text shadows (live demo) Strokes A text shadow applied to a first letter (live demo) The text-stroke property — shorthand for text-stroke-width and text-stroke-color — adds an outline to the centre of the text shape. It’s a Baseline feature and is now widely available. I can make the cap text transparent or colour it to match the page background. p::first-letter { /* ... */ text-stroke: 5px #e6d5b3; } Backgrounds Solid and gradient backgrounds applied to first letters (live demo) Adding a background is a simple way to start making a cap more decorative. I could start by adding a solid background-color. p::first-letter { /* ... */ background-color: #97838f; } To add a lighting effect, I could apply a conical, linear, or radial gradient background image (here’s a demo): p::first-letter { /* ... */ background-color: #e6d5b3; background-image: linear-gradient(135deg,#c8b9c2 0%, #7d6975 50%); } And even an image URL to use a bitmap or vector image as a background (and here’s that demo): p::first-letter { /* ... */ background-color: #e6d5b3; background-image: url(...); background-size: cover; } Background images and a background clipped to text Things become even more interesting by clipping a bitmap, gradient, or vector background image to the text while setting its colour to transparent. Now, the image will only appear inside the text space (demo). p::first-letter { /* ... */ background-clip: text; color: transparent; } Borders Two examples of borders applied to first letters, one square and one rounded You might think borders are boring, but there’s plenty you can do to make them look interesting. I could start by applying a solid border to surround the cap box (demo). p::first-letter { /* ... */ border: 5px solid #e6d5b3; } Then, I could apply border-radius to slightly round all its corners (demo). p::first-letter { /* ... */ border-radius: 1rem; } Or, I might round individual corners for a more interesting look (demo): p::first-letter { /* ... */ border-top-left-radius: 3rem; border-bottom-right-radius: 3rem; } A border radius applied to the first letter, where the top-left and bottom-right edges are rounded (live demo) And then there’s the border-image property, a powerful, yet often overlooked CSS tool. By slicing, repeating, and outsetting images, you can create intricate borders and decorative drop caps with minimal code. A CSS border image applied to a first letter (live demo) You can insert a bitmap or vector format image, or drop a CSS gradient into the border space: p::first-letter { /* ... */ border-style: solid; border-width: 10px; border-image: conic-gradient(...) 1; } Clipping Clipping first letters The clip-path property lets you define a custom shape that controls which parts of an element are visible and which are hidden. Instead of always showing a rectangular box, you can use clip-path to crop elements into circles, polygons, or even complex shapes defined with SVG paths. It’s an effective way to create visual effects like this right-facing arrow. Clipping the drop cap into an arrow shape isn’t just decorative — it reinforces direction and hierarchy, literally pointing readers to where the story begins. Here’s a demo of the following example. p::first-letter { /* ... */ padding-inline: 1rem 2rem; background-color: #e6d5b3; clip-path: polygon(...); } Or a glossy sticker shape cap, made by combining clip-path with a gradient background image and a text shadow (demo). Transforms Two examples of transforming first letters, one rotated (demo) and one scaled (demo) You can transform a drop cap independently from the rest of a paragraph by rotating, scaling, skewing, or translating it to make it feel more dynamic: p::first-letter { /* ... */ margin-inline-end: 2.5em; transform: skew(20deg, 0deg); } And with a little trial and error to arrive at the correct values, you could even flow the remaining paragraph text around the cap using the shape-outside property (demo): p::first-letter { /* ... */ display: block; float: left; shape-outside: polygon(0 0, 0 200px, 250px 600px); shape-margin: 50px; transform: skew(20deg, 0deg) translateX(-60px); } Drop caps don’t just help guide a reader’s eye to where they should begin; they also set the tone for what follows. A well-designed drop cap adds visual interest at the start of a block of text, drawing attention in a way that feels intentional and designed. Because it’s often the first element the reader sees, caps can carry a lot of visual weight, making them powerful tools for expressing a brand’s identity. Designing for Patty Meltt Patty Meltt wanted a website packed with design details. Every element added to a design is an opportunity to be expressive, and that includes her drop caps. Her biography page is presentable, but we felt a focus on where someone should start reading was lacking. Patty Meltt’s biography without a drop cap From the selection of designs I showed her, she felt the sticker-style cap best suited her brand. To implement it, first, I added a cursive typeface which matches her branding and contrasts with the rest of her typographic design: p::first-letter { font-family: "Lobster Two", sans-serif; font-weight: 700; } I changed the cap colour to match the page background and added a semi-transparent text shadow: p::first-letter { /* ... */ color: #140F0A; text-shadow: 6px 6px 0 rgba(163,148, 117, .8); } Next, I clipped the cap box to a visible area shaped like a sticker: p::first-letter { /* ... */ clip-path: polygon(...); } …before applying two background images — a noise-filled SVG and a radial gradient — that I blended using a background-blend-mode: p::first-letter { /* ... */ background-image: url(img/cap-noise.svg), radial-gradient(circle, #e6d5b3 0%, #cdaa65 100%); background-blend-mode: soft-light, normal; } Patty Meltt’s biography with a stylsh new drop cap (demo) The result is a drop cap that’s as stylish as cut-off jeans and a pair of gator-skinned boots. Conclusion Styling drop caps isn’t just about decoration — it’s about setting a tone, drawing readers in, and using every detail to express a brand’s voice. CSS has the tools to go beyond the default: gradients, textures, borders, and even complex shapes all help transform first letters into statements. So don’t waste the opportunities that drop caps give you. Make ’em sing. Getting Creative With Versal Letters originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Gathered notes on Liquid Glass, Apple’s new design language that was introduced at WWDC 2025. These links are a choice selection of posts and resources that I've found helpful for understanding the context of Liquid Glass, as well as techniques for recreating it in code.

Getting Clarity on Apple’s Liquid Glass originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Folks have a lot to say about “liquid glass,” the design aesthetic that Apple introduced at WWDC 2025. Some love it, some hate it, and others jumped straight into seeing how to they could create it in CSS. There’s a lot to love, hate, and experience with liquid glass. You can love the way content reflects against backgrounds. You can hate the poor contrast between foreground and background. And you can be eager to work with it. All of those can be true at the same time. Image credit: Apple I, for one, am generally neutral with things like this for that exact reason. I’m intrigued by liquid glass, but hold some concern about legibility, particularly as someone who already struggles with the legibility of Apple’s existing design system (notably in Control Center). And I love looking at the many and clever ways that devs have tried to replicate liquid glass in their own experiments. So, I’m in the process of gathering notes on the topic as I wrap my head around this “new” (or not-so-new, depending on who’s talking) thing and figure out where it fits in my own work. These links are a choice selection of posts that I’ve found helpful and definitely not meant to be an exhaustive list of what’s out there. WWDC Introduction Always a good idea to start with information straight from the horse’s mouth. In short: It’s the first design system that is universally applied to all of Apple’s platforms, as opposed to a single platform like Apple’s last major overhaul, iOS 7. It’s designed to refract light and dynamically react to user interactions. By “dynamic” we’re referring to UI elements updating into others as the context changes, such as displaying additional controls. This sounds a lot like the Dynamic Island, supporting shape-shifting animations. There’s a focus on freeing up space by removing hard rectangular edges, allowing UI elements to become part of the content and respond to context. Apple also released a more in-depth video aimed at introducing liquid glass to designers and developers. In short: Liquid glass is an evolution of the “aqua” blue interface from macOS 10, the real-time introduced in iOS 7, the “fluidity” of iOS 10, the flexibility of the Dynamic Island, and the immersive interface of visionOS. It’s a “digital meta-material” that dynamically bends and shapes light while moving fluidly like water. It’s at least partially a response to hardware devices adopting deeper rounded corners. Lensing: Background elements are bended and warped rather than scattering light as it’s been in previous designs. There’s gel-like feel to elements. Translucence helps reveal what is underneath a control, such as a progress indicator you can scrub more precisely by seeing what is behind the surface. Controls are persistent between views for establishing a relationship between controls and states. This reminds me of the View Transition API. Elements automatically adapt to light and dark modes. Liquid glass is composed of layers: highlight (light casting and movement), shadow (added depth for separation between foreground and background), and illumination (the flexible properties of the material). It is not meant to be used everywhere but is most effective for the navigation layer. And avoid using glass on glass. There are two variants: regular (most versatile) and clear (does not have adaptive behaviors for allowing content to be more visible below the surface). Glass can be tinted different colors. Documentation Right on cue, Apple has already made a number of developer resources available for using and implementing liquid glass that are handy references. Introduction to Liquid Glass Adopting Liquid Glass Landmarks: Building an app with Liquid Glass Applying Liquid Glass to custom views ‘Beautiful’ and ‘Hard to Read’: Designers React to Apple’s Liquid Glass Update This Wired piece is a nice general overview of what liquid glass is and context about how it was introduced at WWDC 2025. I like getting a take on this from a general tech perspective as opposed to, say, someone’s quick hot take. It’s a helpful pulse on what’s happening from a high level without a bunch of hyperbole, setting the stage for digging deeper into things. In short: Apple is calling this “Liquid Glass.” It’s Apple’s first significant UI overhaul in 10 years. It will be implemented across all of Apple’s platforms, including iOS, macOS, iPadOS, and even the Vision Pro headset from which it was inspired. “From a technical perspective, it’s a very impressive effect. I applaud the time and effort it must have taken to mimic refraction and dispersion of light to such a high degree.” “Similar to the first beta for iOS 7, what we’ve seen so far is rough on the edges and potentially veers into distracting or challenging to read, especially for users with visual impairments.” Accessibility Let’s get right to the heart of where the pushback against liquid glass is coming from. While the aesthetic, purpose, and principles of liquid glass are broadly applauded, many are concerned about the legibility of content against a glass surface. Traditionally, we fill backgrounds with solid or opaque solid color to establish contrast between the foreground and background, but with refracted light, color plays less a role and it’s possible that highlighting or dimming a light source will not produce enough contrast, particularly for those with low-vision. WCAG 2.2 emphasizes color and font size for improving contrast and does provide guidance for something that’s amorphous like liquid glass where bending the content below it is what establishes contrast. “Apple’s “Liquid Glass” and What It Means for Accessibility”: “When you have translucent elements letting background colors bleed through, you’re creating variable contrast ratios that might work well over one background, but fail over a bright photo of the sunset.” “Apple turned the iPhone’s notch into the Dynamic Island, Android phones that don’t have notches started making fake notches, just so they could have a Dynamic Island too. That’s influence. But here they are making what looks like a purely aesthetic decision without addressing the accessibility implications.” “People with dyslexia, who already struggle with busy backgrounds and low-contrast text, now deal with an interface where visual noise is baked into the design language. People with attention disorders may have their focus messed up when they see multiple translucent layers creating a whole lot of visual noise.” “It’s like having a grand entrance and a side door marked ‘accessible.’ Technically compliant. But missing the point.” “The legal landscape adds another layer. There’s thousands of digital accessibility lawsuits filed in the U.S. yearly for violating the ADA, or the American Disabilities Act. Companies are paying millions in settlements. But this is Apple. They have millions. Plus all the resources in the world to save them from legal risks. But their influence means they’re setting precedents.” “Liquid Glass: Apple vs accessibility”: “Yet even in Apple’s press release, linked earlier, there are multiple screenshots where key interface components are, at best, very difficult to read. That is the new foundational point for Apple design. And those screenshots will have been designed to show the best of things.” “Apple is still very often reactive rather than proactive regarding vision accessibility. Even today, there are major problems with the previous versions of its operating systems (one example being the vestibular trigger if you tap-hold the Focus button in Control Centre). One year on, they aren’t fixed.” “State, correctly, that Apple is a leader in accessibility. But stop assuming that just because this new design might be OK for you and because Apple has controls in place that might help people avoid the worst effects of design changes, everything is just peachy. Because it isn’t.” “Liquid Glass” by Hardik Pandya “The effect is technically impressive, but it introduces a layer of visual processing between you and your memories. What was once immediate now feels mediated. What was once direct now feels filtered.” “While Apple’s rationale for Liquid Glass centers on ‘seeing’ content through a refractive surface, user interface controls are not meant to be seen—they are meant to be operated. When you tap a button, slide a slider, or toggle a switch, you are not observing these elements. You are manipulating them directly.” “Buttons become amorphous shapes. Sliders lose their mechanical clarity. Toggle switches abandon their physical affordances. They appear as abstract forms floating behind glass—beautiful perhaps, but disconnected from the fundamental purpose of interface controls: to invite and respond to direct manipulation.” “The most forward-thinking interface design today focuses on invisibility – making the interaction so seamless that the interface itself disappears. Liquid Glass makes the interface more visible, more present, and more demanding of attention.” “Liquid glass, now with frosted tips”: It’s easy to dump on liquid glass in its introductory form, but it’s worth remembering that it’s in beta and that Apple is actively developing it ahead of its formal release. A lot has changed between the Beta 2 and Beta 3 releases. The opacity between glass and content has been bumped up in several key areas. Tutorials, Generators, and Frameworks It’s fun to see the difference approaches many folks have used to re-create the liquid glass effect in these early days. It amazes me that there is already a deluge of tutorials, generators, and even UI frameworks when we’re only a month past the WWDC 2025 introduction. Create this trendy blurry glass effect with CSS (Kevin Powell) Liquid Glass design using CSS (Nordcraft) Adopting Apple’s Liquid Glass: Examples and best practices (LogRocket) Liquid Glass Figma File CSS Liquid Glass Effects (DesignFast) Liquid Glass UI Framework Liquid Glass CSS Generator Experiments Let’s drop in a few interesting demos that folks have created. To be clear, glass-based interfaces are not new and have been plenty explored, which you can find over at CodePen in abundance. These are recent experiments. The most common approaches appear to reach for SVG filters and background blurs, though there are many programmatic demos as well. Using a CSS-only approach with an SVG filter with backdrop-filter with a series of nested containers that sorta mimics how Apple describes glass as being composed of three layers (highlight, shadow and illumination): Same sort of deal here, but in the context of a theme toggle switch that demonstrates how glass can be tinted: Comparing a straight-up CSS blur with an SVG backdrop: Contextual example of a slider component: Using WebGL: Assorted links and coverage A few more links from this browser tab group I have open: “Apple’s Liquid Glass is exactly as ambitious as Apple” (Fast Company) “Apple unveils iOS 26 with Liquid Glass” (9to5Mac) “Apple Announces All-New ‘Liquid Glass’ Software Redesign Across iOS 26 and More” (MacRumors) “Apple just added more frost to its Liquid Glass design” (The Verge) “Apple tones down Liquid Glass effect in iOS 26 beta 3” (The Apple Post) “More assorted notes on Liquid Glass” (Riccardo Mori) A bunch of CodePen Collections Getting Clarity on Apple’s Liquid Glass originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

State of Devs 2025 survey results are out! Sunkanmi Fafowora highlights a few key results about diversity, health, and salaries.

What I Took From the State of Dev 2025 Survey originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

State of Devs 2025 survey results are out! While the survey isn’t directly related to the code part of what we do for work, I do love the focus Devographics took ever since its inception in 2020. And this year it brought us some rather interesting results through the attendance of 8,717 developers, lots of data, and even more useful insights that I think everyone can look up and learn from. I decided to look at the survey results with an analytical mindset, but wound up pouring my heart out because, well, I am a developer, and the entire survey affects me in a way. I have some personal opinions, it turns out. So, sit back, relax, and indulge me for a bit as we look at a few choice pieces of the survey. And it’s worth noting that this is only part one of the survey results. A second data dump will be published later and I’m interested to poke at those numbers, too. An opportunity to connect One thing I noticed from the Demographics section is how much tech connects us all. The majority of responses come from the U.S. (26%) but many other countries, including Italy, Germany, France, Estonia, Austria, South Africa and many more, account for the remaining 74%. I mean, I am working and communicating with you right now, all the way from Nigeria! Isn’t that beautiful, to be able to communicate with people around the world through this wonderful place we call CSS-Tricks? And into the bigger community of developers that keeps it so fun? I think this is a testament to how much we want to connect. More so, the State of Devs survey gives us an opportunity to express our pain points on issues surrounding our experiences, workplace environments, quality of health, and even what hobbies we have as developers. And while I say developers, the survey makes it clear it’s more than that. Behind anyone’s face is someone encountering life challenges. We’re all people and people are capable of pure emotion. We are all just human. It’s also one of the reasons I decided to open a Bluesky account: to connect with more developers. I think this survey offers insights into how much we care about ourselves in tech, and how eager we are to solve issues rarely talked about. And the fact that it’s global in nature illustrates how much in common we all have. More women participated this year From what I noticed, fewer women participated in the 2024 State of JavaScript and State of CSS fewer women (around 6%), while women represented a bigger share in this year’s State of Devs survey. I’d say 15% is still far too low to fairly “represent” an entire key segment of people, but it is certainly encouraging to see a greater slice in this particular survey. We need more women in this male-dominated industry. Experience over talent Contrary to popular opinion, personal performance does not usually equate to higher pay, and this is reflected in the results of this survey. It’s more like, the more experienced you are, the more you’re paid. But even that’s not the full story. If you’re new to the field, you still have to do some personal marketing, find and keep a mentor, and a whole bunch of stuff. Cassidy shares some nice insights on this in a video interview tracing her development career. You should check it out, especially if you’re just starting out. Notice that the average income for those with 10-14 of experience ($115,833) is on par with those with between 15-29 years of experience ($118,000) and not far from those with 30+ years ($120,401). Experience appears to influence income, but perhaps not to the extent you would think, or else we’d see a wider gap between those with 15 years versus those with more than double the service time. More than that, notice how income for the most experienced developers (30+ years) is larger on average but the range of how much they make is lower than than those with 10-29 years under their belts. I’m curious what causes that decline. Is it a lack of keeping up with what’s new? Is it ageism? I’m sure there are lots of explanations. Salary, workplace, and job hunting I prefer not drill into each and every report. I’m interested in very specific areas that are covered in the survey. And what I take away from the survey is bound to be different than your takeaways, despite numbers being what they are. So, here are a few highlights of what stood out to me personally as I combed through the results. Your experience, employment status, and company’s employer count seem to directly affect pay. For example, full-timers report higher salaries than freelancers. I suppose that makes sense, but I doubt it provides the full picture because freelancers freelance for a number of reasons, whether its flexible hours, having more choice to choose their projects, or having personal constraints that limit how much they can work. In some ways, freelancers are able to command higher pay while working less. Bad management and burnout seem to be the most talked-about issues in the workplace. Be on guard during interviews, look up reviews about the company you’re about to work for, and make sure there are far fewer complaints than accolades. Make sure you’re not being too worked up during work hours; breaks are essential for a boost in productivity. Seventy percent of folks reported no discrimination in the workplace, which means we’re perhaps doing something right. That said, it’s still disheartening that 30% experience some form of discrimination and lowering that figure is something we ought to aim for. I’m hoping companies — particularly the tech giants in our space — take note of this and enforce laws and policies surrounding this. Still, we can always call out discriminatory behavior and make corrections where necessary. And who’s to say that everyone who answered the survey felt safe sharing that sort of thing? Silence can be the enemy of progress. Never get too comfortable in your job. Although 69% report having never been laid off, I still think that job security is brittle in this space. Always learn, build, and if possible, try to look for other sources of income. Layoffs are still happening, and looking at the news, it’s likely to continue for the foreseeable future, with the U.S., Australia, and U.K. being leading the way. One number that jumped off the page for me is that it takes an average of four applications for most developers to find a new job. This bamboozles me. I’m looking for a full-time role (yes, I’m available!), and I regularly apply for more than four jobs in a given day. Perhaps I’m doing something wrong, but that’s also not consistent with those in my social and professional circles. I know and see plenty of people who are working hard to find work, and the number of jobs they apply for has to bring that number up. Four applications seems way low, though I don’t have the quantitative proof for it. Your personal network is still the best way to find a job. We will always and forever be social animals, and I think that’s why most survey participants say that coworker relationships are the greatest perk of a job. I find this to be true with my work here at CSS-Tricks. I get to collaborate with other like-minded CSS and front-end enthusiasts far and wide. I’ve developed close relationships with the editors and other writers, and that’s something I value more than any other benefits I could get somewhere else. Compensation is still a top workplace challenge. JavaScript is still the king of programming (bias alert), taking the top spot as the most popular programming language. I know you’re interested, that CSS came in at third. To my surprise, Bluesky is more popular amongst developers than X. I didn’t realize how much toxicity I’ve been exposed to at X until I opened a Bluesky account. I hate saying that the “engagement” is better, or some buzz-worthy thing like that, but I do experience more actual discussions over at Bluesky than I have for a long time at X. And many of you report the same. I hasten to say that Bluesky is a direct replacement for what X (let’s face it, Twitter) used to be, but it seems we at least have a better alternative. Health issues Without our health, we are nothing. Embrace your body for what it is: your temple. It’s a symbiotic relationship. — Mrs. N. I’m looking closer at the survey’s results on health because of the sheer number of responses that report health issues. I struggle with issues, like back pains, and that forced me to upgrade my work environment with a proper desk and chair. I tend to code on my bed, and well, it worked. But perhaps it wasn’t the best thing for my physical health. I know we can fall into the stereotype of people who spend 8-12 hours staring at two big monitors, sitting in a plush gaming chair, while frantically typing away at a mechanical keyboard. You know, the Hackers stereotype. I know that isn’t an accurate portrayal of who we are, but it’s easy to become that because of how people look at and understand our work. And if you feel a great deal of pressure to keep up with that image, I think it’s worth getting into a more healthy mindset, one that gets more than a few hours of sleep, prioritizes exercise, maintains a balanced diet, and all those things we know are ultimately good for us. Even though 20% of folks say they have no health issues at all, a whopping 80% struggle with health issues ranging from sleep deprivation to keeping a healthy weight. You are important and deserve to feel healthy. Think about your health the way you think about the UI/UX of the websites you design and build. It makes up a part of the design, but has the crucial role of turning ordinary tasks into enjoyable experiences, which in turn, transforms into an overall beautiful experience for the user. Your health is the same. Those small parts often overlooked can and will affect the great machine that is your body. Here’s a small list of life improvements you can make right now. Closing thoughts Diversity, representation, experience, income, and health. That’s what stood out to me in the 2025 State of Devs survey results. I see positive trends in the numbers, but also a huge amount of opportunity to be better, particularly when it comes being more inclusive of women, providing ample chances for upward mobility based on experience, and how we treat ourselves. Please check out the results and see what stands out to you. What do you notice? Is there anything you are able to take away from the survey that you can use in your own work or life? I’d love to know! What I Took From the State of Dev 2025 Survey originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

The many ways to juggle line length when working with text... including two proposed properties that could make it easier in the future.

Setting Line Length in CSS (and Fitting Text to a Container) originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

First, what is line length? Line length is the length of a container that holds a body of multi-line text. “Multi-line” is the key part here, because text becomes less readable if the beginning of a line of text is too far away from the end of the prior line of text. This causes users to reread lines by mistake, and generally get lost while reading. Luckily, the Web Content Accessibility Guidelines (WCAG) gives us a pretty hard rule to follow: no more than 80 characters on a line (40 if the language is Chinese, Japanese, or Korean), which is super easy to implement using character (ch) units: width: 80ch; The width of 1ch is equal to the width of the number 0 in your chosen font, so the exact width depends on the font. Setting the optimal line length Just because you’re allowed up to 80 characters on a line, it doesn’t mean that you have to aim for that number. A study by the Baymard Institute revealed that a line length of 50-75 characters is the optimal length — this takes into consideration that smaller line lengths mean more lines and, therefore, more opportunities for users to make reading mistakes. That being said, we also have responsive design to think about, so setting a minimum width (e.g., min-width: 50ch) isn’t a good idea because you’re unlikely to fit 50 characters on a line with, for example, a screen/window size that is 320 pixels wide. So, there’s a bit of nuance involved, and the best way to handle that is by combining the clamp() and min() functions: clamp(): Set a fluid value that’s relative to a container using percentage, viewport, or container query units, but with minimum and maximum constraints. min(): Set the smallest value from a list of comma-separated values. Let’s start with min(). One of the arguments is 93.75vw. Assuming that the container extends across the whole viewport, this’d equal 300px when the viewport width is 320px (allowing for 20px of spacing to be distributed as you see fit) and 1350px when the viewport width is 1440px. However, for as long as the other argument (50ch) is the smallest of the two values, that’s the value that min() will resolve to. min(93.75vw, 50ch); Next is clamp(), which accepts three arguments in the following order: the minimum, preferred, and maximum values. This is how we’ll set the line length. For the minimum, you’d plug in your min() function, which sets the 50ch line length but only conditionally. For the maximum, I suggest 75ch, as mentioned before. The preferred value is totally up to you — this will be the width of your container when not hitting the minimum or maximum. width: clamp(min(93.75vw, 50ch), 70vw, 75ch); In addition, you can use min(), max(), and calc() in any of those arguments to add further nuance. If the container feels too narrow, then the font-size might be too large. If it feels too wide, then the font-size might be too small. Fit text to container (with JavaScript) You know that design trend where text is made to fit the width of a container? Typically, to utilize as much of the available space as possible? You’ll often see it applied to headings on marketing pages and blog posts. Well, Chris wrote about it back in 2018, rounding up several ways to achieve the effect with JavaScript or jQuery, unfortunately with limitations. However, the ending reveals that you can just use SVG as long as you know the viewBox values, and I actually have a trick for getting them. Although it still requires 3-5 lines of JavaScript, it’s the shortest method I’ve found. It also slides into HTML and CSS perfectly, particularly since the SVG inherits many CSS properties (including the color, thanks to fill: currentColor): <h1 class="container"> <svg> <text>Fit text to container</text> </svg> </h1> h1.container { /* Container size */ width: 100%; /* Type styles (<text> will inherit most of them) */ font: 900 1em system-ui; color: hsl(43 74% 3%); text { /* We have to use fill: instead of color: here But we can use currentColor to inherit the color */ fill: currentColor; } } /* Select all SVGs */ const svg = document.querySelectorAll("svg"); /* Loop all SVGs */ svg.forEach(element => { /* Get bounding box of <text> element */ const bbox = element.querySelector("text").getBBox(); /* Apply bounding box values to SVG element as viewBox */ element.setAttribute("viewBox", [bbox.x, bbox.y, bbox.width, bbox.height].join(" ")); }); Fit text to container (pure CSS) If you’re hell-bent on a pure-CSS method, you are in luck. However, despite the insane things that we can do with CSS these days, Roman Komarov’s fit-to-width hack is a bit complicated (albeit rather impressive). Here’s the gist of it: The text is duplicated a couple of times (although hidden accessibly with aria-hidden and hidden literally with visibility: hidden) so that we can do math with the hidden ones, and then apply the result to the visible one. Using container queries/container query units, the math involves dividing the inline size of the text by the inline size of the container to get a scaling factor, which we then use on the visible text’s font-size to make it grow or shrink. To make the scaling factor unitless, we use the tan(atan2()) type-casting trick. Certain custom properties must be registered using the @property at-rule (otherwise they don’t work as intended). The final font-size value utilizes clamp() to set minimum and maximum font sizes, but these are optional. <span class="text-fit"> <span> <span class="text-fit"> <span><span>fit-to-width text</span></span> <span aria-hidden="true">fit-to-width text</span> </span> </span> <span aria-hidden="true">fit-to-width text</span> </span> .text-fit { display: flex; container-type: inline-size; --captured-length: initial; --support-sentinel: var(--captured-length, 9999px); & > [aria-hidden] { visibility: hidden; } & > :not([aria-hidden]) { flex-grow: 1; container-type: inline-size; --captured-length: 100cqi; --available-space: var(--captured-length); & > * { --support-sentinel: inherit; --captured-length: 100cqi; --ratio: tan( atan2( var(--available-space), var(--available-space) - var(--captured-length) ) ); --font-size: clamp( 1em, 1em * var(--ratio), var(--max-font-size, infinity * 1px) - var(--support-sentinel) ); inline-size: var(--available-space); &:not(.text-fit) { display: block; font-size: var(--font-size); @container (inline-size > 0) { white-space: nowrap; } } /* Necessary for variable fonts that use optical sizing */ &.text-fit { --captured-length2: var(--font-size); font-variation-settings: "opsz" tan(atan2(var(--captured-length2), 1px)); } } } } @property --captured-length { syntax: "<length>"; initial-value: 0px; inherits: true; } @property --captured-length2 { syntax: "<length>"; initial-value: 0px; inherits: true; } Watch for new text-grow/text-shrink properties To make fitting text to a container possible in just one line of CSS, a number of solutions have been discussed. The favored solution seems to be two new text-grow and text-shrink properties. Personally, I don’t think we need two different properties. In fact, I prefer the simpler alternative, font-size: fit-width, but since text-grow and text-shrink are already on the table (Chrome intends to prototype and you can track it), let’s take a look at how they could work. The first thing that you need to know is that, as proposed, the text-grow and text-shrink properties can apply to multiple lines of wrapped text within a container, and that’s huge because we can’t do that with my JavaScript technique or Roman’s CSS technique (where each line needs to have its own container). Both have the same syntax, and you’ll need to use both if you want to allow both growing and shrinking: text-grow: <fit-target> <fit-method>? <length>?; text-shrink: <fit-target> <fit-method>? <length>?; <fit-target> per-line: For text-grow, lines of text shorter than the container will grow to fit it. For text-shrink, lines of text longer than the container will shrink to fit it. consistent: For text-grow, the shortest line will grow to fit the container while all other lines grow by the same scaling factor. For text-shrink, the longest line will shrink to fit the container while all other lines shrink by the same scaling factor. <fit-method> (optional) scale: Scale the glyphs instead of changing the font-size. scale-inline: Scale the glyphs instead of changing the font-size, but only horizontally. font-size: Grow or shrink the font size accordingly. (I don’t know what the default value would be, but I imagine this would be it.) letter-spacing: The letter spacing will grow/shrink instead of the font-size. <length> (optional): The maximum font size for text-grow or minimum font size for text-shrink. Again, I think I prefer the font-size: fit-width approach as this would grow and shrink all lines to fit the container in just one line of CSS. The above proposal does way more than I want it to, and there are already a number of roadblocks to overcome (many of which are accessibility-related). That’s just me, though, and I’d be curious to know your thoughts in the comments. Conclusion It’s easier to set line length with CSS now than it was a few years ago. Now we have character units, clamp() and min() (and max() and calc() if you wanted to throw those in too), and wacky things that we can do with SVGs and CSS to fit text to a container. It does look like text-grow and text-shrink (or an equivalent solution) are what we truly need though, at least in some scenarios. Until we get there, this is a good time to weigh-in, which you can do by adding your feedback, tests, and use-cases to the GitHub issue. Setting Line Length in CSS (and Fitting Text to a Container) originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

I was playing around with scroll-driven animations, just searching for all sorts of random things you could do. That’s when I came up with the idea to animate main headings and, using scroll-driven animations, change the headings based on the user’s scroll position.

Scroll-Driven Sticky Heading originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Scroll-driven animations are great! They’re a powerful tool that lets developers tie the movement and transformation of elements directly to the user’s scroll position. This technique opens up new ways to create interactive experiences, cuing images to appear, text to glide across the stage, and backgrounds to subtly shift. Used thoughtfully, scroll-driven animations (SDA) can make your website feel more dynamic, engaging, and responsive. A few weeks back, I was playing around with scroll-driven animations, just searching for all sorts of random things you could do with it. That’s when I came up with the idea to animate the text of the main heading (h1) and, using SDA, change the heading itself based on the user’s scroll position on the page. In this article, we’re going to break down that idea and rebuild it step by step. This is the general direction we’ll be heading in, which looks better in full screen and viewed in a Chromium browser: It’s important to note that the effect in this example only works in browsers that support scroll-driven animations. Where SDA isn’t supported, there’s a proper fallback to static headings. From an accessibility perspective, if the browser has reduced motion enabled or if the page is being accessed with assistive technology, the effect is disabled and the user gets all the content in a fully semantic and accessible way. Just a quick note: this approach does rely on a few “magic numbers” for the keyframes, which we’ll talk about later on. While they’re surprisingly responsive, this method is really best suited for static content, and it’s not ideal for highly dynamic websites. Closer Look at the Animation Before we dive into scroll-driven animations, let’s take a minute to look at the text animation itself, and how it actually works. This is based on an idea I had a few years back when I wanted to create a typewriter effect. At the time, most of the methods I found involved animating the element’s width, required using a monospace font, or a solid color background. None of which really worked for me. So I looked for a way to animate the content itself, and the solution was, as it often is, in pseudo-elements. Pseudo-elements have a content property, and you can (kind of) animate that text. It’s not exactly animation, but you can change the content dynamically. The cool part is that the only thing that changes is the text itself, no other tricks required. Start With a Solid Foundation Now that you know the trick behind the text animation, let’s see how to combine it with a scroll-driven animation, and make sure we have a solid, accessible fallback as well. We’ll start with some basic semantic markup. I’ll wrap everything in a main element, with individual sections inside. Each section gets its own heading and content, like text and images. For this example, I’ve set up four sections, each with a bit of text and some images, all about Primary Colors. <main> <section> <h1>Primary Colors</h1> <p>The three primary colors (red, blue, and yellow) form the basis of all other colors on the color wheel. Mixing them in different combinations produces a wide array of hues.</p> <img src="./colors.jpg" alt="...image description"> </section> <section> <h2>Red Power</h2> <p>Red is a bold and vibrant color, symbolizing energy, passion, and warmth. It easily attracts attention and is often linked with strong emotions.</p> <img src="./red.jpg" alt="...image description"> </section> <section> <h2>Blue Calm</h2> <p>Blue is a calm and cool color, representing tranquility, stability, and trust. It evokes images of the sky and sea, creating a peaceful mood.</p> <img src="./blue.jpg" alt="...image description"> </section> <section> <h2>Yellow Joy</h2> <p>Yellow is a bright and cheerful color, standing for light, optimism, and creativity. It is highly visible and brings a sense of happiness and hope.</p> <img src="./yellow.jpg" alt="...image description"> </section> </main> As for the styling, I’m not doing anything special at this stage, just the basics. I changed the font and adjusted the text and heading sizes, set up the display for the main and the sections, and fixed the image sizes with object-fit. So, at this point, we have a simple site with static, semantic, and accessible content, which is great. Now the goal is to make sure it stays that way as we start adding our effect. The Second First Heading We’ll start by adding another h1 element at the top of the main. This new element will serve as the placeholder for our animated text, updating according to the user’s scroll position. And yes, I know there’s already an h1 in the first section; that’s fine and we’ll address it in a moment so that only one is accessible at a time. <h1 class="scrollDrivenHeading" aria-hidden="true">Primary Colors</h1> Notice that I’ve added aria-hidden="true" to this heading, so it won’t be picked up by screen readers. Now I can add a class specifically for screen readers, .srOnly, to all the other headings. This way, anyone viewing the content “normally” will see only the animated heading, while assistive technology users will get the regular, static semantic headings. Note: The style for the .srOnly class is based on “Inclusively Hidden” by Scott O’Hara. Handling Support As much as accessibility matters, there’s another concern we need to keep in mind: support. CSS Scroll-Driven Animations are fantastic, but they’re still not fully supported everywhere. That’s why it’s important to provide the static version for browsers that don’t support SDA. The first step is to hide the animated heading we just added using display: none. Then, we’ll add a new @supports block to check for SDA support. Inside that block, where SDA is supported, we can change back the display for the heading. The .srOnly class should also move into the @supports block, since we only want it to apply when the effect is active, not when it’s not supported. This way, just like with assistive technology, anyone visiting the page in a browser without SDA support will still get the static content. .scrollDrivenHeading { display: none; } @supports (animation-timeline: scroll()) { .scrollDrivenHeading { display: block; } /* Screen Readers Only */ .srOnly { clip: rect(0 0 0 0); clip-path: inset(50%); height: 1px; overflow: hidden; position: absolute; white-space: nowrap; width: 1px; } } Get Sticky The next thing we need to do is handle the stickiness of the heading. To make sure the heading always stays on screen, we’ll set its position to sticky with top: 0 so it sticks to the top of the viewport. While we’re at it, let’s add some basic styling, including a background so the text doesn’t blend with whatever’s behind the heading, a bit of padding for spacing, and white-space: nowrap to keep the heading on a single line. /* inside the @supports block */ .scrollDrivenHeading { display: block; position: sticky; top: 0; background-image: linear-gradient(0deg, transparent, black 1em); padding: 0.5em 0.25em; white-space: nowrap; } Now everything’s set up: in normal conditions, we’ll see a single sticky heading at the top of the page. And if someone uses assistive technology or a browser that doesn’t support SDA, they’ll still get the regular static content. Now we’re ready to start animating the text. Almost… The Magic Numbers To build the text animation, we need to know exactly where the text should change. With SDA, scrolling basically becomes our timeline, and we have to determine the exact points on that timeline to trigger the animation. To make this easier, and to help you pinpoint those positions, I’ve prepared the following script: @property --scroll-position { syntax: "<number>"; inherits: false; initial-value: 0; } body::after { counter-reset: sp var(--scroll-position); content: counter(sp) "%"; position: fixed; top: 0; left: 0; padding: 1em; background-color: maroon; animation: scrollPosition steps(100); animation-timeline: scroll(); } @keyframes scrollPosition { 0% { --scroll-position: 0; } 100% { --scroll-position: 100; } } I don’t want to get too deep into this code, but the idea is to take the same scroll timeline we’ll use next to animate the text, and use it to animate a custom property (--scroll-position) from 0 to 100 based on the scroll progress, and display that value in the content. If we’ll add this at the start of our code, we’ll see a small red square in the top-left corner of the screen, showing the current scroll position as a percentage (to match the keyframes). This way, you can scroll to any section you want and easily mark the percentage where each heading should begin. With this method and a bit of trial and error, I found that I want the headings to change at 30%, 60%, and 90%. So, how do we actually do it? Let’s start animating. Animating Text First, we’ll clear out the content inside the .scrollDrivenHeading element so it’s empty and ready for dynamic content. In the CSS, I’ll add a pseudo-element to the heading, which we’ll use to animate the text. We’ll give it empty content, set up the animation-name, and of course, assign the animation-timeline to scroll(). And since I’m animating the content property, which is a discrete type, it doesn’t transition smoothly between values. It just jumps from one to the next. By setting the animation-timing-function property to step-end, I make sure each change happens exactly at the keyframe I define, so the text switches precisely where I want it to, instead of somewhere in between. .scrollDrivenHeading { /* style */ &::after { content: ''; animation-name: headingContent; animation-timing-function: step-end; animation-timeline: scroll(); } } As for the keyframes, this part is pretty straightforward (for now). We’ll set the first frame (0%) to the first heading, and assign the other headings to the percentages we found earlier. @keyframes headingContent { 0% { content: 'Primary Colors'} 30% { content: 'Red Power'} 60% { content: 'Blue Calm'} 90%, 100% { content: 'Yellow Joy'} } So, now we’ve got a site with a sticky heading that updates as you scroll. But wait, right now it just switches instantly. Where’s the animation?! Here’s where it gets interesting. Since we’re not using JavaScript or any string manipulation, we have to write the keyframes ourselves. The best approach is to start from the target heading you want to reach, and build backwards. So, if you want to animate between the first and second heading, it would look like this: @keyframes headingContent { 0% { content: 'Primary Colors'} 9% { content: 'Primary Color'} 10% { content: 'Primary Colo'} 11% { content: 'Primary Col'} 12% { content: 'Primary Co'} 13% { content: 'Primary C'} 14% { content: 'Primary '} 15% { content: 'Primary'} 16% { content: 'Primar'} 17% { content: 'Prima'} 18% { content: 'Prim'} 19% { content: 'Pri'} 20% { content: 'Pr'} 21% { content: 'P'} 22% { content: 'R'} 23% { content: 'Re'} 24% { content: 'Red'} 25% { content: 'Red '} 26% { content: 'Red P'} 27% { content: 'Red Po'} 28%{ content: 'Red Pow'} 29% { content: 'Red Powe'} 30% { content: 'Red Power'} 60% { content: 'Blue Calm'} 90%, 100% { content: 'Yellow Joy'} } I simply went back by 1% each time, removing or adding a letter as needed. Note that in other cases, you might want to use a different step size, and not always 1%. For example, on longer headings with more words, you’ll probably want smaller steps. If we repeat this process for all the other headings, we’ll end up with a fully animated heading. User Preferences We talked before about accessibility and making sure the content works well with assistive technology, but there’s one more thing you should keep in mind: prefers-reduced-motion. Even though this isn’t a strict WCAG requirement for this kind of animation, it can make a big difference for people with vestibular sensitivities, so it’s a good idea to offer a way to show the content without animations. If you want to provide a non-animated alternative, all you need to do is wrap your @supports block with a prefers-reduced-motion query: @media screen and (prefers-reduced-motion: no-preference) { @supports (animation-timeline: scroll()) { /* style */ } } Leveling Up Let’s talk about variations. In the previous example, we animated the entire heading text, but we don’t have to do that. You can animate just the part you want, and use additional animations to enhance the effect and make things more interesting. For example, here I kept the text “Primary Color” fixed, and added a span after it that handles the animated text. <h1 class="scrollDrivenHeading" aria-hidden="true"> Primary Color<span></span> </h1> And since I now have a separate span, I can also animate its color to match each value. In the next example, I kept the text animation on the span, but instead of changing the text color, I added another scroll-driven animation on the heading itself to change its background color. This way, you can add as many animations as you want and change whatever you like. Your Turn! CSS Scroll-Driven Animations are more than just a cool trick; they’re a game-changer that opens the door to a whole new world of web design. With just a bit of creativity, you can turn even the most ordinary pages into something interactive, memorable, and truly engaging. The possibilities really are endless, from subtle effects that enhance the user experience, to wild, animated transitions that make your site stand out. So, what would you build with scroll-driven animations? What would you create with this new superpower? Try it out, experiment, and if you come up with something cool, have some ideas, wild experiments, or even weird failures, I’d love to hear about them. I’m always excited to see what others come up with, so feel free to share your work, questions, or feedback below. Special thanks to Cristian Díaz for reviewing the examples, making sure everything is accessible, and contributing valuable advice and improvements. Scroll-Driven Sticky Heading originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Layout. It’s one of those easy-to-learn, difficult-to-master things, like they say about playing bass. Not because it’s innately difficult to, say, place two elements next to each other, but because there are many, many ways to tackle it. And …

The Layout Maestro Course originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Layout. It’s one of those easy-to-learn, difficult-to-master things, like they say about playing bass. Not because it’s innately difficult to, say, place two elements next to each other, but because there are many, many ways to tackle it. And layout is one area of CSS that seems to evolve more than others, as we’ve seen in the past 10-ish years with the Flexbox, CSS Grid, Subgrid, and now Masonry to name but a few. May as well toss in Container Queries while we’re at it. And reading flow. And… That’s a good way to start talking about a new online course that Ahmad Shadeed is planning to release called The Layout Maestro. I love that name, by the way. It captures exactly how I think about working with layouts: orchestrating how and where things are arranged on a page. Layouts are rarely static these days. They are expected to adapt to the user’s context, not totally unlike a song changing keys. Ahmad is the perfect maestro to lead a course on layout, as he does more than most when it comes to experimenting with layout features and demonstrating practical use cases, as you may have already seen in his thorough and wildly popular interactive guides on Container Queries, grid areas, box alignment, and positioning (just to name a few). The course is still in development, but you can get a leg up and sign up to be notified by email when it’s ready. That’s literally all of the information I have at this point, but I still feel compelled to share it and encourage you to sign up for updates because I know few people more qualified to wax on about CSS layout than Ahmad and am nothing but confident that it will be great, worth the time, and worth the investment. I’m also learning that I have a really hard time typing “maestro” correctly. 🤓 The Layout Maestro Course originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

The shape() function's close and move commands may not be ones you reach for often, but are incredibly useful for certain shapes.

Better CSS Shapes Using shape() — Part 4: Close and Move originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

This is the fourth post in a series about the new CSS shape() function. So far, we’ve covered the most common commands you will use to draw various shapes, including lines, arcs, and curves. This time, I want to introduce you to two more commands: close and move. They’re fairly simple in practice, and I think you will rarely use them, but they are incredibly useful when you need them. Better CSS Shapes Using shape() Lines and Arcs More on Arcs Curves Close and Move (you are here!) The close command In the first part, we said that shape() always starts with a from command to define the first starting point but what about the end? It should end with a close command. But you never used any close command in the previous articles!? That’s true. I never did because I either “close” the shape myself or rely on the browser to “close” it for me. Said like that, it’s a bit confusing, but let’s take a simple example to better understand: clip-path: shape(from 0 0, line to 100% 0, line to 100% 100%) If you try this code, you will get a triangle shape, but if you look closely, you will notice that we have only two line commands whereas, to draw a triangle, we need a total of three lines. The last line between 100% 100% and 0 0 is implicit, and that’s the part where the browser is closing the shape for me without having to explicitly use a close command. I could have written the following: clip-path: shape(from 0 0, line to 100% 0, line to 100% 100%, close) Or instead, define the last line by myself: clip-path: shape(from 0 0, line to 100% 0, line to 100% 100%, line to 0 0) But since the browser is able to close the shape alone, there is no need to add that last line command nor do we need to explicitly add the close command. This might lead you to think that the close command is useless, right? It’s true in most cases (after all, I have written three articles about shape() without using it), but it’s important to know about it and what it does. In some particular cases, it can be useful, especially if used in the middle of a shape. In this example, my starting point is the center and the logic of the shape is to draw four triangles. In the process, I need to get back to the center each time. So, instead of writing line to center, I simply write close and the browser will automatically get back to the initial point! Intuitively, we should write the following: clip-path: shape( from center, line to 20% 0, hline by 60%, line to center, /* triangle 1 */ line to 100% 20%, vline by 60%, line to center, /* triangle 2 */ line to 20% 100%, hline by 60%, line to center, /* triangle 3 */ line to 0 20%, vline by 60% /* triangle 4 */ ) But we can optimize it a little and simply do this instead: clip-path: shape( from center, line to 20% 0, hline by 60%, close, line to 100% 20%, vline by 60%, close, line to 20% 100%, hline by 60%, close, line to 0 20%, vline by 60% ) We write less code, sure, but another important thing is that if I update the center value with another position, the close command will follow that position. Don’t forget about this trick. It can help you optimize a lot of shapes by writing less code. The move command Let’s turn our attention to another shape() command you may rarely use, but can be incredibly useful in certain situations: the move command. Most times when we need to draw a shape, it’s actually one continuous shape. But it may happen that our shape is composed of different parts not linked together. In these situations, the move command is what you will need. Let’s take an example, similar to the previous one, but this time the triangles don’t touch each other: Intuitively, we may think we need four separate elements, with its own shape() definition. But the that example is a single shape! The trick is to draw the first triangle, then “move” somewhere else to draw the next one, and so on. The move command is similar to the from command but we use it in the middle of shape(). clip-path: shape( from 50% 40%, line to 20% 0, hline by 60%, close, /* triangle 1 */ move to 60% 50%, line to 100% 20%, vline by 60%, close, /* triangle 2 */ move to 50% 60%, line to 20% 100%, hline by 60%, close, /* triangle 3 */ move to 40% 50%, line to 0 20%, vline by 60% /* triangle 4 */ ) After drawing the first triangle, we “close” it and “move” to a new point to draw the next triangle. We can have multiple shapes using a single shape() definition. A more generic code will look like the below: clip-path: shape( from X1 Y1, ..., close, /* shape 1 */ move to X2 Y2, ..., close, /* shape 2 */ ... move to Xn Yn, ... /* shape N */ ) The close commands before the move commands aren’t mandatory, so the code can be simplified to this: clip-path: shape( from X1 Y1, ..., /* shape 1 */ move to X2 Y2, ..., /* shape 2 */ ... move to Xn Yn, ... /* shape N */ ) Let’s look at a few interesting use cases where this technique can be helpful. Cut-out shapes Previously, I shared a trick on how to create cut-out shapes using clip-path: polygon(). Starting from any kind of polygon, we can easily invert it to get its cut-out version: We can do the same using shape(). The idea is to have an intersection between the main shape and the rectangle shape that fits the element boundaries. We need two shapes, hence the need for the move command. The code is as follows: .shape { clip-path: shape(from ...., move to 0 0, hline to 100%, vline to 100%, hline to 0); } You start by creating your main shape and then you “move” to 0 0 and you create the rectangle shape (Remember, It’s the first shape we create in the first part of this series). We can even go further and introduce a CSS variable to easily switch between the normal shape and the inverted one. .shape { clip-path: shape(from .... var(--i,)); } .invert { --i:,move to 0 0, hline to 100%, vline to 100%, hline to 0; } By default, --i is not defined so var(--i,)will be empty and we get the main shape. If we define the variable with the rectangle shape, we get the inverted version. Here is an example using a rounded hexagon shape: In reality, the code should be as follows: .shape { clip-path: shape(evenodd from .... var(--i,)); } .invert { --i:,move to 0 0, hline to 100%, vline to 100%, hline to 0; } Notice the evenodd I am adding at the beginning of shape(). I won’t bother you with a detailed explanation on what it does but in some cases, the inverted shape is not visible and the fix is to add evenodd at the beginning. You can check the MDN page for more details. Another improvement we can do is to add a variable to control the space around the shape. Let’s suppose you want to make the hexagon shape of the previous example smaller. It‘s tedious to update the code of the hexagon but it’s easier to update the code of the rectangle shape. .shape { clip-path: shape(evenodd from ... var(--i,)) content-box; } .invert { --d: 20px; padding: var(--d); --i: ,move to calc(-1*var(--d)) calc(-1*var(--d)), hline to calc(100% + var(--d)), vline to calc(100% + var(--d)), hline to calc(-1*var(--d)); } We first update the reference box of the shape to be content-box. Then we add some padding which will logically reduce the area of the shape since it will no longer include the padding (nor the border). The padding is excluded (invisible) by default and here comes the trick where we update the rectangle shape to re-include the padding. That is why the --i variable is so verbose. It uses the value of the padding to extend the rectangle area and cover the whole element as if we didn’t have content-box. Not only you can easily invert any kind of shape, but you can also control the space around it! Here is another demo using the CSS-Tricks logo to illustrate how easy the method is: This exact same example is available in my SVG-to-CSS converter, providing you with the shape() code without having to do all of the math. Repetitive shapes Another interesting use case of the move command is when we need to repeat the same shape multiple times. Do you remember the difference between the by and the to directives? The by directive allows us to define relative coordinates considering the previous point. So, if we create our shape using only by, we can easily reuse the same code as many times as we want. Let’s start with a simple example of a circle shape: clip-path: shape(from X Y, arc by 0 -50px of 1%, arc by 0 50px of 1%) Starting from X Y, I draw a first arc moving upward by 50px, then I get back to X Y with another arc using the same offset, but downward. If you are a bit lost with the syntax, try reviewing Part 1 to refresh your memory about the arc command. How I drew the shape is not important. What is important is that whatever the value of X Y is, I will always get the same circle but in a different position. Do you see where I am going with this idea? If I want to add another circle, I simply repeat the same code with a different X Y. clip-path: shape( from X1 Y1, arc by 0 -50px of 1%, arc by 0 50px of 1%, move to X2 Y2, arc by 0 -50px of 1%, arc by 0 50px of 1% ) And since the code is the same, I can store the circle shape into a CSS variable and draw as many circles as I want: .shape { --sh:, arc by 0 -50px of 1%, arc by 0 50px of 1%; clip-path: shape( from X1 Y1 var(--sh), move to X2 Y2 var(--sh), ... move to Xn Yn var(--sh) ) } You don’t want a circle? Easy, you can update the --sh variable with any shape you want. Here is an example with three different shapes: And guess what? You can invert the whole thing using the cut-out technique by adding the rectangle shape at the end: This code is a perfect example of the shape() function’s power. We don’t have any code duplication and we can simply adjust the shape with CSS variables. This is something we are unable to achieve with the path() function because it doesn’t support variables. Conclusion That’s all for this fourth installment of our series on the CSS shape() function! We didn’t make any super complex shapes, but we learned how two simple commands can open a lot of possibilities of what can be done using shape(). Just for fun, here is one more demo recreating a classic three-dot loader using the last technique we covered. Notice how much further we could go, adding things like animation to the mix: Better CSS Shapes Using shape() Lines and Arcs More on Arcs Curves Close and Move (you are here!) Better CSS Shapes Using shape() — Part 4: Close and Move originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Sign up for new Apple developer workshops all over the world. Plus, download Apple UI design kits for Figma and Sketch, meet the Italy-based team behind Sunlitt, and more.

Read more

The App Store is designed to be a safe and trusted place for all ages, including children. The age rating system for apps and games has been updated in order to provide people with more granular age ratings. We’ve also introduced new age rating questions to help identify sensitive content in your app and added the ability to set a higher rating to reflect your app’s minimum age requirement. Ratings for all apps and games on the App Store have been automatically updated to align with this new system and will be reflected on Apple devices running beta versions of iOS 26, iPadOS 26, macOS Tahoe 26, tvOS 26, visionOS 26, and watchOS 26.

The updated age rating system adds 13+, 16+, and 18+ to the existing 4+ and 9+ ratings. Age ratings are assigned to each country or region and may vary based on region-specific suitability standards.

We’ve introduced a new set of required questions to the ratings questionnaire for all apps. These new questions cover:

• In-app controls.
• Capabilities.
• Medical or wellness topics.
• Violent themes in your app or game.

Your answers to these questions will help Apple better calculate a rating and help you deliver an age-appropriate experience.

If your app has a policy requiring a higher minimum user age than the rating assigned by Apple, you can set a higher age rating after you respond to the age ratings questions. You can view the age rating for each of your apps under the updated system and respond to the new questions for each app in the App Information section in App Store Connect.

As a reminder, you must consider how all app features, including AI assistants and chatbot functionality, impact the frequency of sensitive content appearing within your app to make sure it receives the appropriate rating. All apps are subject to the App Review Guidelines, such as the safety guidelines regarding objectionable content or user generated content, and must abide by all applicable local laws and regulations, like the Children’s Online Privacy Protection Act (“COPPA”), and the European Union’s General Data Protection Regulation (“GDPR”).

Please provide responses to the updated age rating questions for each of your apps by January 31, 2026, to avoid an interruption when submitting your app updates in App Store Connect.

Learn more about age ratings values and definitions

Learn how to set your app rating

Beginning April 2026, watchOS apps uploaded to App Store Connect must also include 64-bit support and be built with the watchOS 26 SDK. To enable 64-bit support in your project, we recommend using the default Xcode build setting of “Standard architectures” to build a single binary with 64-bit code.

You can test ARM64 compatibility for your apps in the Xcode Simulator, and on Apple Watch Series 9 or 10, Apple Watch SE (2nd generation) or Apple Watch Ultra 2 running watchOS 11 or watchOS 26 beta.

Learn more about the SDKs included in Xcode

Apple Ul design kits for Figma and Sketch are now available for iOS and iPadOS 26.

Apple Design Resources

The European Commission has required Apple to make a series of additional changes under the Digital Markets Act:

Communication and promotion of offers

• Today, we’re introducing updated terms that let developers with apps in the European Union storefronts of the App Store communicate and promote offers for purchase of digital goods or services available at a destination of their choice. The destination can be a website, alternative app marketplace, or another app, and can be accessed outside the app or within the app via a web view or native experience.
• App Store apps that communicate and promote offers for digital goods or services will be subject to new business terms for those transactions — an initial acquisition fee, store services fee, and for apps on the StoreKit External Purchase Link Entitlement (EU) Addendum, the Core Technology Commission (CTC). The CTC reflects value Apple provides developers through ongoing investments in the tools, technologies, and services that enable them to build and share innovative apps with users.
• Music streaming apps on the App Store in the European Economic Area (EEA) wanting to use the Music Streaming Services Entitlement (EEA) can use these options.

Update to Business Terms for Apps in the European Union

• By January 1, 2026, Apple plans to move to a single business model in the EU for all developers. Under this single business model, Apple will transition from the Core Technology Fee (CTF) to the CTC on digital goods or services. The CTC will apply to digital goods or services sold by apps distributed from the App Store, Web Distribution, and/or alternative marketplaces.
• Apps currently under the Alternative Terms Addendum for Apps in the EU continue to be subject only to the CTF until the transition to the CTC is fully implemented next year. At that time, qualifying transactions will be subject to the CTC, and the CTF will no longer apply. Additional details regarding this transition will be provided at a later date.

User Experience Update

• Beginning with iOS 18.6 and iPadOS 18.6, iOS and iPadOS will provide an updated user experience in the EU for installing alternative marketplaces or apps from a developer’s website. Additionally, later this year, we will provide an API which will allow developers to initiate the download of alternatively distributed apps they publish from within their app.

To learn more, view Communication and promotion of offers on the App Store in the EU. To read the full terms, view the Alternative Terms Addendum for Apps in the EU or the StoreKit External Purchase Link Entitlement Addendum for EU Apps. You can also request a 30-minute online appointment to ask questions and provide feedback about these changes.

The European Commission has required Apple to make a series of additional changes under the Digital Markets Act:

Communication and promotion of offers

• Today, we’re introducing updated terms that let developers with apps in the European Union storefronts of the App Store communicate and promote offers for purchase of digital goods or services available at a destination of their choice. The destination can be a website, alternative app marketplace, or another app, and can be accessed outside the app or within the app via a web view or native experience.
• App Store apps that communicate and promote offers for digital goods or services will be subject to new business terms for those transactions — an initial acquisition fee, store services fee, and for apps on the StoreKit External Purchase Link Entitlement (EU) Addendum, the Core Technology Commission (CTC). The CTC reflects value Apple provides developers through ongoing investments in the tools, technologies, and services that enable them to build and share innovative apps with users.
• Music streaming apps on the App Store in the European Economic Area (EEA) wanting to use the Music Streaming Services Entitlement (EEA) can use these options.

Update to Business Terms for Apps in the European Union

• By January 1, 2026, Apple plans to move to a single business model in the EU for all developers. Under this single business model, Apple will transition from the Core Technology Fee (CTF) to the CTC on digital goods or services. The CTC will apply to digital goods or services sold by apps distributed from the App Store, Web Distribution, and/or alternative marketplaces.
• Apps currently under the Alternative Terms Addendum for Apps in the EU continue to be subject only to the CTF until the transition to the CTC is fully implemented next year. At that time, qualifying transactions will be subject to the CTC, and the CTF will no longer apply. Additional details regarding this transition will be provided at a later date.

User Experience Update

• Beginning with iOS 18.6 and iPadOS 18.6, iOS and iPadOS will provide an updated user experience in the EU for installing alternative marketplaces or apps from a developer’s website. Additionally, later this year, we will provide an API which will allow developers to initiate the download of alternatively distributed apps they publish from within their app.

To learn more, view Communication and promotion of offers on the App Store in the EU. To read the full terms, view the Alternative Terms Addendum for Apps in the EU or the StoreKit External Purchase Link Entitlement Addendum for EU Apps. You can also request a 30-minute online appointment to ask questions and provide feedback about these changes.

The European Commission has required Apple to make a series of additional changes under the Digital Markets Act:

Communication and promotion of offers

• Today, we’re introducing updated terms that let developers with apps in the European Union storefronts of the App Store communicate and promote offers for purchase of digital goods or services available at a destination of their choice. The destination can be a website, alternative app marketplace, or another app, and can be accessed outside the app or within the app via a web view or native experience.
• App Store apps that communicate and promote offers for digital goods or services will be subject to new business terms for those transactions — an initial acquisition fee, store services fee, and for apps on the StoreKit External Purchase Link Entitlement (EU) Addendum, the Core Technology Commission (CTC). The CTC reflects value Apple provides developers through ongoing investments in the tools, technologies, and services that enable them to build and share innovative apps with users.
• Music streaming apps on the App Store in the European Economic Area (EEA) wanting to use the Music Streaming Services Entitlement (EEA) can use these options.

Update to Business Terms for Apps in the European Union

• By January 1, 2026, Apple plans to move to a single business model in the EU for all developers. Under this single business model, Apple will transition from the Core Technology Fee (CTF) to the CTC on digital goods or services. The CTC will apply to digital goods or services sold by apps distributed from the App Store, Web Distribution, and/or alternative marketplaces.
• Apps currently under the Alternative Terms Addendum for Apps in the EU continue to be subject only to the CTF until the transition to the CTC is fully implemented next year. At that time, qualifying transactions will be subject to the CTC, and the CTF will no longer apply. Additional details regarding this transition will be provided at a later date.

User Experience Update

• Beginning with iOS 18.6 and iPadOS 18.6, iOS and iPadOS will provide an updated user experience in the EU for installing alternative marketplaces or apps from a developer’s website. Additionally, later this year, we will provide an API which will allow developers to initiate the download of alternatively distributed apps they publish from within their app.

To learn more, view Communication and promotion of offers on the App Store in the EU. To read the full terms, view the Alternative Terms Addendum for Apps in the EU or the StoreKit External Purchase Link Entitlement Addendum for EU Apps. You can also request a 30-minute online appointment to ask questions and provide feedback about these changes.

The European Commission has required Apple to make a series of additional changes under the Digital Markets Act:

Communication and promotion of offers

• Today, we’re introducing updated terms that let developers with apps in the European Union storefronts of the App Store communicate and promote offers for purchase of digital goods or services available at a destination of their choice. The destination can be a website, alternative app marketplace, or another app, and can be accessed outside the app or within the app via a web view or native experience.
• App Store apps that communicate and promote offers for digital goods or services will be subject to new business terms for those transactions — an initial acquisition fee, store services fee, and for apps on the StoreKit External Purchase Link Entitlement (EU) Addendum, the Core Technology Commission (CTC). The CTC reflects value Apple provides developers through ongoing investments in the tools, technologies, and services that enable them to build and share innovative apps with users.
• Music streaming apps on the App Store in the European Economic Area (EEA) wanting to use the Music Streaming Services Entitlement (EEA) can use these options.

Update to Business Terms for Apps in the European Union

• By January 1, 2026, Apple plans to move to a single business model in the EU for all developers. Under this single business model, Apple will transition from the Core Technology Fee (CTF) to the CTC on digital goods or services. The CTC will apply to digital goods or services sold by apps distributed from the App Store, Web Distribution, and/or alternative marketplaces.
• Apps currently under the Alternative Terms Addendum for Apps in the EU continue to be subject only to the CTF until the transition to the CTC is fully implemented next year. At that time, qualifying transactions will be subject to the CTC, and the CTF will no longer apply. Additional details regarding this transition will be provided at a later date.

User Experience Update

• Beginning with iOS 18.6 and iPadOS 18.6, iOS and iPadOS will provide an updated user experience in the EU for installing alternative marketplaces or apps from a developer’s website. Additionally, later this year, we will provide an API which will allow developers to initiate the download of alternatively distributed apps they publish from within their app.

To learn more, view Communication and promotion of offers on the App Store in the EU. To read the full terms, view the Alternative Terms Addendum for Apps in the EU or the StoreKit External Purchase Link Entitlement Addendum for EU Apps. You can also request a 30-minute online appointment to ask questions and provide feedback about these changes.

Welcome to Day 2 at WWDC25! Watch the Platforms State of the Union recap, then dive into all the updates to Swift, SwiftUI, and Xcode through group labs and video sessions.

WWDC25 Platforms State of the Union Recap Watch now

Explore Day 2 >

Today’s group labs

Developer Tools group lab View now Swift group lab View now Metal & game technologies group lab View now Camera & Photos frameworks group lab View now

Discover the latest advancements on all Apple platforms. With incredible new features in iOS, iPadOS, macOS, tvOS, visionOS, and watchOS, and major enhancements across languages, frameworks, tools, and services, you can create even more unique experiences in your apps and games.

Explore what’s new

The Apple Developer Program License Agreement and App Review Guidelines have been revised to support new features and updated policies, and to provide clarification. Please review the changes below.

Apple Developer Program License Agreement

• Section 3.3.3(D): Updated language on requirements for data and privacy.
• Section 3.3.3(N): Updated requirements for use of the ID Verifier APIs.
• Definitions, 3.3.3(P): Specified requirements for use of the Declared Age Range API.
• Definitions, 3.3.7(G): Specified requirements for use of the Wi-Fi Aware framework.
• Definitions, 3.3.7(H): Specified requirements for use of the TelephonyMessagingKit APIs.
• Definitions, 3.3.7(I): Specified requirements for use of the Default Dialer APIs.
• Definition, Section 3.3.8(H), Attachment 11: Specified requirements for use of EnergyKit.
• Definitions, 3.3.8(I): Specified requirements for use of the Foundation Models framework.
• Definitions, Attachment 4: Specified requirements for use of the iCloud Extended Share APIs.
• Section 6.4: Removed language on Bitcode submissions as it is no longer applicable, and replaced it with terms regarding iOS app widgets on CarPlay.
• Section 7.4(B): Updated and clarified requirements for TestFlight related to digital purchases and tester invitations.
• Section 7.7: Updated language on customization of icons and widgets.
• Section 7.8: Specified terms related to the Apple Games app.
• Attachment 6: Updated terms regarding the entity that distributes the map in China.

App Review Guidelines

• 3.1.2(a), bullet 2: This language has been deleted (“You may offer a single subscription that is shared across your own apps and services”).
• 3.1.2(a), bullet 5: This language has been relocated to Guideline 3.2.2(x).
• 3.2.1(viii): Clarified that financial apps must have necessary licensing and permissions in the locations where developers make them available.
• 3.2.2(x): This new guideline contains the language relocated from Guideline 3.1.2(a), bullet 5, and permits developers to otherwise incentivize users to take specific actions within app.

Please sign in to your account to accept the updated Apple Developer Program License Agreement.

Translations of the guidelines will be available on Apple Developer website within one month.

WWDC25 is here! Watch a quick welcome video to help you get started, then dive into sessions and sign up for tomorrow’s group labs.

Welcome to WWDC25 Watch now

Explore Day 1 >

Tuesday’s group labs

Developer Tools group lab View now Swift group lab View now Metal & game technologies group lab View now Camera & Photos frameworks group lab View now

An artistic puzzler with a wildlife twist. A translation app powered by machine learning and stickers. And a card game that’s been on quite a run. Say hello to the wildly inventive crop of 2025 Apple Design Award honorees.

View this year's winners and finalists >

WWDC25 is just days away! Here’s everything you need to get ready — and a big announcement to start things off. Say hello to the wildly inventive crop of 2025 Apple Design Award winners and finalists.

Read the full article

WWDC25 is almost here! Find out how to tune in to the Keynote and Platforms State of the Union on Monday, June 9.

Learn more

The App Store is designed to make it easy to sell your digital goods and services globally, with support for 44 currencies across 175 storefronts.

From time to time, we may need to adjust prices or your proceeds due to changes in tax regulations or foreign exchange rates. These adjustments are made using publicly available exchange rate information from financial data providers to help make sure prices for apps and In-App Purchases stay consistent across all storefronts.

Tax and price updates

As of May 16:

Your proceeds from the sale of eligible apps and In‑App Purchases have been modified in Brazil to account for the Contribuições de Intervenção no Domínio Econômico (CIDE) tax introduction of 10% for developers based outside of Brazil.

Beginning June 2:

Pricing for apps and In-App Purchases will be updated for Brazil and Kazakhstan if you haven’t selected one of these storefronts as the base storefront for your app or In‑App Purchase.¹ The updates in Brazil also consider the 10% CIDE tax introduction.

If you’ve selected Brazil or Kazakhstan as the base storefront for your app or In-App Purchase, prices won’t change. On other storefronts, prices will be updated to maintain equalization with your chosen base price.

Prices won’t change in any region if your In‑App Purchase is an auto‑renewable subscription. Prices also won’t change on the storefronts where you manually manage prices instead of using the automated equalized prices.

The Pricing and Availability section of Apps has been updated in App Store Connect to display these upcoming price changes. As always, you can change the prices of your apps, In‑App Purchases, and auto‑renewable subscriptions at any time.

Additional upcoming changes

Beginning August 4:

All auto-renewable subscription price increases in Austria, Germany, and Poland will require customers to consent to the new price for their subscription to continue renewing.

• Price increases scheduled with a start date on or after August 4: All customers must consent to the new price. If a subscriber doesn’t agree to the new price or takes no action, Apple will continue to request consent approximately weekly through email, push notifications, and in-app messaging until their subscription expires at the end of their current billing cycle.

• Price increases scheduled with a start date before August 4: Current notice criteria will remain in effect, even if the renewal occurs after August 4 (for annual subscriptions, renewal could be as late as August 2026). See criteria, noting that consent may apply to customers depending on the size or velocity of your price increases.

To help ensure a smooth transition, we recommend avoiding scheduling price increases with a start date between August 2 and August 4.

Learn more about managing your prices

View or edit upcoming price changes

Edit your app’s base country or region

Pricing and availability start times by country or region

Set a price for an In-App Purchase

Learn more about your proceeds

View payments and proceeds

Download financial reports

¹ Excludes auto-renewable subscriptions.

In this edition: Join us to learn how to make your apps more accessible to everyone. Plus, check out our new and refreshed Pathways, and uncover the time-traveling secrets of the Apple Design Award-winning game The Wreck.

Read the full article

The Wreck is filed under games, but it’s also been called a visual novel, an interactive experience, and a playable movie. Florent Maurin is OK with all of it. “I like to think we’re humbly participating in expanding the idea of what a video game can be,” he says.

Maurin is the co-writer, designer, and producer of The Wreck — and here we’ll let you decide what to call it. The Wreck tells the tale of Junon, a writer who’s abruptly called to a hospital to make a life-changing decision involving her mother. The story is anchored by the accident that lends the game its name, but the ensuing narrative is splintered, and begins to take shape only as players navigate through seemingly disconnected scenes that can be viewed multiple times from different perspectives. The Wreck is far from light. But its powerful story and unorthodox mechanics combine for a unique experience.

“We tried to make a game that’s a bit off the beaten path,” says Maurin, who’s also the president and CEO of The Pixel Hunt studio, “and hopefully it connects with people.”

ADA FACT SHEET

The Wreck

• Winner: Social impact
• Team: The Pixel Hunt
• Available on: iPhone, iPad
• Team size: 4

Maurin is a former children’s journalist who worked at magazines and newspapers in his native France. After nearly 10 years in the field, he pivoted to video games, seeing them as a different way to share real stories about real people. “Reality is a source of inspiration in movies, novels, and comic books, but it’s almost completely absent in the gaming landscape,” he says. “We wanted to challenge that.”

Founded in 2014, The Pixel Hunt has released acclaimed titles like the App Store Award–winning historical adventure Inua and the text-message adventure Bury Me, My Love. It was near the end of the development process for the latter that Maurin and his daughter were involved in a serious car accident.

“It was honestly like a movie trope,” he says. “Time slowed down. Weird memories that had nothing to do with the moment flashed before my eyes. Later I read that the brain parses through old memories to find relevant knowledge for facing that kind of situation. It was so sudden and so intense, and I knew I wanted to make something of it. And what immediately came to mind was a game.”

Junon's interactions with the hospital staff drive the narrative in The Wreck.

But Maurin was too close to the source material; the accident had left a lasting impact, and he separated himself from the creative process. “I think I was trying to protect myself from the intensity of that feeling,” he says. “That’s when Alex, our art director, told me, ‘Look, this is your idea, and I don’t think it’ll bloom if you don’t really dig deep and own the creative direction.’ And he was right.”

That was art director Alexandre Grilletta, who helmed the development team alongside lead developer Horace Ribout, animator Peggy Lecouvey, sound designers Luis and Rafael Torres, and Maurin’s sister, Coralie, who served as a “second brain” during writing. (In a nice bit of serendipity, the game’s script was written in an open-source scripting language developed by Inkle, which used it for their own Apple Design Award-winning game, Overboard, in 2022.)

Junon's sister might not be an entirely welcome presence in The Wreck.

The story of The Wreck is split into two parts. The first — what the team calls the “last day” — follows Junon at the hospital while she faces her mother’s situation as well as revealing interactions with her sister and ex-husband. Maurin says the “last day” was pretty straightforward from a design standpoint. “We knew we wanted a cinematic look,” he says, “so we made it look like a storyboard with some stop-motion animation and framing. It was really nothing too fancy. The part that was way more challenging was the memories.”

Those “memories” — and the backstory they tell — employ a clever mechanism in which players view a scene as a movie and have the ability to fast-forward or rewind the scene. These memory scenes feel much different; they’re dreamlike and inventive, with swooping camera angles, shifting perspectives, and words that float in the air. “I saw that first in What Remains of Edith Finch,” says Maurin. “I thought it was an elegant way of suggesting the thing that triggers a character’s brain in that moment.”

Junon's thoughts are often conveyed in floating phrases that surround her in stressful moments.

Successive viewings of these memories can reveal new details or cast doubt on their legitimacy — something Maurin wrote from experience. “I’ll give you an example,” he says. “When my parents brought my baby sister home from the hospital, I remember the exact moment they arrived in the car. It’s incredibly vivid. But the weird part is: This memory is in the third person. I see myself tiptoeing to the window to watch them in the street — which is impossible! I rewrote my own memory for some reason, and only my brain knows why it works like that. But it feels so real.”

Throughout the development process, Maurin and team held close to the idea of a “moving and mature” story. In fact, early prototypes of The Wreck were more gamified — in one version, players grabbed floating items — but playtesters found the activity distracting. “It took them out of the story,” Maurin says. “It broke the immersion. And that was counterproductive to our goal.”

Items in The Wreck — like this tin of peppermints — often carry a larger meaning.

Maurin admits that approaching games with this mindset can be a challenge. “Some players are curious about our games and absolutely love them. Some people think, ‘These don’t fit the perception of what I think I enjoy.’ And maybe the games are for them, and maybe they’re not. But this is what we’ve been doing for 11 years. And I think we're getting better at it.”

Meet the 2024 Apple Design Award winners

Behind the Design is a series that explores design practices and philosophies from finalists and winners of the Apple Design Awards. In each story, we go behind the screens with the developers and designers of these award-winning apps and games to discover how they brought their remarkable creations to life.

The App Review Guidelines have been updated for compliance with a United States court decision regarding buttons, external links, and other calls to action in apps. These changes affect apps distributed on the United States storefront of the App Store, and are reflected in updates to Guidelines 3.1.1, 3.1.1(a), 3.1.3, and 3.1.3(a).

View the App Review Guidelines

Translations of the guidelines will be available on Apple Developer website within one month.

In this edition: Revisit foundational sessions, join us to dive into SwiftUI, and meet an Apple Design Award winner that defies description.

Read the full article

Ask Jason Toff whether his Apple Design Award winner is a game or an app, and his answer is yes.

“There’s no one-sentence description for Rooms, and that can be a blessing,” laughs Toff, CEO and head designer of Things, Inc. “It’s not entirely a game, and it’s not entirely a tool. It’s more like a toy.”

It’s also a blank canvas, cozy game, coding teacher, and social network — but we’re getting ahead of ourselves. At its heart, Rooms is a collection of user-generated 3-D spaces that feels like the open-ended world of the early internet. Start with an empty room or existing template, then fill it with an array of voxel decorations, items, pets, and avatars to create whatever space you like: a college apartment, medieval castle chamber, floating fantasy realm, pirate ship, or a Weezer concert (really), to name just a few. The only limits are the room’s boundaries — and Rooms fans have even gotten around those. “Our 404 page is a room with no walls,” Toff says, “so people just started copying it to work around the constraint.”

ADA FACT SHEET

Rooms

• Winner: Visuals and Graphics
• Team: Things, Inc.
• Available on: iOS, iPadOS
• Team size: 4

Learn more about Rooms

Download Rooms from the App Store

In fact, that community element is a strong point: This creative tapestry of quirky games, tranquil havens, and clever ideas has been conjured by real people, which makes Rooms a social network as well. What’s more, users can click on each item to reveal its underlying code, offering them more options for customization.

To create Rooms — which, incidentally, won the ADA for Visuals and Graphics in games — Toff and cofounders Nick Kruge and Bruno Oliveira threw themselves back into their childhoods. “I was obsessed with Legos as a kid,” says Toff, not unexpectedly. “I found myself wondering, ‘What’s the digital equivalent of that?’”

Rooms isn’t just about rooms; creators have plenty of ways to noodle on their ideas.

Drawing on that inspiration — as well as Toff’s experiences with Kid Pix on his dad’s 1989-era Mac — the Rooms team began envisioning something that, as Oliveira says, kept the floor low but the ceiling high. “We wanted anyone from 4-year-olds to their grandparents to be able to use Rooms,” he says, “and that meant making something free-form and creative.”

It also meant building something that gave a sense of approachability and creativity, which led them right to voxels. “Blocks have a charm, but they can also be kind of ugly,” Toff laughs. “Luckily, Bruno’s were cute and soft, so they felt approachable and familiar.” And from Oliveira’s side, blocks offered a practical value. “It’s much easier to do 3-D modeling with blocks,” says Oliveira. “You can just add or remove voxels whenever you want, which lowers the bar for everyone.”

We wanted anyone from 4-year-olds to their grandparents to be able to use Rooms, and that meant making something free-form and creative.

Jason Toff, CEO and head designer of Things, Inc.

Rooms launched in 2023 as a web-based app that included 1,000 voxel objects and allowed users to write their own code. It gained traction through both word of mouth and, more directly, a video that went viral in the cozy-gaming community. “All of a sudden, we had all these people coming,” says Oliveira, “and we realized we needed to prioritize the mobile app. Nick was like, ‘I think we can get feature parity with desktop on the iPhone screen,’ and we basically pulled a rabbit out of a hat.” Today, the vast majority of Rooms users are on mobile, where they spend the bulk of their time editing. “We were just shocked by how much time people were spending making rooms,” he says. “These weren’t quick five-minute projects. We did not anticipate that.”

Of course the Things, Inc. team rebuilt their own offices in Rooms.

All that building fed into a social aspect as well. Toff says most of the items in Rooms are now created, edited, and amplified by lots of different users. “Here’s a good example: We have a sway effect that makes things wave back and forth a little,” he says. “Someone realized that if they put some branches on a tree and added that effect, the tree immediately looked alive. Now everyone’s doing that. There’s a real additive effect to building in Rooms.” Today, the Rooms library contains more than 10,000 items.

There’s a lot of power under the hood, too. “Rooms uses a Lua scripting language that runs in a C++ context,” says Oliveira, “so it’s kind of Lua, encased in C++, encased in Unity, encased in iOS.” Every room, he says, is a new Unity instance. And adding native iOS elements — like sliders on the Explore page and a bottom navigation — gives what he calls the “design chef’s kiss.”

An early sketch of Rooms shows how the room design came together early in the process.

Like its community, the Rooms team is used to moving fast. “One day I said, ‘It would be cool if this had a D-pad and A/B buttons,” says Toff, “and about 10 hours later Bruno was like, ‘Here you go.’” On another lark, Toff mentioned that it would be fun to let users fly around their rooms, and Kruge and Oliveira promptly created a “camera mode” that’s come to be known internally as the “Jason-Cam.”

That’s satisfying to a team that simply set out to build a cutting-edge plaything. “We always had this metaphor that Rooms was a swimming pool with a shallow side and a deep side,” says Oliveira. “It should be fun for people dabbling in the shallow side. But it should also be amazing for people swimming in the deep end. If you just want to look at rooms, you can. But you can also dive all the way down and write complicated code. There’s something for everyone.”

Meet the 2024 Apple Design Award winners

Behind the Design is a series that explores design practices and philosophies from finalists and winners of the Apple Design Awards. In each story, we go behind the screens with the developers and designers of these award-winning apps and games to discover how they brought their remarkable creations to life.

Join the worldwide developer community online for a week of technology and creativity.

Be there for the reveal of the latest Apple tools, frameworks, and features. Learn to elevate your apps and games through video sessions hosted by Apple engineers and designers. Engage with Apple experts in labs and connect with the worldwide developer community. All online and at no cost.

Learn more about WWDC25

It’s an ice-cold late winter’s morning in Canada, but the offices of Ubisoft Quebec are ablaze with excitement.

The Ubisoft team is preparing the release of Assassin’s Creed Shadows, the 14th main entry in the series and an evolution for the franchise in nearly every detail. It’s set in feudal 16th-century Japan, a rich and elegant period that’s been long sought-after by fans and Ubisoft team members alike. It introduces a pair of fierce protagonists: Yasuke, a powerful warrior of African origin, and Naoe, an agile Shinobi assassin, both brought to life with attention to historical accuracy. Its world feels alive with an ever-changing dynamism that’s apparent in everything from the shifting weather to the rotating seasons to the magical interplay of light and shadow.

And what’s more, it’s set to release on Mac the same day it arrives on PCs and consoles.

“It’s been a longtime dream to bring the game to Mac,” says Ubisoft executive producer Marc-Alexis Côté, who debuted the game on Mac during the WWDC24 Keynote. “It’s incredible that I can now open a MacBook Pro and get this level of immersion.” Shadows will also be coming later to iPad with M-series chips.

Naoe, one of the game’s two protagonists, is an agile assassin who’s at her best when striking from the shadows.

Today marks one of the first times that the gaming community will get its hands on Shadows, and to celebrate the occasion, the Ubisoft offices — a mix of cozy chalet-worthy reclaimed wood and wide-open windows that afford a view of snowy Quebec City rooftops — have been reskinned with an Assassin’s Creed theme, including a display that emphasizes the heft of Yasuke’s weapons, especially an imposing-looking 13-pound model of the character’s sword. (On this day, the display is hosted by associate game director Simon Lemay-Comtois, who appears quite capable of wielding it.)

Download Assassin's Creed Shadows from the Mac App Store

Côté calls Shadows his team’s “most ambitious” game. In crafting the game’s expansive world, Ubisoft’s development team took advantage of an array of advanced Mac technologies: Metal 3 (working in concert with Ubisoft’s next-generation Anvil engine), Apple silicon, and a mix of HDR support and real-time ray tracing on Macs with M3 and M4 that Côté says was “transformative” in creating the game’s immersion.

It’s been a longtime dream to bring the game to Mac.

Marc-Alexis Côté, Ubisoft executive producer

“Seeing those millions of lines of code work natively on a Mac was a feeling that’s hard to describe,” Côté says. “When you look at the game’s performance, the curve Apple is on with successive improvements to the M-series chips year after year, and the way the game looks on an HDR screen, you’re like, ‘Is this real?’”

Assassin’s Creed Shadows is a balance of the technical and creative. For the former, associate technical director Mathieu Belanger says the capabilities of Mac laid the groundwork for technical success. “The architecture of the hardware is so well done, thanks in part to the unified memory between the GPU and CPU. That made us think the future is bright for gaming on the platform. So many things about doing this on Mac were great right out of the box.”

Naoe’s counterpart, Yasuke, prefers the use of brute force.

On the creative side, Ubisoft creative director Jonathan Dumont focused on a different opportunity. “The important thing was: Does this feel right? Is it what we want to send to players? And the answer was yes.”

The creative team’s goal was nothing short of “making this world feel alive,” says Martin Bedard, a 20-year Ubisoft veteran who served as the game’s technology director (and is very good at playing as Naoe). “You’re put into a moment that really existed,” he says. “This story is your playground.”

There are also fluffy kittens. We’ll get to those.

The ever-changing seasons lend an incredible variety to the game’s environments.

And there’s tremendous power behind the beauty, because the game’s biomes, seasons, weather, and lighting are all dynamic creations. The sunset hour bathes the mountains in soft purple light; the sun’s rays float in through leaves and temple roofs. Pretty much every room has a candle in it, which means the light is always changing. “Look at the clouds here,” says Bedard, pointing at the screen. “That’s not a rendering. These are all fluid-based cloud simulations.”

“Japan feels like it’s 80 percent trees and mountains,” says Dumont. “If you’re building this world without the rain, and the winds, and the mountains, it doesn’t feel right.”

Wherever you are, wherever you go, everything is beautiful and alive.

Mathieu Belanger, associate technical director

And those winds? “We developed a lot of features that were barely possible before, and one of them was a full simulation of the wind, not just an animation,” says Belanger. “We even built a humidity simulation that gathers clouds together.” For the in-game seasons, Ubisoft developed an engine that depicted houses, markets, and temples, in ever-changing conditions. “This was all done along the way over the past four years,” he says.

To pursue historical accuracy, Dumont and the creative team visited Japan to study every detail, including big-picture details (like town maps) to very specific ones (like the varnish that would have been applied to 16th-century wood). It wasn’t always a slam dunk, says Côté: In one visit, their Japanese hosts recommended a revision to the light splashing against the mountains. “We want to get all those little details right,” he says. (A “full-immersion version,” entirely in Japanese with English subtitles, is available.)

To recreate the world of 16th-century Japan, the Ubisoft creative visited Japan to study every detail.

Ubisoft’s decision to split the protagonist into two distinct characters with different identities, skill sets, origin stories, and class backgrounds came early in the process. (“That was a fun day,” laughs Belanger.) Ubisoft team members emphasize that choosing between Naoe and Yasuke is a matter of personal preference — lethal subtlety vs. brute force. Players can switch between characters at any time, and, as you might suspect, the pair grows stronger together as the story goes on. Much of Naoe’s advantage comes from her ability to linger in the game’s shadows — not just behind big buildings, but wherever the scene creates a space for her to hide. “The masterclass is clearing out a board without being spotted once,” says Bedard.

(The Hideout is) peaceful. You can say, ‘I feel like putting some trees down, seeing what I collected, upgrading my buildings, and petting the cats.’

Jonathan Dumont, Ubisoft creative director

Which brings us to the Hideout, Naoe and Yasuke’s home base and a bucolic rural village that acts as a zen-infused respite from the ferocity of battle. “It’s a place that welcomes you back,” says Dumont. It’s eminently customizable, both from a game-progression standpoint but also in terms of aesthetics. Where the battle scenes are a frenzy of bruising combat or stealth attacks, the Hideout is a refuge for supplies, artwork, found objects, and even a furry menagerie of cats, dogs, deer, and other calming influences. “There are progressions, of course,” says Dumont, “but it’s peaceful. You can say, ‘I feel like putting some trees down, seeing what I collected, upgrading my buildings, and petting the cats.”

“The kittens were a P1 feature,” laughs associate game director Dany St-Laurent.

Yasuke prepares to face off against an opponent in what will likely be a fruitful battle.

Yet for all those big numbers, Dumont says the game boils down to something much simpler. “I just think the characters work super-well together,” he says. “It’s an open-world game, yes. But at its core, it features two characters you’ll like. And the game is really about following their journey, connecting with them, exploring their unique mysteries, and seeing how they flow together. And I think the way in which they join forces is one of the best moments in the franchise.”

And if the Ubisoft team has its way, there will be plenty more moments to come. “I think the game will scale for years to come on the Mac platform,” says Côté. “Games can be more and more immersive with each new hardware release. We’re trying to create something here where more people can come with day-one games on the Mac, because I think it’s a beautiful platform.”

Download Assassin's Creed Shadows from the Mac App Store

In this edition: An incredible AAA game comes to Mac. Plus, the latest on International Women’s Day activities, WeChat, and more.

Read the full article

Check out the official Apple Developer WeChat account to find news, announcements, and upcoming activities for the developer community.

Learn more in Simplified Chinese

The beta versions of iOS 18.4, iPadOS 18.4, macOS 15.4, tvOS 18.4, visionOS 2.4, and watchOS 11.4 are now available. Get your apps ready by confirming they work as expected on these releases. And to take advantage of the advancements in the latest SDKs, make sure to build and test with Xcode 16.3.

As previewed last year, iOS 18.4 and iPadOS 18.4 include support for default translation apps for all users worldwide, and default navigation apps for EU users.

Beginning April 24, 2025, apps uploaded to App Store Connect must be built with Xcode 16 or later using an SDK for iOS 18, iPadOS 18, tvOS 18, visionOS 2, or watchOS 11.

View downloads and release notes

As of today, apps without trader status have been removed from the App Store in the European Union (EU) until trader status is provided and verified by Apple.

Account Holders or Admins in the Apple Developer Program will need to enter this status in App Store Connect to comply with the Digital Services Act.

Learn what a trader is and how to enter your status

You can now take advantage of upgraded security options when creating new token authentication keys for the Apple Push Notification service (APNs).

Team-scoped keys enable you to restrict your token authentication keys to either development or production environments, providing an additional layer of security and ensuring that keys are used only in their intended environments.

Topic-specific keys provide more granular control by enabling you to associate each key with a specific bundle ID, allowing for more streamlined and organized key management. This is particularly beneficial for large organizations that manage multiple apps across different teams.

Your existing keys will continue to work for all push topics and environments. At this time, you don’t have to update your keys unless you want to take advantage of the new capabilities.

For detailed instructions on how to secure your communications with APNs, read Establishing a token-based connection to APNs.

Starting February 14, 2025, new regulatory requirements in South Korea will apply to all apps with offers and trials for auto-renewing subscriptions.

To comply, if you offer trials or offers for auto-renewing subscriptions to your app or game, additional consent must be obtained for your trial or offer after the initial transaction. The App Store will help to get consent by informing the affected subscribers with an email, push notification, and in-app price consent sheet, and asking your subscribers to agree to the new price.

This additional consent must be obtained from customers within 30 days from the payment or conversion date for:

• Free to paid trials
• Discounted subscription offers to standard-price subscriptions

Apps that do not offer a free trial or discounted offer before a subscription converts to the regular price are not affected.

Learn more about this regulation

The App Store is designed to make it easy to sell your digital goods and services globally, with support for 44 currencies across 175 storefronts.

From time to time, we may need to adjust prices or your proceeds due to changes in tax regulations or foreign exchange rates. These adjustments are made using publicly available exchange rate information from financial data providers to help make sure prices for apps and In-App Purchases stay consistent across all storefronts.

Tax and pricing updates for February

As of February 6:

Your proceeds from the sale of eligible apps and In‑App Purchases have been modified in:

• Azerbaijan: value-added tax (VAT) introduction of 18%
• Peru: VAT introduction of 18%
• Slovakia: Standard VAT rate increase from 20% to 23%
• Slovakia: Reduced VAT rate introduction of 5% for ebooks
• Estonia: Reduced VAT rate increase from 5% to 9% for news publications, magazines, and other periodicals
• Finland: Reduced VAT rate increase from 10% to 14% for ebooks

Exhibit B of the Paid Applications Agreement has been updated to indicate that Apple collects and remits applicable taxes in Azerbaijan and Peru.¹

As of February 24:

Pricing for apps and In-App Purchases will be updated for the Azerbaijan and Peru storefronts if you haven’t selected one of these as the base for your app or In‑App Purchase.² These updates also consider VAT introductions listed in the tax updates section above.

If you’ve selected the Azerbaijan or Peru storefront as the base for your app or In-App Purchase, prices won’t change. On other storefronts, prices will be updated to maintain equalization with your chosen base price.

Prices won’t change in any region if your In‑App Purchase is an auto‑renewable subscription. Prices also won’t change on the storefronts where you manually manage prices instead of using the automated equalized prices.

The Pricing and Availability section of Apps has been updated in App Store Connect to display these upcoming price changes. As always, you can change the prices of your apps, In‑App Purchases, and auto‑renewable subscriptions at any time.

Learn more about managing your prices

View or edit upcoming price changes

Edit your app’s base country or region

Pricing and availability start times by country or region

Set a price for an In-App Purchase

Beginning April 1:

As a result of last year’s change in Japan’s tax regulations, Apple (through iTunes K.K. in Japan) is now designated as a Specified Platform Operator by the Japan tax authority. All paid apps and In-App Purchases, (including game items, such as coins) sold by non-Japan-based developers on the App Store in Japan will be subject to the platform tax regime. Apple will collect and remit a 10% Japanese consumption tax (JCT) to the National Tax Agency JAPAN on such transactions at the time of purchase. Your proceeds will be adjusted accordingly.

Please note any prepaid payment instruments (such as coins) sold prior to April 1, 2025, will not be subject to platform taxation, and the relevant JCT compliance should continue to be managed by the developer.

For specific information on how the JCT affects in-game items, see Question 7 in the Tax Agency of Japan’s Q&A about Platform Taxation of Consumption Tax.

Learn more about your proceeds

View payments and proceeds

Download financial reports

¹ Translations of the updated agreement are available on the Apple Developer website today.

² Excludes auto-renewable subscriptions.

The Vietnamese Ministry of Information and Communications (MIC) requires games to be licensed to remain available on the App Store in Vietnam. To learn more and apply for a game license, review the regulations.

Once you have obtained your license:

• Sign in to App Store Connect.
• Enter the license number and the associated URL in the description section of your game’s product page.
• Note that you only need to provide this information for the App Store localization displayed on the Vietnam storefront.
• Submit an update to App Review.

If you have questions on how to comply with these requirements, please contact the Authority of Broadcasting and Electronic Information (ABEI) under the Vietnamese Ministry of Information and Communications.

View the full law

In this edition: The latest on developer activities, the Swift Student Challenge, the team behind Bears Gratitude, and more.

Read the full article

Here’s the story of how a few little bears led their creators right to an Apple Design Award.

Bears Gratitude is a warm and welcoming title developed by the Australian husband-and-wife team of Isuru Wanasinghe and Nayomi Hettiarachchi.

Journaling apps just don’t get much cuter: Through prompts like “Today isn’t over yet,” “I’m literally a new me,” and “Compliment someone,” the Swift-built app and its simple hand-drawn mascots encourage people to get in the habit of celebrating accomplishments, fostering introspection, and building gratitude. “And gratitude doesn’t have to be about big moments like birthdays or anniversaries,” says Wanasinghe. “It can be as simple as having a hot cup of coffee in the morning.”

ADA FACT SHEET

Bears Gratitude

• Winner: Delight and Fun
• Available on: iOS, iPadOS, macOS
• Team size: 2

Download Bears Gratitude from the App Store

Wanasinghe is a longtime programmer who’s run an afterschool tutoring center in Sydney, Australia, for nearly a decade. But the true spark for Bears Gratitude and its predecessor, Bears Countdown, came from Hettiarachchi, a Sri Lankan-born illustrator who concentrated on her drawing hobby during the Covid-19 lockdown.

Wanasinghe is more direct. “The art is the heart of everything we do,” he says.

Bears Gratitude was developed by the Australian husband-and-wife team of Isuru Wanasinghe and Nayomi Hettiarachchi.

In fact, the art is the whole reason the app exists. As the pandemic months and drawings stacked up, Hettiarachchi and Wanasinghe found themselves increasingly attached to her cartoon creations, enough that they began to consider how to share them with the world. The usual social media routes beckoned, but given Wanasinghe’s background, the idea of an app offered a stronger pull.

“In many cases, you get an idea, put together a design, and then do the actual development,” he says. “In our case, it’s the other way around. The art drives everything.”

The art is the heart of everything we do.

Isuru Wanasinghe, Bears Gratitude cofounder

With hundreds of drawings at their disposal, the couple began thinking about the kinds of apps that could host them. Their first release was Bears Countdown, which employed the drawings to help people look ahead to birthdays, vacations, and other marquee moments. Countdown was never intended to be a mass-market app; the pair didn’t even check its launch stats on App Store Connect. “We’d have been excited to have 100 people enjoy what Nayomi had drawn,” says Wanasinghe. “That’s where our heads were at.”

But Countdown caught on with a few influencers and become enough of a success that the pair began thinking of next steps. “We thought, well, we’ve given people a way to look forward,” says Wanasinghe. “What about reflecting on the day you just had?’”

Hettiarachchi’s art samples get a close inspection from one of her trusted associates.

Gratitude keeps the cuddly cast from Countdown, but otherwise the app is an entirely different beast. It was also designed in what Wanasinghe says was a deliberately unusual manner. “Our design approach was almost bizarrely linear,” says Wanasinghe. “We purposely didn’t map out the app. We designed it in the same order that users experience it.”

Other unorthodox decisions followed, including the absence of a sign-in screen. “We wanted people to go straight into the experience and start writing,” he says. The home-screen journaling prompts are presented via cards that users flip through by tapping left and right. “It’s definitely a nonstandard UX,” says Wanasinghe, “but we found over and over again that the first thing users did was flip through the cards.”

Our design approach was almost bizarrely linear. We purposely didn’t map out the app. We designed it in the same order that users experience it.

Isuru Wanasinghe, Bears Gratitude cofounder

Another twist: The app’s prompts are written in the voice of the user, which Wanasinghe says was done to emphasize the personal nature of the app. “We wrote the app as if we were the only ones using it, which made it more relatable,” he says.

Then there are the bears, which serve not only as a distinguishing hook in a busy field, but also as a design anchor for its creators. “We’re always thinking: ‘Instead of trying to set our app apart, how do we make it ours?’ We use apps all the time, and we know how they behave. But here we tried to detach ourselves from all that, think of it as a blank canvas, and ask, ‘What do we want this experience to be?’”

Early design sketches for Bears Gratitude show the collection of swipe-able prompt cards.

Bears Gratitude isn’t a mindfulness app — Wanasinghe is careful to clarify that neither he nor Hettiarachchi are therapists or mental health professionals. “All we know about are the trials and tribulations of life,” he says.

But those trials and tribulations have reached a greater world. “People have said, ‘This is just something I visit every day that brings me comfort,’” says Wanasinghe. “We’re so grateful this is the way we chose to share the art. We’re plugged into people’s lives in a meaningful way.”

Meet the 2024 Apple Design Award winners

Behind the Design is a series that explores design practices and philosophies from finalists and winners of the Apple Design Awards. In each story, we go behind the screens with the developers and designers of these award-winning apps and games to discover how they brought their remarkable creations to life.

Submissions for the Swift Student Challenge 2025 are now open through February 23. You have three more weeks to design, test, refine, and submit your app playground for consideration to be named one of 350 winners.

What to know:

• The Challenge is free to enter — you just need access to an iPad or Mac with Swift Playground or Xcode.
• The best app ideas are personal — let your passion shine through your work.
• No formal coding experience required — the Challenge is open to students of all levels.
• Your app playground doesn’t need to be intricate — it should be experienced within 3 minutes or less.

Where to start:

• Explore tools and tutorials to build an incredible app playground.
• Get inspired by last year’s Distinguished Winners, learn about their winning apps, and read about their experiences at Apple Park.

Learn more about the Challenge

The App Store facilitates billions of transactions annually to help developers grow their businesses and provide a world-class customer experience. To further support developers’ evolving business models — such as exceptionally large content catalogs, creator experiences, and subscriptions with optional add-ons — we’re introducing the Advanced Commerce API.

Developers can apply to use the Advanced Commerce API to support eligible App Store business models and more flexibly manage their In-App Purchases within their app. These purchases leverage the power of the trusted App Store commerce system, including end-to-end payment processing, tax support, customer service, and more, so developers can focus on providing great app experiences.

Learn about eligibility requirements and how to apply

Starting February 17, 2025: Due to the European Union’s Digital Services Act, apps without trader status will be removed from the App Store in the European Union until trader status is provided and verified, if necessary.

As a reminder, Account Holders or Admins in the Apple Developer Program need to enter trader status in App Store Connect for apps on the App Store in the European Union in order to comply with the Digital Services Act.

Learn what a trader is and how to enter your status

As part of ongoing efforts to improve security and privacy on Apple platforms, the App Store receipt signing intermediate certificate is being updated to use the SHA-256 cryptographic algorithm. This certificate is used to sign App Store receipts, which are the proof of purchase for apps and In-App Purchases.

This update is being completed in multiple phases and some existing apps on the App Store may be impacted by the next update, depending on how they verify receipts.

Starting January 24, 2025, if your app performs on-device receipt validation and doesn’t support the SHA-256 algorithm, your app will fail to validate the receipt. If your app prevents customers from accessing the app or premium content when receipt validation fails, your customers may lose access to their content.

If your app performs on-device receipt validation, update your app to support certificates that use the SHA-256 algorithm; alternatively, use the AppTransaction and Transaction APIs to verify App Store transactions.

For more details, view TN3138: Handling App Store receipt signing certificate changes.

Starting next month, Apple will change the supported algorithms that secure server connections for Apple Pay on the Web. In order to maintain uninterrupted service, you’ll need to ensure that your production servers support one or more of the designated six ciphers before February 4, 2025.

These algorithm changes will affect any secure connection you’ve established as part of your Apple Pay integration, including the following touchpoints:

• Requesting an Apple Pay payment session (Apple Pay on the Web only)
• Renewing your domain verification (Apple Pay on the Web only)
• Receiving and handling merchant token notifications for recurring, deferred, and automatic-reload transactions (Apple Pay on the Web and in app)
• Creating and updating Wallet Orders (Apple Pay on the Web and in app)
• Managing merchant onboarding via the Apple Pay Web Merchant Registration API (payment service provider (PSP) and e-commerce platforms only)

In the first edition of the new year: Bring SwiftUI to your app in Cupertino, get ready for the Swift Student Challenge, meet the team behind Oko, and more.

Read the full article

Oko is a testament to the power of simplicity.

The 2024 Apple Design Award winner for Inclusivity and 2024 App Store Award winner for Cultural Impact leverages Artificial Intelligence to help blind or low-vision people navigate pedestrian walkways by alerting them to the state of signals — “Walk,” “Don’t Walk,” and the like — through haptic, audio, and visual feedback. The app instantly affords more confidence to its users. Its bare-bones UI masks a powerful blend of visual and AI tools under the hood. And it’s an especially impressive achievement for a team that had no iOS or Swift development experience before launch.

“The biggest feedback we get is, ‘It’s so simple, there’s nothing complex about it,’ and that’s great to hear,” says Vincent Janssen, one of Oko’s three Belgium-based founders. “But we designed it that way because that’s what we knew how to do. It just happened to also be the right thing.”

ADA FACT SHEET

From left: Willem Van de Mierop, Michiel Janssen, and Vincent Janssen are the three cofounders of Oko. The app’s name means “eye.”

Oko

• Winner: Inclusivity
• Team: AYES BV
• Available on: iPhone
• Team size: 6
• Previous accolades: 2024 App Store Award winner for Cultural Impact; App Store Editors’ Choice

Learn more about Oko

Download Oko from the App Store

For Janssen and his cofounders, brother Michiel and longtime friend Willem Van de Mierop, Oko — the name translates to “eye” — was a passion project that came about during the pandemic. All three studied computer science with a concentration in AI, and had spent years working in their hometown of Antwerp. But by the beginning of 2021, the trio felt restless. “We all had full-time jobs,” says Janssen, “but the weekends were pretty boring.” Yet they knew their experience couldn’t compare to that of a longtime friend with low vision, who Janssen noticed was feeling more affected as the autumn and winter months went on.

“We really started to notice that he was feeling isolated more than others,” says Janssen. “Here in Belgium, we were allowed to go for walks, but you had to be alone or with your household. That meant he couldn’t go with a volunteer or guide. As AI engineers, that got us thinking, ‘Well, there are all these stories about autonomous vehicles. Could we come up with a similar system of images or videos that would help people find their way around public spaces?’”

I had maybe opened Xcode three times a few years before, but otherwise none of us had any iOS or Swift experience.

Vincent Janssen, Oko founder

The trio began building a prototype that consisted of a microcomputer, 3D-printed materials, and a small portable speaker borrowed from the Janssen brothers’ father. Today, Janssen calls it “hacky hardware,” something akin to a small computer with a camera. But it allowed the team and their friend — now their primary tester — to walk the idea around and poke at the technology’s potential. Could AI recognize the state of a pedestrian signal? How far away could it detect a Don’t Walk sign? How would it perform in rain or wind or snow? There was just one way to know. “We went out for long walks,” says Janssen.

And while the AI and hardware performed well in their road tests, issues arose around the hardware’s size and usability, and the team begin to realize that software offered a better solution. The fact that none of the three had the slightest experience building iOS apps was simply a hurdle to clear. “I had maybe opened Xcode three times a few years before,” says Janssen, “but otherwise none of us had any iOS or Swift experience.”

Oko helps people navigate pedestrian walkways through interactive maps and audio, visual, and haptic feedback.

So that summer, the team pivoted to software, quitting their full-time jobs and throwing themselves into learning Swift through tutorials, videos, and trusty web searches. The core idea crystallized quickly: Build a simple app that relied on Camera, the Maps SDK, and a powerful AI algorithm that could help people get around town. “Today, it’s a little more complex, but in the beginning the app basically opened up a camera feed and a Core ML model to process the images,” says Janssen, noting that the original model was brought over from Python. “Luckily, the tools made the conversion really smooth.” (Oko’s AI models run locally on device.)

With the software taking shape, more field testing was needed. The team reached out to accessibility-oriented organizations throughout Belgium, drafting a team of 100 or so testers to “codevelop the app,” says Janssen. Among the initial feedback: Though Oko was originally designed to be used in landscape mode, pretty much everyone preferred holding their phones in portrait mode. “I had the same experience, to be honest,” said Janssen, “but that meant we needed to redesign the whole thing.”

The Oko team navigates through prototypes at a review session in their hometown of Antwerp, Belgium.

Other changes included amending the audio feedback to more closely mimic existing real-world sounds, and addressing requests to add more visual feedback. The experience amounted to getting a real-world education about accessibility on the fly. “We found ourselves learning about VoiceOver and haptic feedback very quickly,” says Janssen.

Still, the project went remarkably fast — Oko launched on the App Store in December 2021, not even a year after the trio conceived of it. “It took a little while to do things, like make sure the UI wasn’t blocked, especially since we didn’t fully understand the code we wrote in Swift,” laughs Janssen, “but in the end, the app was doing what it needed to do.”

We found ourselves learning about VoiceOver and haptic feedback.

Vincent Janssen, Oko founder

The accessibility community took notice. And in the following months, the Oko team continued expanding its reach — Michiel Janssen and Van de Mierop traveled to the U.S. to meet with accessibility organizations and get firsthand experience with American street traffic and pedestrian patterns. But even as the app expanded, the team retained its focus on simplicity. In fact, Janssen says, they explored and eventually jettisoned some expansion ideas — including one designed to help people find and board public transportation — that made the app feel a little too complex.

Today, the Oko team numbers 6, including a fleet of developers who handle more advanced Swift matters. “About a year after we launched, we got feedback about extra features and speed improvements, and needed to find people who were better at Swift than we are,” laughs Janssen. At the same time, the original trio is now learning about business, marketing, and expansion.

At its core, Oko remains a sparkling example of a simple app that completes its task well. “It’s still a work in progress, and we’re learning every day,” says Janssen. In other words, there are many roads yet to cross.

Meet the 2024 Apple Design Award winners

Behind the Design is a series that explores design practices and philosophies from finalists and winners of the Apple Design Awards. In each story, we go behind the screens with the developers and designers of these award-winning apps and games to discover how they brought their remarkable creations to life.

The beta versions of iOS 18.3, iPadOS 18.3, macOS 15.3, tvOS 18.3, visionOS 2.3, and watchOS 11.3 are now available. Get your apps ready by confirming they work as expected on these releases. And to take advantage of the advancements in the latest SDKs, make sure to build and test with Xcode 16.2.

View downloads and release notes

Learn about testing a beta OS

Learn about sending feedback

Join us in celebrating the outstanding work of these developers from around the world.

Meet the winners

Attachment 2 of the Apple Developer Program License Agreement has been amended to specify requirements for use of the In-App Purchase API. Please review the changes and accept the updated terms in your account.

View the full terms and conditions

Translations of the updated agreement will be available on the Apple Developer website within one month.

In this edition: The year in sessions, activities, apps, and games.

Read the full article

The busiest season on the App Store is almost here. Make sure your apps and games are up to date and ready.

App Review will continue to accept submissions throughout the holiday season. Please plan to submit time-sensitive submissions early, as we anticipate high volume and reviews may take longer to complete from December 20-26.

Learn more about submitting to the App Store

Every year, the App Store Awards celebrate exceptional apps and games that improve people's lives while showcasing the highest levels of technical innovation, user experience, design, and positive cultural impact. This year, the App Store Editorial team is proud to recognize over 40 outstanding finalists. Winners will be announced in the coming weeks.

Learn about the finalists

The App Store is designed to make it easy to sell your digital goods and services globally, with support for 44 currencies across 175 storefronts.

From time to time, we may need to adjust prices or your proceeds due to changes in tax regulations or foreign exchange rates. These adjustments are made using publicly available exchange rate information from financial data providers to help make sure prices for apps and In-App Purchases stay consistent across all storefronts.

Tax updates as of October:

Your proceeds from the sale of eligible apps and In‑App Purchases have been increased in:

• Nepal: Apple no longer remits Nepal value-added tax (VAT) for local developers and proceeds were increased accordingly.
• Kazakhstan: Apple no longer remits Kazakstan VAT for local developers and proceeds were increased accordingly.
• Madeira: Decrease of the Madeira VAT rate from 5% to 4% for news publications, magazines and other periodicals, books, and audiobooks.

Exhibit B of the Paid Applications Agreement has been updated to indicate that Apple will not remit VAT in Nepal and Kazakhstan for local developers.

Learn more about your proceeds

View payments and proceeds

Download financial reports

Price updates as of December 2:

• Pricing for apps and In-App Purchases will be updated for the Japan and Türkiye storefronts if you haven’t selected one of these as the base for your app or In‑App Purchases.

If you’ve selected the Japan or Türkiye storefront as the base for your app or In-App Purchase, prices won’t change. On other storefronts, prices will be updated to maintain equalization with your chosen base price.

Prices won’t change in any region if your In‑App Purchase is an auto‑renewable subscription and won’t change on the storefronts where you manually manage prices instead of using the automated equalized prices.

The Pricing and Availability section of Apps has been updated in App Store Connect to display these upcoming price changes. As always, you can change the prices of your apps, In‑App Purchases, and auto‑renewable subscriptions at any time.

Learn more about managing your prices

View or edit upcoming price changes

Edit your app’s base country or region

Pricing and availability start times by country or region

Set a price for an In-App Purchase

Share your app or game’s upcoming content and enhancements for App Store featuring consideration with new Featuring Nominations in App Store Connect. Submit a nomination to tell our team about a new launch, in-app content, or added functionality. If you’re featured in select placements on the Today tab, you’ll also receive a notification via the App Store Connect app.

In addition, you can promote your app or game’s biggest moments — such as an app launch, new version, or select featuring placements on the App Store — with readymade marketing assets. Use the App Store Connect app to generate Apple-designed assets and share them to your social media channels. Include the provided link alongside your assets so people can easily download your app or game on the App Store.

Learn more about getting featured

Submit a Featuring Nomination

The Push Notifications Console now includes metrics for broadcast push notifications sent in the Apple Push Notification service (APNs) production environment. The console’s interface provides an aggregated view of the broadcast push notifications that are successfully accepted by APNs, the number of devices that receive them, and a snapshot of the maximum number of devices subscribed to your channels.

Set up broadcast push notifications

Broadcast updates to your Live Activities

Let’s get this out of the way: Yes, Devin Davies is an excellent cook. “I’m not, like, a professional or anything,” he says, in the way that people say they’re not good at something when they are.

But in addition to knowing his way around the kitchen, Davies is also a seasoned developer whose app Crouton, a Swift-built cooking aid, won him the 2024 Apple Design Award for Interaction.

Crouton is part recipe manager, part exceptionally organized kitchen assistant. For starters, the app collects recipes from wherever people find them — blogs, family cookbooks, scribbled scraps from the ’90s, wherever — and uses tasty ML models to import and organize them. “If you find something online, just hit the Share button to pull it into Crouton,” says the New Zealand-based developer. “If you find a recipe in an old book, just snap a picture to save it.”

And when it’s time to start cooking, Crouton reduces everything to the basics by displaying only the current step, ingredients, and measurements (including conversions). There’s no swiping around between apps to figure out how many fl oz are in a cup; no setting a timer in a different app. It’s all handled right in Crouton. “The key for me is: How quickly can I get you back to preparing the meal, rather than reading?” Davies says.

ADA FACT SHEET

Crouton

• Winner: Interaction
• Available on: iPhone, iPad, Mac, Apple Vision Pro, Apple Watch
• Team size: 1

Learn more about Crouton

Download Crouton from the App Store

Crouton is the classic case of a developer whipping up something he needed. As the de facto chef in the house, Davies had previously done his meal planning in the Notes app, which worked until, as he laughs, “it got a little out of hand.”

At the time, Davies was in his salad days as an iOS developer, so he figured he could build something that would save him a little time. (It’s in his blood: Davies’s father is a developer too.) "Programming was never my strong suit,” he says, “but once I started building something that solved a problem, I started thinking of programming as a means to an end, and that helped.”

Davies’s full-time job was his meal ticket, but he started teaching himself Swift on the side. Swift, he says, clicked a lot faster than the other languages he’d tried, especially as someone who was still developing a taste for programming. “It still took me a while to get my head into it,” he says, “but I found pretty early on that Swift worked the way I wanted a language to work. You can point Crouton at some text, import that text, and do something with it. The amount of steps you don’t have to think about is astounding.”

I found pretty early on that Swift worked the way I wanted a language to work.

Devin Davies, Crouton

Coding with Swift offered plenty of baked-in benefits. Davies leaned on platform conventions to make navigating Crouton familiar and easy. Lists and collection views took advantage of Camera APIs. VisionKit powered text recognition; a separate model organized imported ingredients by category.

“I could separate out a roughly chopped onion from a regular onion and then add the quantity using a Core ML model,” he says. “It’s amazing how someone like me can build a model to detect ingredients when I really have zero understanding of how it works.”

Davies designed Crouton with simplicity in mind at all times. “I spent a lot of time figuring out what to leave out rather than bring in,” he says.

The app came together quickly: The first version was done in about six months, but Crouton simmered for a while before finding its audience. “My mom and I were the main active users for maybe a year,” Davies laughs. “But it’s really important to build something that you use yourself — especially when you’re an indie — so there’s motivation to carry on.”

Davies served up Crouton updates for a few years, and eventually the app gained more traction, culminating with its Apple Design Award for Interaction at WWDC24. That’s an appropriate category, Davies says, because he believes his approach to interaction is his app’s special sauce. “My skillset is figuring out how the pieces of an app fit together, and how you move through them from point A to B to C,” he says. “I spent a lot of time figuring out what to leave out rather than bring in.”

Crouton recipes can be imported from blogs, cookbook, scraps of paper, or anywhere else they might be found.

Davies hopes to use the coming months to explore spicing up Crouton with Apple Intelligence, Live Activities on Apple Watch, and translation APIs. (Though Crouton is his primary app, he’s also built an Apple Vision Pro app called Plate Smash, which is presumably very useful for cooking stress relief.)

But it’s important to him that any new features or upgrades pair nicely with the current Crouton. “I’m a big believer in starting out with core intentions and holding true to them,” he says. “I don’t think that the interface, over time, has to be completely different.”

My skillset is figuring out how the pieces of an app fit together, and how you move through them from point A to B to C.

Devin Davies, Crouton

Because it’s a kitchen assistant, Crouton is a very personal app. It’s in someone’s kitchen at mealtime, it’s helping people prepare means for their loved ones, it’s enabling them to expand their culinary reach. It makes a direct impact on a person’s day. That’s a lot of influence to have as an app developer — even when a recipe doesn’t quite pan out.

“Sometimes I’ll hear from people who discover a bug, or even a kind of misunderstanding, but they’re always very kind about it,” laughs Davies. “They’ll tell me, ‘Oh, I was baking a cake for my daughter’s birthday, and I put in way too much cream cheese and I ruined it. But, great app!’”

Meet the 2024 Apple Design Award winners

Behind the Design is a series that explores design practices and philosophies from finalists and winners of the Apple Design Awards. In each story, we go behind the screens with the developers and designers of these award-winning apps and games to discover how they brought their remarkable creations to life.

In this edition: The Swift Pathway, new developer activities around the world, and an interview with the creator of recipe app Crouton.

Read the full article

As part of ongoing efforts to improve security and privacy on Apple platforms, the App Store receipt signing intermediate certificate is being updated to use the SHA-256 cryptographic algorithm. This certificate is used to sign App Store receipts, which are the proof of purchase for apps and In-App Purchases.

This update is being completed in multiple phases and some existing apps on the App Store may be impacted by the next update, depending on how they verify receipts.

Starting January 24, 2025, if your app performs on-device receipt validation and doesn't support a SHA-256 algorithm, your app will fail to validate the receipt. If your app prevents customers from accessing the app or premium content when receipt validation fails, your customers may lose access to their content.

If your app performs on-device receipt validation, update your app to support certificates that use the SHA-256 algorithm; alternatively, use the AppTransaction and Transaction APIs to verify App Store transactions.

For more details, view TN3138: Handling App Store receipt signing certificate change.

Beta testing your apps, games, and App Clips is even better with new enhancements to TestFlight. Updates include:

• Redesigned invitations. TestFlight invitations now include your beta app description to better highlight new features and content your app or game offers to prospective testers. Apps and games with an approved version that’s ready for distribution can also include their screenshots and app category in their invite. We’ve also added a way for people to leave feedback if they didn’t join your beta, so you can understand why they didn’t participate.
• Tester enrollment criteria. You can choose to set criteria, such as device type and OS versions, to more easily enroll qualified testers via a public link to provide more relevant feedback on your invite.
• Public link metrics. Find out how successful your public link is at enrolling testers for your app with new metrics. Understand how many testers viewed your invite in the TestFlight app and chose to accept it. If you’ve set criteria for the public link, you can also view how many testers didn’t meet the criteria.

To get started with TestFlight, upload your build, add test information, and invite testers.

Learn more about TestFlight

The beta versions of iOS 18.2, iPadOS 18.2, and macOS 15.2 are now available. Get your apps ready by confirming they work as expected on these releases. And make sure to build and test with Xcode 16.2 beta to take advantage of the advancements in the latest SDKs.

As previewed earlier this year, changes to the browser choice screen, default apps, and app deletion for EU users, as well as support in Safari for exporting user data and for web browsers to import that data, are now available in the beta versions of iOS 18.2 and iPadOS 18.2.

These releases also include improvements to the Apps area in Settings first introduced in iOS 18 and iPadOS 18. All users worldwide will be able to manage their default apps via a Default Apps section at the top of the Apps area. New calling and messaging defaults are also now available for all users worldwide.

Following feedback from the European Commission and from developers, in these releases developers can develop and test EU-specific features, such as alternative browser engines, contactless apps, marketplace installations from web browsers, and marketplace apps, from anywhere in the world. Developers of apps that use alternative browser engines can now use WebKit in those same apps.

View details about the browser choice screen, how to make an app available for users to choose as a default, how to create a calling or messaging app that can be a default, and how to import user data from Safari.

The Apple Developer Program License Agreement and its Schedules 1, 2, and 3 have been updated to support updated policies and upcoming features, and to provide clarification. Please review the changes below and accept the updated terms in your account.

Apple Developer Program License Agreement

• Definitions, Section 3.3.3(J): Specified requirements for use of App Intents.
• Definitions, Section 3.3.5(C): Clarified requirements for use of Sign in With Apple.
• Definitions, Section 3.3.8(G): Specified requirements for use of the Critical Messaging API.
• Definitions, Sections 3.3.9(C): Clarified requirements for use of the Apple Pay APIs; updated definition of “Apple” for use of the Apple Pay APIs.
• Attachment 2: Clarified requirements for use of the In-App Purchase API.

Schedules 1, 2, and 3

Apple Services Pte. Ltd. is now the Apple legal entity responsible for the marketing and End-User download of the Licensed and Custom Applications by End-Users located in the following regions:

• Bhutan
• Brunei
• Cambodia
• Fiji
• Korea
• Laos
• Macau
• Maldives
• Micronesia, Fed States of
• Mongolia
• Myanmar
• Nauru
• Nepal
• Papua New Guinea
• Palau
• Solomon Islands
• Sri Lanka
• Tonga
• Vanuatu

Paid Applications Agreement (Schedules 2 and 3)

Exhibit B: Indicated that Apple shall not collect and remit taxes for local developers in Nepal and Kazakhstan, and such developers shall be solely responsible for the collection and remittance of such taxes as may be required by local law.

Exhibit C:

1. Section 6: Clarified that Apple will apply Korean VAT on the commissions payable by Korean developers to Apple to be deducted from remittance with respect to sales to Korean customers pursuant to local tax laws.
2. Section 10: For Singaporean developers who have registered for Singapore GST and have provided their Singapore GST registration number to Apple, clarified that Apple will apply Singaporean GST on the commissions payable by Singaporean developers to Apple to be deducted from remittance with respect to sales to Singaporean customers pursuant to local tax laws.

View the full terms and conditions

Translations of the Apple Developer Program License Agreement will be available on the Apple Developer website within one month.

Starting today, in order to submit updates for apps on the App Store in the European Union (EU) Account Holders or Admins in the Apple Developer Program need to enter trader status in App Store Connect. If you’re a trader, you’ll need to provide your trader information before you can submit your app for review.

Starting February 17, 2025, apps without trader status will be removed from the App Store in the EU until trader status is provided and verified in order to comply with the Digital Services Act.

Learn what a trader is and how to enter your status

The Certification Authority (CA) for Apple Push Notification service (APNs) is changing. APNs will update the server certificates in sandbox on January 20, 2025, and in production on February 24, 2025. All developers using APNs will need to update their application’s Trust Store to include the new server certificate: SHA-2 Root : USERTrust RSA Certification Authority certificate.

To ensure a smooth transition and avoid push notification delivery failures, please make sure that both old and new server certificates are included in the Trust Store before the cut-off date for each of your application servers that connect to sandbox and production.

At this time, you don’t need to update the APNs SSL provider certificates issued to you by Apple.

Get your app up to speed, meet the team behind Lies of P, explore new student resources, and more.

Read the full article

Lies of P is closer to its surprising source material than you might think.

Based on Carlo Collodi’s 1883 novel The Adventures of Pinocchio, the Apple Design Award-winning game is a macabre reimagining of the story of a puppet who longs to be a real boy. Collodi’s story is still best known as a children’s fable. But it’s also preprogrammed with more than its share of darkness — which made it an appealing foundation for Lies of P director Jiwon Choi.

“When we were looking for stories to base the game on, we had a checklist of needs,” says Choi. “We wanted something dark. We wanted a story that was familiar but not entirely childish. And the deeper we dove into Pinocchio, the more we found that it checked off everything we were looking for.”

ADA FACT SHEET

Lies of P

• Winner: Visuals and Graphics
• Team: ROUND8 Studio (developer), NEOWIZ (publisher)
• Available on: Mac
• Team size: 100
• Previous accolades: App Store 2023 Mac Game of the Year, App Store Editors’ Choice

Developed by the South Korea-based ROUND8 Studio and published by its parent company, NEOWIZ, Lies of P is a lavishly rendered dark fantasy adventure and a technical showpiece for Mac with Apple silicon. Yes, players control a humanoid puppet created by Geppetto. But instead of a little wooden boy with a penchant for little white lies, the game’s protagonist is a mechanical warrior with an array of massive swords and a mission to battle through the burned-out city of Krat to find his maker — who isn’t exactly the genial old woodcarver from the fable.

“The story is well-known, and so are the characters,” says Choi. “We knew that to create a lasting memory for gamers, we had to add our own twists.”

In the burned-out world of Lies of P, something this warm and beautiful can’t be good news.

Those twists abound. The puppet is accompanied by a digital lamp assistant named Gemini — pronounced “jim-i-nee,” of course. A major character is a play on the original’s kindly Blue Fairy. A game boss named Mad Donkey is a lot more irritable than the donkeys featured in Collodi’s story. And though nobody’s nose grows in Lies of P, characters have opportunities to lie in a way that directly affects the storyline — and potentially one of the game’s multiple endings.

We knew that to create a lasting memory for gamers, we had to add our own twists.

Jiwon Choi, Lies of P director

“If you play without knowing the original story, you might not catch all those twists,” says Choi. “But it goes the other way, too. We’ve heard from players who became curious about the original story, so they went back and found out about our twists that way.”

There’s nothing curious about the game’s success: In addition to winning a 2024 Apple Design Award for Visuals and Graphics, Lies of P was named the App Store’s 2023 Mac Game of the Year and has collected a bounty of accolades from the gaming community. Many of those call out the game’s visual beauty, a world of rich textures, detailed lighting, and visual customization options like MetalFX upscaling and volumetric fog effects that let you style the ruined city to your liking.

Many of Collodi’s original characters have been updated for Lies of P, including the Black Rabbit Brotherhood, who appear to be hopping mad.

For that city, the ROUND8 team added another twist by moving the story from its original Italian locale to the Belle Èpoque era of pre-WWI France. “Everyone expected Italy, and everyone expected steampunk,” says Choi, “but we wanted something that wasn’t quite as common in the gaming industry. We considered a few other locations, like the wild west, but the Belle Èpoque was the right mix of beauty and prosperity. We just made it darker and gloomier.”

We considered a few other locations, like the wild west, but the Belle Èpoque was the right mix of beauty and prosperity. We just made it darker and gloomier.

Jiwon Choi, Lies of P director

To create the game’s fierce (and oily) combat, Choi and the team took existing Soulslike elements and added their own touches, like customizable weapons that can be assembled from items lying around Krat. “We found that players will often find a weapon they like and use it until the ending,” says Choi. “We found that inefficient. But we also know that everyone has a different taste for weapons.”

The system, he says, gives players the freedom to choose their own combinations instead of pursuing a “best” pre-ordained weapon. And the strategy worked: Choi says players are often found online discussing the best combinations rather than the best weapons. “That was our intention when creating the system,” he says.

The game is set in the Belle Èpoque, an era known for its beauty and prosperity. “We just made it darker and gloomier,” says Choi.

Also intentional: The game’s approach to lying, another twist on the source material. “Lying in the game isn’t just about deceiving a counterpart,” says Choi. “Humans are the only species who can lie to one another, so lying is about exploring the core of this character.”

It’s also about the murky ethics of lying: Lies of P suggests that, at times, nothing is as human — or humane — as a well-intentioned falsehood.

“The puppet of Geppetto is not human,” says Choi. “But at the same time, the puppet acts like a human and occasionally exhibits human behavior, like getting emotional listening to music. The idea was: Lying is something a human might do. That’s why it’s part of the game.”

Every environment in Lies of P — including the Krat Festival, which has seen better days — is rich with desolate detail.

The Lies of P story might not be done just yet. Choi and team are working on downloadable content and a potential sequel — possibly starring another iconic character who’s briefly teased in the game’s ending. But in the meantime, the team is taking a moment to enjoy the fruits of their success. “At the beginning of development, I honestly doubted that we could even pull this off,” says Choi. “For me, the most surprising thing is that we achieved this. And that makes us think, ‘Well, maybe we could do better next time.’”

Meet the 2024 Apple Design Award winners

Behind the Design is a series that explores design practices and philosophies from finalists and winners of the Apple Design Awards. In each story, we go behind the screens with the developers and designers of these award-winning apps and games to discover how they brought their remarkable creations to life.

We’re thrilled to announce the Swift Student Challenge 2025. The Challenge provides the next generation of student developers the opportunity to showcase their creativity and coding skills by building app playgrounds with Swift.

Applications for the next Challenge will open in February 2025 for three weeks.

We’ll select 350 Swift Student Challenge winners whose submissions demonstrate excellence in innovation, creativity, social impact, or inclusivity. From this esteemed group, we’ll name 50 Distinguished Winners whose work is truly exceptional and invite them to join us at Apple in Cupertino for three incredible days where they’ll gain invaluable insights from Apple experts and engineers, connect with their peers, and enjoy a host of unforgettable experiences.

All Challenge winners will receive one year of membership in the Apple Developer Program, a special gift from Apple, and more.

To help you get ready, we’re launching new coding resources, including Swift Coding Clubs designed for students to develop skills for a future career, build community, and get ready for the Challenge.

Learn more

Apple is committed to making the App Store a safe place for everyone — especially kids. Within the next few months, the following regional age ratings for Australia and France will be implemented in accordance with local laws. No action is needed on your part. Where required by local regulations, regional ratings will appear alongside Apple global age ratings.

Australia

Apps with any instances of simulated gambling will display an R18+ regional age rating in addition to the Apple global age rating on the App Store in Australia.

France

Apps with a 17+ Apple global age rating will also display an 18+ regional age rating on the App Store in France.

Learn more about the age ratings

The App Review Guidelines have been revised to add iPadOS to Notarization.

Starting September 16:

• Users in the EU can download iPadOS apps on the App Store and through alternative distribution. As mentioned in May, if you have entered into the Alternative Terms Addendum for Apps in the EU, iPadOS first annual installs will begin to accrue and the lower App Store commission rate will apply.
• Alternative browser engines can be used in iPadOS apps.
• Historical App Install Reports in App Store Connect that can be used with our fee calculator will include iPadOS.

If you’ve entered into a previous version of the following agreements, be sure to sign the latest version, which supports iPadOS:

• Alternative Terms Addendum for Apps in the EU
• Web Browser Engine Entitlement Addendum for Apps in the EU
• Embedded Browser Engine Entitlement Addendum for Apps in the EU

Learn more about the update on apps distributed in the EU

Translations of the guidelines will be available on the Apple Developer website within one month.

You can now configure win-back offers — a new type of offer for auto-renewable subscriptions — in App Store Connect. Win-back offers allow you to reach previous subscribers and encourage them to resubscribe to your app or game. For example, you can create a pay up front offer for a reduced subscription price of $9.99 for six months, with a standard renewal price of $39.99 per year. Based on your offer configuration, Apple displays these offers to eligible customers in various places, including:

• Across the App Store, including on your product page, as well as in personalized recommendations and editorial selections on the Today, Games, and Apps tabs.
• In your app or game.
• Via a direct link you share using your own marketing channels.
• In Subscription settings.

When creating win-back offers in App Store Connect, you’ll determine customer eligibility, select regional availability, and choose the discount type. Eligible customers will be able to discover win-back offers this fall.

Set up win-back offers

Learn about win-back offers

iOS 18, iPadOS 18, macOS Sequoia, tvOS 18, visionOS 2, and watchOS 11 will soon be available to customers worldwide. Build your apps and games using the Xcode 16 Release Candidate and latest SDKs, test them using TestFlight, and submit them for review to the App Store. You can now start deploying seamlessly to TestFlight and the App Store from Xcode Cloud. With exciting new features like watchOS Live Activities, app icon customization, and powerful updates to Swift, Siri, Controls, and Core ML, you can deliver even more unique experiences on Apple platforms.

And beginning next month, you’ll be able to bring the incredible new features of Apple Intelligence into your apps to help inspire the way users communicate, work, and express themselves.

Starting April 2025, apps uploaded to App Store Connect must be built with SDKs for iOS 18, iPadOS 18, tvOS 18, visionOS 2, or watchOS 11.

Learn about submitting apps

Get your apps ready by digging into these video sessions and resources.

Explore machine learning on Apple platforms Watch now Bring expression to your app with Genmoji Watch now Browse new resources

Learn how to make actions available to Siri and Apple Intelligence.

• Ebook actions
• Camera actions
• Presentation actions

Need a boost?

Check out our curated guide to machine learning and AI.

FEATURED

Get ready for OS updates

Dive into the latest updates with these developer sessions.

Level up your games Port advanced games to Apple platforms Watch now Design advanced games for Apple platforms Watch now Bring your vision to life Design great visionOS apps Watch now Design interactive experiences for visionOS Watch now Upgrade your iOS and iPadOS apps Extend your app’s controls across the system Watch now Elevate your tab and sidebar experience in iPadOS Watch now

Browse Apple Developer on YouTube

Get expert guidance

Check out curated guides to the latest features and technologies.

• Games
• visionOS
• iOS and iPadOS

BEHIND THE DESIGN

Rytmos: A puzzle game with a global beat

Find out how Floppy Club built an Apple Design Award winner that sounds as good as it looks.

Behind the Design: The rhythms of Rytmos View now

MEET WITH APPLE

Reserve your spot for upcoming developer activities

• Envision the future: Create great apps for visionOS: Find out how to build visionOS apps for a variety of use cases. (October 2, Cupertino)
• Build faster and more efficient apps: Learn how to optimize your use of Apple frameworks, resolve performance issues, and reduce launch time. (October 23, Cupertino)

Subscribe to Hello Developer

Want to get Hello Developer in your inbox? Make sure you’ve opted in to receive emails about developer news and events by updating your email preferences in your developer account.

Share your thoughts

We’d love to hear from you. If you have suggestions for our activities or stories, please let us know.

Rytmos is a game that sounds as good as it looks.

With its global rhythms, sci-fi visuals, and clever puzzles, the 2024 Apple Design Award winner for Interaction is both a challenge and an artistic achievement. To solve each level, players must create linear pathways on increasingly complex boards, dodging obstacles and triggering buttons along the way. It’s all set to a world-music backdrop; different levels feature genres as diverse as Ethiopian jazz, Hawaiian slack key guitar, and Gamelan from Indonesia, just to name a few.

And here’s the hook: Every time you clear a level, you add an instrument to an ever-growing song.

“The idea is that instead of reacting to the music, you’re creating it,” says Asger Strandby, cofounder of Floppy Club, the Denmark-based studio behind Rytmos. “We do a lot to make sure it doesn’t sound too wild. But the music in Rytmos is entirely generated by the way you solve the puzzles.”

ADA FACT SHEET

Rytmos

• Winner: Interaction
• Team: Floppy Club
• Available on: iPhone, iPad
• Team size: 5

Learn more about Rytmos

Download Rytmos from the App Store

The artful game is the result of a partnership that dates back decades. In addition to being developers, Strandby and Floppy Club cofounder Niels Böttcher are both musicians who hail from the town of Aarhus in Denmark. “It’s a small enough place that if you work in music, you probably know everyone in the community,” laughs Böttcher.

The music in Rytmos comes mostly from traveling and being curious.

Niels Böttcher, Floppy Club cofounder

The pair connected back in the early 2000s, bonding over music more than games. “For me, games were this magical thing that you could never really make yourself,” says Strandby. “I was a geeky kid, so I made music and eventually web pages on computers, but I never really thought I could make games until I was in my twenties.” Instead, Strandby formed bands like Analogik, which married a wild variety of crate-digging samples — swing music, Eastern European folk, Eurovision-worthy pop — with hip-hop beats. Strandby was the frontman, while Böttcher handled the behind-the-scenes work. “I was the manager in everything but name,” he says.

The band was a success: Analogik went on to release five studio albums and perform at Glastonbury, Roskilde, and other big European festivals. But when their music adventure ended, the pair moved back into separate tech jobs for several years — until the time came to join forces again. “We found ourselves brainstorming one day, thinking about, ‘Could we combine music and games in some way?’” says Böttcher. “There are fun similarities between the two in terms of structures and patterns. We thought, ‘Well, let’s give it a shot.’”

Puzzles in Rytmos — like the one set on the planet “Hateta” — come with a little history lesson about the music being played.

The duo launched work on a rhythm game that was powered by their histories and travels. “I’ve collected CDs and tapes from all over the world, so the genres in Rytmos are very carefully chosen,” says Böttcher. “We really love Ethiopian jazz music, so we included that. Gamelan music (traditional Indonesian ensemble music that’s heavy on percussion) is pretty wild, but incredible. And sometimes, you just hear an instrument and say, ‘Oh, that tabla has a really nice sound.’ So the music in Rytmos comes mostly from traveling and being curious.”

The game took shape early, but the mazes in its initial versions were much more intricate. To help bring them down to a more approachable level, the Floppy Club team brought on art director Niels Fyrst. “He was all about making things cleaner and clearer,” says Böttcher. “Once we saw what he was proposing — and how it made the game stronger — we realized, ‘OK, maybe we’re onto something.’”

Success in Rytmos isn't just that you're beating a level. It's that you're creating something.

Asger Strandby, Floppy Club cofounder

Still, even with a more manageable set of puzzles, a great deal of design complexity remained. Building Rytmos levels was like stacking a puzzle on a puzzle; the team not only had to build out the levels, but also create the music to match. To do so, Strandby and his brother, Bo, would sketch out a level and then send it over to Böttcher, who would sync it to music — a process that proved even more difficult than it seems.

“The sound is very dependent on the location of the obstacles in the puzzles,” says Strandby. “That’s what shapes the music that comes out of the game. So we’d test and test again to make sure the sound didn’t break the idea of the puzzle.”

Puzzles in Rytmos are all about getting from Point A to Point B — but things are never as simple as they seem.

The process, he says, was “quite difficult” to get right. “Usually with something like this, you create a loop, and then maybe add another loop, and then add layers on top of it,” says Böttcher. “In Rytmos, hitting an emitter triggers a tone, percussion sound, or chord. One tone hits another tone, and then another, and then another. In essence, you’re creating a pattern while playing the game.”

We’ve actually gone back to make some of the songs more imprecise, because we want them to sound human.

Niels Böttcher, Floppy Club cofounder

The unorthodox approach leaves room for creativity. “Two different people’s solutions can sound different,” says Strandby. And when players win a level, they unlock a “jam mode” where they can play and practice freely. "It’s just something to do with no rules after all the puzzling,” laughs Strandby.

Yet despite all the technical magic happening behind the scenes, the actual musical results had to have a human feel. “We’re dealing with genres that are analog and organic, so they couldn’t sound electronic at all,” says Böttcher. “We’ve actually gone back to make some of the songs more imprecise, because we want them to sound human.”

Best of all, the game is shot through with creativity and cleverness — even offscreen. Each letter in the Rytmos logo represents the solution to a puzzle. The company’s logo is a 3.5-inch floppy disk, a little nod to their first software love. (“That’s all I wished for every birthday,” laughs Böttcher.) And both Böttcher and Strandby hope that the game serves as an introduction to both sounds and people they might not be familiar with. "Learning about music is a great way to learn about a culture,” says Strandby.

But mostly, Rytmos is an inspirational experience that meets its lofty goal. “Success in Rytmos isn’t just that you’re beating a level,” says Strandby. “It’s that you’re creating something.”

Meet the 2024 Apple Design Award winners

Behind the Design is a series that explores design practices and philosophies from finalists and winners of the Apple Design Awards. In each story, we go behind the screens with the developers and designers of these award-winning apps and games to discover how they brought their remarkable creations to life.

The App Store is designed to make it easy to sell your digital goods and services globally, with support for 44 currencies across 175 storefronts.

From time to time, we may need to adjust prices or your proceeds due to changes in tax regulations or foreign exchange rates. These adjustments are made using publicly available exchange rate information from financial data providers to help make sure prices for apps and In-App Purchases stay consistent across all storefronts.

Price updates

On September 16:

• Pricing for apps and In-App Purchases¹ will be updated for the Chile, Laos, and Senegal storefronts if you haven’t selected one of these as the base for your app or In‑App Purchase.¹ These updates also consider value‑added tax (VAT) introductions listed in the “Tax updates” section below.

If you’ve selected the Chile, Laos, or Senegal storefront as the base for your app or In-App Purchase, prices won’t change. On other storefronts, prices will be updated to maintain equalization with your chosen base price.

Prices won’t change in any region if your In‑App Purchase is an auto‑renewable subscription and won’t change on the storefronts where you manually manage prices instead of using the automated equalized prices.

The Pricing and Availability section of Apps has been updated in App Store Connect to display these upcoming price changes. As always, you can change the prices of your apps, In‑App Purchases, and auto‑renewable subscriptions at any time.

Learn more about managing your prices

View or edit upcoming price changes

Edit your app’s base country or region

Pricing and availability start times by region

Set a price for an In-App Purchase

Tax updates

As of August 29:

Your proceeds from the sale of eligible apps and In‑App Purchases have been modified in:

• Laos: VAT introduction of 10%
• Senegal: VAT introduction of 18%
• India: Equalization levy of 2% no longer applicable

Exhibit B of the Paid Applications Agreement has been updated to indicate that Apple collects and remits applicable taxes in Laos and Senegal.

Beginning in September:

Your proceeds from the sale of eligible apps and In‑App Purchases will be modified in:

• Canada: Digital services tax introduction of 3%
• Finland: VAT increase from 24% to 25.5%

Learn more about your proceeds

View payments and proceeds

Download financial reports

1: Excludes auto-renewable subscriptions.

Join us for a special Apple Event on September 9 at 10 a.m. PT.

Watch on apple.com, Apple TV, or YouTube Live.

By the end of this year, we’ll make changes to the browser choice screen, default apps, and app deletion for iOS and iPadOS for users in the EU. These updates come from our ongoing and continuing dialogue with the European Commission about compliance with the Digital Market Act’s requirements in these areas.

Developers of browsers offered in the browser choice screen in the EU will have additional information about their browser shown to users who view the choice screen, and will get access to more data about the performance of the choice screen. The updated choice screen will be shown to all EU users who have Safari set as their default browser. For details about the changes coming to the browser choice screen, view About the browser choice screen in the EU.

For users in the EU, iOS 18 and iPadOS 18 will also include a new Default Apps section in Settings that lists defaults available to each user. In future software updates, users will get new default settings for dialing phone numbers, sending messages, translating text, navigation, managing passwords, keyboards, and call spam filters. To learn more, view Update on apps distributed in the European Union.

Additionally, the App Store, Messages, Photos, Camera, and Safari apps will now be deletable for users in the EU.

As a reminder, Account Holders or Admins in the Apple Developer Program need to enter trader status in App Store Connect for apps on the App Store in the European Union (EU) in order to comply with the Digital Services Act.

Please note these new dates and requirements:

• October 16, 2024: Trader status will be required to submit app updates. If you’re a trader, you’ll need to provide your trader information before you can submit your app for review.
• February 17, 2025: Apps without trader status will be removed from the App Store in the EU until trader status is provided and verified.

Learn what a trader is and how to enter your status

Apple Entrepreneur Camp supports underrepresented founders and developers, and encourages the pipeline and longevity of these entrepreneurs in technology. Attendees benefit from one-on-one code-level guidance, receive unprecedented access to Apple engineers and experts, and become part of the extended global network of Apple Entrepreneur Camp alumni.

Applications are now open for female,* Black, Hispanic/Latinx, and Indigenous founders and developers. And this year we’re thrilled to bring back our in-person programming at Apple in Cupertino. For those who can’t attend in person, we’re still offering our full program online. We welcome established entrepreneurs with app-driven businesses to learn more about eligibility requirements and apply today.

Apply by September 3, 2024.

Learn more

* Apple believes that gender expression is a fundamental right. We welcome all women to apply to this program.

In response to the announcement by the European Commission in June, we’re making the following changes to Apple’s Digital Markets Act compliance plan. We’re introducing updated terms that will apply this fall for developers with apps in the European Union storefronts of the App Store that use the StoreKit External Purchase Link Entitlement. Key changes include:

• Developers can communicate and promote offers for purchases available at a destination of their choice. The destination can be an alternative app marketplace, another app, or a website, and it can be accessed outside the app or via a web view that appears in the app.
• Developers may design and execute within their apps the communication and promotion of offers. This includes providing information about prices of subscriptions or any other offer available both within or outside the app, and providing explanations or instructions about how to subscribe to offers outside the application. These communications must provide accurate information regarding the digital goods or services available for purchase.
• Developers may choose to use an actionable link that can be tapped, clicked, or scanned, to take users to their destination.
• Developers can use any number of URLs, without declaring them in the app’s Info.plist.
• Links with parameters, redirects, and intermediate links to landing pages are permitted.
• Updated business terms for apps with the External Purchase Link Entitlement are being introduced to align with the changes to these capabilities.

Learn more by visiting Alternative payment options on the App Store in the European Union or request a 30-minute online consultation to ask questions and provide feedback about these changes.

Meet with Apple

Explore the latest developer activities — including sessions, consultations, and labs — all around the world.

Browse the full schedule >

BEHIND THE DESIGN

Creating the make-believe magic of Lost in Play

Discover how the developers of this Apple Design Award-winning game conjured up an imaginative world of oversized frogs, mischievous gnomes, and occasional pizzas.

Behind the Design: Creating the make-believe magic of Lost in Play View now Get resourceful

• Build local experiences with room tracking: Use room tracking in visionOS to provide custom interactions with physical spaces.
• Preview your app’s interface in Xcode: Iterate designs quickly and preview your apps’ displays across different Apple devices.

News snippets

• Explore Apple Music Feed: Now available through the Apple Developer Program, Apple Music Feed provides bulk rich catalog metadata for developing experiences that link back to Apple Music.
• Updates to runtime protection in macOS Sequoia: Find out about updates to Gatekeeper.
• Evaluate your app’s performance: Find out what’s working — and what you can improve — with peer group benchmark metrics across app categories, business models, and download volumes.

SESSION OF THE MONTH

Extend your Xcode Cloud workflows

Discover how Xcode Cloud can adapt to your development needs.

Extend your Xcode Cloud workflows Watch now Subscribe to Hello Developer

Want to get Hello Developer in your inbox? Make sure you’ve opted in to receive emails about developer news and events by updating your email preferences in your developer account.

Share your thoughts

We’d love to hear from you. If you have suggestions for our activities or stories, please let us know.

Lost in Play is a game created by and for people who love to play make-believe.

The 2024 Apple Design Award (ADA) winner for Innovation is a point-and-click adventure that follows two young siblings, Toto and Gal, through a beautifully animated world of forbidden forests, dark caverns, friendly frogs, and mischievous gnomes. To advance through the game’s story, players complete fun mini-games and puzzles, all of which feel like a Saturday morning cartoon: Before the journey is out, the pair will fetch a sword from a stone, visit a goblin village, soar over the sea on an enormous bird, and navigate the real-world challenges of sibling rivalry. They will also order several pizzas.

ADA FACT SHEET

Lost in Play

• Winner: Innovation
• Team: Happy Juice Games, Israel
• Available on: iPhone, iPad
• Team size: 7
• Previous accolades: iPad Game of the Year (2023)

Download Lost in Play

Learn more about Lost in Play

Lost in Play is the brainchild of Happy Juice Games, a small Israel-based team whose three cofounders drew inspiration from their own childhoods — and their own families. “We’ve all watched our kids get totally immersed playing make-believe games,” says Happy Juice’s Yuval Markovich. “We wanted to recreate that feeling. And we came up with the idea of kids getting lost, partly in their imaginations, and partly in real life.”

The team was well-equipped for the job. Happy Juice cofounders Markovich, Oren Rubin, and Alon Simon, all have backgrounds in TV and film animation, and knew what they wanted a playful, funny adventure even before drawing their first sketch. “As adults, we can forget how to enjoy simple things like that,” says Simon, “so we set out to make a game about imagination, full of crazy creatures and colorful places.”

Toto meets a new friend in the belly of a whale in Lost in Play. At right is an early sketch of the scene.

For his part, Markovich didn’t just have a history in gaming; he taught himself English by playing text-based adventure games in the ‘80s. “You played those games by typing ‘go north’ or ‘look around,’ so every time I had to do something, I’d open the dictionary to figure out how to say it,” he laughs. “At some point I realized, ‘Oh wait, I know this language.’”

The story became a matter of, ‘OK, a goblin village sounds fun — how do we get there?’

Yuval Markovich, Happy Juice Games cofounder

But those games could be frustrating, as anyone who ever tried to “leave house” or “get ye flask” can attest. Lost in Play was conceived from day one to be light and navigable. “We wanted to keep it comic, funny, and easy,” says Rubin. “That’s what we had in mind from the very beginning.”

Toto must go out on a limb to solve the ravens' puzzle in this screenshot and early sketch.

Lost in Play may be a linear experience — it feels closer to playing a movie than a sandbox game — but it’s hardly simple. As befitting a playable dream, its story feels a little unmoored, like it’s being made up on the fly. That’s because the team started with art, characters, and environments, and then went back to add a hero’s journey to the elements.

“We knew we’d have a dream in the beginning that introduced a few characters. We knew we’d end up back at the house. And we knew we wanted one scene under the sea, and another in a maker space, and so on,” says Markovich. “The story became a matter of, ‘OK, a goblin village sounds fun — how do we get there?’”

Early concept sketches show the character design evolution of Toto and Gal.

Naturally, the team drew on their shared backgrounds in animation to shape the game all throughout its three-year development process — and not just in terms of art. Like a lot of cartoons, Lost in Play has no dialogue, both to increase accessibility and to enhance the story’s illusion. Characters speak in a silly gibberish. And there are little cartoon-inspired tricks throughout; for instance, the camera shakes when something is scary. “When you study animation, you also study script writing, cinematography, acting, and everything else,” Markovich says. “I think that’s why I like making games so much: They have everything.”

The best thing we hear is that it’s a game parents enjoy playing with their kids.

Oren Rubin, Happy Juice games cofounder

And in a clever acknowledgment of the realities of childhood, brief story beats return Toto and Gal to the real world to navigate practical issues like sibling rivalries. That’s on purpose: Simon says early versions of the game were maybe a little too cute. “Early on, we had the kids sleeping neatly in their beds,” says Simon. “But we decided that wasn’t realistic. We added a bit more of them picking on each other, and a conflict in the middle of the game.” Still, Markovich says that even the real-world interludes keep one foot in the imaginary world. “They may go through a park where an old lady is feeding pigeons, but then they walk left and there’s a goblin in a swamp,” he laughs.

Strange frogs distributing swords are the basis for one of Lost in Play's many inventive puzzles.

On the puzzle side, Lost in Play’s mini-games are designed to strike the right level of challenging. The team is especially proud of the game’s system of hints, which often present challenges in themselves. “We didn’t want people getting trapped like I did in those old adventure games,” laughs Markovich. “I loved those, but you could get stuck for months. And we didn’t want people going online to find answers either.” The answer: A hint system that doesn’t just hand over the answer but gives players a feeling of accomplishment, an incentive to go back for more.

It all adds up to a unique experience for players of all ages — and that’s by design too. “The best feedback we get is that it’s suitable for all audiences,” says Rubin, “and the best thing we hear is that it’s a game parents enjoy playing with their kids.”

Meet the 2024 Apple Design Award winners

Behind the Design is a series that explores design practices and philosophies from finalists and winners of the Apple Design Awards. In each story, we go behind the screens with the developers and designers of these award-winning apps and games to discover how they brought their remarkable creations to life.

In macOS Sequoia, users will no longer be able to Control-click to override Gatekeeper when opening software that isn’t signed correctly or notarized. They’ll need to visit System Settings > Privacy & Security to review security information for software before allowing it to run.

If you distribute software outside of the Mac App Store, we recommend that you submit your software to be notarized. The Apple notary service automatically scans your Developer ID-signed software and performs security checks. When your software is ready for distribution, it’s assigned a ticket to let Gatekeeper know it’s been notarized so customers can run it with confidence.

Learn how to notarize your macOS software

The App Review Guidelines have been revised to support updated policies and upcoming features, and to provide clarification.

• Updated 4.7 to clarify that PC emulator apps can offer to download games.
• Added 4.7, 4.7.2, and 4.7.3 to Notarization.

View the App Review Guidelines

Get resources and support to prepare for App Review

Translations of the guidelines will be available on the Apple Developer website within one month.

Dive into all the new updates from WWDC24

Our doors are open. Join us to explore all the new sessions, documentation, and features through online and in-person activities held in 15 cities around the world.

Sign up now >

Join us July 22–26 for online office hours to get one-on-one guidance about your app or game. And visit the forums where more engineers are ready to answer your questions.

Reserve your spot >

Browse the forums >

WWDC24 highlights View now

BEHIND THE DESIGN

Positive vibrations: How Gentler Streak approaches fitness with “humanity”

Find out why the team behind this Apple Design Award-winning lifestyle app believes success is about more than stats.

Behind the Design: How Gentler Streak approaches fitness with “humanity“ View now

GET RESOURCEFUL

New sample code

• Grow your skills with the BOT-anist: Build a multiplatform app that uses windows, volumes, and animations to create a robot botanist’s greenhouse.
• Doing the things a particle can: Add a range of visual effects to a RealityKit view by attaching a particle emitter component to an entity.
• Chart a course for Destination Video: Leverage SwiftUI to build an immersive media experience.

New in the HIG

• Design for games: Make your game feel at home on all Apple devices.
• Take control of controls: Provide quick access to a feature of your app from Control Center, the Lock Screen, or the Action button.
• Tint your icons: Create dark and tinted app icon variants for iOS and iPadOS.

SESSION OF THE MONTH

Say hello to the next generation of CarPlay design system

Learn how the system at the heart of CarPlay allows each automaker to express their vehicle’s character and brand.

Say hello to the next generation of CarPlay design system Watch now Subscribe to Hello Developer

Want to get Hello Developer in your inbox? Make sure you’ve opted in to receive emails about developer news and events by updating your email preferences in your developer account.

Share your thoughts

We’d love to hear from you. If you have suggestions for our activities or stories, please let us know.

Gentler Streak is a different kind of fitness tracker. In fact, to hear cofounder and CEO Katarina Lotrič tell it, it’s not really a fitness tracker at all.

“We think of it more as a lifestyle app,” says Lotrič, from the team’s home office in Kranj, Slovenia. “We want it to feel like a compass, a reminder to get moving, no matter what that means for you,” she says.

ADA FACT SHEET

The app’s “Go Gentler” page suggests optimal workouts for a user’s day.

Gentler Streak

• Winner: Social Impact
• Team: Gentler Stories d.o.o., Slovenia
• Available on: iPhone, iPad, Apple Watch
• Team size: 8
• Previous accolades: Apple Watch App of the Year (2022), Apple Design Award finalist (Visuals and graphics, 2023)

Download Gentler Streak from the App Store

Learn more about Gentler Streak

Meet the 2024 Apple Design Award winners

That last part is key. True to its name, the Apple Design Award-winning Gentler Streak takes a friendlier approach to fitness. Instead of focusing on performance — on the bigger, faster, and stronger — Gentler Streak meets people where they are, presenting workout suggestions, statistics, and encouragement for all skill levels.

“A lot of mainstream fitness apps can seem to be about pushing all the time,” Lotrič says. “But for a lot of people, that isn’t the reality. Everyone has different demands and capabilities on different days. We thought, ‘Can we create a tool to help anyone know where they’re at on any given day, and guide them to a sustainably active lifestyle?’”

If a 15-minute walk is what your body can do at that moment, that’s great.

Katarina Lotrič, CEO and cofounder of Gentler Stories

To reach those goals, Lotrič and her Gentler Stories cofounders — UI/UX designer Andrej Mihelič, senior developer Luka Orešnik, and CTO and iOS developer Jasna Krmelj — created an app powered by an optimistic and encouraging vibe that considers physical fitness and mental well-being equally.

Fitness and workout data (collected from HealthKit) is presented in a colorful, approachable design. The app’s core functions are available for free; a subscription unlocks premium features. And an abstract mascot named Yorhart (sound it out) adds to the light touch. “Yorhart helps you establish a relationship with the app and with yourself, because it’s what your heart would be telling you,” Lotrič says.

Good news from Yorhart: This user’s needs and capabilities are being met perfectly.

It’s working: In addition to the 2024 Apple Design Award for Social Impact, Gentler Streak was named 2022 Apple Watch App of the Year. What’s more, it has an award-winning ancestor: Lotrič and Orešnik won an Apple Design Award in 2017 for Lake: Coloring Book for Adults.

The trio used the success of Lake to learn more about navigating the industry. But something else was happening during that time: The team, all athletes, began revisiting their own relationships with fitness. Lotrič suffered an injury that kept her from running for months and affected her mental health; she writes about her experiences in Gentler Streak’s editorial section. Mihelič had a different issue. “My problem wasn’t that I lacked motivation,” he says. “It was that I worked out too much. I needed something that let me know when it was enough.”

Statistics are just numbers. Without knowing how to interpret them, they are meaningless.

Katarina Lotrič, CEO and cofounder of Gentler Stories

As a way to reset, Mihelič put together an internal app, a simple utility that encouraged him to move but also allowed time for recuperation. “It wasn’t very gentle,” he laughs. “But the core idea was more or less the same. It guided but it didn’t push. And it wasn’t based on numbers; it was more explanatory.”

Over time, the group began using Mihelič’s app. “We saw right away that it was sticky,” says Lotrič. “I came back to it daily, and it was just this basic prototype. After a while, we realized, ‘Well, this works and is built, to an extent. Why don’t we see if there’s anything here?’”

Gentler Streak pulls workout information from HealthKit and presents it in simple, easy-to-understand charts.

That’s when Lotrič, Orešnik, and Krmelj split from Lake to create Gentler Stories with Mihelič. "I wanted in because I loved the idea behind the whole company,” Krmelj says. “It wasn’t just about the app. I really like the app. But I really believed in this idea about mental well-being.”

Early users believed it too: The team found that initial TestFlight audience members returned at a stronger rate than expected. “Our open and return rates were high enough that we kept thinking, “Are these numbers even real?’” laughs Lotrič. The team found that those early users responded strongly to the “gentler” side, the approachable repositioning of statistics.

“We weren’t primarily addressing the audience that most fitness apps seemed to target,” says Lotrič. “We focused on everyone else, the people who maybe didn’t feel like they belonged in a gym. Statistics are just numbers. Without knowing how to interpret them, they are meaningless. We wanted to change that and focus on the humanity.” By fall of 2021, Gentler Streak was ready for prime time.

Gentler Streak on Apple Watch brings encouragement closer than ever before.

Today’s version of the app follows the same strategy of Mihelič’s original prototype. Built largely in UIKit, its health data is smartly organized, the design is friendly and consistent, and features like its Monthly Summary view — which shows how you’re doing in relation to your history — focus less on comparison and more on progress, whatever that may mean. “If a 15-minute walk is what your body can do at that moment, that’s great,” Lotrič says. “That how we make people feel represented.”

The app’s social impact continues to grow. In the spring of 2024, Gentler Streak added support for Japanese, Korean, and traditional and simplified Chinese languages; previous updates added support for French, German, Italian, Spanish, and Brazilian Portuguese.

And those crucial features — fitness tracking, workout suggestions, metrics, and activity recaps — will remain available to everyone. “That goes with the Gentler Stories philosophy,” says Lotrič. “We’re bootstrapped, but at the same time we know that not everyone is in a position to support us. We still want to be a tool that helps people stay healthy not just for the first two weeks of the year or the summer, but all year long.”

Meet the 2024 Apple Design Award winners

Behind the Design is a series that explores design practices and philosophies from finalists and winners of the Apple Design Awards. In each story, we go behind the screens with the developers and designers of these award-winning apps and games to discover how they brought their remarkable creations to life.

Alternative payment options are now supported starting in visionOS 1.2 for apps distributed on the App Store in the EU.

Learn about alternative payments in the EU

The changes for apps in the European Union (EU), currently available to iOS users in the 27 EU member countries, can now be tested in iPadOS 18 beta 2 with Xcode 16 beta 2.

Also, the Web Browser Engine Entitlement Addendum for Apps in the EU and Embedded Browser Engine Entitlement Addendum for Apps in the EU now include iPadOS. If you’ve already entered into either of these addendums, be sure to sign the updated terms.

Learn more about the recent changes:

• Web Distribution
• Alternative marketplaces
• Alternative browser engines

Apple Vision Pro will launch in China mainland, Hong Kong, Japan, and Singapore on June 28 and in Australia, Canada, France, Germany, and the United Kingdom on July 12. Your apps and games will be automatically available on the App Store in regions you’ve selected in App Store Connect.

If you’d like, you can:

• Manage the availability of your visionOS apps and compatible iPhone or iPad apps at any time.
• Request to have your app evaluated directly on Apple Vision Pro.
• Localize your product page metadata for local audiences.

You can also learn how to build native apps to fully take advantage of exciting visionOS features.

Apple is committed to making sure that the App Store is a safe place for everyone — especially kids. Within the next few months, you’ll need to indicate in App Store Connect if your app includes loot boxes available for purchase. In addition, a regional age rating based on local laws will automatically appear on the product page of the apps listed below on the App Store in Australia and South Korea. No other action is needed. Regional age ratings appear in addition to Apple global age ratings.

Australia

A regional age rating is shown if Games is selected as the primary or secondary category in App Store Connect.

• 15+ regional age rating: Games with loot boxes available for purchase.
• 18+ regional age rating: Games with Frequent/Intense instances of Simulated Gambling indicated in App Store Connect.

South Korea

A regional age rating is shown if either Games or Entertainment is selected as the primary or secondary category in App Store Connect, or if the app has Frequent/Intense instances of Simulated Gambling in any category.

• KR-All regional age rating: Apps and games with an Apple global age rating of 4+ or 9+.
• KR-12 regional age rating: Apps and games with an Apple global age rating of 12+. Certain apps and games in this group may receive a KR-15 regional age rating from the South Korean Games Ratings and Administration Committee (GRAC). If this happens, App Review will reach out to impacted developers.
• Certain apps and games may receive a KR-19 regional age rating from the GRAC. Instead of a pictogram, text will indicate this rating.

Thank you to everyone who joined us for an amazing week. We hope you found value, connection, and fun. You can continue to:

• Watch sessions at any time.
• Check out session highlights.
• Read about newly announced technologies.
• Get sample code from sessions.
• Dive into new and updated documentation.

We’d love to know what you thought of this year’s conference. If you’d like to tell us about your experience, please complete the WWDC24 survey.

Take the survey

Browse the biggest moments from an incredible week of sessions.

Machine Learning & AI Explore machine learning on Apple platforms Watch now Bring expression to your app with Genmoji Watch now Get started with Writing Tools Watch now Bring your app to Siri Watch now Design App Intents for system experiences Watch now Swift What’s new in Swift Watch now Meet Swift Testing Watch now Migrate your app to Swift 6 Watch now Go small with Embedded Swift Watch now SwiftUI & UI Frameworks What’s new in SwiftUI Watch now SwiftUI essentials Watch now Enhance your UI animations and transitions Watch now Evolve your document launch experience Watch now Squeeze the most out of Apple Pencil Watch now Developer Tools What’s new in Xcode 16 Watch now Extend your Xcode Cloud workflows Watch now Spatial Computing Design great visionOS apps Watch now Design interactive experiences for visionOS Watch now Explore game input in visionOS Watch now Bring your iOS or iPadOS game to visionOS Watch now Create custom hover effects in visionOS Watch now Work with windows in SwiftUI Watch now Dive deep into volumes and immersive spaces Watch now Customize spatial Persona templates in SharePlay Watch now Design Design great visionOS apps Watch now Design interactive experiences for visionOS Watch now Design App Intents for system experiences Watch now Design Live Activities for Apple Watch Watch now Say hello to the next generation of CarPlay design system Watch now Add personality to your app through UX writing Watch now Graphics & Games Port advanced games to Apple platforms Watch now Design advanced games for Apple platforms Watch now Bring your iOS or iPadOS game to visionOS Watch now Meet TabletopKit for visionOS Watch now App Store Distribution and Marketing What’s new in StoreKit and In-App Purchase Watch now What’s new in App Store Connect Watch now Implement App Store Offers Watch now Privacy & Security Streamline sign-in with passkey upgrades and credential managers Watch now What’s new in privacy Watch now App and System Services Meet the Contact Access Button Watch now Use CloudKit Console to monitor and optimize database activity Watch now Extend your app’s controls across the system Watch now Safari & Web Optimize for the spatial web Watch now Build immersive web experiences with WebXR Watch now Accessibility & Inclusion Catch up on accessibility in SwiftUI Watch now Get started with Dynamic Type Watch now Build multilingual-ready apps Watch now Photos & Camera Build a great Lock Screen camera capture experience Watch now Build compelling spatial photo and video experiences Watch now Keep colors consistent across captures Watch now Use HDR for dynamic image experiences in your app Watch now Audio & Video Enhance the immersion of media viewing in custom environments Watch now Explore multiview video playback in visionOS Watch now Build compelling spatial photo and video experiences Watch now Business & Education Introducing enterprise APIs for visionOS Watch now What’s new in device management Watch now Health & Fitness Explore wellbeing APIs in HealthKit Watch now Build custom swimming workouts with WorkoutKit Watch now Get started with HealthKit in visionOS Watch now

Revisit the biggest moments from WWDC24

Explore the highlights.

WWDC24 highlights View now Catch WWDC24 recaps around the world

Join us for special in-person activities at Apple locations worldwide this summer.

Sign up >

Explore apps and games from the Keynote

Check out all the incredible featured titles.

Visit the App Store >

How’d we do?

We’d love to know your thoughts about this year’s conference.

Take the survey >

Today’s WWDC24 playlist: Power Up

Get ready for one last day.

Listen on Apple Music >

And that’s a wrap!

Thanks for being part of another incredible WWDC. It’s been a fantastic week of celebrating, connecting, and exploring, and we appreciate the opportunity to share it all with you.

Plan for platforms

Find out what’s new across Apple platforms.

Design great visionOS apps Watch now Bring your iOS or iPadOS game to visionOS Watch now Design App Intents for system experiences Watch now Explore all platforms sessions

• Watch on the Apple Developer app and website
• Watch on YouTube

Guides

Sessions, labs, documentation, and sample code — all in one place.

WWDC24 iOS & iPadOS guide View now WWDC24 Games guide View now WWDC24 visionOS guide View now WWDC24 watchOS guide View now Today’s WWDC24 playlist: Coffee Shop

Comfy acoustic sounds for quieter moments.

Listen on Apple Music >

One more to go

What a week! But we’re not done yet — we’ll be back tomorrow for a big Friday. #WWDC24

All Swift, all day

Explore new Swift and SwiftUI sessions.

What’s new in Swift Watch now What’s new in SwiftUI Watch now Meet Swift Testing Watch now Explore all Swift sessions

• Watch on the Apple Developer app and website
• Watch on YouTube

Guides

Sessions, labs, documentation, and sample code — all in one place.

WWDC24 Swift guide View now WWDC24 Developer Tools guide View now WWDC24 SwiftUI & UI Frameworks guide View now Go further with Swift

Connect with Apple experts and the worldwide developer community.

• Request a consultation in the WWDC labs.
• Explore the Apple Developer Forums.
• Connect with developers all over the world.

Today’s WWDC24 playlist: A jazz thing

Cutting-edge sounds from the global frontiers of jazz.

Listen on Apple Music >

More to come

Thanks for being a part of #WWDC24. We’ll be back tomorrow with even more.

Watch the Platforms State of the Union 5-minute recap

• Watch on the Apple Developer app and website
• Watch on YouTube

Explore everything announced at WWDC24 >

Introducing Apple Intelligence

Get smarter.

Explore machine learning on Apple platforms Watch now Get started with Writing Tools Watch now Bring your app to Siri Watch now Explore all Machine Learning and AI sessions

• Watch on the Apple Developer app and website
• Watch on YouTube

Guides

Sessions, labs, documentation, and sample code — all in one place.

WWDC24 Machine Learning & AI guide View now WWDC24 Design guide View now Go further with Apple Intelligence

• Request a consultation in the WWDC labs.
• Explore the Apple Developer Forums.
• Connect with developers all over the world.

Today’s WWDC24 playlist: Hello sunshine

Summer sounds to change your latitude.

Listen on Apple Music >

More tomorrow

Thanks for being a part of this incredible week. We’ll catch you tomorrow for another big day of technology and creativity. #WWDC24

Discover the latest advancements across Apple platforms, including the all-new Apple Intelligence, that can help you create even more powerful, intuitive, and unique experiences.

To start exploring and building with the latest features, download beta versions of Xcode 16, iOS 18, iPadOS 18, macOS 15, tvOS 18, visionOS 2, and watchOS 11.

Learn about installing beta software

Learn about sharing feedback

Browse new and updated documentation and sample code to learn about the latest technologies, frameworks, and APIs introduced at WWDC24.

Explore everything announced at WWDC24 >

WWDC24 GUIDE Design

Discover how this year’s design announcements can help make your app shine on Apple platforms.

Whether you’re refining your design, building for visionOS, or starting from scratch, this year’s design sessions can take your app to the next level on Apple platforms. Find out what makes a great visionOS app, and learn how to design interactive experiences for the spatial canvas. Dive into creating advanced games for Apple devices, explore the latest SF Symbols, learn how to add personality to your app through writing, and much more.

Get the highlights

Download the design one-sheet.

Download

VIDEOS

Explore the latest video sessions Design great visionOS apps Watch now Design advanced games for Apple platforms Watch now Create custom environments for your immersive apps in visionOS Watch now Explore game input in visionOS Watch now Design Live Activities for Apple Watch Watch now What’s new in SF Symbols 6 Watch now Design interactive experiences for visionOS Watch now Design App Intents for system experiences Watch now Build multilingual-ready apps Watch now Add personality to your app through UX writing Watch now Get started with Dynamic Type Watch now Create custom visual effects with SwiftUI Watch now

FORUMS

Find answers and get advice

Ask questions and get advice about design topics on the Apple Developer Forums.

Design

Spatial computing

COMMUNITY

Meet the community

Explore a selection of developer activities all over the world during and after WWDC.

Meet the community

RESOURCES

Explore the latest resources

• Get the latest Apple Design Resources kits and templates.
• Explore the latest SF Symbols.
• Download the fonts you need to design interfaces for your apps on Apple platforms.

Check out updates to the Human Interface Guidelines

• Find out all that’s new in the HIG.
• Designing for games: Explore an all-new way to start creating games that feel comfortable and intuitive on Apple platforms.
• Tab bars: iPadOS apps now give people the option to switch between a tab bar or sidebar when navigating their app. Plus, items in the tab bar can now be customized.
• App icons: Learn how people can customize their Home Screens to show dark and tinted icons.
• Controls: Discover how people can quickly and easily perform actions from your app from Control Center, the Lock Screen, and the Action button.
• Widgets: Learn how to tint widgets when a person has customized their Home Screen to show dark and tinted icons.
• Windows: Learn how to use volumes in visionOS to display 2D or 3D content that people can view from any angle.
• Live Activities: Craft Live Activities that look and feel at home in the Smart Stack in watchOS.
• Immersive experiences: Explore the latest guidance on immersion, including design environments and virtual hands.
• Game controls: Learn how to design touch controls for games on iOS and iPadOS.

WWDC24 GUIDE Swift

Your guide to everything new in Swift, related tools, and supporting frameworks.

From expanded support across platforms and community resources, to an optional language mode with an emphasis on data-race safety, this year’s Swift updates meet you where you are. Explore this year’s video sessions to discover everything that’s new in Swift 6, find tools that support migrating to the new language mode at your own pace, learn about new frameworks that support developing with Swift, and much more.

Get the highlights

Download the Swift one-sheet.

Download

VIDEOS

Explore the latest video sessions What’s new in Swift Watch now What’s new in SwiftData Watch now Migrate your app to Swift 6 Watch now Go small with Embedded Swift Watch now A Swift Tour: Explore Swift’s features and design Watch now Create a custom data store with SwiftData Watch now Explore the Swift on Server ecosystem Watch now Explore Swift performance Watch now Consume noncopyable types in Swift Watch now Track model changes with SwiftData history Watch now

FORUMS

Find answers and get advice

Find support from Apple experts and the developer community on the Apple Developer Forums, and check out the Swift Forums on swift.org.

Explore Swift on the Apple Developer Forums

Dive into the Swift Forums

COMMUNITY

Meet the community

Explore a selection of activities hosted by developer organizations during and after WWDC.

Meet the community

RESOURCES

Dive into Apple Developer documentation

• Discover new and updated Swift documentation
• Explore the Swift Standard Library

Discover Swift community resources

• Learn how to migrate your code to Swift 6
• Reference the Swift programming language guide
• Read A Swift Tour: An overview of the features and syntax of Swift
• Explore the new Swift-dedicated GitHub organization
• Learn more about the Swift Package Manager (SwiftPM)

WWDC24 GUIDE SwiftUI & UI Frameworks

Design and build your apps like never before.

With enhancements to live previews in Xcode, new customization options for animations and styling, and updates to interoperability with UIKit and AppKit views, SwiftUI is the best way to build apps for Apple platforms. Dive into the latest sessions to discover everything new in SwiftUI, UIKit, AppKit, and more. Make your app stand out with more options for custom visual effects and enhanced animations. And explore sessions that cover the essentials of building apps with SwiftUI.

Get the highlights

Download the SwiftUI one-sheet.

Download

VIDEOS

Explore the latest video sessions What’s new in SwiftUI Watch now What’s new in AppKit Watch now What’s new in UIKit Watch now SwiftUI essentials Watch now What’s new in watchOS 11 Watch now Swift Charts: Vectorized and function plots Watch now Elevate your tab and sidebar experience in iPadOS Watch now Bring expression to your app with Genmoji Watch now Squeeze the most out of Apple Pencil Watch now Catch up on accessibility in SwiftUI Watch now Migrate your TVML app to SwiftUI Watch now Get started with Writing Tools Watch now Dive deep into volumes and immersive spaces Watch now Work with windows in SwiftUI Watch now Enhance your UI animations and transitions Watch now Evolve your document launch experience Watch now Build multilingual-ready apps Watch now Create custom hover effects in visionOS Watch now Tailor macOS windows with SwiftUI Watch now Demystify SwiftUI containers Watch now Support semantic search with Core Spotlight Watch now Create custom visual effects with SwiftUI Watch now

FORUMS

Find answers and get advice

Connect with Apple experts and other developers on the Apple Developer Forums.

View discussions about SwiftUI & UI frameworks

COMMUNITY

Meet the community

Explore a selection of activities hosted by developer organizations during and after WWDC.

Meet the community

RESOURCES

Dive into documentation

• Level up the accessibility of your SwiftUI app.
• Interact with nearby points of interest.
• Build a document-based app with SwiftUI.
• Customize window styles and state-restoration behavior in macOS.
• Enhance your app’s content with tab navigation.
• Create visual effects with SwiftUI.
• Unify your app’s animations.
• Find all of this year’s SwiftUI, AppKit, and UIKit updates.
• Explore updates in the Human Interface Guidelines (HIG).

It all starts here

Keynote

The exciting reveal of the latest Apple software and technologies. 10 a.m. PT.

Keynote Watch now

Platforms State of the Union

The newest advancements on Apple platforms. 1 p.m. PT.

Platforms State of the Union Watch now

Where to watch

• Apple Developer app and website
• Apple Developer YouTube channel

Sessions drop today

The full lineup of sessions arrives after the Keynote. And you can start exploring the first batch right after the Platforms State of the Union.

Get ready for sessions >

What to do at WWDC24

The Keynote is only the beginning. Explore the first day of activities.

• Request your spot in the labs after the Keynote.
• Explore the Apple Developer Forums.
• Connect with developers all over the world.

Celebrate the 2024 Apple Design Award winners

The Apple Design Awards recognize unique achievements in app and game design — and provide a moment to step back and celebrate the innovations of the Apple developer community.

Meet this year’s winners >

More to come

Thanks for reading and get some rest! We’ll be back tomorrow for a very busy Day 2. #WWDC24

WWDC24 GUIDE Developer Tools

Explore a wave of updates to developer tools that make building apps and games easier and more efficient than ever.

Watch the latest video sessions to explore a redesigned code completion experience in Xcode 16, and say hello to Swift Assist — a companion for all your coding tasks. Level up your code with the help of Swift Testing, the new, easy-to-learn framework that leverages Swift features to help enhance your testing experience. Dive deep into debugging, updates to Xcode Cloud, and more.

Get the highlights

Download the developer tools one-sheet.

Download

VIDEOS

Explore the latest video sessions Meet Swift Testing Watch now What’s new in Xcode 16 Watch now Go further with Swift Testing Watch now Xcode essentials Watch now Run, Break, Inspect: Explore effective debugging in LLDB Watch now Break into the RealityKit debugger Watch now Demystify explicitly built modules Watch now Extend your Xcode Cloud workflows Watch now Analyze heap memory Watch now

FORUMS

Find answers and get advice

Find support from Apple experts and the developer community on the Apple Developer Forums.

Explore developer tools on the forums

COMMUNITY

Meet the community

Explore a selection of activities hosted by developer organizations during and after WWDC.

Meet the community

RESOURCES

Dive into documentation

Expand your tool belt with new and updated articles and documentation.

• Explore updates in Xcode 16
• Discover Swift Testing
• Migrate a test from XCTest
• Define test functions
• Organize test functions with suite types
• Implement parameterized tests
• Enable and disable tests
• Limit the running time of tests
• Add tags to tests
• Add comments to tests
• Associate bugs with tests
• Interpret bug identifiers

WWDC24 GUIDE iOS & iPadOS

Your guide to all the new features and tools for building apps for iPhone and iPad.

Learn how to create more customized and intelligent apps that appear in more places across the system with the latest Apple technologies. And with Apple Intelligence, you can bring personal intelligence into your apps to deliver new capabilities — all with great performance and built-in privacy. Explore new video sessions about controls, Live Activities, App Intents, and more.

Get the highlights

Download the iOS & iPadOS one-sheet.

Download

VIDEOS

Explore the latest video sessions Bring your app to Siri Watch now Discover RealityKit APIs for iOS, macOS, and visionOS Watch now Explore machine learning on Apple platforms Watch now Elevate your tab and sidebar experience in iPadOS Watch now Extend your app’s controls across the system Watch now Streamline sign-in with passkey upgrades and credential managers Watch now What’s new in App Intents Watch now Squeeze the most out of Apple Pencil Watch now Meet FinanceKit Watch now Bring your iOS or iPadOS game to visionOS Watch now Build a great Lock Screen camera capture experience Watch now Design App Intents for system experiences Watch now Bring your app’s core features to users with App Intents Watch now Broadcast updates to your Live Activities Watch now Unlock the power of places with MapKit Watch now Implement App Store Offers Watch now What’s new in Wallet and Apple Pay Watch now Meet the Contact Access Button Watch now What’s new in device management Watch now

FORUMS

Find answers and get advice

Connect with Apple experts and other developers on the Apple Developer Forums.

View discussions about iOS

View discussions about iPadOS

COMMUNITY

Meet the community

Explore a selection of activities hosted by developer organizations during and after WWDC.

Meet the community

RESOURCES

Get a head start with sample code

• AVCam — Building a camera app
• Configuring the PencilKit tool picker

Dive into documentation

• Discover WidgetKit for controls.
• Find out how to set up broadcast push notifications, send channel management requests to APNs, and send broadcast push notification requests to APNs.
• Check out the new LockedCameraCapture, Media Accessibility, AccessorySetupKit, and Contact Provider frameworks.
• Explore object tracking with ARKit.
• Learn how to elevate your iPad app with the tab sidebar, as well as with a floating tab bar and integrated sidebar, using SwiftUI or UIkit.

WWDC24 GUIDE Machine Learning & AI

Bring personal intelligence to your apps.

Apple Intelligence brings powerful, intuitive, and integrated personal intelligence to Apple platforms — designed with privacy from the ground up. And enhancements to our machine learning frameworks let you run and train your machine learning and artificial intelligence models on Apple devices like never before.

Get the highlights

Download the Machine Learning & AI one-sheet.

Download

VIDEOS

Explore the latest video sessions

Get the most out of Apple Intelligence by diving into sessions that cover updates to Siri integration and App Intents, and how to support Writing Tools and Genmoji in your app. And learn how to bring machine learning and AI directly into your apps using our machine learning frameworks.

Explore machine learning on Apple platforms Watch now Bring your app to Siri Watch now Bring your app’s core features to users with App Intents Watch now Bring your machine learning and AI models to Apple silicon Watch now Get started with Writing Tools Watch now Deploy machine learning and AI models on-device with Core ML Watch now Support real-time ML inference on the CPU Watch now Bring expression to your app with Genmoji Watch now What’s new in App Intents Watch now What’s new in Create ML Watch now Design App Intents for system experiences Watch now Discover Swift enhancements in the Vision framework Watch now Meet the Translation API Watch now Accelerate machine learning with Metal Watch now Train your machine learning and AI models on Apple GPUs Watch now

FORUMS

Find answers and get advice

Connect with Apple experts and other developers on the Apple Developer Forums.

Dive into Machine learning and AI on the forums

COMMUNITY

Meet the community

Explore a selection of activities hosted by developer organizations during and after WWDC.

Meet the community

RESOURCES

Dive into documentation

• Build a search interface for your app.
• Bring Writing Tools to your app with UITextView for UIKit and NSTextView for AppKit.
• Add expression to your app with Genmoji using NSAdaptiveImageGlyph in UIKit and AppKit.
• Integrate machine learning models into your app using Core ML.
• Create your own machine learning models using Create ML.
• Discover all of the latest Core ML updates.
• Find out what’s new in the Vision framework.

WWDC24 GUIDE Games

Create the next generation of games for millions of players worldwide.

Learn how to create cutting-edge gaming experiences across a unified gaming platform built with tightly integrated graphics software and a scalable hardware architecture. Explore new video sessions about gaming in visionOS, game input, the Game Porting Toolkit 2, and more.

Get the highlights

Download the games one-sheet.

Download

VIDEOS

Explore the latest video sessions Render Metal with passthrough in visionOS Watch now Meet TabletopKit for visionOS Watch now Port advanced games to Apple platforms Watch now Design advanced games for Apple platforms Watch now Explore game input in visionOS Watch now Bring your iOS or iPadOS game to visionOS Watch now Accelerate machine learning with Metal Watch now

FORUMS

Find answers and get advice

Connect with Apple experts and other developers on the Apple Developer Forums.

View discussions about games

COMMUNITY

Meet the community

Explore a selection of activities hosted by developer organizations during and after WWDC.

Meet the community

RESOURCES

Get a head start with sample code

• Creating tabletop games

Dive into documentation

• Check out updated design guidance for games.
• Easily bring your game to Apple platforms using the Game Porting Toolkit 2.
• Meet the new TabletopKit framework.
• Learn how to play sound from a location in a 3D scene.
• Learn how to manage your game window for Metal in macOS.
• Get details on adapting your game interface for smaller screens.
• Discover how to improve your game’s graphics performance and settings.
• Find out how to improve the player experience for games with large downloads.
• Explore adding touch controls to games that support game controllers.

WWDC24 GUIDE watchOS

Your guide to all the new features and tools for building apps for Apple Watch.

Learn how to take advantage of the increased intelligence and capabilities of the Smart Stack. Explore new video sessions about relevancy cues, interactivity, Live Activities, and double tap.

Get the highlights

Download the watchOS one-sheet.

Download

VIDEOS

Explore the latest video sessions What’s new in watchOS 11 Watch now Bring your Live Activity to Apple Watch Watch now What’s new in SwiftUI Watch now SwiftUI essentials Watch now Design Live Activities for Apple Watch Watch now Catch up on accessibility in SwiftUI Watch now Build custom swimming workouts with WorkoutKit Watch now Demystify SwiftUI containers Watch now

FORUMS

Find answers and get advice

Connect with Apple experts and other developers on the Apple Developer Forums.

View discussions about watchOS

COMMUNITY

Meet the community

Explore a selection of activities hosted by developer organizations during and after WWDC.

Meet the community

RESOURCES

Dive into documentation

• Discover double tap.
• Learn how to use the latest technologies to build apps for Apple Watch.
• Get updated guidance on design for Apple Watch.
• Visit the Apple Watch site.

WWDC24 is here! Here’s how to make the most of your week:

• Watch daily sessions.
• Request one-on-one online lab appointments with Apple experts.
• Check out curated guides to the week’s biggest announcements.
• Dive into new and updated documentation.

Learn more

WWDC24 GUIDE visionOS

The infinite canvas is waiting for you.

In this year’s sessions, you’ll get an overview of great visionOS app design, explore object tracking, and discover new RealityKit APIs. You’ll also find out how to build compelling spatial photo and video experiences, explore enterprise APIs for visionOS, find out how to render Metal with passthrough, and much more.

Get the highlights

Download the visionOS one-sheet.

Download

VIDEOS

Explore the latest video sessions Design great visionOS apps Watch now Explore object tracking for visionOS Watch now Compose interactive 3D content in Reality Composer Pro Watch now Discover RealityKit APIs for iOS, macOS, and visionOS Watch now Create enhanced spatial computing experiences with ARKit Watch now Enhance your spatial computing app with RealityKit audio Watch now Build compelling spatial photo and video experiences Watch now Meet TabletopKit for visionOS Watch now Render Metal with passthrough in visionOS Watch now Explore multiview video playback in visionOS Watch now Introducing enterprise APIs for visionOS Watch now Dive deep into volumes and immersive spaces Watch now Build a spatial drawing app with RealityKit Watch now Optimize for the spatial web Watch now Explore game input in visionOS Watch now Create custom environments for your immersive apps in visionOS Watch now Enhance the immersion of media viewing in custom environments Watch now Design interactive experiences for visionOS Watch now Create custom hover effects in visionOS Watch now Optimize your 3D assets for spatial computing Watch now Discover area mode for Object Capture Watch now Bring your iOS or iPadOS game to visionOS Watch now Build immersive web experiences with WebXR Watch now Get started with HealthKit in visionOS Watch now What’s new in Quick Look for visionOS Watch now What’s new in USD and MaterialX Watch now Customize spatial Persona templates in SharePlay Watch now Create enhanced spatial computing experiences with ARKit Watch now Break into the RealityKit debugger Watch now What’s new in SwiftUI Watch now

FORUMS

Find answers and get advice

Connect with Apple experts and other developers on the Apple Developer Forums.

View discussions about visionOS

COMMUNITY

Meet the community

Explore a selection of activities hosted by developer organizations during and after WWDC.

Meet the community

RESOURCES

Get a head start with sample code

• BOT-anist: Discover how the RealityKit debugger lets you inspect the entity hierarchy of spatial apps, debug rogue transformation, detect bad behavior, and find missing entities.
• Destination Video: Leverage 3D video and Spatial Audio to deliver an immersive experience.
• Incorporating real-world surroundings in an immersive experience: Make your app’s content respond to the local shape of the world.
• Simulating particles in your visionOS app: Add a range of visual effects to a RealityKit view by attaching a particle emitter component to an entity.
• Simulating physics with collisions in your visionOS app: Create entities that behave and react like physical objects in a RealityKit view.

Dive into documentation

• Discover new visionOS content in the HIG.
• Creating your first visionOS app: Learn new tips for building a new visionOS app using SwiftUI and platform-specific features.
• Adding 3D content to your app: Explore the latest in adding depth and dimension to your visionOS app.
• Understanding RealityKit’s modular architecture: Learn how everything fits together in RealityKit.
• Designing RealityKit content with Reality Composer Pro: Discover updates that can help you quickly create RealityKit scenes for your visionOS app.
• Presenting windows and spaces: Find out how to open and close the scenes that make up your app’s interface.

The App Review Guidelines, Apple Developer Program License Agreement, and Apple Developer Agreement have been updated to support updated policies and upcoming features, and to provide clarification. Please review the changes below and accept the updated terms as needed.

App Review Guidelines

• 2.1(a): Added to Notarization.
• 2.1(b): Added requirement to explain why configured in-app items cannot be found or reviewed in your app to your review notes.
• 2.5.8: We will no longer reject apps that simulate multi-app widget experiences.
• 4.6: This guideline has been removed.

Apple Developer Agreement

• Sections 1, 6(B): Updated “Apple ID” to “Apple Account.”
• Section 16(A): Clarified export compliance requirements.
• Section 18: Updated terminology for government end users.

Developer Program License Agreement

• Definitions, Section 2.1, 3.3.6(C), 3.3.10(A), 14.2(C), Attachment 9, Schedules 1-3: Updated “Apple ID” to “Apple Account.”
• Definitions: Clarified definition of Apple Maps Service.
• Definitions, Section 3.3.6(F): Specified requirements for using the Apple Music Feed API.
• Definitions, Section 3.3.8(F): Added terms for use of the Now Playing API.
• Section 3.2(h): Added terms for use of Apple Software and Services.
• Section 6.5: Added terms for use of TestFlight.
• Section 7.7: Added terms on customization of icons.
• Section 11.2(f), 14.8(A): Clarified export compliance requirements.
• Section 14.9: Updated terminology for government end users.
• Attachment 5, Section 3.1: Added terms for use of Wallet pass templates.

Please sign in to your account to review and accept the updated terms.

View all agreements and guidelines

Translations of the terms will be available on the Apple Developer website within one month.

With WWDC24 just days away, there’s a lot of ground to cover, so let’s get right to it.

WWDC24

Introducing the 2024 Apple Design Award winners

Innovation. Ingenuity. Inspiration.

Meet this year’s winners >

WWDC24: Everything you need to know

From the Keynote to the last session drop, here are the details for an incredible week of sessions, labs, community activities, and more.

Download the Apple Developer app >

Subscribe to Apple Developer on YouTube >

Watch the Keynote

Don’t miss the exciting reveal of the latest Apple software and technologies at 10 a.m. PT on Monday, June 10.

Add to calendar >

Watch the Platforms State of the Union

Here’s your deep dive into the newest advancements on Apple platforms. Join us at 1 p.m. PT on Monday, June 10.

Add to calendar >

Get ready for sessions

Learn something new in video sessions posted to the Apple Developer app, website, and YouTube channel. The full schedule drops after the Keynote on Monday, June 10.

Learn more >

Prepare for labs

Here’s everything you need to know to get ready for online labs.

Read more >

Find answers on the forums

Discuss the conference’s biggest moments on the Apple Developer Forums.

Join the conversation >

Get the most out of the forums >

Meet the community

Explore a selection of activities hosted by developer organizations during and after WWDC.

Explore community activities >

Say hello to the first WWDC24 playlist

The official WWDC24 playlists drop right after the Keynote. Until then, here’s a teaser playlist to get you excited for the week.

Listen on Apple Music >

Coming up: One incredible week

Have a great weekend, and we’ll catch you on Monday. #WWDC24

WWDC24

Tune in at 10 a.m. PT on June 10 to catch the exciting reveal of the latest Apple software and technologies.

Keynote Watch now Keynote (ASL) Watch now

WWDC24

Tune in at 1 p.m. PT on June 10 to dive deep into the newest advancements on Apple platforms.

Platforms State of the Union Watch now Platforms State of the Union (ASL) Watch now

The App Store is designed to make it easy to sell your digital goods and services globally, with support for 44 currencies across 175 storefronts.

From time to time, we may need to adjust prices or your proceeds due to changes in tax regulations or foreign exchange rates. These adjustments are made using publicly available exchange rate information from financial data providers to help make sure prices for apps and In-App Purchases stay consistent across all storefronts.

Price updates

On June 21, pricing for apps and In-App Purchases¹ will be updated for the Egypt, Ivory Coast, Nepal, Nigeria, Suriname, and Zambia storefronts if you haven’t selected one of these as the base for your app or In‑App Purchase.¹ These updates also consider the following value‑added tax (VAT) changes:

• Ivory Coast: VAT introduction of 18%
• Nepal: VAT introduction of 13% and digital services tax of 2%
• Suriname: VAT introduction of 10%
• Zambia: VAT introduction of 16%

Prices won’t change on the Egypt, Ivory Coast, Nepal, Nigeria, Suriname, or Zambia storefront if you’ve selected that storefront as the base for your app or In-App Purchase.¹ Prices on other storefronts will be updated to maintain equalization with your chosen base price.

Prices won’t change in any region if your In‑App Purchase is an auto‑renewable subscription and won’t change on the storefronts where you manually manage prices instead of using the automated equalized prices.

The Pricing and Availability section of Apps has been updated in App Store Connect to display these upcoming price changes. As always, you can change the prices of your apps, In‑App Purchases, and auto‑renewable subscriptions at any time.

Learn more about managing your prices

View or edit upcoming price changes

Edit your app’s base country or region

Pricing and availability start times by region

Set a price for an In-App Purchase

Tax updates

Your proceeds for sales of apps and In-App Purchases will change to reflect the new tax rates and updated prices. Exhibit B of the Paid Applications Agreement has been updated to indicate that Apple collects and remits applicable taxes in Ivory Coast, Nepal, Suriname, and Zambia.

As of today, June 6, your proceeds from the sale of eligible apps and In‑App Purchases have been modified in the following countries to reflect introductions of or changes in tax rates.

• France: Digital services tax no longer applicable
• Ivory Coast: VAT introduction of 18%
• Malaysia: Sales and Service Tax (SST) increased to 8% from 6%
• Nepal: VAT introduction of 13% and digital services tax introduction of 2%
• Norway: VAT increased to 20% from 0% for certain Norwegian news publications
• Suriname: VAT introduction of 10%
• Uganda: Digital services tax introduction of 5%
• Zambia: VAT introduction of 16%

Learn more about your proceeds

View payments and proceeds

Download financial reports

Tax categories

The Fitness and Health category has a new attribute: “Content is primarily accessed through streaming”. If this is relevant to your apps or In-App Purchases that offer fitness video streaming, review and update your selections in the Pricing and Availability section of Apps in App Store Connect.

Learn about setting tax categories

1: Excludes auto-renewable subscriptions.

Every year, the Apple Design Awards recognize innovation, ingenuity, and technical achievement in app and game design.

The incredible developers behind this year’s finalists have shown what can be possible on Apple platforms — and helped lay the foundation for what’s to come.

We’re thrilled to present the winners of the 2024 Apple Design Awards.

Meet this year’s winners

One week to go. Don’t miss the exciting reveal of the latest Apple software and technologies.

Keynote kicks off at 10 a.m. PT on June 10.

Add to calendar

Join us for the Platforms State of the Union at 1 p.m. PT on June 10.

Add to calendar

Learn more

Every year, the Apple Design Awards recognize innovation, ingenuity, and technical achievement in app and game design.

But they’ve also become something more: A moment to step back and celebrate the Apple developer community in all its many forms.

Meet this year’s finalists

Join the worldwide developer community for an incredible week of technology and creativity — all online and free. WWDC24 takes place from June 10-14.

Get ready

The Apple Developer Forums have been redesigned for WWDC24 to help developers connect with Apple experts, engineers, and each other to find answers and get advice.

Apple Developer Relations and Apple engineering are joining forces to field your questions and work to solve your technical issues. You’ll have access to an expanded knowledge base and enjoy quick response times — so you can get back to creating and enhancing your app or game. Plus, Apple Developer Program members now have priority access to expert advice on the forums.

Check out the new forums

It won’t be long now! WWDC24 takes place online from June 10 through 14, and we’re here to help you get ready for the biggest developer event of the year. In this edition:

• Explore Pathways, a brand-new way to learn about developing for Apple platforms.
• Meet three Distinguished Winners of this year’s Swift Student Challenge.
• Get great tips from the SharePlay team.
• Browse new developer activities about accessibility, machine learning, and more.

WWDC24

Introducing Pathways

If you’re new to developing for Apple platforms, we’ve got an exciting announcement. Pathways are simple and easy-to-navigate collections of the videos, documentation, and resources you’ll need to start building great apps and games. Because Pathways are self-directed and can be followed at your own pace, they’re the perfect place to begin your journey.

Explore Pathways for Swift, SwiftUI, design, games, visionOS, App Store distribution, and getting started as an Apple developer.

Dive into Pathways >

Meet three Distinguished Winners of the Swift Student Challenge

Elena Galluzzo, Dezmond Blair, and Jawaher Shaman all drew inspiration from their families to create their winning app playgrounds. Now, they share the hope that their apps can make an impact on others as well.

Meet Elena, Dezmond, and Jawaher >

MEET WITH APPLE EXPERTS

Check out the latest worldwide developer activities

• Meet with App Review online to discuss the App Review Guidelines and explore best practices for a smooth review process. Sign up for May 14.
• Join us in Bengaluru for a special in-person activity to commemorate Global Accessibility Awareness Day. Sign up for May 15.
• Learn how Apple machine learning frameworks can help you create more intelligent apps and games in an online activity. Sign up for May 19.

Browse the full schedule of activities >

NEWS

Explore Apple Pencil Pro

Bring even richer and more immersive interactions to your iPad app with new features, like squeeze gestures, haptic feedback, and barrel-roll angle tracking.

BEHIND THE DESIGN

The rise of Tide Guide

Here’s the swell story of how fishing with his grandfather got Tucker MacDonald hooked into creating his tide-predicting app.

‘I taught myself’: Tucker MacDonald and the rise of Tide Guide View now

GROW YOUR BUSINESS

Explore simple, safe transactions with In-App Purchase

Take advantage of powerful global pricing tools, promotional features, analytics only available from Apple, built-in customer support, and fraud detection.

Learn more >

Q&A

Get shared insights from the SharePlay team

Learn about shared experiences, spatial Personas, that magic “shockwave” effect, and more.

Q&A with the SharePlay team View now

DOCUMENTATION

Browse new and updated docs

• Explore the new framework for converting Pages, Numbers, and Keynote files to PDF, enabling you to show an inline preview in a web browser.
• Check out Writing ARM64 code for Apple platforms for an update on data-independent timing.
• Visit the HIG for new and enhanced guidance on virtual hands and interactive elements in visionOS, sheets in iPadOS, and more.

Subscribe to Hello Developer

Want to get Hello Developer in your inbox? Make sure you’ve opted in to receive emails about developer news and events by updating your email preferences in your developer account.

Share your thoughts

We’d love to hear from you. If you have suggestions for our activities or stories, please let us know.

SharePlay is all about creating meaningful shared experiences in your app. By taking advantage of SharePlay, your app can provide a real-time connection that synchronizes everything from media playback to 3D models to collaborative tools across iPhone, iPad, Mac, Apple TV, and Apple Vision Pro. We caught up with the SharePlay team to ask about creating great SharePlay experiences, spatial Personas, that magic “shockwave” effect, and more.

How does a person start a SharePlay experience?

Anyone can begin a group activity by starting a FaceTime call and then launching a SharePlay-supported app. When they do, a notification about the group activity will appear on all participants’ screens. From there, participants can join — and come and go — as they like. You can also start a group activity from your app, from the share sheet, or by adding a SharePlay button to your app.

Learn more >

How can I use SharePlay to keep media playback in sync?

SharePlay supports coordinated media playback using AVKit. You can use the system coordinator to synchronize your own player across multiple participants. If you have an ad-supported app, you can synchronize both playback and ad breaks. SharePlay also provides the GroupSessionMessenger API, which lets participants communicate in near-real time.

What’s the difference between SharePlay and Shared with You? Can they work together?

SharePlay allows people to share rich experiences with each other. Shared with You helps make app content that people are sharing in Messages available to your app. For example, if a group chat is discussing a funny meme video from your app, adopting Shared with You would allow your app to highlight that content in the app. And if your app supports SharePlay, you can surface that relevant content as an option for watching together.

Separately, Shared with You offers ways to initiate collaboration on shared, persisted content (such as documents) over Messages and FaceTime. You can choose to support SharePlay on that collaborative content, but if you do, consider the ephemerality of a SharePlay experience compared to the persistence of collaboration. For example, if your document is a presentation, you may wish to leverage Shared with You to get editors into the space while using SharePlay to launch an interactive presentation mode that just isn’t possible with screen sharing alone.

What’s the easiest way for people to share content?

When your app lets your system know that your current view has shareable content on screen, people who bring their devices together can seamlessly share that content — much like NameDrop, which presents a brief “shockwave” animation when they do. This method supports the discrete actions of sharing documents, initiating SharePlay, and starting a collaboration. This can also connect your content to the system share sheet and help you expose shareable content to the Share menu in visionOS.

Learn more >

Can someone on iPhone join a SharePlay session with someone on Apple Vision Pro?

Yes! SharePlay is supported across iOS, iPadOS, macOS, tvOS, and visionOS. That means people can watch a show together on Apple TV+ and keep their playback synchronized across all platforms. To support a similar playback situation in your app, watch Coordinate media playback in Safari with Group Activities. If you’re looking to maintain your app’s visual consistency across platforms, check out the Group Session Messenger and DrawTogether sample project. Remember: SharePlay keeps things synchronized, but your UI is up to you.

How do I get started adopting spatial Personas with SharePlay in visionOS?

When you add Group Activities to your app, people can share in that activity over FaceTime while appearing windowed — essentially the same SharePlay experience they’d see on other platforms. In visionOS, you have the ability to create a shared spatial experience using spatial Personas in which participants are placed according to a template. For example:

Using spatial Personas, the environment is kept consistent and participants can see each others’ facial expressions in real time.

Learn more >

How do I maintain visual and spatial consistency with all participants in visionOS?

FaceTime in visionOS provides a shared spatial context by placing spatial Personas in a consistent way around your app. This is what we refer to as “visual consistency.” You can use SharePlay to maintain the same content in your app for all participants.

Learn more >

Can both a window and a volume be shared at the same time in a SharePlay session?

No. Only one window or volume can be associated with a SharePlay session, but you can help the system choose the proper window or volume.

Learn more >

How many people can participate in a group activity?

SharePlay supports 33 total participants, including yourself. Group activities on visionOS involving spatial Personas support five participants at a time.

Do iOS and iPadOS apps that are compatible with visionOS also support SharePlay in visionOS?

Yes. During a FaceTime call, your app will appear in a window, and participants in the FaceTime call will appear next to it.

Learn more about SharePlay Design spatial SharePlay experiences Watch now Build spatial SharePlay experiences Watch now Share files with SharePlay Watch now Add SharePlay to your app Watch now

Lots of apps have great origin stories, but the tale of Tucker MacDonald and Tide Guide seems tailor-made for the Hollywood treatment. It begins in the dawn hours on Cape Cod, where a school-age MacDonald first learned to fish with his grandfather.

“Every day, he’d look in the paper for the tide tables,” says MacDonald. “Then he’d call me up and say, ‘Alright Tucker, we’ve got a good tide and good weather. Let’s be at the dock by 5:30 a.m.’”

Rhapsody in blue: Tide Guide delivers Washington weather data in a gorgeous design and color scheme.

That was MacDonald’s first introduction to tides — and the spark behind Tide Guide, which delivers comprehensive forecasts through top-notch data visualizations, an impressive array of widgets, an expanded iPad layout, and Live Activities that look especially great in, appropriately enough, the Dynamic Island. The SwiftUI-built app also offers beautiful Apple Watch complications and a UI that can be easily customized, depending how deep you want to dive into its data. It’s a remarkable blend of original design and framework standards, perfect for plotting optimal times for a boat launch, research project, or picnic on the beach.

Impressively, Tide Guide was named a 2023 Apple Design Award finalist — no mean feat for a solo developer who had zero previous app-building experience and started his career as a freelance filmmaker.

“I wanted to be a Hollywood director since I was in the fifth grade,” says MacDonald. Early in his filmmaking career, MacDonald found himself in need of a tool that could help him pre-visualize different camera and lens combinations — “like a director’s viewfinder app,” he says. And while he caught a few decent options on the market, MacDonald wanted an app with iOS design language that felt more at home on his iPhone. “So I dove in, watched videos, and taught myself how to make it,” he says.

My primary use cases were going fishing, heading to the beach, or trying to catch a sunset.

Tucker MacDonald, Tide Guide

Before too long, MacDonald drifted away from filmmaking and into development, taking a job as a UI designer for a social app. “The app ended up failing, but the job taught me how a designer works with an engineer,” he says. “I also learned a lot about design best practices, because I had been creating apps that used crazy elements, non-standard navigation, stuff like that.”

Tucker MacDonald grew up fishing with his grandfather in the waters off Cape Cod.

Armed with growing design knowledge, he started thinking about those mornings with his grandfather, and how he might create something that could speed up the crucial process of finding optimal fishing conditions. And it didn’t need to be rocket science. “My primary use cases were going fishing, heading to the beach, or trying to catch a sunset,” he says. “I just needed to show current conditions.”

I’d say my designs were way prettier than the code I wrote.

Tucker MacDonald, Tide Guide

In the following years, Tide Guide grew in parallel with MacDonald’s self-taught skill set. “There was a lot of trial and error, and I’d say my designs were way prettier than the code I wrote,” he laughs. “But I learned both coding and design by reading documentation and asking questions in the developer community.”

Today’s Tide Guide is quite the upgrade from that initial version. MacDonald continues to target anyone heading to the ocean but includes powerful metrics — like an hour-by-hour 10-day forecast, water temperatures, and swell height — that advanced users can seek out as needed. The app’s palette is even designed to match the color of the sky throughout the day. “The more time you spend with it, the more you can dig into different layers,” he says.

All the information you need for a day on the water, in one place.

People around the world have dug into those layers, including an Alaskan tour company operator who can only land in a remote area when the tide is right, and a nonprofit national rescue service in Scotland, whose members weighed in with a Siri shortcut-related workflow request that MacDonald promptly included. And as Tide Guide gets bigger, MacDonald’s knowledge of developing — and oceanography — continues to swell. “I’m just happy that my passion for crafting an incredible experience comes through,” he says, “because I really do have so much fun making it.”

Behind the Design is a series that explores design practices and philosophies from finalists and winners of the Apple Design Awards. In each story, we go behind the screens with the developers and designers of these award-winning apps and games to discover how they brought their remarkable creations to life.

Core Technology Fee (CTF)

The CTF is an element of the alternative business terms in the EU that reflects the value Apple provides developers through tools, technologies, and services that enable them to build and share innovative apps. We believe anyone with a good idea and the ingenuity to bring it to life should have the opportunity to offer their app to the world. Only developers who reach significant scale (more than one million first annual installs per year in the EU) pay the CTF. Nonprofit organizations, government entities, and educational institutions approved for a fee waiver don’t pay the CTF. Today, we’re introducing two additional conditions in which the CTF is not required:

• First, no CTF is required if a developer has no revenue whatsoever. This includes creating a free app without monetization that is not related to revenue of any kind (physical, digital, advertising, or otherwise). This condition is intended to give students, hobbyists, and other non-commercial developers an opportunity to create a popular app without paying the CTF.
• Second, small developers (less than €10 million in global annual business revenue*) that adopt the alternative business terms receive a 3-year free on-ramp to the CTF to help them create innovative apps and rapidly grow their business. Within this 3-year period, if a small developer that hasn’t previously exceeded one million first annual installs crosses the threshold for the first time, they won’t pay the CTF, even if they continue to exceed one million first annual installs during that time. If a small developer grows to earn global revenue between €10 million and €50 million within the 3-year on-ramp period, they’ll start to pay the CTF after one million first annual installs up to a cap of €1 million per year.

iPadOS

This week, the European Commission designated iPadOS a gatekeeper platform under the Digital Markets Act. Apple will bring our recent iOS changes for apps in the European Union (EU) to iPadOS later this fall, as required. Developers can choose to adopt the Alternative Terms Addendum for Apps in the EU that will include these additional capabilities and options on iPadOS, or stay on Apple’s existing terms.

Once these changes are publicly available to users in the EU, the CTF will also apply to iPadOS apps downloaded through the App Store, Web Distribution, and/or alternative marketplaces. Users who install the same app on both iOS and iPadOS within a 12-month period will only generate one first annual install for that app. To help developers estimate any potential impact on their app businesses under the Alternative Terms Addendum for Apps in the EU, we’ve updated the App Install reports in App Store Connect that can be used with our fee calculator.

For more details, visit Understanding the Core Technology Fee for iOS apps in the European Union. If you’ve already entered into the Alternative Terms Addendum for Apps in the EU, be sure to sign the updated terms.

Global business revenue takes into account revenue across all commercial activity, including from associated corporate entities. For additional details, read the Alternative Terms Addendum for Apps in the EU.

The App Store was created to be a safe place for users to discover and get millions of apps all around the world. Over the years, we‘ve built many critical privacy and security features that help protect users and give them transparency and control — from Privacy Nutrition Labels to app tracking transparency, and so many more.

An essential requirement of maintaining user trust is that developers are responsible for all of the code in their apps, including code frameworks and libraries from other sources. That‘s why we’ve created privacy manifests and signature requirements for the most popular third-party SDKs, as well as required reasons for covered APIs.

Starting May 1, 2024, new or updated apps that have a newly added third-party SDK that‘s on the list of commonly used third-party SDKs will need all of the following to be submitted in App Store Connect:

1. Required reasons for each listed API
2. Privacy manifests
3. Valid signatures when the SDK is added as a binary dependency

Apps won’t be accepted if they fail to meet the manifest and signature requirements. Apps also won’t be accepted if all of the following apply:

1. They’re missing a reason for a listed API
2. The code is part of a dynamic framework embedded via the Embed Frameworks build phase
3. The framework is a newly added third-party SDK that’s on the list of commonly used third-party SDKs

In the future, these required reason requirements will expand to include the entire app binary. If you’re not using an API for an approved reason, please find an alternative. These changes are designed to help you better understand how third-party SDKs use data, secure software dependencies, and provide additional privacy protection for users.

This is a step forward for all apps and we encourage all SDKs to adopt this functionality to better support the apps that depend on them.

Apple Search Ads helps you drive discovery of your app or game on the App Store. We caught up with the Apple Search Ads team to learn more about successfully using the service, including signing up for the free online Apple Search Ads Certification course.

How might my app or game benefit from promotion on the App Store?

With Apple Search Ads, developers are seeing an increase in downloads, retention, return on ad spend, and more. Find out how the developers behind The Chefz, Tiket, and Petit BamBou have put the service into practice.

Where will my ad appear?

You can reach people in the following places:

• The Today tab, where people start their App Store visit.
• The Search tab, before people search for something specific.
• Search results, at the top of the results list.
• Product pages, in the “You Might Also Like” section.

How can I learn best practices for creating and managing campaigns?

Online Apple Search Ads Certification training teaches proven best practices for driving stronger campaign performance. Certification training is designed for all skill levels, from marketing pros to those just starting out. To become certified, complete all of the Certification lessons (each takes between 10 and 20 minutes), then test your skills with a free exam. Once you’re certified, you can share your certificate with your professional network on platforms like LinkedIn.

Sign up here with your Apple ID.

Will my certification expire?

Although your Apple Search Ads certification never expires, training is regularly updated. You can choose to be notified about these updates through email or web push notifications.

Can I highlight specific content or features in my ads?

You can use the custom product pages you create in App Store Connect to tailor your ads for a specific audience, feature launch, seasonal promotion, and more. For instance, you can create an ad for the Today tab that leads people to a specific custom product page or create ad variations for different search queries. Certification includes a lesson on how to do so.

Can I advertise my app before launch?

You can use Apple Search Ads to create ads for apps you’ve made available for pre-order. People can order your app before it’s released, and it’ll automatically download onto their devices on release day.

Drive discovery and downloads on the App Store with Apple Search Ads in 70 countries and regions, now including Brazil, Bolivia, Costa Rica, the Dominican Republic, El Salvador, Guatemala, Honduras, Panama, and Paraguay.

Visit the Apple Search Ads site and Q&A.

And explore best practices to improve your campaign performance with the free Apple Search Ads Certification course.

Watch the May 7 event at apple.com, on Apple TV, or on YouTube Live.

Join us around the world to learn about growing your business, elevating your app design, and preparing for the App Review process. Here’s a sample of our new activities — and you can always browse the full schedule to find more.

• Expand your app to new markets: Learn how to bring your apps and games to Southeast Asia, Hong Kong, and Taiwan in new online sessions with App Store experts.
• Request a one-on-one App Review consultation: Meet online to discuss the App Review Guidelines and explore best practices for a smooth review process.
• Visit the Apple Vision Pro developer labs: Test, refine, and optimize your apps and games for the infinite canvas — with in-person help from Apple.
• Request a design or technology consultation: In this 30-minute online consultation, you’ll get expert advice tailored to your app or game.

Browse the full schedule

Web Distribution lets authorized developers distribute their iOS apps to users in the European Union (EU) directly from a website owned by the developer. Apple will provide developers access to APIs that facilitate the distribution of their apps from the web, integrate with system functionality, and back up and restore users’ apps, once they meet certain requirements designed to help protect users and platform integrity. For details, visit Getting started with Web Distribution in the EU.

The beta versions of iOS 17.5, iPadOS 17.5, macOS 14.5, tvOS 17.5, visionOS 1.2, and watchOS 10.5 are now available. Get your apps ready by confirming they work as expected on these releases. And to take advantage of the advancements in the latest SDKs, make sure to build and test with Xcode 15.3.

View downloads and release notes

Learn about testing a beta OS

Learn about sending feedback

The App Review Guidelines have been revised to support updated policies, upcoming features, and to provide clarification. The following guidelines have been updated:

• 3.1.1(a): Updated to include Music Streaming Services Entitlements.
• 4.7: Added games from retro game console emulator apps to the list of permitted software, and clarifies that mini apps and mini games must be HTML5.

View guidelines

Welcome to Hello Developer — and the kickoff to WWDC season. In this edition:

• Discover what’s ahead at WWDC24 — and check out the new Apple Developer YouTube channel.
• Learn how the all-new Develop in Swift Tutorials can help jump-start a career in app development.
• Find out how Zach Gage and Jack Schlesinger rebooted the crossword puzzle with Knotwords.

WWDC24

The countdown is on

WWDC season is officially here.

This year’s Worldwide Developers Conference takes place online from June 10 through 14, offering you the chance to explore the new tools, frameworks, and technologies that’ll help you create your best apps and games yet.

All week long, you can learn and refine new skills through video sessions, meet with Apple experts to advance your projects and ideas, and join the developer community for fun activities. It’s an innovative week of technology and creativity — all online at no cost.

And for the first time, WWDC video sessions will be available on YouTube, in addition to the Apple Developer app and website. Visit the new Apple Developer channel to subscribe and catch up on select sessions.

TUTORIALS

Check out the new Develop in Swift Tutorials

Know a student or aspiring developer looking to start their coding journey? Visit the all-new Develop in Swift Tutorials, designed to introduce Swift, SwiftUI, and spatial computing through the experience of building a project in Xcode.

BEHIND THE DESIGN

Gage and Schlesinger at the crossroads

Learn how acclaimed game designers Zach Gage and Jack Schlesinger reimagined the crossword with Knotwords.

Knotwords: Gage and Schlesinger at the crossroads View now

MEET WITH APPLE EXPERTS

Browse new developer activities

Check out this month’s sessions, labs, and consultations, held online and in person around the world.

NEWS AND DOCUMENTATION

Explore and create with new and updated docs

• Check out two new sample code projects about creating and viewing stereo MV-HEVC movies: Converting side-by-side 3D video to multiview HEVC and Reading multiview 3D video files.
• Find out about creating distribution-signed code for macOS, and explore the details of packaging Mac software for distribution.
• Learn what’s new in the Human Interface Guidelines, including guidance on displaying virtual hands, organizing your spatial layouts, and using Activity rings in your app.

View the complete list of new resources.

Subscribe to Hello Developer

Want to get Hello Developer in your inbox? Make sure you’ve opted in to receive emails about developer news and events by updating your email preferences in your developer account.

Share your thoughts

We’d love to hear from you. If you have suggestions for our activities or stories, please let us know.

Knotwords is a clever twist on crossword puzzles — so much so that one would expect creators Zach Gage and Jack Schlesinger to be longtime crossword masters who set out to build themselves a new challenge.

One would be totally wrong.

“Crosswords never hit with me,” says Gage, with a laugh. “I dragged myself kicking and screaming into this one.”

It’s not about ‘What random box of words will you get?’ but, ‘What are the decisions you’ll make as a player?’

Jack Schlesinger, Knotwords

In fact, Gage and Schlesinger created the Apple Design Award finalist Knotwords — and the Apple Arcade version, Knotwords+ — not to revolutionize the humble crossword but to learn it. “We know people like crosswords,” says Schlesinger, “so we wanted to figure out what we were missing.” And the process didn’t just result in a new game — it led them straight to the secret of word-game design success. “It’s not about ‘What random box of words will you get?’” says Schlesinger, “but, ‘What are the decisions you’ll make as a player?’”

Knotwords challenges players to complete a puzzle using only specific letters in specific parts of the board.

Gage and Schlesinger are longtime design partners; in addition to designing Knotwords and Good Sudoku with Gage, Schlesinger contributed to the 2020 reboot of SpellTower and the Apple Arcade title Card of Darkness. Neither came to game design through traditional avenues: Gage has a background in interactive art, while Schlesinger is the coding mastermind with a history in theater and, of all things, rock operas. (He’s responsible for the note-perfect soundtracks for many of the duo’s games.) And they’re as likely to talk about the philosophy behind a game as the development of it.

I had been under the mistaken impression that the magic of a simple game was in its simple rule set. The magic actually comes from having an amazing algorithmic puzzle constructor.

Zach Gage

“When you’re playing a crossword, you’re fully focused on the clues. You’re not focused on the grid at all,” explains Gage. “But when you’re building a crossword, you’re always thinking about the grid. I wondered if there was a way to ask players not to solve a crossword but recreate the grid instead,” he says.

Knotwords lets players use only specific letters in specific sections of the grid — a good idea, but one that initially proved elusive to refine and difficult to scale. “At first, the idea really wasn’t coming together,” says Gage, “so we took a break and built Good Sudoku.” Building their take on sudoku — another game with simple rules and extraordinary complexity — proved critical to restarting Knotwords. “I had been under the mistaken impression that the magic of a simple game was in its simple rule set,” Gage says. “The magic actually comes from having an amazing algorithmic puzzle constructor.”

An early — and very analog — prototype of Knotwords.

Problematically, they didn’t just have one of those just lying around. But they did have Schlesinger. “I said, ‘I will make you a generator for Knotwords in two hours,’” Schlesinger laughs. That was maybe a little ambitious. The first version took eight hours and was, by his own account, not great. However, it proved a valuable learning experience. “We learned that we needed to model a player. What would someone do here? What steps could they take? If they make a mistake, how long would it take them to correct it?” In short, the puzzle generation algorithm needed to take into account not just rules, but also player behavior.

The work provided the duo an answer for why people liked crosswords. It also did one better by addressing one of Gage’s longstanding game-design philosophies. “To me, the only thing that’s fun in a game is the process of getting better,” says Gage. “In every game I’ve made, the most important questions have been: What’s the journey that people are going through and how can we make that journey fun? And it turns out it's easy to discover that if I've never played a game before.”

Learn more about Knotwords

Find Knotwords+ on Apple Arcade

Behind the Design is a series that explores design practices and philosophies from each of the winners and finalists of the Apple Design Awards. In each story, we go behind the screens with the developers and designers of these award-winning apps and games to discover how they brought their remarkable creations to life.

Join the worldwide developer community online for a week of technology and creativity.

Be there for the unveiling of the latest Apple platforms, technologies, and tools. Learn how to create and elevate your apps and games. Engage with Apple designers and engineers and connect with the worldwide developer community. All online and at no cost.

Learn more

To align with the Digital Services Act (DSA) in the European Union (EU), Account Holders and Admins in the Apple Developer Program can now enter their trader status in App Store Connect.

Submission requirements

You’ll need to let us know whether or not you’re a trader to submit new apps to the App Store. If you’re a trader, you may be asked for documentation that verifies your trader contact information.

We’re providing more flexibility for developers who distribute apps in the European Union (EU), including introducing a new way to distribute apps directly from a developer’s website.

More flexibility

Developers who’ve agreed to the Alternative Terms Addendum for Apps in the EU have new options for their apps in the EU:

• Alternative app marketplaces. Marketplaces can choose to offer a catalog of apps solely from the developer of the marketplace.
• Linking out to purchase. When directing users to complete a transaction for digital goods or services on an external webpage, developers can choose how to design promotions, discounts, and other deals. The Apple-provided design templates, which are optimized for key purchase and promotional use cases, are now optional.

Distributing directly from your website

Web Distribution, available with a software update later this spring, will let authorized developers distribute their iOS apps to EU users directly from a website owned by the developer. Apple will provide authorized developers access to APIs that facilitate the distribution of their apps from the web, integrate with system functionality, back up and restore users’ apps, and more. For details, visit Getting ready for Web Distribution in the EU.

On its surface, Finding Hannah is a bright and playful hidden-object game — but dig a little deeper and you’ll find something much more.

The Hannah of Finding Hannah is a 38-year-old Berlin resident trying to navigate career, relationships (including with her best friend/ex, Emma), and the nagging feeling that something’s missing in her life. To help find answers, Hannah turns to her nurturing grandmother and free-spirited mother — whose own stories gradually come into focus and shape the game’s message as well.

“It’s really a story about three women from three generations looking for happiness,” says Franziska Zeiner, cofounder and co-CEO of the Fein Games studio. “For each one, times are changing. But the question is: Are they getting better?”

Locate hidden objects in this lively Berlin subway scene to move along the story of Finding Hannah.

To move the story along, players comb through a series of richly drawn scenes — a packed club, a bustling train, a pleasantly cluttered bookstore. Locating (and merging) hidden items unlocks new chapters, and the more you find, the more the time-hopping story unfolds. The remarkable mix of message and mechanic made the game a 2023 Apple Design Award finalist, as well as a Cultural Impact winner in the 2023 App Store Awards.

Fein Games is the brainchild of Zeiner and Lea Schönfelder, longtime friends from the same small town in Germany who both pursued careers in game design — despite not being all that into video games growing up. “I mean, at some point I played The Sims as a teenager,” laughs Zeiner, “but games were rare for us. When I eventually went to study game design, I felt like I didn’t really fit in, because my game literacy was pretty limited.”

The goal is to create for people who enjoy authentic female experiences in games.

Lea Schönfelder, cofounder and co-CEO of Fein Games

Cofounder and co-CEO Schönfelder also says she felt like an outsider, but soon found game design a surprisingly organic match for her background in illustration and animation. “In my early years, I saw a lot of people doing unconventional things with games and thought, ‘Wow, this is really powerful.’ And I knew I loved telling stories, maybe not in a linear form but a more systematic way.” Those early years included time with studios like Nerial and ustwo Games, where she worked on Monument Valley 2 and Assemble With Care.

Drawing on their years of experience — and maybe that shared unconventional background — the pair went out on their own to launch Fein Games in 2020. From day one, the studio was driven by more than financial success. “The goal is to create for people who enjoy authentic female experiences in games,” says Schönfelder. “But the product is only one side of the coin — there’s also the process of how you create, and we’ve been able to make inclusive games that maybe bring different perspectives to the world.”

Hannah and her free-spirited mother, Sigrid, share an uncomfortable conversation.

Finding Hannah was driven by those perspectives from day one. The story was always meant to be a time-hopping journey featuring women in Berlin, and though it isn’t autobiographical, bits and pieces do draw from their creators’ lives. “There’s a scene inspired by my grandmother, who was a nurse during the second world war and would tan with her friends on a hospital roof while the planes circled above,” says Schönfelder. The script was written by Berlin-based author Rebecca Harwick, who also served as lead writer on June’s Journey and writer on Switchcraft, The Elder Scrolls Online, and many others.

In the beginning, I felt like I wasn’t part of the group, and maybe even a little ashamed that I wasn’t as games-literate as my colleagues. But what I thought was a weakness was actually a strength.

Lea Schönfelder, cofounder and co-CEO of Fein Games

To design the art for the different eras, the team tried not to think like gamers. “The idea was to try to reach people who weren’t gamers yet, and we thought we’d most likely be able to do that if we found a style that hadn’t been seen in games before,” says Zeiner. To get there, they hired Elena Resko, a Russian-born artist based in Berlin who’d also never worked in games. “What you see is her style,” says Schönfelder. “She didn’t develop that for the game. I think that’s why it has such a deep level of polish, because Elena has been developing her style for probably a decade now.”

And the hidden-object and merge gameplay mechanic itself is an example of sticking with a proven success. “When creating games, you usually want to invent a new mechanic, right?” says Schönfelder. “But Finding Hannah is for a more casual audience. And it’s been proven that the hidden-object mechanic works. So we eventually said, ‘Well, maybe we don’t need to reinvent the wheel here,’” she laughs.

The scene in which Hannah’s grandmother sits with friends on the roof was inspired by Lea Schönfelder’s grandmother.

The result is a hidden-object game like none other, part puzzler, part historically flavored narrative, part meditation on the choices faced by women across generations. And it couldn’t have come from a team with any other background. “In the beginning, I felt like I wasn’t part of the group, and maybe even a little ashamed that I wasn’t as games-literate as my colleagues,” says Schönfelder. “But what I thought was a weakness was actually a strength. Players don’t always play your game like you intended. And I felt a very strong, very sympathetic connection to people, and wanted to make the experience as smooth and accessible as possible. And I think that shows.”

Learn more about Finding Hannah

Download Finding Hannah from the App Store

Behind the Design is a series that explores design practices and philosophies from finalists and winners of the Apple Design Awards. In each story, we go behind the screens with the developers and designers of these award-winning apps and games to discover how they brought their remarkable creations to life.

Security is at the core of every Apple platform. The Mac notary service team is part of Apple Security Engineering and Architecture, and in this Q&A, they share their tips on app distribution and account security to help Mac developers have a positive experience — and protect their users.

When should I submit my new app for notarization?

Apps should be mostly complete at the time of notarization. There’s no need to notarize an app that isn’t functional yet.

How often should I submit my app for notarization?

You should submit all versions you might want to distribute, including beta versions. That’s because we build a profile of your unique software to help distinguish your apps from other developers’ apps, as well as malware. As we release new signatures to block malware, this profile helps ensure that the software you’ve notarized is unaffected.

What happens if my app is selected for additional analysis?

Some uploads to the notary service require additional evaluation. If your app falls into this category, rest assured that we’ve received your file and will complete the analysis, though it may take longer than usual. In addition, if you’ve made changes to your app while a prior upload has been delayed, it’s fine to upload a new build.

What should I do if my app is rejected?

Keep in mind that empty apps or apps that might damage someone’s computer (by changing important system settings without the owner’s knowledge, for instance) may be rejected, even if they’re not malicious. If your app is rejected, first confirm that your app doesn’t contain malware. Then determine whether it should be distributed privately instead, such as within your enterprise via MDM.

What should I do if my business changes?

Keep your developer account details — including your business name, contact info, address, and agreements — up to date. Drastic shifts in account activity or software you notarize can be signs that your account or certificate has been compromised. If we notice this type of activity, we may suspend your account while we investigate further.

I’m a contractor. What are some ways to make sure I’m developing responsibly?

Be cautious if anyone asks you to:

• Sign, notarize, or distribute binaries that you didn’t develop.
• Develop software that appears to be a clone of existing software.
• Develop what looks like an internal enterprise application when your customer isn’t an employee of that company.
• Develop software in a high-risk category, like VPNs, system utilities, finance, or surveillance apps. These categories of software have privileged access to private data, increasing the risk to users.

Remember: It’s your responsibility to know your customer and the functionality of all software you build and/or sign.

What can I do to maintain control of my developer account?

Since malware developers may try to gain access to legitimate accounts to hide their activity, be sure you have two-factor authentication enabled. Bad actors may also pose as consultants or employees and ask you to add them to your developer team. Luckily, there’s an easy solve: Don’t share access to your accounts.

Should I remove access for developers who are no longer on my team?

Yes. And we can revoke Developer ID certificates for you if you suspect they may have been compromised.

Learn more about notarization

Notarizing macOS software before distribution

Developer agreement for notarizing macOS applications

Two-factor authentication for developer accounts

Welcome to Hello Developer. In this edition:

• Find out what you can do at the Apple Developer Centers in Bengaluru, Cupertino, Shanghai, and Singapore.
• Learn how the team behind Finding Hannah created a hidden-object game with a meaningful message.
• Get security tips from the Mac notary service team.
• Catch up on the latest news and documentation.

FEATURED

Step inside the Apple Developer Centers

The new Apple Developer Centers are open around the world — and we can’t wait for you to come by. With locations in Bengaluru, Cupertino, Shanghai, and now Singapore, Apple Developer Centers are the home bases for in-person sessions, labs, workshops, and consultations around the world.

Whether you’re looking to enhance your existing app or game, refine your design, or launch a new project, there’s something exciting for you at the Apple Developer Centers. Browse activities in Bengaluru, Cupertino, Shanghai, and Singapore.

BEHIND THE DESIGN

Uncover the hidden joys of Finding Hannah

On its surface, Finding Hannah is a bright and playful hidden-object game — but dig a little deeper and you’ll find something more. “It’s really a story about three women from three generations looking for happiness,” says Franziska Zeiner, cofounder and co-CEO of the Fein Games studio. “For each one, times are changing. But the question is: Are they getting better?” Find out how Zeiner and her Berlin-based team created this compelling Apple Design Award finalist.

Uncovering the hidden joys of Finding Hannah View now

Q&A

Get answers from the Mac notary service team

Security is at the core of every Apple platform. The Mac notary service team is part of Apple Security Engineering and Architecture, and in this Q&A, they share their tips on app distribution and account security to help Mac developers have a positive experience — and protect their users.

Q&A with the Mac notary service team View now

VIDEOS

Improve your subscriber retention with App Store features

In this new video, App Store experts share their tips for minimizing churn and winning back subscribers.

Improve your subscriber retention with App Store features Watch now

GROW YOUR BUSINESS

Make the most of custom product pages

Learn how you can highlight different app capabilities and content through additional (and fully localizable) versions of your product page. With custom product pages, you can create up to 35 additional versions — and view their performance data in App Store Connect.

Plus, thanks to seamless integration with Apple Search Ads, you can use custom product pages to easily create tailored ad variations on the App Store. Read how apps like HelloFresh, Pillow, and Facetune used the feature to gain performance improvements, like higher tap-through and conversion rates.

DOCUMENTATION

Find the details you need in new and updated docs

• Create complex materials and effects for 3D content with Shader Graph, a node-based material editor in Reality Composer Pro.
• Use SwiftData to add persistence to your app with minimal code and no external dependencies. Check out new documentation on classes, macros, and structures.
• Learn how to share configurations across Xcode Cloud workflows.
• Explore HIG updates about visionOS support, including new details on immersive experiences, the virtual keyboard, layout, color, and motion.
• New in Technotes: Learn how to identify and handle CloudKit throttles. Plus, find out how to recognize and resolve synchronization issues when working with NSPersistentCloudKitContainer, and how to explore details inside the container by capturing and analyzing a sysdiagnose.

View the full list of new resources

NEWS

Catch up on the latest updates

• App Store Connect upload requirement: Starting April 29, 2024, uploaded apps must be built with Xcode 15 for iOS 17, iPadOS 17, tvOS 17, or watchOS 10.
• Updates to support app distribution changes in the European Union: Learn how we’re continuing to provide new ways to understand and utilize these changes.
• App Store Connect update: Learn about changes to app statuses and support for features related to alternative app distribution in the EU.
• App Store Connect API 3.3: Manage distribution keys, alternative distribution packages, and marketplace search for alternative app distribution in the EU.

Subscribe to Hello Developer

Want to get Hello Developer in your inbox? Make sure you’ve opted in to receive emails about developer news and events by updating your email preferences in your developer account.

Share your thoughts

We’d love to hear from you. If you have suggestions for our activities or stories, please let us know.

We’re expanding the analytics available for your apps to help you get even more insight into your business and apps’ performance.

Over 50 new reports are now available through the App Store Connect API to help you analyze your apps’ App Store and iOS performance. These reports include hundreds of new metrics that can enable you to evaluate your performance and find opportunities for improvement. Reports are organized into the following categories:

• App Store Engagement — the number of users on the App Store interacting with a developer’s app or sharing it with others
• App Store Commerce — downloads, sales, pre-orders, and transactions made with the secure App Store In-App Purchase system
• App Usage — active devices, installs, app deletions, and more
• Frameworks Usage — an app’s interaction with OS capabilities, such as PhotoPicker and Widgets
• Performance — how your apps perform and how users interact with specific features

Additionally, new reports are also available through the CloudKit console with data about Apple Push Notifications and File Provider.

• Apple Push Notifications — notification states as they pass through the Apple Push Notification service (APNs)
• File Provider — usage, consistency, and error data

Over the past several weeks, we’ve communicated with thousands of developers to discuss DMA-related changes to iOS, Safari, and the App Store impacting apps in the European Union. As a result of the valuable feedback received, we’ve revised the Alternative Terms Addendum for Apps in the EU to update the following policies and provide developers more flexibility:

• Decisioning by membership: To make it easier for more developers to sign up for the new terms, we’ve removed the corporate entity requirement that the Addendum must be signed by each membership that controls, is controlled by, or is under control with another membership. This means an entity can now choose to sign up for the new terms at the developer account level.
• Switching back: To help reduce the risk of unexpected business changes under the new terms, such as reaching massive scale more quickly than anticipated, or if you simply change your mind, we’ve created a one-time option to terminate the Addendum under certain circumstances and switch back to Apple’s standard business terms for your EU apps. For details, view the Addendum.
• Alternative app marketplace requirements: To make it easier for developers who want to create alternative app marketplaces, we’ve added a new eligibility criteria that lets developers qualify without a stand-by letter of credit. For details, view the marketplace support page.

If you’ve already entered into the Addendum, you can sign the updated version here.

You can now submit your apps and games built with Xcode 15.3 and all the latest SDKs for iOS 17.4, iPadOS 17.4, macOS 14.4, tvOS 17.4, visionOS 1.1, and watchOS 10.4.

Developers who have agreed to the Alternative Terms Addendum for Apps in the EU can now submit apps offering alternative payment options in the EU. They can also now measure the number of first annual installs their apps have accumulated.

If you’d like to discuss changes to iOS, Safari, and the App Store impacting apps in the EU to comply with the Digital Markets Act, request a 30-minute online consultation with an Apple team member.

The App Store Review Guidelines have been revised to support updated policies, upcoming features, and to provide clarification.

• The title of the document has been changed to App Review Guidelines.
• The Introduction section explains that in the European Union, developers can also distribute notarized iOS apps from alternative app marketplaces. This section provides links to further information about alternative app marketplaces and Notarization for iOS apps.

The following guidelines have been updated:

• 2.3.1: Added that a violation of this rule is grounds for an app being blocked from installing via alternative distribution.
• 2.3.10: Added that developers cannot include names, icons, or imagery of other mobile platforms or alternative app marketplaces in their apps or metadata, unless there is specific, approved interactive functionality.
• 3.1.3(b): Added a link to 3.1.1 to make clear that 3.1.1(a) applies, and multiplatform services apps can use the 3.1.1(a) entitlement.
• 4.8 Login Services: Updated to make clear that the login service cannot collect interactions with your app for advertising purposes without consent. It also adds that another login service is not required if your app is an alternative app marketplace, or an app distributed from an alternative app marketplace, that uses a marketplace-specific login for account, download, and commerce features.
• 5.1.1(viii): Added that apps that compile personal information from any source that is not directly from the user or without the user’s explicit consent, even public databases, are not permitted on alternative app marketplaces.
• 5.4 and 5.5: Updated to state that apps that do not comply with these guidelines will be blocked from installing via alternative distribution.
• Bug Fix Submissions: Added that bug fixes will not be delayed for apps that are already on alternative app marketplaces, except for those related to legal or safety issues.

View the App Review Guidelines

Translations of the guidelines will be available on the Apple Developer website within one month.

Developers are responsible for all code included in their apps. At WWDC23, we introduced new privacy manifests and signatures for commonly used third-party SDKs and announced that developers will need to declare approved reasons for using a set of APIs in their app’s privacy manifest. These changes help developers better understand how third-party SDKs use data, secure software dependencies, and provide additional privacy protection for users.

Starting March 13: If you upload a new or updated app to App Store Connect that uses an API requiring approved reasons, we’ll send you an email letting you know if you’re missing reasons in your app’s privacy manifest. This is in addition to the existing notification in App Store Connect.

Starting May 1: You’ll need to include approved reasons for the listed APIs used by your app’s code to upload a new or updated app to App Store Connect. If you’re not using an API for an allowed reason, please find an alternative. And if you add a new third-party SDK that’s on the list of commonly used third-party SDKs, these API, privacy manifest, and signature requirements will apply to that SDK. Make sure to use a version of the SDK that includes its privacy manifest and note that signatures are also required when the SDK is added as a binary dependency.

This functionality is a step forward for all apps and we encourage all SDKs to adopt it to better support the apps that depend on them.

Submit in App Store Connect

iOS 17.4, iPadOS 17.4, macOS 14.4, tvOS 17.4, visionOS 1.1, and watchOS 10.4 will soon be available to customers worldwide. Build your apps and games using the Xcode 15.3 Release Candidate and latest SDKs, then test them using TestFlight. You can submit your iPhone and iPad apps today.

Apps in the European Union

Developers who’ve agreed to the Alternative Terms Addendum for Apps in the EU can set up marketplace distribution in the EU. Eligible developers can also submit marketplace apps and offer apps with alternative browser engines.

Once these platform versions are publicly available:

• First annual installs for the Core Technology Fee begin accruing and the new commission rates take effect for these developers.
• Apps offering alternative payment options in the EU will be accepted in App Store Connect. In the meantime, you can test in the sandbox environment.

If you’d like to discuss changes to iOS, Safari, and the App Store impacting apps in the EU to comply with the Digital Markets Act, request a 30-minute online consultation to meet with an Apple team member. In addition, if you’re interested in getting started with operating an alternative app marketplace on iOS in the EU, you can request to attend an in-person lab in Cork, Ireland.

Sign in to App Store Connect

Apple developer activities are in full swing. Here’s a look at what’s happening:

• Join an online session to learn to minimize churn and win back subscribers hosted by App Store experts.
• Celebrate International Women’s Day with special in-person activities in Bengaluru, Cupertino, Shanghai, Singapore, Sydney, and Tokyo.
• Visit an Apple Vision Pro developer lab in Cupertino, London, Munich, Singapore, Sydney, or Tokyo to test and refine your apps for the infinite canvas.
• Meet with an Apple team member to discuss changes to iOS, Safari, and the App Store impacting apps in the European Union to comply with the Digital Markets Act.

And we’ll have lots more activities in store — online, in person, and in multiple languages — all year long.

Browse the schedule

Writing is fundamental — especially in your apps and games, where the right words can have a profound impact on your experience. During WWDC23, the Apple UX writing team hosted a wide-ranging Q&A that covered everything from technical concepts to inspiring content to whether apps should have “character.” Here are some highlights from that conversation and resources to help you further explore writing for user interfaces.

Writing for interfaces Watch now My app has a lot of text. What’s the best way to make copy easier to read?

Ask yourself: What am I trying to accomplish with my writing? Once you’ve answered that, you can start addressing the writing itself. First, break up your paragraphs into individual sentences. Then, go back and make each sentence as short and punchy as possible. To go even further, you can start each sentence the same way — like with a verb — or add section headers to break up the copy. Or, to put it another way:

Break up your paragraphs into individual sentences.

Make each sentence as short and punchy as possible.

Start each sentence the same way — like with a verb.

Keep other options in mind too. Sometimes it might be better to get your point across with a video or animation. You might also put a short answer first and expand on it elsewhere. That way, you’re helping people who are new to your app while offering a richer option for those who want to dive a little deeper.

What’s your advice for explaining technical concepts in simple terms?

First, remember that not everyone will have your level of understanding. Sometimes we get so excited about technical details that we forget the folks who might be using an app for the first time.

Try explaining the concept to a friend or colleague first — or ask an engineer to give you a quick summary of a feature.

From there, break down your idea into smaller components and delete anything that isn’t absolutely necessary. Technical concepts can feel even more intimidating when delivered in a big block of text. Can you link to a support page? Do people need that information in this particular moment? Offering small bits of information is always a good first step.

How can I harness the “less is more” concept without leaving people confused?

Clarity should always be the priority. The trick is to make something as long as it needs to be, but as short as it can be. Start by writing everything down — and then putting it away for a few days. When you come back to it, you’ll have a clearer perspective on what can be cut.

One more tip: Look for clusters of short words — those usually offer opportunities to tighten things up.

How should I think about writing my onboarding?

Naturally, this will depend on your app or game — you’ll have to figure out what’s necessary and right for you. But typically, brevity is key when it comes to text — especially at the beginning, when people are just trying to get into the experience.

Consider providing a brief overview of high-level features so people know why they should use your app and what to expect while doing so. Also, think about how they got there. What text did they see before opening your app? What text appeared on the App Store? All of this contributes to the overall journey.

Human Interface Guidelines: Onboarding

Should UX writing have a personal tone? Or does that make localization too difficult?

When establishing your voice and tone, you should absolutely consider adding elements of personality to get the elusive element of “character.” But you're right to consider how your strings will localize. Ideally, you’ll work with your localization partners for this. Focus on phrases that strike the tone you want without resorting to idioms. And remember that a little goes a long way.

How should I approach writing inclusively, particularly in conveying gender?

This is an incredibly important part of designing for everyone. Consider whether specifying gender is necessary for the experience you’re creating. If gender is necessary, it’s helpful to provide a full set of options — as well as an option to decline the question. Many things can be written without alluding to gender at all and are thus more inclusive. You can also consider using glyphs. SF Symbols provides lots of inclusive options. And you can find more guidance about writing inclusively in the Human Interface Guidelines.

Human Interface Guidelines: Inclusion

What are some best practices for writing helpful notifications?

First, keep in mind that notifications can feel inherently interruptive — and that people receive lots of them all day long. Before you write a notification at all, ask yourself these questions:

• Does the message need to be sent right now?
• Does the message save someone from opening your app?
• Does the message convey something you haven’t already explained?

If you answered yes to all of the above, learn more about notification best practices in the Human Interface Guidelines.

Human Interface Guidelines: Notifications

Can you offer guidance on writing for the TipKit framework?

With TipKit — which displays tips that help people discover features in your app — concise writing is key. Use tips to highlight a brand-new feature in your app, help people discover a hidden feature, or demonstrate faster ways to accomplish a task. Keep your tips to just one idea, and be as clear as possible about the functionality or feature you’re highlighting.

What’s one suggestion you would give writers to improve their content?

One way we find the perfect (or near-perfect) sentence is to show it to other people, including other writers, designers, and creative partners. If you don’t have that option, run your writing by someone else working on your app or even a customer. And you can always read out loud to yourself — it’s an invaluable way to make your writing sound conversational, and a great way to find and cut unnecessary words.

Welcome to the first Hello Developer of the spatial computing era. In this edition: Join us to celebrate International Women’s Day all over the world, find out how the Fantastical team brought their app to life on Apple Vision Pro, get UX writing advice straight from Apple experts, and catch up on the latest news and documentation.

FEATURED

Join us for International Women's Day celebrations

This March, we’re honoring International Women’s Day with developer activities all over the world. Celebrate and elevate women in app development through a variety of sessions, panels, and performances.

FEATURED

“The best version we’ve ever made”: Fantastical comes to Apple Vision Pro

The best-in-class calendar app Fantastical has 11 years of history, a shelf full of awards, and plenty of well-organized fans on iPad, iPhone, Mac, and Apple Watch. Yet Fantastical’s Michael Simmons says the app on Apple Vision Pro is “the best version we’ve ever made.” Find out what Simmons learned while building for visionOS — and what advice he’d give fellow developers bringing their apps to Apple Vision Pro.

“The best version we’ve ever made”: Fantastical comes to Apple Vision Pro View now

Q&A

Get advice from the Apple UX writing team

Writing is fundamental — especially in your apps and games, where the right words can have a profound impact on your app’s experience. During WWDC23, the Apple UX writing team hosted a wide-ranging Q&A that covered everything from technical concepts to inspiring content to whether apps should have “character.”

Q&A with the Apple UX writing team View now

NEWS

Download the Apple Developer app on visionOS

Apple Developer has come to Apple Vision Pro. Experience a whole new way to catch up on WWDC videos, browse news and features, and stay up to date on the latest Apple frameworks and technologies.

Download Apple Developer from the App Store

VIDEOS

Dive into Xcode Cloud, Apple Pay, and network selection

This month’s new videos cover a lot of ground. Learn how to connect your source repository with Xcode Cloud, find out how to get started with Apple Pay on the Web, and discover how your app can automatically select the best network for an optimal experience.

Connect your project to Xcode Cloud Watch now Get started with Apple Pay on the Web Watch now Adapt to changing network conditions Watch now

BEHIND THE DESIGN

Rebooting an inventive puzzle game for visionOS

Bringing the mind-bending puzzler Blackbox to Apple Vision Pro presented Ryan McLeod with a challenge and an opportunity like nothing he'd experienced before. Find out how McLeod and team are making the Apple Design Award-winning game come to life on the infinite canvas. Then, catch up on our Apple Vision Pro developer interviews and Q&As with Apple experts.

Blackbox: Rebooting an inventive puzzle game for visionOS View now Apple Vision Pro developer stories and Q&As View now

MEET WITH APPLE EXPERTS

Sign up for developer activities

This month, you can learn to minimize churn and win back subscribers in an online session hosted by App Store experts, and meet with App Review to explore best practices for a smooth review process. You can also request to attend an in-person lab in Cork, Ireland, to help develop your alternative app marketplace on iOS in the European Union. View the full schedule of activities.

DOCUMENTATION

Explore and create with new and updated docs

• Track specific points in world space: In this new sample app, you’ll learn to use world anchors along with an ARKit session’s WorldTrackingProvider to create coherence and continuity in a 3D world.
• Explore over 400 newly localized SF symbols: Download the latest version of SF Symbols to browse the updates.
• Preview your app's interface in Xcode: Iterate designs quickly and preview your displays across Apple devices.
• Set up or add a Border Router to your Thread network: Configure a Border Router as a bridge between the Thread and Wi-Fi or Ethernet networks in a home.

View the full list of new resources.

Discover what’s new in the Human Interface Guidelines.

NEWS

Catch up on the latest updates

• Swift Student Challenge applications are open: Learn about past Challenge winners and get everything you need to create an awesome app playground.
• App Store Connect API 3.2: Manage your apps on the App Store for Apple Vision Pro and download new Sales and Trends install reports, including information about historical first annual installs.
• New StoreKit entitlement: If your app offers in-app purchases on the App Store for iPhone or iPad in the United States, you can include a link to your website to let people know of other ways to purchase your digital goods or services.
• New reports and sign-in options: You’ll soon be able to view over 50 new reports to help measure your apps’ performance. And you can take advantage of new flexibility when asking users to sign in to your app.
• App distribution in the European Union: We’re sharing some changes to iOS, Safari, and the App Store, impacting developers’ apps in the EU to comply with the Digital Markets Act.
• App Store Review Guideline update: Check out the latest changes to support updated policies and provide clarification.

Subscribe to Hello Developer

Want to get Hello Developer in your inbox? Make sure you’ve opted in to receive emails about developer news and events by updating your email preferences in your developer account.

Share your thoughts

We’d love to hear from you. If you have suggestions for our activities or stories, please let us know.

The best-in-class calendar app Fantastical has more than a decade of history, a shelf full of awards, and plenty of well-organized fans on iPad, iPhone, Mac, and Apple Watch. Yet Michael Simmons, CEO and lead product designer for Flexibits, the company behind Fantastical, says the Apple Vision Pro app is “the best version we’ve ever made.” We asked Simmons about what he’s learned while building for visionOS, his experiences visiting the developer labs, and what advice he’d give fellow developers bringing their apps to Vision Pro.

What was your initial approach to bringing Fantastical from iPad to Apple Vision Pro?

The first thing we did was look at the platform to see if a calendar app made sense. We thought: “Could we do something here that’s truly an improvement?” When the answer was yes, we moved on to, “OK, what are the possibilities?” And of course, visionOS gives you unlimited possibilities. You’re not confined to borders; you have the full canvas of the world to create on.

We wanted to take advantage of that infinite canvas. But we also needed to make sure Fantastical felt right at home in visionOS. People want to feel like there’s a human behind the design — especially in our case, where some customers have been with us for almost 13 years. There’s a legacy there, and an expectation that what you’ll see will feel connected to what we’ve done for more than a decade.

I play guitar, so to me it felt like learning an instrument.

Michael Simmons, CEO and lead product designer for Flexibits

In the end, it all felt truly seamless, so much so that once Fantastical was finished, we immediately said, “Well, let’s do [the company’s contacts app] Cardhop too!”

Was there a moment when you realized, “We’ve really got something here”?

It happened as instantly as it could. I play guitar, so to me it felt like learning an instrument. One day it just clicks — the songs, the notes, the patterns — and feels like second nature. For me, it felt like those movies where a musical prodigy feels the music flowing out of them.

How did you approach designing for visionOS?

We focused a lot on legibility of the fonts, buttons, and other screen elements. The opaque background didn’t play well with elements from other operating systems, for example, so we tweaked it. We stayed consistent with design language, used system-provided colors as much as possible, built using mainly UIKit, and used SwiftUI for ornaments and other fancy Vision Pro elements. It’s incredible how great the app looked without us needing to rewrite a bunch of code.

How long did the process take?

It was five months from first experiencing the device to submitting a beautiful app. Essentially, that meant three months to ramp up — check out the UI, explore what was doable, and learn the tools and frameworks — and two more months to polish, refine, and test. That’s crazy fast! And once we had that domain knowledge, we were able to do Cardhop in two months. So I’d say if you have an iPad app and that knowledge, it takes just months to create a Apple Vision Pro version of your app.

What advice would you give to other developers looking to bring their iPhone or iPad apps to Apple Vision Pro?

Make sure your app is appropriate for the platform. Look at the device — all of its abilities and possibilities — and think about how your app would feel with unlimited real estate. And if your app makes sense — and most apps do make sense — and you’re already developing for iPad, iPhone, or Mac, it’s a no-brainer to bring it to Apple Vision Pro.

Download Fantastical from the App Store

We recently announced changes to iOS, Safari, and the App Store impacting developers’ apps in the European Union (EU) to comply with the Digital Markets Act (DMA), supported by more than 600 new APIs, a wide range of developer tools, and related documentation.

And we’re continuing to provide new ways for developers to understand and utilize these changes, including:

• Online consultations to discuss alternative distribution on iOS, alternative payments on the App Store, linking out to purchase on their webpage, new business terms, and more.
• Labs to help develop alternative app marketplaces on iOS.

Developers who have agreed to the new business terms can now use new features in App Store Connect and the App Store Connect API to set up marketplace distribution and marketplace apps, and use TestFlight to beta test these features. TestFlight also supports apps using alternative browser engines, and alternative payments through payment service providers and linking out to a webpage.

And soon, you’ll be able to view expanded app analytics reports for the App Store and iOS.

Apps uploaded to App Store Connect must be built with Xcode 15 for iOS 17, iPadOS 17, tvOS 17, or watchOS 10, starting April 29, 2024.

Learn about submitting your apps

Every year, the Swift Student Challenge aims to inspire students to create amazing app playgrounds that can make life better for their communities — and beyond.

Have an app idea that’s close to your heart? Now’s your chance to make it happen. Build an app playground and submit by February 25.

All winners receive a year of complimentary membership in the Apple Developer Program and other exclusive awards. And for the first time ever, we’ll award a select group of Distinguished Winners a trip to Apple Park for an incredible in-person experience.

Apply now

Meet with an Apple team member to discuss changes to iOS, Safari, and the App Store impacting apps in the European Union to comply with the Digital Markets Act. Topics include alternative distribution on iOS, alternative payments in the App Store, linking out to purchase on your webpage, new business terms, and more.

Request a 30-minute online consultation to ask questions and provide feedback about these changes.

In addition, if you’re interested in getting started with operating an alternative app marketplace on iOS in the European Union, you can request to attend an in-person lab in Cork, Ireland.

If you’ve ever played Blackbox, you know that Ryan McLeod builds games a little differently.

In the inventive iOS puzzler from McLeod’s studio, Shapes & Stories, players solve challenges not by tapping or swiping but by rotating the device, plugging in the USB cable, singing a little tune — pretty much everything except touching the screen.

“The idea was to get people in touch with the world outside their device,” says McLeod, while ambling along the canals of his Amsterdam home base.

I’m trying to figure out what makes Blackbox tick on iOS, and how to bring that to visionOS. That requires some creative following of my own rules — and breaking some of them.

Ryan McLeod

In fact, McLeod freed his puzzles from the confines of a device screen well before Apple Vision Pro was even announced — which made bringing the game to this new platform a fascinating challenge. On iOS and iPadOS, Blackbox plays off the familiarity of our devices. But how do you transpose that experience to a device people haven’t tried yet? And how do you break boundaries on a canvas that doesn’t have any? “I do love a good constraint,” says McLeod, “but it has been fun to explore the lifting of that restraint. I’m trying to figure out what makes Blackbox tick on iOS, and how to bring that to visionOS. That requires some creative following of my own rules — and breaking some of them.”

After a brief onboarding, the game becomes an all-new visionOS experience that takes advantage of the spatial canvas right from the first level selection. “I wanted something a little floaty and magical, but still grounded in reality,” he says. “I landed on the idea of bubbles. They’re like soap bubbles: They’re natural, they have this hyper-realistic gloss, and they move in a way you’re familiar with. The shader cleverly pulls the reflection of your world into them in this really believable, intriguing way.”

And the puzzles within those bubbles? “Unlike Blackbox on iOS, you’re not going to play this when you’re walking home from school or waiting in line,” McLeod says. “It had to be designed differently. No matter how exciting the background is, or how pretty the sound effects are, it’s not fun to just stare at something, even if it’s bobbing around really nicely.”

Ryan McLeod’s notebook shows pen sketches of what will become Blackbox on Apple Vision Pro.

Now, McLeod cautions that Blackbox is still very much a work in progress, and we’re certainly not here to offer any spoilers. But if you want to go in totally cold, it might be best to skip this next part.

In Blackbox, players interact with the space — and their own senses — to explore and solve challenges. One puzzle involves moving your body in a certain manner; another involves sound, silence, and a blob of molten gold floating like an alien in front of you. A second puzzle involves Morse code. And solving a third puzzle causes part of the scene to collapse into a portal. “Spatial Audio makes the whole thing kind of alarming but mesmerizing,” he says.

There's an advantage to not knowing expected or common patterns.

Ryan McLeod

It's safe to say Blackbox will continue evolving, especially since McLeod is essentially building this plane as he’s flying it — something he views as a positive. “There’s an advantage to not knowing expected or common patterns,” he says. “There’s just so much possibility.”

Download Blackbox for Vision from the App Store

Meet some of the incredible teams building for visionOS, and get answers from Apple experts on spatial design and creating great apps for Apple Vision Pro.

Developer stories “The best version we’ve ever made”: Fantastical comes to Apple Vision Pro View now Blackbox: Rebooting an inventive puzzle game for visionOS View now “The full impact of fruit destruction”: How Halfbrick cultivated Super Fruit Ninja on Apple Vision Pro View now Realizing their vision: How djay designed for visionOS View now JigSpace is in the driver’s seat View now PTC is uniting the makers View now Q&As Q&A: Spatial design for visionOS View now Q&A: Building apps for visionOS View now

The App Store is designed to make it easy to sell your digital goods and services globally, with support for 44 currencies across 175 storefronts.

From time to time, we may need to adjust prices or your proceeds due to changes in tax regulations or foreign exchange rates. These adjustments are made using publicly available exchange rate information from financial data providers to help ensure that prices for apps and in-app purchases remain consistent across all storefronts.

Price updates

On February 13, pricing for apps and in-app purchases* will be updated for the Benin, Colombia, Tajikistan, and Türkiye storefronts. Also, these updates consider the following tax changes:

• Benin: value-added tax (VAT) introduction of 18%

• Tajikistan: VAT rate decrease from 15% to 14%

Prices will be updated on the Benin, Colombia, Tajikistan, and Türkiye storefronts if you haven’t selected one of these as the base for your app or in‑app purchase.*

Prices won’t change on the Benin, Colombia, Tajikistan, or Türkiye storefront if you’ve selected that storefront as the base for your app or in-app purchase.* Prices on other storefronts will be updated to maintain equalization with your chosen base price.

Prices won’t change in any region if your in‑app purchase is an auto‑renewable subscription and won’t change on the storefronts where you manually manage prices instead of using the automated equalized prices.

The Pricing and Availability section of My Apps has been updated in App Store Connect to display these upcoming price changes. As always, you can change the prices of your apps, in‑app purchases, and auto‑renewable subscriptions at any time.

Learn more about managing your prices

View or edit upcoming price changes

Edit your app’s base country or region

Pricing and availability start times by region

Set a price for an in-app purchase

Tax updates

Your proceeds for sales of apps and in-app purchases will change to reflect the new tax rates and updated prices. Exhibit B of the Paid Applications Agreement has been updated to indicate that Apple collects and remits applicable taxes in Benin.

On January 30, your proceeds from the sale of eligible apps and in‑app purchases were modified in the following countries to reflect introductions or changes in VAT rates.

• Benin: VAT introduction of 18%

• Czechia: VAT rate decreased from 10% to 0% for certain eBooks and audiobooks

• Czechia: VAT rate increased from 10% to 12% for certain eNewspapers and Magazines

• Estonia: VAT rate increased from 20% to 22%

• Ireland: VAT rate decreased from 9% to 0% for certain eBooks and audiobooks

• Luxembourg: VAT rate increased from 16% to 17%

• Singapore: GST rate increased from 8% to 9%

• Switzerland: VAT rate increased from 2.5% to 2.6% for certain eNewspapers, magazines, books and audiobooks

• Switzerland: VAT rate increased from 7.7% to 8.1% for all other apps and in-app purchases

• Tajikistan: VAT rate decreased from 15% to 14%

Learn more about your proceeds

View payments and proceeds

Download financial reports

*Excludes auto-renewable subscriptions.

The beta versions of iOS 17.4, iPadOS 17.4, macOS 14.4, tvOS 17.4, and watchOS 10.4 are now available. Get your apps ready by confirming they work as expected on these releases. And to take advantage of the advancements in the latest SDKs, make sure to build and test with Xcode 15.3 beta.

View downloads and release notes

Learn about testing a beta OS

Learn about sending feedback

New analytics reports coming in March for developers everywhere

Developers can also enable new sign-in options for their apps

Today, Apple is introducing new options for how apps globally can deliver in-app experiences to users, including streaming games and mini-programs. Developers can now submit a single app with the capability to stream all of the games offered in their catalog.

Apps will also be able to provide enhanced discovery opportunities for streaming games, mini-apps, mini-games, chatbots, and plug-ins that are found within their apps.

Additionally, mini-apps, mini-games, chatbots, and plug-ins will be able to incorporate Apple’s In-App Purchase system to offer their users paid digital content or services for the first time, such as a subscription for an individual chatbot.

Each experience made available in an app on the App Store will be required to adhere to all App Store Review Guidelines and its host app will need to maintain an age rating of the highest age-rated content included in the app.

The changes Apple is announcing reflect feedback from Apple’s developer community and is consistent with the App Store’s mission to provide a trusted place for users to find apps they love and developers everywhere with new capabilities to grow their businesses. Apps that host this content are responsible for ensuring all the software included in their app meets Apple’s high standards for user experience and safety.

New app analytics

Apple provides developers with powerful dashboards and reports to help them measure their apps’ performance through App Analytics, Sales and Trends, and Payments and Financial Reports. Today, Apple is introducing new analytics for developers everywhere to help them get even more insight into their businesses and their apps’ performance, while maintaining Apple’s long-held commitment to ensure users are not identifiable at an individual level.

Over 50 new reports will be available through the App Store Connect API to help developers analyze their app performance and find opportunities for improvement with more metrics in areas like:

Engagement — with additional information on the number of users on the App Store interacting with a developer’s app or sharing it with others;

Commerce — with additional information on downloads, sales and proceeds, pre-orders, and transactions made with the App Store’s secure In-App Purchase system;

App usage — with additional information on crashes, active devices, installs, app deletions, and more.

Frameworks usage — with additional information on an app’s interaction with OS functionality such as PhotoPicker, Widgets, and CarPlay.

Additional information about report details and access will be available for developers in March.

Developers will have the ability to grant third-party access to their reports conveniently through the API.

More flexibility for sign in options in apps

In line with Apple’s mission to protect user privacy, Apple is updating its App Store Review Guideline for using Sign in with Apple. Sign in with Apple makes it easy for users to sign in to apps and websites using their Apple ID and was built from the ground up with privacy and security in mind. Starting today, developers that offer third-party or social login services within their app will have the option to offer Sign in with Apple, or they will now be able to offer an equivalent privacy-focused login service instead.

We’re sharing some changes to iOS, Safari, and the App Store, impacting developers’ apps in the European Union (EU) to comply with the Digital Markets Act (DMA). These changes create new options for developers who distribute apps in any of the 27 EU member states, and do not apply to apps distributed anywhere else in the world. These options include how developers can distribute apps on iOS, process payments, use web browser engines in iOS apps, request interoperability with iPhone and iOS hardware and software features, access data and analytics about their apps, and transfer App Store user data.

If you want nothing to change for you — from how the App Store works currently in the EU and in the rest of the world — no action is needed. You can continue to distribute your apps only on the App Store and use its private and secure In-App Purchase system.

Learn about the updates

The App Store Review Guidelines have been revised to support updated policies, upcoming features, and to provide clarification. We now also indicate which guidelines only apply to Notarization for iOS apps in the European Union.

The following guidelines have been divided into subsections for the purposes of Notarization for iOS apps in the EU:

• 2.3.1
• 2.5.16
• 4.1
• 4.3
• 4.6
• 5.1.4
• 5.2.4

The following guidelines have been deleted:

• 2.5.7
• 3.2.2(vi)
• 4.2.4
• 4.2.5
• 4.4.3

2.5.6: Added a link to an entitlement to use an alternative web browser engine in your app in the EU.

3.1.6: Moved to 4.9.

3.2.2(ii): Moved to 4.10.

4.7: Edited to set forth new requirements for mini apps, mini games, streaming games, chatbots, and plug-ins.

4.8: Edited to require an additional login service with certain privacy features if you use a third-party or social login service to set up or authenticate a user’s primary account.

4.9: The original version of this rule (Streaming games) has been deleted and replaced with the Apple Pay guideline.

5.1.2(i): Added that apps may not require users to enable system functionalities (e.g., push notifications, location services, tracking) in order to access functionality, content, use the app, or receive monetary or other compensation, including but not limited to gift cards and codes. A version of this rule was originally published as Guideline 3.2.2(vi).

After You Submit — Appeals: Edited to add an updated link for suggestions for changes to the Guidelines.

The term “auto-renewing subscriptions” was replaced with “auto-renewable subscriptions” throughout.

View guidelines

Translations of the guidelines will be available on the Apple Developer website within one month.

We’re so excited applications for the Swift Student Challenge 2024 will open on February 5.

Looking for some inspiration? Learn about past Challenge winners to gain insight into the motivations behind their apps.

Just getting started? Get tools, tips, and guidance on everything you need to create an awesome app playground.

Fruit Ninja has a juicy history that stretches back more than a decade, but Samantha Turner, lead gameplay programmer at the game’s Halfbrick Studios, says the Apple Vision Pro version — Super Fruit Ninja on Apple Arcade — is truly bananas. “When it first came out, Fruit Ninja kind of gave new life to the touchscreen,” she notes, “and I think we have the potential to do something very special here.”

What if players could squeeze juice out of an orange? What if they could rip apart a watermelon and cover the table and walls with juice?

Samantha Turner, lead gameplay programmer at Halfbrick Studios

Turner would know. She’s worked on the Fruit Ninja franchise for nearly a decade, which makes her especially well suited to help grow the game on a new platform. “We needed to understand how to bring those traditional 2D user interfaces into the 3D space,” she says. “We were full of ideas: What if players could squeeze juice out of an orange? What if they could rip apart a watermelon and cover the table and walls with juice?” She laughs, on a roll. “We were really playing with the environment.”

But they also needed to get people into that environment. “That’s where we came up with the flying menu,” she says, referring to the old-timey home screen that’ll feel familiar to Fruit Ninja fans, except for how it hovers in space. “We wanted a friendly and welcoming way to bring people into the immersive space,” explains Turner. “Before we landed on the menu, we were doing things like generating 3D text to put on virtual objects. But that didn’t give us the creative freedom we needed to set the theme for our world.”

To create Super Fruit Ninja, the Halfbrick team worked to bring “traditional 2D interfaces into the 3D space.”

That theme: The good citizens of Fruitasia have discovered a portal to our world — one that magically materializes in the room. “Sensei steps right through the portal,” says Turner, “and you can peek back into their world too.”

Next, Turner and Halfbrick set about creating a satisfying — and splashy — way for people to interact with their space. The main question: What’s the most logical way to launch fruit at people?

“We started with, OK, you have a couple meters square in front of you. What will the playspace look like? What if there’s a chair or a table in the way? How do we work around different scenarios for people in their office or living room or kitchen?” To find their answers, Halfbrick built RealityKit prototypes. “Just being able to see those really opened up the possibilities.” The answer? A set of cannons, arranged in a semicircle at the optimal distance for efficient slashing.

Instead of holding blades, you simply use your hands.

Samantha Turner, lead gameplay programmer at Halfbrick Studios

It also let them move onto the question of how players can carve up a bunch of airborne bananas in a 3D space. The team experimented with a variety of hand motions, but none felt as satisfying as the final result. “Instead of holding blades, you simply use your hands,” she says. “You become the weapon.”

And you’re a powerful weapon. Slice and dice pineapples and watermelons by jabbing with your hands. Send bombs away by pushing them to a far wall, where they harmlessly explode at a distance. Fire shuriken into floating fruit by brushing your palms in an outward direction — a motion Turner particularly likes. “It’s satisfying to see it up close, but when you see it happen far away, you get the full impact of fruit destruction,” she laughs. All were results of hand gesture explorations.

Truffles the pig awaits his reward in Super Fruit Ninja.

“We always knew hands would be the center of the experience,” she says. “We wanted players to be able to grab things and knock them away. And we can tailor the arc of the fruit to make sure it's a comfortable fruit-slicing experience — we’re actually using the vertical position of the device itself to make sure that we're not throwing fruit over your head or too low.”

The result is the most immersive — and possibly most entertaining — Fruit Ninja to date, not just for players but for the creators. “Honestly,” Turner says, “this version is one of my favorites.”

Find Super Fruit Ninja on Apple Arcade

Years ago, early in his professional DJ career, Algoriddim cofounder and CEO Karim Morsy found himself performing a set atop a castle tower on the Italian coast. Below him, a crowd danced in the ruins; before him streched a moonlit-drenched coastline and the Mediterranean Sea. “It was a pretty inspiring environment,” Morsy says, probably wildly underselling this.

Through their app djay, Morsy and Algoriddim have worked to recreate that live DJ experience for nearly 20 years. The best-in-class DJ app started life as boxed software for Mac; subsequent versions for iPad offered features like virtual turntables and beat matching. The app was a smashing success that won an Apple Design Award in both 2011 and 2016.

On Apple Vision Pro, djay transports people to a number of inventive immersive environments.

But Morsy says all that previous work was prologue to djay on the infinite canvas. “When we heard about Apple Vision Pro,” he says, “it felt like djay was this beast that wanted to be unleashed. Our vision — no pun intended — with Algoriddim was to make DJing accessible to everyone,” he says. Apple Vision Pro, he says, represents the realization of that dream. “The first time I experienced the device was really emotional. I wanted to be a DJ since I was a child. And suddenly here were these turntables, and the night sky, and the stars above me, and this light show in the desert. I felt like, ‘This is the culmination of everything. This is the feeling I’ve been wanting people to experience.’”

When we heard about Apple Vision Pro, it felt like djay was this beast that wanted to be unleashed.

Karim Morsy, Algoriddim cofounder and CEO

Getting to that culmination necessitated what Morsy calls “the wildest sprint of our lives.” With a 360-degree canvas to explore, the team rethought the entire process of how people interacted with djay. “We realized that with a decade of building DJ interfaces, we were taking a lot for granted,” he says. “So the first chunk of designing for Apple Vision Pro was going back to the drawing board and saying, ‘OK, maybe this made sense 10 years ago with a computer and mouse, but why do we need it now? Why should people have to push a button to match tempos — shouldn’t that be seamless?’ There was so much we could abstract away.”

Spin in a fully immersive environment, or bring your two turntables into the room with you.

They also thought about environments. djay offers a windowed view, a shared space that brings 3D turntables into your environment, and several forms of full immersion. The app first opens to the windowed view, which should feel familiar to anyone who’s spun on the iPad app: a simple UI of two decks. The volumetric view brings into your room not just turntables, but the app’s key moment: the floating 3D cube that serves as djay’s effects control pad.

But those immersive scenes are where Morsy feels people can truly experience reacting to and feeding off the environment. There’s an LED wall that reflects colors from the artwork of the currently playing song, a nighttime desert scene framed by an arena of lights, and a space lounge — complete with dancing robots — that offers a great view of planet Earth. The goal of those environments is to help create the “flow state” that’s sought by live DJs. “You want to get into a loop where the environment influences you and vice versa,” Morsy says.

From left: Algoriddim’s Karim Morsy, Frederik Seiffert, and Federico Tessmann work on updates to their app with the proper equipment.

In the end, this incredible use of technology serves a very simple purpose: interacting with the music you love. Morsy — a musician himself — points to a piano he keeps in his office. “That piano has had the same interface for hundreds of years,” he says. “That’s what we’re trying to reach, that sweet spot between complexity and ease of use. With djay on Vision Pro, it’s less about, ‘Let’s give people bells and whistles,’ and more, ‘Let’s let them have this experience.’”

Download djay from the App Store

Welcome to Hello Developer. In this Apple Vision Pro-themed edition: Find out how to submit your visionOS apps to the App Store, learn how the team behind djay approached designing for the infinite canvas, and get technical answers straight from Apple Vision Pro engineers. Plus, catch up on the latest news, documentation, and developer activities.

FEATURED

Submit your apps to the App Store for Apple Vision Pro

Apple Vision Pro will have a brand-new App Store, where people can discover and download all the incredible apps available for visionOS. Whether you’ve created a new visionOS app or are making your existing iPad or iPhone app available on Apple Vision Pro, here’s everything you need to know to prepare and submit your app to the App Store.

BEHIND THE DESIGN

Realizing their vision: How djay designed for visionOS

Algoriddim CEO Karim Morsy says Apple Vision Pro represents “the culmination of everything” for his app, djay. In the latest edition of Behind the Design, find out how this incredible team approached designing for the infinite canvas.

Realizing their vision: How djay designed for visionOS View now

Q&A

Get answers from Apple Vision Pro engineers

In this Q&A, Apple Vision Pro engineers answer some of the most frequently asked questions from Apple Vision Pro developer labs all over the world.

Q&A: Building apps for visionOS View now

COLLECTION

Reimagine your enterprise apps on Apple Vision Pro

Discover the languages, tools, and frameworks you’ll need to build and test your apps for visionOS. Explore videos and resources that showcase productivity and collaboration, simulation and training, and guided work. And dive into workflows for creating or converting existing media, incorporating on-device and remote assets into your app, and much more.

Reimagine your enterprise apps on Apple Vision Pro View now

MEET WITH APPLE EXPERTS

Submit your request for developer labs and App Review consultations

Join us this month in the Apple Vision Pro developer labs to get your apps ready for visionOS. With help from Apple, you’ll be able to test, refine, and finalize your apps and games. Plus, Apple Developer Program members can check out one-on-one App Review, design, and technology consultations, offered in English, Spanish, Brazilian Portuguese, and more.

DOCUMENTATION

Check out visionOS sample apps, SwiftUI tutorials, audio performance updates, and more

These visionOS sample apps feature refreshed audio, visual, and timing elements, simplified collision boxes, and performance improvements.

• Hello World: Use windows, volumes, and immersive spaces to teach people about the Earth.

• Happy Beam: Leverage a Full Space to create a game using ARKit.

• Diorama: Design scenes for your visionOS app using Reality Composer Pro.

• Swift Splash: Use RealityKit to create an interactive ride in visionOS.

And these resources and updated tutorials cover iOS 17, accessibility, Live Activities, and audio performance.

• SwiftUI Tutorials: Learn the latest best practices for iOS 17.

• Accessibility Inspector: Review your app’s accessibility experience.

• Starting and updating Live Activities with ActivityKit push notifications: Use push tokens to update and end Live Activities.

• Analyzing audio performance with Instruments: Ensure a smooth and immersive audio experience using Audio System Trace.

View the full list of new resources.

Discover what’s new in the Human Interface Guidelines.

NEWS

Catch up on the latest updates

• Announcing contingent pricing: Give customers discounted pricing when they’re subscribed to a different subscription on the App Store.

• Updated agreements and guidelines now available: Check out the latest changes that have been made to support updated policies and provide clarification.

Subscribe to Hello Developer

Want to get Hello Developer in your inbox? Make sure you’ve opted in to receive emails about developer news and events by updating your email preferences in your developer account.

Share your thoughts

We’d love to hear from you. If you have suggestions for our activities or stories, please let us know.

Over the past few months, Apple experts have fielded questions about visionOS in Apple Vision Pro developer labs all over the world. Here are answers to some of the most frequent questions they’ve been asked, including insights on new concepts like entities, immersive spaces, collision shapes, and much more.

How can I interact with an entity using gestures?

There are three important pieces to enabling gesture-based entity interaction:

1. The entity must have an InputTargetComponent. Otherwise, it won’t receive gesture input at all.
2. The entity must have a CollisionComponent. The shapes of the collision component define the regions that gestures can actually hit, so make sure the collision shapes are specified appropriately for interaction with your entity.
3. The gesture that you’re using must be targeted to the entity you’re trying to interact with (or to any entity). For example:

private var tapGesture: some Gesture {
    TapGesture()
        .targetedToAnyEntity()
        .onEnded { gestureValue in
            
            let tappedEntity = gestureValue.entity
                
            print(tappedEntity.name)
        }
}

It’s also a good idea to give an interactive entity a HoverEffectComponent, which enables the system to trigger a standard highlight effect when the user looks at the entity.

Should I use a window group, an immersive space, or both?

Consider the technical differences between windows, volumes, and immersive spaces when you decide which scene type to use for a particular feature in your app.

Here are some significant technical differences that you should factor into your decision:

1. Windows and volumes from other apps the user has open are hidden when an immersive space is open.
2. Windows and volumes clip content that exceeds their bounds.
3. Users have full control over the placement of windows and volumes. Apps have full control over the placement of content in an immersive space.
4. Volumes have a fixed size, windows are resizable.
5. ARKit only delivers data to your app if it has an open immersive space.

Explore the Hello World sample code to familiarize yourself with the behaviors of each scene type in visionOS.

How can I visualize collision shapes in my scene?

Use the Collision Shapes debug visualization in the Debug Visualizations menu, where you can find several other helpful debug visualizations as well. For information on debug visualizations, check out Diagnosing issues in the appearance of a running app.

Can I position SwiftUI views within an immersive space?

Yes! You can position SwiftUI views in an immersive space with the offset(x:y:) and offset(z:) methods. It’s important to remember that these offsets are specified in points, not meters. You can utilize PhysicalMetric to convert meters to points.

What if I want to position my SwiftUI views relative to an entity in a reality view?

Use the RealityView attachments API to create a SwiftUI view and make it accessible as a ViewAttachmentEntity. This entity can be positioned, oriented, and scaled just like any other entity.

RealityView { content, attachments in
            
    // Fetch the attachment entity using the unique identifier.
    let attachmentEntity = attachments.entity(for: "uniqueID")!
            
    // Add the attachment entity as RealityView content.
    content.add(attachmentEntity)
            
} attachments: {
    // Declare a view that attaches to an entity.
    Attachment(id: "uniqueID") {
        Text("My Attachment")
    }
}

Can I position windows programmatically?

There’s no API available to position windows, but we’d love to know about your use case. Please file an enhancement request. For more information on this topic, check out Positioning and sizing windows.

Is there any way to know what the user is looking at?

As noted in Adopting best practices for privacy and user preferences, the system handles camera and sensor inputs without passing the information to apps directly. There's no way to get precise eye movements or exact line of sight. Instead, create interface elements that people can interact with and let the system manage the interaction. If you have a use case that you can't get to work this way, and as long as it doesn't require explicit eye tracking, please file an enhancement request.

When are the onHover and onContinuousHover actions called on visionOS?

The onHover and onContinuousHover actions are called when a finger is hovering over the view, or when the pointer from a connected trackpad is hovering over the view.

Can I show my own immersive environment textures in my app?

If your app has an ImmersiveSpace open, you can create a large sphere with an UnlitMaterial and scale it to have inward-facing geometry:

struct ImmersiveView: View {
    var body: some View {
        RealityView { content in
            do {
                // Create the sphere mesh.
                let mesh = MeshResource.generateSphere(radius: 10)
                
                // Create an UnlitMaterial.
                var material = UnlitMaterial(applyPostProcessToneMap: false)
                
                // Give the UnlitMaterial your equirectangular color texture.
                let textureResource = try await TextureResource(named: "example")
                material.color = .init(tint: .white, texture: .init(textureResource))
                
                // Create the model.
                let entity = ModelEntity(mesh: mesh, materials: [material])
                // Scale the model so that it's mesh faces inward.
                entity.scale.x *= -1
                
                content.add(entity)
            } catch {
                // Handle the error.
            }
        }
    }
}

I have existing stereo videos. How can I convert them to MV-HEVC?

AVFoundation provides APIs to write videos in MV-HEVC format. For a full example, download the sample code project Converting side-by-side 3D video to multiview HEV.

To convert your videos to MV-HEVC:

• Create an AVAsset for each of the left and right views.
• Use AVOutputSettingsAssistant to get output settings that work for MV-HEVC.
• Specify the horizontal disparity adjustment and field of view (this is asset specific). Here’s an example:

var compressionProperties = outputSettings[AVVideoCompressionPropertiesKey] as! [String: Any]
        
        // Specifies the parallax plane.
        compressionProperties[kVTCompressionPropertyKey_HorizontalDisparityAdjustment as String] = horizontalDisparityAdjustment
        
        // Specifies the horizontal FOV (90 degrees is chosen in this case.)
        compressionProperties[kCMFormatDescriptionExtension_HorizontalFieldOfView as String] = horizontalFOV

• Create an AVAssetWriterInputTaggedPixelBufferGroupAdaptor as the input for your AVAssetWriter.
• Create an AVAssetReader for each of the left and right video tracks.
• Read the left and right tracks, then append matching samples to the tagged pixel buffer group adaptor:

// Create a tagged buffer for each stereoView.
                        let taggedBuffers: [CMTaggedBuffer] = [
                            .init(tags: [.videoLayerID(0), .stereoView(.leftEye)], pixelBuffer: leftSample.imageBuffer!),
                            .init(tags: [.videoLayerID(1), .stereoView(.rightEye)], pixelBuffer: rightSample.imageBuffer!)
                        ]
                        
                        // Append the tagged buffers to the asset writer input adaptor.
                        let didAppend = adaptor.appendTaggedBuffers(taggedBuffers,
                                                    withPresentationTime: leftSample.presentationTimeStamp)

How can I light my scene in RealityKit on visionOS?

You can light your scene in RealityKit on visionOS by:

• Using a system-provided automatic lighting environment that updates based on real-world surroundings.
• Providing your own image-based lighting via an ImageBasedLightComponent. To see an example, create a new visionOS app, select RealityKit as the Immersive Space Renderer, and select Full as the Immersive Space.

I see that CustomMaterial isn’t supported on visionOS. Is there a way I can create materials with custom shading?

You can create materials with custom shading in Reality Composer Pro using the Shader Graph. A material created this way is accessible to your app as a ShaderGraphMaterial, so that you can dynamically change inputs to the shader in your code.

For a detailed introduction to the Shader Graph, watch Explore materials in Reality Composer Pro.

How can I position entities relative to the position of the device?

In an ImmersiveSpace, you can get the full transform of the device using the queryDeviceAnchor(atTimestamp:) method.

Learn more about building apps for visionOS Q&A: Spatial design for visionOS View now Spotlight on: Developing for visionOS View now Spotlight on: Developer tools for visionOS View now

Sample code contained herein is provided under the Apple Sample Code License.

Apple Vision Pro will have a brand-new App Store, where people can discover and download incredible apps for visionOS. Whether you’ve created a new visionOS app or are making your existing iPad or iPhone app available on Apple Vision Pro, here’s everything you need to know to prepare and submit your app to the App Store.

Find out more

The Apple Developer Program License Agreement has been revised to support updated policies and provide clarification. The revisions include:

• Definitions, Section 3.3.3(N): Updated "Tap to Present ID" to "ID Verifier"

• Definitions, Section 14.10: Updated terms regarding governing law and venue

• Section 3.3: Reorganized and categorized provisions for clarity

• Section 3.3.3(B): Clarified language on privacy and third-party SDKs

• Section 6.7: Updated terms regarding analytics

• Section 12: Clarified warranty disclaimer language

• Attachment 1: Updated terms for use of Apple Push Notification Service and Local Notifications

• Attachment 9: Updated terms for Xcode Cloud compute hours included with Apple Developer Program membership

View full terms and conditions

Contingent pricing for subscriptions on the App Store — a new feature that helps you attract and retain subscribers — lets you give customers a discounted subscription price as long as they’re actively subscribed to a different subscription. It can be used for subscriptions from one developer or two different developers. We’re currently piloting this feature and will be onboarding more developers in the coming months. If you’re interested in implementing contingent pricing in your app, you can start planning today and sign up to get notified when more details are available in January.

Learn about contingent pricing and sign up to get notified

The beta versions of iOS 17.3, iPadOS 17.3, macOS 14.3, tvOS 17.3, and watchOS 10.3 are now available. Get your apps ready by confirming they work as expected on these releases. And to take advantage of the advancements in the latest SDKs, make sure to build and test with Xcode 15.2 beta.

View downloads and release notes

Learn about testing a beta OS

Learn about sending feedback

Welcome to Hello Developer. In this edition: Check out new videos on Game Center and the Journaling Suggestions API, get visionOS guidance straight from the spatial design team, meet three App Store Award winners, peek inside the time capsule that is Ancient Board Game Collection, and more.

VIDEOS

Manage Game Center with the App Store Connect API

In this new video, discover how you can use the App Store Connect API to automate your Game Center configurations outside of App Store Connect on the web.

Manage Game Center with the App Store Connect API Watch now

And find out how the new Journaling Suggestions API can help people reflect on the small moments and big events in their lives through your app — all while protecting their privacy.

Discover the Journaling Suggestions API Watch now

Q&A

Get your spatial design questions answered

What’s the best way to make a great first impression in visionOS? What’s a “key moment”? And what are some easy methods for making spatial computing visual design look polished? Get answers to these questions and more.

Q&A: Spatial design for visionOS View now

FEATURED

Celebrate the winners of the 2023 App Store Awards

Every year, the App Store celebrates exceptional apps that improve people’s lives while showcasing the highest levels of technical innovation, user experience, design, and positive cultural impact. Find out how the winning teams behind Finding Hannah, Photomator, and Unpacking approached their incredible work this year.

“We’re trying to drive change": Meet three App Store Award-winning teams View now

Missed the big announcement? Check out the full list of 2023 winners.

NEWS

Xcode Cloud now included with membership

Starting January 2024, all Apple Developer Program memberships will include 25 compute hours per month on Xcode Cloud as a standard, with no additional cost. Learn more.

BEHIND THE DESIGN

Travel back in time with Ancient Board Game Collection

Klemens Strasser’s Ancient Board Game Collection blends the new and the very, very old. Its games date back centuries: Hnefatafl is said to be nearly 1,700 years old, while the Italian game Latrunculi is closer to 2,000. “I found a book on ancient board games by an Oxford professor and it threw me right down a rabbit hole,” Strasser says. Find out how the Austria-based developer and a team of international artists gave these ancient games new life.

With Ancient Board Game Collection, Klemens Strasser goes back in time View now

DOCUMENTATION

Get creative with 3D immersion, games, SwiftUI, and more

This month’s new sample code, tutorials, and documentation cover everything from games to passing control between apps to addressing reasons for common crashes. Here are a few highlights:

• Game Center matchmaking essentials, rules, and testing: Learn how to create custom matchmaking rules for better matches between players and test the rules before applying them.

• Incorporating real-world surroundings in an immersive experience: This sample code project helps you use scene reconstruction in ARKit to give your app an idea of the shape of the person’s surroundings and to bring your app experience into their world.

• Creating a macOS app: Find out how to bring your SwiftUI app to macOS, including adding new views tailored to macOS and modifying others to work better across platforms.

• Creating a watchOS app: Find out how to bring your SwiftUI app to watchOS, including customizing SwiftUI views to display the detail and list views on watchOS.

View the full list of new resources.

View what’s new in the Human Interface Guidelines.

NEWS

Catch up on the latest updates

• App Store holiday schedule: We’ll remain open throughout the holiday season and look forward to accepting your submissions. However, reviews may take a bit longer to complete from December 22 to 27.

• Sandbox improvements: Now you can change a test account’s storefront, adjust subscription renewal rates, clear purchase history, simulate interrupted purchase flows directly on iPhone or iPad, and test Family Sharing.

• New software releases: Build your apps using the latest developer tools and test them on this week’s OS releases. Download Xcode 15.1 RC, and the RC versions of iOS 17.2, iPadOS 17.2,  macOS 14.2,  tvOS 17.2, and watchOS 10.2.

Subscribe to Hello Developer

Want to get Hello Developer in your inbox? Make sure you’ve opted in to receive emails about developer news and events by updating your email preferences in your developer account.

Share your thoughts

We’d love to hear from you. If you have suggestions for our activities or stories, please let us know.

Spatial computing offers unique opportunities and challenges when designing apps and games. At WWDC23, the Apple design team hosted a wide-ranging Q&A to help developers explore designing for visionOS. Here are some highlights from that conversation, including insights on the spectrum of immersion, key moments, and sound design.

What’s the best way to make a great first impression on this platform?

While it depends on your app, of course, starting in a window is a great way to introduce people to your app and let them control the amount of immersion. We generally recommend not placing people into a fully immersive experience right away — it’s better to make sure they’re oriented in your app before transporting them somewhere else.

What should I consider when bringing an existing iPadOS or iOS app to visionOS?

Think about a key moment where your app would really shine spatially. For example, in the Photos app for visionOS, opening a panoramic photo makes the image wrap around your field of view. Ask yourself what that potential key moment — an experience that isn’t bound by a screen — is for your app.

From a more tactical perspective, consider how your UI will need to be optimized for visionOS. To learn more, check out “Design for spatial user interfaces”.

Design for spatial user interfaces Watch now Can you say a bit more about what you mean by a “key moment”?

A key moment is a feature or interaction that takes advantage of the unique capabilities of visionOS. (Think of it as a spatial or immersive highlight in your app.) For instance, if you’re creating a writing app, your key moment might be a focus mode in which you immerse someone more fully in an environment or a Spatial Audio soundscape to get them in the creative zone. That’s just not possible on a screen-based device.

I often use a grid system when designing for iOS and macOS. Does that still apply here?

Definitely! The grid can be very useful for designing windows, and point sizes translate directly between platforms. Things can get more complex when you’re designing elements in 3D, like having nearby controls for a faraway element. To learn more, check out “Principles of spatial design.”

Principles of spatial design Watch now What’s the best way to test Apple Vision Pro experiences without the device?

You can use the visionOS simulator in Xcode to recreate system gestures, like pinch, drag, tap, and zoom.

What’s the easiest way to make my spatial computing design look polished?

As a starting point, we recommend using the system-provided UI components. Think about hover shapes, how every element appears by default, and how they change when people look directly at them. When building custom components or larger elements like 3D objects, you'll also need to customize your hover effects.

What interaction or ergonomic design considerations should I keep in mind when designing for visionOS?

Comfort should guide experiences. We recommend keeping your main content in the field of view, so people don't need to move their neck and body too much. The more centered the content is in the field of view, the more comfortable it is for the eyes. It's also important to consider how you use input. Make sure you support system gestures in your app so people have the option to interact with content indirectly (using their eyes to focus an element and hand gestures, like a pinch, to select). For more on design considerations, check out “Design considerations for vision and motion.”

Design considerations for vision and motion Watch now Are there design philosophies for fully immersive experiences? Should the content wrap behind the person’s head, above them, and below them?

Content can be placed anywhere, but we recommend providing only the amount of immersion needed. Apps can create great immersive experiences without taking over people's entire surroundings. To learn more, check out the Human Interface Guidelines.

Human Interface Guidelines: Immersive experiences

Are there guidelines for creating an environment for a fully immersive experience?

First, your environment should have a ground plane under the feet that aligns with the real world. As you design the specifics of your environment, focus on key details that will create immersion. For example, you don't need to render all the details of a real theater to convey the feeling of being in one. You can also use subtle motion to help bring an environment to life, like the gentle movement of clouds in the Mount Hood environment.

What else should I consider when designing for spatial computing?

Sound design comes to mind. When designing for other Apple platforms, you may not have placed as much emphasis on creating audio for your interfaces because people often mute sounds on their devices (or it's just not desirable for your current experience). With Apple Vision Pro, sound is crucial to creating a compelling experience.

People are adept at understanding their surroundings through sound, and you can use sound in your visionOS app or game to help people better understand and interact with elements around them. When someone presses a button, for example, an audio cue helps them recognize and confirm their actions. You can position sound spatially in visionOS so that audio comes directly from the item a person interacts with, and the system can use their surroundings to give it the appropriate reverberation and texture. You can even create spatial soundscapes for scenes to make them feel more lifelike and immersive.

For more on designing sound for visionOS, check out “Explore immersive sound design.”

Explore immersive sound design Watch now Learn more

For even more on designing for visionOS, check out more videos, the Human Interface Guidelines, and the Apple Developer website.

Develop your first immersive app Watch now Get started with building apps for spatial computing Watch now Build great games for spatial computing Watch now

Human Interface Guidelines

Design for visionOS

Every year, the App Store Awards celebrate exceptional apps that improve people’s lives while showcasing the highest levels of technical innovation, user experience, design, and positive cultural impact.

This year’s winners were drawn from a list of 40 finalists that included everything from flight trackers to retro games to workout planners to meditative puzzles. In addition to exhibiting an incredible variety of approaches, styles, and techniques, these winners shared a thoughtful grasp and mastery of Apple tools and technologies.

Meet the winners and finalists of the 2023 App Store Awards

For the team behind the hidden-object game Finding Hannah, their win for Cultural Impact is especially meaningful. “We’re trying to drive change on the design level by bringing more personal stories to a mainstream audience,” says Franziska Zeiner, cofounder and managing director of the Fein Games studio, from her Berlin office. “Finding Hannah is a story that crosses three generations, and each faces the question: How truly free are we as women?”

Finding Hannah’s story is driven by quiet, meaningful interactions between the main character, her mother, and her grandmother.

The Hannah of Finding Hannah is a 39-year-old Berlin resident trying to navigate a career, relationships (including with her best friend/ex, Emma), and the meaning of true happiness. Players complete a series of found-object puzzles that move along the backstory of Hannah’s mother and grandmother to add a more personal touch to the game.

We’re trying to drive change on the design level by bringing more personal stories to a mainstream audience.

Franziska Zeiner, Fein Games co-founder and managing director

To design the art for the game’s different time periods, the team tried a different approach. “We wanted an art style that was something you’d see more on social media than in games,” says Zeiner. “The idea was to try to reach people who weren’t gamers yet, and we thought we’d most likely be able to do that if we found a style that hadn’t been seen in games before. And I do think that added a new perspective, and maybe helped us stand out a little bit.”

Learn more about Finding Hannah

Download Finding Hannah from the App Store

Pixelmator, the team behind Mac App of the Year winner Photomator, is no stranger to awards consideration, having received multiple Apple Design Awards in addition to their 2023 App Store Award. The latter is especially meaningful for the Lithuania-based team. “We’re still a Mac-first company,” says Simonas Bastys, lead developer of the Pixelmator team. “For what we do, Mac adds so many benefits to the user experience.”

Photomator’s Smart Deband feature is just one of its many powerful features on Mac.

To start adding Photomator to their portfolio of Mac apps back in 2020, Bastys and his team of engineers decided against porting over their UIKit and AppKit code. Instead, they set out to build Photomator specifically for Mac with SwiftUI. “We had a lot of experience with AppKit,” Bastys says, “but we chose to transition to SwiftUI to align with cutting-edge, future-proof technologies.”

The team zeroed in on maximizing performance, assuming that people would need to navigate and manipulate large libraries. They also integrated a wealth of powerful editing tools, such as repairing, debanding, batch editing, and much more. Deciding what to work on — and what to prioritize — is a constant source of discussion. “We work on a lot of ideas in parallel,” Bastys says, “and what we prioritize comes up very naturally, based on what’s ready for shipment and what new technology might be coming.” This year, that meant a focus on HDR.

We had a lot of experience with AppKit, but we wanted to create with native Mac technologies.

Simonas Bastys, lead developer of the Pixelmator team

How does Bastys and the Pixelmator team keep growing after so long? “This is the most exciting field in computer science to me,” says Bastys. “There’s so much to learn. I’m only now starting to even understand the depth of human vision and computer image processing. It’s a continuous challenge. But I see endless possibilities to make Photomator better for creators.”

Learn more about Photomator

Download Photomator from the Mac App Store

To create the Cultural Impact winner Unpacking, the Australian duo of creative director Wren Brier and technical director Tim Dawson drew on more than a decade of development experience. Their game — part zen puzzle, part life story — follows a woman through the chapters of her life as she moves from childhood bedroom to first apartment and beyond. Players solve puzzles by placing objects around each new dwelling while learning more about her history with each new level — something Brier says is akin to a detective story.

“You have this series of places, and you’re opening these hints, and you’re piecing together who this person is,” she says from the pair’s home in Brisbane.

Brier and Dawson are partners who got the idea for Unpacking from — where else? — one of their own early moves. “There was something gamelike about the idea of finishing one box to unlock the one underneath,” Brier says. “You’re completing tasks, placing items together on shelves and in drawers. Tim and I started to brainstorm the game right away.”

Unpacking has no visible characters and no dialogue. Its emotionally rich story is told entirely through objects in boxes.

While the idea was technically interesting, says Dawson, the pair was especially drawn to the idea of unpacking as a storytelling vehicle. “This is a really weird example,” laughs Dawson, “but there’s a spatula in the game. That’s a pretty normal household item. But what does it look like? Is it cheap plastic, something that maybe this person got quickly? Is it damaged, like they’ve been holding onto it for a while? Is it one of those fancy brands with a rubberized handle? All of that starts painting a picture. It becomes this really intimate way of knowing a character.”

There was something game-like about the idea of finishing one box to unlock the one underneath.

Wren Brier, Unpacking creative director

Those kinds of discussions — spatula-based and otherwise — led to a game that includes novel uses of technology, like the haptic feedback you get when you shake a piggy bank or board game. But its diverse, inclusive story is the reason behind its App Store Award nod for Cultural Impact. Brier and Dawson say players of all ages and backgrounds have shared their love of the game, drawn by the universal experience of moving yourself, your belongings, and your life into a new home. “One guy even sent us a picture of his bouldering shoes and told us they were identical to the ones in the game,” laughs Brier. “He said, ‘I have never felt so seen.’”

Learn more about Unpacking

Download Unpacking from the App Store

Klemens Strasser will be the first to tell you that prior to launching his Ancient Board Game Collection, he wasn’t especially skilled at Hnefatafl. “Everybody knows chess and everybody knows backgammon,” says the indie developer from his home office in Austria, “but, yeah, I didn’t really know that one.”

Today, Strasser runs what may well be the hottest Hnefatafl game in town. The Apple Design Award finalist for Inclusivity Ancient Board Game Collection comprises nine games that reach back not years or decades but centuries — Hnefatafl (or Viking chess) is said to be nearly 1,700 years old, while the Italian game Latrunculi is closer to 2,000. And while games like Konane, Gomoku, and Five Field Kono might not be household names, Strasser’s collection gives them fresh life through splashy visuals, a Renaissance faire soundtrack, efficient onboarding, and even a bit of history.

At roughly 1,700 years old, Hnefatafl is one of the more ancient titles in Klemens Strasser’s Ancient Board Game Collection.

Strasser is a veteran of Flexibits (Fantastical, Cardhop) and the developer behind such titles as Letter Rooms, Subwords and Elementary Minute (for which he won a student Apple Design Award in 2015). But while he was familiar with Nine Men’s Morris — a game popular in Austria he’d play with his grandma — he wasn’t exactly well versed in third-century Viking pastimes until a colleague brought Hnefatafl to his attention three years ago. “It was so different than the traditional symmetric board games I knew,” he says. “I really fell in love with it.”

Less appealing were mobile versions of Hnefatafl, which Strasser found lacking. “The digital versions of many board games have a certain design,” he says. “It’s usually pretty skeuomorphic, with a lot of wood and felt and stuff like that. That just didn’t make me happy. And I thought, ‘Well, if I can’t find one I like, I’ll build it.’”

I found a book on ancient board games by an Oxford professor and it threw me right down a rabbit hole.

Klemens Strasser

Using SpriteKit, Strasser began mocking up an iOS Hnefatafl prototype in his downtime. A programmer by trade — “I’m not very good at drawing stuff,” he demurs — Strasser took pains to keep his side project as simple as possible. “I always start with minimalistic designs for my games and apps, but these are games you play with some stones and maybe a piece of paper,” he laughs. “I figured I could build that myself.”

His Hnefatafl explorations came surprisingly fast — enough so that he started wondering what other long-lost games might be out there. “I found a book on ancient board games by an Oxford professor and it threw me right down a rabbit hole,” Strasser laughs. “I kept saying, ‘Oh, that’s an interesting game, and that’s also an interesting game, and that’s another interesting game.’” Before he knew it, his simple Hnefatafl mockup had become a buffet of games. “And I still have a list of like 20 games I’d still like to digitize,” he says.

Italian designer Carmine Acierno brought a mosaic-inspired design to Nine Men’s Morris.

For the initial designs of his first few games, Strasser tried to maintain the simple style of his Hnefatafl prototype. “But I realized that I couldn’t really represent the culture and history behind each game in that way,” he says, “so I hired people who live where the games are from.”

That’s where Ancient Board Game Collection really took off. Strasser began reaching out to artists from each ancient game’s home region — and the responses came fast. Out went the minimalist version of Ancient Board Game Collection, in came a richer take, powered by a variety of cultures and design styles. For Hnefatafl, Strasser made a fortuitous connection with Swedish designer Albina Lind. “I sent her a few images of like Vikings and runestones, and in two hours she came up with a design that was better than anything I could have imagined,” he says. “If I hadn’t run into her, I might not have finished the project. But it was so perfect that I had to continue.”

Stockholm-based artist Albina Lind leapt right into designing Hnefatafl. “I instantly thought, ‘Well, this is my cup of tea,’” she says.

Lind was a wise choice. The Stockholm-based freelance artist had nearly a decade of experience designing games, including her own Norse-themed adventure, Dragonberg. “I instantly thought, ‘Well, this is my cup of tea,’” Lind says. Her first concept was relatively realistic, all dark wood and stone textures, before she settled on a more relaxed, animation-inspired style. “Sometimes going unreal, going cartoony, is even more work than being realistic,” she says with a laugh. Lind went on to design two additional ancient games: Dablot, the exact origins of which aren’t known but it which first turned up in 1892, and Halatafl, a 14th century game of Scandinavian origin.

Work arrived from around the globe. Italian designer Carmine Acierno contributed a mosaic-inspired version of Nine Men’s Morris; Honolulu-based designer Anna Fujishige brought a traditional Hawaiian flavor to Konane. And while the approach succeeded in preserving more of each game’s authentic heritage, it did mean iterating with numerous people over numerous emails. One example: Tokyo-based designer Yosuke Ando pitched changing Strasser’s initial designs for the Japanese game Gomoku altogether. “Klemens approached me initially with the idea of the game design to be inspired by ukiyo-e (paintings) and musha-e (woodblocks prints of warriors),” Ando says. “Eventually, we decided to focus on samurai warrior armor from musha-e, deconstructing it, and simplifying these elements into the game UI.”

Honolulu-based designer Anna Fujishige brought a traditional Hawaiian flavor to Konane (at left), while the Tokyo designer Yosuke Ando’s ideas for Gomoku were inspired by samurai warrior armor.

While the design process continued, Strasser worked on an onboarding strategy — times nine. As you might suspect, it can be tricky to explain the rules and subtleties of 500-year-old games from lost civilizations, and Strasser’s initial approach — walkthroughs and puzzles designed to teach each game step by step — quickly proved unwieldy. So he went in the other direction, concentrating on writing “very simple, very understandable” rules with short gameplay animations that can be accessed at any time. “I picked games that could be explained in like three or four sentences,” he says. “And I wanted to make sure it was all accessible via VoiceOver.”

Strasser designed every part of Ancient Board Game Collection with accessibility in mind.

In fact, accessibility remained a priority throughout the entire project. (He wrote his master’s thesis on accessibility in Unity games.) As an Apple Design Award finalist for Inclusivity, Ancient Board Game Collection shines with best-in-class VoiceOver adoption, as well as support for Reduce Motion, Dynamic Type, and high-contrast game boards. “It’s at least some contribution to making everything better for everyone,” he says.

I picked games that could be explained in like three or four sentences. And I wanted to make sure it was all accessible via VoiceOver.

Klemens Strasser

Ancient Board Game Collection truly is for everyone, and it’s hardly hyperbole to call it a novel way to introduce games like Hnefatafl to a whole new generation of players. “Most people,” he says, “are just surprised that they’ve never heard of these games.”

Learn more about Ancient Board Game Collection

Download Ancient Board Game Collection from the App Store

Behind the Design is a series that explores design practices and philosophies from each of the winners and finalists of the Apple Design Awards. In each story, we go behind the screens with the developers and designers of these award-winning apps and games to discover how they brought their remarkable creations to life.

Explore more of the 2023 Behind the Design series

Xcode Cloud, the continuous integration and delivery service built into Xcode, accelerates the development and delivery of high-quality apps. It brings together cloud-based tools that help you build apps, run automated tests in parallel, deliver apps to testers, and view and manage user feedback.

We’re pleased to announce that as of January 2024, all Apple Developer Program memberships will include 25 compute hours per month on Xcode Cloud as a standard, with no additional cost. If you’re already subscribed to Xcode Cloud for free, no additional action is required on your part. And if you haven’t tried Xcode Cloud yet, now is the perfect time to start building your app for free in just a few minutes.

Learn more about Xcode Cloud

Third-party SDK privacy manifest and signatures. Third-party software development kits (SDKs) can provide great functionality for apps; they can also have the potential to impact user privacy in ways that aren’t obvious to developers and users. As a reminder, when you use a third-party SDK with your app, you are responsible for all the code the SDK includes in your app, and need to be aware of its data collection and use practices.

At WWDC23, we introduced new privacy manifests and signatures for SDKs to help app developers better understand how third-party SDKs use data, secure software dependencies, and provide additional privacy protection for users. Starting in spring 2024, if your new app or app update submission adds a third-party SDK that is commonly used in apps on the App Store, you’ll need to include the privacy manifest for the SDK. Signatures are also required when the SDK is used as a binary dependency. This functionality is a step forward for all apps, and we encourage all SDKs to adopt it to better support the apps that depend on them.

Learn more and view list of commonly-used third-party SDKs

New use cases for APIs that require reasons. When you upload a new app or app update to App Store Connect that uses an API (including from third-party SDKs) that requires a reason, you’ll receive a notice if you haven’t provided an approved reason in your app’s privacy manifest. Based on the feedback we received from developers, the list of approved reasons has been expanded to include additional use cases. If you have a use case that directly benefits users that isn’t covered by an existing approved reason, submit a request for a new reason to be added.

Starting in spring 2024, in order to upload your new app or app update to App Store Connect, you’ll be required to include an approved reason in the app’s privacy manifest which accurately reflects how your app uses the API.

Learn more and view list of APIs and approved reasons

Have questions on designing your app or implementing a technology? We’re here to help you find answers, no matter where you are in your development journey. One-on-one consultations with Apple experts in December — and newly published dates in January — are available now.

We’ll have lots more consultations and other activities in store for 2024 — online, in person, and in multiple languages.

Browse the schedule

The busiest season on the App Store is almost here! Make sure your apps and games are up to date and ready in advance of the upcoming holidays. We’ll remain open throughout the season and look forward to accepting your submissions. On average, 90% of submissions are reviewed in less than 24 hours. However, reviews may take a bit longer to complete from December 22 to 27.

Learn about submitting apps

Join us in celebrating the work of these outstanding developers from around the world!

Discover the winners

Every year, the App Store celebrates exceptional apps that improve people’s lives while showcasing the highest levels of technical innovation, user experience, design, and positive cultural impact. This year we’re proud to recognize nearly 40 outstanding finalists. Winners will be announced in the coming weeks.

Learn about the finalists

APPLE VISION PRO APPS FOR ENTERPRISE

PTC’s CAD products have been at the forefront of the engineering industry for more than three decades. And the company’s AR/VR CTO, Stephen Prideaux-Ghee, has too. “I’ve been doing VR for 30 years, and I’ve never had this kind of experience before,” he says. “I almost get so blasé about VR. But when I had [Apple Vision Pro] on, walking around digital objects and interacting with others in real time — it’s one of those things that makes you stop in your tracks."

Prideaux-Ghee says Apple Vision Pro offers PTC an opportunity to bring together components of the engineering and manufacturing process like never before. “Our customers either make stuff, or they make the machines that help somebody else make stuff,” says Prideaux-Ghee. And that stuff can be anything from chairs to boats to spaceships. “I can almost guarantee that the chair you’re sitting on is made by one of our customers,” he says.

As AR/VR CTO (which he says means “a fancy title for somebody who comes up with crazy ideas and has a reasonably good chance of implementing them”), Prideaux-Ghee describes PTC’s role as the connective tissue between the multiple threads of production. “When you’ve got a big, international production process, it's not always easy for the people involved to talk to each other. Our thought was: ‘Hey, we’re in the middle of this, so let’s come up with a simple mechanism that allows everyone to do so.’”

I’ve been doing VR for 30 years, and I’ve never had this kind of experience before.

Stephen Prideaux-Ghee, AR/VR CTO of PTC

For PTC, it’s all about communication and collaboration. “You can be a single user and get a lot of value from our app,” says Prideaux-Ghee, “but it really starts when you have multiple people collaborating, either in the same room or over FaceTime and SharePlay.” He speaks from experience; PTC has tested its app with everyone in the same space, and spread out across different countries.

"It enables some really interesting use cases, especially with passthrough," says Prideaux-Ghee. "You can use natural human interactions with a remote device."

Development is going fast. In recent weeks, PTC completed a prototype in which changes made on their iPad CAD software immediately reflect in Apple Vision Pro. “Before, we weren’t able to drive from the CAD software,” he explains. “Now, one person can run our CAD software pretty much unmodified and another can see changes instantly in 3D, at full scale. It’s really quite magical.”

Read more

Businesses of all kinds and sizes are exploring the possibilities of the infinite canvas of Apple Vision Pro — and realizing ideas that were never before possible.

JigSpace is in the driver’s seat View now

In this series of videos, you can learn how to level up your pro app or game by harnessing the speed and power of Apple platforms. We’ll discover GPU advancements, explore new Metal profiling tools for M3 and A17 Pro, and share performance best practices for Metal shaders.

Explore GPU advancements in M3 and A17 Pro Watch now Discover new Metal profiling tools for M3 and A17 Pro Watch now Learn performance best practices for Metal shaders Watch now

New to developing games for Apple platforms? Familiarize yourself with the tools and technologies you need to get started.

APPLE VISION PRO APPS FOR ENTERPRISE

It’s one of the most memorable images from JigSpace’s early Apple Vision Pro explorations: A life-size Alfa Romeo C43 Formula 1 car, dark cherry red, built to scale, reflecting light from all around, and parked right in the room. The camera pans back over the car’s front wings; a graceful animation shows airflow over the wings and body.

Numa Bertron, cofounder and chief technology officer for JigSpace — the creative and collaborative company that partnered with Alfa Romeo for the model — has been in the driver’s seat for the project from day one and still wasn’t quite prepared to see the car in the spatial environment. “The first thing everyone wanted to do was get in,” he says. “Everyone was stepping over the side to get in, even though you can just, you know, walk through.”

The F1 car is just one component of JigSpace’s grand plans for visionOS. The company is leaning on the new platform to create avenues of creativity and collaboration never before possible.

Bertron brings up one of JigSpace’s most notable “Jigs” (the company term for spatial presentations): an incredibly detailed model of a jet engine. “On iPhone, it’s an AR model that expands and looks awesome, but it’s still on a screen,” he explains. On Apple Vision Pro, that engine becomes a life-size piece of roaring, spinning machinery — one that people can walk around, poke through, and explore in previously unimaginable detail.

“One of our guys is a senior 3D artist,” says Bertron, “and the first time he saw one of his models in space at scale — and walked around it with his hands free — he actually cried.”

We made that F1 Jig with tools everyone can use.

Numa Bertron, JigSpace cofounder and chief technology officer

Getting there required some background learning. Prior to developing for visionOS, Bertron had no experience with SwiftUI. “We’d never gone into Xcode, so we started learning SwiftUI and RealityKit. Honestly, we expected some pain. But since everything is preset, we had really nice rounded corners, blur effects, and smooth scrolling right off the bat.”

JigSpace is designing a “full-on collaboration platform,” says Bertron.

For people who’ve used JigSpace on iOS, the visionOS version will look familiar but feel quite different. “We asked ourselves: What's the appropriate size for an object in front of you?” asks Bertron. “What’s comfortable? Will that model be on the table or on the floor? Spatial computing introduces so many more opportunities — and more decisions.”

In the case of the F1 example, it also offers a chance to level up visually. “For objects that big, we’d never been able to achieve this level of fidelity on smaller devices, so we always had to compromise,” says Bertron. In visionOS, they were free to keep adding. “We’d look at a prototype and say, ‘Well, this still runs, so let’s double the size of the textures and add more screws and more effects!’” (It’s not just about functionality, but fun as well. You can remove a piece of the car — like a full-sized tire — and throw it backwards over your head.)

The incredible visual achievement is matched by new powers of collaboration. “If I point at the tire, the other person sees me, no matter where they are,” says Bertron. “I can grab the wheel and give it to them. I can circle something we need to fix, I can leave notes or record audio. It’s a full-on collaboration platform.” And it’s also for everyone, not just F1 drivers and aerospace engineers. “We made that F1 Jig with tools everyone can use.”

Download JigSpace from the App Store

Read more

Businesses of all kinds and sizes are exploring the possibilities of the infinite canvas of Apple Vision Pro — and realizing ideas that were never before possible.

PTC is uniting the makers View now

Games simply don’t get much cuter than Kimono Cats, a casual cartoon adventure about two cats on a date (awww) that creator Greg Johnson made as a present for his wife. “I wanted to make a game she and I could play together,” says the Maui-based indie developer, “and I wanted it to be sweet, creative, and romantic.”

Kimono Cats is all three, and it’s also spectacularly easy to play and navigate. This Apple Design Award finalist for Interaction in games is set in a Japanese festival full of charming mini-games — darts, fishing, and the like — that are designed for maximum simplicity and casual fun. Players swipe up to throw darts at balloons that contain activities, rewards, and sometimes setbacks that threaten to briefly derail the date. Interaction gestures (like scooping fish) are simple and rewarding, and the gameplay variation and side activities (like building a village for your feline duo) fit right in.

“I wanted something sweet, creative, and romantic,” says Kimono Cats developer Greg Johnson.

“I’m a huge fan of Hayao Miyazaki and that kind of heartfelt, slower-paced style,” says Johnson. “What you see in Kimono Cats is a warmth and appreciation for Japanese culture.”

You also see a game that’s a product of its environment. Johnson’s been creating games since 1983 and is responsible for titles like Starfight, ToeJam and Earl, Doki-Doki Universe, and many more. His wife, Sirena, is a builder of model houses — miniature worlds not unlike the village in Kimono Cats. And the game’s concept was a reaction to the early days of COVID-19 lockdowns. “When we started building this in 2020, everybody was under so much weight and pressure,” he says. “We felt like this was a good antidote.”

Early Kimono Cats sketches show how the characters’ cute look was established early in the design process.

To start creating the game, Johnson turned to artist and longtime collaborator Ferry Halim, as well as Tanta Vorawatanakul and Ferrari Duanghathai, a pair of developers who happen to be married. “Tanta and Ferrari would provide these charming little characters, and Ferry would come in to add animations — like moving their eyes,” says Johnson. “We iterated a lot on animating the bubbles — how fast they were moving, how many there were, how they were obscured. That was the product of a lot of testing and listening all throughout the development process.”

When we started with this in 2020, everybody was under so much weight and pressure. We felt like this was a good antidote.

Greg Johnson, Kimono Cats

Johnson notes that players can select characters without gender distinction — a detail that he and the Kimono Cats team prioritized from day one. “Whenever any companion kisses the player character on the cheek, a subtle rainbow will appear in the sky over their heads,” Johnson says. “This allows the gender of the cat characters to be open to interpretation by the users.”

Kimono Cats was designed with the simple goal of bringing smiles. “The core concept of throwing darts at bubbles isn't an earth-shaking idea by any stretch,” says Johnson, “but it was a way to interact with the storytelling that I hadn’t seen before, and the festival setting felt like a natural match.”

Learn more about Kimono Cats

Find Kimono Cats on Apple Arcade

Behind the Design is a series that explores design practices and philosophies from each of the winners and finalists of the Apple Design Awards. In each story, we go behind the screens with the developers and designers of these award-winning apps and games to discover how they brought their remarkable creations to life.

Explore more of the 2023 Behind the Design series

Businesses of all kinds and sizes are exploring the possibilities of the infinite canvas of Apple Vision Pro — and realizing ideas that were never before possible. We caught up with two of those companies — JigSpace and PTC — to find out how they’re approaching the new world of visionOS.

JigSpace is in the driver’s seat View now PTC is uniting the makers View now

Discover the languages, tools, and frameworks you’ll need to build and test your apps in visionOS. Explore videos and resources that showcase productivity and collaboration, simulation and training, and guided work. And dive into workflows for creating or converting existing media, incorporating on-device and remote assets into your app, and much more.

Apple Vision Pro at work Keynote Watch now Keynote (ASL) Watch now Platforms State of the Union Watch now Platforms State of the Union (ASL) Watch now Design for Apple Vision Pro

WWDC sessions

Design for spatial input Watch now Design for spatial user interfaces Watch now Principles of spatial design Watch now Design considerations for vision and motion Watch now Explore immersive sound design Watch now

Sample code, articles, documentation, and resources

Destination Video

Diorama

Hello World

Happy Beam

Apple Design Resources

Design for visionOS

Developer paths to Apple Vision Pro

WWDC sessions

Go beyond the window with SwiftUI Watch now Meet SwiftUI for spatial computing Watch now Meet ARKit for spatial computing Watch now What’s new in SwiftUI Watch now Discover Observation in SwiftUI Watch now Enhance your spatial computing app with RealityKit Watch now Build spatial experiences with RealityKit Watch now Evolve your ARKit app for spatial experiences Watch now Create immersive Unity apps Watch now Bring your Unity VR app to a fully immersive space Watch now Meet Safari for spatial computing Watch now Rediscover Safari developer features Watch now Design for spatial input Watch now Explore the USD ecosystem Watch now Explore USD tools and rendering Watch now

Sample code, articles, documentation, and resources

Unity – Unity for visionOS

Unity – XR Interaction Toolkit package

Unity – How Unity builds applications for Apple platforms

three.js – webGL and WebXR library

babylon.js – webGL and WebXR library

PlayCanvas – webGL and WebXR library

w3.org – Model element

AOUSD – Alliance for OpenUSD

Immersiveweb – WebXR Device API

WebKit.org – Bug tracking for WebKit open source project

A-Frame WebXR framework

Frameworks to explore

WWDC sessions

Discover streamlined location updates Watch now Meet Core Location Monitor Watch now Meet MapKit for SwiftUI Watch now What's new in MapKit Watch now Build spatial SharePlay experiences Watch now Share files with SharePlay Watch now Design spatial SharePlay experiences Watch now Discover Quick Look for spatial computing Watch now Create 3D models for Quick Look spatial experiences Watch now Explore pie charts and interactivity in Swift Charts Watch now Elevate your windowed app for spatial computing Watch now Create a great spatial playback experience Watch now Deliver video content for spatial experiences Watch now

Sample code, articles, documentation, and resources

Placing content on detected planes

Incorporating real-world surroundings in an immersive experience

Tracking specific points in world space

Tracking preregistered images in 3D space

Explore a location with a highly detailed map and Look Around

Drawing content in a group session

Supporting Coordinated Media Playback

QuickLook example files

Visualizing your app’s data

Adopting live updates in Core Location

Monitoring location changes with Core Location

Access enterprise data and assets

WWDC sessions

Meet Swift OpenAPI Generator Watch now Advances in Networking, Part 1 Watch now Advances in App Background Execution Watch now The Push Notifications primer Watch now Power down: Improve battery consumption Watch now Build robust and resumable file transfers Watch now Efficiency awaits: Background tasks in SwiftUI Watch now Use async/await with URLSession Watch now Meet SwiftData Watch now Explore the USD ecosystem Watch now What’s new in App Store server APIs Watch now

Sample code, articles, documentation, and resources

grpc-swift

swift-protobuf

Apple is proud to support and uplift the next generation of student developers, creators, and entrepreneurs. The Swift Student Challenge has given thousands of students the opportunity to showcase their creativity and coding capabilities through app playgrounds, and build real-world skills that they can take into their careers and beyond. From connecting their peers to mental health resources to identifying ways to support sustainability efforts on campus, Swift Student Challenge participants use their creativity to develop apps that solve problems they’re passionate about.

We’re releasing new coding resources, working with community partners, and announcing the Challenge earlier than in previous years so students can dive deep into Swift and the development process — and educators can get a head start in supporting them.

Applications will open in February 2024 for three weeks.

New for 2024, out of 350 overall winners, we’ll recognize 50 Distinguished Winners for their outstanding submissions and invite them to join us at Apple in Cupertino for three incredible days next summer.

Learn more

Ready to level up your app or game? Join us around the world for a new set of developer labs, consultations, sessions, and workshops, hosted in person and online throughout November and December.

You can explore:

• App Store activities: Learn about discovery, engagement, in-app events, custom product pages, subscription best practices, and much more.
• Apple Vision Pro developer labs: Apply to attend a lab in Cupertino, London, Munich, New York City, Shanghai, Singapore, Sydney, or Tokyo.
• Apple Vision Pro activities: Learn to design and build an entirely new universe of apps and games for visionOS.
• Design and technology consultations: Sign up for one-on-one guidance on app design, technology implementation, and more.

Discover activities in multiple time zones and languages.

Browse the full schedule

The App Store’s commerce and payments system was built to enable you to conveniently set up and sell your products and services on a global scale in 44 currencies across 175 storefronts. Apple administers tax on behalf of developers in over 70 countries and regions and provides you with the ability to assign tax categories to your apps and in‑app purchases.

Periodically, we make updates to rates, categories, and agreements to accommodate new regulations and rate changes in certain regions. As of today, the following updates have been made in App Store Connect.

Tax rates

Your proceeds from the sale of eligible apps and in‑app purchases (including auto‑renewable subscriptions) have been increased to reflect the following reduced value-added tax (VAT) rates. Prices on the App Store haven’t changed.

• Austria: Reduced VAT rates for certain apps in the Video tax category
• Cyprus: Reduced VAT rate of 3% for certain apps in the following tax categories: Books, News Publications, Audiobooks, Magazines and other periodicals
• Vietnam: Eliminated VAT for certain apps in the following tax categories: Books, News Publications, Magazines, and other periodicals

Tax categories

• New Boosting category: Apps and/or in-app purchases that offer resources to provide exposure, visibility, or engagement to enhance the prominence and reach of specific content that’s experienced or consumed in app (such as videos, sales of “boosts” in social media apps, listings, and/or other forms of user-generated content).
• New attribute for books: Textbook or other educational publication used for teaching and studying between ages 5 to 18
• New attributes for videos: Exclusively features live TV broadcasting and/or linear programming. Public TV broadcasting, excluding shopping or infomercial channels.

If any of these categories or attributes are relevant to your apps or in-app purchases, you can review and update your selections in the Pricing and Availability section of My Apps.

Learn about setting tax categories

Paid Applications Agreement

• Exhibit C Section 1.2.2: Updated language to clarify the goods and services tax (GST) requirements for developers on the Australia storefront.

The beta versions of iOS 17.2, iPadOS 17.2, macOS 14.2, tvOS 17.2, and watchOS 10.2 are now available. Get your apps ready by confirming they work as expected on these releases. And to take advantage of the advancements in the latest SDKs, make sure to build and test with Xcode 15.1 beta.

To check if a known issue from a previous beta release has been resolved or if there’s a workaround, review the latest release notes. Please let us know if you encounter an issue or have other comments. We value your feedback, as it helps us address issues, refine features, and update documentation.

View downloads and release notes

Learn about testing a beta OS

Learn about sending feedback

TestFlight provides an easy way to get feedback on beta versions of your apps, so you can publish on the App Store with confidence. Now, improved controls in App Store Connect let you better evaluate tester engagement and manage participation to help you get the most out of beta testing. Sort testers by status and engagement metrics (like sessions, crashes, and feedback), and remove inactive testers who haven’t engaged. You can also filter by device and OS, and even select relevant testers to add to a new group.

Learn about managing testers

Learn about TestFlight

Watch the October 30 event at apple.com.

The Push Notifications Console now includes metrics for notifications sent in production through the Apple Push Notification service (APNs). With the console’s intuitive interface, you’ll get an aggregated view of delivery statuses and insights into various statistics for notifications, including a detailed breakdown based on push type and priority.

Introduced at WWDC23, the Push Notifications Console makes it easy to send test notifications to Apple devices through APNs.

Learn more

We’re thrilled with the excitement and enthusiasm from developers around the world at the Apple Vision Pro developer labs, and we’re pleased to announce new labs in New York City and Sydney. Join us to test directly on the device and connect with Apple experts for help with taking your visionOS, iPadOS, and iOS apps even further on this exciting new platform. Labs also take place in Cupertino, London, Munich, Shanghai, Singapore, and Tokyo.

Submit a lab request

Learn about other ways to work with Apple to prepare for visionOS.

The team behind Plex has a brilliant strategy for dealing with bugs and addressing potential issues: Find them first.

“We’ve got a pretty good process in place,” says Steve Barnegren, Plex senior software engineer on Apple platforms, “and when that’s the case, things don’t go wrong.”

Launched in 2009, Plex is designed to serve as a “global community for streaming content,” says engineering manager Alex Stevenson-Price, who’s been with Plex for more than seven years. A combination streaming service and media server, Plex aims to cover the full range of the streaming experience — everything from discovery to content management to organizing watchlists.

This allows us more time to investigate the right solutions.

Ami Bakhai, Plex product manager for platforms and partners

To make it all run smoothly, the Plex team operates on a six-week sprint, offering regular opportunities to think in blocks, define stop points in their workflow, and assess what’s next. “I’ve noticed that it provides more momentum when it comes to finalizing features or moving something forward,” says Ami Bakhai, product manager for platforms and partners. “Every team has their own commitments. This allows us more time to investigate the right solutions.”

The Plex team iterates, distributes, and releases quickly — so testing features and catching issues can be a tall order. (Plex releases regular updates during their sprints for its tvOS flagship, iOS, iPadOS, and macOS apps.)

Though Plex boasts a massive reach across all the platforms, it’s not powered by a massive number of people. The fully remote team relies on a well-honed mix of developer tools (like Xcode Cloud and TestFlight), clever internal organization, Slack integration, and a thriving community of loyal beta testers that stretches back more than a decade. “We’re relatively small,” says Danni Hemberger, Plex director of product marketing, “but we’re mighty.”

Over the summer, the Plex team made a major change to their QA process: Rather than bringing in their QA teams right before the release, they shifted QA to a continuous process that unfolds over every pull request. “The QA team would find something right at the end, which is when they’d start trying to break everything,” laughs Barnegren. “Now we can say, ‘OK, ten features have gone in, and all of them have had QA eyes on them, so we’re ready to press the button.’”

Now we can say, ‘OK, ten features have gone in, and all of them have had QA eyes on them, so we’re ready to press the button.'

Steve Barnegren, Plex senior software engineer on Apple platforms

The continuous QA process is a convenient mirror to the continuous delivery process. Previously, Plex tested before a new build was released to the public. Now, through Xcode Cloud, Plex sends nightly builds to all their employees, ensuring that everyone has access to the latest version of the app.

Once the release has been hammered out internally, it moves on to Plex’s beta testing community, which might be more accurately described as a beta testing city. It numbers about 8,000 people, some of whom date back to Plex’s earliest days. “That constant feedback loop is super valuable, especially when you have power users that understand your core product,” says Stevenson-Price.

All this feedback and communication is powered by TestFlight and Plex’s customer forums. “This is especially key because we have users supplying personal media for parts of the application, and that can be in all kinds of rare or esoteric formats,” says Barnegren.

[CI] is a safety net. Whenever you push code, your app is being tested and built in a consistent way. That’s so valuable, especially for a multi-platform app like ours.

Alex Stevenson-Price, Plex engineering manager

To top it all off, this entire process is automated with every new feature and every new bug fix. Without any extra work or manual delivery, the Plex team can jump right on the latest version — an especially handy feature for a company that’s dispersed all over the globe. “It’s a great reminder of ‘Hey, this is what’s going out,’ and allows my marketing team to stay in the loop,” says Hemberger.

It’s also a great use of a continuous integration system (CI). “I’m biased from my time spent as an indie dev, but I think all indie devs should try a CI like Xcode Cloud,” says Stevenson-Price. “I think some indies don’t always see the benefit on paper, and they’ll say, ‘Well, I build the app myself, so why do I need a CI to build it for me?’ But it’s a safety net. Whenever you push code, your app is being tested and built in a consistent way. That’s so valuable, especially for a multi-platform app like ours. And there are so many tools at your disposal. Once you get used to that, you can’t go back.”

Learn more about Plex

Download Plex from the App Store

Steffan Glynn’s Automatoys is a mix between a Rube Goldberg machine and a boardwalk arcade game — and there’s a very good reason why.

In 2018, the Cardiff-based developer visited the Musée Mécanique, a vintage San Francisco arcade packed with old-timey games, pinball machines, fortune tellers, and assorted gizmos. On that same trip, he stopped by an exhibit of Rube Goldberg sketches that showcased page after page of wildly intricate machines. “It was all about the delight of the pointless and captivating,” Glynn says. “There was a lot of crazy inspiration on that trip.”

An early sketch of the ramps, mazes, and machines that combine to create the puzzles in Automatoys.

That inspiration turned into Automatoys, an Apple Design Award finalist for Interaction in games. Automatoys is a single-touch puzzler in which players roll their marble from point A to point B by navigating a maze of ramps, elevators, catapults, switches, and more. True to its roots, the game is incredibly tactile; every switch and button feels lifelike, and players even insert a virtual coin to launch each level. And it unfolds to a relaxing and jazzy lo-fi soundtrack. “My brief to the sound designer was, ‘Please make this game less annoying,’” Glynn laughs.

While Automatoys’ machines may be intricate, its controls are anything but. Every button, claw, and catapult is controlled by a single tap. “And it doesn’t matter where you tap — the whole machine moves at once,” Glynn says. The mechanic doesn’t just make the game remarkably simple to learn; it also creates a sense of discovery. “I like that moment when the player is left thinking, ‘OK, well, I guess I’ll just start tapping and find out what happens.’”

To create levels in Automatoys, Steffan Glynn worked directly in the 3D space, starting with a basic model (top left) and creating obstacles until he reached a finished whole (bottom right).

To design each of the game’s 12 levels, Glynn first sketched his complex contraptions in Procreate. The ideas came fast and furious, but he found that building what he’d envisioned in his sketches proved elusive — so he changed his strategy. “I started playing with shapes directly in 3D space,” he says. “Once a level had a satisfying form, I’d then try to imagine what sort of obstacle each part could be. One cylinder would become a ferris wheel, another would become a spinning helix for the ball to climb, a square panel would become a maze, and so on.”

Getting your marble from point A to point B is as simple as this.

The game was a four-year passion project for Glynn, a seasoned designer who in 2018 left his gig with State of Play (where he contributed to such titles as Lumino City and Apple Design Award winner INKS.) to focus on creating “short, bespoke” games. There was just one catch: Though he had years of design experience, he’d never written a single line of code. To get up to speed, he threw himself into video tutorials and hands-on practice.

Welsh developer Steffan Glynn set out on his own in 2018 to create “short, bespoke” games.

In short order, Glynn was creating Unity prototypes of what would become Automatoys. “As a designer, being able to prototype and test ideas is incredibly liberating. When you have those tools, you can quickly try things out and see for yourself what works.”

Learn more about Automatoys

Download Automatoys from the App Store

Behind the Design is a series that explores design practices and philosophies from each of the winners and finalists of the Apple Design Awards. In each story, we go behind the screens with the developers and designers of these award-winning apps and games to discover how they brought their remarkable creations to life.

Explore more of the 2023 Behind the Design series

Find out about our latest activities (including more Apple Vision Pro developer lab dates), learn how the Plex team embraced Xcode Cloud, discover how the inventive puzzle game Automatoys came to life, catch up on the latest news, and more.

Meet with Apple Experts

Hosted in person and online, our developer activities are for everyone, no matter where you are on your development journey. Find out how to enhance your existing app or game, refine your design, or launch a new project. Explore the list of upcoming activities worldwide.

Get ready for a new round of Apple Vision Pro developer lab dates

Developers have been thrilled to experience their apps and games in the labs, and connect with Apple experts to help refine their ideas and answer questions. Ben Guerrette, chief experience officer at Spool, says, “That kind of learning experience is incredibly valuable.” Developer and podcaster David Smith says, “The first time you see your own app running for real is when you get the audible gasp.” Submit a lab request.

You can also request Apple Vision Pro compatibility evaluations. We’ll evaluate your apps and games directly on Apple Vision Pro to make sure they behave as expected and send you the results.

“Small but mighty”: Go behind the scenes with Plex

Discover how the streaming service and media player uses developer tools like Xcode Cloud to maintain a brisk release pace. “We’re relatively small,” says Danni Hemberger, director of product marketing at Plex, “but we’re mighty.”

“Small but mighty”: How Plex serves its global community View now Meet the mind behind Automatoys

“I like the idea of a moment where players are left to say, ‘Well, I guess I’ll just start tapping and see what happens,’” says Steffan Glynn of Apple Design Award finalist Automatoys, an inspired puzzler in which players navigate elaborate contraptions with a single tap. Find out how Glynn brought his Rube Goldberg-inspired game to life.

The gorgeous gadgets of Automatoys View now Catch up on the latest news and updates

Make sure you’re up to date on feature announcements, important guidance, new documentation, and more.

• Get ready with the latest beta releases: Build your apps using the latest developer tools and test them on the most recent OS releases. Download Xcode 15.1 beta, and the beta 2 versions of iOS 17.1, iPadOS 17.1, macOS 14.1, tvOS 17.1, and watchOS 10.1.

• Use RealityKit to create an interactive ride in visionOS: The developer sample project “Swift Splash” leverages RealityKit and Reality Composer Pro to create a waterslide by combining modular slide pieces. And once you finish your ride, you can release an adventurous goldfish to try it out.

• Take your iPad and iPhone apps even further on Apple Vision Pro: A brand‑new App Store will launch with Apple Vision Pro, featuring apps and games built for visionOS, as well as hundreds of thousands of iPad and iPhone apps that run great on visionOS too.

• App Store Connect API 3.0: This release includes support for Game Center, pre-orders by region, and more.

• Debugging universal links: Investigate why your universal links are opening in Safari instead of your app.

Share your thoughts

We’d love to hear from you. If you have suggestions for our activities or stories, please let us know.

The beta versions of iOS 17.1, iPadOS 17.1, macOS 14.1, tvOS 17.1, and watchOS 10.1 are now available. Get your apps ready by confirming they work as expected on these releases. And to take advantage of the advancements in the latest SDKs, make sure to build and test with Xcode 15.

To check if a known issue from a previous beta release has been resolved or if there’s a workaround, review the latest release notes. Please let us know if you encounter an issue or have other feedback. We value your feedback, as it helps us address issues, refine features, and update documentation.

View downloads and release notes

Learn about testing a beta OS

Learn about sending feedback

Join us around the world for a variety of sessions, consultations, labs, and more — tailored for you.

Apple developer activities are for everyone, no matter where you are on your development journey. Activities take place all year long, both online and in person around the world. Whether you’re looking to enhance your existing app or game, refine your design, or launch a new project, there’s something for you.

Learn more

Offering your app or game for pre-order is a great way to build awareness and excitement for your upcoming releases on the App Store. And now you can offer pre-orders on a regional basis. People can pre-order your app in a set of regions that you choose, even while it’s available for download in other regions at the same time. With this new flexibility, you can expand your app to new regions by offering it for pre-order and set different release dates for each region.

Learn about pre-orders

Learn how to manage your app’s availability

iOS 17, iPadOS 17, macOS Sonoma, tvOS 17, and watchOS 10 will soon be available to customers worldwide. Build your apps and games using the Xcode 15 Release Candidate and latest SDKs, test them using TestFlight, and submit them for review to the App Store. You can now start deploying seamlessly to TestFlight and the App Store from Xcode Cloud. With exciting new capabilities, as well as major enhancements across languages, frameworks, tools, and services, you can deliver even more unique experiences on Apple platforms.

Xcode and Swift. Xcode 15 enables you to code and design your apps faster with enhanced code completion, interactive previews, and live animations. Swift unlocks new kinds of expressive and intuitive APIs by introducing macros. The new SwiftData framework makes it easy to persist data using declarative code. And SwiftUI brings support for creating more sophisticated animations with phases and keyframes, and simplified data flows using the new Observation framework.

Widgets and Live Activities. Widgets are now interactive and run in new places, like StandBy on iPhone, the Lock Screen on iPad, the desktop on Mac, and the Smart Stack on Apple Watch. With SwiftUI, the system adapts your widget’s color and spacing based on context, extending its usefulness across platforms. Live Activities built with WidgetKit and ActivityKit are now available on iPad to help people stay on top of what’s happening live in your app.

Metal. The new game porting toolkit makes it easier than ever to bring games to Mac and the Metal shader converter dramatically simplifies the process of converting your game’s shaders and graphics code. Scale your games and production renderers to create even more realistic and detailed scenes with the latest updates to ray tracing. And take advantage of many other enhancements that make it even simpler to deliver fantastic games and pro apps on Apple silicon.

App Shortcuts. When you adopt App Shortcuts, your app’s key features are now automatically surfaced in Spotlight, letting people quickly access the most important views and actions in your app. A new design makes running your app’s shortcuts even simpler and new natural language capabilities let people execute your shortcuts with their voice with more flexibility.

App Store. It’s now even simpler to merchandise your in-app purchases and subscriptions across all platforms with new SwiftUI views in StoreKit. You can also test more of your product offerings using the latest enhancements to StoreKit testing in Xcode, the Apple sandbox environment, and TestFlight. With pre-orders by region, you can build customer excitement by offering your app in new regions with different release dates. And with the most dynamic and personalized app discovery experience yet, the App Store helps people find more apps through tailored recommendations based on their interests and preferences.

And more. Learn about advancements in machine learning, Object Capture, Maps, Passkeys, SharePlay, and so much more.

Starting in April 2024, apps submitted to the App Store must be built with Xcode 15 and the iOS 17 SDK, tvOS 17 SDK, or watchOS 10 SDK (or later).

Download Xcode

Learn more about submitting apps

Apple Entrepreneur Camp supports underrepresented founders and developers, and encourages the pipeline and longevity of these entrepreneurs in technology. Building on the success of our alumni from cohorts for female*, Black, and Hispanic/Latinx founders, starting this fall, we’re expanding our reach to welcome professionals from Indigenous backgrounds who are looking to enhance and grow their existing app-driven businesses. Attendees benefit from one-on-one code-level guidance, receive insight, inspiration, and unprecedented access to Apple engineers and experts, and become part of the extended global network of Apple Entrepreneur Camp alumni.

Applications are now open for founders and developers from these groups who have either an existing app on the App Store, a functional beta build in TestFlight, or the equivalent. Attendees will join us online starting in October 2023. We welcome eligible entrepreneurs with app-driven organizations to apply and we encourage you to share these details with those who may be interested.

Apply by September 24, 2023.

Learn more

* Apple believes that gender expression is a fundamental right. We welcome all women to apply to this program.

A brand‑new App Store will launch with Apple Vision Pro, featuring apps and games built for visionOS, as well as hundreds of thousands of iPad and iPhone apps that run great on visionOS too. Users can access their favorite iPad and iPhone apps side by side with new visionOS apps on the infinite canvas of Apple Vision Pro, enabling them to be more connected, productive, and entertained than ever before. And since most iPad and iPhone apps run on visionOS as is, your app experiences can easily extend to Apple Vision Pro from day one — with no additional work required.

Timing. Starting this fall, an upcoming developer beta release of visionOS will include the App Store. By default, your iPad and/or iPhone apps will be published automatically on the App Store on Apple Vision Pro. Most frameworks available in iPadOS and iOS are also included in visionOS, which means nearly all iPad and iPhone apps can run on visionOS, unmodified. Customers will be able to use your apps on visionOS early next year when Apple Vision Pro becomes available.

Making updates, if needed. In the case that your app requires a capability that is unavailable on Apple Vision Pro, App Store Connect will indicate that your app isn’t compatible and it won’t be made available. To make your app available, you can provide alternative functionality, or update its UIRequiredDeviceCapabilities. If you need to edit your existing app’s availability, you can do so at any time in App Store Connect.

To see your app in action, use the visionOS simulator in Xcode 15 beta. The simulator lets you interact with and easily test most of your app’s core functionality. To run and test your app on an Apple Vision Pro device, you can submit your app for a compatibility evaluation or sign up for a developer lab.

Beyond compatibility. If you want to take your app to the next level, you can make your app experience feel more natural on visionOS by building your app with the visionOS SDK. Your app will adopt the standard visionOS system appearance and you can add elements, such as 3D content tuned for eyes and hands input. To learn how to build an entirely new app or game that takes advantage of the unique and immersive capabilities of visionOS, view our design and development resources.

Watch the replay from September 12 at apple.com.

The Apple Developer Program License Agreement has been revised to support upcoming features and updated policies, and to provide clarification. The revisions include:

• Definitions, Section 3.3.39: Specified requirements for use of the Journaling Suggestions API.

• Schedule 1 Exhibit D Section 3 and Schedules 2 and 3 Exhibit E Section 3: Added language about the Digital Services Act (DSA) redress options available to developers based in the European Union.

• Schedule 1 Section 6.3 and Schedules 2 and 3 Section 7.3: Added clarifying language that the content moderation process is subject to human and systematic review and action pursuant to notices of illegal and harmful content.

View full terms and conditions

As CEO of Flexibits, the team behind successful apps like Fantastical and Cardhop, Michael Simmons has spent more than a decade minding every last facet of his team’s work. But when he brought Fantastical to the Apple Vision Pro labs in Cupertino this summer and experienced it for the first time on the device, he felt something he wasn’t expecting.

“It was like seeing Fantastical for the first time,” he says. “It felt like I was part of the app.”

That sentiment has been echoed by developers around the world. Since debuting in early August, the Apple Vision Pro labs have hosted developers and designers like Simmons in London, Munich, Shanghai, Singapore, Tokyo, and Cupertino. During the day-long lab appointment, people can test their apps, get hands-on experience, and work with Apple experts to get their questions answered. Developers can apply to attend if they have a visionOS app in active development or an existing iPadOS or iOS app they’d like to test on Apple Vision Pro.

Learn more about Apple Vision Pro developer labs

For his part, Simmons saw Fantastical work right out of the box. He describes the labs as “a proving ground” for future explorations and a chance to push software beyond its current bounds. “A bordered screen can be limiting. Sure, you can scroll, or have multiple monitors, but generally speaking, you’re limited to the edges,” he says. “Experiencing spatial computing not only validated the designs we’d been thinking about — it helped us start thinking not just about left to right or up and down, but beyond borders at all.”

And as not just CEO but the lead product designer (and the guy who “still comes up with all these crazy ideas”), he came away from the labs with a fresh batch of spatial thoughts. “Can people look at a whole week spatially? Can people compare their current day to the following week? If a day is less busy, can people make that day wider? And then, what if like you have the whole week wrap around you in 360 degrees?” he says. “I could probably — not kidding — talk for two hours about this.”

‘The audible gasp’

David Smith is a prolific developer, prominent podcaster, and self-described planner. Shortly before his inaugural visit to the Apple Vision Pro developer labs in London, Smith prepared all the necessary items for his day: a MacBook, Xcode project, and checklist (on paper!) of what he hoped to accomplish.

All that planning paid off. During his time with Apple Vision Pro, “I checked everything off my list,” Smith says. “From there, I just pretended I was at home developing the next feature.”

I just pretended I was at home developing the next feature.

David Smith, developer and podcaster

Smith began working on a version of his app Widgetsmith for spatial computing almost immediately after the release of the visionOS SDK. Though the visionOS simulator provides a solid foundation to help developers test an experience, the labs offer a unique opportunity for a full day of hands-on time with Apple Vision Pro before its public release. “I’d been staring at this thing in the simulator for weeks and getting a general sense of how it works, but that was in a box,” Smith says. “The first time you see your own app running for real, that’s when you get the audible gasp.”

Smith wanted to start working on the device as soon as possible, so he could get “the full experience” and begin refining his app. “I could say, ‘Oh, that didn’t work? Why didn’t it work?’ Those are questions you can only truly answer on-device.” Now, he has plenty more plans to make — as evidenced by his paper checklist, which he holds up and flips over, laughing. “It’s on this side now.”

‘We understand where to go’

When it came to testing Pixite’s video creator and editor Spool, chief experience officer Ben Guerrette made exploring interactions a priority. “What’s different about our editor is that you’re tapping videos to the beat,” he says. “Spool is great on touchscreens because you have the instrument in front of you, but with Apple Vision Pro you’re looking at the UI you’re selecting — and in our case, that means watching the video while tapping the UI.”

The team spent time in the lab exploring different interaction patterns to address this core challenge. “At first, we didn’t know if it would work in our app,” Guerrette says. “But now we understand where to go. That kind of learning experience is incredibly valuable: It gives us the chance to say, ‘OK, now we understand what we’re working with, what the interaction is, and how we can make a stronger connection.’”

Chris Delbuck, principal design technologist at Slack, had intended to test the company’s iPadOS version of their app on Apple Vision Pro. As he spent time with the device, however, “it instantly got me thinking about how 3D offerings and visuals could come forward in our experiences,” he says. “I wouldn’t have been able to do that without having the device in hand.”

‘That will help us make better apps’

As lab participants like Smith continue their development at home, they’ve brought back lessons and learnings from their time with Apple Vision Pro. “It’s not necessarily that I solved all the problems — but I solved enough to have a sense of the kinds of solutions I’d likely need,” Smith says. “Now there’s a step change in my ability to develop in the simulator, write quality code, and design good user experiences.”

I've truly seen how to start building for the boundless canvas.

Michael Simmons, Flexibits CEO

Simmons says that the labs offered not just a playground, but a way to shape and streamline his team’s thinking about what a spatial experience could truly be. “With Apple Vision Pro and spatial computing, I’ve truly seen how to start building for the boundless canvas — how to stop thinking about what fits on a screen,” he says. “And that will help us make better apps.”

As announced in April, your customers will soon be able to resolve payment issues without leaving your app, making it easier for them to stay subscribed to your content, services, and premium features.

Starting August 14, 2023, if an auto-renewable subscription doesn’t renew because of a billing issue, a system-provided sheet will appear in your app with a prompt that lets customers update the payment method for their Apple ID. You can test this sheet in Sandbox, as well as delay or suppress it using messages and display in StoreKit. This feature is available in iOS 16.4 and iPadOS 16.4 or later, and no action is required to adopt it.

Learn about the system-provided sheet

Learn how to test billing issues in Sandbox

Recent content on Mobile A11y

For iOS, Accessibility values are one of the building blocks of how Accessibility works on the platform, along with traits, labels, hints, and showing/hiding elements. If you’re familiar with WCAG or web accessibility, accessibility values are the value part of WCAG 4.1.2: Name, Role, Value. Values Not every element in your view will have a value - in fact, most won’t. Any element that ‘contains’ some data, data that is not included in the element’s label requires an accessibility value to be set.

Accessibility traits on iOS is the system by which assistive technologies know how to present your interface to your users. The exact experience will vary between assistive technologies, in some cases they may change the intonation of what VoiceOver reads, or add additional options for navigation, sometimes they will disable that assistive technology from accessing the element, or change how the assistive tech functions. They are the ‘Role’ part of the fundamental rule of making something accessible to screen readers - WCAG’s 4.

When testing your app with VoiceOver or Switch Control, a common test is to ensure you can reach every interactive element on screen. If these assistive technologies can’t focus all of your buttons how will your customers be able to interact fully with your app? Except there are times when hiding buttons from your assistive technology users is the better choice. Consider an app with a table view that has many repeating interactive elements - this could be a social media app where ’like, share, reply’ etc is repeated for each post.

Disclosure: Evinced has paid for my time in writing this blog, and I have provided them feedback on the version of their tool reviewed and an early beta. I agreed to this because I believe in the product they are offering. Testing your app for accessibility is an essential part of making an accessible app, as with any part of the software you build, if you don’t test it, how can you be sure it works?

This is a common question I get asked - how do I go about arranging an accessibility audit for my app so I know where I can make improvements? If you’re truly looking for an answer to that question then I have a few options for you below, but first, are you asking the right question? Accessibility Isn’t About Box Ticking You can’t make your app accessible by getting a report, fixing the findings, and accepting it as done.

I’ll admit, adding UI testing to an app that currently doesn’t have it included is probably stretching the definition of quick win, but the aim here isn’t 100% coverage - not right away anyway. Start small and add to your test suite as you gain confidence. Even a small suite of crucial happy-path UI tests will help to ensure and persist accessibility in your app. And the more you get comfortable with UI tests the more accessible your apps will become, because an app that is easy to test is also great for accessibility.

Many people don’t realise dark mode is an accessibility feature. It’s often just considered a nice to have, a cool extra feature that power users will love. But dark mode is also a valuable accessibility feature. Some types of visual impairment can make it painful to look at bright colours, or large blocks of white might wash over the black text. Some people with dyslexia or Irlen’s Syndrome can struggle to read black text on a white background.

If you have a regulatory requirement to provide accessibility in your app (spoiler, you do) the chances are it will say you have a requirement to reach WCAG AA. While this is likely meaningless to anyone other an accessibility professionals, in short it means you are providing the minimum level of accessibility features required to make your app usable by the majority of people. This post is about one such requirement, the jazzily titled Success Criterion 1.

Images are a major part of our apps. They add meaning and interest, they give your app character and context. The adage is that a picture is worth a thousand words. But if you can’t see the image clearly, how do you know what those words are? If you aren’t providing image descriptions in your app many of your users will be missing out on the experience you’ve crafted. The result can be an app thats missing that spark an character, or worse an app thats just meaningless and unusable.

How many shades of grey do you use in your app? OK, maybe thats a bit cruel towards designers, grey is a great colour, but the problem with grey is that it can be deceptively difficult to distinguish from a background. And this problem is not just limited to greys - lighter colours too can blend into the background. This effect can be heightened too for people who have blurred or obscured vision, or one of many forms of colour blindness.

Each year at WWDC Xcode Santa brings us exciting new APIs to play with, and this year our accessibility present is Customized Accessibility Content. This API flew under the radar a little, I’m told this is because it’s so new there wasn’t even time for inclusion at WWDC. But this new feature helps to solve a difficult question when designing a VoiceOver interface - where is the balance between too much and too little content.

The Accessibility Review series uses real world apps to provide examples of common accessibility issues and provide tips on how to fix them. Each of the developers has kindly volunteered their app to be tested. Huh? is a dictionary and thesaurus app from Peter Yaacoub. Enter a word into the search bar then choose a dictionary service. Press search and the app will present your chosen service’s entry for the term you entered.

The Accessibility Review series uses real world apps to provide examples of common accessibility issues and provide tips on how to fix them. Each of the developers has kindly volunteered their app to be tested. Figure Case is an app to help organise a tabletop miniature collection created by Simon Nickel. The app helps to track miniatures you own, and what state they currently find themselves in - unassembled, assembled, or painted.

The Accessibility Review series uses real world apps to provide examples of common accessibility issues and provide tips on how to fix them. Each of the developers has kindly volunteered their app to be tested. Daily Dictionary is an app from Benjamin Mayo providing a new word every day with definitions and real-world uses designed to help increase your vocabulary. Assessing the app, I noticed Benjamin has made a design decision around presenting the app’s settings.

Attributed accessibility labels are an incredible tool for making some next-level accessible experiences. They let you tell VoiceOver not just what to speak, but how to say it too. Using the accessibilityAttributedLabel property you can provide an NSAttributedString to VoiceOver, much the same way you would provide an NSAttributedString to a label’s attributedText property to display a string with an underline or character colour for example. The difference here is that all of our attributes are instructions for VoiceOver.

A good accessibility label lets your customer know exactly what a control does in as few words as possible, without having to rely on implied context. Don’t Add the Element Type iOS already knows your button is a button and your image is an image, it does this using an accessibility trait. If you label your button as ‘Play button’ your VoiceOver customers will hear ‘Play button. Button.’ Keep it Succinct Don’t frustrate your customer by adding too much information to your labels.

There’s a few circumstances when you’ll want to set your own accessibility label, such as… An interactive element that you haven’t given a text value to, such as an image button. An interactive element with a long visual label. An interactive element with a short visual label that takes context from your design. A control or view you have created yourself or built by combining elements. Images of text. Elements Without a text value Take the controls for a music player as an example.

This blog was inspired by Jeff Watkins’ series of blogs on UIButton. UIButton is a fundamental part of building interfaces on iOS. So much so, that it probably doesn’t get the love it deserves. But it’s also really powerful and customisable when used correctly. Accessibility labels on iOS I feel are very similar. They’re fundamental to how accessibility works on iOS, yet I think they suffer from a few PR issues.

A few months ago I shared a project I’d been working on for iOS exploring the accessibility API available on that platform. The Android accessibility API is equally large and full featured, and really deserves the same treatment. So here’s A11y Box for Android. A11y Box for Android is an exploration of what is available on the Android accessibility api and how you can make use of it in your apps.

I was supposed to be attending the 2020 CSUN Assistive Technology conference to present a couple of talks, unfortunately with COVID-19 starting to take hold at that time, I wasn’t able to attend. In lieu of attending I decided to record one of the talks I was scheduled to present on Accessibility in SwiftUI. SwiftUI is Apple’s new paradigm for creating user interfaces on Apple platforms, and it has a bunch of new approaches that really help create more accessible experiences.

iOS’ UIAccessibility API is huge. I like to think I know it pretty well, but I’m always being surprised by discovering features I previously had no idea about. Like many things on iOS, the documentation for UIAccessibility is not always complete, even for parts of the API that have been around for years. In an attempt to help spread the knowledge of some of the awesome things UIAccessibility is capable of, I’ve created A11y Box for iOS.

Live Regions are one of my favourite accessibility features on Android. They’re a super simple solution to a common accessibility problem that people with visual impairments can stumble across. Say you have a game app, really any type of game. Your user interacts with the play area, and as they do, their score increases or decreases depending on your customer’s actions. In this example, the score display is separate to the element your customer is interacting with.

A11yUITests is an extension to XCTestCase that adds tests for common accessibility issues that can be run as part of an XCUITest suite. I’ve written a detailed discussion of the tests available if you’re interested in changing/implementing these tests yourself. Alternatively, follow this quick start guide. Getting Started Adding A11yUITests I’m assuming you’re already familiar with cocoapods, if not, cocoapods.org has a good introduction. There is one minor difference here compared to most cocoapods, we’re not including this pod in our app, but our app’s test bundle.

For a while now I’ve been looking at possibilities for automated accessibility testing on iOS. Unfortunately, I’ve not found any option so far that I’m happy with. I am a big fan of Apple’s XCUI Test framework. Although it has its limitations, I believe there’s scope for creating valid accessibility tests using this framework. Over the last few months I’ve been trying things out, and here’s what I’ve come up with.

This is a personally curated list of resources I have used and think others may find helpful too. I’m always looking for new high quality mobile accessibility and inclusion resources to add here. Please share any you find with me via email or Twitter. Code Android Android Developers: Build more accessible appsAndroid’s developer documentation for Accessibility, including design, building & testing. With videos, code samples, and documentation. Android: Make apps more accessibleGoogle’s guide to improving accessibility on Android

Laura’s introduction to web accessibility jumped out to me because it’s available as an audiobook. Being dyslexic I struggle to read, so prefer to listen to audiobooks where available. Unfortunately, most technical books aren’t available as audiobooks for a couple of potentially obvious reasons. Hearing code or descriptions of diagrams and illustrations read aloud may not be the best experience for an audiobook. As such, this book choses to leave those out of the audio version.

Accessibility is a long word. It’s not the simplest of words to read or to spell, so it seems like a word that would be a good candidate for abbreviation. The common abbreviation of accessibility is a11y. We take the A and Y from the beginning and end of accessibility, and 11 for the number of letters in between. This abbreviation also creates a pleasing homophone for ‘ally.’ The irony of this abbreviation is that a11y isn’t accessible.

About Mobile A11y Mobile A11y is a collection of blogs and resources about how we as mobile developers can improve accessibility on mobile devices. From time to time the blog might also touch on related topics such as digital inclusion, and other topics around ethics in technology. The site is aimed at mobile developers and is written by a mobile developer. I hope this means other mobile developers will find the content relatable and engaging, and you’ll find learning about mobile accessibility along with me helpful.

Accessibility is important. We can take that as a given. But as iOS devs we’re not always sure how to make the most of the accessibility tools that Apple have provided us. We’re lucky as iOS developers that we work on such a forward-thinking accessibility platform. Many people consider Apple’s focus on accessibility for iOS as the driver for other technology vendors to include accessibility features as standard. To the point that we now consider accessibility an expected part of any digital platform.

Semantic views are not new to SwiftUI, but changes in SwiftUI mean creating them is simple. Semantic views are not so much a language feature. They’re more a technique for manipulating the accessible user interface and improving the experience for assistive technology users. A what view? A semantic view is not one view, but a collection of views grouped together because they have meaning (or semantic) together. Take a look at this iOS table view cell from the files app.

SwiftUI allows us to read environmental values that might affect how we want to present ­­our UI. Things like size classes and locale for example. We also get the ability to read some of the user’s chosen accessibility settings allowing us to make decisions that will best fit with your customer’s preference. Why? Before we cover what these options are and how to detect them I think it’s important to briefly cover why we need to detect them.

When a customer enables an assistive technology to navigate your app the interface that technology navigates isn’t exactly the same as the one visible on the screen. They’re navigating a modified version that iOS creates especially for assistive technology. This is known as the accessibility tree or accessible user interface. iOS does an incredible job at creating the AUI for you from your SwiftUI code. We can help iOS in creating this by tweaking some element’s accessibility attributes.

Accessibility traits are a group of attributes on a SwiftUI element. They inform assistive technologies how to interact with the element or present it to your customer. Each element has a selection of default traits, but you might need to change these as you create your UI. In SwiftUI there are two modifiers to use for traits, .accessibility(addTraits: ) and .accessibility(removeTraits: ) which add or remove traits respectively. Each modifier takes as its argument either a single accessibility trait or a set of traits.

Design Meets Disability was recommended to me by accessibility consultant Jon Gibbins while we were sharing a long train journey through mid-Wales. We were talking, amongst many things, about our love for Apple products and their design. I am a hearing aid wearer, my aid is two-tone grey. A sort of dark taupe grey above, and a darker, almost gun-metal grey below. There’s a clear tube into my ear. This is fine, I don’t hate it.

I was asked to guest on the iPhreaks podcast to discuss iOS accessibility. We talked about why accessibility is important, how you can improve it in your apps, and some of the changes iOS 13 and SwiftUI bring. unfortunatley iPhreaks don’t provide a transcript, but they do provide a comprehensive write-up on their site.

Take a look at your app. Notice the collection of buttons, text, images, and other controls you can see and interact with that make up your app’s user interface. When one of your customers navigates your app with Voice Control, Switch Control, VoiceOver, or any other assistive technology, this isn’t the interface they’re using. Instead, iOS creates a version of your interface for assistive technology to use. This interface is generally known as the accessibility tree.

I was honoured in 2019 to be able to give my first full conference talk at CodeMobile. I was then lucky enough to be able to repeat that talk at NSLondon, NSManchester, and SWMobile meetups. As an iOS developer, I know accessibility is important for a huge range of people. But at times I think I can treat it like an afterthought. Accessibility Without the ‘V’ Word covers a skill I think we as software engineers would benefit from developing - empathy towards our users.

Assistive technology, such as VoiceOver, works in natural reading direction. In English, and most other languages, this means top left through to the bottom right. Mostly this is the right decision for assistive technology to make. This is the order anyone not using assistive technology would experience your app. Sometimes though, we make designs that don’t read in this way. By using the .accessibility(sortPriority: ) modifier we can set the order in which assistive technology accesses elements.

One big accessibility improvement in SwiftUI comes in the form of named controls. Nearly all controls and some non-interactive views (see Images) can take a Text view as part of their view builder. The purpose of this is to tie the meaning to the control. Toggle(isOn: $updates) { Text("Send me updates") } Imagine a UIKit layout with a UISwitch control. We’d most likely right align the switch, and provide a text label to the left.

Like all accessibility features, Dynamic Type is about customisability. Many of your customers, and maybe even you, are using Dynamic Type without even considering it an accessibility feature. Dynamic type allows iOS users to set the text to a size that they find comfortable to read. This may mean making it a little larger so it’s easier to read for those of us who haven’t yet accepted we might need glasses.

Images in SwiftUI are accessible by default. This is the opposite of what we’d experience in UIKit, where images are not accessible unless you set isAccessibilityElement to true. Sometimes making images not accessible to VoiceOver is the right decision. Like when using a glyph as a redundant way of conveying meaning alongside text. An example of this would be displaying a warning triangle next to the text ‘Error’ or a tick next to ‘success’.

I was asked by Capital One to contribute an accessibility piece to the Capital One Tech Medium. The blog, titled Baking Digital Inclusion Into Your Mobile Apps, briefly covers what we mean by disability and what we can do to make our mobile apps work better for everyone.

The European Accessibility Act, or EAA is due to become law in Europe later this year, and it defines some specific requirements for mobile. In fact, its the first accessibility legislation that I’m aware of, anywhere, that explicitly covers mobile apps. Since 2012 the European Union has been working on standardising accessibility legislation across Europe. The ultimate aim is to both improve the experience for those who need to use assistive technology, but also to simplify the rules business need to follow on accessibility.

The Swift website provides nightly builds of the Swift compiler (called toolchains) for download. Building with a nightly compiler can be useful if you want to check if a bug has already been fixed on main, or if you want to experiment with upcoming language features such as Embedded Swift, as I’ve been doing lately. A toolchain is distributed as a .pkg installer that installs itself into /Library/Developer/Toolchains (or the equivalent path in your home directory). After installation, you have several options to select the toolchain you want to build with: In Xcode In Xcode, select the toolchain from the main menu (Xcode > Toolchains), then build and/or run your code normally. Not all Xcode features work with a custom toolchain. For example, playgrounds don’t work, and Xcode will always use its built-in copy of the Swift Package Manager, so you won’t be able to use unreleased SwiftPM features in this way. Also, Apple won’t accept apps built with a non-standard toolchain for submission to the App Store. On the command line When building on the command line there are multiple options, depending on your preferences and what tool you want to use. The TOOLCHAINS environment variable All of the various Swift build tools respect the TOOLCHAINS environment variable. This should be set to the desired toolchain’s bundle ID, which you can find in the Info.plist file in the toolchain’s directory. Example (I’m using a nightly toolchain from 2024-03-03 here): # My normal Swift version is 5.10 $ swift --version swift-driver version: 1.90.11.1 Apple Swift version 5.10 (swiftlang-5.10.0.13 clang-1500.3.9.4) # Make sure xcode-select points to Xcode, not to /Library/Developer/CommandLineTools # The Command Line Tools will ignore the TOOLCHAINS variable. $ xcode-select --print-path /Applications/Xcode.app/Contents/Developer # The nightly toolchain is 6.0-dev $ export TOOLCHAINS=org.swift.59202403031a $ swift --version Apple Swift version 6.0-dev (LLVM 0c7823cab15dec9, Swift 0cc05909334c6f7) Toolchain name vs. bundle ID I think the TOOLCHAINS variable is also supposed to accept the toolchain’s name instead of the bundle ID, but this doesn’t work reliably for me. I tried passing: the DisplayName from Info.plist (“Swift Development Snapshot 2024-03-03 (a)”), the ShortDisplayName (“Swift Development Snapshot”; not unique if you have more than one toolchain installed!), the directory name, both with and without the .xctoolchain suffix, but none of them worked reliably, especially if you have multiple toolchains installed. In my limited testing, it seems that Swift picks the first toolchain that matches the short name prefix (“Swift Development Snapshot”) and ignores the long name components. For example, when I select “Swift Development Snapshot 2024-03-03 (a)”, Swift picks swift-DEVELOPMENT-SNAPSHOT-2024-01-30-a, presumably because that’s the “first” one (in alphabetical order) I have installed. My advice: stick to the bundle ID, it works. Here’s a useful command to find the bundle ID of the latest toolchain you have installed (you may have to adjust the path if you install your toolchains in ~/Library instead of /Library): $ plutil -extract CFBundleIdentifier raw /Library/Developer/Toolchains/swift-latest.xctoolchain/Info.plist org.swift.59202403031 # Set the toolchain to the latest installed: export TOOLCHAINS=$(plutil -extract CFBundleIdentifier raw /Library/Developer/Toolchains/swift-latest.xctoolchain/Info.plist) xcrun and xcodebuild xcrun and xcodebuild respect the TOOLCHAINS variable too. As an alternative, they also provide an equivalent command line parameter named --toolchain. The parameter has the same semantics as the environment variable: you pass the toolchain’s bundle ID. Example: $ xcrun --toolchain org.swift.59202403031a --find swiftc /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2024-03-03-a.xctoolchain/usr/bin/swiftc Swift Package Manager SwiftPM also respects the TOOLCHAINS variable, and it has a --toolchains parameter as well, but this one expects the path to the toolchain, not its bundle ID. Example: $ swift build --toolchain /Library/Developer/Toolchains/swift-latest.xctoolchain Missing toolchains are (silently) ignored Another thing to be aware of: if you specify a toolchain that isn’t installed (e.g. because of a typo or because you’re trying to run a script that was developed in a different environment), none of the tools will fail: swift, xcrun, and xcodebuild silently ignore the toolchain setting and use the default Swift toolchain (set via xcode-select). SwiftPM silently ignores a missing toolchain set via TOOLCHAINS. If you pass an invalid directory to the --toolchains parameter, it at least prints a warning before it continues building with the default toolchain. I don’t like this. I’d much rather get an error if the build tool can’t find the toolchain I told it to use. It’s especially dangerous in scripts.

You may have noticed that the Swift compiler automatically treats the closure of a DispatchQueue.main.async call as @MainActor. In other words, we can call a main-actor-isolated function in the closure: import Dispatch @MainActor func mainActorFunc() { } DispatchQueue.main.async { // The compiler lets us call this because // it knows we're on the main actor. mainActorFunc() } This behavior is welcome and very convenient, but it bugs me that it’s so hidden. As far as I know it isn’t documented, and neither Xcode nor any other editor/IDE I’ve used do a good job of showing me the actor context a function or closure will run in, even though the compiler has this information. I’ve written about a similar case before in Where View.task gets its main-actor isolation from, where Swift/Xcode hide essential information from the programmer by not showing certain attributes in declarations or the documentation. It’s a syntax check So how is the magic behavior for DispatchQueue.main.async implemented? It can’t be an attribute or other annotation on the closure parameter of the DispatchQueue.async method because the actual queue instance isn’t known at that point. A bit of experimentation reveals that it is in fact a relatively coarse source-code-based check that singles out invocations on DispatchQueue.main, in exactly that spelling. For example, the following variations do produce warnings/errors (in Swift 5.10/6.0, respectively), even though they are just as safe as the previous code snippet. This is because we aren’t using the “correct” DispatchQueue.main.async spelling: let queue = DispatchQueue.main queue.async { // Error: Call to main actor-isolated global function // 'mainActorFunc()' in a synchronous nonisolated context mainActorFunc() // ❌ } typealias DP = DispatchQueue DP.main.async { // Error: Call to main actor-isolated global function // 'mainActorFunc()' in a synchronous nonisolated context mainActorFunc() // ❌ } I found the place in the Swift compiler source code where the check happens. In the compiler’s semantic analysis stage (called “Sema”; this is the phase right after parsing), the type checker calls a function named adjustFunctionTypeForConcurrency, passing in a Boolean it obtained from isMainDispatchQueueMember, which returns true if the source code literally references DispatchQueue.main. In that case, the type checker adds the @_unsafeMainActor attribute to the function type. Good to know. Fun fact: since this is a purely syntax-based check, if you define your own type named DispatchQueue, give it a static main property and a function named async that takes a closure, the compiler will apply the same “fix” to it. This is NOT recommended: // Define our own `DispatchQueue.main.async` struct DispatchQueue { static let main: Self = .init() func async(_ work: @escaping () -> Void) {} } // This calls our DispatchQueue.main.async { // No error! Compiler has inserted `@_unsafeMainActor` mainActorFunc() } Perplexity through obscurity I love that this automatic @MainActor inference for DispatchQueue.main exists. I do not love that it’s another piece of hidden, implicit behavior that makes Swift concurrency harder to learn. I want to see all the @_unsafeMainActor and @_unsafeInheritExecutor and @_inheritActorContext annotations! I believe Apple is doing the community a disservice by hiding these in Xcode. The biggest benefit of Swift’s concurrency model over what we had before is that so many things are statically known at compile time. It’s a shame that the compiler knows on which executor a particular line of code will run, but none of the tools seem to be able to show me this. Instead, I’m forced to hunt for @MainActor annotations and hidden attributes in superclasses, protocols, etc. This feels especially problematic during the Swift 5-to-6 transition phase we’re currently in where it’s so easy to misuse concurrency and not get a compiler error (and sometimes not even a warning if you forget to enable strict concurrency checking). The most impactful change Apple can make to make Swift concurrency less confusing is to show the inferred executor context for each line of code in Xcode. Make it really obvious what code runs on the main actor, some other actor, or the global cooperative pool. Use colors or whatnot! (Other Swift IDEs should do this too, of course. I’m just picking on Xcode because Apple has the most leverage.)

And what it can teach us about SwiftUI’s stack layout algorithm I have one more thing to say on the relative sizing view modifier from my previous post, Working with percentages in SwiftUI layout. I’m assuming you’ve read that article. The following is good to know if you want to use the modifier in your own code, but I hope you’ll also learn some general tidbits about SwiftUI’s layout algorithm for HStacks and VStacks. Using relative sizing inside a stack view Let’s apply the relativeProposed modifier to one of the subviews of an HStack: HStack(spacing: 10) { Color.blue .relativeProposed(width: 0.5) Color.green Color.yellow } .border(.primary) .frame(height: 80) What do you expect to happen here? Will the blue view take up 50 % of the available width? The answer is no. In fact, the blue rectangle becomes narrower than the others: This is because the HStack only proposes a proportion of its available width to each of its children. Here, the stack proposes one third of the available space to its first child, the relative sizing modifier. The modifier then halves this value, resulting in one sixth of the total width (minus spacing) for the blue color. The other two rectangles then become wider than one third because the first child view didn’t use up its full proposed width. Update May 1, 2024: SwiftUI’s built-in containerRelativeFrame modifier (introduced after I wrote my modifier) doesn’t exhibit this behavior because it uses the size of the nearest container view as its reference, and stack views don’t count as containers in this context (which I find somewhat unintuitive, but that’s the way it is). Order matters Now let’s move the modifier to the green color in the middle: HStack(spacing: 10) { Color.blue Color.green .relativeProposed(width: 0.5) Color.yellow } Naively, I’d expect an equivalent result: the green rectangle should become 100 pt wide, and blue and yellow should be 250 pt each. But that’s not what happens — the yellow view ends up being wider than the blue one: I found this unintuitive at first, but it makes sense if you understand that the HStack processes its children in sequence: The HStack proposes one third of its available space to the blue view: (620 – 20) / 3 = 200. The blue view accepts the proposal and becomes 200 pt wide. Next up is the relativeProposed modifier. The HStack divides the remaining space by the number of remaining subviews and proposes that: 400 / 2 = 200. Our modifier halves this proposal and proposes 100 pt to the green view, which accepts it. The modifier in turn adopts the size of its child and returns 100 pt to the HStack. Since the second subview used less space than proposed, the HStack now has 300 pt left over to propose to its final child, the yellow color. Important: the order in which the stack lays out its subviews happens to be from left to right in this example, but that’s not always the case. In general, HStacks and VStacks first group their subviews by layout priority (more on that below), and then order the views inside each group by flexibility such that the least flexible views are laid out first. For more on this, see How an HStack Lays out Its Children by Chris Eidhof. The views in our example are all equally flexible (they all can become any width between 0 and infinity), so the stack processes them in their “natural” order. Leftover space isn’t redistributed By now you may be able guess how the layout turns out when we move our view modifier to the last child view: HStack(spacing: 10) { Color.blue Color.green Color.yellow .relativeProposed(width: 0.5) } Blue and green each receive one third of the available width and become 200 pt wide. No surprises there. When the HStack reaches the relativeProposed modifier, it has 200 pt left to distribute. Again, the modifier and the yellow rectangle only use half of this amount. The end result is that the HStack ends up with 100 pt left over. The process stops here — the HStack does not start over in an attempt to find a “better” solution. The stack makes itself just big enough to contain its subviews (= 520 pt incl. spacing) and reports that size to its parent. Layout priority We can use the layoutPriority view modifier to influence how stacks and other containers lay out their children. Let’s give the subview with the relative sizing modifier a higher layout priority (the default priority is 0): HStack(spacing: 10) { Color.blue Color.green Color.yellow .relativeProposed(width: 0.5) .layoutPriority(1) } This results in a layout where the yellow rectangle actually takes up 50 % of the available space: Explanation: The HStack groups its children by layout priority and then processes each group in sequence, from highest to lowest priority. Each group is proposed the entire remaining space. The first layout group only contains a single view, our relative sizing modifier with the yellow color. The HStack proposes the entire available space (minus spacing) = 600 pt. Our modifier halves the proposal, resulting in 300 pt for the yellow view. There are 300 pt left over for the second layout group. These are distributed equally among the two children because each subview accepts the proposed size. Conclusion The code I used to generate the images in this article is available on GitHub. I only looked at HStacks here, but VStacks work in exactly the same way for the vertical dimension. SwiftUI’s layout algorithm always follows this basic pattern of proposed sizes and responses. Each of the built-in “primitive” views (e.g. fixed and flexible frames, stacks, Text, Image, Spacer, shapes, padding, background, overlay) has a well-defined (if not always well-documented) layout behavior that can be expressed as a function (ProposedViewSize) -> CGSize. You’ll need to learn the behavior for view to work effectively with SwiftUI. A concrete lesson I’m taking away from this analysis: HStack and VStack don’t treat layout as an optimization problem that tries to find the optimal solution for a set of constraints (autolayout style). Rather, they sort their children in a particular way and then do a single proposal-and-response pass over them. If there’s space leftover at the end, or if the available space isn’t enough, then so be it.

SwiftUI’s layout primitives generally don’t provide relative sizing options, e.g. “make this view 50 % of the width of its container”. Let’s build our own! Use case: chat bubbles Consider this chat conversation view as an example of what I want to build. The chat bubbles always remain 80 % as wide as their container as the view is resized: The chat bubbles should become 80 % as wide as their container. Download video Building a proportional sizing modifier 1. The Layout We can build our own relative sizing modifier on top of the Layout protocol. The layout multiplies its own proposed size (which it receives from its parent view) with the given factors for width and height. It then proposes this modified size to its only subview. Here’s the implementation (the full code, including the demo app, is on GitHub): /// A custom layout that proposes a percentage of its /// received proposed size to its subview. /// /// - Precondition: must contain exactly one subview. fileprivate struct RelativeSizeLayout: Layout { var relativeWidth: Double var relativeHeight: Double func sizeThatFits( proposal: ProposedViewSize, subviews: Subviews, cache: inout () ) -> CGSize { assert(subviews.count == 1, "expects a single subview") let resizedProposal = ProposedViewSize( width: proposal.width.map { $0 * relativeWidth }, height: proposal.height.map { $0 * relativeHeight } ) return subviews[0].sizeThatFits(resizedProposal) } func placeSubviews( in bounds: CGRect, proposal: ProposedViewSize, subviews: Subviews, cache: inout () ) { assert(subviews.count == 1, "expects a single subview") let resizedProposal = ProposedViewSize( width: proposal.width.map { $0 * relativeWidth }, height: proposal.height.map { $0 * relativeHeight } ) subviews[0].place( at: CGPoint(x: bounds.midX, y: bounds.midY), anchor: .center, proposal: resizedProposal ) } } Notes: I made the type private because I want to control how it can be used. This is important for maintaining the assumption that the layout only ever has a single subview (which makes the math much simpler). Proposed sizes in SwiftUI can be nil or infinity in either dimension. Our layout passes these special values through unchanged (infinity times a percentage is still infinity). I’ll discuss below what implications this has for users of the layout. 2. The View extension Next, we’ll add an extension on View that uses the layout we just wrote. This becomes our public API: extension View { /// Proposes a percentage of its received proposed size to `self`. public func relativeProposed(width: Double = 1, height: Double = 1) -> some View { RelativeSizeLayout(relativeWidth: width, relativeHeight: height) { // Wrap content view in a container to make sure the layout only // receives a single subview. Because views are lists! VStack { // alternatively: `_UnaryViewAdaptor(self)` self } } } } Notes: I decided to go with a verbose name, relativeProposed(width:height:), to make the semantics clear: we’re changing the proposed size for the subview, which won’t always result in a different actual size. More on this below. We’re wrapping the subview (self in the code above) in a VStack. This might seem redundant, but it’s necessary to make sure the layout only receives a single element in its subviews collection. See Chris Eidhof’s SwiftUI Views are Lists for an explanation. Usage The layout code for a single chat bubble in the demo video above looks like this: let alignment: Alignment = message.sender == .me ? .trailing : .leading chatBubble .relativeProposed(width: 0.8) .frame(maxWidth: .infinity, alignment: alignment) The outermost flexible frame with maxWidth: .infinity is responsible for positioning the chat bubble with leading or trailing alignment, depending on who’s speaking. You can even add another frame that limits the width to a maximum, say 400 points: let alignment: Alignment = message.sender == .me ? .trailing : .leading chatBubble .frame(maxWidth: 400) .relativeProposed(width: 0.8) .frame(maxWidth: .infinity, alignment: alignment) Here, our relative sizing modifier only has an effect as the bubbles become narrower than 400 points. In a wider window the width-limiting frame takes precedence. I like how composable this is! Download video 80 % won’t always result in 80 % If you watch the debugging guides I’m drawing in the video above, you’ll notice that the relative sizing modifier never reports a width greater than 400, even if the window is wide enough: The relative sizing modifier accepts the actual size of its subview as its own size. This is because our layout only adjusts the proposed size for its subview but then accepts the subview’s actual size as its own. Since SwiftUI views always choose their own size (which the parent can’t override), the subview is free to ignore our proposal. In this example, the layout’s subview is the frame(maxWidth: 400) view, which sets its own width to the proposed width or 400, whichever is smaller. Understanding the modifier’s behavior Proposed size ≠ actual size It’s important to internalize that the modifier works on the basis of proposed sizes. This means it depends on the cooperation of its subview to achieve its goal: views that ignore their proposed size will be unaffected by our modifier. I don’t find this particularly problematic because SwiftUI’s entire layout system works like this. Ultimately, SwiftUI views always determine their own size, so you can’t write a modifier that “does the right thing” (whatever that is) for an arbitrary subview hierarchy. nil and infinity I already mentioned another thing to be aware of: if the parent of the relative sizing modifier proposes nil or .infinity, the modifier will pass the proposal through unchanged. Again, I don’t think this is particularly bad, but it’s something to be aware of. Proposing nil is SwiftUI’s way of telling a view to become its ideal size (fixedSize does this). Would you ever want to tell a view to become, say, 50 % of its ideal width? I’m not sure. Maybe it’d make sense for resizable images and similar views. By the way, you could modify the layout to do something like this: If the proposal is nil or infinity, forward it to the subview unchanged. Take the reported size of the subview as the new basis and apply the scaling factors to that size (this still breaks down if the child returns infinity). Now propose the scaled size to the subview. The subview might respond with a different actual size. Return this latest reported size as your own size. This process of sending multiple proposals to child views is called probing. Lots of built-in containers views do this too, e.g. VStack and HStack. Nesting in other container views The relative sizing modifier interacts in an interesting way with stack views and other containers that distribute the available space among their children. I thought this was such an interesting topic that I wrote a separate article about it: How the relative size modifier interacts with stack views. The code The complete code is available in a Gist on GitHub. Digression: Proportional sizing in early SwiftUI betas The very first SwiftUI betas in 2019 did include proportional sizing modifiers, but they were taken out before the final release. Chris Eidhof preserved a copy of SwiftUI’s “header file” from that time that shows their API, including quite lengthy documentation. I don’t know why these modifiers didn’t survive the beta phase. The release notes from 2019 don’t give a reason: The relativeWidth(_:), relativeHeight(_:), and relativeSize(width:height:) modifiers are deprecated. Use other modifiers like frame(minWidth:idealWidth:maxWidth:minHeight:idealHeight:maxHeight:alignment:) instead. (51494692) I also don’t remember how these modifiers worked. They probably had somewhat similar semantics to my solution, but I can’t be sure. The doc comments linked above sound straightforward (“Sets the width of this view to the specified proportion of its parent’s width.”), but they don’t mention the intricacies of the layout algorithm (proposals and responses) at all. containerRelativeFrame Update May 1, 2024: Apple introduced the containerRelativeFrame modifier for its 2023 OSes (iOS 17/macOS 14). If your deployment target permits it, this can be a good, built-in alternative. Note that containerRelativeFrame behaves differently than my relativeProposed modifier as it computes the size relative to the nearest container view, whereas my modifier uses its proposed size as the reference. The SwiftUI documentation somewhat vaguely lists the views that count as a container for containerRelativeFrame. Notably, stack views don’t count! Check out Jordan Morgan’s article Modifier Monday: .containerRelativeFrame(_ axes:) (2022-06-26) to learn more about containerRelativeFrame.

Problem The Photos app on macOS doesn’t provide a keyboard shortcut for the Export Unmodified Original command. macOS allows you to add your own app-specific keyboard shortcuts via System Settings > Keyboard > Keyboard Shortcuts > App Shortcuts. You need to enter the exact spelling of the menu item you want to invoke. Photos renames the command depending on what’s selected: Export Unmodified Original For 1 Photo“ turns into ”… Originals For 2 Videos” turns into “… For 3 Items” (for mixed selections), and so on. Argh! The System Settings UI for assigning keyboard shortcuts is extremely tedious to use if you want to add more than one or two shortcuts. Dynamically renaming menu commands is cute, but it becomes a problem when you want to assign keyboard shortcuts. Solution: shell script Here’s a Bash script1 that assigns Ctrl + Opt + Cmd + E to Export Unmodified Originals for up to 20 selected items: #!/bin/bash # Assigns a keyboard shortcut to the Export Unmodified Originals # menu command in Photos.app on macOS. # @ = Command # ^ = Control # ~ = Option # $ = Shift shortcut='@~^e' # Set shortcut for 1 selected item echo "Setting shortcut for 1 item" defaults write com.apple.Photos NSUserKeyEquivalents -dict-add "Export Unmodified Original For 1 Photo" "$shortcut" defaults write com.apple.Photos NSUserKeyEquivalents -dict-add "Export Unmodified Original For 1 Video" "$shortcut" # Set shortcut for 2-20 selected items objects=(Photos Videos Items) for i in {2..20} do echo "Setting shortcut for $i items" for object in "${objects[@]}" do defaults write com.apple.Photos NSUserKeyEquivalents -dict-add "Export Unmodified Originals For $i $object" "$shortcut" done done # Use this command to verify the result: # defaults read com.apple.Photos NSUserKeyEquivalents The script is also available on GitHub. Usage: Quit Photos.app. Run the script. Feel free to change the key combo or count higher than 20. Open Photos.app. Note: There’s a bug in Photos.app on macOS 13.2 (and at least some earlier versions). Custom keyboard shortcuts don’t work until you’ve opened the menu of the respective command at least once. So you must manually open the File > Export once before the shortcut will work. (For Apple folks: FB11967573.) I still write Bash scripts because Shellcheck doesn’t support Zsh. ↩︎

I rarely participate actively in the Swift Evolution process, but I frequently refer to evolution proposals for my work, often multiple times per week. The proposals aren’t always easy to read, but they’re the most comprehensive (and sometimes only) documentation we have for many Swift features. For years, my tool of choice for searching Swift Evolution proposals has been Karoy Lorentey’s swift-evolution workflow for Alfred. The workflow broke recently due to data format changes. Karoy was kind enough to add me as a maintainer so I could fix it. The new version 2.1.0 is now available on GitHub. Download the .alfredworkflow file and double-click to install. Besides the fix, the update has a few other improvements: The proposal title is now displayed more prominently. New actions to copy the proposal title (hold down Command) or copy it as a Markdown link (hold down Shift + Command). The script forwards the main metadata of the selected proposal (id, title, status, URL) to Alfred. If you want to extend the workflow with your own actions, you can refer to these variables.

Foundation overloads the pattern matching operator ~= to enable matching against error codes in catch clauses. catch clauses in Swift support pattern matching, using the same patterns you’d use in a case clause inside a switch or in an if case … statement. For example, to handle a file-not-found error you might write: import Foundation do { let fileURL = URL(filePath: "/abc") // non-existent file let data = try Data(contentsOf: fileURL) } catch let error as CocoaError where error.code == .fileReadNoSuchFile { print("File doesn't exist") } catch { print("Other error: \(error)") } This binds a value of type CocoaError to the variable error and then uses a where clause to check the specific error code. However, if you don’t need access to the complete error instance, there’s a shorter way to write this, matching directly against the error code: let data = try Data(contentsOf: fileURL) - } catch let error as CocoaError where error.code == .fileReadNoSuchFile { + } catch CocoaError.fileReadNoSuchFile { print("File doesn't exist") Foundation overloads ~= I was wondering why this shorter syntax works. Is there some special compiler magic for pattern matching against error codes of NSError instances? Turns out: no, the answer is much simpler. Foundation includes an overload for the pattern matching operator ~= that matches error values against error codes.1 The implementation looks something like this: public func ~= (code: CocoaError.Code, error: any Error) -> Bool { guard let error = error as? CocoaError else { return false } return error.code == code } The actual code in Foundation is a little more complex because it goes through a hidden protocol named _ErrorCodeProtocol, but that’s not important. You can check out the code in the Foundation repository: Darwin version, swift-corelibs-foundation version. This matching on error codes is available for CocoaError, URLError, POSIXError, and MachError (and possibly more types in other Apple frameworks, I haven’t checked). I wrote about the ~= operator before, way back in 2015(!): Pattern matching in Swift and More pattern matching examples. ↩︎

I know I’m almost a decade late to this party, but I’m probably not the only one, so here goes. Double Fine Adventure was a wildly successful 2012 Kickstarter project to crowdfund the development of a point-and-click adventure game and, crucially, to document its development on video. The resulting game Broken Age was eventually released in two parts in 2014 and 2015. Broken Age is a beautiful game and I recommend you try it. It’s available for lots of platforms and is pretty cheap (10–15 euros/dollars or less). I played it on the Nintendo Switch, which worked very well. Broken Age. But the real gem to me was watching the 12.5-hour documentary on YouTube. A video production team followed the entire three-year development process from start to finish. It provides a refreshingly candid and transparent insight into “how the sausage is made”, including sensitive topics such as financial problems, layoffs, and long work hours. Throughout all the ups and downs there’s a wonderful sense of fun and camaraderie among the team at Double Fine, which made watching the documentary even more enjoyable to me than playing Broken Age. You can tell these people love working with each other. I highly recommend taking a look if you find this mildly interesting. The Double Fine Adventure documentary. The first major game spoilers don’t come until episode 15, so you can safely watch most of the documentary before playing the game (and this is how the original Kickstarter backers experienced it). However, I think it’s even more interesting to play the game first, or to experience both side-by-side. My suggestion: watch two or three episodes of the documentary. If you like it, start playing Broken Age alongside it.

I wrote an app called SwiftUI View Lifecycle. The app allows you to observe how different SwiftUI constructs and containers affect a view’s lifecycle, including the lifetime of its state and when onAppear gets called. The code for the app is on GitHub. It can be built for iOS and macOS. The view tree and the render tree When we write SwiftUI code, we construct a view tree that consists of nested view values. Instances of the view tree are ephemeral: SwiftUI constantly destroys and recreates (parts of) the view tree as it processes state changes. The view tree serves as a blueprint from which SwiftUI creates a second tree, which represents the actual view “objects” that are “on screen” at any given time (the “objects” could be actual UIView or NSView objects, but also other representations; the exact meaning of “on screen” can vary depending on context). Chris Eidhof likes to call this second tree the render tree (the link points to a 3 minute video where Chris demonstrates this duality, highly recommended). The render tree persists across state changes and is used by SwiftUI to establish view identity. When a state change causes a change in a view’s value, SwiftUI will find the corresponding view object in the render tree and update it in place, rather than recreating a new view object from scratch. This is of course key to making SwiftUI efficient, but the render tree has another important function: it controls the lifetimes of views and their state. View lifecycles and state We can define a view’s lifetime as the timespan it exists in the render tree. The lifetime begins with the insertion into the render tree and ends with the removal. Importantly, the lifetime extends to view state defined with @State and @StateObject: when a view gets removed from the render tree, its state is lost; when the view gets inserted again later, the state will be recreated with its initial value. The SwiftUI View Lifecycle app tracks three lifecycle events for a view and displays them as timestamps: @State = when the view’s state was created (equivalent to the start of the view’s lifetime) onAppear = when onAppear was last called onDisappear = when onDisappear was last called The lifecycle monitor view displays the timestamps when certain lifecycle events last occurred. The app allows you to observe these events in different contexts. As you click your way through the examples, you’ll notice that the timing of these events changes depending on the context a view is embedded in. For example: An if/else statement creates and destroys its child views every time the condition changes; state is not preserved. A ScrollView eagerly inserts all of its children into the render tree, regardless of whether they’re inside the viewport or not. All children appear right away and never disappear. A List with dynamic content (using ForEach) lazily inserts only the child views that are currently visible. But once a child view’s lifetime has started, the list will keep its state alive even when it gets scrolled offscreen again. onAppear and onDisappear get called repeatedly as views are scrolled into and out of the viewport. A NavigationStack calls onAppear and onDisappear as views are pushed and popped. State for parent levels in the stack is preserved when a child view is pushed. A TabView starts the lifetime of all child views right away, even the non-visible tabs. onAppear and onDisappear get called repeatedly as the user switches tabs, but the tab view keeps the state alive for all tabs. Lessons Here are a few lessons to take away from this: Different container views may have different performance and memory usage behaviors, depending on how long they keep child views alive. onAppear isn’t necessarily called when the state is created. It can happen later (but never earlier). onAppear can be called multiple times in some container views. If you need a side effect to happen exactly once in a view’s lifetime, consider writing yourself an onFirstAppear helper, as shown by Ian Keen and Jordan Morgan in Running Code Only Once in SwiftUI (2022-11-01). I’m sure you’ll find more interesting tidbits when you play with the app. Feedback is welcome!

The clipped() modifier in SwiftUI clips a view to its bounds, hiding any out-of-bounds content. But note that clipping doesn’t affect hit testing; the clipped view can still receive taps/clicks outside the visible area. I tested this on iOS 16.1 and macOS 13.0. Example Here’s a 300×300 square, which we then constrain to a 100×100 frame. I also added a border around the outer frame to visualize the views: Rectangle() .fill(.orange.gradient) .frame(width: 300, height: 300) // Set view to 100×100 → renders out of bounds .frame(width: 100, height: 100) .border(.blue) SwiftUI views don’t clip their content by default, hence the full 300×300 square remains visible. Notice the blue border that indicates the 100×100 outer frame: Now let’s add .clipped() to clip the large square to the 100×100 frame. I also made the square tappable and added a button: VStack { Button("You can't tap me!") { buttonTapCount += 1 } .buttonStyle(.borderedProminent) Rectangle() .fill(.orange.gradient) .frame(width: 300, height: 300) .frame(width: 100, height: 100) .clipped() .onTapGesture { rectTapCount += 1 } } When you run this code, you’ll discover that the button isn’t tappable at all. This is because the (unclipped) square, despite not being fully visible, obscures the button and “steals” all taps. The dashed outline indicates the hit area of the orange square. The button isn’t tappable because it’s covered by the clipped view with respect to hit testing. The fix: .contentShape() The contentShape(_:) modifier defines the hit testing area for a view. By adding .contentShape(Rectangle()) to the 100×100 frame, we limit hit testing to that area, making the button tappable again: Rectangle() .fill(.orange.gradient) .frame(width: 300, height: 300) .frame(width: 100, height: 100) .contentShape(Rectangle()) .clipped() Note that the order of .contentShape(Rectangle()) and .clipped() could be swapped. The important thing is that contentShape is an (indirect) parent of the 100×100 frame modifier that defines the size of the hit testing area. Video demo I made a short video that demonstrates the effect: Initially, taps on the button, or even on the surrounding whitespace, register as taps on the square. The top switch toggles display of the square before clipping. This illustrates its hit testing area. The second switch adds .contentShape(Rectangle()) to limit hit testing to the visible area. Now tapping the button increments the button’s tap count. The full code for this demo is available on GitHub. Download video Summary The clipped() modifier doesn’t affect the clipped view’s hit testing region. The same is true for clipShape(_:). It’s often a good idea to combine these modifiers with .contentShape(Rectangle()) to bring the hit testing logic in sync with the UI.

On the positioning of the .animation modifier in the view tree, or: “Rendering” vs. “non-rendering” view modifiers The documentation for SwiftUI’s animation modifier says: Applies the given animation to this view when the specified value changes. This sounds unambiguous to me: it sets the animation for “this view”, i.e. the part of the view tree that .animation is being applied to. This should give us complete control over which modifiers we want to animate, right? Unfortunately, it’s not that simple: it’s easy to run into situations where a view change inside an animated subtree doesn’t get animated, or vice versa. Unsurprising examples Let me give you some examples, starting with those that do work as documented. I tested all examples on iOS 16.1 and macOS 13.0. 1. Sibling views can have different animations Independent subtrees of the view tree can be animated independently. In this example we have three sibling views, two of which are animated with different durations, and one that isn’t animated at all: struct Example1: View { var flag: Bool var body: some View { HStack(spacing: 40) { Rectangle() .frame(width: 80, height: 80) .foregroundColor(.green) .scaleEffect(flag ? 1 : 1.5) .animation(.easeOut(duration: 0.5), value: flag) Rectangle() .frame(width: 80, height: 80) .foregroundColor(flag ? .yellow : .red) .rotationEffect(flag ? .zero : .degrees(45)) .animation(.easeOut(duration: 2.0), value: flag) Rectangle() .frame(width: 80, height: 80) .foregroundColor(flag ? .pink : .mint) } } } The two animation modifiers each apply to their own subtree. They don’t interfere with each other and have no effect on the rest of the view hierarchy: Download video 2. Nested animation modifiers When two animation modifiers are nested in a single view tree such that one is an indirect parent of the other, the inner modifier can override the outer animation for its subviews. The outer animation applies to view modifiers that are placed between the two animation modifiers. In this example we have one rectangle view with animated scale and rotation effects. The outer animation applies to the entire subtree, including both effects. The inner animation modifier overrides the outer animation only for what’s nested below it in the view tree, i.e. the scale effect: struct Example2: View { var flag: Bool var body: some View { Rectangle() .frame(width: 80, height: 80) .foregroundColor(.green) .scaleEffect(flag ? 1 : 1.5) .animation(.default, value: flag) // inner .rotationEffect(flag ? .zero : .degrees(45)) .animation(.default.speed(0.3), value: flag) // outer } } As a result, the scale and rotation changes animate at different speeds: Download video Note that we can also pass .animation(nil, value: flag) to selectively disable animations for a subtree, overriding a non-nil animation further up the view tree. 3. animation only animates its children (with exceptions) As a general rule, the animation modifier only applies to its subviews. In other words, views and modifiers that are direct or indirect parents of an animation modifier should not be animated. As we’ll see below, it doesn’t always work like that, but here’s an example where it does. This is a slight variation of the previous code snippet where I removed the outer animation modifier (and changed the color for good measure): struct Example3: View { var flag: Bool var body: some View { Rectangle() .frame(width: 80, height: 80) .foregroundColor(.orange) .scaleEffect(flag ? 1 : 1.5) .animation(.default, value: flag) // Don't animate the rotation .rotationEffect(flag ? .zero : .degrees(45)) } } Recall that the order in which view modifiers are written in code is inverted with respect to the actual view tree hierarchy. Each view modifier is a new view that wraps the view it’s being applied to. So in our example, the scale effect is the child of the animation modifier, whereas the rotation effect is its parent. Accordingly, only the scale change gets animated: Download video Surprising examples Now it’s time for the “fun” part. It turns out not all view modifiers behave as intuitively as scaleEffect and rotationEffect when combined with the animation modifier. 4. Some modifiers don’t respect the rules In this example we’re changing the color, size, and alignment of the rectangle. Only the size change should be animated, which is why we’ve placed the alignment and color mutations outside the animation modifier: struct Example4: View { var flag: Bool var body: some View { let size: CGFloat = flag ? 80 : 120 Rectangle() .frame(width: size, height: size) .animation(.default, value: flag) .frame(maxWidth: .infinity, alignment: flag ? .leading : .trailing) .foregroundColor(flag ? .pink : .indigo) } } Unfortunately, this doesn’t work as intended, as all three changes are animated: Download video It behaves as if the animation modifier were the outermost element of this view subtree. 5. padding and border This one’s sort of the inverse of the previous example because a change we want to animate doesn’t get animated. The padding is a child of the animation modifier, so I’d expect changes to it to be animated, i.e. the border should grow and shrink smoothly: struct Example5: View { var flag: Bool var body: some View { Rectangle() .frame(width: 80, height: 80) .padding(flag ? 20 : 40) .animation(.default, value: flag) .border(.primary) .foregroundColor(.cyan) } } But that’s not what happens: Download video 6. Font modifiers Font modifiers also behave seemingly erratic with respect to the animation modifier. In this example, we want to animate the font width, but not the size or weight (smooth text animation is a new feature in iOS 16): struct Example6: View { var flag: Bool var body: some View { Text("Hello!") .fontWidth(flag ? .condensed : .expanded) .animation(.default, value: flag) .font(.system( size: flag ? 40 : 60, weight: flag ? .regular : .heavy) ) } } You guessed it, this doesn’t work as intended. Instead, all text properties animate smoothly: Download video Why does it work like this? In summary, the placement of the animation modifier in the view tree allows some control over which changes get animated, but it isn’t perfect. Some modifiers, such as scaleEffect and rotationEffect, behave as expected, whereas others (frame, padding, foregroundColor, font) are less controllable. I don’t fully understand the rules, but the important factor seems to be if a view modifier actually “renders” something or not. For instance, foregroundColor just writes a color into the environment; the modifier itself doesn’t draw anything. I suppose this is why its position with respect to animation is irrelevant: RoundedRectangle(cornerRadius: flag ? 0 : 40) .animation(.default, value: flag) // Color change still animates, even though we’re outside .animation .foregroundColor(flag ? .pink : .indigo) The rendering presumably takes place on the level of the RoundedRectangle, which reads the color from the environment. At this point the animation modifier is active, so SwiftUI will animate all changes that affect how the rectangle is rendered, regardless of where in the view tree they’re coming from. The same explanation makes intuitive sense for the font modifiers in example 6. The actual rendering, and therefore the animation, occurs on the level of the Text view. The various font modifiers affect how the text is drawn, but they don’t render anything themselves. Similarly, padding and frame (including the frame’s alignment) are “non-rendering” modifiers too. They don’t use the environment, but they influence the layout algorithm, which ultimately affects the size and position of one or more “rendering” views, such as the rectangle in example 4. That rectangle sees a combined change in its geometry, but it can’t tell where the change came from, so it’ll animate the full geometry change. In example 5, the “rendering” view that’s affected by the padding change is the border (which is implemented as a stroked rectangle in an overlay). Since the border is a parent of the animation modifier, its geometry change is not animated. In contrast to frame and padding, scaleEffect and rotationEffect are “rendering” modifiers. They apparently perform the animations themselves. Conclusion SwiftUI views and view modifiers can be divided into “rendering“ and “non-rendering” groups (I wish I had better terms for these). In iOS 16/macOS 13, the placement of the animation modifier with respect to non-rendering modifiers is irrelevant for deciding if a change gets animated or not. Non-rendering modifiers include (non-exhaustive list): Layout modifiers (frame, padding, position, offset) Font modifiers (font, bold, italic, fontWeight, fontWidth) Other modifiers that write data into the environment, e.g. foregroundColor, foregroundStyle, symbolRenderingMode, symbolVariant Rendering modifiers include (non-exhaustive list): clipShape, cornerRadius Geometry effects, e.g. scaleEffect, rotationEffect, projectionEffect Graphical effects, e.g. blur, brightness, hueRotation, opacity, saturation, shadow

Mac apps built with Xcode 14.0 and 14.0.1 may contain concurrency bugs because the Swift 5.7 compiler can generate invalid code when targeting the macOS 12.3 SDK. If you distribute Mac apps, you should build them with Xcode 13.4.1 until Xcode 14.1 is released. Here’s what happened: Swift 5.7 implements SE-0338: Clarify the Execution of Non-Actor-Isolated Async Functions, which introduces new rules how async functions hop between executors. Because of SE-0338, when compiling concurrency code, the Swift 5.7 compiler places executor hops in different places than Swift 5.6. Some standard library functions need to opt out of the new rules. They are annotated with a new, unofficial attribute @_unsafeInheritExecutor, which was introduced for this purpose. When the Swift 5.7 compiler sees this attribute, it generates different executor hops. The attribute is only present in the Swift 5.7 standard library, i.e. in the iOS 16 and macOS 13 SDKs. This is fine for iOS because compiler version and the SDK’s standard library version match in Xcode 14.0. But for macOS targets, Xcode 14.0 uses the Swift 5.7 compiler with the standard library from Swift 5.6, which doesn’t contain the @_unsafeInheritExecutor attribute. This is what causes the bugs. Note that the issue is caused purely by the version mismatch at compile-time. The standard library version used by the compiled app at run-time (which depends on the OS version the app runs on) isn’t relevant. As soon as Xcode 14.1 gets released with the macOS 13 SDK, the version mismatch will go away, and Mac targets built with Xcode 14.1 won’t exhibit these bugs. Third-party developers had little chance of discovering the bug during the Xcode 14.0 beta phase because the betas ship with the new beta macOS SDK. The version mismatch occurs when the final Xcode release in September reverts back to the old macOS SDK to accommodate the different release schedules of iOS and macOS. Sources Breaking concurrency invariants is a serious issue, though I’m not sure how much of a problem this is in actual production apps. Here are all related bug reports that I know of: Concurrency is broken in Xcode 14 for macOS (2022-09-14) withUnsafeContinuation can break actor isolation (2022-10-07) And explanations of the cause from John McCall of the Swift team at Apple: John McCall (2022-10-07): This guarantee is unfortunately broken with Xcode 14 when compiling for macOS because it’s shipping with an old macOS SDK that doesn’t declare that withUnsafeContinuation inherits its caller’s execution context. And yes, there is a related actor-isolation issue because of this bug. That will be fixed by the release of the new macOS SDK. John McCall (2022-10-07): Now, there is a bug in Xcode 14 when compiling for the macOS SDK because it ships with an old SDK. That bug doesn’t actually break any of the ordering properties above. It does, however, break Swift’s data isolation guarantees because it causes withUnsafeContinuation, when called from an actor-isolated context, to send a non-Sendable function to a non-isolated executor and then call it, which is completely against the rules. And in fact, if you turn strict sendability checking on when compiling against that SDK, you will get a diagnostic about calling withUnsafeContinuation because it thinks that you’re violating the rules (because withUnsafeContinuation doesn’t properly inherit the execution context of its caller). Poor communication from Apple What bugs me most about the situation is Apple’s poor communication. When the official, current release of your programming language ships with a broken compiler for one of your most important platforms, the least I’d expect is a big red warning at the top of the release notes. I can’t find any mention of this issue in the Xcode 14.0 release notes or Xcode 14.0.1 release notes, however. Even better: the warning should be displayed prominently in Xcode, or Xcode 14.0 should outright refuse to build Mac apps. I’m sure the latter option isn’t practical for all sorts of reasons, although it sounds logical to me: if the only safe compiler/SDK combinations are either 5.6 with the macOS 12 SDK or 5.7 with the macOS 13 SDK, there shouldn’t be an official Xcode version that combines the 5.7 compiler with the macOS 12 SDK.

SwiftUI’s .task modifier inherits its actor context from the surrounding function. If you call .task inside a view’s body property, the async operation will run on the main actor because View.body is (semi-secretly) annotated with @MainActor. However, if you call .task from a helper property or function that isn’t @MainActor-annotated, the async operation will run in the cooperative thread pool. Example Here’s an example. Notice the two .task modifiers in body and helperView. The code is identical in both, yet only one of them compiles — in helperView, the call to a main-actor-isolated function fails because we’re not on the main actor in that context: We can call a main-actor-isolated function from inside body, but not from a helper property. import SwiftUI @MainActor func onMainActor() { print("on MainActor") } struct ContentView: View { var body: some View { VStack { helperView Text("in body") .task { // We can call a @MainActor func without await onMainActor() } } } var helperView: some View { Text("in helperView") .task { // ❗️ Error: Expression is 'async' but is not marked with 'await' onMainActor() } } } Why does it work like this? This behavior is caused by two (semi-)hidden annotations in the SwiftUI framework: The View protocol annotates its body property with @MainActor. This transfers to all conforming types. View.task annotates its action parameter with @_inheritActorContext, causing it to adopt the actor context from its use site. Sadly, none of these annotations are visible in the SwiftUI documentation, making it very difficult to understand what’s going on. The @MainActor annotation on View.body is present in Xcode’s generated Swift interface for SwiftUI (Jump to Definition of View), but that feature doesn’t work reliably for me, and as we’ll see, it doesn’t show the whole truth, either. View.body is annotated with @MainActor in Xcode’s generated interface for SwiftUI. SwiftUI’s module interface To really see the declarations the compiler sees, we need to look at SwiftUI’s module interface file. A module interface is like a header file for Swift modules. It lists the module’s public declarations and even the implementations of inlinable functions. Module interfaces use normal Swift syntax and have the .swiftinterface file extension. SwiftUI’s module interface is located at: [Path to Xcode.app]/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/System/Library/Frameworks/SwiftUI.framework/Modules/SwiftUI.swiftmodule/arm64e-apple-ios.swiftinterface (There can be multiple .swiftinterface files in that directory, one per CPU architecture. Pick any one of them. Pro tip for viewing the file in Xcode: Editor > Syntax Coloring > Swift enables syntax highlighting.) Inside, you’ll find that View.body has the @MainActor(unsafe) attribute: @available(iOS 13.0, macOS 10.15, tvOS 13.0, watchOS 6.0, *) @_typeEraser(AnyView) public protocol View { // … @SwiftUI.ViewBuilder @_Concurrency.MainActor(unsafe) var body: Self.Body { get } } And you’ll find this declaration for .task, including the @_inheritActorContext attribute: @available(iOS 15.0, macOS 12.0, tvOS 15.0, watchOS 8.0, *) extension SwiftUI.View { #if compiler(>=5.3) && $AsyncAwait && $Sendable && $InheritActorContext @inlinable public func task( priority: _Concurrency.TaskPriority = .userInitiated, @_inheritActorContext _ action: @escaping @Sendable () async -> Swift.Void ) -> some SwiftUI.View { modifier(_TaskModifier(priority: priority, action: action)) } #endif // … } SwiftUI’s module interface file shows the @_inheritActorContext annotatation on View.task. Putting it all together Armed with this knowledge, everything makes more sense: When used inside body, task inherits the @MainActor context from body. When used outside of body, there is no implicit @MainActor annotation, so task will run its operation on the cooperative thread pool by default. Unless the view contains an @ObservedObject or @StateObject property, which makes the entire view @MainActor via this obscure rule for property wrappers whose wrappedValue property is bound to a global actor: A struct or class containing a wrapped instance property with a global actor-qualified wrappedValue infers actor isolation from that property wrapper Update May 1, 2024: SE-0401: Remove Actor Isolation Inference caused by Property Wrappers removes the above rule when compiling in Swift 6 language mode. This is a good change because it makes reasoning about actor isolation simpler. In the Swift 5 language mode, you can opt into the better behavior with the -enable-upcoming-feature DisableOutwardActorInference compiler flags. I recommend you do. The lesson: if you use helper properties or functions in your view, consider annotating them with @MainActor to get the same semantics as body. By the way, note that the actor context only applies to code that is placed directly inside the async closure, as well as to synchronous functions the closure calls. Async functions choose their own execution context, so any call to an async function can switch to a different executor. For example, if you call URLSession.data(from:) inside a main-actor-annotated function, the runtime will hop to the global cooperative executor to execute that method. See SE-0338: Clarify the Execution of Non-Actor-Isolated Async Functions for the precise rules. On Apple’s policy to hide annotations in documentation I understand Apple’s impetus not to show unofficial API or language features in the documentation lest developers get the preposterous idea to use these features in their own code! But it makes understanding so much harder. Before I saw the annotations in the .swiftinterface file, the behavior of the code at the beginning of this article never made sense to me. Hiding the details makes things seem like magic when they actually aren’t. And that’s not good, either.

iOS 16 beta 4 is the first SDK release that supports Live Activities. A Live Activity is a widget-like view an app can place on your lock screen and update in real time. Examples where this can be useful include live sports scores or train departure times. These are my notes on playing with the API and implementing my first Live Activity. A bike computer on your lock screen My Live Activity is a display for a bike computer that I’ve been developing with a group a friends. Here’s a video of it in action: Download video And here with simulated data: Download video I haven’t talked much about our bike computer project publicly yet; that will hopefully change someday. In short, a group of friends and I designed a little box that connects to your bike’s hub dynamo, measures speed and distance, and sends the data via Bluetooth to an iOS app. The app records all your rides and can also act as a live speedometer when mounted on your bike’s handlebar. It’s this last feature that I wanted to replicate in the Live Activity. Follow Apple’s guide Adding a Live Activity to the app wasn’t hard. I found Apple’s guide Displaying live data on the Lock Screen with Live Activities easy to follow and quite comprehensive. No explicit user approval iOS doesn’t ask the user for approval when an app wants to show a Live Activity. I found this odd since it seems to invite developers to abuse the feature, but maybe it’s OK because of the foreground requirement (see below). Plus, users can disallow Live Activities on a per-app basis in Settings. Users can dismiss an active Live Activity from the lock screen by swiping (like a notification). Most apps will probably need to ask the user for notification permissions to update their Live Activities. The app must be in the foreground to start an activity To start a Live Activity, an app must be open in the foreground. This isn’t ideal for the bike computer because the speedometer can’t appear magically on the lock screen when the user starts riding (even though iOS wakes up the app in the background at this point to deliver the Bluetooth events from the bike). The user has to open the app manually at least once. On the other hand, this limitation may not be an issue for most use cases and will probably cut down on spamming/abuse significantly. The app must keep running in the background to update the activity (or use push notifications) As long as the app keeps running (in the foreground or background), it can update the Live Activity as often as it wants (I think). This is ideal for the bike computer as the app keeps running in the background processing Bluetooth events while the bike is in motion. I assume the same applies to other apps that can remain alive in the background, such as audio players or navigation apps doing continuous location monitoring. Updating the Live Activity once per second was no problem in my testing, and I didn’t experience any rate limiting. Most apps get suspended in the background, however. They must use push notifications to update their Live Activity (or background tasks or some other mechanism to have the system wake you up). Apple introduced a new kind of push notification that is delivered directly to the Live Activity, bypassing the app altogether. I haven’t played with push notification updates, so I don’t know the benefits of using this method over sending a silent push notification to wake the app and updating the Live Activity from there. Probably less aggressive rate limiting? Lock screen color matching I haven’t found a good way to match my Live Activity’s colors to the current system colors on the lock screen. By default, text in a Live Activity is black in light mode, whereas the built-in lock screen themes seem to favor white or other light text colors. If there is an API or environment value that allows apps to match the color style of the current lock screen, I haven’t found it. I experimented with various foreground styles, such as materials, without success. I ended up hardcoding the foreground color, but I’m not satisfied with the result. Depending on the user’s lock screen theme, the Live Activity can look out of place. The default text color of a Live Activity in light mode is black. This doesn’t match most lock screen themes. Animations can’t be disabled Apple’s guide clearly states that developers have little control over animations in a Live Activity: Animate content updates When you define the user interface of your Live Activity, the system ignores any animation modifiers — for example, withAnimation(_:_:) and animation(_:value:) — and uses the system’s animation timing instead. However, the system performs some animation when the dynamic content of the Live Activity changes. Text views animate content changes with blurred content transitions, and the system animates content transitions for images and SF Symbols. If you add or remove views from the user interface based on content or state changes, views fade in and out. Use the following view transitions to configure these built-in transitions: opacity, move(edge:), slide, push(from:), or combinations of them. Additionally, request animations for timer text with numericText(countsDown:). It makes total sense to me that Apple doesn’t want developers to go crazy with animations on the lock screen, and perhaps having full control over animations also makes it easier for Apple to integrate Live Activities into the always-on display that’s probably coming on the next iPhone. What surprised me is that I couldn’t find a way to disable the text change animations altogether. I find the blurred text transitions for the large speed value quite distracting and I think this label would look better without any animations. But no combination of .animation(nil), .contentTransition(.identity), and .transition(.identity) would do this. Sharing code between app and widget A Live Activity is very much like a widget: the UI must live in your app’s widget extension. You start the Live Activity with code that runs in your app, though. Both targets (the app and the widget extension) need access to a common data type that represents the data the widget displays. You should have a third target (a framework or SwiftPM package) that contains such shared types and APIs and that the downstream targets import. Availability annotations Update September 22, 2022: This limitation no longer applies. The iOS 16.1 SDK added the ability to have availability conditions in WidgetBundle. Source: Tweet from Luca Bernardi (2022-09-20). WidgetBundle apparently doesn’t support widgets with different minimum deployment targets. If your widget extension has a deployment target of iOS 14 or 15 for an existing widget and you now want to add a Live Activity, I’d expect your widget bundle to look like this: @main struct MyWidgets: WidgetBundle { var body: some Widget { MyNormalWidget() // Error: Closure containing control flow statement cannot // be used with result builder 'WidgetBundleBuilder' if #available(iOSApplicationExtension 16.0, *) { MyLiveActivityWidget() } } } But this doesn’t compile because the result builder type used by WidgetBundle doesn’t support availability conditions. I hope Apple fixes this. This wasn’t a problem for me because our app didn’t have any widgets until now, so I just set the deployment target of the widget extension to iOS 16.0. If you have existing widgets and can’t require iOS 16 yet, a workaround is to add a second widget extension target just for the Live Activity. I haven’t tried this, but WidgetKit explicitly supports having multiple widget extensions, so it should work: Typically, you include all your widgets in a single widget extension, although your app can contain multiple extensions.

@MainActor is a Swift annotation to coerce a function to always run on the main thread and to enable the compiler to verify this. How does this work? In this article, I’m going to reimplement @MainActor in a slightly simplified form for illustration purposes, mainly to show how little “magic” there is to it. The code of the real implementation in the Swift standard library is available in the Swift repository. @MainActor relies on two Swift features, one of them unofficial: global actors and custom executors. Global actors MainActor is a global actor. That is, it provides a single actor instance that is shared between all places in the code that are annotated with @MainActor. All global actors must implement the shared property that’s defined in the GlobalActor protocol (every global actor implicitly conforms to this protocol): @globalActor final actor MyMainActor { // Requirements from the implicit GlobalActor conformance typealias ActorType = MyMainActor static var shared: ActorType = MyMainActor() // Don’t allow others to create instances private init() {} } At this point, we have a global actor that has the same semantics as any other actor. That is, functions annotated with @MyMainActor will run on a thread in the cooperative thread pool managed by the Swift runtime. To move the work to the main thread, we need another concept, custom executors. Executors A bit of terminology: The compiler splits async code into jobs. A job roughly corresponds to the code from one await (= potential suspension point) to the next. The runtime submits each job to an executor. The executor is the object that decides in which order and in which context (i.e. which thread or dispatch queue) to run the jobs. Swift ships with two built-in executors: the default concurrent executor, used for “normal”, non-actor-isolated async functions, and a default serial executor. Every actor instance has its own instance of this default serial executor and runs its code on it. Since the serial executor, like a serial dispatch queue, only runs a single job at a time, this prevents concurrent accesses to the actor’s state. Custom executors As of Swift 5.6, executors are an implementation detail of Swift’s concurrency system, but it’s almost certain that they will become an official feature fairly soon. Why? Because it can sometimes be useful to have more control over the execution context of async code. Some examples are listed in a draft proposal for allowing developers to implement custom executors that was first pitched in February 2021 but then didn’t make the cut for Swift 5.5. @MainActor already uses the unofficial ability for an actor to provide a custom executor, and we’re going to do the same for our reimplementation. A serial executor that runs its job on the main dispatch queue is implemented as follows. The interesting bit is the enqueue method, where we tell the job to run on the main dispatch queue: final class MainExecutor: SerialExecutor { func asUnownedSerialExecutor() -> UnownedSerialExecutor { UnownedSerialExecutor(ordinary: self) } func enqueue(_ job: UnownedJob) { DispatchQueue.main.async { job._runSynchronously(on: self.asUnownedSerialExecutor()) } } } We’re responsible for keeping an instance of the executor alive, so let’s store it in a global: private let mainExecutor = MainExecutor() Finally, we need to tell our global actor to use the new executor: import Dispatch @globalActor final actor MyMainActor { // ... // Requirement from the implicit GlobalActor conformance static var sharedUnownedExecutor: UnownedSerialExecutor { mainExecutor.asUnownedSerialExecutor() } // Requirement from the implicit Actor conformance nonisolated var unownedExecutor: UnownedSerialExecutor { mainExecutor.asUnownedSerialExecutor() } } That’s all there is to reimplement the basics of @MainActor. Conclusion The full code is on GitHub, including a usage example to demonstrate that the @MyMainActor annotations work. John McCall’s draft proposal for custom executors is worth reading, particularly the philosophy section. It’s an easy-to-read summary of some of the design principles behind Swift’s concurrency system: Swift’s concurrency design sees system threads as expensive and rather precious resources. … It is therefore best if the system allocates a small number of threads — just enough to saturate the available cores — and for those threads [to] only block for extended periods when there is no pending work in the program. Individual functions cannot effectively make this decision about blocking, because they lack a holistic understanding of the state of the program. Instead, the decision must be made by a centralized system which manages most of the execution resources in the program. This basic philosophy of how best to use system threads drives some of the most basic aspects of Swift’s concurrency design. In particular, the main reason to add async functions is to make it far easier to write functions that, unlike standard functions, will reliably abandon a thread when they need to wait for something to complete. And: The default concurrent executor is used to run jobs that don’t need to run somewhere more specific. It is based on a fixed-width thread pool that scales to the number of available cores. Programmers therefore do not need to worry that creating too many jobs at once will cause a thread explosion that will starve the program of resources.

Here’s a simple AttributedString with some formatting: import Foundation let str = try! AttributedString( markdown: "Café **Sol**", options: .init(interpretedSyntax: .inlineOnly) ) AttributedString is Codable. If your task was to design the encoding format for an attributed string, what would you come up with? Something like this seems reasonable (in JSON with comments): { "text": "Café Sol", "runs": [ { // start..<end in Character offsets "range": [5, 8], "attrs": { "strong": true } } ] } This stores the text alongside an array of runs of formatting attributes. Each run consists of a character range and an attribute dictionary. Unicode is complicated But this format is bad and can break in various ways. The problem is that the character offsets that define the runs aren’t guaranteed to be stable. The definition of what constitutes a Character, i.e. a user-perceived character, or a Unicode grapheme cluster, can and does change in new Unicode versions. If we decoded an attributed string that had been serialized on a different OS version (before Swift 5.6, Swift used the OS’s Unicode library for determining character boundaries), or by code compiled with a different Swift version (since Swift 5.6, Swift uses its own grapheme breaking algorithm that will be updated alongside the Unicode standard)1, the character ranges might no longer represent the original intent, or even become invalid. Update April 11, 2024: See this Swift forum post I wrote for an example where the Unicode rules for grapheme cluster segmentation changed for flag emoji. This change caused a corresponding change in how Swift counts the Characters in a string containing consecutive flags, such as "🇦🇷🇯🇵". Normalization forms So let’s use UTF-8 byte offsets for the ranges, I hear you say. This avoids the first issue but still isn’t safe, because some characters, such as the é in the example string, have more than one representation in Unicode: it can be either the standalone character é (Latin small letter e with acute) or the combination of e + ◌́ (Combining acute accent). The Unicode standard calls these variants normalization forms.2 The first form needs 2 bytes in UTF-8, whereas the second uses 3 bytes, so subsequent ranges would be off by one if the string and the ranges used different normalization forms. Now in theory, the string itself and the ranges should use the same normalization form upon serialization, avoiding the problem. But this is almost impossible to guarantee if the serialized data passes through other systems that may (inadvertently or not) change the Unicode normalization of the strings that pass through them. A safer option would be to store the text not as a string but as a blob of UTF-8 bytes, because serialization/networking/storage layers generally don’t mess with binary data. But even then you’d have to be careful in the encoding and decoding code to apply the formatting attributes before any normalization takes place. Depending on how your programming language handles Unicode, this may not be so easy. Foundation’s solution The people on the Foundation team know all this, of course, and chose a better encoding format for Attributed String. Let’s take a look.3 let encoder = JSONEncoder() encoder.outputFormatting = [.prettyPrinted, .sortedKeys] let jsonData = try encoder.encode(str) let json = String(decoding: jsonData, as: UTF8.self) This is how our sample string is encoded: [ "Café ", { }, "Sol", { "NSInlinePresentationIntent" : 2 } ] This is an array of runs, where each run consists of a text segment and a dictionary of formatting attributes. The important point is that the formatting attributes are directly associated with the text segments they belong to, not indirectly via brittle byte or character offsets. (This encoding format is also more space-efficient and possibly better represents the in-memory layout of AttributedString, but that’s beside the point for this discussion.) There’s still a (smaller) potential problem here if the character boundary rules change for code points that span two adjacent text segments: the last character of run N and the first character of run N+1 might suddenly form a single character (grapheme cluster) in a new Unicode version. In that case, the decoding code will have to decide which formatting attributes to apply to this new character. But this is a much smaller issue because it only affects the characters in question. Unlike our original example, where an off-by-one error in run N would affect all subsequent runs, all other runs are untouched. Related forum discussion: Itai Ferber on why Character isn’t Codable. Storing string offsets is a bad idea We can extract a general lesson out of this: Don’t store string indices or offsets if possible. They aren’t stable over time or across runtime environments. On Apple platforms, the Swift standard library ships as part of the OS so I’d guess that the standard library’s grapheme breaking algorithm will be based on the same Unicode version that ships with the corresponding OS version. This is effectively no change in behavior compared to the pre-Swift 5.6 world (where the OS’s ICU library determined the Unicode version). On non-ABI-stable platforms (e.g. Linux and Windows), the Unicode version used by your program is determined by the version of the Swift compiler your program is compiled with, if my understanding is correct. ↩︎ The Swift standard library doesn’t have APIs for Unicode normalization yet, but you can use the corresponding NSString APIs, which are automatically added to String when you import Foundation: import Foundation let precomposed = "é".precomposedStringWithCanonicalMapping let decomposed = "é".decomposedStringWithCanonicalMapping precomposed == decomposed // → true precomposed.unicodeScalars.count // → 1 decomposed.unicodeScalars.count // → 2 precomposed.utf8.count // → 2 decomposed.utf8.count // → 3 ↩︎ By the way, I see a lot of code using String(jsonData, encoding: .utf8)! to create a string from UTF-8 data. String(decoding: jsonData, as: UTF8.self) saves you a force-unwrap and is arguably “cleaner” because it doesn’t depend on Foundation. Since it never fails, it’ll insert replacement characters into the string if it encounters invalid byte sequences. ↩︎

The environment in SwiftUI is sort of like a global dictionary but with stronger types: each key (represented by a key path) can have its own specific value type. For example, the \.isEnabled key stores a boolean value, whereas the \.font key stores an Optional<Font>. I wrote a custom dictionary type that can do the same thing. The HeterogeneousDictionary struct I show in this article stores mixed key-value pairs where each key defines the type of value it stores. The public API is fully type-safe, no casting required. Usage I’ll start with an example of the finished API. Here’s a dictionary for storing text formatting attributes: import AppKit var dict = HeterogeneousDictionary<TextAttributes>() dict[ForegroundColor.self] // → nil // The value type of this key is NSColor dict[ForegroundColor.self] = NSColor.systemRed dict[ForegroundColor.self] // → NSColor.systemRed dict[FontSize.self] // → nil // The value type of this key is Double dict[FontSize.self] = 24 dict[FontSize.self] // → 24 (type: Optional<Double>) We also need some boilerplate to define the set of keys and their associated value types. The code to do this for three keys (font, font size, foreground color) looks like this: // The domain (aka "keyspace") enum TextAttributes {} struct FontSize: HeterogeneousDictionaryKey { typealias Domain = TextAttributes typealias Value = Double } struct Font: HeterogeneousDictionaryKey { typealias Domain = TextAttributes typealias Value = NSFont } struct ForegroundColor: HeterogeneousDictionaryKey { typealias Domain = TextAttributes typealias Value = NSColor } Yes, this is fairly long, which is one of the downsides of this approach. At least you only have to write it once per “keyspace”. I’ll walk you through it step by step. Notes on the API Using types as keys As you can see in this line, the dictionary keys are types (more precisely, metatype values): dict[FontSize.self] = 24 This is another parallel with the SwiftUI environment, which also uses types as keys (the public environment API uses key paths as keys, but you’ll see the types underneath if you ever define your own environment key). Why use types as keys? We want to establish a relationship between a key and the type of values it stores, and we want to make this connection known to the type system. The way to do this is by defining a type that sets up this link. Domains aka “keyspaces” A standard Dictionary is generic over its key and value types. This doesn’t work for our heterogeneous dictionary because we have multiple value types (and we want more type safety than Any provides). Instead, a HeterogeneousDictionary is parameterized with a domain: // The domain (aka "keyspace") enum TextAttributes {} var dict = HeterogeneousDictionary<TextAttributes>() The domain is the “keyspace” that defines the set of legal keys for this dictionary. Only keys that belong to the domain can be put into the dictionary. The domain type has no protocol constraints; you can use any type for this. Defining keys A key is a type that conforms to the HeterogeneousDictionaryKey protocol. The protocol has two associated types that define the relationships between the key and its domain and value type: protocol HeterogeneousDictionaryKey { /// The "namespace" the key belongs to. associatedtype Domain /// The type of values that can be stored /// under this key in the dictionary. associatedtype Value } You define a key by creating a type and adding the conformance: struct Font: HeterogeneousDictionaryKey { typealias Domain = TextAttributes typealias Value = NSFont } Implementation notes A minimal implementation of the dictionary type is quite short: struct HeterogeneousDictionary<Domain> { private var storage: [ObjectIdentifier: Any] = [:] var count: Int { self.storage.count } subscript<Key>(key: Key.Type) -> Key.Value? where Key: HeterogeneousDictionaryKey, Key.Domain == Domain { get { self.storage[ObjectIdentifier(key)] as! Key.Value? } set { self.storage[ObjectIdentifier(key)] = newValue } } } Internal storage private var storage: [ObjectIdentifier: Any] = [:] Internally, HeterogeneousDictionary uses a dictionary of type [ObjectIdentifier: Any] for storage. We can’t use a metatype such as Font.self directly as a dictionary key because metatypes aren’t hashable. But we can use the metatype’s ObjectIdentifier, which is essentially the address of the type’s representation in memory. Subscript subscript<Key>(key: Key.Type) -> Key.Value? where Key: HeterogeneousDictionaryKey, Key.Domain == Domain { get { self.storage[ObjectIdentifier(key)] as! Key.Value? } set { self.storage[ObjectIdentifier(key)] = newValue } } The subscript implementation constrains its arguments to keys in the same domain as the dictionary’s domain. This ensures that you can’t subscript a dictionary for text attributes with some other unrelated key. If you find this too restrictive, you could also remove all references to the Domain type from the code; it would still work. Using key paths as keys Types as keys don’t have the best syntax. I think you’ll agree that dict[FontSize.self] doesn’t read as nice as dict[\.fontSize], so I looked into providing a convenience API based on key paths. My preferred solution would be if users could define static helper properties on the domain type, which the dictionary subscript would then accept as key paths, like so: extension TextAttributes { static var fontSize: FontSize.Type { FontSize.self } // Same for font and foregroundColor } Sadly, this doesn’t work because Swift 5.6 doesn’t (yet?) support key paths to static properties (relevant forum thread). We have to introduce a separate helper type that acts as a namespace for these helper properties. Since the dictionary type can create an instance of the helper type, it can access the non-static helper properties. This doesn’t feel as clean to me, but it works. I called the helper type HeterogeneousDictionaryValues as a parallel with EnvironmentValues, which serves the same purpose in SwiftUI. The code for this is included in the Gist. Drawbacks Is the HeterogeneousDictionary type useful? I’m not sure. I wrote this mostly as an exercise and haven’t used it yet in a real project. In most cases, if you need a heterogeneous record with full type safety, it’s probably easier to just write a new struct where each property is optional — the boilerplate for defining the dictionary keys is certainly longer and harder to read. For representing partial values, i.e. struct-like records where some but not all properties have values, take a look at these two approaches from 2018: Ian Keen, Type-safe temporary models (2018-06-05) Joseph Duffy, Partial in Swift (2018-07-10), also available as a library These use a similar storage approach (a dictionary of Any values with custom accessors to make it type-safe), but they use an existing struct as the domain/keyspace, combined with partial key paths into that struct as the keys. I honestly think that this is the better design for most situations. Aside from the boilerplate, here are a few more weaknesses of HeterogeneousDictionary: Storage is inefficient because values are boxed in Any containers Accessing values is inefficient: every access requires unboxing HeterogeneousDictionary can’t easily conform to Sequence and Collection because these protocols require a uniform element type The code The full code is available in a Gist.

We released the fifth edition of our book Advanced Swift a few days ago. You can buy the ebook on the objc.io site. The hardcover print edition is printed and sold by Amazon (amazon.com, amazon.co.uk, amazon.de). Highlights of the new edition: Fully updated for Swift 5.6 A new Concurrency chapter covering async/await, structured concurrency, and actors New content on property wrappers, result builders, protocols, and generics The print edition is now a hardcover (for the same price) Free update for owners of the ebook A growing book for a growing language Updating the book always turns out to be more work than I expect. Swift has grown substantially since our last release (for Swift 5.0), and the size of the book reflects this. The fifth edition is 76 % longer than the first edition from 2016. This time, we barely stayed under 1 million characters: Character counts of Advanced Swift editions from 2016–2022. Many thanks to our editor, Natalye, for reading all this and improving our Dutch/German dialect of English. Hardcover For the first time, the print edition comes in hardcover (for the same price). Being able to offer this makes me very happy. The hardcover book looks much better and is more likely to stay open when laid flat on a table. We also increased the page size from 15×23 cm (6×9 in) to 18×25 cm (7×10 in) to keep the page count manageable (Amazon’s print on demand service limits hardcover books to 550 pages). I hope you enjoy the new edition. If you decide to buy the book or if you bought it in the past, thank you very much! And if you’re willing to write a review on Amazon, we’d appreciate it.

Cancellation is a Swift concurrency feature, but this doesn’t mean it’s only available in async functions. Synchronous functions can also support cancellation, and by doing so they’ll become better concurrency citizens when called from async code. Motivating example: JSONDecoder Supporting cancellation makes sense for functions that can block for significant amounts of time (say, more than a few milliseconds). Take JSON decoding as an example. Suppose we wrote an async function that performs a network request and decodes the downloaded JSON data: import Foundation func loadJSON<T: Decodable>(_ type: T.Type, from url: URL) async throws -> T { let (data, _) = try await URLSession.shared.data(from: url) return try JSONDecoder().decode(type, from: data) } The JSONDecoder.decode call is synchronous: it will block its thread until it completes. And if the download is large, decoding may take hundreds of milliseconds or even longer. Avoid blocking if possible In general, async code should avoid calling blocking APIs if possible. Instead, async functions are expected to suspend regularly to give waiting tasks a chance to run. But JSONDecoder doesn’t have an async API (yet?), and I’m not even sure it can provide one that works with the existing Codable protocols, so let’s work with what we have. And if you think about it, it’s not totally unreasonable for JSONDecoder to block. After all, it is performing CPU-intensive work (assuming the data it’s working on doesn’t have to be paged in), and this work has to happen on some thread. Async/await works best for I/O-bound functions that spend most of their time waiting for the disk or the network. If an I/O-bound function suspends, the runtime can give the function’s thread to another task that can make more productive use of the CPU. Responding to cancellation Cancellation is a cooperative process. Canceling a task only sets a flag in the task’s metadata. It’s up to individual functions to periodically check for cancellation and abort if necessary. If a function doesn’t respond promptly to cancellation or outright ignores the cancellation flag, the program may appear to the user to be stalling. Now, if the task is canceled while JSONDecoder.decode is running, our loadJSON function can’t react properly because it can’t interrupt the decoding process. To fix this, the decode method would have to perform its own periodic cancellation checks, using the usual APIs, Task.isCancelled or Task.checkCancellation(). These can be called from anywhere, including synchronous code. Internals How does this work? How can synchronous code access task-specific metadata? Here’s the code for Task.isCancelled in the standard library: extension Task where Success == Never, Failure == Never { public static var isCancelled: Bool { withUnsafeCurrentTask { task in task?.isCancelled ?? false } } } This calls withUnsafeCurrentTask to get a handle to the current task. When the runtime schedules a task to run on a particular thread, it stores a pointer to the task object in that thread’s thread-local storage, where any code running on that thread – sync or async – can access it. If task == nil, there is no current task, i.e. we haven’t been called (directly or indirectly) from an async function. In this case, cancellation doesn’t apply, so we can return false. If we do have a task handle, we ask the task for its isCancelled flag and return that. Reading the flag is an atomic (thread-safe) operation because other threads may be writing to it concurrently. Conclusion I hope we’ll see cancellation support in the Foundation encoders and decoders in the future. If you have written synchronous functions that can potentially block their thread for a significant amount of time, consider adding periodic cancellation checks. It’s a quick way to make your code work better with the concurrency system, and you don’t even have to change your API to do it. Update February 2, 2022: Jordan Rose argues that cancellation support for synchronous functions should be opt-in because it introduces a failure mode that’s hard to reason about locally as the “source“ of the failure (the async context) may be several levels removed from the call site. Definitely something to consider!

In Swift’s concurrency model, cancellation is cooperative. To be a good concurrency citizen, code must periodically check if the current task has been cancelled, and react accordingly. You can check for cancellation by calling Task.isCancelled or with try Task.checkCancellation() — the latter will exit by throwing a CancellationError if the task has been cancelled. By convention, functions should react to cancellation by throwing a CancellationError. But this convention isn’t enforced, so callers must be aware that cancellation can manifest itself in other forms. Here are some other ways how functions might respond to cancellation: Throw a different error. For example, the async networking APIs in Foundation, such as URLSession.data(from: URL), throw a URLError with the code URLError.Code.cancelled on cancellation. It’d be nice if URLSession translated this error to CancellationError, but it doesn’t. Return a partial result. A function that has completed part of its work when cancellation occurs may choose to return a partial result rather than throwing the work away and aborting. In fact, this may be the best choice for a non-throwing function. But note that this behavior can be extremely surprising to callers, so be sure to document it clearly. Do nothing. Functions are supposed to react promptly to cancellation, but callers must assume the worst. Even if cancelled, a function might run to completion and finish normally. Or it might eventually respond to cancellation by aborting, but not promptly because it doesn’t perform its cancellation checks often enough. So as the caller of a function, you can’t really rely on specific cancellation behavior unless you know how the callee is implemented. Code that wants to know if its task has been cancelled should itself call Task.isCancelled, rather than counting on catching a CancellationError from a callee.

Software Development News

It’s imperative that business leaders can enable their business to work at the speed that technology is moving. However, lengthy and cumbersome approval processes to adopt new tools can hinder an organization’s ability to keep pace, especially when they need to remain compliant with regulations and standards, such as FedRAMP and SOC-2.  With a three-stage … continue reading

The post Accelerate tool adoption with a developer experimentation framework appeared first on SD Times.

It’s imperative that business leaders can enable their business to work at the speed that technology is moving. However, lengthy and cumbersome approval processes to adopt new tools can hinder an organization’s ability to keep pace, especially when they need to remain compliant with regulations and standards, such as FedRAMP and SOC-2. With a three-stage developer experimentation framework, organizations can make it easier to evaluate new technologies, determine their fit and accelerate their adoption across the organization. Stage One: Trial The goal of the first stage involves exploratory testing to gauge how a development tool might benefit the organization. The primary objective is to identify concrete applications for the organization through hands-on experimentation. During the trial stage, the tool should be used only by a small cohort of engineers while it’s still new, untested and unvetted. Additionally, the trial stage should be limited to a short period of time for initial testing of the tool to reduce risk and prevent extended use. This period should allow ample time for initial experimentation to determine the value of a tool and make a decision about whether to explore it in more detail. Stage Two: Pilot The pilot stage expands tool access to a broader group of developers to gather more feedback. By increasing usage across various development teams, the tool’s more tangible benefits can be evaluated to determine whether full-scale implementation across the product development organization is appropriate. If an external vendor is being used and the tool is not publicly available on the internet for download or use without signup, a mutual non-disclosure agreement, or NDA, should be in place with the vendor before entering the pilot stage. This will help to ensure that any discussions held with the vendor remain confidential. The pilot stage must not exceed four to six weeks to prevent the tool from being “unofficially” used by a large set of developers for extended periods of time. Teams can then gather sufficient feedback from a wide enough audience to make an accurate decision about whether the tool should proceed to the rollout stage. Stage Three: Rollout The final stage focuses on successful rollout. The primary objectives include completing thorough legal and security assessments, and creating an effective deployment and enablement strategy to make the tool accessible across all engineering teams. Enablement is especially critical to help drive broader adoption. Without adoption, the deployment would be meaningless. A security review of the tool and its intended uses must be conducted to ensure that the tool is safe to use. The security review must involve detailed analysis of all the information the tool will consume or access, which will help prevent developers from putting themselves or the organization under unnecessary risk. The tool will also need to undergo any procurement and new vendor onboarding processes the organization may have in place. Additionally, success metrics should be created to evaluate if a tool actually achieves its goal, and should focus on the tool’s ability to satisfy the needs of the developers. Streamlining Organization-Wide Tool Adoption Technology is constantly changing, and organizations can’t afford to be left behind. Business leaders need to be confident that the tools that they’re implementing are sustainable and effective long-term. Establishing an experimentation framework enables organizations to streamline their tool adoption process so they can keep up with emerging technology trends. By abandoning any tools that would get ruled out in the trial or pilot phase, they can avoid the risk of dedicating security, legal and procurement overhead to a tool that may ultimately show insufficient value. The post Accelerate tool adoption with a developer experimentation framework appeared first on SD Times.

OpenAI is joining the open weight model game with the launch of gpt-oss-120b and gpt-oss-20b.  Gpt-oss-120b is optimized for production, high reasoning use cases, and gpt-oss-20b is designed for lower latency or local use cases.  According to the company, these open models are comparable to its closed models in terms of performance and capability, but … continue reading

The post OpenAI releases two open weight reasoning models appeared first on SD Times.

OpenAI is joining the open weight model game with the launch of gpt-oss-120b and gpt-oss-20b. Gpt-oss-120b is optimized for production, high reasoning use cases, and gpt-oss-20b is designed for lower latency or local use cases. According to the company, these open models are comparable to its closed models in terms of performance and capability, but at a much lower cost. For example, gpt-oss-120b running on an 80 GB GPU achieved similar performance to o4-mini on core reasoning benchmarks, while gpt-oss-20b running on an edge device with 16 GB of memory was comparable to o3-mini on several common benchmarks. “Releasing gpt-oss-120b and gpt-oss-20b marks a significant step forward for open-weight models,” OpenAI wrote in a post. “At their size, these models deliver meaningful advancements in both reasoning capabilities and safety. Open models complement our hosted models, giving developers a wider range of tools to accelerate leading edge research, foster innovation and enable safer, more transparent AI development across a wide range of use cases.” The new open models are ideal for developers who want to be able to customize and deploy models in their own environment, while developers looking for multimodal support, built-in tools, and integration with OpenAI’s platform would be better suited with the company’s closed models. Both new models are available under the Apache 2.0 license, and are compatible with OpenAI’s Responses API, can be used within agentic workflows, and provide full chain-of-thought. According to OpenAI, these models were trained using its advanced pre- and post-training techniques, with a focus on reasoning, efficiency, and real-world usability in various types of deployment environments. Both models are available for download on Hugging Face and are quantized in MXFP4 to enable gpt-oss-120B to run with 80 GB of memory and gpt-oss-2bb to run with 16 GB. OpenAI also created a playground for developers to experiment with the models online. The company partnered with several deployment providers for these models, including Azure, vLLM, Ollama, llama.cpp, LM Studio, AWS, Fireworks, Together AI, Baseten, Databricks, Vercel, Cloudflare, and OpenRouter. It also worked with NVIDIA, AMD, Cerebras, and Groq to help ensure consistent performance across different systems. As part of the initial release, Microsoft will be providing GPU-optimized versions of the smaller model to Windows devices. “A healthy open model ecosystem is one dimension to helping make AI widely accessible and beneficial for everyone. We invite developers and researchers to use these models to experiment, collaborate and push the boundaries of what’s possible. We look forward to seeing what you build,” the company wrote. The post OpenAI releases two open weight reasoning models appeared first on SD Times.

Microsoft has announced the release of .NET Aspire 9.4, which the company says is the largest update yet.  .NET Aspire is a set of tools, templates, and packages that Microsoft provides to enable developers to build distributed apps with observability built in.  With this release, Aspire’s CLI is now generally available and includes four core … continue reading

The post .NET Aspire’s CLI reaches general availability in 9.4 release appeared first on SD Times.

Microsoft has announced the release of .NET Aspire 9.4, which the company says is the largest update yet. .NET Aspire is a set of tools, templates, and packages that Microsoft provides to enable developers to build distributed apps with observability built in. With this release, Aspire’s CLI is now generally available and includes four core commands: aspire new (use templates to create an app), aspire add (add hosting integrations), aspire run (run the app from any terminal or editor), and aspire config (view, set, and change CLI settings). Additionally, there are two new beta commands that can be turned on using aspire config set. exec allows developers to execute CLI tools and deploy allows apps to be deployed to dev, test, or prod environments. Microsoft also redesigned the experience around its eventing APIs and added an interaction service that allows developers to create custom UX for getting user input. It supports standard text input, masked text input, numeric input, dropdowns, and checkboxes. .NET Aspire also uses this interaction service to collect missing parameter values by prompting the developer for them before starting a resource that needs them. Also new in this release are previews for hosting integrations with GitHub Models and Azure AI Foundry to enable developers to define AI apps in their apphost and then run them locally. “Aspire streamlines distributed, complex app dev, and an increasingly popular example of this is AI development. If you’ve been adding agentic workflows, chatbots, or other AI-enabled experiences to your stacks, you know how difficult it is to try different models, wire them up, deploy them (and authenticate to them!) at dev time, and figure out what’s actually happening while you debug. But, AI-enabled apps are really just distributed apps with a new type of container – an AI model! – which means Aspire is perfect for streamlining this dev loop,” Microsoft wrote in a blog post. And finally, .NET Aspire 9.4 adds the ability to use AddExternalService() to model a URL or endpoint as a resource, get its status, and configure it like any other resource in the apphost. The post .NET Aspire’s CLI reaches general availability in 9.4 release appeared first on SD Times.

With cloud native technologies becoming foundational for software development and deployment, and finding developers skilled in those areas a challenge, talent marketplace provider Andela and the Cloud Native Computing Foundation have partnered to create the Kubernetes African Developer Training Program that more than 5,600 Africans have completed. Andela and the CNCF are looking to train … continue reading

The post African training program creates developers with cloud-native skills appeared first on SD Times.

With cloud native technologies becoming foundational for software development and deployment, and finding developers skilled in those areas a challenge, talent marketplace provider Andela and the Cloud Native Computing Foundation have partnered to create the Kubernetes African Developer Training Program that more than 5,600 Africans have completed. Andela and the CNCF are looking to train between 20,000 – 30,000 African technologists by 2027, skilled in everything required to create and use AI systems. The eight-week program is free, and those completing the training have the option to seek CNCF certification. (Of the 5,600 learners that participated in the training, 1157 have achieved official KCNA certification, according to Andela.) “Kubernetes is a technology you can bet your career on. It’s the backbone of modern software, and increasingly, of scalable AI systems. The demand for this skill is exploding,” Carrol Chang, CEO of Andela, said in an announcement of the program. “At Andela, we’re preparing the technologists of the future who are not just trained to code but to lead in environments where cloud, AI, and orchestration intersect. This partnership helps us to move faster, to bring that kind of talent to the world and to our clients.” Organizations needing specific proficiencies but lacking the ability to upskill their developers quickly enough are turning to these talent marketplaces to fill gaps in their teams. Mike Morris, head of talent engagement provider Torc and Randstad Digital Recruiting, said, “Timezone, plus skill proficiency, plus communication skills are the trifecta for successful remote work models,” Morris said. “We see this with our LATAM community for North American customers similar to how European customers would be closely aligned with Africa’s timezones.” “This partnership underscores the huge demand for cloud native knowledge to enable workers to secure developer, SRE, DevOps, Sysadmin positions and more, whether in their own countries or as remote workers,” said Christophe Sauthier, cloud native training and certification lead at CNCF. The post African training program creates developers with cloud-native skills appeared first on SD Times.

Since the 2001 Agile Manifesto, software development has thrived on principles like “individuals and interactions over processes,” continuous delivery, and embracing change. Over the following decades, we watched Agile disrupt heavyweight, documentation-driven SDLCs by enabling iterative value delivery and adaptive planning. Now, fast forward to 2025, and AI is drastically changing software development. Models like … continue reading

The post Is Agile dead in the age of AI? appeared first on SD Times.

Since the 2001 Agile Manifesto, software development has thrived on principles like “individuals and interactions over processes,” continuous delivery, and embracing change. Over the following decades, we watched Agile disrupt heavyweight, documentation-driven SDLCs by enabling iterative value delivery and adaptive planning. Now, fast forward to 2025, and AI is drastically changing software development. Models like GPT-4o and Claude 3.5 Sonnet can generate code in seconds, prompting a critical question for industry veterans: Is Agile still relevant? Or have AI-driven workflows reshaped what “agile” should be? AI Isn’t Killing Agile, It’s Reframing It Generative AI tools like Copilot and GPT-based systems have become essential in modern developer workflows, automating routine tasks and accelerating prototyping. For example, Robinhood’s engineering teams report that the majority of new code is generated by AI, with near-universal adoption among developers. However, this shift hasn’t spelled the end of Agile. Instead, it’s evolved the roles of Agile practitioners like our engineers at Inflectra. Stand-up meetings, backlog grooming, and iteration planning now incorporate AI insights, which require new competencies like prompt engineering, AI validation, and risk governance. The Productivity Paradox Studies confirm developers using AI complete tasks 56% faster, while Atlassian reports that developers save 10+ hours weekly thanks to AI, yet still lose time to fragmented collaboration and information seeking. The key with these changes is to be aware that AI-driven speed may breed complacency. Research indicates that rapid code generation can lead to technical debt and reduced understanding, which manifests later in sprint cycles. Without adequate human review and refactoring, your code quality may degrade (despite Agile’s iterative guardrails). The Father of Agile Weighs In Kent Beck, co-author of the original Agile Manifesto, compares AI agents to genies — incredibly powerful but unpredictable. He emphasizes AI’s role in boosting creativity and fun, but warns of its volatility. For Beck, Agile is now more about vision, complexity management, and human oversight than code syntax. New AI-Driven Agile Manifesto Our own Dr. Sriram Rajagopalan proposes a reimagined Agile framework tailored for AI-enabled development: Automated Quality Control OVER Software Testing: AI can generate and update test cases continuously, evolving QA as code evolves. Comprehensive Documentation OVER Writing Code: With code ephemeral and reproducible on demand, human-readable architectural docs and traceability become pillars. Risk Management OVER Burndown Charts: Risk scoring, compliance checks, and audit trails must be baked into sprints for regulated industries. Architectural Governance OVER Code Reviews: Pattern drift and sustainability should be managed with automated architecture enforcement (e.g. ModelOps). This updated framework flips Agile values to reflect current needs. AI can generate and rewrite code, so maintaining architectural integrity, safety, and traceability is now critical. Practical Implications for Teams Shift in Roles & Skillsets Prompt Engineers become critical for consistently getting useful AI output. Skilled prompts combine context, constraints, format, and validation instructions using layered structures and role definitions. In fact, we’ve seen JSON prompts used for even more structured VEO 3 generation to enhance replicability. AI Auditors / AI-Ops Specialists monitor hallucinations, correctness, drift, and security issues. They maintain dashboards, post-crisis protocols, and operate across DevOps and ModelOps domains. Traditional Agile roles will also evolve: Scrum Masters can rely on AI for meeting summaries and sprint metrics, but remain essential as facilitators and culture stewards. Product Owners can generate user stories or prototype layouts automatically, but they still refine, prioritize, and human-validate the output to ensure alignment with the vision. Backlog & Discovery Work AI can evaluate epic and story quality using LLM-based quality metrics. Another recent case study showed high satisfaction among product managers refining backlog artifacts with AI assistance, but adoption barriers remain. For example, LLM agents can generate acceptability criteria, edge-case tests, or backlog refinements, accelerating grooming sessions while requiring human review. Coding, Testing & CI/CD AI pair programmers like GitHub Copilot help developers complete tasks faster, resulting in overall developer productivity drastically increasing. AI-generated tests like static analysis, code suggestions, and test case generation are built into pipelines. Continuous testing becomes automated quality control, shifting testing earlier and more fluidly into development cycles. Governance, Risk & Security ModelOps integration ensures AI-generated outputs are monitored for fairness, compliance, drift, bias, and performance to align with enterprise policies and standards. Security becomes central via agent identities, credential handling, and anomaly detection to avoid data leaks or unsafe patterns. We might also see centralized “agent security managers” to balance autonomy and oversight. Ethical bias must be surfaced in recurring backlog sessions. Teams should schedule ethics checkpoints and review AI-suggested features from multiple perspectives. Agile Ceremonies & Metrics Sprint planning is augmented by AI forecasting capacity, estimating risk, and surface dependencies. However, planning still relies on human discretion to anchor AI output in product vision and stakeholder context. Stand-ups and retrospectives can surface trends like prompt efficacy, code rejection rates, hallucination incidents, and team sentiment. While these are automated by agents, they should be reviewed by humans for action items. Traditional metrics like velocity or burndown give way to AI-specific KPIs. These include prompt success rate, test drift, refactor frequency, architectural compliance, and governance gate pass/fail rates. Collaboration & Workflow AI tools reduce cognitive load, so modern developers spend under 16% of their time coding — the rest is spent on coordination, documentation, and context retrieval. This is because AI can’t address information fragmentation or leadership clarity quite yet. Cross-functional alignment still needs to be human-led. AI may identify dependencies or backlog gaps across teams, but resolving them demands negotiation and planning beyond what AI models can provide. Productivity Gains vs. Hidden Costs Significant speed improvements can save time and resources that are reinvested into further innovation instead of cost-cutting. However, increased integration and review time (challenges like coordination overhead per commit) are observed in open-source analysis. Teams need to be cognizant of dependency risk, or becoming overly reliant on AI. This could result in degradation of critical thinking capacity, so teams need to maintain review rituals, pair programming, and deliberate code comprehension. Agile Isn’t Dead, It’s Evolving Agile’s true essence lies in a mindset of adaptability, continuous feedback, and human-centric collaboration. AI doesn’t remove those values, it amplifies execution while heightening the need for human oversight in architecture, risk, and ethical governance. The future of software development isn’t Agile vs. AI, it’s Agile with AI. Strategic alignment, mentorship, and smart governance make sure that AI’s power enhances safety, maintainability, and long-term product value. Actionable Recommendations for Agile + AI Define AI Governance Policies: Use a 5 W’s framework (Who, What, When, Where, Why) to clarify who can use AI, for what purposes, and under what oversight. Launch Pilot Agentic Pods: Small teams should combine human roles with AI agents (dev, QA, backlog refinement) to test workflows. Track AI-Specific Metrics: Leverage KPIs like prompt accuracy, hallucinations, test drift, and governance gate passes/fails. Upskill Agile Professionals: Train Scrum Masters, Product Owners, and Architects in prompt engineering, AI auditing, and context review. Embed Continuous QA & Architecture Checks: Combine model-driven architectural governance with AI QA automation in CI/CD pipelines. Agility (and software craftsmanship) is far from obsolete. It’s evolving into a framework where human-guided, AI-accelerated delivery becomes the norm. Practitioners who embrace this hybrid model will shape the future. The post Is Agile dead in the age of AI? appeared first on SD Times.

Companies rushed into AI adoption without building the data foundations necessary to make it work reliably. Now they’re discovering that even the most sophisticated algorithms can’t overcome fundamentally flawed information, and the consequences extend far beyond poor performance metrics.  The problem is strategic. Companies are building AI applications on data foundations that were never designed … continue reading

The post The hidden crisis behind AI’s promise: Why data quality became an afterthought appeared first on SD Times.

Companies rushed into AI adoption without building the data foundations necessary to make it work reliably. Now they’re discovering that even the most sophisticated algorithms can’t overcome fundamentally flawed information, and the consequences extend far beyond poor performance metrics. The problem is strategic. Companies are building AI applications on data foundations that were never designed to support machine learning, creating systems that amplify existing biases and produce unreliable results at scale. The implications become visible in products and applications where poor data quality directly affects AI performance and reliability. This conversation shouldn’t need to happen. Data quality is so essential to successful AI implementation that it should be a prerequisite, not an afterthought. Yet organizations across industries are discovering this truth only after deploying AI systems that fail to deliver expected results. From Gradual Growth to Instant Access Historically, organizations developed AI capabilities through a natural progression. They built strong data foundations, moved into advanced analytics, and eventually graduated to machine learning. This organic growth ensured data quality practices evolved alongside technical sophistication. The generative AI revolution disrupted this sequence. Suddenly, powerful AI tools became available to anyone with an API key, regardless of their data maturity. Organizations could start building AI applications immediately, without the infrastructure that previously acted as a natural quality filter. In the past, companies grew AI capability based on very strong data foundations. But what changed in the last 18-24 months is that AI became highly accessible. Everybody jumped into AI adoption without the preparatory work that traditionally preceded advanced analytics projects. This accessibility created a false sense of simplicity. While AI models can handle natural language and unstructured data more easily than previous technologies, they remain fundamentally dependent on data quality for reliable outputs. The Garbage In, Garbage Out Reality The classic programming principle “garbage in, garbage out” takes on new urgency with AI systems that can influence real-world decisions. Poor data quality can perpetuate harmful biases and lead to discriminatory outcomes that trigger regulatory scrutiny. Consider a medical research example: for years, ulcers were attributed to stress because every patient in datasets experienced stress. Machine learning models would have confidently identified stress as the cause, even though bacterial infections were actually responsible. The data reflected correlation, not causation, but AI systems can’t distinguish between the two without proper context. This represents real-world evidence of why data quality demands attention. If datasets only contain correlated information rather than causal relationships, machine learning models will produce confident but incorrect conclusions that can influence critical decisions. The Human Element in Data Understanding Addressing AI data quality requires more human involvement, not less. Organizations need data stewardship frameworks that include subject matter experts who understand not just technical data structures, but business context and implications. These data stewards can identify subtle but crucial distinctions that pure technical analysis might miss. In educational technology, for example, combining parents, teachers, and students into a single “users” category for analysis would produce meaningless insights. Someone with domain expertise knows these groups serve fundamentally different roles and should be analyzed separately. The person who excels with models and dataset analysis might not be the best person to understand what the data means for the business. That’s why data stewardship requires both technical and domain expertise. This human oversight becomes especially critical as AI systems make decisions that affect real people — from hiring and lending to healthcare and criminal justice applications. Regulatory Pressure Drives Change The push for better data quality isn’t coming primarily from internal quality initiatives. Instead, regulatory pressure is forcing organizations to examine their AI data practices more carefully. In the United States, various states are adopting regulations governing AI use in decision-making, particularly for hiring, licensing, and benefit distribution. These laws require organizations to document what data they collect, obtain proper consent, and maintain auditable processes that can explain AI-driven decisions. Nobody wants to automate discrimination. Certain data parameters cannot be used for making decisions, otherwise, it will be perceived as discrimination and difficult to defend the model. The regulatory focus on explainable AI creates additional data quality requirements. Organizations must not only ensure their data is accurate and complete but also structure it in ways that enable clear explanations of how decisions are made. Subtle Biases in Training Data Data bias extends beyond obvious demographic characteristics to subtle linguistic and cultural patterns that can reveal an AI system’s training origins. The word “delve,” for example, appears disproportionately in AI-generated text because it’s more common in training data from certain regions than in typical American or British business writing. Because of reinforced learning, certain words were introduced and statistically appear much higher in text produced with specific models. Users will actually see that bias reflected in outputs. These linguistic fingerprints demonstrate how training data characteristics inevitably appear in AI outputs. Even seemingly neutral technical choices about data sources can introduce systematic biases that affect user experience and model effectiveness. Quality Over Quantity Strategy Despite the industry’s excitement about new AI model releases, a more disciplined approach focused on clearly defined use cases rather than maximum data exposure proves more effective. Instead of opting for more data to be shared with AI, sticking to the basics and thinking about product concepts produces better results. You don’t want to just throw a lot of good stuff in a can and assume that something good will happen. This philosophy runs counter to the common assumption that more data automatically improves AI performance. In practice, carefully curated, high-quality datasets often produce better results than massive, unfiltered collections. The Actionable AI Future Looking ahead, “actionable AI” systems will reliably perform complex tasks without hallucination or errors. These systems would handle multi-step processes like booking movie tickets at unfamiliar theaters, figuring out interfaces and completing transactions autonomously. Imagine asking your AI assistant to book a ticket for you, and although that AI engine has never worked with that provider, it will figure out how to do it. You will receive a confirmation email in your inbox without any manual intervention. Achieving this level of reliability requires solving current data quality challenges while building new infrastructure for data entitlement and security. Every data field needs automatic annotation and classification that AI models respect inherently, rather than requiring manual orchestration. Built-in Data Security Future AI systems will need “data entitlement” capabilities that automatically understand and respect access controls and privacy requirements. This goes beyond current approaches that require manual configuration of data permissions for each AI application. Models should be respectful of data entitlements. Breaking down data silos should not create new, more complex problems by accidentally leaking data. This represents a fundamental shift from treating data security as an external constraint to making it an inherent characteristic of AI systems themselves. Strategic Implications The data quality crisis in AI reflects a broader challenge in technology adoption: the gap between what’s technically possible and what’s organizationally ready. Companies that address data stewardship, bias detection, and quality controls now will have significant advantages as AI capabilities continue advancing. The organizations that succeed will be those that resist the temptation to deploy AI as quickly as possible and instead invest in the foundational work that makes AI reliable and trustworthy. This includes not just technical infrastructure, but also governance frameworks, human expertise, and cultural changes that prioritize data quality over speed to market. As regulatory requirements tighten and AI systems take on more consequential decisions, companies that skipped data quality fundamentals will face increasing risks. Those who built strong foundations will be positioned to take advantage of advancing AI capabilities while maintaining the trust and compliance necessary for sustainable growth. The path forward requires acknowledging that AI’s promise can only be realized when built on solid data foundations. Organizations must treat data quality as a strategic imperative, not a technical afterthought. The companies that understand this distinction will separate themselves from those still struggling with the fundamental challenge of making AI work reliably at scale. The post The hidden crisis behind AI’s promise: Why data quality became an afterthought appeared first on SD Times.

Google’s new Opal tool allows users to create mini AI apps with no coding required Google has launched a new experimental AI tool designed for users who want to build apps entirely using AI prompts, with no coding needed at all. Opal allows users to create mini AI apps by chaining together AI prompts, models, and … continue reading

The post July 2025: All AI updates from the past month appeared first on SD Times.

Google’s new Opal tool allows users to create mini AI apps with no coding required Google has launched a new experimental AI tool designed for users who want to build apps entirely using AI prompts, with no coding needed at all. Opal allows users to create mini AI apps by chaining together AI prompts, models, and tools, using natural language and visual editing. “Opal is a great tool to accelerate prototyping AI ideas and workflows, demonstrate a proof of concept with a functional app, build custom AI apps to boost your productivity at work, and more,” Google wrote in a blog post. The tool consists of a visual editor to help creators see the workflows in their apps and connect different prompts together to build multi-step apps. It allows the user to describe the logic they want in the app and have Opal build the workflow for them. Users will be able to edit the generated workflow either in the visual editor or through additional prompts. Gemini 2.5 Flash-Lite is now generally available The model is Google’s fastest and cheapest model, costing $0.10/1M tokens for input and $0.40/1M tokens for output (compared to $1.25/1M tokens for input and $10/1M tokens for output in Gemini 2.5 Pro). “We built 2.5 Flash-Lite to push the frontier of intelligence per dollar, with native reasoning capabilities that can be optionally toggled on for more demanding use cases. Building on the momentum of 2.5 Pro and 2.5 Flash, this model rounds out our set of 2.5 models that are ready for scaled production use,” Google wrote in a blog post. GitLab Duo Agent Platform enters beta GitLab Duo Agent Platform is an orchestration platform for AI agents that work across DevSecOps in parallel. For instance, a user could delegate a refactoring task to a Software Developer Agent, have a Security Analyst Agent scan for vulnerabilities, and have a Deep Research Agent analyze progress across the repository. Some of the other agents that GitLab is building as part of this include a Chat Agent, Product Planning Agent, Software Test Engineer Agent, Code Reviewer Agent, Platform Engineer Agent, and Deployment Engineer Agent. The first beta is available for GitLab.com and self-managed GitLab Premium and Ultimate customers. It includes a VS Code extension and JetBrains IDEs plugins, and next month the company plans to add it to GitLab and expand IDE support. Google adds updated workspace templates in Firebase Studio that leverage new Agent mode Google is adding several new features to its cloud-based AI workspace Firebase Studio, following its update a few weeks ago when it added new Agent modes, support for MCP, and integration with the Gemini CLI. Now it is announcing updated workspace templates for Flutter, Angular, React, Next.js, and general Web that use the Agent mode by default. Users will still be able to toggle between the “Ask” and Agent mode, depending on what the task at hand calls for. The templates now have an airules.md file to provide Gemini with instructions for code generation, like specific coding standards, handling methods, dependencies, and development best practices. Google says it will be updating templates for frameworks like Go, Node.js, and .NET over the next few weeks as well. ChatGPT now has an agent mode OpenAI is bringing the power of agentic AI to ChatGPT so that it can handle complex requests from users autonomously. It leverages two of OpenAI’s existing capabilities: Operator, which can interact with websites, and deep research, which can synthesize information. According to OpenAI, these capabilities were best suited for different situations, with Operator struggling with complex analysis and deep research being unable to interact with websites to refine results or access content that required authentication. “By integrating these complementary strengths in ChatGPT and introducing additional tools, we’ve unlocked entirely new capabilities within one model. It can now actively engage websites—clicking, filtering, and gathering more precise, efficient results. You can also naturally transition from a simple conversation to requesting actions directly within the same chat,” the company wrote in a blog post. YugabyteDB adds new capabilities for AI developers The company added new vector search capabilities, an MCP Server, and built-in Connection Pooling to support tens of thousands of connections per node. Additionally, it announced support for LangChain, OLLama, LlamaIndex, AWS Bedrock, and Google Vortex AI. Finally, YugabyteDB now has multi-modal API support with the addition of support for the MongoDB API. “Today’s launch is another key step in our quest to deliver the database of choice for developers building mission-critical AI-powered applications,” said Karthik Ranganathan, co-founder and CEO, Yugabyte. “As we continuously enhance YugabyteDB’s compatibility with PostgreSQL, the expanded multi-modal support, a new YugabyteDB MCP server, and wider integration with the AI ecosystem provide AI app developers with the tools and flexibility they need for future success.” Composio raises $29 million in Series A funding The company is trying to build a shared learning layer for AI agents so that they can learn from experience. “You can spend hundreds of hours building LLM tools, tweaking prompts, and refining instructions, but you hit a wall,” said Soham Ganatra, CEO of Composio. “These models don’t get better at their jobs the way a human employee would. They can’t build context, learn from mistakes, or develop the subtle understanding that makes human workers invaluable. We’re solving this at the infrastructure level.” This funding round will be used to accelerate the development of Composio’s learning infrastructure. The round was led by Lightspeed Venture Partners, with participation from Vercel’s CEO Guillermo Rauch, HubSpot’s CTO and founder Dharmesh Shah, investor Gokul Rajaram, Rubrik’s co-founder Soham Mazumdar, V Angel, Blitzscaling Ventures, Operator Partners, and Agent Fund by Yohei Nakajima, in addition to existing investors Elevation Capital and Together Fund. Parasoft brings agentic AI to service virtualization in latest release The company added an agentic AI assistant to its virtual testing simulation solution Virtualize, allowing customers to create virtual services using natural language prompts. For example, a user could write the prompt: “Create a virtual service for a payment processing API. There should be a POST and a GET operation. The operations should require an account id along with other data related to payment.” The platform will then draw from the provided API service definitions, sample requests/responses, and written descriptions of a service to generate a virtual service with dynamic behavior, parameterized responses, and the correct default values. Slack’s AI search now works across an organization’s entire knowledge base Slack is introducing a number of new AI-powered tools to make team collaboration easier and more intuitive. “Today, 60% of organizations are using generative AI. But most still fall short of its productivity promise. We’re changing that by putting AI where work already happens — in your messages, your docs, your search — all designed to be intuitive, secure, and built for the way teams actually work,” Slack wrote in a blog post. The new enterprise search capability will enable users to search not just in Slack, but any app that is connected to Slack. It can search across systems of record like Salesforce or Confluence, file repositories like Google Drive or OneDrive, developer tools like GitHub or Jira, and project management tools like Asana. “Enterprise search is about turning fragmented information into actionable insights, helping you make quicker, more informed decisions, without leaving Slack,” the company explained. The platform is also getting AI-generated channel recaps and thread summaries, helping users catch up on conversations quickly. It is introducing AI-powered translations as well to enable users to read and respond in their preferred language. Anthropic’s Claude Code gets new analytics dashboard to provide insights into how teams are using AI tooling Anthropic has announced the launch of a new analytics dashboard in Claude Code to give development teams insights into how they are using the tool. It tracks metrics such as lines of code accepted, suggestion acceptance rate, total user activity over time, total spend over time, average daily spend for each user, and average daily lines of code accepted for each user. These metrics can help organizations understand developer satisfaction with Claude Code suggestions, track code generation effectiveness, and identify opportunities for process improvements. Mistral launches first voice model Voxtral is an open weight model for speech understanding, that Mistral says offers “state-of-the-art accuracy and native semantic understanding in the open, at less than half the price of comparable APIs. This makes high-quality speech intelligence accessible and controllable at scale.” It comes in two model sizes: a 24B version for production-scale applications and a 3B version for local deployments. Both sizes are available under the Apache 2.0 license and can be accessed via Mistral’s API. JFrog releases MCP server The MCP server will allow users to create and view projects and repositories, get detailed vulnerability information from JFrog, and review the components in use at an organization. “The JFrog Platform delivers DevOps, Security, MLOps, and IoT services across your software supply chain. Our new MCP Server enhances its accessibility, making it even easier to integrate into your workflows and the daily work of developers,” JFrog wrote in a blog post. JetBrains announces updates to its coding agent Junie Junie is now fully integrated into GitHub, enabling asynchronous development with features such as the ability to delegate multiple tasks simultaneously, the ability to make quick fixes without opening the IDE, team collaboration directly in GitHub, and seamless switching between the IDE and GitHub. Junie on GitHub is currently in an early access program and only supports JVM and PHP. JetBrains also added support for MCP to enable Junie to connect to external sources. Other new features include 30% faster task completion speed and support for remote development on macOS and Linux. Gemini API gets first embedding model These types of models generate embeddings for words, phrases, sentences, and code, to provide context-aware results that are more accurate than keyword-based approaches. “They efficiently retrieve relevant information from knowledge bases, represented by embeddings, which are then passed as additional context in the input prompt to language models, guiding it to generate more informed and accurate responses,” the Gemini docs say. The embedding model in the Gemini API supports over 100 languages and a 2048 input token length. It will be offered via both free and paid tiers to enable developers to experiment with it for free and then scale up as needed. Kong AI Gateway 3.11 introduces new method for reducing token costs Kong has introduced the latest update to Kong AI Gateway, a solution for securing, governing, and controlling LLM consumption from popular third-party providers. Kong AI Gateway 3.11 introduces a new plugin that reduces token costs, several new generative AI capabilities, and support for AWS Bedrock Guardrails. The new prompt compression plugin that removes padding and redundant words or phrases. This approach preserves 80% of the intended semantic meaning of the prompt, but the removal of unnecessary words can lead to up to a 5x reduction in cost. OutSystems launches Agent Workbench Agent Workbench, now in early access, allows companies to create agents that have enterprise-grade security and controls. Agents can integrate with custom AI models or third-party ones like Azure OpenAI or AWS Bedrock. It contains a unified data fabric for connecting to enterprise data sources, including existing OutSystems 11 data and actions, relational databases, data lakes, and knowledge retrieval systems like Azure AI Search. It comes with built in monitoring features, error tracing, and guardrails, providing insights into how AI agents are behaving throughout their lifecycle. Perforce launches Perfecto AI Perfecto AI is a testing model within Perfecto’s mobile testing platform that can generate tests, and adapts in real-time to UI changes, failures, and changing user flows. According to Perforce, Perfecto AI’s early testing has shown 50-70% efficiency gains in test creation, stabilization, and triage. “With this release, you can create a test before any code is written—true Test-Driven Development (TDD)—contextual validation of dynamic content like charts and images, and triage failures in real time—without the legacy baggage of scripts and frameworks,” said Stephen Feloney, VP of product management at Perforce. “Unlike AI copilots that simply generate scripts tied to fragile frameworks, Perforce Intelligence eliminates scripts entirely and executes complete tests with zero upkeep—eliminating rework, review, and risk.” Amazon launches spec-driven AI IDE, Kiro Amazon is releasing a new AI IDE to rival platforms like Cursor or Windsurf. Kiro is an agentic editor that utilizes spec-driven development to combine “the flow of vibe coding” with “the clarity of specs.” According to Amazon, developers use specs for planning and clarity, and they can benefit agents in the same way. Specs in Kiro are artifacts that can be used whenever a feature needs to be thought through in-depth, to refactor work that requires upfront planning, or in situations when a developer wants to understand the behavior of a system. Kiro also features hooks, which the company describes as event-driven automations that trigger an agent to execute a task in the background. According to Amazon, Kiro hooks are sort of like an experienced developer catching the things you’ve missed or completing boilerplate tasks as you work. Akka introduces platform for distributed agentic AI Akka, a company that provides solutions for building distributed applications, is introducing a new platform for scaling AI agents across distributed systems. Akka Agentic Platform consists of four integrated offerings: Akka Orchestration, Akka Agents, Akka Memory, and Akka Streaming. Akka Orchestration allows developers to guide, moderate, and control multi-agent systems. It offers fault-tolerant execution, enabling agents to reliably complete their tasks even if there are crashes, delays, or infrastructure failures. The second offering, Akka Agents, enables a design model and runtime for agentic systems, allowing creators to define how the agents gather context, reason, and act, while Akka handles everything else needed for them to run. Akka Memory is durable, in-memory, sharded data that can be used to provide agents context, retain history, and personalize behavior. Data stays within an organization’s infrastructure, and is replicated, shared, and rebalanced across Akka clusters. Finally, Akka Streaming offers continuous stream processing, aggregation, and augmentation of live data, metrics, audio, and video. Streams can be ingested from any source and they can stream between agents, Akka services, and external systems. Streamed inputs can trigger actions, update memory, or feed other Akka agents. Clarifai announces MCP server hosting, OpenAI compatibility Users will be able to upload and host their own tools, functions, and APIs as an MCP server that is fully hosted and managed by Clarifai. The company is also introducing OpenAI-compatible APIs, which will allow users to integrate with more than 100 open-source and third-party models. “Our MCP server hosting unleashes a new level of agent intelligence, allowing them to directly interact with an organization’s unique operational DNA and proprietary data sources. Paired with our OpenAI-compatible APIs, we’re not just accelerating deployment; we’re breaking down barriers, enabling developers to integrate these highly capable agents into their existing infrastructure almost instantly, driving rapid, impactful innovation,” said Artjom Shestajev, senior product manager at Clarifai. Gemini API gets Batch Mode Batch Mode allows large jobs to be submitted through the Gemini API. Results are returned within 24 hours, and the delayed processing offers benefits like a 50% reduction in cost and higher rate limits. “Batch Mode is the perfect tool for any task where you have your data ready upfront and don’t need an immediate response,” Google wrote in a blog post. AWS announces new features in SageMaker AI SageMaker HyperPod—which allows scaling of genAI model development across thousands of accelerators—was updated with a new CLI and SDK. It also received a new observability dashboard that shows performance metrics, resource utilization, and cluster health, as well as the ability to deploy open-weight models from Amazon SageMaker JumpStart on SageMaker HyperPod. New remote connections were also added to SageMaker AI to allow it to be connected to from a local VS Code instance. Finally, SageMaker AI now has access to fully managed MLFlow 3.0, which provides a straightforward experience for tracking experiments, monitoring training progress, and gaining deeper insights into model behavior. Anthropic proposes transparency framework for frontier AI development Anthropic is calling for the creation of an AI transparency framework that can be applied to large AI developers to ensure accountability and safety. “As models advance, we have an unprecedented opportunity to accelerate scientific discovery, healthcare, and economic growth. Without safe and responsible development, a single catastrophic failure could halt progress for decades. Our proposed transparency framework offers a practical first step: public visibility into safety practices while preserving private sector agility to deliver AI’s transformative potential,” Anthropic wrote in a post. As such, it is proposing its framework in the hope that it could be applied at the federal, state, or international level. The initial version of the framework includes six core tenets to be followed, including restricting the framework to large AI developers only, requirements for system cards and documentation, and the flexibility to evolve as AI evolves. Docker Compose gets new features for building and running agents Docker has updated Compose with new features that will make it easier for developers to build, ship, and run AI agents. Developers can define open models, agents, and MCP-compatible tools in a compose.yaml file and then spin up an agentic stack with a single command: docker compose up. Compose integrates with several agentic frameworks, including LangGraph, Embabel, Vercel AI SDK, Spring AI, CrewAI, Google’s ADK, and Agno. Coder reimagines development environments to make them more ideal for AI agents Coder is announcing the launch of its AI cloud development environments (CDEs), bringing together IDEs, dynamic policy governance, and agent orchestration into a single platform. According to Coder, current development infrastructure was built for humans, not agents, and agents have different requirements to be successful. “Agents need secure environments, granular permissions, fast boot times, and full toolchain access — all while maintaining governance and compliance,” the company wrote in an announcement. Coder’s new CDE attempts to solve this problem by introducing features designed for both humans and agents. Some capabilities include fully isolated environments where AI agents and developers work alongside each other, a dual-firewall model to scope agent access, and an interface for running and managing AI agents. DigitalOcean unifies AI offerings under GradientAI GradientAI is an umbrella for all of the company’s AI offerings, and it is split into three categories: Infrastructure, Platform, and Application. GradientAI Infrastructure features building blocks such as GPU Droplets, Bare Metal GPUs, vector databases, and optimized software for improving model performance; GradientAI Platform includes capabilities for building and monitoring agents, such as model integration, function calling, RAG, external data, and built-in evaluation tools; and GradientAI Applications includes prebuilt agents. “If you’re already building with our AI tools, there’s nothing you need to change. All of your existing projects and APIs will continue to work as expected. What’s changing is how we bring it all together, with clearer organization, unified documentation, and a product experience that reflects the full potential of our AI platform,” DigitalOcean wrote in a blog post. Newest LF Decentralized Trust Lab HOPrS identifies if photos have been altered OpenOrigins has announced that its Human-Oriented Proof System (HOPrS) has been accepted by the Linux Foundation’s Decentralized Trust as a new Lab. HOPrS is an open-source framework that can be used to figure out if an image has been altered. It utilizes techniques like perceptual hashes and quadtree segmentation, combined with blockchain technology, to determine how images have been changed. According to OpenOrigins, HOPrS can be used to identify if content is generated by AI, a capability becoming increasingly more important as it becomes more difficult to distinguish between AI-generated and human-generated content. “The addition of HOPrS to the LF Decentralized Trust labs enables our community to access and collaborate on crucial tools for verifying content in the age of generative AI,” said Daniela Barbosa, executive director of LF Decentralized Trust. Denodo announces DeepQuery DeepQuery leverages governed enterprise data across multiple systems, departments, and formats to provide answers that are rooted in real-time information. It is currently available as a private preview. The company also announced its support for MCP, and the latest version of Denodo AI SDK includes an MCP Server implementation. Cloudflare now blocks AI crawlers by default, introduces pay per crawl model Last year, Cloudflare introduced a setting that allowed website owners to block AI crawlers. Now, the company is announcing that this setting will now be the default rather than a user needing to switch it on. The company explained that by switching to a permission-based model, it is eliminating the need for content owners to manually configure settings in order to opt out. Additionally, Cloudflare is experimenting with a pay per crawl model (in private beta) for content owners to monetize content that is being used to train AI. When an AI crawler requests content, it will be prompted to pay or will receive an HTTP response code 402 error message. Perplexity launches Max subscription Perplexity Max costs $200/month and includes everything that the $20/month Pro subscription comes with, in addition to an unlimited number of Labs, early access to new features, advanced model options like OpenAI o3-pro and Claude Opus 4, and priority support. “Perplexity Max is our most advanced subscription tier yet, built for those who demand limitless AI productivity and immediate access to the newest products and features from Perplexity. With Perplexity Max, you can reach the maximum power of your curiosity,” the company wrote in a post. Microsoft launches Awesome GitHub Copilot Customizations repo This is a repository that includes custom instructions, reusable prompts, and custom chat modes created by the community. Already, the repo includes custom instructions for Angular best practices, .NET MAUI components and application patterns, Python coding conventions, and more. Some examples of reusable prompts include transforming Python scripts into beginner-friendly projects, creating GitHub Issues for feature requests, and analyzing Azure resources an app is using. And finally, some of the chat modes include a debug mode, planning mode, and database admin mode. The repo is constantly being updated with new additions from the community, so Microsoft is encouraging further contributions. Gartner: More than 40% of agentic AI projects will be canceled in the next few years Gartner recently revealed a new report where it predicted that by the end of 2027, over 40% of agentic AI projects will be canceled. Factors contributing to this decline include escalating costs, unclear business value, and inadequate risk controls. According to the analyst firm, one trend it is seeing is that vendors are hyping up AI agents by “agent washing,” or rebranding existing products like AI assistants, RPA, or chatbots without actually adding substantial agentic capabilities. The company estimates that of the thousands of agentic AI vendors out there, only about 130 of them are real and delivering on their promises. BrowserStack launches suite of AI agents BrowserStack AI agents are integrated throughout the testing life cycle, helping teams accelerate release cycles, improve test coverage, and boost productivity. The initial release includes five agents: Test Case Generator Agent, Low-Code Authoring Agent, Self-Healing Agent, A11y Issue Detection Agent, and Visual Review Agent. There are over 20 other agents in development as well. “We mapped the testing journey to identify where teams spend the most time and manual effort, and reimagined it with AI at the core,” said Ritesh Arora, CEO and co-founder of BrowserStack. “Early results are game-changing, our Test Case Generator delivers 90% faster test creation with 91% accuracy and 92% coverage, results that generic LLMs can’t match.” Microsoft creates small language model for changing Windows settings Mu powers Microsoft’s Settings agent by mapping natural language inputs to Settings function calls. It runs directly on the devices using the Neural Processing Unit (NPU) on Copilot+ PCs, and was designed with NPU constraints in mind, such as parallelism and memory limits. The agent that Mu powers is available currently to Windows Insiders in the Dev Channel using Copilot+ PCs. Mirantis reveals Lens Prism, an AI copilot for operating Kubernetes clusters With Lens Prism, developers will be able to use natural language to troubleshoot and operate their Kubernetes clusters. Developers can ask questions like “What’s wrong with my pod?”, “How much CPU is this namespace using?” or “Is anything failing in my cluster?” Lens Prism will then respond with insights gathered from kubectl output, metrics, logs, and the current view in Lens Desktop, and will generate commands that are ready to be run. Amazon creates new generative AI model for its robots DeepFleet was designed to act as an intelligent traffic management system for Amazon’s fleet of robots. According to the company, the model coordinates all of the robots’ movements and optimizes how they navigate through fulfillment centers. The model was able to improve the travel time of Amazon’s robotic fleet by 10%, translating to faster delivery times and lower costs for customers. The post July 2025: All AI updates from the past month appeared first on SD Times.

Like many large enterprises, we must navigate the beauty and chaos of legacy code. In our case, decades of SQL procedures and business logic that underpin a platform capable of handling over 3 million concurrent users and hundreds of micro code deployments per week. It’s a complex machine. Touch one part, and you risk breaking … continue reading

The post Understanding the code modernization conundrum appeared first on SD Times.

Like many large enterprises, we must navigate the beauty and chaos of legacy code. In our case, decades of SQL procedures and business logic that underpin a platform capable of handling over 3 million concurrent users and hundreds of micro code deployments per week. It’s a complex machine. Touch one part, and you risk breaking 10 others. That’s why modernizing the codebase is both a technical challenge and a human one. It requires empathy, trust, and the ability to make informed guesses. Inside the Innovation Engine At bet365, the platform innovation function was established to provoke possibility. We’re a small, specialized team charged with exploring emerging and future technologies. Our aim is to identify where they can have the greatest impact, and help the wider organization understand how to use them meaningfully. We’re enablers and ambassadors for change. Our work spans everything from product development and cybersecurity to the future of the workforce. Our guiding model is McKinsey’s Three Horizons of Growth reimagined for innovation. Horizon 1 focuses on what we can implement today. Horizon 2 explores what’s coming next. Horizon 3 dares us to consider the future no one is talking about yet. This framework helps us balance ambition with pragmatism. It creates space to experiment without losing sight of operational value, and it ensures our developers, architects, and stakeholders are all part of the same conversation. When GenAI Met Developers When GPT-4 dropped in 2023, everything changed. Like most in the tech world, we were fascinated. Generative AI offered a tantalizing vision of the future filled with faster insights, instant summaries, and automated refactoring. But the excitement quickly gave way to doubt. We handed very capable developers a powerful LLM and said, “Go for it.” The results were mixed at best. They inserted code into the prompt windows, stripped out context to save space, and hoped the AI would understand. It didn’t. Developers were confused, frustrated, and, understandably, skeptical. They saw the AI as a shortcut, not a partner, and when the output didn’t match expectations, frustration followed. Many asked the same question: “Why am I asking a machine to write code I could just write myself?” What we learned was profound. The problem wasn’t the AI. It was the relationship between the AI and the person using it. We had assumed that skill in software engineering would automatically translate to skill in prompt engineering. It didn’t. Did we miss something? The point we couldn’t overlook was during the exercise, our developers were completing the tasks consistently around 80% of estimated time. There was definitely something here. We just weren’t sure what it was. So, we went back to basics. Vibe Coding and the Limits of Trust There’s a new term in developer culture: “vibe coding.” It’s where you throw a chunk of code at an LLM, get a response, tweak it, throw it back. Iterate fast. Ship faster. It’s trendy. It’s seductive. But it isn’t risk free. Without a clear understanding of intention or context, vibe coding can quickly become a game of trial and error. And when your system is as complex as ours – many databases processing 500,000 transactions a second – “trial and error” isn’t good enough. We needed more than vibes. We needed vision. Context Over Content The turning point came when we realized the real job wasn’t teaching AI how to write better code. It was teaching humans how to communicate with AI. We learned a new mantra: intention + context + detail. That’s what the AI needs. Not just content. Not just “fix this function.” But: “Here’s what this code does, here’s why it matters, and here’s what I need it to become.” This insight is key. Our developers, especially those tackling the most complex, interdependent problems, adapted quickly. They were used to thinking deeply, providing rationale, and navigating ambiguity. They got it. They fed the AI what it needed. They flourished. The difference was mindset. We came to call this phenomenon “the unreliable narrator.” Not just the AI, but the developer. Because often, the problem wasn’t that the machine got it wrong. It was at times that we weren’t clear on what we were asking. RAG, GraphRAG, and the Power of Grounded Context To build reliable, human-aligned AI support we needed a way to ground what the AI was seeing in fact. That’s where we saw the power of Retrieval-Augmented Generation (RAG). RAG allows an AI model to retrieve relevant context from an external source – like documentation, system metadata, or a knowledge base – before generating a response. It’s faster to implement and more flexible than fine-tuning, making it ideal for dynamic, domain-intensive environments like ours. Developers can update the knowledge base without retraining the model, keeping outputs current and grounded. But RAG has its limits. When a question spans multiple systems or requires reasoning across disconnected pieces of information, traditional RAG, which is based on text similarity, starts to falter. That’s why we turned to GraphRAG, a more advanced approach that uses a knowledge graph to enhance LLM outputs. A knowledge graph doesn’t just hold facts, it encodes relationships. It captures how components interact, where dependencies lie, and what could break if you change something. GraphRAG uses this structure to augment prompts at query time, giving the AI the relational context it needs to answer with precision. This is especially true in environments where accuracy is critical, and hallucinations are unacceptable. As a real-world exercise, we looked at our SQL server estate. We wanted to build a system that we could use to gain valuable insight on how the system works. To build it, we started by parsing all our database objects including tables, views, procedures, functions, etc. into abstract syntax trees (ASTs). Using Microsoft’s ScriptDOM, we extracted key facts and used them to construct the initial knowledge graph. We overlaid this with natural language descriptions to further explain what each element did, and added runtime statistics like execution frequency, CPU time, and read volumes. The result was a rich, relational representation of our SQL estate, complete with contextual insights about how objects are consumed and how they interact. Then we surfaced this intelligence to developers through three core tools: A chatbot that lets users query the system in plain language A visualiser that renders a 3D map of dependencies and relationships A Cypher executor for advanced graph querying and analysis What’s important to note is that most of the system’s value lies in the graph, not the model. The AI doesn’t need to know everything. It just needs to know where to look, and how to ask the right questions. That’s the power of grounding. For us, GraphRAG wasn’t just a nice-to-have, it became essential. It helped us move from generic code assistance to something far more valuable: a system that understands what our code means, how it behaves, and what it impacts. We’re not just writing code anymore. We’re curating it. We’re shaping the intentions behind it. Our developers now have tooling to gain further insight to become code reviewers, system designers, and transformation agents at an expert level across huge department spanning architectures. All from a simple interface allowing natural language inquiries That’s the real shift. The future isn’t about AI doing our jobs. It’s about reimagining what the job is. The success of our code modernization program has little to do with algorithms and everything to do with attitude. We had to unlearn old habits, rethink our relationship with code, and embrace a culture of curiosity. We had to stop asking AI for answers and start giving it the right questions. The technology was the easy part. The people part, now that was the real breakthrough. The post Understanding the code modernization conundrum appeared first on SD Times.

While AI is becoming better at generating that functional code, it is also enabling attackers to identify and exploit vulnerabilities in that code more quickly and effectively. This is making it easier for less-skilled programmers to attack the code, increasing the speed and sophistication of those attacks — creating a situation in which code vulnerabilities … continue reading

The post AI-generated code poses major security risks in nearly half of all development tasks, Veracode research reveals    appeared first on SD Times.

While AI is becoming better at generating that functional code, it is also enabling attackers to identify and exploit vulnerabilities in that code more quickly and effectively. This is making it easier for less-skilled programmers to attack the code, increasing the speed and sophistication of those attacks — creating a situation in which code vulnerabilities are increasing even as the ability to exploit them is becoming easier, according to new research from application risk management software provider Veracode. AI-generated code introduced security vulnerabilities in 45% of 80 curated coding tasks across more than 100 LLMs, according to the 2025 GenAI Code Security Report. The research also found that GenAI models chose an insecure method to write code over a secure method 45% of the time. So, even though AI can create code that is functional and syntaactically correct, the report reveals that security performance has not kept pace. “The rise of vibe coding, where developers rely on AI to generate code, typically without explicitly defining security requirements, represents a fundamental shift in how software is built,” Jens Wessling, chief technology officer at Veracode, said in a statement announcing the report. “The main concern with this trend is that they do not need to specify security constraints to get the code they want, effectively leaving secure coding decisions to LLMs. Our research reveals GenAI models make the wrong choices nearly half the time, and it’s not improving.” In announcing the report, Veracode wrote: “To evaluate the security properties of LLM-generated code, Veracode designed a set of 80 code completion tasks with known potential for security vulnerabilities according to the MITRE Common Weakness Enumeration (CWE) system, a standard classification of software weaknesses that can turn into vulnerabilities. The tasks prompted more than 100 LLMs to auto-complete a block of code in a secure or insecure manner, which the research team then analyzed using Veracode Static Analysis. In 45 percent of all test cases, LLMs introduced vulnerabilities classified within the OWASP (Open Web Application Security Project) Top 10—the most critical web application security risks.” Other findings in the report were that Java was found to be the riskiest of programming languages for AI code generation, with a security failure rate of more than 70%. Failure rates of between 38% and 45% were found in apps creating in Python, C# and JavaScript. The research also revealed LLMs failed to secure code against cross-site scripting and log injection in 86% and 88%, respectively, according to Veracode. Wessling noted that the research showed that larger models perform no better than smaller models, which he said indicates that the vulnerability issue is a systemic one, rather than an LLM scaling problem. “AI coding assistants and agentic workflows represent the future of software development, and they will continue to evolve at a rapid pace,” Wessling concluded. “The challenge facing every organization is ensuring security evolves alongside these new capabilities. Security cannot be an afterthought if we want to prevent the accumulation of massive security debt.” The post AI-generated code poses major security risks in nearly half of all development tasks, Veracode research reveals appeared first on SD Times.

More and more developers are adopting AI, but the trust they have in its outputs is getting worse and worse over the years. This is according to Stack Overflow’s 2025 Developer Survey, which gathered responses from 49,000 developers across 177 countries. This year, 84% of respondents say they are using or plan to use AI … continue reading

The post Stack Overflow: Developers’ trust in AI outputs is worsening year over year appeared first on SD Times.

More and more developers are adopting AI, but the trust they have in its outputs is getting worse and worse over the years. This is according to Stack Overflow’s 2025 Developer Survey, which gathered responses from 49,000 developers across 177 countries. This year, 84% of respondents say they are using or plan to use AI tools for development (up from 76% last year), but 46% say they don’t trust the output of those AI tools (up from 31% last year). More specifically, 75.3% said they don’t trust AI-generated answers, 61.7% had ethical or security concerns about AI-generated code, and 61.3% said they want to be able to fully understand their code. “The growing lack of trust in AI tools stood out to us as the key data point in this year’s survey, especially given the increased pace of growth and adoption of these AI tools. AI is a powerful tool, but it has significant risks of misinformation or can lack complexity or relevance,” said Prashanth Chandrasekar, CEO of Stack Overflow. The survey found that for 45% of respondents, debugging AI-generation code is time consuming, which is one of the key frustrations with dealing with AI-generated code. Stack Overflow also found that only 31% of respondents are currently using AI agents, and of those, 69% said they have seen an increase in productivity. Seventeen percent are planning to use them in the future, while 38% don’t plan to ever use them. Additionally, 64% of developers don’t perceive AI as a threat to their jobs, a slight decrease from last year (68%). The report also found that 69% of developers have spent time learning new coding techniques or languages in the past year, and 44% used AI tools for learning (up from 37%) last year. Finally, while developers are using AI to assist with their work, a majority (77%) aren’t partaking in vibe coding for their professional work. Other interesting findings from the survey are: 24% of developers are happy at their current job—a slight increase from last year’s 20%, likely related to pay raises 32% of developers work remotely and 45% of US developers work remotely GitHub surpassed Jira as the most desirable collaboration tool For more insights, the full survey findings are available here. The post Stack Overflow: Developers’ trust in AI outputs is worsening year over year appeared first on SD Times.

The personal website of the one and only Joe Fabisevich, and indie developer building Red Panda Club Inc. Formerly an iOS developer working on civic integrity, societal health, misinformation, and other wild things @Twitter.

I. I once knew a wonderful man. He was kind, gentle, and beloved by many. He was so wise that when he graduated from college, Mahatma Gandhi himself handed him his diploma. He was a scholar and a gentleman, blessed with the unique gift of deeply knowing Sanskrit and Hindi. He spent much of his life translating scrolls filled with the wisdom of the ancients into modern language — in pursuit of preserving history.

II. When Mongol troops raided the House of Wisdom and dumped so many manuscripts into the Tigris that “the river ran black with ink”, Muslim chroniclers equated the loss of knowledge to a civilizational catastrophe. Many of the books in the Grand Library of Baghdad were torn apart by pillagers so their leather covers could be made into sandals — compounding the pain of an already destructive act.

III. In 1969, three astronauts planted an American flag on the moon. This event was captured on film and beamed to millions of household television sets, as people across the world shared the experience of witnessing a profound leap for mankind. Our connection to the cosmos had been reshaped — and we still talk about it decades later.

IV. Early internet phenomenons like Charlie the Unicorn, Potter Puppet Pals, and Peanut Butter Jelly Time provided endless entertainment. My older brother introduced me to All Your Base Are Belong to Us, and I showed him lolcats. A few months later, I met a kid I considered sheltered because he’d never heard of Newgrounds — so I showed him everything it had to offer, and we relived the humor together. That rhythm of discovery and sharing lasted for years, as the internet grew at a pace that felt almost unthinkable compared to my early childhood.

I. I once knew a wonderful man. He was kind, gentle, and beloved by many. He was so wise that when he graduated from college, Mahatma Gandhi himself handed him his diploma. He was a scholar and a gentleman, blessed with the unique gift of deeply knowing Sanskrit and Hindi. He spent much of his life translating scrolls filled with the wisdom of the ancients into modern language — in pursuit of preserving history. II. When Mongol troops raided the House of Wisdom and dumped so many manuscripts into the Tigris that “the river ran black with ink”, Muslim chroniclers equated the loss of knowledge to a civilizational catastrophe. Many of the books in the Grand Library of Baghdad were torn apart by pillagers so their leather covers could be made into sandals — compounding the pain of an already destructive act. III. In 1969, three astronauts planted an American flag on the moon. This event was captured on film and beamed to millions of household television sets, as people across the world shared the experience of witnessing a profound leap for mankind. Our connection to the cosmos had been reshaped — and we still talk about it decades later. IV. Early internet phenomenons like Charlie the Unicorn, Potter Puppet Pals, and Peanut Butter Jelly Time provided endless entertainment. My older brother introduced me to All Your Base Are Belong to Us, and I showed him lolcats. A few months later, I met a kid I considered sheltered because he’d never heard of Newgrounds — so I showed him everything it had to offer, and we relived the humor together. That rhythm of discovery and sharing lasted for years, as the internet grew at a pace that felt almost unthinkable compared to my early childhood. V. Millennials remember The Dress as a seminal cultural moment that captivated people for days, but what most don’t remember are the two llamas that escaped a zoo earlier that day and caused a commotion along the way. To my recollection, this was the first viral moment that was overtaken by another so quickly that it might as well not have even happened. VI. Last week I watched a very funny TikTok. It was a meme that dominated everyone's feeds for about eight hours — but then we collectively forgot it ever existed and moved on to the next funny video. As people willfully turn themselves into content creators, information disseminates faster than ever. The half-life of any artifact grows shorter, and the societal impact of any captured moment becomes increasingly fleeting. The purpose of writing, art, and creation has always been human connection — but as the goal shifts to pleasing an opaque algorithm, the creations themselves have become less meaningful. I expect this trend will only accelerate as more of our economy becomes tied to clicks and views, and as the act of creation grows more frictionless with the proliferation of AI. Artifacts are our distillations of history — they encapsulate and preserve the human experience. Our world is built on the artifacts of those who came before us — people who cared enough to share, document, and build something that outlasted themselves. It is a spiritual experience to create something new in this world — to turn a figment of our imagination into a shareable element of the universe. I do my best to fill my days with artifact creation — shunning the incentive structures the modern world creates when I can — to tap into the essence of what drives me to create artifacts that will outlive me. I don’t spend all my time creating my own artifacts; there is often more to be gained by sharing myself, so others can create their own artifacts that bring meaning to them and others. In a way, that transfer of knowledge is itself a transient artifact — just like a years-long running joke between me and my wife, a kiss we share, or a wedding vow we made, is an artifact of our love. Almost everything I consciously do is related to creating or preserving artifacts — but the artifact is only a small part of who I am. It’s no coincidence that I’ve aligned the time I spend on earth with the way I make a living with my values. Anything meaningful is worth doing, and worth preserving. What people see is the result of hundreds or thousands of hours of work that went into creating the artifact — and the hundreds of thousands of hours I’ve lived that led to it. But an artifact can never truly capture my full experience. It is a synthesized approximation. At best, it’s a low-fidelity version of my lived reality — not the life itself, but the echo. And yet, when thoughtfully preserved, the artifact will outlive me.

Colleen and I were binge-watching Gossip Girl last winter, and there are a few scenes where a stressed and irate Blair Waldorf wanders over to Central Park to feed the ducks. I told Colleen, "that sounds soothing — we should do that when the weather gets better". And then, as I’m wont to do, I promptly forgot. But Colleen takes note of moments like that, and a few months later she reminded me: we should actually go feed some ducks.

That’s how I found myself in Central Park last weekend, feeding ducks. It was the first beautiful day of spring in New York — the kind of day New Yorkers wait for, when everyone pours out to enjoy sunlight finally breaking through after a long dark winter. We had a picnic, strolled through the park, wandered amidst thousands of New Yorkers — and of course, we fed the ducks.

My wife (who I should preface is an extremely kind, caring, and loving person) and I got into a small debate over what kind of bread to feed the ducks. I insisted on buying them a nice loaf, and she felt it was unnecessary — the ducks would happily take our scraps. I argued that buying a good loaf cost us very little but could potentially make their day. Heck, it could even possibly be the best meal they ever have. She replied that there’s no way to know if they’d even notice the difference — to them, it might just be one carb versus another.

Three Philosphers Interject

I bought the dang bread, and she didn’t mind. I spent the whole afternoon thinking about that moment, and why it meant so much to me. In the end, I came back to three philosophers and their philosophies.

Colleen and I were binge-watching Gossip Girl last winter, and there are a few scenes where a stressed and irate Blair Waldorf wanders over to Central Park to feed the ducks. I told Colleen, "that sounds soothing — we should do that when the weather gets better". And then, as I’m wont to do, I promptly forgot. But Colleen takes note of moments like that, and a few months later she reminded me: we should actually go feed some ducks. That’s how I found myself in Central Park last weekend, feeding ducks. It was the first beautiful day of spring in New York — the kind of day New Yorkers wait for, when everyone pours out to enjoy sunlight finally breaking through after a long dark winter. We had a picnic, strolled through the park, wandered amidst thousands of New Yorkers — and of course, we fed the ducks. My wife (who I should preface is an extremely kind, caring, and loving person) and I got into a small debate over what kind of bread to feed the ducks. I insisted on buying them a nice loaf, and she felt it was unnecessary — the ducks would happily take our scraps. I argued that buying a good loaf cost us very little but could potentially make their day. Heck, it could even possibly be the best meal they ever have. She replied that there’s no way to know if they’d even notice the difference — to them, it might just be one carb versus another. Three Philosphers Interject I bought the dang bread, and she didn’t mind. I spent the whole afternoon thinking about that moment, and why it meant so much to me. In the end, I came back to three philosophers and their philosophies. John Rawls John Rawls’ Veil of Ignorance is a thought experiment about how to design a just society. Imagine yourself behind a veil of ignorance, where you don’t know your place in that society. You don’t know your race, gender, class, talents, or job — and because you could end up a CEO or a janitor, you’d rationally choose to build a society rooted in fairness and decency for all. Now imagine you’re born into a world where you could be a human or a duck. Humans shape the world to their whims, while ducks hunt for scraps and take handouts from strangers. What if you were the duck — not the one giving bread, but the one hoping someone kind might offer you a piece? That’s the essence of contractualism. This is not a truly just world — but it is our world. Blaise Pascal Pascal’s Wager is a similar framework — but more inward-looking. Blaise Pascal argued that the only rational thing to do is believe in God. Why? If you believe in God and you’re right, you gain infinite reward: a spot in heaven for the rest of eternity. If you believe in God and you’re wrong, you lose a little: some wasted time and lifestyle shifts. If you don’t believe in God and you’re wrong, you risk infinite loss: eternal fiery damnation. If you don’t believe in God and you’re right, you only gain a little: temporary freedom and earthly pleasures. I think about Pascal’s Wager a lot — not just when I’m wondering about my everlasting fate. Feeding ducks good bread isn’t exactly a God-tier question, but I do often ask: what are the consequences of my choices if I’m right or wrong about my assumptions? It’s often worth putting in the extra effort — because maybe I’m wrong, and there’s more to this mortal plane than I know. Immanuel Kant And then we have Deontology — or more specifically, Kantian Ethics. Kant believed that morality isn’t about outcomes or self-interest — it’s about duty, reason, and universal principles. His Categorical Imperative says: Act only according to that maxim whereby you can at the same time will that it should become a universal law. That's a philosophical way of saying Kant believed in the Golden Rule. If I were a duck, I’d want the good bread just like any person does. And so, as a human, I have a responsibility to feed ducks the good bread. Back to Central Park Reader, I did not feed the ducks the good bread. Not because I’m morally bankrupt — we simply did not find enough ducks to feed the giant loaf of bread I’d stressed about all day. The few we did find got some decent sandwich bread leftover from our picnic. When I got home, I left out the remainder of our picnic for the neighborhood birds — some fruit that they seemed to appreciate. The next day, we used the good bread to make delicious sandwiches and played lovingly with our little cat. Not feeding the ducks wasn’t a moral failing — it was just a coincidence. Sometimes, you need to find more ducks in your life so you can feed them the good bread. Spend some time looking for a duck to feed — you might be surprised how much it fills you up, too. Look — no one really knows how any of this works. Not Kant, not Pascal, not Rawls. But I feel pretty strongly that small acts go a long way. So when you get the chance, you should feed ducks the good bread. Metaphorically speaking, of course. It turns out that bread isn’t great for ducks, and ethics are complicated — but kindness is always warranted.

This blog post is documentation for a very specific problem I run into about once a year. That’s rare enough to forget how I solved it, but frequent enough to waste 15 minutes rediscovering the answer. And let’s be honest: it’s not the big problems that drive you mad — it’s the little ones that feel like their own Sisyphean hell.

The Problem

Some websites ¹ require you to log in using a magic link — a one-time link emailed to you that signs you in when clicked. It’s usually seamless. But on iOS, it can quietly become a headache. ²

This blog post is documentation for a very specific problem I run into about once a year. That’s rare enough to forget how I solved it, but frequent enough to waste 15 minutes rediscovering the answer. And let’s be honest: it’s not the big problems that drive you mad — it’s the little ones that feel like their own Sisyphean hell. The Problem Some websites 1 require you to log in using a magic link — a one-time link emailed to you that signs you in when clicked. It’s usually seamless. But on iOS, it can quietly become a headache. 2 If you open the link in your default browser, everything’s fine — no issue at all. But I do most of my reading in my RSS app, Reeder. When I run into a short-form RSS feed 3, I’ll tap to open the article in SafariViewController — the in-app browser you see in apps like Reeder, or my own app, Plinky. It’s an easy way to read the full article in a browser without leaving the app you’re already in. The Problem (Simplified) I open a link to paywalled content, like the excellent tech newsletter I subscribe to: platformer.news. Platformer’s hosting provider, Ghost, emails me a magic link to log in and access the content I pay for. But there’s no way to open that sign-in link inside Reeder’s SafariViewController. If I click the link, it opens in the iOS default browser — and there’s no way to force it to open in Reeder’s SafariViewController instead. 4 I can’t even copy and paste the link, since SafariViewController has no address bar. The Solution Every time I run into this issue, I end up coming back to the only solution that actually works. My favorite RSS provider, Feedbin, has a clever feature: it lets you generate a unique email address (like xyz123@feedbi.in) that turns incoming emails into an RSS feed. 5 It’s meant for forwarding email newsletters into your RSS reader — a nice way to keep all your reading in one place. But in a pinch, it’s also a great trick for accessing any email inside your feed. I can’t tell Platformer to send the magic link directly to that Feedbin address, because my login is tied to my personal email — but I can forward the email there myself. Since I’m already subscribed to that email-based RSS feed, the message shows up in Reeder. Now I can tap the login link in Reeder, which opens SafariViewController — and just like that, I’m signed in. 🌟 Finally, I can read the paywalled content I actually paid for! 🌟 Conclusion While I hope this post helps someone else out there, let’s be honest — it’s really written for me, 12 months from now, when I’ve forgotten all of this again. 😒 Such as all paid Ghost newsletters↩↩ . You can’t even long-press and copy the link, because that will load the authentication page, invalidating the link’s effectiveness.↩↩ Some websites don’t offer the full content of an article in the RSS feed. This can happen for a few reasons, but the most prominent is because the content lives behind a paywall, and this prevents free access to paid content.↩↩ I did actually add a URL scheme for this in Plinky, because I know firsthand how this can be an issue!↩↩ In case you don’t use Feedbin there are many services which are just as good and handle this specific problem.↩↩

The iPhone 15 Pro launched with a marquee feature, the Action Button. The Action Button set out to replace the mute switch, which had existed since the first iPhone was released back in 2007. The Action Button is a software-powered button, replacing what previously was a hardware switch that would toggle your phone’s silent mode on or off.

The appeal of the Action Button was that now you could decide what the side button should do for you. If you wanted it to be a mute switch, no problem, the Action Button can still be one. But if you want to use it to toggle your flashlight, launch the camera, or turn on Do Not Disturb mode, these alternatives and more are now possible. The unspoken downside has always been that it’s hard to decide what the Action Button should do, if it can only do one thing.

The iPhone 15 Pro launched with a marquee feature, the Action Button. The Action Button set out to replace the mute switch, which had existed since the first iPhone was released back in 2007. The Action Button is a software-powered button, replacing what previously was a hardware switch that would toggle your phone’s silent mode on or off. The appeal of the Action Button was that now you could decide what the side button should do for you. If you wanted it to be a mute switch, no problem, the Action Button can still be one. But if you want to use it to toggle your flashlight, launch the camera, or turn on Do Not Disturb mode, these alternatives and more are now possible. The unspoken downside has always been that it’s hard to decide what the Action Button should do, if it can only do one thing. There are ways to set up the Action Button to show a menu of actions, but that makes the Action Button less convenient. You can use hacks like Federico Viticci's MultiButton, which made it possible to assign separate tap and double-tap actions to your Action Button. These workflows and many others were built off of the Action Button’s ability to run a Shortcut, but none of them ever stuck for me. While you may get a more powerful Action Button, you also get a more complicated one — trading off flexibility for fiddliness. Then after 18 months with the iPhone 15 Pro, I had a breakthrough. This idea came to me in a dream (literally, not metaphorically), and last month I discovered a way to use the Action Button that is useful across apps, without tying myself to one action for the Action Button. Our First App-Specific Action My most common use case for the Action Button has always been to save links from my clipboard to Plinky, the link-saving app I make. You may be thinking, “Plinky has a share extension which lets you save links from any app, so why do you need the Action Button to save links from the clipboard?” Because the app I send and receive links from most, Messages, surprisingly does not have a share button. Before mapping the Action Button to a “Save Link to Plinky” Shortcut, whenever a friend sends a link to me over iMessage I would have to go through multiple steps to save a link. Copy the link into my clipboard, open Plinky, and save the link manually. This was tedious, especially if I wanted to save multiple links, so I decided to take advantage of Plinky’s built-in Shortcuts support to create a one-tap action, letting me save links from anywhere. At the same time, this action is mostly useful to me in Messages — it's not as important when I'm in an app like Safari or Slack. This meant we were back to where we started: there's this really useful action mapped to my Action Button, but I don't need it all the time. That got me thinking, why can't I create one dedicated action per app, which I can use to build a more flexible Action Button? An iOS 18.2 Interlude iOS 18.2 brought a very important change to Shortcuts, one that made the technique I’m about to share possible. There is a new Get Current App Shortcut block, which unsurprisingly, will tell you what app you currently have open. Once I was able to figure out the current app, it became possible to conditionally run actions based on the current app. Action Mode Now that we have all of the necessary pieces, we can build out our custom App-Specific Action Button workflow. (I’ve called mine Action Mode.) Let’s walk through this image step by step, to see what’s happening here. It’s a bit long, but I promise it’s not scary. We set our Shortcut to receive input from the Share Sheet. This allows us to run this Shortcut from an assortment of locations. If there is no input, I’ve chosen to fallback to the Get Clipboard function. We create a bunch of if blocks, one per app. This will allow us to run a different action based on the result of Current App. You’ll notice there are no else blocks, we’ll get to that in a little bit. When Current App is equal to an app we’ve chosen to have a Custom Action, we now run said Custom Action. That Custom Action can be anything, it doesn’t even have to be related to the current app we’re in. (As you see in the example when the Current App is Messages.) You can create as many Custom Actions for as many apps as you’d like, the only limit is your imagination. At the end of the list we have a Fallback Action block. This is an optional action to run if press the Action Button outside of an app with a Custom Action. I’ve mapped it to adding a Reminder to my Groceries list, an action I take often. Note: The way we know to enter the fallback action block is a bit unconventional, and is predicated on the hasRunAction variable. Instead of having infinitely nested else blocks for every Current App check, we populate the hasRunAction variable whenever we run a Custom Action. This is slightly more error prone because we can forget to populate the hasRunAction variable, but leaves our Shortcut significantly more manageable and flexible. Long Live Apps The great thing about this system is that it’s easy to get started, and easy to add new apps to your workflow the more ideas you come up with over time. I started off with a handful of apps, but now it’s grown to over a dozen. A few examples for how I’m using my App-Specific Action Button: Plinky: Open my Reading List App Store: Open the App Updates tab - Via URL scheme: itms-apps://apps.apple.com/updates Castro: Toggle the sleep timer (so I can listen to a podcast while falling asleep) ChatGPT: Start a new ChatGPT Voice conversation Craft: Open my Plinky Roadmap doc Fantastical: Switch to my Personal Calendar Set GitHub: Open the repo of Boutique (my most popular open source project) Ivory & Mona: Generate a screenshot of the Mastodon post in my clipboard Messages: Save the a link from my clipboard to Plinky MyWater: Log 12 ounces of water Photos: Open the Favorites album Safari: Open Reader Mode Slack: Switch to my Red Panda Club Slack - Via URL scheme Things: Open my Today list These are just my workflows, but the possibilities for configuring your Action Button are personal and limitless. If you need a template to start with, here is the Action Button Sample Shortcut I created, identical to the screenshot above. Now all that’s left to do is to assign our Action Mode Shortcut to the Action Button, which we can do in the iOS system Settings. And viola, that’s the App-Specific Action Button system — some would call it a Shortcut — to a better workflow.

The post below was written by me, originally featured on the Plinky blog.

To celebrate the launch of Plinky you can get 50% off of a yearly subscription by redeeming this offer: plinky.app/offer/REDPANDA

There are few words I've ever said more excitedly than these: I want to tell you about my latest app, Plinky.

Plinky makes it incredibly easy to do something we do every day, save links for later. You may already have a way to save links, I know I've tried every method under the sun, to the point where I decided to build my own app. That app is Plinky, and today it's available to download on the App Store. Over the last 18 months people have been loving Plinky, because it fixes the same problems I ran into when I've tried to save links in the past.

The post below was written by me, originally featured on the Plinky blog. To celebrate the launch of Plinky you can get 50% off of a yearly subscription by redeeming this offer: plinky.app/offer/REDPANDA There are few words I've ever said more excitedly than these: I want to tell you about my latest app, Plinky. Plinky makes it incredibly easy to do something we do every day, save links for later. You may already have a way to save links, I know I've tried every method under the sun, to the point where I decided to build my own app. That app is Plinky, and today it's available to download on the App Store. Over the last 18 months people have been loving Plinky, because it fixes the same problems I ran into when I've tried to save links in the past. I tried filling up Apple Notes with links to come back to later, but that proved to be a disorganized mess. I tried leaving browser tabs open with links I wanted to look at later, but the links I needed later got lost amongst the dozens of tabs I had open for right now. I even tried spending hundreds of hours using apps dedicated for reading articles later, but not all links are for reading. All of that led me to build Plinky, a home for your links. Why I Built An App To Save Your Links I love links. I love reading links, I love it when people send me links to funny videos, I love collecting links, and I love sharing links. Something else I love is my fiancée Colleen. Shortly after meeting Colleen discovered how much I love links, and I'm very grateful that she found that to be an endearing trait. While she loved that I was thinking of her and sharing interesting articles, recipes to cook together, or cute animals I knew she'd like, she quickly found it distracting to have her phone buzzing with all the links I'd share while she was working. She suggested saving the links for later, so we could look at them together at night. That’s when I started working on a small project, a home for these links, an app that would become Plinky. I started to show people the app I'd made for the two of us, and they loved it. They were all saving links they needed but were unhappy with one thing or another. They kept telling me that they wanted an app like this for themselves. A few months later when I left my job at Twitter to start my own company building personal, playful, productivity apps, I decided that the app I needed to build for all of these people was Plinky. Plinky became more than an app to Colleen and I, it became an essential tool in our lives and a ritual. Sometimes Colleen would save a cute picture of a red panda for me, sometimes I would save an activity we could do next weekend, but every night the two of us would come together and share the links that we'd saved for each other. To this day we still have plink time, where we lay in bed and show each other the links we've for each other. Links come in all forms. An article just isn't the same as a Tweet or Instagram post you want to show a friend. A YouTube video or TikTok won't even open in an app dedicated to reading. Many apps like LinkedIn or Facebook have their own bookmarking systems, but I've wasted hours bouncing from app to app trying to remember where that link I saw a month ago but need now is. As I’ve built Plinky I've heard people tell me about the myriad of techniques they have for saving and storing links. There are an unending amount of organizational methods people use to reference links they might need later, but none of those perfectly fit into one app. The experience of listening to Plinky's beta testers led me to three realizations: It needs to be easy to save a link, the simpler the better. Saving a link shouldn't take work, it needs to be one tap, so you can easily save a link. People's workflows benefit from having a universal inbox for their links. It should be easy to organize and find links you've saved for later, otherwise why are you even saving them? People aren't always looking for an app dedicated to reading articles. The diversity of links people save means many people are looking for a tool that helps them do anything with the links they've saved, a Swiss army knife for their links. This is where Plinky comes in. Plinky: Saving Links Made Effortless Plinky makes it easy to save a link for later. You can save links from anywhere with just one tap. Whether you’re on the iPhone, iPad, or Mac, in your favorite browser like Chrome, Firefox, and Safari, or want to build personalized workflows using integrations like Zapier, Unread, Shortcuts, or Plinky's API, saving a link for later couldn't be easier. Plinky is highly customizable. You can make the app look, feel, and behave however you like. The links you save are very personal, as is what you want to do with them after they're saved. People have all sorts of workflows, so it’s a core goal of mine to make Plinky easy enough for my mom to use (she really is a big user), yet something you can infinitely tweak to make Plinky a perfect place for your links. Plinky has organizational features like Folders, Tags, Search, and Pinned Links. Each of these provides an opportunity to mold Plinky to your needs, and makes it very easy to find your saved links later. What's Next For Plinky I'm continuing to build upon these three pillars: ease, customization, and organization. Over the coming months Plinky will have the ability to: Add timed reminders for your links, for the purpose of reviewing a link in a certain time or context. Import your links from services like GoodLinks, Raindrop, Pocket, and other places you may already have your links saved. Create Secure Folders, giving you a space for more sensitive links protected by TouchID and FaceID. Indulge in an elegant reading experience that lets you customize fonts, sizes, and background color for the ideal read it later experience. Enjoy a native Mac app, one that takes the beautiful design Plinky already provides on iPhone and iPad and makes it feels right at home on the Mac. Have more ways to build personalized workflows around your links. It's easy to tag a link, but it should always be getting easier. Pinning links helps you prioritize some links over others, but the best experience will be even quicker. Plinky's search is powerful but it can get even more helpful by searching every word of a webpage you save. A Favor, If I May If you've made it this far I want to say thank you to you for caring so much about the app I've made. Plinky is the result of more than 1,500 hours of work. If that doesn't emphasize how much of my heart, sweat, and tears are in Plinky, I'm not sure what will. I'm truly excited about the idea of spending another 1,500 hours making Plinky better for you, then 1,500 more hours after that. If I may ask: Please download Plinky and try the app. I would love to know what you love about Plinky, what can be improved, or what I can do to make Plinky an integral part of your life. If you like the app, I would greatly appreciate a rating or review. Ratings decide the success or failure of apps the App Store, and as much as I hate to ask, I would like to succeed because that means I get to continue building an app that strives to make your links better. Tell your friends. I hope it's not too gauche to ask, but I genuinely believe that Plinky can help improve many people's lives. Every person who tries Plinky may be a person who's now using an app that makes their life a little better, and nothing in this world makes me happier getting a chance to help others. Thank You While you can say that I built this app, nothing in this world happens alone. I've had a lot of help along the way, and want to make sure anyone who's helped even in the smallest way is honored in Plinky. Plinky has a Thank You section on the About Red Panda Club screen where I've assembled everyone who's helped me while I've been building Plinky. The rest of this post was written for me and my loved ones, but you’re free to read it as well. I would like to first mention my wonderful fiancée and soon to be wife Colleen. Thank you for supporting me with your love, your advice, your daily feedback, and the hours of hands on help you provided over the last few months in creating and solidifying Plinky's launch plan. I love you, and because of you my dream is now a reality. Thank you to my family for cheering me on this whole time, without you I wouldn't be the person I am today. Plinky is a personal expression of who I am and the way I want to help make the world a slightly easier to navigate place. If it wasn't for you I wouldn't have that perspective, so thank you for instilling those values in me. Thank you to Joey Banks for being a great friend, for our weekly calls, and for your help in shaping Plinky's App Store screenshots and website. Because of you I was able to show the world what I've built in the way that reflects what I wanted people to see. While I'm here bragging about my friend, if you're looking for the world's foremost expert in Figma, you should reach out to Joey. Thank you to all of the beta testers who have provided endless ideas, feedback, and guidance over the last 18 months. Plinky wouldn't look or work the way it does today without your amazing ideas, and of course your extremely helpful bug reports. If you've provided a suggestion during Plinky's beta then odds are it's already been implemented, or is on the Plinky roadmap I've constructed for the next year and beyond. Thank you to anyone who's helped me over the last few years, whether or not that involves Plinky. The last few years haven't been easy, and while I can't always be strong, I can't always be brave, what I can always be is grateful and appreciative. Now if I may leave you with a few words: Be good to others, help those in need, and save a few links.

The Turing test is dead, and we killed it. The Turing test is a test of a machine's ability to exhibit intelligent behavior equivalent to, or indistinguishable from, that of a human. From the 1940s ¹ to the 2010s people programmed computers, and computers could only do what they were programmed to do in a rules-based deterministic manner. Sometimes a person would program the computer and it would do something unexpected, but 100 out of 100 times the computer was doing what it was programmed to do whether the person liked it or not. While there has been experimentation with what today we call AI since the 1950s, those machines were a long ways away from passing the Turing test.

Why does using ChatGPT feel more like a conversation with the smartest person you know than a computer? It's because ChatGPT doesn't solve problems deterministically the way a programmed computer does, it solves them probabilistically. ² ChatGPT demonstrates the ability to think about something in a logical, sensible way, the definition of reasoning. ³

We've created something completely new here, a reasoning computer. ⁴

The Turing test is dead, and we killed it. The Turing test is a test of a machine's ability to exhibit intelligent behavior equivalent to, or indistinguishable from, that of a human. From the 1940s 1 to the 2010s people programmed computers, and computers could only do what they were programmed to do in a rules-based deterministic manner. Sometimes a person would program the computer and it would do something unexpected, but 100 out of 100 times the computer was doing what it was programmed to do whether the person liked it or not. While there has been experimentation with what today we call AI since the 1950s, those machines were a long ways away from passing the Turing test. Why does using ChatGPT feel more like a conversation with the smartest person you know than a computer? It's because ChatGPT doesn't solve problems deterministically the way a programmed computer does, it solves them probabilistically. 2 ChatGPT demonstrates the ability to think about something in a logical, sensible way, the definition of reasoning. 3 We've created something completely new here, a reasoning computer. 4 Working With A Reasoning Computer There are so many political, societal, economic, and ethical implications of Large Language Models (LLMs), 5,000 words wouldn’t be enough to cover all those thoughts. (Trust me, there’s a much longer post sitting in my drafts.) But what’s really captivated me is why a reasoning computer really is different than anything we’ve used before, a conclusion I could only arrive at through experience. ChatGPT has been an essential tool for me over the last month, especially over the last week as I've been building Plinky's browser extension. I'm a very experienced iOS developer but have little experience with web development. I know enough TypeScript and React to cobble together something with lots of help and guidance, but it will take me much longer than someone who knows what they're doing. A browser extension is important for Plinky to be successful though, which presents a unique challenge: I know what I want, I know how to describe it, I don't quite know how to get it, but I will know when ChatGPT gives me the wrong answer so with some nudging I can get what I'm looking for. Here's why the process of pairing with ChatGPT works, and how it helped me build a fully functional browser extension that lives up to my standards in less than a week. (With far less frustration than if you took away the tool and gave me a whole month.) A simple browser extension to save links to Plinky's database is a much smaller problem than building a whole app. The problem is self-contained, which makes it quick and easy to test ChatGPT’s results and see if the output matches my expectations. In fields like mathematics or computer science it's generally easier to verify a solution's correctness than come up with a solution in the first place. I may be a novice web developer but I'm a great programmer. Even in a domain where I’m not comfortable I can describe the problem I'm trying to solve, assess whether a solution is good, do some research (on my own or with the aid of Perplexity and ChatGPT), and nudge the reasoning computer in the right direction. This isn't a process where I ask for something and am given exactly what I want, but I can promise you it's much easier than becoming a good enough TypeScript developer to build the high quality browser extension I want. Little by little the browser extension looks and works more and more how I want it to be, until it does exactly what I want it to do. The whole process is interactive so I’m learning about how to get to the right solution. Not only do I have what I want, but this iteration made me a better web developer, I started off only knowing what the wrong output looks like but now I also know how the correct solution should look. This is just one example of how I was able to accomplish something I previously wouldn't have been able to do thanks to an LLM, the number of tasks I turn to LLMs for is growing every day. The same way that GPS becoming ever-present means I haven't opened a map in almost two decades, I find myself turning to ChatGPT or Perplexity rather than opening Google and clicking a bunch of links to find answers. I used to do my own research, I used to be the reasoning machine, but now I'm offloading more and more of that work to Large Language Models. How Can A Reasoning Computer Even Work? People will say that ChatGPT can't do math, and that's true in the most literal sense. A Large Language Model may not know what addition and subtraction mean to a human, but it can synthesize the correct results to add and subtract numbers better than a person. Similarly people point out that ChatGPT can't read, because it's just a stochastic parrot that means it can't provide intelligible output. It's true that LLMs are complex statistical models, yet despite ChatGPT not knowing English from Urdu the way people do it's still capable of translating from English to Urdu to Russian to French in a way that I never would be able to. The fact that Github Copilot 5 doesn't actually know the difference between JavaScript and Swift hasn't stopped it from making programmers 55% faster at coding. Large Language Models use a different form of problem solving that starts with inputs and extrapolates technique. That's the reverse of how humans believe they develop their skills, if you study hard, read a lot, and put in enough hours as a writer you too can become the next Faulkner or Shakespeare. But think about the way you first learned your native language, you listened and watched the world around you for 1-2 years, then reverse-engineered how the technique works. We're reasoning machines too, the difference is that the entirety of the internet wasn't preloaded into our brains the way it was into an LLM. (For the best, I don't know if you know but there's some bad shit on the internet.) When we say ChatGPT can't do this or ChatGPT can't do that what we're doing is anthropomorphizing flaws onto the system, derived from our own experiences of solving problems successfully. The problem solving process may be difficult for people to understand because this is the first computer that doesn't do exactly what you tell it to do. Our intuitions may view this as a flaw, but OpenAI loading the whole internet into ChatGPT and creating a simple model for how to think rather than directly programming the machine is the reason this computer is incredibly useful in new and previously unexplored ways. Simon Willison says that these tools make you more ambitious with what you can accomplish, and I'd like to build upon his axiom. When you have a reasoning computer you only have to know what the wrong result looks like, not how to get the right result, and that alone has the power to change how society solves problems. Ada Lovelace deserves credit for writing the world's first computer program 100 years before ENIAC, but in this context I'm using the timeframe of the 1940s to focus the post on generally programmable computers.↩↩ It's perfectly fair to debate whether this is how the inner-machinations of ChatGPT work, but I feel very strongly that at a minimum you can say this about the output ChatGPT provides.↩↩ This isn’t because ChatGPT is sentient, but in all likelihood because it was trained on a corpus of human-generated data. It's difficult to define "thinking" in this context, my personal view is that there is no thinking without sentience, but in this context what I call thinking isn't the low-level internal machinations of ChatGPT, but one level higher — the step by step token output process that people using ChatGPT see in the process of getting their result.↩↩ I'd like to co-credit Joe Ugowe with coining this term, it stemmed from a wide-reaching discussion we had last night about our experiences with ChatGPT and Large Language Models.↩↩ Github Copilot is a Large Language Model product like ChatGPT, but trained with a coding-specific focus, which allows it to be integrated into a whole suite of Microsoft's programming-related tools and platforms.↩↩

When I wrote The Future Will Be Signed almost six years ago the latest in AI advancements was Google Duplex. If you're like me and have never used Google Duplex, it's a feature of Google Assistant that could make calls on behalf of a person and automatically perform a task, such as booking restaurant tables. While you may have never heard of Google Duplex there's a good chance you've used a generative AI tool like ChatGPT, Midjourney, or GitHub Copilot.

Authenticity

We’re going to need a way to prove the authenticity of a piece of digital content, everywhere, in a simple manner. This is where public key cryptography comes in. Our current solutions are noble efforts, but remain too complex.

It's quite an understatement to say that AI has come a long way since 2018, and yet the blog post's core thesis is even stronger today than when it was written. At the time I was concerned about a future where deepfakes, audio manipulation, and text generation spread across the internet. We're now living in the beginning of that future, this is our present. It has never been faster or easier to generate inorganic content, the tools to do so are more usable and accessible than ever.

AI already has us questioning what we see on the internet, and the problem isn't going away. Fake news articles are being written by ChatGPT, fake books are being written with ChatGPT, and of course fake reviews made up by ChatGPT are being used to sell all of this.

When I wrote The Future Will Be Signed almost six years ago the latest in AI advancements was Google Duplex. If you're like me and have never used Google Duplex, it's a feature of Google Assistant that could make calls on behalf of a person and automatically perform a task, such as booking restaurant tables. While you may have never heard of Google Duplex there's a good chance you've used a generative AI tool like ChatGPT, Midjourney, or GitHub Copilot. Authenticity We’re going to need a way to prove the authenticity of a piece of digital content, everywhere, in a simple manner. This is where public key cryptography comes in. Our current solutions are noble efforts, but remain too complex. It's quite an understatement to say that AI has come a long way since 2018, and yet the blog post's core thesis is even stronger today than when it was written. At the time I was concerned about a future where deepfakes, audio manipulation, and text generation spread across the internet. We're now living in the beginning of that future, this is our present. It has never been faster or easier to generate inorganic content, the tools to do so are more usable and accessible than ever. AI already has us questioning what we see on the internet, and the problem isn't going away. Fake news articles are being written by ChatGPT, fake books are being written with ChatGPT, and of course fake reviews made up by ChatGPT are being used to sell all of this. Trust This infrastructure is going to have to be baked directly into the software that developers build, in a way that is transparent to the end user. A politician (or anyone) needs to be able to sign a tweet, audio recording, or video clip to prove authenticity of what they are saying. With the creation and fabrication of content being so easy, we’re going to need a model where the person creating the content can prove it is trustworthy, and otherwise it should be treated as inauthentic. When I worked on Twitter's Societal Health team I spent a lot of time thinking about misinformation, disinformation, abuse, harassment, and civic integrity. These issues often took the form of coordinated inauthentic behavior by large groups of people trying to manipulate people and the public conversation. The scale of the problem seemed enormous, now it's larger than ever, and only getting bigger. We still need tools to help us differentiate authentic and inauthentic behavior or content, but there haven't been many meaningful efforts to build authenticity into the products people use. Arguably the largest advancements have come from a technology I personally have few positive feelings about, cryptocurrencies. When you believe everyone is an adversary then you need to build systems for trust. Bitcoin, Ethereum, and other crypto projects have shown that you can build a system based on public key cryptography that ensures a sense of truth. You may not like what that truth is, and it's easy to do so because of all the "Web3" that have been hilariously misused and abused in a seemingly unending amount of ways. I'm not pinning my hopes to the blockchain solving our trust problem, but I appreciate that much better user experience paradigms for trustless systems have emerged over the last five years because they were necessary for crypto to succeed. Scale In some ways the problems are actually worse than ever. Anyone can buy verification on X Twitter and impersonate their favorite brand. People have grown hostile and are treating platforms as adversaries because platforms no longer care about the people using their product. Platforms are even stealing usernames from active users, how can anyone trust what they read online when they don’t know who’s writing it? Platforms are treating their users as adversaries as well. If you get locked out of your Google account you might as well consider your digital life gone. A company like Google doesn't and can't scale support to the level of personal help we've historically been accustomed to in common society. Protecting user safety means support agents must assume that someone writing them for help is a scammer, fraudster, or hacker trying to break into someone else's account. The incentive structures for helping people are all backwards because the risk of Google turning over someone's Gmail account to the wrong person far outweighs the positives of helping thousands of people. This may only affect 1/100,000 people, but when you're that 1 person, losing your entire digital identity is horribly destructive experience. People need a sense of trust, some shared truth, and we're still in search of that online. As more of our lives happen on an inherently untrustworthy internet the status quo becomes more and more untenable, something has to give. Things will either get better or they will get worse, and based our approach of trying nothing and being all out of ideas, they are likely to get worse. The guardrails are coming off the system, if we wait too long then trust in our systems online and offline may fully erode. It's discouraging that we can't figure out a way to solve the problems we have today, but an even bigger repudiation of the status quo is that we don't even talk about this large systemic risk, and probably won't until it's too late.

Sometimes I think about all of the societal issues I cared about 10 years ago: privacy, government overreach, and platform accountability. More and more as I look at the technological landscape it feels like none of that care seems to have mattered.

When I worked on the Societal Health team at Twitter I had a voice and direct impact on these matters. If the feedback I received and still hear from my peers and higher ups holds true, that voice was not only well-received but considered thoughtful and led to meaningful change. With hindsight I can't say that every choice we made was right, there are few easy answers and no correct answers, but we made the best decisions we could with the information we knew at the time. These days I build indie apps like Short Circuit and Plinky for many reasons, it's what I think will make me truly happiest right now, but one of my reasons is to carry less emotional weight on my shoulders. I still have my morals, but without having the position I once had it’s harder than ever to translate my values into change.

The self-induced immolation of Twitter has caused a schism with the community I formed, cultivated, and connected with on the platform. People I follow, people I learn from, and many people I’d call my friends have all scattered to the four winds across a myriad of text-based social networks. I’ve spent the last week thinking about whether to join the latest Twitter-esque social network Threads, where many people close to me have made their way.

Sometimes I think about all of the societal issues I cared about 10 years ago: privacy, government overreach, and platform accountability. More and more as I look at the technological landscape it feels like none of that care seems to have mattered. When I worked on the Societal Health team at Twitter I had a voice and direct impact on these matters. If the feedback I received and still hear from my peers and higher ups holds true, that voice was not only well-received but considered thoughtful and led to meaningful change. With hindsight I can't say that every choice we made was right, there are few easy answers and no correct answers, but we made the best decisions we could with the information we knew at the time. These days I build indie apps like Short Circuit and Plinky for many reasons, it's what I think will make me truly happiest right now, but one of my reasons is to carry less emotional weight on my shoulders. I still have my morals, but without having the position I once had it’s harder than ever to translate my values into change. The self-induced immolation of Twitter has caused a schism with the community I formed, cultivated, and connected with on the platform. People I follow, people I learn from, and many people I’d call my friends have all scattered to the four winds across a myriad of text-based social networks. I’ve spent the last week thinking about whether to join the latest Twitter-esque social network Threads, where many people close to me have made their way. Twitter was an online home for me, and by working there I laid many of the bricks that stood up that home before new ownership decided they wanted to go Nero on it. Now as I contemplate a home on Threads I know I won't have the opportunity to speak up and create impact that aligns with my morals. Meta's long and sordid history of causing societal problems is well known. It's a helpless feeling to trust such important relationships to the whims of a historically opaque and soulless platform, but sadly it's now an option I'm considering. Meta has often been a destructive force to the values I care about. When I look at the state of technology it's depressing to see how blatantly corrupt the technologies we use have become. Maybe they always were, perhaps it was youth and innocence that led me to believe that such large, powerful, and impactful institutions could be guided and reformed, but from what I saw firsthand there was a glimmer of hope that it could be fixed by people from the bottom up. I'm torn between my values and wanting to stay connected with the people I care about online. Twitter changed my life by connecting me to people that still show me kindness, give me joy, and make me a happier person. But Joe, Why Don't You Just Use Mastodon Or Calckey Or Some Other Weird Thing That Federates Across The Fediverse? Facebook aside I've had moral qualms with using Google products, so I've long used alternative services. Instead of heading to google.com I open kagi.com, and instead of Gmail I use Fastmail. These are actually quite good substitutes, in many ways I prefer these two options over Google's billion-user products. Similarly I haven't missed Facebook at all since I stopped using it 10 years ago. I have no problem switching away from free problematic products to pay for a less troublesome alternative. Since a Musk-sized dagger ripped apart my community on Twitter I've wandered around looking for my people. I've joined Mastodon, Bluesky, and countless other alternatives, all with their own benefits and sets of tradeoffs. I strongly believe in an open and federated social layer for the internet, letting people use any social network they want and staying in touch with their friends and family the same way I was able to switch email providers. I don't ever again want to be caught in this situation where I've lost my community again, and the promise of federated platforms is that you can move around from platform to platform with your followers and people you follow. Mastodon has been a haven for more technical nerds leaving Twitter. (Nerds who I love, especially since much of the iOS community has moved over there.) I have a core group of people that I enjoy spending time with there, but the second anything I say escapes that circle of people the environment gets much worse. I receive so many low-value context-free replies, often completely misunderstanding what I was actually trying to say. People who don't know you can be pushy and aggressive with their views, some basically ignore what you post instead opting to spend 500 characters telling you what they think regardless of whether you asked. I constantly feel like I'm being talked at, not talked to, and it doesn't feel like a place that can be my home. Beyond the community it's discouraging to see how slow Mastodon's pace of development has been. I know first hand how hard it is to build a global-scale platform, and it's especially hard to build a large platform with only a few people and community funding. I have nothing but respect for Mastodon's approach, especially as they build the service in a standards-abiding way that can work with other ActivityPub-based services. And yet the platform still lacks features that Twitter has had for over a decade (ahem, global search), and has not become the Twitter substitute I'd hoped it would become. [Very] Technical Solutions For Social Problems I don't want to spend all my time ragging on Mastodon, I applaud their efforts and appreciate how thoughtful their team is. On the other hand Bluesky’s decision making is not what I would call thoughtful, but what they have managed to do was capture lightning in a bottle. Many of Twitter's most entertaining posters migrated to the Bluesky, leading to hilarious antics such as people threatening to beat Matt Yglesias with a bunch of hammers. (I wish I was kidding, but I do have to admit this was the first time a Twitter alternative actually felt like Twitter.) Unsurprisingly a community that leads with hammers hasn’t been very good at making Black users feel safe. I don’t think it requires having worked at Twitter trying to minimize harassment to feel empathy, and you don’t need a big empathic nerve to feel for people being told that the death threats they’re receiving are "hypothetical death threats" and won’t be removed from the platform. To Bluesky’s credit they’ve intentionally kept the network small, passing up opportunities to scale and seize an opportunity knowing they can’t make everyone feel safe right now. I feel conflicted about Bluesky, but where my hope for Bluesky lies is in what the platform is built upon, the AT protocol. AT solves important problems related to account portability and data ownership by relying on the concept of a Personal Data Server (commonly called a PDS). We live in a world where people say that platforms should both moderate more and less content, that you should have free speech guarantees unless it’s harmful, there is never going to be a right answer about what content should be allowed on a platform. This is why Facebook gets backlash, it’s arguably why Elon Musk bought Twitter, and it’s why every big tech company gets called in front of Congress. Currently your Facebook data is locked on Meta’s servers, which means if you don’t like Meta’s speech or harassment or governance policies, you can’t leave without losing your community. If a person owned their data then they would be free to move from platform to platform, looking for a home that suits them without losing connection to the greater community. The Bluesky team aren’t looking to build a platform, they’re trying to build the protocols that underly any social platform. By building a common protocol across the web people will be able to build and find platforms that suit them, and then can choose to (or choose not to) interact with people on other platforms through this shared language. The Bluesky team are protocol developers through and through, and I think their approach of building these fundamental primitives is the wise choice. The countless moderation failures of Twitter, Facebook, and others, show that ultimately someone has to make an often impossible decision about what content should be visible to users. These companies cannot make all the right decisions at a global scale, there is often no right decision, and despite my past work trying to help make Twitter safer, I don't believe it’s possible to create a set of rules that can make everyone happy. A better approach is to bring these decisions closer to the user. Mastodon does this at a community level, rather than some random contractor being paid an unfair wage halfway around the world make decisions about what content should be moderated on Twitter. On Mastodon the person who runs your community’s server (often with the help of admins) will decide what’s right for their community. You can join a community that seems great at protecting trans people, but over time you learn that they don’t do a great job of removing pro-Nazi content. Now we’re right back where we started, and you have to decide whether to find yourself a new home. This is why building primitives into the protocol and doing it right is important. Bluesky recently shipped a feature that lets users build custom timelines, letting you add or remove any content you want from your feed, for example, nazis.1 If done correctly platforms, developers, and individuals will be able to build and use tools that can be used for creating your own personalized experience rather than one homogenous "right" experience. Will this work? Well that's a big question and what I don't trust the Bluesky team to do though is to build a healthy social network where people feel safe to share their thoughts. And why should I? They assembled a small team to build a protocol, that was and is their stated mission, but have ended up falling ass-backwards into owning a social platform that people want to join. An 800 Pound Gorilla Walks Into The Room There are many things Mark Zuckerberg doesn’t understand, for example why anyone would want to have legs in the metaverse, but if there‘s one thing Mark Zuckerberg understands it’s social. You can read that as a compliment about his operational skills or you can imagine him as the digital version of Phillip Morris, but he has an almost gut-level understanding of what people want and how to give it to them. Threads has managed to sign up 100 million users in 5 days, in large part by bootstrapping their growth off of the Instagram network. There's also been a large collective of unhappy Twitter fiends (such as my friends) who are looking for any alternative to a Twitter run by Elon Musk. They're willing to forgive Mark Zuckerberg for his sins if he can lead them to salvation, which says a lot about how Twitter has fallen in their eyes. According to celebrities like Dane Cook the first week on Threads has felt like some drugged up parallel universe of Twitter. Post by @danecook View on Threads I don't expect this high to continue. Meta still has to retain and grow the Threads user base for it to be meaningful, but it does seem that unlike other niche Twitter alternatives Threads will at least give Twitter a run for it's money. What gives many people in the fediverse hope is that is Meta building Threads atop the open ActivityPub protocol. (The interconnected ActivityPub servers powering Mastodon and other services is called the fediverse, and yes, no matter how many times I hear it I still cringe.) By doing so Threads content will be available to anyone in the fediverse, and fediverse users will be able to interact with their friends on Threads. This works exactly the same way email does, if you have a Gmail account you can still email your grandma with her ancient AOL account. Some cynical people in the fediverse assume that Meta won't actually stay true to their promise of federating, but I think it's actually in their best interest. This is what Ben Thompson has coined a Strategy Credit, where you get credit for doing something widely considered to be good but is also beneficial to you. By federating with ActivityPub servers Meta will have access to content across the entire social web. Federating with ActivityPub servers is less about Mastodon and more about a service like WordPress which host nearly half of the internet's content. Imagine having a pipeline to all of that great content and applying Meta’s machine learning models to those posts so their users can see the best of the best across the web. This would make Threads a premier destination for content across the web, and Meta wouldn’t have to deal with angry publishers or content moderation since it’s not their content. This sounds like a dream for Meta, and at the same time may end up being beneficial to the open web. Open Questions Muddling A Federated The Future Let's say Threads really does federate, and they even act in good faith doing so. There are still many open questions about how life outside of the Meta ecosystem will look. I won't go into all of them, but to provide a choice few: What if Meta's search deprioritizes people on other servers for safety or quality reasons? It makes sense when you have a platform that serves over 100 million people that there will be many spammers, state actors, and bad people. The best way to tackle these issues is to gather insights from data, and third parties may not provide that data. If running your own server means being deprioritized, even with good reason, it may mean being cut off from my community at any point in time. What if Meta’s algorithm adds more weight to posts from Threads users higher because they have more insight into their users? It's much easier to operate on first-party data than it is on third-party data, especially since it seems like Meta is taking the privacy expectations Mastodon users have somewhat seriously with Threads. If my friends aren't actually seeing what I post then will they really feel connected to me? What if Meta builds good features that don’t translate to ActivityPub? For example on Threads you can control who replies to you (a feature I desperately need given my experience dealing with random Mastodon users), but since it's not a part of the ActivityPub spec that feature isn't available to Mastodon users. This isn't nefarious, it's perfectly reasonable. Meta's goal is to provide their users the best experience they can so they feel safe to come back and engage with the platform (and ads). If I trusted Mastodon with my online experience I would miss out on a lot of features like this, features that in all likelihood would make my online life better. Being on a different server may end up feeling like being worlds apart from my community, which is exactly the problem that brought me here. I hate to say it because of my moral questions, but the world is an impure place and I think I trust Meta more than Mastodon or Bluesky or whoever to listen and build a product that better connects me to my community. Where Do We Go From Here? I've been spinning my wheels for a week and I'm not any closer to answering the big question: do I choose my values or connection to my community? I love philosophy and many philosophers would tell me to live my values, those are by definition the choices I have to live with. But maybe the lesson is that there’s no purity here, I'm living in a world with many variables I can't control, and as much as I want to have it all it doesn't seem like I can. I believe the same things I once did, but it all seems harder, messier, and more difficult to rectify. Perhaps it always was, perhaps this is wisdom and that was naïveté, or perhaps it will get better. Only time will tell, and until then I still don’t have my online dream home. Appendix: Building My Ideal Home There is still a very good chance I don’t end up using Threads. Owning my data is still a very high priority, and I want to have my own space on the internet without Meta sticking their tentacles into it. When you use an ActivityPub-based service like Mastodon the choices your server owner makes are the rules you abide by. If my server owner doesn't want to enable local search (as mine doesn't), then I'm out of luck and can't even search my own Mastodon posts (as I currently can't). Because of that I don’t plan on continuing to use macaw.social as my Mastodon instance long-term, I would prefer to have control over my experience. The most straightforward option is to run my own Mastodon server. As noted earlier I can't say the Mastodon experience is very good, and I don't particularly want to tie my online identity to the Mastodon community. As explored in the amazing essay Paradigm Shifts For The Decentralized Web, Bluesky's concept of a PDS solves the ownership problem much like running my own Mastodon server would. A PDS would allow me to host my own data and you can let anyone I want access to it. A service like Meta can have a peek into my data for the purposes of showing it to users on Threads, but they wouldn't be able to follow me all across the web based on my data and usage habits since I wouldn't be using the Threads app. Since I find Bluesky's technical solution to be the best match for my personal desires I'm leaning towards setting up a PDS once it becomes easier, and using the AT protocol with a bridge that lets me interoperate with ActivityPub servers. There are still many questions with a setup like that though. It would be a piece of infrastructure I have to maintain, the most far along project Bridgy-Fed still has many open questions and, and I don't know how it would work in practice. It's like I'm both living through the early internet, waiting to see what emerges, and spending the rest of my day the internet circa 2023. I think custom feeds are brilliant and truly necessary, though I may be a little biased because giving users the ability to construct custom timelines was the last project I was working on at Twitter before I left the company.↩↩

To set expectations for you my dear reader, this blog post was written for me, not for you. It's very long (quite long), but I'm still proud of it enough to post for the world to read.

The frigid days of December are often unbearable in New York City, but those same freezing temperatures combined with the slow down of work, life, and everyone's collective desire to rest up after a long year afford plenty of opportunity to sit and reflect. At the end of every year I start to think about what I'd like the next year to look like, and then I set a theme for the upcoming year to help me make those ideas become a reality.

Yearly Whats?

A yearly theme is explicitly not a resolution, but a guiding principle you can look to over the next year. A yearly theme shouldn't be too specific, otherwise you could just craft a resolution, and it shouldn't be so broad that anything could fall into that theme. I've borrowed the idea of yearly themes from the Cortex podcast, where they discuss at length what yearly themes are, and how they approach their own themes.

"We are what we repeatedly do. Excellence, then, is not an act, but a habit."

— A quote commonly misattributed to Aristotle

What I like to do for my yearly theme is to look at a part of my life that's stopping me from being the person I want to be, and then work backwards to figure out what ideas, practices, and habits I can adopt to become that person.

New year new me, right? Wrong. I treat yearly themes as a way to build upon the work I did in the previous year, always striving to become more the person that I want myself to be.

To set expectations for you my dear reader, this blog post was written for me, not for you. It's very long (quite long), but I'm still proud of it enough to post for the world to read. The frigid days of December are often unbearable in New York City, but those same freezing temperatures combined with the slow down of work, life, and everyone's collective desire to rest up after a long year afford plenty of opportunity to sit and reflect. At the end of every year I start to think about what I'd like the next year to look like, and then I set a theme for the upcoming year to help me make those ideas become a reality. Yearly Whats? A yearly theme is explicitly not a resolution, but a guiding principle you can look to over the next year. A yearly theme shouldn't be too specific, otherwise you could just craft a resolution, and it shouldn't be so broad that anything could fall into that theme. I've borrowed the idea of yearly themes from the Cortex podcast, where they discuss at length what yearly themes are, and how they approach their own themes. "We are what we repeatedly do. Excellence, then, is not an act, but a habit." — A quote commonly misattributed to Aristotle What I like to do for my yearly theme is to look at a part of my life that's stopping me from being the person I want to be, and then work backwards to figure out what ideas, practices, and habits I can adopt to become that person. New year new me, right? Wrong. I treat yearly themes as a way to build upon the work I did in the previous year, always striving to become more the person that I want myself to be. Yearly Themes Past 2022 (Year of Trial & Error) 2021 (Year of Building Foundations) 2020 (Year of Pushing Boundaries) 2019 (Year of Creativity) 2018 (Year of Stabilization and Independence) I'll zoom in on 2022 in a personal appendix at the end of this post, so let's start in 2018. If you read these themes from oldest to newest, a story emerges. I was reeling from a divorce, and my #1 priority was to stabilize my life, and re-learn who I am outside of my marriage. I spent much of 2019 working on projects not because I thought they would bring me fortune, fame, or acclaim, but because they scratched a creative itch. By putting out those projects and seeing that they resonated with people just as they were I grew the confidence to push my boundaries, sharing more and more widely, delving into things that I previously would have been too scared to try. In 2021 I decided it was time to start thinking about a future where I don't work at Twitter, and instead pursue my dreams of being an indie developer. So in 2022 I leaned into the fact that being an indie developer would mean making many mistakes as I built a business around my own software, and that meant a lot of trial, error, and being ok with the mistakes I make. Year of Focus I managed to accomplish so much in 2022, but most importantly I was able to focus on my health after a very difficult 18 months. Working at Twitter was extremely difficult near the end of my tenure because of deteriorating health, and also a loss of motivation due to the related externalities. But while I was still working at Twitter I was spending nights and weekends working on Plinky. I used the positive initial response and support from friends and loved ones to quit my job and focus on building apps full time. The personal appendix discusses this with a lot more in depth, but in terms of my yearly themes, this year I'm working to my reign in the worst of my habits, my distractibility. I love to dream big, and letting my creativity run wild has taken me to some new and interesting places. I think it's something that sets me apart from many developers, and has allowed me to build some things that truly resonated with people in expected and unexpected ways, which is something I don't want to lose. But it's also important to set a few goals this year and make sure that I get them done, this is the difference in knowing how to do everything, and having the time, energy, and wherewithal to do everything. I have to draw some lines and make some tough choices about what fulfills me to ensure I don't spend my days working on an app, but instead am building an app that's the cornerstone of a successful business. Apps, Apps, Apps (And Business) Ship Plinky to the App Store Ship 2 major feature product updates Stretch goal: Ship a smaller app to grow Red Panda Club My top priority in 2023 is turning my software into an indie apps business. I spent four months last year working on Boutique and Bodega, and while I didn't intend to make money from them, I really appreciate the people who sponsor my open source work. Those two libraries are the foundation of my first indie app, Plinky 1, taking care of pretty much any state management one needs in a modern iOS app. I've built and shipped many apps before, but none that I was working on full time with the intention of building a business on top of. It turns out you can't make money as an indie developer until you have a product people can pay for though, so my success in 2023 starts and ends with shipping Plinky to the App Store. Shipping is just the beginning. The day you launch is closer to the first day of the journey than the last, which means there's still a lot of story left to be written once Plinky is in the App Store. I have a backlog of features I'd love to build as long as the Grand Canyon, but it's more important to listen to my users about what they want than to trust my gut. All of the feedback I received after launching Plinky's public beta was incredibly helpful. There was so much positivity and excitement, people told me so many things they wanted to see, and of course they found plenty of bugs. A sign that I'm building a product that will resonate is how many of the features people requested were already on the roadmap. There's no substitute for people using the product and telling you what they want, so rather than building out everything I think will resonate I'm making sure that I ship the minimum viable [polished] product, and then will build more features afterwards. Hopefully it will be more than two features, shipping regularly is an important sign of commitment to my users, but I'd like to set expectations low given how many other things there are involved with building a business. I don't expect my stretch goal to come to pass, but it's valuable to keep in the back of my head. I'm building an app with the code I write, but I'm also building a company. My dream is to build personal playful productivity apps that help people be the best versions of the person they want to be, but it's pretty rare that someone predicts exactly how they get to their dream. I keep a doc of "Interesting Business Ideas", ideas that I hope to implement, building a business around my values. It has idealistic goals like my Red Panda Promise, a plan to donate 5% of my profits every year to offset climate change and help preserve red pandas. It has practical ideas like giving away a free month of Plinky Pro to people who send bug reports that lead to me fixing problems or feature requests I implement, because they should be rewarded for helping me build my dream. And of course there's something I'm already doing, working in public and giving away as much knowledge as I can so other people can start business centered around their own novel ideas. Shipping a second app would give me more of a playground to experiment with these ideas, or to even potentially work on a project with a partner. My dreams don't stop at me working solo, they're about building things that matter to me and resonate with others. Working with the right person is such a wonderful feeling, so if I find the right person I might consider bumping one of my smaller projects to the front of the queue, something we can build together on nights and weekends. The reason this is a stretch goal though is because taking my eye off the ball and splitting my attention is clearly antithetical to my Year of Focus. I would only consider shipping a second app if the right circumstances emerge, but you never know. Simple But Effective Steps Towards Working More Effectively Use flow sessions per day to focus on my work Plan out my work tasks in Craft Make sure my todo list is under control Be less reactive through better batching Some days I wake up and can't wait to begin working. Other days I'm so distracted by every possible distraction that I have to conjure up the will of Thor to start my work day. I spent much of 2022 letting my creativity guide me to what I should work on next, and it resulted in quite a fulfilling year. I often found myself in research mode, which led to me creating Boutique and Bodega. I spent a lot of time prototyping really interesting ideas, resulting in some truly unique experiences for Plinky. And while I was able to get Plinky out to users in my public beta, it feels like I haven't had to "work like an adult" in a while. Even my work environment at Twitter was very reactive, and led to me forming plenty of bad habits for accomplishing deep work. The scope of my work will continue to narrow by necessity the closer I get to shipping Plinky to the App Store, and that's where practicing good work habits will become crucial. I've never lacked motivation, but my lizard brain gets distracted very easily. The Unreasonable Effectiveness Of Just Showing Up Everyday discusses how once you get started, staying in the flow is much easier, it even becomes quite an exciting state that you strive to reach. Over the final month 2022 I started using the app Flow to, well, stay in my flow. Flow is a pomodoro timer, with a twist. Flow lets you denylist apps and websites, so when I try to open Slack, Tweetbot, or Messages during a pomodoro session, it will just close the window automatically. Having a hard boundary allows me to stay in my flow, now when I tab over to check out what's happening on Slack I'm no longer distracted, instead I'm greeted with a reminder to stay in Xcode until Plinky finishes building. I've picked up another good habit in the last two months, I've started to plan out my day and my week in Craft. As cliche as it is for a software developer, I always try to bite off more than I can chew. Having a list of tasks I'd like to accomplish provides me enough perspective to see how much I really am trying to do, and keeps me on track when I see something else I want to do like spend 30 minutes tweaking an animation. Planning out my week gives me a good overview of just how much I'm really trying to accomplish, because it's easy to lose sight when you're only focused on that day. And it's also nice to be able to look back and see all that I accomplished, like a little gold star from my teacher at the end of a productive week. I've always been a todo list person, but by the end of 2022 I found myself overwhelmed with 50 tasks to do on my todo list, which was clearly not actionable. My list was filled with everything from urgent chores to stray ideas I didn't want to forget to long-term plans. I spent two days at the end of the year to find each idea their right home, whether it was in Things, Craft, or in the mental dumpster. Anything that isn't actionable in the short term has a better home in long-term storage like Craft, it's not necessary for me to wading through my entire future all the time when what I really have to do right now is pay the electric bill. Most people operate their lives around the standard work calendar. But as an indie I have an inordinate amount of freedom to shape my day, including working later into the night when my mind is ramped up and operating at it's best. I consider that a real blessing, but the bad habits of working reactively that I picked up working at Twitter aren't good for my personal life either. I constantly feel like I'm behind and playing catch up, or need to respond to my friend the same way I'd be tempted to respond immediately to my boss. But I don't have a boss, and my friends definitely aren't the boss of me. The solution is pretty simple, but took some time for me to see. I should just not do that, instead of responding immediately I can designate 10am and 6pm as the time I look at emails, find 10 minutes in the middle of the day to respond to some friends, and make reasonable exceptions when there's some urgency or necessity to respond quickly. I expect these boundaries to not only make me less distracted, but will also make me more effective and will enable me to do better work. Energy More morning or mid-day meditations Rest one day on the weekend, for real Figure out where I can cut some social obligations Plan for no more than three weekday social obligations per week My day is dictated by time and energy. We all have the same amount of time, but we have differing amounts of energy at different times. There are many things I can change in my life, but I'd benefit most from focusing on how I apply my energy, and where I apply it. I've meditated every day for the last five years, it's one of my best habits. I always feel better after meditating, but when I'm at my busiest my daily meditation will often slip into the evening or possibly very late into the night. When I'm my least focused and most frazzled is when I need to take a step back and meditate, so it's important for me to stay conscious, pause during the day, meditate, and regain my energy. It's also important for me to take a real day to rest, something I often have trouble doing. I'm a constantly curious person, so historically I've found myself constantly solving problems and puzzles until eventually I burn out and need a real break. It's important for me to avoid that trap, and to take a day off every week to make sure I can recharge. Creativity needs room to breathe, and that day off comes with other perks. It will give me space to be excited for that next day of work when I do get to let my mind loose on something I want to solve. Life is about more than just work, and I need time to live life and celebrate the opportunities I have. This year I did a much better job of putting down the computer and spending time with the people I love, and I intend to keep doing that. As for the second day most people take off every week, I tend to work six days a week but with a more relaxed schedule, scattering for chores and obligations that most people accomplish on the weekend. This year I'll use one of my days off to do the personal and work planning I mentioned earlier, maybe scratch a creative itch, prototype an idea I have, or spend the day with family and friends if I'm feeling particularly social. Your energy is bound by what you do, but it's also determined by what you choose not to do. 2022 was a year filled not only with work, but a lot of socializing, travel, and quality time with loved ones. As an introvert though I've found my energy running really low, and often feeling like I can't be my best self for the people in my life. Too often I've treated the time I have to work as a gift because it lets me go into goblin mode behind a computer, and that's a signal that I need to find a way to stop feeling so overwhelmed and stretched thin socially. It's incredibly hard to do, but I need to figure out where I can cut some of my social obligations. The ability to connect with friends across the world thanks to messaging, video, and airplanes has made me feel more connected to them than ever. Every week I have a few FaceTime calls, and I stay in touch with people over iMessage and Slack all day. I took four major trips to see friends in other parts of the world this year, and it was incredibly fulfilling. Spending time with people in person made me realize how much is missed over a monthly FaceTime call, and I don't have a good answer about how to fix that. But it does make me think, even if it isn't easy maybe it's worth trying to move those calls back from every four weeks to every six or eight, to reclaim some of that social energy I've been giving away. I need to get that energy back somehow, and limiting myself to three social obligations per week (including FaceTime calls) feels like a reasonable balance between keeping up with friends and running at a constant energy deficit. For much of 2022 I had the flexibility to work around people's schedules, but now that I'm working full time and more focused, I've become bound to the same constraints as everyone else. It's far from my favorite thing to do, but I have to be responsible and set hard(er) limits, staying vigilant about my energy, so I have energy to spare. One thing I'm not willing to give up is my time with Colleen. We have our weekly date night, time together on the weekend, and dedicated space for each other every night before bed. We spend plenty of time together besides that, and even though I have space to be my own individual, I'm always happy when I'm with Colleen, so spending time with Colleen has to stay a priority. Tradeoffs Improve my sleep regimen Shorter journal entries to reclaim my time Figure out where I can cut my information intake More bad news, as an adult I have to start setting better boundaries. I don't want to go to bed at 1am every night anymore, it makes me feel like I'm not a functioning member of society. I always get my 8 hours of beauty rest which means I'm often crawling out of bed at 9:30 or 10. Every time I've tried to be a morning person it's failed, but I should be able to wind back the clock to 12 or 12:30, or gasp, maybe even falling asleep before midnight. I spend quite a bit of time journaling every night before I go to sleep, and along with meditation it's one of my most treasured activities. It's worth the time I put into it, but it can also be really daunting, especially as the last thing I do before going to sleep. In an effort to preserve my memories I've found myself adding more and more details to my journal entries. The more detail I add the longer a journal entry becomes, which means spending more time journaling every day. That time adds up, and it adds up fast. I've noticed my journal entries ballon from 400-600 words per day to 800-1200, which means spending 20-30 minutes writing rather than 10-15. While I find the longer journal entries better to read afterwards, it's a lot of time to give up. I intend to reclaim my time by focusing in on the important events of the day, adding flourishes and details to capture my memories as accurately as possible, rather than recapping everything that happened that day, down to taste of the bagel I had to start my morning. An evergreen reason I find myself constantly feeling behind is because I've done this to myself, I am constantly behind all the content entering the firehose of my phone. There's always one more thing to read, a show to watch, a podcast to listen to, and all this content comes in all day every day. I'm always happy to indulge myself with something else to consume, but I've noticed that when I have free time my mind really enjoys wandering off. I don't need to put on a podcast or some music when I'm walking around, the world is so rich and textured, I should enjoy the full experience of my surroundings. I'm very happy when the content runs out, so why shouldn't I give myself more of that? All I've been missing is permission. I'm giving myself the permission to drop things. I've unsubscribed from a bunch of podcasts, I've removed a bunch of RSS feeds, I've unfollowed a lot of people on Twitter (and Mastodon), and I'm giving myself permission to put down books I don't like rather than begrudgingly finishing them. There's a central motif underlying my yearly theme of focus: my time is precious, so I should focus on what's important. Appendix: 2022 I'm really proud of how I leaned into my Year of Trial & Error in 2022. I accomplished so much by deviating away from my tendency to make safe choices, having always feared the impact of making a mistake. I sold myself on 2022 being a year where it was ok to make mistakes, and to show myself that I can recover from any mishap. Not only did I come out ok, I had a great year where I accomplished so much. But I also learned a very valuable lesson. When you down the “wrong” path, it often ends up being the foundation for another more formative path. When you make reversible decisions you can always walk back down the road you came on, and take another path from there. This time though you'll be armed with knowledge and experience that you didn't have the first time, letting you make better choices. You can even walk back up the same path you came down, succeeding this time because you're prepared for what lies ahead. Beautiful, amazing, wonderful things can happen when you do something you're unsure of. This year I did one of the least safe things I could imagine doing, I quit my job at Twitter to pursue my dream of being an indie developer. I've been dreaming of building a business around my apps, and in 2022 I took a big leap forward. I'd been preparing mentally, emotionally, and financially for the day I decided to leave for over a year, but that didn't make it feel any more practical. I left on a Friday, had a blissful weekend, and on Monday I woke up to frantic texts from friends asking and telling me about Elon Musk acquiring enough shares of Twitter to become the top shareholder. I didn't know what I was going to do that day, but I was very glad that this news didn't directly affect me anymore. If I had stayed at Twitter for one extra day I would have had a completely different perspective about leaving rather than all of the positivity I had around my departure. The lesson here is that no matter how safe or unsafe you feel making a decision, you always only have a small subset of information. No one can predict the future, and the future is more vast than the present, so worrying and trying to optimize every detail isn't a recipe for success. You can only control the parts of any major decision that you have direct control over. Contrary to the chaos that ensued at Twitter over the coming months, I spent my first months of self-employment following my creative impulses, and they took me to some amazing places. I won't spend too much time going over every one of them because this is the personal part of the post, and I know what they mean to me. Instead I'll list them off, with some details in case one of them catches your eye and you feel like taking a deeper look. I built two very successful open source projects in Boutique and Bodega. These projects even led to me being interviewed by the GitHub team. (Hi mom and dad, I know you don't really get what I do but I'm happy you listened to the podcast and were very proud. 🙋🏻‍♂️) Boutique and Bodega serve as good foundation for creating MVCS, an architecture for building SwiftUI apps that's gotten some traction and helped me a lot. I needed an image-based API for my Boutique demo project, so I built one that serves images of red pandas. This was a fun example of what I could do because I'm now working for myself, there's no immediate business value to having spent 2 days learning Cloudflare Pages, R2, and a whole bunch of other technologies, but given my company is named Red Panda Club I'm sure I'll find plenty of fun uses for this going forward. 🦊 I rebuilt and redesigned my personal website, fabisevi.ch, something I've had on my todo list for nearly a decade. I created build.ms to supplement Red Panda Club. Red Panda Club is where my apps and products will live, build.ms is where I'll be sharing the lessons I learn building Red Panda Club, with a focus on engineering, design, product, business, and more. I wrote six blog posts across those two websites. Coding As Creative Expression, Reflections On An Open Source Project, Goodbye Fellow Tweeps, Designing A High Signal Interview Process, Model View Controller Store: Reinventing MVC for SwiftUI with Boutique The Best Twitter Bio, The Humble Tweet I put my feelings out there by spending the day before my birthday writing about all the nice people in my life. And last but definitely not least, I launched a public beta of Plinky, my first indie app. [I'll do my best to not pitch you again in this blog post, but maybe sign up for the beta? I make you an empty promise that you'll like it.] I did a lot more than that of course. I read 15 books, a whole bunch of meaningful articles, traveled around the world to meet friends old and new, and of course spend a lot of time with my friends, family, and girlfriend here in New York. Those all spurred much reflection and insight, but to explain how they fall under trial and error would take far too many words. Now we're going to get really personal. By far the biggest trial I dealt with was a mysterious neurological disorder that caused me indescribable pain for the last 18 months. People who are close to me know about it, people who know me from afar may have some allusions to it, but in 2022 I finally received a diagnosis for my mystery ailment after seeing dozens of doctors and specialists who couldn't figure out what was wrong with me. Thank you to my neurologist for diagnosing my cervical dystonia, which allowed me to start getting treatment for the condition. In most cases it's incurable, but since my condition has a good chance of being linked to trauma, I may be able to heal over time. I've seen a lot of progress and pain reduction not only from the quarterly botox injections in my neck and medication I'm taking, but also from the work I'm doing in somatic therapy to address the underlying trauma. There were many errors along the way, I tried so many different things to feel better. Every day there was a new and slightly different pain, and every day I would try to figure out what was happening. Somatic therapy has not only helped me face the trauma that's causing my brain to malfunction, but to learn how to listen to what my body is telling me that my brain won't allow me to hear. But I persevered. I knew I couldn't live like that, I love life far too much to give up. I love Colleen who's been there for me every day, and I love my mom who's been there to listen to me as I've gone through so much. I love my brother and my dad who have their own sense of how I'll get better, and are supportive no matter what. While every day still carries some difficulty, it's easier than it was six months ago when I finally found my doctor and somatic therapist. It's easier than it was three months ago when I started botox injections. It's easier than a two months ago, one month ago, one week ago, all of which are times I made majors breakthrough in somatic therapy. None of this would have been possible if I hadn't quit my job. I was suffering physically every day, and even with the generous time and space away from work that Twitter allowed me to focus on my health, I couldn't focus on on my health enough to see progress. I needed this time in my life, I needed this space, I needed to feel like this year was a year dedicated to me. I said that quitting my job was one of the least safe things I could have imagined doing, but sometimes doing what's safe isn't the same as doing what's right for you. Having learned that lesson, I consider my Year of Trial & Error a tremendous success. Plinky is an app that lives between a link utility and a bookmarking app, with some very novel collaboration features that I haven't seen on any other app. I think there's an interesting space for managing links that don't really fit into the mold of Pocket, Instapaper, Matter, or other apps that focus on reading. I'd love it if you checked out here or signed up for the beta. 🙂↩↩

Is coding a science or an art?

— Matthew Garlington (@dejadu13) May 21, 2022

I've seen many versions of this question posed over the years, and to Matthew's credit it's a very good question. As you can see in the replies people translate their lived experience writing code and answer art or science based on however they conceptualize and practice programming. A few years ago MIT conducted a study that concluded "reading computer code is not the same as reading language", answering the question of whether coding is art or science with a rigorously documented "both". While I'm hard-pressed to argue with science, I'd like to provide a different answer, one that's a little more conceptual.

Is coding a science or an art? — Matthew Garlington (@dejadu13) May 21, 2022 I've seen many versions of this question posed over the years, and to Matthew's credit it's a very good question. As you can see in the replies people translate their lived experience writing code and answer art or science based on however they conceptualize and practice programming. A few years ago MIT conducted a study that concluded "reading computer code is not the same as reading language", answering the question of whether coding is art or science with a rigorously documented "both". While I'm hard-pressed to argue with science, I'd like to provide a different answer, one that's a little more conceptual. The instinct to qualify coding as art comes from the practice of programming. While writing a program software developers make many choices, ones that rarely have hard and fast rules. As long as your program compiles and runs as expected, you can make any choice you want. It's all human input, if you ask 100 developers to write a complex program they'll write it 100 different ways. Heck, if you ask one developer 100 times they may write it 100 different ways. Code can create something beautiful, enable an amazing experience, and people will even call a piece of code elegant or exquisite. To someone in the arts this all sounds very familiar. The instinct to qualify coding as a science comes from the output of a program. Developers desire deterministic results for their programs, when you provide an input to a program you expect to receive the same output every time. The practice of programming itself can be imprecise, and the same way that science operates in unknown space, building a program can often feel the same. Developers will try to minimize the ambiguity by using industry-tested practices, much the same that a scientist uses a standardized beaker rather than throwing some chemicals in an unclean cup and seeing what happens. When put together that truly sounds like the practice of science. What we've found ourselves asking is whether code is a paint brush or a calculator, and frustratingly the answer appears to be both. Despite the fact that programming looks like art and looks like science, I still think there's a concept that better fits the practice of coding, creative expression. We can look to writing as a point of comparison. Sometimes it's hard to believe that the most beautiful poem uses the same medium as boring technical documentation because the artifacts look and feel so different, but we all know it's true. The medium doesn't impose limitations on how someone can choose to express themselves, it's a tool for creative expression. With writing it's impossible to separate the medium from the artifact created, and the same is true for code. Code can be artistic and create something new in the world, or it can simply exist to accomplish a task. Code helps people capture the meaningful moments of their lives, lets you carry the beauty of every song ever recorded in your pocket, but it's also the boring spreadsheet that helps you run your business. So is coding an art, a science, or creative expression? I say coding isn’t science, it's not art, it’s not quite a craft, but a malleable form of creative expression. When given an infinitely flexible and manipulable canvas people use their imagination to create wondrous things, ones not limited to simple categorization.

Hard to believe it's over. My time at Twitter wasn’t perfect but it was incredibly special and there's little I would change about it (though less crypto would be cool). I was able to provide constant feedback about products across the entire platform and the entire organization, work on some of the most pressing digital societal health issues of our time, including the 2020 US presidential election, and help launch numerous products to minimize abuse and harassment. I never once felt like I couldn't advocate for the concerns of the sometimes thoughtful sometimes bonkers people who use Twitter, providing a voice for people who don't get to have a voice inside Twitter.

There's so much more I could say but instead I decided to post the going away email I sent to a thousand or so people at Twitter.

Hard to believe it's over. My time at Twitter wasn’t perfect but it was incredibly special and there's little I would change about it (though less crypto would be cool). I was able to provide constant feedback about products across the entire platform and the entire organization, work on some of the most pressing digital societal health issues of our time, including the 2020 US presidential election, and help launch numerous products to minimize abuse and harassment. I never once felt like I couldn't advocate for the concerns of the sometimes thoughtful sometimes bonkers people who use Twitter, providing a voice for people who don't get to have a voice inside Twitter. There's so much more I could say but instead I decided to post the going away email I sent to a thousand or so people at Twitter. I was really heartened by plethora of thoughtful, meaningful, and overwhelmingly kind responses I received, enough so that I decided to publish it publicly with minimal edits to provide context or clarifications such as the fact that Visible Changes is an internal mailing list for new products shipping at Twitter since there are so many teams working on so many different projects that it would be impossible to keep up with everything happening at Twitter without subscribing to the Visible Changes mailing list. If you're curious about what I'll be up to now that I no longer have a job, feel free to check out this thread, unsurprisingly on Twitter. Howdy friends, colleagues, and strangers (sorry for the email strangers, feel free to send this straight to the archive!). You may recognize me from my occasional long-winded Slack messages so it should come as no surprise that I decided to squeeze in a 1,300 word going away email with a linked Google Doc1 of feature requests before I leave. After 3 years, 10 months, 3 days, and one pandemic at Twitter, my last day at Twitter will be April 1st. (Yes I recognize that me writing an org-wide email joking about quitting on April Fools Day would be incredibly on-brand for me, but I assure you it’s true.) I’m so proud to have worked at Twitter, and I forever will be. I'm incredibly grateful for the work I've been able to do directly, influenced indirectly, and most importantly so thankful to the people I've met and worked with along the way. (Maybe the real friends were the coworkers I made along the way — those of you not in the strangers category will appreciate this.) I love this company, I love the people, I love using all the latest and greatest experiments in Earlybird (so please remember to bucket me into all the good experiments). I want to stay connected with many of you, now and beyond, so please don’t be shy about throwing some time on my calendar or reaching out to me by other means over the next two weeks or after — I’ll always make the time. To get the first question everyone’s been asking out of the way, I’m not going to work anywhere else. It’s definitely not Facebook (lol, Meta or whatever they wanna be called), and never will be. I’m taking some time off (2, 3, heck maybe 6 months off but don’t worry I’ll still be tweeting) to recover from what’s been a very taxing year physically and emotionally, focusing on some health issues that I’ve been dealing with. But what I’m really looking forward to is wandering around the streets of NYC this spring, riding around on my bike, and enjoying time with family, friends, and loved ones. Twitter has been the job of a lifetime, but right now the last thing I want is a job, so I guess I’m just going to not have one. Since most of society has to exchange their labor for capital in some manner after I’m refreshed and rejuvenated I do intend to do the same, but working for myself again like I did before Twitter. This time around I’d like to try my hand at building playful and creative indie software products, tools oriented around helping people leverage technology for their personal needs, with a matching company that combines my love for teaching others and helping people reach into their hearts to derive the true value of what they can do. I’d be remiss if I didn’t say I learned some of the valuable lessons I'll be using and sharing from my time here at Twitter, and will do what I can to reach others through writing (longer than tweets) so they too can benefit by learning from others learning. If you’d like to know more about what I'll be up to by all means please reach out and I’ll be happy to share. I’m sure you'll appreciate that this is where I say the best way to keep up with how it’s going is by following me on Twitter @mergesort, with indie development updates and red panda gifs @redpandaclub. I'm always looking for feedback, the sense of community I built here is something I wouldn’t trade for the world and will miss dearly, I'd love to keep as much of it as possible. And because I trust you all with my personal email you can always reach out to me at [nice try but you don't get this random blog post reader]. I want to say thank you to every team I worked with (aka bugging every feature team to build my pet idea — some of them were actually good!) and worked on, Communities, Communities Health, Twitter Dev, and Notifications. But a special shoutout is reserved for Health, and that goes even further for the team formerly known as Health Client. We built some incredibly meaningful things on Societal Health and beyond, but more importantly we built a team of amazing people on the foundation of empathy, caring, and curiosity. To those people I’ve had the pleasure of working with on that team, I don’t say this lightly but I love you like family. The work you do isn’t only about helping Twitter today, it’s some of the most important work for keeping Twitter an important part of the world in 5, 10, or 50 years from now. But today I’m still at Twitter, and as a parting gift in the spirit of our company value fearless honesty I’d like to leave a few thoughts I’ve had bouncing around in my head over the last few months while thinking about the unique and wonderful place Twitter has been to work. Twitter isn’t the biggest platform in the world, but its effect makes it the most consequential tech company in the world. The world takes its cues from Twitter, and because of that we should find ways to get more users by opening Twitter, not closing it off from the open web. When we move away from Twitter’s open nature we’re losing a bit of Twitter’s service to the world, I hope we remember that in everything we build. Let your values guide you. The success of Twitter isn’t DAU, DAU is a lagging indicator that shows we’ve succeeded in building a good product. We’ve heard a lot about our DAU goals and we should shoot for them, but please don’t let the ends become the means. Never stop looking for paper cuts. If you look closely you’ll see more of them happening more frequently as the system we build becomes more and more complex, and the expression death by a thousand cuts has resonance for a reason. Health isn’t a fixed goal and it isn’t a lever we can pull up and down depending on where we’re focusing our energy. As we gain users and build new surface areas Health problems will only become exponentially more difficult in unpredictable ways so please don’t view Health as something that can be balanced with user growth. Lean into and invest in the infrastructure the Health org has built and turn expansion into newfound success, striving to build a better and healthier social network than any of our competitors. Twitter’s culture is unique and one of a kind, please don’t lose it. Especially as the company grows it’s easy for culture to dissipate. New perspectives are incredibly important, don’t be shy about integrating new tweeps and their ideas, but for those of you who have been here for a while your job is also to teach what’s made Twitter so special that people all over the world want to join and leave their mark. That culture only continues to be world class if we help new tweeps know about it. Unfortunately over the last year I’ve seen a lot of newer tweeps across the entire company struggle to feel like they understand what they’re supposed to be doing, and that’s not their fault. Every person’s job involves doing the work they came here to do, but a part of that is setting every new tweep up for success. Keep helping new tweeps succeed, so look at a person to your left, look at a person to your right, look at your Google Meet screen, and remember that you only succeed when they succeed. I’ll sign off with a few words @Kayvon once said that have stuck with me since — you are absolutely right Joe. ✌🏻 P.S. Thank you Kayvon for always being a good sport the 945 times I’ve used this clip to make a joke, all the best on your parental leave! P.P.S. Bothering y’all while I still can, here’s a list of features and ideas I would like to see be built. Consider this one last dump of practical and reasonable ideas I’d love to see Twitter build since I won’t be able to bother people after April 1st, 2022. (You don’t want to see the list of impractical ideas I have saved.) A quote tweet redesign that de-emphasizes the original content to detract from the nature to dunk, rendering more like an organic reply that’s visible on your timeline, and the ability to de-index your tweets from search as discussed in Slack here. (We've talked about de-linked quote tweets on the Health side before, and I'm all for it. I've also wanted a similar feature for search. It would be useful to give users the power to delist their tweets from search, that way we could prevent people searching through people's old tweets and dogpiling them for years-old comments that may not be reflective of today's norms, but still allowing those tweets to live on a user's profile so the original author can choose to surface/resurface them as desired. I guess a better way of putting it, allowing users to opt out of letting their tweet(s) be publicly indexed for search.) Third Party Verification. Twitter should be the central hub for identity on the internet, and we can get a step closer to there by letting people authenticate with third parties such as YouTube, Instagram, Tik Tok, Github, etc, and have those destinations displayed on a user’s profile without resorting to hacks like LinkTree or this. Fix open graph tags. I cannot tell you how many iOS users would rejoice if you could play videos in tweets without leaving iMessage, or at least see that a tweet contains a video with a little play button over the image rather than rendering a static thumbnail from the video. If you send a quote tweet to someone it shows up as some text and a link so users sometimes don’t realize it’s a quote tweet. And showing the date of the tweet would do well to help lessen the spread of outdated information (which can become misinformation). Please don’t ship an edit button, but do ship Clarifications. (go/clarifications) Timeline sync, the way third party clients such as Tweetbot implement it. I would love to leave my Latest timeline on one device and pick it up on another device, that way I don’t lose my place. This can be pretty simply done by sending down a “sync cursor”, and would likely bring a lot of fanfare and users over from third party clients. A slight redesign to the composer to make it feel more WYSIWIG. Reading in the context of a tweet makes it easier to catch mistakes so looking at a live preview as you’re composing it not only should look better, but should hopefully reduce the rate of errors and typos in tweets. Tweet digests. Follow the best tweets from a person in a day, being able to set custom criteria. Show me the top five tweets from a person in a day, only show me tweets with 50 likes or more from people I follow, etc. Thread marker. Instead of users manually writing 1/25 to signify the first of a 25-tweet thread, since we know how many tweets are in a thread we should show a little bubble on the tweet in the top right corner that says (1/25). It’ll save people precious characters and let threads grow in size without having to know how long they’ll be upfront. Searching my bookmarks and likes has gotta be some of the lowest hanging fruit at the company and has been built in hack weeks multiple times, can we please ship that? While we’re at it can we expose filter:follows filter:nativeretweets in search so users can find tweets they’ve seen (including injections) without having to remember such a wild query? 🥺 Please stop making Latest harder to use. I know research and metrics show that Latest has less engagement than Home but people who use Latest are different users, not worse. They may not engage as much by choice but you won’t convert many in that specific batch to being on Twitter more by making Latest harder and harder to use, instead you risk losing them entirely. And last but not least, it’s not a feature per se but I would love to see Twitter become the industry leader on harassment, spam, misinformation, etc, not only by working with with governments and NGOs — but by working with other companies and our peers there who also want a safer and more secure internet. Together we move farther than we do alone, and a healthy internet is an internet that’s healthy for every participant around the world. ↩

Crafting a great interview process is difficult¹, especially for software development where a company is often trying to assess years of specialized knowledge and potential in only a few hours. The best interviews are said to feel like a discussion amongst peers, where each side is providing the other with signal about what it will be like to work together. Candidates share signals about their experience and thought process, while interviewers help provide signal and insight about a company’s values, the working environment, the state of a company, and more.

Crafting a great interview process is difficult1, especially for software development where a company is often trying to assess years of specialized knowledge and potential in only a few hours. The best interviews are said to feel like a discussion amongst peers, where each side is providing the other with signal about what it will be like to work together. Candidates share signals about their experience and thought process, while interviewers help provide signal and insight about a company’s values, the working environment, the state of a company, and more. The interview process for a job in a highly collaborative environment should be highly collaborative, providing a lot of feedback and insights for both sides along the way. The interview I am imagining is nimble and fair, mimicking the day to day work of a software developer in only 3-4 hours over four rounds. Any shorter and it may be hard to glean enough understanding of who a candidate is. If it goes much longer then that it'll be unfair to candidates who can't dedicate a whole day (or two) to interviewing with your company, and will be an increasingly expensive amount of resources to expend as your company grows. Transparency There aren't any benefits to being secretive about the process so I recommend letting a candidate know ahead of time what to expect from their day with you, beginning the process from a perspective of mutual respect. Given a relatively short time constraint the ideal process would seek to emulate the product lifecycle at your company, with time at the end to fill in any gaps you and the candidate may have. The highest-value work that can be done in that time is to build a small feature end to end with partners who will be working day to day with this developer. The Product Design Round The first part of most product development lifecycles is one that focuses on communication and iteration, taking a whole world of possibilities and whittles it down to a tangible output. That’s what we’ll aim to accomplish by pairing up the candidate with a product manager or designer, to discuss the feature they’ll be building together. The product design portion of the interview would start by walking through the scenario the company finds themselves in, the constraints they have, the customer needs, and anything else that is necessary to consider for what we’ll be building. Acting as partners both sides would work together to develop the context and thoughts into an idea, ultimately leading the candidate towards a defined version of the idea that they’ve worked together to build. There should be enough wiggle room to let a candidate's creativity shine through (which is in itself a useful signal), but ultimately by the end of the interview there will be a defined spec and designs of what needs to be built so the candidate can be prepared for their second interview. If you don’t reach a well-defined spec through collaboration that’s not necessarily a dealbreaker, not all engineers shine at product design. If you haven’t reached consensus on what a good product spec would look like, you should pause with about 10 minutes left to discuss what an ideal solution is. This will allow the candidate to familiarize themselves with the solution they’ll be building in the following interview, and it will also clue you into other important signals such as communication skills, how they collaborate in situations that have ambiguity, and their ability to respond to feedback (positive and negative). The Cross-Discipline Round Depending on if you're a front-end or a backend engineer, your second interview will be with a partner from the alternative team. (A backend developer would be asked to discuss the front-end portion in the second interview, and a front-end developer would be asked to discuss the backend needs.) In this case we’ll assume that a front-end engineer is being interviewed, so the discussion would involve your team’s backend engineer, centering around high-level architecture, API design, and other ways that a client would interact with a hypothetical backend. This interview would not be a coding interview, it would be a high-level discussion with a technical partner. The pair would discuss how the feature should work end to end, not asking a front-end engineer to understand the specific implementation details but to know where the front-end and backend would interact with each other. Knowing what SQL queries are occurring under the hood isn't as valuable day to day for a front-end engineer, but having a good idea for what a solid API looks like or how JSON should be shaped for the necessary data is highly beneficial. By the end of the interview the candidate should walk away with a fully fleshed out spec, one that makes sense for the problem they're looking to solve. The Proficiency Round This is the interview where a candidate will implement the feature we've designed and spec'd out. Much like in the first two interviews it’s important to establish early on that the candidate knows that the developer across the table is their partner and is there to help, answering questions, even pair programming if necessary. We want to get a feel for the kind of code a candidate writes, but we also want to minimize the context necessary to solve a problem. It's difficult to write code on demand, especially when there's a time constraint. To balance those requirements we won’t drop the candidate into a huge code base, and will use common platform/framework conventions so they feel as familiar as possible. Our top priority will be to build something that works, acknowledging the tradeoffs that were made along the way, and talking through where improvements could have been made (if there's room for improvement). The output we want to see is a working solution to match the spec we’ve built upon in prior exercises, if this were a test this would be where the candidate shows their work. The best candidates will be the ones that not only have a good solution to the problem, but also communicate well in the process of building it. The Calibration Round If you’ve ever walked out of an interview hoping the first person you met hours ago didn’t misunderstand a slip of the tongue or an unclear thought, you know how awful it can be to sit with that feeling for 24, 48, or even 72 hours as you wait for a response. Sometimes a company feels like if they had only spent a little more time with a candidate they would have gotten the signal they need to make a solid hire or no hire decision. It's much better for both sides to figure any open questions before a candidate leaves the office, so that’s what this interview accomplishes. This interview is a candidate’s opportunity to ask questions they have for the company, and a company’s opportunity to get answers to any open questions they may still have about the candidate. Before starting this interview let a candidate know that the three interviewers they met will be taking 10-15 minutes to try and figure out what questions they have. It’s been a stressful couple of hours so do whatever you can to ease the candidate’s nerves. Assure and reassure them that this is a normal part of the process no matter how well they did, it’s not always feasible to answer all the questions you may have about a candidate in a short period of time. But also let them know that you want both sides to feel confident they know what working with the other side is like, this is a big decision to make. The extra interview session is bidirectional, the candidate will have plenty of time to have their questions answered as well. Offer some water, let them use the restroom, ask them if they want to take a few minutes to themselves or even offer an employee for them to hang out with, whatever they want after a long day. At first this short gap may seem anxiety provoking, almost like sitting through judgment day, but as long as a candidate knows upfront about the process and motivation it should be a lot less uneasy than days of wondering about how an interview went without an opportunity to correct the record. Due to the imbalanced dynamics of this experience time-boxing your team to 15 minutes of discussion is a must. In this time a team should be coordinating to figure out what open questions remain, your goal is to figure out if you have enough signal to make a decision, and if not what needs to be asked to get enough signal. You can dive in more to the solutions a candidate came up with, discuss proper leveling, interpersonal dynamics, and whatever else matters to your team. If the interviewers agree that the candidate did well and don’t have any open questions then this last interview will be short. Provide the candidate with 15-30 minutes to ask about whatever they may want to know, and then let them go destress. If you’re still looking for more signal then the process will be extended a bit longer, accounting for the questions you want to answer. The candidate will still have 15-30 minutes to learn more about your company, but you’ll also have 30-45 minutes to learn more about the candidate. You may want to clarify a response the candidate gave, which is easy to do with them still here. If you didn't get a good read on their product design skills, have an exercise prepared where they'll need to go in depth a little more. If it was the high level architecture discussion then ask them to design a slightly more complicated system. If you weren't sure about their feature development, work to expand upon what you built in the last session. Like every interview process both sides are trying to leave with as few open questions as possible, so use this time to close out any open doors. Following Up While a high signal interview process is unsurprisingly about getting a lot of signal in a short period of time, it’s also one that aims to have candidates and companies be respectful to each other in the process. A good interview process is only made better when a candidate receives an answer in a timely manner. Once the interview has wrapped up it's ok to take some time to figure out your thoughts, but don’t take too long. If the process went as expected the interviewers should have a good idea about whether they want to hire a candidate after the third interview, so all that’s left is to figure out the specifics. It’s not unreasonable to come out of an interview to pressing work but it’s important to close this loop, try to make an official call by the end of the day (or early the next day if the interview took place in the afternoon) so the candidate will remember this process favorably no matter the result. And that's it. This process is quick, has depth to it, and provides a much more accurate feel for what working with a person is like than a whiteboarding exercise. It's a flexible enough approach that you can tailor the interviews to your company's needs, and I would highly recommend doing so, reevaluating what's working and what isn't. We should always be reevaluating our interview processes because talent evaluation isn't easy and needs change as a company and the industry move forward, so if you have ideas for improvement I’d love for you to share them with me. This post was surprisingly difficult to write in a clear and concise manner without making a formal write up feel so formal, and not losing the message by being too informal. It really took a village so thank you to the plethora of people who helped by providing feedback and editing my drafts, most notably Tamar Nachmany, Amro Mousa, and Brian Michel. There are a lot of tradeoffs when it comes to interviewing around preference, fairness, complexity, bias, and more. To be upfront I won't cover any of that in this post, but know that they were considered, and some are listed in the appendix below. I have another post planned about how every interview process is flawed and biased, but for now the most important thing to keep in mind is that every interview process, whether it's a take home project or writing code on a whiteboard provides both sides signal, but comes with tradeoffs Tradeoffs are a necessity because there’s no fair way to evaluate in only a few hours what working with a candidate or a company will look like for the next few years, so it's important to acknowledge as a company which tradeoffs you're willing to make. Caveats, Disclaimers, and Footnotes This is written from the perspective of a company, but all of these considerations are just as important to a candidate understanding a company they hope to work at for a long time. Hiring criteria differs, for example sometimes you need to hire the best applicant available vs. hiring someone who can do the role, so you should be flexible and define that ahead of time. This may not work for your startup, this may not work for a big tech company! But I believe it's a process worth considering if your company is one where engineering, product, design, and other organizational functions are expected to work well together. Assume that this is an on-site interview, something that may be less common right now, especially with the rise of remote work. The process should still be doable in a remote setting, but there may be some adaptations necessary. ↩

Tell me who you are in 160 characters. I'll wait while you try and achieve the level of nuance necessary for the task. This constraint is why you end up with generic Twitter bios that don't tell you much about someone and all look like:

Father, cyclist, biz-dev, and fighting every day for the Quebec sovereignty movement. Working on saving democracy @Meta, ex-Palantir, ex-Accenture, ex of my ex.

Kinda hard to stand out, right? The inability to differentiate yourself on a platform built upon self-expression has always felt surprising to me, so I started to look for alternative means of letting people get to know more about me. The most common approach to gain additional room for expression is to use Twitter's Website field, linking out to a more information-rich bio. But that jump to the web is an opportunity to lose focus, especially in a world where nobody has the attention span to read (or leave Twitter). There are even solutions like Linktree that build upon the link to link to a link of links, letting those links speak for you.

Tell me who you are in 160 characters. I'll wait while you try and achieve the level of nuance necessary for the task. This constraint is why you end up with generic Twitter bios that don't tell you much about someone and all look like: Father, cyclist, biz-dev, and fighting every day for the Quebec sovereignty movement. Working on saving democracy @Meta, ex-Palantir, ex-Accenture, ex of my ex. Kinda hard to stand out, right? The inability to differentiate yourself on a platform built upon self-expression has always felt surprising to me, so I started to look for alternative means of letting people get to know more about me. The most common approach to gain additional room for expression is to use Twitter's Website field, linking out to a more information-rich bio. But that jump to the web is an opportunity to lose focus, especially in a world where nobody has the attention span to read (or leave Twitter). There are even solutions like Linktree that build upon the link to link to a link of links, letting those links speak for you. There are plenty of hacks one can imagine using, more advanced users have taken to pinning an “intro thread”, but what I was looking for was an option that would let me be more expressive than a bio, felt eloquent, and was native to Twitter. That's when I remembered the humble Twitter carousel. You may have seen carousels serving you ads for apps or services that everyone is excited about like… VMWare Cloud. But did you know that Twitter's advertiser tools are available to everyone, without having to pay a penny? 1 That's right, you a regular Twitter user can have the same capabilities as a company that pays Twitter millions of dollars per year. I'm going to show you how to take advantage of them so you can stand out just like household brands such as Disney, Nike, and of course… VMWare. Who's That Handsome Guy? About Me About Me — ✨  Joe Fabisevich  ✨ (@mergesort) February 19, 2022 I've always debated whether my bio should link to my home page, my About Me page, or the best posts I've written. Thanks to the carousel I no longer have to choose, and I'm able to put all three front and center. The flexibility of having six links means I can also guide people to the office hours I host, and have room to spare for another link or two.2 As importantly as taking the time to construct the tweet is remembering to pin it, that way anyone who comes to my Twitter account has this information visible immediately. Do you love red pandas? Love apps? Find out more about what we do! — The Red Panda Club (@redpandaclub) February 19, 2022 A brand can get really creative by linking to their homepage, their support page3, FAQs, App Store apps, and a whole lot more. The carousel is also a medium to play with, you can use custom artwork to show off your brand's style, which in my case is playful and silly. I created a tweet carousel for my indie development company Red Panda Club as a proof of concept, and pinned it to the top of the @redpandaclub Twitter account. Building Your Carousel The process for building your own Twitter carousel is hidden away, but surprisingly easy. Head over to ads.twitter.com and look in the navigation bar for a menu titled Creatives. Under Creatives you'll find a menu item titled Tweet Composer, this is unsurprisingly what you'll want to compose tweets. The URL will look something like ads.twitter.com / composer / XXXXX /carousel, where the XXXXX will be a random set of letters and numbers. You may run into various popups asking for more information, feel free to ignore ‘em! The only popup you’ll see that you have to fill out is one asking you to setup a payment method and campaign to unlock a Creatives menu. 1 (You really don't have to pay Twitter anything to use the tools but you do need to have a credit card on file to use the Ads Tweet Composer.) And that's actually it, there's no real step 2 beyond composing your tweet. But to save you some time I'll mention a few things that may seem unintuitive. A) Your first step for customizing the carousel is to add media. You can't start creating a card by updating the website destination; that will only appear after you've chosen media for your carousel. B) Website cards can customize the text that displays under a card's image, but app cards always display the app name and app category under the image. C) You’ll be asked to choose an app carousel or a web carousel, but don’t let that think you can't make one that mixes the two together. To do this you'll need to choose a website carousel and for any app you want to add you'll use your app's App Store or Google Play URL and manually upload your app's icon. D) The Tweet Composer will default to making your tweet Promoted Only. If you want the composed tweet to show up on your profile timeline remember to uncheck the Promoted Only checkbox. It's worth noting that a Promoted Tweet is a real tweet, but you’ll only be able to find the tweet’s URL in the Twitter Ads dashboard. E) Cards do not render in third-party clients4, so if that's important to you I recommend including text and links in the body of the tweet. It doesn't look as good in native Twitter clients so it's your choice whether to prioritize this or not. Now that you know how to build a fun carousel, I'd love to see you get creative. I can't wait to see what kind you come up with. 🎠 To add a payment method: Click the Create an ad button. You may be prompted to confirm your timezone, then click Let's go. A popup will display asking you to Choose your objective. Exit this screen by clicking the cancel button in the bottom right corner of the screen. In the top right corner you will see your account name, clicking it will show a dropdown option that says Add new payment method. Add a credit or debit card and from now on you should see the Creatives menu that you need to access the Ads Tweet Composer. ↩ I expect these links to change so I'm not particularly attached to them, and if I ever do change them I can always post an updated tweet. Alternatively using a link shortener is a good strategy for not having to change the underlying data.↩↩ Twitter doesn't let website carousels link to custom URL schemes so I got a little creative with my support link. Using my redpanda.best URL shortener I linked to a page who's contents contain <body onload="javascript: window.location.href= 'mailto:abc@mywebsite.com'; ">, to work around the fact you can't use a mailto: URL.↩↩ Unfortunately the underlying cards these carousels are built on aren’t exposed in the v2 third-party API tweet payload, so they can’t be rendered in them.↩↩

The work of writing maintainable code is an ongoing endeavor and some of my favorite problems to solve are ones that build maintainable systems. Maintainable systems are ones you can learn once, easily manipulate, and ideally take from project to project. My favorite part of building maintainable systems is that it minimizes the amount of work I need to do when starting a new project, and like it is for many programmers hitting ⌘ + ⇪ + N to start a new project is one of the most satisfying feelings in the world for me.

The work of writing maintainable code is an ongoing endeavor and some of my favorite problems to solve are ones that build maintainable systems. Maintainable systems are ones you can learn once, easily manipulate, and ideally take from project to project. My favorite part of building maintainable systems is that it minimizes the amount of work I need to do when starting a new project, and like it is for many programmers hitting ⌘ + ⇪ + N to start a new project is one of the most satisfying feelings in the world for me. A color palette is something every well-designed app needs, and it turns out there are a lot of ways to solve this problem. If you don't yet have a good sense for how to construct a color palette, I highly recommend this post by Refactoring UI that explains the fundamentals of a good color palette. Generating a good color palette can be tricky if you’re new to the practice and can require some trial and error, so if you’d like a shortcut a tool like Coolors is a great starting point. I've spent years iterating on approaches to codifying color palettes in my iOS and macOS apps, seeking to create one that’s flexible, scales well, and is easy to understand, landing on the version we’ll explore below. We'll be able to leverage asset catalogs, create a clear sense of hierarchy, provide statically typed semantic colors, even take advantage of the built in features of SwiftUI. As a bonus, if you're working with designers, your palette will be so straightforward to modify that a designer can submit a pull request to change colors without ever involving you. Considering we'll be leveraging asset catalogs, the first step should be pretty intuitive, we should create an asset catalog to hold our color palettes. As I was piecing together different instructions and ideas this second step confused me, so I'll spare you the misery. You're going to want to make a different folder for each color palette you create, and you can do that by right clicking in the asset catalog and selecting New Folder. Now it's time to create our color palettes. I'm showing you the Night palette I created for my app, and below it are Spring, Summer, and Winter. Each palette has the same name but all of the colors are named the same, each palette will have colors named background-alt, primary, quaternary, etc. Do not miss this incredibly important step, guide your eyes towards the pink arrow on the right side of the image. You must select the folder you're adding colors to and check the Provides Namespace checkbox. This is what will enable our code to have a clear and consistent naming structure, matching the folder’s name to our palette's name. Now that we've got our asset catalogs setup, we're ready to write some code. We'll start by constructing a new Palette struct, and populating it with some Colors that we'll reference across our app. extension Color { struct Palette { let name: String var mainBackground: Color { Color(fromPalette: self.name, semanticName: "background-main") } var midBackground: Color { Color(fromPalette: self.name, semanticName: "background-mid") } var alternativeBackground: Color { Color(fromPalette: self.name, semanticName: "background-alt") } var primaryText: Color { Color(fromPalette: self.name, semanticName: "text-primary") } var alternativeText: Color { Color(fromPalette: self.name, semanticName: "text-alt") } var primary: Color { Color(fromPalette: self.name, semanticName: "primary") } var secondary: Color { Color(fromPalette: self.name, semanticName: "secondary") } var tertiary: Color { Color(fromPalette: self.name, semanticName: "tertiary") } var quaternary: Color { Color(fromPalette: self.name, semanticName: "quaternary") } } } This is a pretty standard palette and should cover most of the use cases you'll encounter in building an app. You can modify it to your needs, but the important thing is that the colors you choose need to match the names of the colors you declared in your asset catalog. But what is this Color(fromPalette:semanticName:) initializer? private extension Color { init(fromPalette palette: String, semanticName: String) { #if os(macOS) self.init(NSColor(named: "\(palette)/\(semanticName)")!) #else self.init(UIColor(named: "\(palette)/\(semanticName)")!) #endif } } You can just as easily use a private method in Color.Palette, something like private func assetCatalogColor(semanticName: String). I happen to prefer the ergonomics of a custom initializer, and this whole post is about improving ergonomics, so let's run with that. This initializer lives in Color.Palette and takes advantage of our namespaced folder structure to pull out colors from the asset catalog. palette unsurprisingly is the name of our color palette, and semanticName is the name of the color we're pulling out of it, such as primary, secondary, or background-main. Combining the two with a /, we'll get the primary, secondary, or background-main color from our current palette. All that's left is to define the palettes we'll be constructing. extension Color.Palette { static let spring = Color.Palette(name: "Spring") static let summer = Color.Palette(name: "Summer") static let autumn = Color.Palette(name: "Autumn") static let winter = Color.Palette(name: "Winter") static let day = Color.Palette(name: "Day") static let dusk = Color.Palette(name: "Dusk") static let night = Color.Palette(name: "Night") } Constructing palettes is pretty easy. All you have to do is instantiate a Color.Palette object with a name. That name must match the folder name, so in my app the palette name for Night will be Night because the folder we chose for that palete was "Night". Now that we have a color palette created, we should probably start using it. If you're using UIKit you'll likely have built your palette atop UIColor instead of Color and used .palette.primaryText wherever a UIColor is expected. But if we're building our app in SwiftUI, we can go the extra mile with just a few lines of code to leverage the Environment, making our palette easily accessible and SwiftUI-friendly. private struct ColorPaletteKey: EnvironmentKey { // We need to default to a palette so without any particular preference let's pick `day` static let defaultValue = Color.Palette.day } extension EnvironmentValues { var preferredColorPalette: Color.Palette { get { return self[ColorPaletteKey.self] } set { self[ColorPaletteKey.self] = newValue } } } This creates the preferredColorPalette property in our Environment. If you're not sure how the Environment works there are a lot of great resources on the internet like this post by Keith Harrison. struct HeaderView: View { @Environment(\.preferredColorPalette) private var palette var body: View { Text("Hello World") .foregroundColor(palette.primaryText) } } Now accessing our colors is a nothing more than two lines of code, how slick is that? Hope I didn't wear you out, there's a lot here, but when you throw it into Xcode you'll see that it's pretty easy to digest. After a few iterations I'm really happy with this solution and have been using it in my personal apps for a while now. It allows us to easily add or change colors, have a visual representation of our colors, with minimal code, and a pretty slick API. But no code is perfect (except for mergesort), so I'm always looking for improvements. I'm excited to hear your thoughts or suggestions, so don't be shy about reaching out.

For a long time I've told people that I love technology and all it enables, yet dislike the technology industry and working in tech. People often find my statement hard to rectify, probably because they see the two as inextricably linked. Technology is an ever-changing process, one that pushes humanity forward through the application of science, and the industry has become (and arguably always has been) about capitalizing those mechanisms of change.

For a long time I've told people that I love technology and all it enables, yet dislike the technology industry and working in tech. People often find my statement hard to rectify, probably because they see the two as inextricably linked. Technology is an ever-changing process, one that pushes humanity forward through the application of science, and the industry has become (and arguably always has been) about capitalizing those mechanisms of change. The tech world today is capitalizing those innovations at an unprecedented rate. That's why the tech sector is the most dominant and rapidly advancing industry in history. That's also what makes it so difficult to express the discord between the progress people see and the disproportionate impact it has. People see the progress of technology in real time, and they only see the moral and ethical issues with the rapid advancement of technology after that technology has established a role in people's lives. No one had any problems with Facebook in 2012, but they sure do now. Why Is This Happening? Many solutions invented today are about replacing existing solutions with more efficient ones. That feels like it should be an undeniable good. What happens when you create a technology that gives you everything you had before, cheaper, faster, and with even more improvements and features — but only addresses 99% of the problems? That's what you're seeing play out in the tech sector today. Companies are built on efficiency gains, but they don't have to pay the cost of the inefficiencies they create. They're not punished for the externalities they cause. As long as you're not feeling the burden, if you're not in the 1% for whom the new technology is a worse experience, you see nothing but progress and get to reap its benefits. But those who bear the cost are shut out from the new experience or improvement in their lives. Often times they're not only shut out, but as the world modernizes and standardizes around these solutions, those people are falling behind through the inequities of being a have-not in a system where almost everyone else is a have. Technology For Good, Not Always So Machine learning is an amazing technology, it shows us what we always could have known if we were smart enough to spot patterns in enormous data sets. It's helping fight cancer, it's helping people who can't speak have a voice, it's helping power the recommendation engines that give us the answers we need to get through the day. But what happens when machine learning makes a mistake? What happens when the system you've built increases racial bias? The most common use of machine learning seems to be reshaping our interactions around algorithms that want to optimize us as consumers. There's no manager to talk to, there's no one who can look into this black box, there are few companies who will turn off their models that work for 99% of people. At the scale of millions, incorporated into our lives, these technologies that make the world a better place are making some people's lives worse. Cryptocurrency is having a moment, especially as billionaires bored during a pandemic have started shoveling money into NFTs. Is there a need for a global censorship-resistant currency? I'm not smart enough to say, but I can see the allure and benefits that drive crypto enthusiasts to push for it.1 What I am smart enough to say is that the environmental impact of cryptocurrencies is a nightmare. Supporters will say "just wait, Proof of Stake will solve these problems", and they're probably right. But PoS was introduced in 2012 and it's still not here in 2021. We're living in a Proof of Work world, why is it people bearing the costs who have to wait? How about when you've fixed your problems you can come back and try again. How much unnecessary damage to the planet has been done in the last 9 years in the name of advancing a technology? I'm not here to pick on machine learning and cryptocurrencies, these problems of unaccountability are systemic. Uber is an amazing innovation in global transport built on already existing infrastructure, except to the drivers. Amazon provides unprecedented logistics, letting you have anything you could ever want in two days, built on the backs of real human beings. Twitter is a real-time archive of human history, except it globalizes and nationalizes local issues, and disproportionately exposes marginalized communities to abuse and harassment. What technologists optimize for is an explicit choice that’s made, even if the tools we use to do so render opaque results. So much of engineering is focused on the concept of minimizing friction, but minimizing friction is almost always focused on short-term benefits because that’s what feels most rewarding. This is echoed by people who decry the death of investing in infrastructure, and as a society we seem to be trading our long term costs for short term happiness. We’re letting technology go down the same path, even using it to accelerate that trend. Like any technologist knows technical debt eventually gets paid off, either by choice or by circumstance. What’s To Come The list goes on, and will continue to go on until there's a cost associated with making mistakes. Existing incentive structures in our society and economy don’t factor in a price for the externalities of building something that causes damage, even if that damage is only borne by a small percentage of people. At the scale technology operates at, edge cases are millions of people. The sheer awesomeness of technology can lure you into a sense of moving forward. It may feel that the ends justify the means, that you're doing the right thing at a small cost. You too are creating or experiencing the advancement of humanity through technology, like billions have felt before us. But as they say, history is written by the victors, the people who are worse off through our advancements as always are being forgotten and erased. The drive to continue growing leaves little time for fixing mistakes when there's another frontier to capitalize. That only makes it harder for people who are left behind to be brought forward. We need to do better to understand not only the benefits, but to explore the costs of a new technology. The costs are real, and are felt by real people. I wish that by the end of my post we’d found a solution, but unfortunately systemic issues aren't fixed by meandering thoughts. The most I can ask you to do is to think about the externalities of your actions, to not accept new technology into your life without considering the tradeoffs, and to hold those building them accountable — the same way you would if it was your life being impacted negatively. Not that anyone asked for my opinions on censorship-resistance currency, but I do think the goal in a vacuum is laudable. Despite that I think people underestimate the value of tried and true banking systems that have been operating for over 600 years. I suspect much of the antipathy towards banks is actually people’s understandable disgust at our current financial system. I don’t see how cryptocurrencies fix that, and in many ways by not having the promises of banks only make it worse.↩↩

GraphQL has been on my list of technologies to learn for a few months now, and last week I came across Majid Jabrayilov's post, feeling pretty excited to tackle the subject. The post was very good, but it didn't answer the one question I've had as I've gone through numerous exercises to understand GraphQL, how do I make GraphQL requests without a library?

GraphQL has been on my list of technologies to learn for a few months now, and last week I came across Majid Jabrayilov's post, feeling pretty excited to tackle the subject. The post was very good, but it didn't answer the one question I've had as I've gone through numerous exercises to understand GraphQL, how do I make GraphQL requests without a library? I've read about how to create a GraphQL query and how to integrate GraphQL on your server a dozen times, but one topic that's highly under-covered is how to make a GraphQL request from the client. In the world of GraphQL it's very common to reach for Apollo, a library that handles turning GraphQL queries into functions, leveraging tooling to turn those functions into type-safe API requests the client can make. While this is a perfectly reasonable approach, and actually a pretty good developer experience, it still didn't answer the questions I had as an ever-curious engineer, how would I do this on my own? I broke the problem I saw down into two smaller problems, request-generation and request-making. Generating a request, especially in Swift, it turns out is pretty easy. I really like the approach that SociableWeaver takes, leveraging Swift's function builders to let you build a type-safe directly in Swift. The second problem was a bit fiddlier. I knew that I had to make a POST request, and I knew the endpoint that was being hit, and through some trial and error (and a friend's help1), I was able to start making GraphQL requests without any external libraries needed. extension URLSession { func graphQLRequest(url: URL, query: String) -> URLSession.DataTaskPublisher { var request = URLRequest(url: url) request.httpMethod = "POST" request.addValue("application/json", forHTTPHeaderField: "Content-Type") let body = """ { "query": "\(query)" } """ let queryData = body.data(using: .utf8) request.httpBody = queryData return self.dataTaskPublisher(for: request) } // If using SociableWeaver or a similar GraphQL query generator, you can do it in a type-safe manner. func graphQLRequest(url: URL, query: Weave) -> URLSession.DataTaskPublisher { return self.executeGraphQLQuery(url: url, query: query.description) } } After looking over the above code a few times I realized that the majority of it was handling the creation of a URLRequest. That served as a hint to me that we could refactor the code into a custom URLRequest initializer. This would be less prescriptive about how the URLRequest is used, since my first code snippet assumes you always want to return a URLSession.DataTaskPublisher. extension URLRequest { init(url: URL, graphQLQuery query: String) { self.init(url: url) self.httpMethod = "POST" self.addValue("application/json", forHTTPHeaderField: "Content-Type") let body = """ { "query": "\(query)" } """ let queryData = body.data(using: .utf8) self.httpBody = queryData } // If we're going all in on SociableWeaver we can make a similar initializer that takes a `Weave` parameter instead of a `String`. } Now if you'd like to use URLSession.DataTaskPublisher you're free to by creating a URLRequest from our new initializer and using it, but you can also return a URLSession.DataTask or any other reason mechanism that involves a URLRequest. extension URLSession { func graphQLRequest(url: URL, query: String) -> URLSession.DataTaskPublisher { let request = URLRequest(url: url, graphQLQuery: query) return self.dataTaskPublisher(for: request) } func graphQLRequest(url: URL, query: Weave) -> URLSession.DataTaskPublisher { return self.graphQLRequest(url: url, query: query.description) } } That looks a lot cleaner, and our responsibilities seem a lot more well-divided. Is there room for tools like Apollo? Absolutely! I'm not going to pretend that my dozen lines of code replaces the value that a multimillion dollar company provides. (I'll only make sick jokes about it.) But before importing a library like Apollo, any library really, it's worth asking yourself whether you need a big solution for a small problem. Or maybe question the better question to ask before that is, have you really understood the problem you're trying to solve? But we still haven't really answered where exactly we should put the U in GraphQL. (I say after the Q since Q is almost always followed by U, but I'm open to feedback on that or the rest of this post.) Special thanks to Dave DeLong for his debugging prowess.↩↩

Apple's been in the news quite a bit lately over concerns that many apps on the App Store are little more than scams. Some of these apps aren't even functional, they don't provide anything more than a screen with no functionality, only a button to purchase an indefinite weekly subscription. Many developers and consumers are confused or surprised that Apple isn't catching these scams, given Apple has a process for App Review which every app must go through, and while I'm not surprised given the breadth of the problem, I find myself thinking it's very problematic for the digital economy and consumer confidence in buying services through what once was considered a safe place.

Apple's been in the news quite a bit lately over concerns that many apps on the App Store are little more than scams. Some of these apps aren't even functional, they don't provide anything more than a screen with no functionality, only a button to purchase an indefinite weekly subscription. Many developers and consumers are confused or surprised that Apple isn't catching these scams, given Apple has a process for App Review which every app must go through, and while I'm not surprised given the breadth of the problem, I find myself thinking it's very problematic for the digital economy and consumer confidence in buying services through what once was considered a safe place. Twitter, the company I work for, deals a lot with content moderation. I'd argue it's the largest existential threat to the company. Whether Apple likes it or not they've walked into the same position with the App Store. This may be news to them, having spent decades curating all sorts of content from music to workouts, but as the App Store has grown, they now serve billions of customers and work with millions of developers. Those developers are creating content that Apple has little control over, other than acting as a gating mechanism, and so their ability to exercise control over that content has diminished significantly. Let’s skip past the debate about whether or not Apple should have this much level of control or whether the system needs to be reformed. Instead I'd like to talk about where I think Apple can patch the cracks in a broken App Store, before it breaks itself apart or is broken apart from the outside. The App Store Apple treats every developer the same (😉), or at least let's say so for the sake of this argument.1 From my own work, what I've seen is that when you don't have any way of validating whether someone is a good actor or bad actor, the reasonable default assumption is that everyone is a bad actor, and that's how Apple treats developers. This leads to many false negatives and false positives, good developers getting much more scrutiny than they should, and bad developers sliding through when they are in need of scrutiny. There's no thorough process for validation, there's no process for restorative justice, only Apple doing their best to remain hyper-vigilant at all times, and accepting the human errors that come along with that. While you can't eliminate bad actors, they're always going to exist in any system, what you can do is minimize the total bad actor surface area, and minimize the effects of these bad actors. A simple equation: if you treat 100% of developers as potential threats, there's no way to avoid hyper-vigilance, but if you only have to watch out for 20%, then you can be five times more efficient at rooting out bad behavior such as scams. So we need a way to let bad actors tell us that they're bad? No, we need a way for good actors to signal to us that they're good, leaving everyone else in questionable territory. Apple needs an internal scoring system to know where to devote their investigative resources. If you don't need to pay attention to the well-meaning app developer trying to make an honest buck, you can devote more resources, or your limited resources to the people who haven't done the work to show that they're good actors. Incentive Design Let’s take a step back to understand our friend from the world of behavioral economics, incentive design. To quote liberally: An incentive is something that motivates an individual to perform an action. It is therefore essential to the study of any economic activity. Incentives, whether they are intrinsic or extrinsic (traditional), can be effective in encouraging behavior change, such as ceasing to smoke, doing more exercise, complying with laws or increasing public good contributions. Traditional incentives can effectively encourage behavior change, as they can help to both create desirable and break undesirable habits. I don't have all the answers for fixing the App Store, but I don't think you need all the answers up front to start improving the system. Taking what we learned about incentive design above, what I see Apple having is a resource allocation problem due to them not knowing who’s complying with the rules and contributing to the public good. With that in mind, a scoring system is where I would invest resources to know who’s having a net-positive and a net-negative effect on the App Store system. There can be many contributors to this scoring system. Right now reviews and downloads are already used, but they are gameable due to their public nature, an example of poor incentive design. Surely new metrics can be added, such as how many times they've passed the scrutiny of app review, or how closely the instructions a developer gives match the reviewer's expectations. While those are relatively weak signals, Apple surely has dozens if not hundreds more internal signals they can apply to understanding a developer’s net outcome on the App Store. And yet I think there's room for a much stronger signal. App Store Preview App Store Preview would work similar to Apple's current DTS system, where you can get hands-on help with a technical problem you're having. A developer should be able to get pre-approval for an idea2, in the context of their application, without having to build an entire feature (or application) before App Review deems it worthy. This would also provide context for future reviewers, knowing what to look for and what's changed. The more a pre-approved version matches the reviewer's expectations come review time, the higher the score would the developer would receive. The higher their overall score over time (by some to be established scoring mechanism), the less scrutiny they would receive in the future. More importantly though is the inverse. If someone doesn't go through review, they implicitly receive more scrutiny. Bad actors will be disincentivized to have their app in Apple's hands for longer, and to be put under a microscope. This aversion makes them inherently less trustworthy, and would lead to them getting more scrutiny in the future. By letting good actors prove they're good actors, we've isolated the bad actors to show their cards and prove through implicit means that they're not good actors. This wouldn't fix the mistakes that App Review makes, and bless them, it's a very tough job. This doesn’t even solve many of the App Store's problems, it’s only one idea and there are many other problems that Apple needs to solve. But it does show that Apple has lots of levers to pull when designing resilient systems, and can lay the foundation for a system where Apple can trust developers. And that's increasingly necessary for maintaining the consistency quality Apple, developers, and customers all want for the App Store. As always, I’m excited to hear your thoughts, and am receptive to feedback, so if you want to talk don't be shy about sending me a trustworthy tweet. To paraphrase George Orwell, "all developers are equal but some are more equal than others."↩↩ Given this is time intensive, you could make validation finite, maybe 2-4 tickets per year, or even have a system where people can pay for more tickets to have more previews, something that would surely be valuable for many developers and Apple.↩↩

I recorded an episode of the Empower Apps podcast, where Leo Dion and I discussed a wide range of topics. We spoke about everything from how we scale app development to thousands of people and millions of users at Twitter, communication, documentation, people working together, and a lot about and the complexity of holding moral frameworks at a global level.

I recorded an episode of the Empower Apps podcast, where Leo Dion and I discussed a wide range of topics. We spoke about everything from how we scale app development to thousands of people and millions of users at Twitter, communication, documentation, people working together, and a lot about and the complexity of holding moral frameworks at a global level. Empower Apps: Large Scale Teams with Joe Fabisevich Original recording

I've been thinking about privacy lately. No, not online privacy, but about how APIs can balance exposing the right amount of implementation details without revealing too much.

I'll walk through a task I find myself doing often when building iOS apps, creating a view controller with header view, and four different ways to go about it.

I've been thinking about privacy lately. No, not online privacy, but about how APIs can balance exposing the right amount of implementation details without revealing too much. I'll walk through a task I find myself doing often when building iOS apps, creating a view controller with header view, and four different ways to go about it. Regular View Configured as a Header SettingsViewController.swift final class SettingsViewController: UIViewController { private let headerView = UIView() private let tableView = UITableView() override func viewDidLoad() { super.viewDidLoad() self.view.addSubview(self.tableView) self.setupTableView() self.configureHeaderView() } func setupTableView() { self.tableView.translatesAutoresizingMaskIntoConstraints = false NSLayoutConstraint.activate([ self.tableView.leadingAnchor.constraint(equalTo: self.view.leadingAnchor), self.tableView.trailingAnchor.constraint(equalTo: self.view.trailingAnchor), self.tableView.topAnchor.constraint(equalTo: self.view.topAnchor), self.tableView.bottomAnchor.constraint(equalTo: self.view.bottomAnchor), ]) } func configureHeaderView() { // Some code configuring self.headerView // ... // ... self.tableView.tableHeaderView = self.headerView } } For folks new to iOS development, this is a common approach I see when adding a header. It makes sense, you want to have a header, and a header is a view, so why not configure and style UIView to be the UITableView header. While this is a good first try, it lacks the encapsulation that makes your code easy to edit and reason about. Separate Class For The Header SettingsViewController.swift final class SettingsViewController: UIViewController { private let headerView = SettingsTableHeaderView() private let tableView = UITableView() override func viewDidLoad() { super.viewDidLoad() self.view.addSubview(self.tableView) self.setupTableView() self.tableView.tableHeaderView = self.headerView } } SettingsTableHeaderView.swift final class SettingsTableHeaderView: UIView { // Some code creating and configuring SettingsTableHeaderView // ... // ... } A naive approach to improve our readability would have been to move our configuration code into a function, but an even nicer improvement is to move it into its own class. This looks a lot better, it's easier to reason about and it's well-encapsulated. But a new problem this introduces is adding SettingsTableHeaderView into our module’s namespace. Now I'll admit this isn't the world's biggest problem, but as you start adding different view controllers with different headers, suddenly finding the right header view for a given view controller becomes difficult. Private Class for the Header SettingsViewController.swift final class SettingsViewController: UIViewController { private let headerView = HeaderView() private let tableView = UITableView() override func viewDidLoad() { super.viewDidLoad() self.view.addSubview(self.tableView) self.setupTableView() self.tableView.tableHeaderView = self.headerView } private final class HeaderView: UIView { // Some code creating and configuring SettingsViewController.HeaderView // ... // ... } } Now this is a solution that I'm really liking. We've moved SettingsTableHeaderView out of our module’s namespace and into one dependent on the context it's in, SettingsViewController. When referring to SettingsViewController.HeaderView inside of this class we can plainly refer to it as HeaderView, which is not only less verbose, but emphasizes the pairing between HeaderView and SettingsViewController. There is a downside to this approach though, the more views we add to SettingsViewController, the harder this file becomes to parse. Now again this may not seem like a big problem, but if you have a well encapsulated view, you may have many subviews that belong to either SettingsViewController or HeaderView, and your file can get pretty large. (Trust me, I’ve seen written some pretty large files.) Two Files with Namespaced Internal Classes SettingsViewController.swift final class SettingsViewController: UIViewController { private let headerView = HeaderView() private let tableView = UITableView() override func viewDidLoad() { super.viewDidLoad() self.view.addSubview(self.tableView) self.setupTableView() self.tableView.tableHeaderView = self.headerView } } SettingsViewController.HeaderView.swift extension SettingsViewController { final class HeaderView: UIView { // Some code creating and configuring SettingsViewController.HeaderView // ... // ... } } This is the approach I've settled on today. You'll notice that HeaderView is no longer private, but it's also not particularly easy to access publicly. You still end up with the benefits from namespacing the API, and this extension can go into its own file, unlike the earlier approach. If you were to accidentally misuse this API, it would be pretty clear. When calling HeaderView inside of SettingsViewController the call-site is clean and simple. But if someone were to attempt to use it from another class, they would have to reference the fully-qualified type, SettingsViewController.HeaderView. While I’ve walked through one example with four approaches, binding a type to its context is something you can do throughout a codebase. In an ideal world Swift would have a submodule keyword to make types less ambiguous, but in the mean time this is a reasonable substitute that developers can take advantage of. While we don’t have a submodule keyword, we have a close approximation by using empty enums. One notable example is Combine’s usage of Publishers and Subscribers to help people have context and understanding for their subtypes. As always, I’d love to know what you think or if you’ve come up with better solutions, so please don’t be shy about reaching out. Special shoutout to Jasdev for taking a very rough first draft and helping me turn it into something coherent.

If you haven't checked out Part I, I recommend reading it because if you don't, none of writing below will make sense!