DEV Community: Artem Novichkov

Custom @Environment value for share actions

Artem Novichkov — Mon, 15 Feb 2021 18:24:10 +0000

SwiftUI has a lot of modern and useful features. One of my favourite is @Environment property wrapper. It allows you to get system-wide settings, for instance, current locale or color scheme. Since iOS 14.0 you can use openURL value to open URLs from apps easily.

@available(iOS 14.0, macOS 11.0, tvOS 14.0, watchOS 7.0, *)
extension EnvironmentValues {

    /// Opens a URL using the appropriate system service.
    public var openURL: OpenURLAction { get }
}

With just a one line of code you can extend behaviour of you views:

import SwiftUI

struct ContentView: View {

    @Environment(\.openURL) var openURL

    var body: some View {
        Button("Share") {
            openURL(URL(string: "https://blog.artemnovichkov.com")!)
        }
    }
}

I was wondering how it works under the hood and tried to implement the same trick for sharing activity items with UIActivityViewController. Let's check the result!

Keys and values

At first we should create a custom key, conform to EnvironmentKey protocol and set a default value. It will be an empty struct for now:

struct ShareAction {}

struct ShareActionEnvironmentKey: EnvironmentKey {

    static let defaultValue: ShareAction = .init()
}

Next, we should extend EnvironmentValues to make our ShareAction be available from the environment:

extension EnvironmentValues {

    var share: ShareAction {
        self[ShareActionEnvironmentKey]
    }
}

The last thing is adding callAsFunction in ShareAction struct to use the same syntax:

struct ShareAction {

    func callAsFunction(_ activityItems: [Any]) {
        let vc = UIActivityViewController(activityItems: activityItems, applicationActivities: nil)
        UIApplication.shared.windows.first?.rootViewController?.present(vc, animated: true, completion: nil)
    }
}

Unfortunately, there is no SwiftUI-way to open this controller. If you use a better way, let me know!

To read more about callable values of user-defined nominal types, check SE-0253 proposal on Github.

That's it, now we can use .share value and share activities from any view:

import SwiftUI

struct ContentView: View {

    @Environment(\.share) var share

    var body: some View {
        Button("Share") {
            share([URL(string: "https://blog.artemnovichkov.com")!])
        }
    }
}

Related Resources

The final code is available here, and there is a list of related articles:

iOS 13 Dark Mode

Artem Novichkov — Sat, 11 Jan 2020 09:41:17 +0000

In iOS 13.0 and later, users can choose to adopt a dark appearance called Dark Mode. In Dark Mode, apps and system use a darker colors for all screens, controls and views. Users can select Dark Mode as their default interface style, and can use Settings to make their devices automatically switch to Dark Mode when ambient light is low.

In this article I'll describe Dark Mode support in third-party apps with(out) storyboards, highlight handy debugging tools and try to implement Dark Mode updating inside the app without overhead.

All my examples from this article are available in DarkMode project. This small framework is a result of my research and a place for experiments with Dark Mode. Please feel free to open it and play with examples.

Note: in this article I'll tell about UIKit, not SwiftUI. The main goals of my research were practical use and backward compatibility.

Implementation

Dark mode appearance is based on trait collections. When the user changes the system appearance, the system automatically asks all windows and views to redraw its content. UIKit controls support it out of the box without additional logic. Let's start with colors.

Color appearance

To configure app colors with different appearances, you can use Asset Catalogs. Just create a New Color Set and add required colors. If you want to improve app accessibility, you can add high contrast color variant for every color:

In storyboards these colors are available in Named Colors section during color selection. To use it in code, just initialize it with the given name:

let view = UIView()
view.backdroundColor = UIColor(named: "Color")

Note: I recommend that we use code generation tools for it to prevent silly crashes after renaming or refactoring.

If you don't want to use Asset Catalog for some reason, you can configure colors directly via UIColor.init(dynamicProvider:) initializer. It returns different colors based on trait collection properties. I've added an extension to reduce SDK version checks:

import UIKit

public extension UIColor {

    /// Creates a color object that generates its color data dynamically using the specified colors. For early SDKs creates light color.
    /// - Parameters:
    ///   - light: The color for light mode.
    ///   - dark: The color for dark mode.
    convenience init(light: UIColor, dark: UIColor) {
        if #available(iOS 13.0, tvOS 13.0, *) {
            self.init { traitCollection in
                if traitCollection.userInterfaceStyle == .dark {
                    return dark
                }
                return light
            }
        }
        else {
            self.init(cgColor: light.cgColor)
        }
    }
}

By the way, iOS has some default colors that automatically adapt to the current trait environment:

let view = UIView()
view.backdroundColor = .systemRed

Image appearance

The same logic in Asset Catalog works for images as well:

Use it as usual in code:

let imageView = UIImageView()
imageView.image = UIImage(named: "Image")

If you want to create images at runtime, for example, load from file system or from server, you must use image assets. Also I've added an extension to initialize assets with two images for different appearances:

import UIKit

public extension UIImageAsset {

    /// Creates an image asset with registration of tht eimages with the light and dark trait collections.
    /// - Parameters:
    ///   - lightModeImage: The image you want to register with the image asset with light user interface style.
    ///   - darkModeImage: The image you want to register with the image asset with dark user interface style.
    convenience init(lightModeImage: UIImage?, darkModeImage: UIImage?) {
        self.init()
        register(lightModeImage: lightModeImage, darkModeImage: darkModeImage)
    }

    /// Register an images with the light and dark trait collections respectively.
    /// - Parameters:
    ///   - lightModeImage: The image you want to register with the image asset with light user interface style.
    ///   - darkModeImage: The image you want to register with the image asset with dark user interface style.
    func register(lightModeImage: UIImage?, darkModeImage: UIImage?) {
        register(lightModeImage, for: .light)
        register(darkModeImage, for: .dark)
    }

    /// Register an image with the specified trait collection.
    /// - Parameters:
    ///   - image: The image you want to register with the image asset.
    ///   - traitCollection: The traits to associate with image.
    func register(_ image: UIImage?, for traitCollection: UITraitCollection) {
        guard let image = image else {
            return
        }
        register(image, with: traitCollection)
    }

    /// Returns the variant of the image that best matches the current trait collection. For early SDKs returns the image for light user interface style.
    func image() -> UIImage {
        if #available(iOS 13.0, tvOS 13.0, *) {
            image(with: .current)
        }
        return image(with: .light)
    }
}

Layers

Previous examples work for views perfectly. The colors are updated automatically without additional logic. But what about layers?
To update colors in CALayers, you should implement traitCollectionDidChange(_:) method in UIView or UIViewController and configure layer's colors manually:

override func traitCollectionDidChange(_ previousTraitCollection: UITraitCollection?) {
    super.traitCollectionDidChange(previousTraitCollection)
    traitCollection.hasDifferentColorAppearance(comparedTo: traitCollection) {
        layer.backgroundColor = UIColor.layer.cgColor
    }
}

Pay attention to line #3. Trait collection may be changed for many reasons, for instance, when an iPhone is rotated from portrait to landscape orientation. This function indicates whether changing between the specified and current trait collections would affect color values. It saves you from extra drawing.

Debugging

There are many ways to test Dark Mode appearance in your apps. Let's start with storyboards. If you use storyboards for layout, you can update interface style in the bottom next to device configuration pane.

One of the useful features of Xcode 11 is Xcode Preview. It's possible to use it for UIKit-based projects with additional configuration:

final class ViewController: UIViewController {
}

#if canImport(SwiftUI) && DEBUG

import SwiftUI

struct ViewControllerRepresentable: UIViewRepresentable {

    func makeUIView(context: Context) -> UIView {
        let storyboard = UIStoryboard(name: "Main", bundle: nil)
        let viewController = storyboard.instantiateViewController(withIdentifier: "ViewController")
        return viewController.view
    }

    func updateUIView(_ view: UIView, context: Context) {

    }
}

@available(iOS 13.0, *)
struct ViewController_Preview: PreviewProvider {

    static var previews: some View {
        Group {
            ViewControllerRepresentable()
                .colorScheme(.light)
                .previewDisplayName("Light Mode")
            ViewControllerRepresentable()
                .colorScheme(.dark)
                .previewDisplayName("Dark Mode")
        }
    }
}

#endif

Using colorScheme(_:) you can preview screens with both schemes simultaneously:

If you are debugging one of the color schemes, it's handy to fix dark appearance in the Simulator in Preferences > Developer > Dark Appearance:

If it's not enough for your case, you can override interface style during app sessions via Environment Overrides:

As I told earlier, trait collections may be changed a lot of times during app sessions. You can enable debug logging to easily see when traitCollectionDidChange(_:) is called in your own classes. Turn on the logging by using the following launch argument: -UITraitCollectionChangeLoggingEnabled YES.

When Dark Mode setting is updated, you'll see a message in the Console like this:

2019-12-16 09:12:44.819195+0600 DarkModeExample[22611:3698294] [TraitCollectionChange] Sending -traitCollectionDidChange: to <DarkModeExample.ViewController: 0x7fdb81d0b7a0>
► trait changes: { UserInterfaceStyle: Light → Dark }
► previous: <UITraitCollection: 0x600002f98900; UserInterfaceIdiom = Phone, DisplayScale = 3, DisplayGamut = P3, HorizontalSizeClass = Compact, VerticalSizeClass = Regular, UserInterfaceStyle = Light, UserInterfaceLayoutDirection = LTR, ForceTouchCapability = Available, PreferredContentSizeCategory = L, AccessibilityContrast = Normal, UserInterfaceLevel = Base>
► current: <UITraitCollection: 0x600002f98840; UserInterfaceIdiom = Phone, DisplayScale = 3, DisplayGamut = P3, HorizontalSizeClass = Compact, VerticalSizeClass = Regular, UserInterfaceStyle = Dark, UserInterfaceLayoutDirection = LTR, ForceTouchCapability = Available, PreferredContentSizeCategory = L, AccessibilityContrast = Normal, UserInterfaceLevel = Base>

Update Dark Mode dynamically

Unfortunately, iOS doesn't support updating color schemes dynamically for a single app. A simple way to implement it is saving selected UIUserInterafaceStyle and using it in next app sessions. A good option for this is UserDefaults:

public extension UserDefaults {

    var overridedUserInterfaceStyle: UIUserInterfaceStyle {
        get {
            UIUserInterfaceStyle(rawValue: integer(forKey: #function)) ?? .unspecified
        }
        set {
            set(newValue.rawValue, forKey: #function)
        }
    }
}

To apply the style saved we should override it for all app windows. They're available via UIApplication.shared.windows. Pay attention that since iOS 13 iPad apps may support multiple windows

import UIKit

public extension UIApplication {

     func override(_ userInterfaceStyle: UIUserInterfaceStyle) {
         if supportsMultipleScenes {
             for connectedScene in connectedScenes {
                 if let scene = connectedScene as? UIWindowScene {
                     for window in scene.windows {
                          window.overrideUserInterfaceStyle = userInterfaceStyle
                     }
                 }
             }
         }
         else {
             for window in windows {
                 window.overrideUserInterfaceStyle = userInterfaceStyle
             }
         }
     }
 }

Don't forget to override the style for windows created afterwards. After overriding it standard views and controls automatically update their appearance to match the current interface style.

Note: You may think about method swizzling to reduce configurations. I tried to avoid it in my example. Method swizzling is risky and may lead to unexpected behaviour. In my opinion for this case it's a good decision.

What do you think? How did you implement this feature in your apps? And should apps have this option or should we rely on the system?

Backward compatibility

At Rosberry we usually support two latest major iOS versions. At the time of writing this article it's iOS 12 and 13. The simplest way is to use only a light color scheme for iOS 12 devices.

Conclusion

I've shared my experience as to the Dark Mode support. I hope this article will help you to update existing apps and to inspire you to develop new ones. I want to believe that in future Dark Mode will be default app feature without the need for additional adjustments for design and code.

At the end I want to mention useful materials from around the web that helped me writing this article. And don't forget to check DarkMode project to see how Dark Mode works.

Apple

WWDC 2019 - Implementing Dark Mode on iOS
Human Interface Guidelines - Dark Mode
Human Interface Guidelines - System Colors
Supporting Dark Mode in Your Interface

Articles

Dark Mode: Adding support to your app in Swift - SwiftLee
Dark Mode on iOS 13 - NSHipster
Adopting Dark Mode on iOS and Ensuring Backward Compatibility - Inside PSPDFKit

Github

aaronbrethorst/SemanticUI: iOS 13 Semantic UI: Dark Mode, Dynamic Type, and SF Symbols
noahsark769/ColorCompatibility: Use iOS 13+ system colors while defaulting to light colors on iOS <=12

Plugins

Color System Plugin for Sketch - Product Hunt
Lights - Light and Dark Mode - Figma

Github Actions CI for Swift Projects

Artem Novichkov — Thu, 29 Aug 2019 09:38:12 +0000

Github introduced CI and CD based on actions. It allows you to automate how you analyse, build, test and deploy your projects on any platform, including Linux, macOS and Windows.

I was excited over this news and can't wait to try it out. My idea was to automate building and unit testing of Swift projects.
There are two types of actions and we should know the difference before starting.

Docker container vs JS

Originally all actions were based on Docker and used HCL syntax for workflows. Actions based on Docker run only in Linux virtual environment. With CI/CD announcement Github released JavaScript based actions and new YAML syntax for workflows.

For iOS projects you can use only JS actions because they should be run on macOS. Moreover using a JavaScript action simplifies the action code and executes faster than a Docker container action.

Lights! Camera! Github Action!

As an example I will use Texstyle. It's a framework for formatting attributed strings. Let's start with a complete configuration and inspect it step by step:

At first you should select an event to trigger the workflow. My workflow is triggered on any pull request in the repository. Optionally you can label the workflow with name.

Workflows must contain at least one job. My workflow contains only one job for testing. It is possible to run up to 20 jobs concurrently per repository across all workflows.

Jobs run on virtual host machines that are specified with runs-on. In my case it's macOS-latest, because I want to use xcodebuild. It's a standard Apple developer tool and works on macOS only.

Texstyle supports both iOS and tvOS, so I want to run xcodebuild with two destinations. To specify different variations, I used strategy.matrix. I added two simulators with actual OS versions.

And the last step is to adding steps 🙃. I used checkout action to access the contents of the repository. You can specify the version of actions after @ sign with a release version, branch or specific commit.
Everything is ready for testing. I added run with bash commands to change current directory, run xcodebuild and send code coverage data to Codecov. To use matrix variables, I added env with the required variable name.

To read more about workflow syntax, check the documentation.

Comparing to Travis CI, my configuration looked like:

That's it! Here is an example of live logs:

But that's not the end, it's just the start! Suppose that we want to reject pull requests if there are any linting warnings or errors. The most popular lint tool for Swift is Swiftlint. For now it's possible to run it and see warnings in logs that is not enough. It would be great to see annotations from SwiftLint Violations via GitHub Checks API, or even have suggested changes. And actions allow to use this API easily.

Conclusion

As for me Github Actions CI is a game changer. It is deeply integrated into the service. And community-driven actions allow to reuse common scenarios.

Let's summarise my experience with pros and cons.

Pros:

Various triggers for workflows. Pull requests, staring repos, project card statuses, scheduled events etc.
Speed. According to logs for Texstyle, last builds were 2 min 12 sec on Travis CI and 1 min 8 sec on Github CI.
Preinstalled software. macOS images have fastlane, swiftlint, Cocoapods, Carthage etc.
Marketplace. There are plenty of actions developed by community. You can reuse any of them.
Pricing. Of course, it's free for open source. The time limits look pretty good - 2000 minutes for free plan and 3000 minutes with a Pro plan including private repositories 😏.

Cons:

Still in beta. First actions were written in HCL syntax. Support for it will be removed on September 30. And maybe it's not the end, YAML syntax may be updated as well. So be ready to migrate your actions before public release.
Debugging. It's hard to debug workflows as any CI service. You must trigger related event and wait for all steps. It's not possible to test it locally, even validate workflow syntax.
Documentation. On of the goals of this article is to clarify Actions benefit for myself and give it a try on real project. I had many unobvious errors, official documentation and StackOverflow won't help. For instance, a multiline run command won't work without a name label. I believe open source workflows will help to avoid dump errors and handle edge cases in the future.

Thanks for reading! If you have any questions or ideas of workflows, feel free to leave comments or ping me on Twitter @iosartem.

References

Automating your workflow with GitHub Actions
Github Actions
Awesome Actions