Forem: Amarildo Lucas

All SwiftUI Scene Types Noted

Amarildo Lucas — Wed, 22 Mar 2023 16:21:12 +0000

Discover the latest SwiftUI scenes to help you present windows within your apps.

SwiftUI scenes are the main building blocks to structure and easily build more kinds of apps for apple platforms.

While most developers build apps for iOS, knowing the different scene types helps you to easily build multiplatform apps and follow the apple human interface guidelines to better design and architect your ideas.

Below I share all the SwiftUI scene types available with a resume of these key points concepts and their use.

Things to take in mind:

WindowGroup: Provides a way to build data-driven applications across all of apple's platforms.
DocumentGroup: Enables support for opening, creating, and saving documents.
Settings: Presents an interface for viewing and modifying an app's settings. (macOS only)
Window: Present its content in a single, unique window. (macOS - only.)
MenuBarExtra: Create a utility app that only shows in the menu bar.

I hope this sketch note is helpful to you.

If you find this content helpful, please consider buying me a coffee by downloading the rich and high-resolution version of this sketch note here.

References:

WWDC 2022: https://developer.apple.com/videos/play/wwdc2022/10061/

Sketch Note: SwiftUI App Structure

Amarildo Lucas — Mon, 20 Mar 2023 18:31:27 +0000

The SwiftUI App protocol looks simpler but is decisive for your applications' structure and organization.

This sketch note shares a general look at the parts involved while implementing your app's entry point.

Things to take in mind:

1. The App protocol represents structure and behavior.

2. The body is the content and can define scenes.

3. Scene acts as the root view of the view hierarchy and can be more than one.

4. The @main initialize and call the main() method which runs your app.

5. The init() runs by default.

6. You can have multiple scenes whose lifecycles will be managed by the system.

I hope this sketch note is helpful to you.

CustomPresentationDetent Protocol Implementation in SwiftUI for Modal Presentations

Amarildo Lucas — Wed, 08 Mar 2023 21:47:29 +0000

You can also read this article directly in my personal blog https://amarildo.codes

We can build more flexible and customized modal view presentations thanks to the CustomPresentationDetent protocol. It's common to use the .sheet modifier when presenting a modal view. However, occasionally we may need more control over the presentation and the .sheet's default behavior will not be enough. This is where CustomPresentationDetent implementation begins because it enables us to change the presentation's behavior in the modal view.

What you will learn

The article provides and outlines a step-by-step guide on how to use CustomPresentationDetent. You will download a starter project that explains how to create an extension of PresentationDetent struct and implements CustomPresentationDetent protocol.

Getting started with the starter project
Create PresentationDetent extension
Implementing CustomPresentationDetent

Getting started with the starter project

Before we start, clone/fork or download the project from the main branch and run the following git commands:

git clone git@github.com:amarildolucas/CustomPresentationDetent.git
cd CustomPresentationDetent
git checkout start-project

The main branch contains the final result of the implementation.
The start-project branch contains the version that you should use to follow through with this article. It is highly recommended that you use the start-project branch.

The start project contains a ContentView.swift file that:

Defines a SwiftUI view.
Contains a button that, when pressed, toggles the boolean value of isPresentingSheet and presents a modal sheet using the .sheet modifier. The content of the modal sheet is defined in a separate struct called ContentModalSheet. The ContentView struct also conforms to the View protocol and has a body property that returns a VStack containing the button.

// ContentView.swift

struct ContentView {
    // Used to toggle and present the modal sheet.
    @State private var isPresentingSheet: Bool = false
}

extension ContentView: View {
    // Returns a VStack containing the button.
    var body: some View {
        VStack {
            Button(action: presentSheet) {
                HStack {
                    Image(systemName: "arrow.up")
                    Text("Present Sheet")
                }
                .fontWeight(.semibold)
                .foregroundColor(.white)
                .padding()
                .background(Color.accentColor)
                .cornerRadius(8)
            }
            .sheet(
                isPresented: $isPresentingSheet, 
                content: ContentModalSheet.init
            )
        }
        .padding()
    }
}

extension ContentView {
    // Toggles the boolean value of isPresentingSheet and presents a modal sheet using the .sheet modifier. 
    private func presentSheet() {
        isPresentingSheet.toggle()
    }
}

The start project also contains another file called ContentModalSheet.swift that contains the View to be presented.

Defines a view called ContentModalSheet, which is presented as a modal sheet.
Display the Text "Showing Modal Sheet" and the Button that dismisses the sheet by using the Environment dismiss property and calling the .callAsFunction method.

// ContentModalSheet.swift

struct ContentModalSheet {
    @Environment(\\.dismiss) private var dismissModalSheet
}

extension ContentModalSheet: View {
    var body: some View {
        VStack {
            ZStack {
                Button(action: dismissModalSheet.callAsFunction) {
                    Image(systemName: "xmark")
                }
                .fontWeight(.semibold)
                .foregroundColor(Color(uiColor: .label))
            }
            .frame(maxWidth: .infinity, alignment: .leading)

            Spacer()
            Text("Showing Modal Sheet")
                .font(.title3)
            Spacer()
        }
        .padding()
    }
}

Create PresentationDetent extension

A straightforward implementation of the .presentationDetents() method sets the available detents/static properties and methods (snap points) for enclosing sheet presentations in different sizes:

.large
.medium
.custom<D>(D.Type)
.fraction(CGFloat)
.height(CGFloat)

All the above properties and methods return a PresentationDetent instance. Let's see this in practice in the bellow code by checking the .presentationDetents([.medium, .height(420), .large]) line of code.

Button(action: presentSheet) {
    HStack {
        Image(systemName: "arrow.up")
        Text("Present Sheet")
    }
    .fontWeight(.semibold)
    .foregroundColor(.white)
    .padding()
    .background(Color.accentColor)
    .cornerRadius(8)
}
.sheet(isPresented: $isPresentingSheet) {
    ContentModalSheet()
          .presentationDetents([.medium, .height(420), .large])
}

By default, sheets present the PresentationDetent/large detent. If we want to change this behavior we can change this with two lines of code.

Add a private property named selectDetent of type PresentationDetent and initializes it with a value of .height(64).

struct ContentView {
    // ...

    @State private var selectDetent: PresentationDetent = .height(64)
}

Add the selection parameter to the .presentationDetents method and assign it with $selectDetent variable. The method will return the selected PresentationDetent assigned to this variable.


// Button... {}
    .sheet(isPresented: $isPresentingSheet) {
        ContentModalSheet()
            .presentationDetents(
                [.height(64), .medium, .height(420), .large],
                selection: $selectDetent
            )
        }

To explain a little bit further, a detent is a position at which our modal presentation can snap to. For example, if we have a modal presentation, we can define different detents for displaying the View in different sizes or styles.

Now that we understood how detents work, let's extend our detents to a separate file called PresentationDetent+Extension, then add the following code to it.

extension PresentationDetent {
    static let mediumBottomBar = Self.medium
    static let largeBottomBar = Self.large
}

This code defines two static properties in the PresentationDetent struct and assigns them the original values of the medium and large static properties of the struct. This can be good if we want to improve the context and nomenclature of our properties and feature implementations.

In the next section, we will go further and finally implements our custom property.

CustomPresentationDetent implementation

To implement CustomPresentationDetent for our modal presentation, we need to create a custom struct that conforms with the protocol. The protocol contains a static method that returns an optional CGFloat.

static func height(in context: Context) -> CGFloat?

So, let's create our custom struct and implements the protocol.

private struct BottomBarDetent: CustomPresentationDetent {
    // Calculates and returns a height based on the context.
    static func height(in context: Context) -> CGFloat? {
        max(64, context.maxDetentValue * 0.1)
    }
}

Now on top of our extension file, we can add a new property that uses our custom type.

extension PresentationDetent {
    static let bottom = Self.custom(BottomBarDetent.self)
        // ...
}

And respectively in our existing .presentationDetents method, we can update it to use our new custom properties .bottom, .mediumBottomBar, and .largeBottomBar.

// Button... {}
    .sheet(isPresented: $isPresentingSheet) {
        ContentModalSheet()
            .presentationDetents(
                [.bottom, .mediumBottomBar, .largeBottomBar],
                selection: $selectDetent
            )
        }

Summary

This article provided a detailed explanation of how to use CustomPresentationDetent. Now if necessary, create more flexible and customizable modal presentations in your future SwiftUI projects.

You can download the final project here.

If you enjoyed this article, please consider supporting me by offering me a coffee:

https://www.buymeacoffee.com/amarildocodes

Thanks for reading, and happy building! :)

Navigation App Architecture on Apple eyes

Amarildo Lucas — Sat, 14 May 2022 20:48:12 +0000

A visual on Apple human interface guidelines for navigation on iOS.

If you are like me and love learning by seeing visuals or flows about some programming or UI/UX topics, I hope you enjoy this mind node that I created about how the Navigation should be on iOS on Apple eyes.

You can download it and use it as your need. 🚀

References

@discardableResult

Amarildo Lucas — Fri, 27 Mar 2020 14:18:28 +0000

Ignoring non-void function returns so they do not warn on unused results.

You are writing your code and have a couple of functions that return some values. But when you are invoking some of these functions you are not using the returning values and are getting warnings like this through your compiler.

warning: result of call to 'someFunction()' is unused

So to avoid these warnings, your code starts looking like this:

let _ = someFunction()

The warning was now suppressed and your console outputs the expected result. But you are feeling not happy about seeing your code with a lot of let _. This can be prone to future errors.

👉🏿 You need `@discardableResult`.

In Swift annotating methods and functions with @discardableResult informs the compiler that a non-void return type should be consumed. So, ignored results do not raise warnings or errors.

warning: result of call to 'someFunction()' is unused

The @discardableResult attribute enables developers to indicate when their functions and methods produce a non-essential result and should not produce a warning.

extension Array { 
    mutating func removeLast() -> Element {
        return remove(at: count - 1)
    }
}

The above function removes the last element of an Array. When we call array.removeLast() from var array = [2, 4, 7, 0], array.removeLast() returns 0.

var array = [2, 4, 7, 0]
array.removeLast()
// warning: result of call to 'removeLast()' is unused
// array.removeLast()
//      ^         ~~
// [2, 4, 7]

As our intention was just to remove the last element of the array and do nothing with the returned value, it makes sense to us to discard this value. So rather suppress the warning message with let _ = array.removeLast(), we should use @discardableResult.

In the following snippet, we expect to be able to discard the return value after invoking array.removeLast().

extension Array { 
    @discardableResult
    mutating func removeLast() -> Element {
        return remove(at: count - 1)
    }
}

When we call array.removeLast() again, we will not see the warning anymore.

var array = [2, 4, 7, 0]
array.removeLast()
// [2, 4, 7]

🙌🏿

iOS CI/CD: Continuous Integration and Continuous Delivery Explained

Amarildo Lucas — Tue, 01 Oct 2019 13:06:08 +0000

Continuous integration and continuous delivery (CI/CD) is widely used by development teams, even in open-source communities. It offers a sustainable way to test and deploy code many times a day without the hurdle of doing it manually.

In this guide, you'll learn the foundations of getting started with CI/CD for iOS. We'll learn about:

The importance of CI/CD for iOS developers
Principles of iOS CI/CD
The top benefits of CI/CD for iOS
Best practices to remember for iOS CI/CD
An iOS CI/CD workflow example
Getting started with CI/CD for iOS
Choosing the right iOS CI/CD platform

By the end of this article, you’ll be able to evaluate your current workflow, adopt the best CI/CD practices, and ship your iOS applications faster.

The importance of CI/CD for iOS developers

CI/CD for iOS will save you days of preparing app submissions, fixing critical bugs, and uploading screenshots to the App Store. Automating these processes means that any member of the team will be able to release bug fixes or updates.

The CI/CD can check in and check out source code so all members on your team will be on the same page. Leading to better communication, increased app development quality, and more frequent releases.

The DevOps Role

DevOps is a cultural change in the organization where the operations and development teams join forces to continuously deliver high-quality software.

Because teams employing DevOps ideals are focused on delivering value to users as quickly and efficiently as possible, continuous integration and delivery is a natural extension of their operations.

The end goal is to help iOS developers build and release apps at high velocity by defining a process for effective app delivery.

Principles of iOS CI/CD

One of the most important aspects of implementing CI/CD for iOS is learning about the principles that can increase the value of your current workflow:

Use Static Code Analysis

So that the build can fail early (in the event of serious coding errors), static code analysis should be the absolute first step in the build process. This way, you can fix the issues as soon they are found by the server.

Keep the Code Deployable

Once the linter step is passed, we can move on to the building and compiling of the source code. The last step in the app build process should be to generate the archive to be submitted to iTunes Connect. In the case of iOS, it should be an IPA file.

Notify your Team

Any developer can deploy any version of the app to any environment at a push of a button. Once the build is finished, it’s important to send a notification to other developers with the status of the build. This can be an email, Slack message, or similar notification service. The iOS CI/CD pipeline should trigger this notification at the end of every build.

Design for Iterative Releases

Have a well-defined pipeline that focuses on automated delivery. Implement static analytics on your source code to detect issues or crashes (even in production).

The top benefits of CI/CD for iOS

Aside from making your previous iOS development process more efficient, implementing a CI/CD pipeline helps your team:

1. Build faster

A continuous and automated development cycle helps mobile development teams make high-value releases faster.

2. Detect problems early

A continuous integration pipeline can run test suites on every code change. Thus, problems can be spotted before they can reach production.

3. Provide effective feedback

In a continuous integration workflow, the entire team can view and monitor source code activity. When new problems appear, the team members that introduced the failure are automatically notified.

4. Automate the testing process

Manually testing iOS apps on a simulator or multiple devices is a time-consuming process. In a CI/CD workflow, the process is automatic and straightforward. Simply configure the devices and simulators into the server workflow and let your pipeline do the work for you.

5. Build deployment logs

In a CI/CD pipeline, all build deployments are logged. This means that at any given time, you can identify the exact point where your app failed.

Best practices to remember for iOS CI/CD

When implementing a CI/CD workflow for iOS development, it's vital you adhere to standard best practices. Why? The guidelines below are designed to help you push high-quality code with every release.

1. Keep your Pipeline Fast

Always improve the quality of your pipeline by inspecting its configuration, improving build times, removing any unnecessary code or assets, configuring the right environments, and removing any bottlenecks causing issues on the deploy process.

2. Run Code Analysis Early

Fail fast: Include unit tests and linters early in the pipeline.

3. Separate Build Configurations

Use profiles to separate build configurations. Internal and testing builds are different from the builds for your users. By default, an iOS app includes Debug and Release build configurations. It makes sense to add Test, Staging and Production builds.

4. Automate Your Builds

Compiling and building an iOS app takes a great deal of time. Using CI/CD workflow you can automate the process and save time.

5. Deploy Only Through the Pipeline

The pipeline is configured to help and enforce best practices of CI/CD for your development cycle. Avoid at all cost manual deploys.

Making your code run through your pipeline requires each change to conform with your code standards and styles. This mechanism safeguards your codebase from untrusted code.

6. Maintain Similar Environments

If possible, try to maintain similar pipelines in all your environments. Changes that pass the requirements of one environment should pass in another. This also includes feature branches.

7. Monitor the Pipeline

Apps are unpredictable. No matter how cool you think your code is, the app can fail for a lot of reasons. Therefore, you'll need to proactively monitor your deploys throughout the pipeline so you can catch problems before they reach the App Store.

An iOS CI/CD workflow example

After understanding and adopting essential CI/CD principles, the next step is to set up your pipeline. One of the more painful parts of iOS development is iterative releases. It's tedious and time-consuming. The role of CI/CD here is to automate all of these steps.

Before implementing CI/CD, a typical release to the App Store looks like this:

Check out source code from some remote repository (GitHub, Bitbucket, GitLab, etc.).
Do some static analysis of the code using SwiftLint, for example.
Compile and build your iOS app in a simulator or device to check that everything is running as expected.
Run unit, UI or other kinds of tests.
Code signing and archive your app.
Submit your app to iTunes Connect.
Notify users about your release.

This process can be error-prone; you may experience merge conflicts and poor management of versions (as this is done manually by each developer).

Fortunately, we can improve it with automation. When we use an iOS CI/CD pipeline, our workflow looks more like this:

Code the application changes with Xcode.
When the code is ready for integration, it automatically pushes to a Git repository.
Next, CI triggers the execution of test cases that will confirm the code is ready for release.
Finally, the release pipeline triggers to deploy the archive produced in the CI stage, and a build is released with TestFlight.

See how the iOS developer has far less to do with CI/CD? That’s the beauty of automation.

Getting Started with iOS CI/CD

To integrate CI/CD into your iOS development process, start by exploring what things can make your team's job easier. You need to understand and collect information about your current workflow and provide feedback to the team until you have defined a process for your pipeline.

Using this information, your team can evaluate and define how to automate the current workflow to lead to a better development lifecycle. Optimizing and automating the current process should be the priority.

Ultimately, this approach increases transparency through all your team. When your iOS CI/CD pipeline is set up, your entire team will know what’s going on with the builds and will receive the latest results of tests, which means they can move on to resolving new issues.

This process allows developers to stay focused on writing code and observing the app's behavior. Meanwhile, product stakeholders have access to updated metrics. Code changes and tests are available for review at any time.

The lesson here is that, as a faster feedback loop emerges, each member of the team can learn from each other and take responsibility for the code that is shipped.

Choosing the Right iOS CI/CD Platform

Self-hosted CI/CD solutions require owning hardware and setting up infrastructure. Maintenance becomes a big endeavor.

Software-as-a-service (SaaS) solutions, on the other hand, offer cross-platform capabilities with zero maintenance

These cloud-based CI/CD tools are easy to set up and all the hardware and software maintenance is managed by the service provider. Developers can skip a lot of tedious or repetitive tasks, such as code signing and publishing.

Cloud-based CI/CD also comes with a big advantage: it unifies your team around a single platform, mobilizing your iOS, Android and web developers within a consistent tool.

Summing Up

A well-defined process and the right CI/CD tools will make your iOS development cycle faster and more efficient.

If you want to explore CI/CD for iOS in a more hands-on way, check out our tutorial on building, testing, & deploying an iOS App with CI/CD.

Have any questions about this guide? Don't hesitate to reach out to us on Twitter @semaphoreci.

Tutorial: Build, Test, & Deploy an iOS App with CI/CD

Amarildo Lucas — Fri, 20 Sep 2019 21:36:59 +0000

When we develop iOS apps, we usually manage the app publication process using the Xcode Organizer. Then we sign, test, build, archive, submit, change versions, submit new builds again and again to the TestFlight or AppStore.

If we generate our builds daily, this process is tedious and tiring. Sooner or later, you will ask yourself:

How can we automate this entire process?

Continuous Integration and Continuous Delivery (CI/CD) for iOS enable us to improve our build deploys. We’re able to release updates at any time in a sustainable way without the hurdle of doing it manually every time. We don’t need to run all our tests when we add new code or take a trial and error approach before pushing a commit to our repository.

In this tutorial, we’ll learn how to automatically deploy our apps to the TestFlight using Semaphore as our CI/CD platform. When we push our code to our remote repository, Semaphore will test, build, deploy and generate screenshots of our app.

To make things simple, we’ve divided this tutorial into two parts:

Continuous integration: build, test and archive the app.
Continuous deployment: submit the build to Testflight.

We will start by:

Setting up our repository in GitHub.
Signing up for Semaphore CI.
Linking our GitHub repository to Semaphore CI Project.
Configuring our first CI/CD pipeline.
Improving our CI/CD pipeline with Fastlane.

Continuous integration with Semaphore

You will need an iOS app to configure our Continuous Integration and Delivery pipeline. Then, you will need to configure a new repository.

We will use:

Git: for version control.
A GitHub account to manage our repository.
Xcode 11 with Swift 5.1 as our development tools.
SwiftUI to build our user interface.
XCTest to create and run unit tests and UI tests.

Note: SwiftUI previews and inspectors are only available when running on macOS Catalina 10.15.

You can download the project and follow along with this tutorial, or create a new iOS Single View Application project from scratch.

Download: Semaphore Demo iOS Swift Xcode

Xcode will set up Git automatically for you since it is checked by default. Otherwise, you can set up manually by running git init in the root project directory in the terminal.

You can also check your new git repository by writing git status in the terminal.

$ git status

On branch master
nothing to commit, working tree clean

Build and run the app on the simulator. If you have unit tests and UI tests in the project, run your test cases first in the Test navigator. If everything looks right, push the code to the GitHub repository. Nearly every new iOS project runs without problems the first time. If you run into a problem, you can always grab the Semaphore demo app from Github that we are using to following through this tutorial.

The Semaphore pipeline is configured to:

Run all unit and UI tests.
Build the app and generate an ipa archive.
Generate automated App Store screenshots.
Upload the archived ipa and screenshots.

At the end of this tutorial you will achieve a result like in the below image:

Setting up Semaphore for an iOS project

Go to https://semaphoreci.com/login and log in with your GitHub account.

Click on + Projects to add the project.

Semaphore will list GitHub repositories. If you haven't pushed the code yet, you will need to push it so you can see the repository listed.

Follow the GitHub instructions after you created a new repository, which is the most important part:

$ git remote add origin git@github.com:amarildolucas/ios-semaphore-intro.git
$ git add -A
$ git commit -m "First commit"
$ git push -u origin master

This will push your code to GitHub. Since this is likely part of your day-to-day workflow, I won't go into too many details here. Remember, if you don't want to start a new project from scratch, you can just fork the Semaphore iOS demo app as recommended above.

Now, in Semaphore, connect the new repository. Refresh the list to see the repository, if needed.

After you connected the repository to Semaphore, select your project's main language. Choose "Swift" to continue with an iOS setup.

You will see that Semaphore created a new file to be committed to our repository. If you chose the Semaphore demo app to follow through this tutorial, find the configured pipeline inside the root directory .semaphore/semaphore.yml..

# Use the latest stable version of Semaphore 2.0 YML syntax:
version: v1.0

# Name your pipeline. If you choose to connect multiple pipelines with
# promotions, the pipeline name will help you differentiate between
# them. For example, you might have a build phase and a delivery phase.
# For more information on promotions, see:
# https://docs.semaphoreci.com/article/67-deploying-with-promotions
name: Tallest Towers

# The agent defines the environment in which your CI runs. It is a combination
# of a machine type and an operating system image. For a project built with
# Xcode you must use one of the Apple machine types, coupled with a macOS image
# running either Xcode 10 or Xcode 11.
# See https://docs.semaphoreci.com/article/20-machine-types
# https://docs.semaphoreci.com/article/161-macos-mojave-xcode-10-image and
# https://docs.semaphoreci.com/article/162-macos-mojave-xcode-11-image
agent:
  machine:
    type: a1-standard-4
    os_image: macos-mojave-xcode11

# Blocks are the heart of a pipeline and are executed sequentially. Each block
# has a task that defines one or more parallel jobs. Jobs define commands that
# should be executed by the pipeline.
# See https://docs.semaphoreci.com/article/62-concepts
blocks:
  - name: Run tests
    task:
      # Set environment variables that your project requires.
      # See https://docs.semaphoreci.com/article/66-environment-variables-and-secrets
      env_vars:
        - name: LANG
          value: en_US.UTF-8
      prologue:
        commands:
          # Download source code from GitHub.
          - checkout

          # Restore dependencies from the cache. This command will not fail in
          # case of a cache miss. In case of a cache hit, bundle  install will
          # complete in about a second.
          # See https://docs.semaphoreci.com/article/68-caching-dependencies
          - cache restore
          - bundle install --path vendor/bundle
          - cache store
      jobs:
        - name: Test
          commands:
            # Select an Xcode version.
            # See https://docs.semaphoreci.com/article/161-macos-mojave-xcode-10-image and
            # https://docs.semaphoreci.com/article/162-macos-mojave-xcode-11-image
            - bundle exec xcversion select 11.2.1

            # Run tests of iOS and Mac app on a simulator or connected device.
            # See https://docs.fastlane.tools/actions/scan/
            - bundle exec fastlane test

  - name: Build app
    task:
      env_vars:
        - name: LANG
          value: en_US.UTF-8
      secrets:
        # Make the SSH key for the certificate repository and the MATCH_PASSWORD
        # environment variable available.
        # See https://docs.semaphoreci.com/article/109-using-private-dependencies
        - name: match-secrets
      prologue:
        commands:
          # Add the key for the match certificate repository to ssh
          # See https://docs.semaphoreci.com/article/109-using-private-dependencies
          - chmod 0600 ~/.ssh/*
          # Add the key to the ssh agent:
          - ssh-add ~/.ssh/*
          # Continue with checkout as normal
          - checkout
          - cache restore
          - bundle install --path vendor/bundle
          - cache store
      jobs:
        - name: Build
          commands:
            - bundle exec xcversion select 11.2.1
            - bundle exec fastlane build

            # Upload the IPA file as a job artifact.
            # See https://docs.semaphoreci.com/article/155-artifacts
            - artifact push job build/TallestTowers.ipa
  - name: Take screenshots
    task:
      env_vars:
        - name: LANG
          value: en_US.UTF-8
      prologue:
        commands:
          - checkout
          - cache restore
          - bundle install --path vendor/bundle
          - cache store
      jobs:
        - name: Screenshots
          commands:
            - bundle exec xcversion select 11.2.1
            - bundle exec fastlane screenshots

            # Upload the screenshots directory as a project artifact.
            # See https://docs.semaphoreci.com/article/155-artifacts
            - artifact push job screenshots

Every Semaphore pipeline starts with the version, name and agent. An agent is a virtual machine that powers the pipeline. Let's understand the above file, which defines our pipeline workflow.

Version

The first line version: v1.0 uses the latest stable version of Semaphore 2.0 YML syntax.

version: v1.0
name: Tallest Towers

By default, they are named with the language-specific template that you chose. This is our pipeline name.

Agent

Next, we have an agent.

agent:
  machine:
    type: a1-standard-4
    os_image: macos-mojave-xcode11

An agent defines the environment in which your code will run. There are multiple available machine types and operating system images. This means that on the Semaphore side, your code will be built in a hosted macos-mojave machine. This is a customized image with Xcode 11 preinstalled.

In our case, a1-standard-4 is our machine name with 4 virtual CPUs, 8 GB of memory and 50 GB of disk.

Blocks

Blocks define actions for the pipeline. They are executed sequentially and are probably the most important part of this file. Each block has a task that defines one or more jobs, and these jobs define the commands to execute. Once all jobs in a block are complete, the next block begins. Essentially, blocks define your Continuous Integration and Continuous Delivery pipeline flow.

In this file we have 3 blocks named ** Run tests**, Build app and ** Take screenshots**. All defining a task with some jobs. These jobs define some commands to run, for example bundle exec xcversion select 11.2.1 . Below is a more descriptive explanation for the job named Test inside Run tests block:

bundle exec xcversion select 11.2.1 selects an Xcode version.
bundle exec fastlane test run tests of iOS and Mac app on a simulator or connected device.

The first block run all our unit and UI tests.

- name: Run tests
  task:
    env_vars:
      - name: LANG
        value: en_US.UTF-8
    prologue:
      commands:
        - checkout
        - cache restore
        - bundle install --path vendor/bundle
        - cache store
    jobs:
      - name: Test
        commands:
          - bundle exec xcversion select 11.2.1
          - bundle exec fastlane test

The checkout command download source code from GitHub. The next commands, restore dependencies from the cache and install it. Finally, we select the Xcode version of the project and run the tests using Fastlane.

The next block build the app and generates an ipa archive.

- name: Build app
  task:
    env_vars:
      - name: LANG
        value: en_US.UTF-8
    secrets:
      - name: match-secrets
    prologue:
      commands:
        - chmod 0600 ~/.ssh/*
        - ssh-add ~/.ssh/*
        - checkout
        - cache restore
        - bundle install --path vendor/bundle
        - cache store
    jobs:
      - name: Build
        commands:
          - bundle exec xcversion select 11.2.1
          - bundle exec fastlane build
          - artifact push job build/TallestTowers.ipa

It is very similar to the previous block. The commands inside this block configure our secrets, sign our app and upload it to TestFlight using Fastlane. We will go more in-depth about the other commands and Fastlane later.

The last block capture and upload our app screenshots.

- name: Take screenshots
  task:
    env_vars:
      - name: LANG
        value: en_US.UTF-8
    prologue:
      commands:
        - checkout
        - cache restore
        - bundle install --path vendor/bundle
        - cache store
    jobs:
      - name: Screenshots
        commands:
          - bundle exec xcversion select 11.2.1
          - bundle exec fastlane screenshots
          - artifact push job screenshots

Notice that we repeat some commands like checkout, cache, etc, to get the necessary files from our repositories and dependencies.

To commit your file, tap the button Run this workflow. Also, pay attention to the fact that you can customize the default configuration before running by clicking on the Customize it first link.

Is everything green (Passed)? You did it! 🎉

We have a working setup for a real workflow that makes it easy for iOS developers entering the Continuous Delivery stage. After running the code, everything shows a “Passed” message in green. Go further and see the output of every step by tapping in your commit message or job name in the Semaphore dashboard to understand everything that happened in the backend of the console while running the pipeline steps.

We can even have more blocks if we want. For example, a block to create changelog files of build versions or to send notifications on Slack, etc. This all depends on you and your pipeline strategy. So, now that you understand the file and how the integration process works, let’s understand our deployment process in depth.

Before doing it, let’s make a quick overview of Continuous Integration. In this process, we commit our changes to the main code branch that triggers an automated code to build and run. Every git push origin branch will trigger the automated process defined in the semaphore.yml configuration file. This way we focus on our work rather than manually build and test code every time we do changes.

Continuous Integration helps us archive a build that can be deployed and the automated tests check every tested code to be safe to deploy.

Continuous Deployment with Semaphore

Our code changes continuously while working on our apps. In practice, we deploy several versions of our apps, sometimes even on the same day. Rather, to fix bugs, add new features, refactoring some code, etc. It’s an endless cycle. Continuous Delivery is exactly this process. If we configure our project to trigger our defined pipeline automatically and fully automate the entire process of push code from our repository to production, the process is called Continuous Deployment.

We want to define our pipeline with steps to do Continuous Deployment, so we can focus only on our code while working in small iterations and always keep the code in a deployable state.

If you forked the Semaphore demo app you got all of this out of the box.

Make sure that you:

Configured Fastlane to automate deployments and releases (Continuous Deployment).
Added a block to build and run our unit and UI tests.
Added a block with steps to build and deploy our app to TestFlight.

Fastlane makes our Continuous Deployment life a bit easier. You may know it as is vastly used for deployment of apps to the App Store.

If you don’t have Fastlane installed, you will need to:

Install Fastlane.
Follow the instructions of configuring Fastlane files.
Test if everything is working right.

If you want a quick setup help, you can see the files that we use in the configuration of the Semaphore Demo iOS Swift app here. These files are added after we install and run Fastlane for the first time. To understand more about the process of Fastlane installation and configuration you should read this introductory article.

Run fastlane init in the terminal after installation and follow the instructions.

As we will automate our deployment of build distributions to TestFlight, you will need to have these steps finished:

Your new app configured on the Apple Dev Center.
Your new app available in App Store Connect.
A successfully generated Fastlane configuration.

Also, as an iOS Developer, I think that is your day to day for every new app. So, we will not enter in details here.

This is everything we need to set up and deploy our first build with Continuous Deployment. In case you’re blocked in some steps, check the code of Semaphore Demo for iOS again to guide you, it is very specific and self-explanatory.

Note: Ensure that Xcode “automatically manage signing” it’s unchecked in Xcode when you work with Fastlane. And that your Signing (Release) contains the match AppStore provisioning profile selected if you had a Match file.

Configure your keys and secrets

Now that we have configured Fastlane, we must also provide a way for Semaphore CI to access the Git certificates repository and the Apple Developer portal.

Because we will access a private repository, we need to create a deploy key and add it to Semaphore CI secrets. This typically happens over SSH. If you are not familiar with SSH, this article walks you through the process to create, add and manage SSH keys to use in your pipeline.

Also, I recommend this GitHub article on generating a new SSH key.

$ cd ~/.ssh
$ ssh-keygen -t rsa -f id_rsa_semaphoreci

After generating the key, you will need to connect the SSH key to the project or user. Deploy your key to GitHub to grant access to your private repository.

Also, let’s store the deploy key as a secret file in the Semaphore CI environment.

Open the Semaphore Dashboard for your Organization. On the left sidebar find the Configuration section and click Secrets.

To store the deploy key as a secret file in the Semaphore environment, click Create a new Secret button.

Name the secret as match-secrets than enter your environment variables name and value to match Semaphore and Fastlane configuration.

MATCH_GIT_URL: your SSH Git URL.
MATCH_PASSWORD: password for decryption of the match certificates.
FASTLANE_USER: App Store developer’s Apple ID.
FASTLANE_PASSWORD: App Store developer’s password.

Enter a destination file path /Users/semaphore/.ssh/match-secrets to upload the SSH key that you previously generated id_rsa_semaphoreci on your computer. Click Save Changes.

This created the file ~/.ssh/match-secrets with necessary environment variables and made it accessible in Semaphore CI jobs.

Now that you created your secret key, go to your Semaphore project page, click Edit workflow button, select block to which you want to connect secret, in your case is the Build app block. On the right sidebar, scroll to Secrets section, click the arrow button and check the secret that you previously created match-secrets. Click Run the workflow button to add the secret.

After running this command, you will find your secrets inside the Semaphore Dashboard Secrets.

Our Build app block will look like below:

- name: Build app
  task:
    env_vars:
      - name: LANG
        value: en_US.UTF-8
    secrets:
      - name: match-secrets
    prologue:
      commands:
        - chmod 0600 ~/.ssh/*
        - ssh-add ~/.ssh/match-secrets

Let’s explain some commands that we repeated in our pipeline blocks:

cache restore: restores an archive that matches any given key. In case of a cache hit, retrieves the archive and make it available at its original path in the job environment.
bundle install: installs all Fastlane dependencies.
cache store: archives a file or directory specified by the path and associates it with a given key.
chmod 0600 ~/.ssh/*: reads and writes in files if it is the owner. It is all about permissions! You should be familiar with it in UNIX-like systems.
ssh-add ~/.ssh/match-secrets: gives the path of the key file as an argument to ssh-add to add the generated keys.
secrets: allows Semaphore to download certificates from a private repository configured with Fastlane. We needed to create a deploy key and add it to Semaphore secrets.

Deploy

After you do all your changes, commit it to get the CI/CD workflow started:

$ git add -A
$ git commit -m "Updates pipeline"
$ git push

Check your Semaphore dashboard and Voilá!

Now, you need to continuously push code to your branches, and App Store Connect processes the build. It becomes available in TestFlight, and you will be able to select it for your new iOS app version.

Let’s do a quick recap of what we did in this tutorial. Our pipeline:

Run all unit and UI tests.
Build the app and generate an ipa archive.
Generate automated App Store screenshots.
Upload the archived ipa and screenshots.

Open the finished project and explore the code on your own.

Download: Semaphore Demo iOS Swift Xcode

Next steps

There is much more that you can do with automated deployments. For example, you can add more steps to your pipeline configuration, such as getting your CHANGELOG file, pushing messages to Slack, automating build number incrementation, dSYM uploads to Crashlytics, and more.

After you take some time to configure CI/CD for your iOS applications, you can focus on writing code instead of manually delivering your app every time.

Have questions about this tutorial? Want to show off your results? Reach out to us on Twitter @semaphoreci.

iOS 13: The Top 5 Features Your App Needs Now

Amarildo Lucas — Wed, 11 Sep 2019 17:20:00 +0000

At WWDC 2019, Apple announced many improvements for iOS 13, such as the much-hyped Dark Mode and increased privacy capabilities. Apple tends to highlight apps in the App Store that implement new features, so now is the time to optimize your apps for the new iOS 13 features.

Today, I will highlight the five most important features that you, as an iOS developer, should plan to implement.

1. Dark Mode

Prepare your apps for the Dark Mode feature in iOS 13. Apple is putting so much emphasis on Dark Mode that the WWDC 2019 event environment was totally dark.

Before this update, you have likely seen apps emulating this capability by creating their own themes using the UIAppearence class. But now that Apple officially supports it, you can prepare for the iOS 13 Dark Mode that is seamlessly integrated throughout the system.

Screenshot of iOS 13’s Dark Mode functionality (image credit).

As Apple states:

When a user has Dark Mode turned on, all apps built with the iOS 13 SDK will run in Dark Mode.

If you need more time to make your apps optimized for Dark Mode, or if Dark Mode is not suited for your app, you can learn how to opt-out.

However, because the emphasis Apple placed on it at WWDC this year, I recommend adding it to your app’s interface if possible.

Dark Mode Best Practices

Choose adaptive colors for your UI by defining custom colors in your asset catalog.
For example, load a color value from an asset catalog by name

let labelColor = UIColor(named: “customControlColor”)

The images you create should look good in both light and dark appearances.
Update custom views with specific methods. One way to do this it is by moving your code to the updateLayer()method so that whenever the UI refreshes, the background color also changes.

You can read a complete introduction about implementing Dark Mode for iOS 13 with Apple’s official documentation here.

2. Sign in with Apple

In this update, Apple greatly improved its privacy features. Now, users can sign into applications using Apple’s native sign-in feature, like they do with Facebook and Google’s authenticators. The Sign In with Apple feature, introduced in iOS 13, provides fast, easy sign-in without tracking. Users can simply tap a button and use their FaceID.

In iOS 13, users can sign into applications using the secure Sign In with Apple feature (image credit).

The difference from the new Apple authentication option lies in its privacy-conscious features. It keeps users’ data more secure and allows them to keep their activity hidden from advertisers.

Even better, whenever your app asks for a name and email address, you could choose not to ask. Or, if you prefer, you can allow Apple to create a randomized email address for your users. So, when your app sends a message to the user, it will go to their Apple ID email, so nobody knows their email.

Whether you should implement this, of course, depends on your business model. If it is possible for your business, though, this feature will communicate to your users that you are being transparent and secure with their data, without the interest to track them and send unsolicited emails or ads.

The main advantages of Sign In with Apple are that it:

Hides users’ emails, which may make them more willing to use your app.
Works everywhere, including browsers, watchOS, tvOS, and more.
Shows that you respect your users’ privacy and helps strengthen your brand.
Integrates built-in security without too much effort on your part as the developer.

If you want to implement this feature, take a look at the ASAuthorizationAppleIDButton class to create the Apple Sign in Button. This class allows different visual styles and labels. Then, it captures the results in the authentication request that it returns with data like UserID, Verification Data, Full Name, Verified email, Real User Indicator, Credential State, and more. Also, Password Autofill seemingly integrates with Apple Sign In.

You can learn more about Apple Sign In here.

3. Siri Shortcuts

If you’ve never integrated Siri into your application, now is the time to evaluate it. Siri’s functionality now offers a better voice experience, additional customization, and more. For example, a food delivery app can allow people to ask about the delivery status of their order, and an event app can remind users to leave on time for a party.

Depending on your app’s core features, you may find that Siri adds significant value to your user experience.

Take, for example, conversational shortcuts. Siri can now ask follow-up questions, which makes your app’s voice shortcuts even better. For example, when a user says “Order status,” you can program Siri to ask which order the user is referring to for clarification.

One possible reason Siri adoption has been low among consumers is that users must navigate to Siri’s settings to record their own custom voice commands. With iOS 13, developers can suggest a voice command within the app and allow users to create it with a tap of a button. This eliminates the need for users to manually record their custom voice commands and makes it easier for them to interact with your app.

Consider adding a Siri Shortcut button for recurrent tasks in your app, such as placing an order or checking the status of something. Take some time to explore Siri’s updates using the SiriKit documentation.

4. SwiftUI

SwiftUI is a user interface toolkit that lets you design apps in a declarative way. This means that you can write code that clearly states what you want it to do. It is natural to write and work seamlessly with the new Xcode design tools, keeping your code and design in synchronization.

Josh Shaffer demonstrating SwiftUI’s interface at WWDC 2019 (image credit).

One of the things that first impressed me about SwiftUI is how it merges the benefits of Storyboards and code at the same time. For example, the code updates as you drag and drop UI elements into the canvas. This can help in code organization and fix the massive view controller problem.

Another advantage is that SwiftUI is a cross-platform, truly native toolkit. It allows your apps to directly access each of Apple’s operating systems with a small amount of code and an interactive design canvas.

For everything that I previously highlighted with SwiftUI, I recommend only experimenting with it for now rather than quickly putting it into your production codebase. It is the first step from Apple to include these new intuitive design tools that make building interfaces as easy as dragging and dropping. But you should take care to experiment first, decide later!

5. Core NFC

Core NFC is likely the most difficult feature that I recommend, but it will open up your application’s ability to connect to the physical world.

Using Core NFC, your app could read Near Field Communication (NFC) tags to give users more information about their physical environment and the real-world objects in it. Imagine the possibilities!

So, using Core NFC, your app might give users information about products they find in a store or exhibits they visit in a museum.

Apple improved the use of Core NFC this year by adding the ability to read contactless smartcards, passports, and other government-issued IDs on iPhone 7 devices and up.

To use Core NFC, you need to enable Xcode capability, use one of the Core NFC sessions objects like NFCTagReaderSession or NFCNDEFReaderSession and receive tags in discovery callbacks. Connect to a tag to perform operations, and then invalidate the session.

This can sound a bit confusing if you have never worked with NFC before. To get started (and inspired by the possibilities), I recommend reading some of Apple’s documentation.

Faster, simpler app development for iOS 13

Remember, Apple often highlights applications in the App Store that incorporate the top features and ideas from their latest updates. If you are looking to grow your app’s discoverability and be among the top-ranking apps, this could be your chance.

If this all sounds overwhelming, automating some parts of your development process can help you focus on development and set repetitive tasks on auto-pilot.

One way to do this is by using iOS Continuous Integration and Continuous Delivery (CI/CD). Semaphore just finished its initiative to support iOS 13, so now you can use our CI/CD platform to compile and test your iOS applications.

Start with simple things first, and feel free to reach out to the Semaphore team (@semaphoreci) on Twitter if you have any questions!

Continuous Integration and Continuous Delivery with SemaphoreCI and Fastlane for iOS apps

Amarildo Lucas — Mon, 12 Aug 2019 17:01:14 +0000

When you develop mobile apps, you manage the process of the app publication manually, using Xcode Organizer, after following some steps like signing, test, build, archive and deploy your build, then change versions and send new builds again and again to the AppStore.

If you generate your builds daily, this process is tedious and tiring. So, soon or later, you will ask yourself: — How could I automate all this proccess? The answer to this question becomes essential to your development and deploy flow, it's essential to have a quick feedback loop to iterate when deploying your builds.

Using SemaphoreCI and Fastlane it's a great choice to build products at high velocity. Whenever you push your code to your remote repository, SemaphoreCI will automatically run your custom build, test and deploy pipeline.

So, let’s start playing with some configuration and set up our first continuous integration flow.

Introducing the project

The steps that we will follow in this tutorial to use our Continuous Integration pipeline is going to look like this:

1. Clone SemaphoreCI Swift demo project from Github
2. Configuring SemaphoreCI pipeline
3. Understanding the configuration of the files in our project
4. Push our first build with Continuous Integration

Clone SemaphoreCI Swift demo project from Github

In order to continue with this tutorial, you should grab a copy of the SemaphoreCI demo project from GitHub and clone it to your computer.

We will use along the tutorial the following tools:
1. Git
2. Xcode
3. Fastlane
4. SemaphoreCI

git clone git@github.com:semaphoreci-demos/semaphore-demo-ios-swift-xcode.git

Note: I recommend to you, to fork the project and clone from your forked repo.

Configuring SemaphoreCI pipeline

Go to your SemaphoreCI dashboard and create a new project. Select a repository semaphore-demo-ios-swift-xcodeand connect to SemaphoreCI.

At this moment, you will see an empty connected project. This is because we didn’t push anything to the project yet.

On your cloned project, open .semaphore/semaphore.yml file. This is the configuration file to run your pipeline every time that you push your code. The file is well commented and you need to change it according to your own necessities.

.semaphore/semaphore.yml

# Use the latest stable version of Semaphore 2.0 YML syntax:
version: v1.0

# Name your pipeline. In case you connect multiple pipelines with promotions,
# the name will help you differentiate between, for example, a CI build phase
# and delivery phases.
name: Semaphore iOS Swift example with Fastlane

# An agent defines the environment in which your code runs.
# It is a combination of one of available machine types and operating
# system images.
# See https://docs.semaphoreci.com/article/20-machine-types
# and https://docs.semaphoreci.com/article/120-macos-mojave-image
agent:
  machine:
    type: a1-standard-4
    os_image: macos-mojave

# Blocks are the heart of a pipeline and are executed sequentially.
# Each block has a task that defines one or more jobs. Jobs define the
# commands to execute.
# See https://docs.semaphoreci.com/article/62-concepts
blocks:
  - name: Run tests
    task:
      # Set environment variables that your project requires.
      # See https://docs.semaphoreci.com/article/66-environment-variables-and-secrets
      env_vars:
        - name: LANG
          value: en_US.UTF-8
      prologue:
        commands:
          # Download source code from GitHub:
          - checkout

          # Restore dependencies from cache. This command will not fail in
          # case of a cache miss. In case of a cache hit, bundle  install will
          # complete in about a second.
          # For more info on caching, see https://docs.semaphoreci.com/article/68-caching-dependencies
          - cache restore gems-$SEMAPHORE_GIT_BRANCH-$(checksum Gemfile.lock),gems-$SEMAPHORE_GIT_BRANCH-,gems-master-
          - bundle install --path vendor/bundle
          - cache store gems-$SEMAPHORE_GIT_BRANCH-$(checksum Gemfile.lock) vendor/bundle
      jobs:
        - name: Fastlane test
          commands:
            # Select an Xcode version, for available versions
            # See https://docs.semaphoreci.com/article/120-macos-mojave-image
            - bundle exec xcversion select 10.3
            # Run tests of iOS and Mac app on a simulator or connected device
            # See https://docs.fastlane.tools/actions/scan/
            - bundle exec fastlane test

  - name: Build app
    task:
      env_vars:
        - name: LANG
          value: en_US.UTF-8
      prologue:
        commands:
          - checkout
          - cache restore gems-$SEMAPHORE_GIT_BRANCH-$(checksum Gemfile.lock),gems-$SEMAPHORE_GIT_BRANCH-,gems-master-
          - bundle install --path vendor/bundle
          - cache store gems-$SEMAPHORE_GIT_BRANCH-$(checksum Gemfile.lock) vendor/bundle
      jobs:
        - name: Fastlane build
          commands:
            - bundle exec xcversion select 10.3
            # Gym builds and packages iOS apps.
            # See https://docs.fastlane.tools/actions/build_app/
            - bundle exec fastlane release

If you try to push your code at this moment, your pipeline wouldn’t work yet and will fail. You need to configure your keys and secrets to allow SemaphoreCI to integrate with your project.

To add a deploy key to your Semaphore project you will need to create secrets to add to your pipeline configuration file. So, let's store the deploy key as a secret file in the SemaphoreCI environment.

If you have not installed the sem command-line tool that we are using in this tutorial, this is a good time to install it, see the sem reference and follow the instructions.

$ sem create secret your-fastlane-ios-certificates-repo -f id_rsa_semaphoreci:/Users/semaphore/.keys/your-fastlane-ios-certificates-repo

You will see the following message on the terminal, Secret ‘fastlane-ios-certificates-repo’ created.. This means that everything worked as expected.

id_rsa_semaphoreci it's your ssh file for SemaphoreCI. Upload it to GitHub so you can deploy your code without further problems.

In our case:

ssh-keygen -t rsa -f id_rsa_semaphoreci
cd ~/.ssh/id_rsa_semaphoreci.pub

Copy and paste to Github SSH keys configuration.

Next, add the URL for the certificates repository and the encryption password as environment variables that will be accessible in SemaphoreCI. I recommend also adding the App Store developer account’s credentials to the same secret.

$ sem create secret fastlane-env \
  -e MATCH_GIT_URL=“<your ssh git url>” \
  -e MATCH_PASSWORD=“<password for decryption>” \
  -e FASTLANE_USER=“<App Store developer’s Apple ID>” \
  -e FASTLANE_PASSWORD=“<App Store developer’s password>”

After run this command, you will find your keys in configuration secrets inside SemaphoreCI dashboard.

Updates your .semaphore/semaphore.yml file with your keys and secrets.

jobs:
        - name: Fastlane build
        commands:
            - chmod 0600 ~/.keys/*
            - ssh-add ~/.keys/*
            - bundle exec fastlane release
secrets:
        - name: fastlane-env
        - name: fastlane-ios-certificates-repo

Understanding the Fastlane Configuration

When you open the demo project folder, you will see that you have a fastlane folder with some files inside. This folder was added after we installed and run fastlane for the first time. To understand more about the process of fastlane installation and configuration you should read this introductory article.

Let's go with the steps that usually you will take.

1. Install fastlane
2. Configure fastlane files
3. Test if everything is working

As fastlane describes in their own website:

Fastlane is the easiest way to automate beta deployments and releases for your iOS apps. It handles all tedious tasks, like generating screenshots, dealing with code signing, and releasing your application.

It also supports other platforms.

Install the latest Xcode command line tools if you haven’t installed yet.

xcode-select —install

Install fastlane.

# Using RubyGems
sudo gem install fastlane -NV

# Alternatively using Homebrew
brew cask install fastlane

After Fastlane installation, run the following command.

fastlane init

Fastlane will automatically detect your project and ask for any missing information. In our case, these folders and files installed by fastlane exists as we downloaded from the demo project in Github. Depending on what kind of setup you choose, different files will be set up for you out of the box.

The most interesting file is fastlane/Fastfile, which contains all the information that is needed to distribute your app.

Our fastlane current folder. Again, the files are well commented, so I will not give further explanations about each of them.

fastlane/Appfile

# For more information about the Appfile, see:
#     https://docs.fastlane.tools/advanced/#appfile

app_identifier "***" # The bundle identifier of your app
apple_id "***" # Your Apple email address
team_id "***" # Developer Portal Team ID

fastlane/Fastfile

# This file contains the fastlane.tools configuration
# You can find the documentation at https://docs.fastlane.tools
#
# For a list of all available actions, check out
#
#     https://docs.fastlane.tools/actions
#
# For a list of all available plugins, check out
#
#     https://docs.fastlane.tools/plugins/available-plugins
#

# Uncomment the line if you want fastlane to automatically update itself
# update_fastlane

default_platform(:ios)

platform :ios do

  before_all do
    # installed via the semaphore plugin with `fastlane add_plugin semaphore`
    setup_semaphore
  end

  desc "Run Tests"
  lane :test do
    scan
  end

  desc "Deploy a new version to the App Store"
  lane :release do
    match(type: "appstore")
    gym(export_method: "app-store") # Build your app - more options available
    deliver(force: true)
  end
end

fastlane/Gymfile

# For more information about this configuration visit
# https://github.com/fastlane/fastlane/tree/master/gym#gymfile
#
# In general, you can use the options available
# fastlane gym --help

# Remove the # in front of the line to enable the option

scheme "HelloWorld"

sdk "iphoneos12.4"

output_directory "./"

fastlane/Matchfile

git_url("https://github.com/amarildolucas/fastlane_certficates")

storage_mode("git")

type("appstore") # The default type, can be: appstore, adhoc, enterprise or development

# app_identifier(["com.amarildolucas.com"])
# username("***") # Your Apple Developer Portal username

# For all available options run `fastlane match --help`
# Remove the # in the beginning of the line to enable the other options

# The docs are available on https://docs.fastlane.tools/actions/match

fastlane/Pluginfile

# Autogenerated by fastlane
#
# Ensure this file is checked in to source control!

gem 'fastlane-plugin-semaphore'

This is everything we need to set up and deploy our first build with continuous integration. The code is very specific and self-explanatory. You just defined 2 different lanes, one for your test deployment, one for App Store release. To release your app in the App Store, all you have to do now is push your code.

Note: Ensure that Xcode "automatically manage signing" is unchecked in Xcode. And that your Signing (Release) contains the match AppStore provisioning profile selected.

Some considerations

Gemfile

It is recommended that you use a Gemfile to define your dependency on fastlane. This will clearly define the used fastlane version, and its dependencies, and will also speed up using fastlane.

Our current Gemfile:

source 'https://rubygems.org'

gem "fastlane"
gem "xcode-install"
gem "cocoapods"

plugins_path = File.join(File.dirname(__FILE__), 'fastlane', 'Pluginfile')
eval_gemfile(plugins_path) if File.exist?(plugins_path)

Setting up Fastlane Match

You can use fastlane match to manage code signing. We use it in our fastlane setup.

To set up the match, you’ll need a private Git repository. Follow the documentation and run the init command from the root directory of our project and follow the instructions shown in the terminal.

bundle exec fastlane match init

In our case, our Matchfile exists from the cloned demo project in Github. So, run fastlane match without init to get all required keys, certificates and provisioning profiles installed to your project. 🙌

Note:

Private information like API keys or deploy credentials shouldn’t be written in the pipeline definition file or elsewhere committed to source control. On Semaphore you define these values as secrets using either the sem CLI or through the web interface (Configuration part of the sidebar -> Secrets). Secrets are shared by all projects in the organization. — Semaphore Team

Build your project and run fastlane to check if everything that we did it until now is working as expected.

If you see the message [10:28:38]: fastlane.tools finished successfully 🎉, celebrate 🎉.

Now, we just need to push our code to GitHub, and SemaphoreCI will run the CI/CD pipeline for us.

git add -A
git commit -m "setup semaphore"
git push origin master

After you push your code to master branch in GitHub, your semaphore pipeline will run for the first time. If you click in the commit link, you can see all the processes (steps) in a beautiful layout components separated the steps of your pipeline configuration.

Voilá! Now you just need to continuously push code to your branches and App Store Connect processes the build, and it becomes available in TestFlight and you will be able to select it for your new iOS app version.

Conclusion

There is much more that you can do with automated deployments. CI/CD pipeline has a lot of advantages, more than from the steps we follow through this tutorial. You can add more steps to your pipeline configuration, like get your CHANGELOG file, push messages to Slack, automate build number incrementation, dSYM uploads to Crashlytics, etc.

After you take some time configuring, all this stuff will help you stay focused on writing code rather to manually deliver your app every time. So, your build updates are not stressful and tedious. You can inspect your code by adding tools in the process, for example to run static code reviews, linting, tests or any other important step that you could automate.

However, start with simple things first. If you've made it this far, congrats! 😃 I hope you found this post helpful.

Want to deliver continuously your iOS applications? Check outBuild, test and deliver your iOS apps with Semaphore CI/CD.

Automatic Reference Counting (ARC) in class instances

Amarildo Lucas — Sun, 07 Apr 2019 23:00:49 +0000

An introduction to ARC

In Swift language memory management works out of the box and you don't need even to think about it yourself.

In this article i'll share the basic about ARC. ARC just works! It's frees up the memory used by your class instances when their no longer needed.

By Apple words:

Every time you create a new instance of a class, ARC allocates a chunk of memory to store information about instance. Addictionally, when an instance is no longer needed, ARC frees up the memory used by that instance so that the memory can be used for other purposes insted.

Let's practice!!!

Let's see how this works with our previous music app idea example.

You have a class called Artist. We will play a little bit with code now.

class Artist {
    let name: String

    init(name: String) {
        self.name = name
        print("Artist \(name) is being initialized")
    }

    deinit {
        print("Artist \(name) is being deinitialized")
    }
}

We will now create an Artist instance and assign it to some variables.

var artist1: Artist?
var artist2: Artist?
var artist3: Artist?

artist1 = Artist(name: "Taylor Swift")

artist2 = artist1
artist3 = artist1

artist1 = nil
artist2 = nil

Because the instance in artist3 it wasn't nil, Artist instance it's never deallocated. You can check this by seeing the number of "Artist \(name) is being deinitialized" printed in the result in your console. And this happens because there is now a strong reference from artist1 to the new Artist instances. The third strong reference never was deallocated and so, the instance it's broken. So you need to change the line to artist3 = nil in order to fix the last strong reference.

Now lets learn about new references than strong, weak and unowned, by understanding how it's possible sometimes to have instance of a class that never gets to the point where it has zero strong references and this is known as strong reference cycle.

Here is where we defined some of our relationships between classes as weak or unowned insted of strong references.

A practical example about weak.

We have one class called Artist and other called Label.

class Artist {
    let name: String
    var label: Label?

    init(name: String) {
        self.name = name
        print("Artist \(name) is being initialized")
    }

    deinit {
        print("Artist \(name) is being deinitialized")
    }
}

The second class called Label.

class Label {
    let name: String
    weak var artist: Artist?

    init(name: String) {
        self.name = name
        print("Label \(name) is being initialized")
    }

    deinit {
        print("Label \(name) is being deinitialized")
    }
}

Let's play with some initialization. Below is the result!

var artist: Artist?
var label: Label?

artist = Artist(name: "Taylor Swift")
label = Label(name: "Sonic Music")

artist!.label = label
label!.artist = artist

artist = nil
label = nil

As you can see, when we pass nil to both variables, the strong reference not drop to zero and the instance it's not deallocated. Neither deinitializer was called and nothing it's printed in console. This can cause memory leak and other problems to your apps. I see this happening a lot while people work with instances of UITableView delegate methods or when try to capture values inside Clocures. We will expand more about these topics in future articles.

So, how we break this?

weak weak weak!

In this case because we can have an Artist without a Label or Label without an Artist, it's possible to use weakreference. Because the lifetime of Label can finish first than the Artist in this context, we use weak references.

We use weak references when the other instance has a shorter lifetime, this mean, when the other instance can be deallocated first.

In the previous example we just need to change our class by adding the weak reference before the Artist declaration.

weak var artist: Artist?

The Artist instance still has a strong reference to the Label instance, but the Label instance has now a weak reference to the Artist instance.

Now, if in our test we add artist = nil, we will see a different result in console and instances being deallocated. Try yourself a litle bit!

So when to use the `unowned reference` then?!

We use it when the other instance has the same lifetime or longer lifetime.

In the below quick example, you can see two classes and understand their relationship. An Artist can have zero or more Albums but an Album can't exists without an Artist.

class Artist {
    let name: String
    var album: Album?

    init(name: String) {
        self.name = name
        print("Artist \(name) is being initialized")
    }

    deinit {
        print("Artist \(name) is being deinitialized")
    }
}

class Album {
    let title: String
    unowned let artist: Artist

    init(title: String, artist: Artist) {
        self.title = title
        self.artist = artist
        print("Album \(title), Artist \(artist.name) is being initialized")
    }

    deinit {
        print("Album \(title) is being deinitialized")
    }
}

This is a great scenario to use the unowned reference. Because an Album will always have an Artist, we use the unowned reference to avoid strong reference cycle in the defined property. You can just update the Album class with

unowned let artist: Artist

See some results and please try different inputs to test diferrent outputs to better understanding.

Always check wether the deinitializer was called or not.

var artist: Artist?
var album: Album?

artist = Artist(name: "Taylor Swift")
artist!.album = Album(title: "Fearless", artist: artist!)

artist = nil

That's it.

Resources

While there is a lot to find on the internet about ARC, I mainly used the Apple Swift Book and it is very clear and complete.

https://docs.swift.org/swift-book/

I hope you enjoyed the post and if so, please follow me because more content will come soon. I'll write more about memory management in the next articles.

Also consider following me on Twitter? 😬 @amarildulucas

Note: Please, english isn't my native language, so feel free to send me any feedback about typos or anything.

Swift For-In Loops

Amarildo Lucas — Fri, 05 Apr 2019 20:08:14 +0000

In Swift language we use the for-in loop to iterate over a sequence. A sequence contains items such Array elements, Ranges of numbers or Characters in a String for example.

Let's quickly experiment with some code. You can iterate a genres of music Array like this for example:

// Iterate genres
let genres = ["Ambient", "Dubstep", "Electronic", "Hip Hop", "Jazz"]
print("Choose a genre:")
for genre in genres {
  print("\(genre)")
}

As we can see, we iterated over an Array printing every genre inside. We can go further and try the same using a Dictionary insted of an Array.

Now we have music titles with a file type.

// Iterate dictionaries
let titleWithAudioTypes = ["Castle in the Hill": "MP3", "Different seas": "WAV", "See you again": "FLAC"]
for (title, audioType) in titleWithAudioTypes {
  print("\(title).\(audioType.lowercased())")
}

Above, each item in the Dictionary is returned as (key, value) pairs.

Now let's say that we want to put a sound to repeat five times. You could use for-in loops with numeric Ranges to achieve this.

// Iterate ranges
let soundTitle = "See you again.mp3"
let soundRepeats = 5
for time in 1...soundRepeats {
  print("Repeating \(soundTitle): \(time) time(s)")
}

The key here is the closed Range operator (...). Most of the times when you don't need the constant inside the loop, for example time in for time in (...) you can ignore the values by using an underscore _ in place of a variable name. time it's implicity declared by its inclusion in the loop declaration.

You can read more about for-in loops in Swift on Apple Swift Book.

Forem: Amarildo Lucas

All SwiftUI Scene Types Noted

Discover the latest SwiftUI scenes to help you present windows within your apps.

Things to take in mind:

Sketch Note: SwiftUI App Structure

CustomPresentationDetent Protocol Implementation in SwiftUI for Modal Presentations

What you will learn

Getting started with the starter project

Create PresentationDetent extension

CustomPresentationDetent implementation

Summary

Navigation App Architecture on Apple eyes

References

@discardableResult

👉🏿 You need @discardableResult.

🙌🏿

iOS CI/CD: Continuous Integration and Continuous Delivery Explained

The importance of CI/CD for iOS developers

The DevOps Role

Principles of iOS CI/CD

Use Static Code Analysis

Keep the Code Deployable

Notify your Team

Design for Iterative Releases

The top benefits of CI/CD for iOS

1. Build faster

2. Detect problems early

3. Provide effective feedback

4. Automate the testing process

5. Build deployment logs

Best practices to remember for iOS CI/CD

1. Keep your Pipeline Fast

2. Run Code Analysis Early

3. Separate Build Configurations

4. Automate Your Builds

5. Deploy Only Through the Pipeline

6. Maintain Similar Environments

7. Monitor the Pipeline

An iOS CI/CD workflow example

Getting Started with iOS CI/CD

Choosing the Right iOS CI/CD Platform

Summing Up

Tutorial: Build, Test, & Deploy an iOS App with CI/CD

How can we automate this entire process?

Continuous integration with Semaphore

Setting up Semaphore for an iOS project

Version

Agent

Blocks

Continuous Deployment with Semaphore

Configure your keys and secrets

Deploy

Next steps

iOS 13: The Top 5 Features Your App Needs Now

1. Dark Mode

Dark Mode Best Practices

2. Sign in with Apple

3. Siri Shortcuts

4. SwiftUI

5. Core NFC

Faster, simpler app development for iOS 13

Continuous Integration and Continuous Delivery with SemaphoreCI and Fastlane for iOS apps

Introducing the project

Clone SemaphoreCI Swift demo project from Github

Configuring SemaphoreCI pipeline

Understanding the Fastlane Configuration

Some considerations

Gemfile

Setting up Fastlane Match

Conclusion

Automatic Reference Counting (ARC) in class instances

An introduction to ARC

Let's practice!!!

A practical example about weak.

weak weak weak!

So when to use the unowned reference then?!

Resources

Swift For-In Loops

👉🏿 You need `@discardableResult`.

So when to use the `unowned reference` then?!