DEV Community: leogdion

Swift Packages – Dependency Management of the Future

leogdion — Wed, 26 May 2021 11:12:18 +0000

Package Management has been around for decades. There’s everything from APT to Maven to chocolatey. For those who work in the Apple space we are probably more familiar with Cocoapods and Homebrew. However since the introduction of Swift, the Apple team has given us a new package manager: Swift Package Manager.

In this article, I'll cover:

what iOS and other Swift developers can use
the advantages of SPM (Swift Package Manager) from its predecessors

First, let's get into why you'd want to use any package manager in the first place.

Modularity and Reuse - Benefits of Package Management

One key component of package management is the ability to share code or an executable - whether that's publicly or just within your internal dev team.

Part of doing that is breaking your code into separate pieces. This is where package managers encourage modularization. In other words components can be separated out, tested properly, and used by others.

Once you’ve separated that piece of functionality, you can include support across a variety of devices and operating systems. In the Apple ecosystem, this could mean supporting not only the iPhones but anything from Linux servers to the Apple Watch.

Another nice feature of package management is that you can lock onto specific versions. Usually you can specify a semver compatible version number related to a version tag or even a branch name. Let's get into the different package managers for developers in the Apple ecosystem.

What Came Before... and is Still Around

Swift Package Manager is fairly a new addition for Swift developers let alone iOS and macOS developers. Let's talk about what what has come before for developers.

Carthage has been around since the advent of Swift. Carthage really specializes in building the binary frameworks and sharing those within your project. Before Carthage, there was CocoaPods which has been around since the early days of Objective-C.

One drawback is that Cocoapods is built in Ruby and is therefore dependent on having the correct versions of Ruby installed while Carthage is built in Swift. Another drawback for Cocoapods is that it requires modification of your Xcode projects and workspaces. Carthage gets around this by having the user add the built frameworks the manually the first time they integrate it. If you are interested in some of the choices where Carthage differs from Cocoapods, check out this piece the Carthage README.

Lastly, if neither works for your project, there's git submodules. Git Submodules are the most difficult to deal with, but perhaps the most versatile. They simply require an available git repo to link to a subdirectory. If you plan editing your dependency, git submodules may be required.

If you are going to use a package manager, choose one at best and stick with it. However your best bet is migrating to Swift Package Manager.

Why Swift Package Manager?

Swift Package Manager brings plenty of benefits along with it. Along with it's versatile handing of versioning, SPM (Swift Package Manager) is natively supported in Swift. While tools like CocoaPods require Ruby and other Gem dependencies, there's no need with SPM. SPM simply requires either Swift or Xcode be installed on your macOS or Linux machine.

SPM is also open-source while also being supported by Apple. This means you get the benefits of seeing how something works and being open to the community as well as in Apple's best interest to support it.

Really it comes down to whether your current line of dependencies support SPM. At this point, the list of Cocoapods and Carthage packages which also support SPM continues to grow as SPM expands its support for features like binary packages (i.e. XCFrameworks).

Not only does SPM provide benefits in your Xcode projects but also in the way you modularize and share your code.

Why Publish with Swift Package Manager?

There are plenty of reasons to break apart your application or even publish your library or executable via Swift Package Manager. For one thing, it becomes easier to build your application completely in Swift - from server to device.

Full Stack Swift

For instance, you can build your supporting server application in Swift whether that’s Vapor, Lambda, Smoke, or Hummingbird. By doing that, you can share code between client (iOS application) and server. Specifically Codable models can be shared on both iOS and the server. Even if you have an existing server, you can build a mock server in Swift for testing.

    // an example of sharing server-side and client-side code via SPM

    // HeartwitchKit/WorkoutData.swift
    public struct WorkoutData {
      public let heartRate: Double?

      public init(heartRate: Double? = nil) {
        self.heartRate = heartRate
      }

      public func updated(with new: WorkoutData) -> WorkoutData {
        let heartRate = new.heartRate ?? self.heartRate
        return WorkoutData(heartRate: heartRate)
      }
    }

    extension WorkoutData: Codable {}

    // HeartwitchKitServer/WorkoutData
    import Vapor
    extension WorkoutData: Content {}

If you are going the route of building both ends of your application in Swift, SPM is the only way to go. In fact for parts of your code that can be abstracted away from the device, SPM has advantages over Xcode when it comes to testing.

Testability

The ease of testing through SPM is really nice as well. Especially when it’s difficult and slow to do in simulator. For instance before Xcode 12.5 supported watchOS testing, it was nearly impossible to run unit tests for watchOS.

However by having most of your Apple Watch application code in a Swift package, I can easily test code which doesn't require watchOS specifically. This circumvents the issue but also makes it easier without needing an actual device or via simulator.

In spots where code is only applicable and available on the watch, such as SwiftUI or HealthKit code I can use a combination of preprocessor directives to mark availability:

    // using canImport and os to disable applicable code

    #if canImport(HealthKit)
      import HealthKit

      extension HKHealthStore: HealthInterface {
        public func workout(withConfiguration configuration: WorkoutConfiguration) throws -> Workout {
          let hkConfig = HKWorkoutConfiguration()
          hkConfig.activityType = configuration.activityType.healthKitType
          #if os(watchOS)
            return try HealthKitLiveWorkout(fromHealthStore: self, withConfiguration: hkConfig)
          #else
            return try HealthKitWorkout(fromHealthStore: self, withConfiguration: hkConfig)
          #endif
        }
      }
    #endif

Not only that but as I develop a server-side application I may not want to run the watchOS application every time to test capabilities on the server. This is where refactoring into a Swift package is also useful. By having a library which contains most of my watchOS code, I can simulate the heart rate in the Apple Watch application by creating a simple command line application.

Command Line Tools

SPM allows me to duplicate the functionality of Heartwitch, my watchOS app, into a command line tool which replicates the heart rate sensor feature. This makes it easier to test the server application without having to run the Heartwitch app on my Apple Watch or via simulator.

One of my favorite tools out there is the Swift Argument Parser by the Swift team.

Swift Argument Parser builds on the great ideas from Swift UI (i.e. Property Wrappers) and Codable and brings that to the command line. You can do things like subcommands, helpful feedback, options, and flags. In my case, I use it to enable faster server-side development. Specifically I built a command line tool to replicate the heart rate monitoring feature of the Apple Watch app and feed my server simulated heart rates.

Power of SPM

In this article we covered package management and the advantages of SPM over other managers. Consider using SPM and learning the ins and outs of integrating Swift Packages into your projects. If you are using Cocoapods or Carthage, consider migrating your applications over. In the next article, I'll talk about creating a Swift Package from scratch as well as the most important part - Package.swift - the Swift Package Manifest file.

Combine & CoreLocation, Part 3 - Integrations with flatMap

leogdion — Tue, 01 Sep 2020 15:50:34 +0000

In our previous post, I explained how to hook up our new CLManagerDelegate publishers for CLAuthorizationStatus to the ObservableObject using Combine. In this post, we be transforming the CLLocation publisher data into something useful using flatMap and the built-in publisher, Sequence.

Creating Publishers from Delegates
Using Function Reactive Programming to Transform Values
Understanding FlatMap and Built-In Publishers

Using Combine for Complex Transformations

While we can simply assign the value from the authorizationPublisher to our authorizationStatus property, locationPublisher requires more work.

class CoreLocationObject: ObservableObject {
  @Published var location: CLLocation?
  ...
}

protocol CLLocationManagerCombineDelegate: CLLocationManagerDelegate {
  func locationPublisher() -> AnyPublisher<[CLLocation], Never>
  ...
}

While our locationPublisher returns a [CLLocation] result, our location property is CLLocation?.

That is to say we are going to need to do some functional programming to transform the result of our publisher:

Turn the Array itself into a Sequential Publisher of each value
Use flatMap to return a new Publisher
Cast the CLLocation into the matching CLLocation? (i.e. Optional<CLLocation>)

Here is our result:

      locationPublisher
        // convert the array of CLLocation into a Publisher itself
        .flatMap(Publishers.Sequence.init(sequence:))
        // in order to match the property map to Optional
        .map { $0 as CLLocation? }
        // since this is used in the UI,
        //  it needs to be on the main DispatchQueue
        .receive(on: DispatchQueue.main)
        // store the value in the location property
        .assign(to: &$location)

Let’s break each of these steps down starting with Publishers.Sequence.

Built-In Publishers from Combine

Combine comes with several built-in Publishers we can use.

Just - single value
Future - handling asynchronous callbacks
Sequence - publishing individual values from a sequence in order

We already talked about Just which takes in a single value. Another popular built-in publisher to use with asynchronous calls is Future which takes in a result type for when a call is completed. In this case, we are using Sequence which transforms a sequence type object into a Publisher stream of sequential values. Therefore when CLLocationManagerDelegate receives multiple locations, the publisher acts as if each location from that array received in order.

However, as Just is a Publisher so is Sequence, therefore we can not use .map but .flatMap since we want the values from the Publisher not the publisher itself. flatMap is especially powerful in Combine since it allows us to integrate Publishers from multiple technologies.

Integrations in Combine

I’ve talked previously about what flatMap does in the functional sense whether that be Arrays or Optionals. The same goes for Publishers as well.

Here’s an example of a piece of code to download json from the Bacon Ipsum JSON API:

  let url = URL(string: "https://baconipsum.com/api/?type=all-meat&sentences=1&format=json")!

  let urlPublisher = URLSession.shared.dataTaskPublisher(for: url)
    .map(\.data)
    .decode(type: [String].self, decoder: JSONDecoder())
    .replaceError(with: [String]())
    .compactMap{ $0.first }

This uses the dataTaskPublisher available on URLSession and transforms it to a single String. Here is step-by-step how:

Create DataTaskPublisher from URL
Use the map function to get the data property from the tuple
Decode the JSON into an Array of Strings
In order to assign the value, we change the Failure type to Never. In this case, we are replacing each Error instance with an empty Array of Strings.
Lastly, we use compactMap to get the first string and therefore ignore all empty Arrays.

Depending on your app and the data you are looking for, you’ll want change the transformations and error handle but typically this is the basics for handling a data task in Combine.

Combine System Publishers with `flatMap`

Along with URLSession.dataTaskPublisher there are other System publishers available to use:

URLSession.dataTaskPublisher
NotificationCenter.publisher
Key Value Observation via NSObject.publisher
Timer.publisher

With this in mind, let’s use the Timer publisher and use flatMap to update our String from the Bacon Ipsum JSON API at a regular interval. Firstly, let’s create a Timer publisher:

let timerInterval:TimeInterval = 1.0
let timerPublisher = Timer.publish(every: timerInterval, on: .current, in: .default)
      .autoconnect()

In this instance, we are creating a Timer publisher on the current RunLoop using the default mode for every 1 second. Lastly is autoconnect which ensure the publisher connects when subscribed.

Now we can use flatMap to initiate a new dataTaskPublisher each second:

timerPublisher.flatMap {_ in urlPublisher }
      .receive(on: DispatchQueue.main)
      .assign(to: &$publishedStringProperty)

With this we can automate the assignment of the String value, as each dataTask is completed. In other words, our string property will update every second as the url is called.

Let’s again take a look at our code for updating CLLocation:

      locationPublisher
        // convert the array of CLLocation into a Publisher itself
        .flatMap(Publishers.Sequence.init(sequence:))
        // in order to match the property map to Optional
        .map { $0 as CLLocation? }
        // since this is used in the UI,
        //  it needs to be on the main DispatchQueue
        .receive(on: DispatchQueue.main)
        // store the value in the location property
        .assign(to: &$location)

By using Sequence to create a Publisher and flatMap to flatten and return the values from the Sequence Publisher, we have transformed the value from [CLLocation] to CLLocation without losing any data.

However the location property type and the Publisher result type must match. Therefore since our property takes into not having CLLocation as a possibility, we need to transform the CLLocation to an Optional<CLLocation> (i.e. CLLocation?).

Combine with other Delegates

While I've demonstrated how to use CoreLocation with Combine, this can be useful for other uses of Delegation APIs.

Recently, I've used these Publicists in my app, Heartwitch, which is an Apple Watch app for broadcasting your heart rate to a live stream, as you are playing games or doing presentations. Likewise with HealthKit workouts, I've used the same pattern of creating publishers.

...   
    public let coalesce: CoalescePublicist
    public let failurePublisist: FailurePublicist
    public let fullIdentifier: FullIdentifierPublicist
    public let metadata: MetadataPublicist
    public let optional: OptionalPublicist
    public let transition: TransitionPublicist
    public let workoutCreation: WorkoutCreationPublicist
    public let workoutDataUpdate: WorkoutDataUpdatePublicist
    public let workoutStart: WorkoutStartPublicist
...

This same pattern can be used with other Delegation APIs such as:

CoreBluetooth
UINotificationCenter
AVFoundation etc...

Other Resources

If you are interested in learning more about Combine, I highly recommend checking out:

Donny also appeared on my podcast EmpowerApps.Show:

Practical Combine with Donny Wals

EmpowerApps.Show

Your browser does not support the audio element.

1x initializing... ×

For code samples, check out my repositories here:

If you have any questions or comments on this series, reach out to me on Twitter.

Leo G Dion still @Home

@leogdion

The last on my series of posts on Combine and CoreLocation is out. In this one I explain:
🎞Built-in publishers like Just and Sequence
🗺Power of flatMap in Combine
🚜Using Publishers with other Delegation Pattern APIs
buff.ly/32Jlxn9

13:52 PM - 01 Sep 2020

0 3

If you are interested in learning more about Combine, follow me here on dev.to and I'll let you know when the next Combine or Swift article is out.

Combine & CoreLocation, Part 2 - Receiving & Handling Events

leogdion — Mon, 31 Aug 2020 13:02:35 +0000

In our previous post, we talked about how to build a Publisher Factory or Publicist. In this post, we'll talk about how receiving and handling Events in our ObservableObject from our new Publicist class.

Creating Publishers from Delegates
Using Function Reactive Programming to Transform Values
Understanding flatMap and Built-In Publishers

Receiving and Handling Events in our ObservableObject

Our ObservableObject needs to accomplish a few things to update our SwiftUI while listening to our CoreLocation publishers. First of all we need to:

Create the CoreLocation Manager
Create our CoreLocation Publicist
Connect the Publicist as the Delegate of the Manager
Create our Authorization Status and Location Publishers

With this in mind, here is how that looks:

class CoreLocationObject: ObservableObject {
  @Published var authorizationStatus = CLAuthorizationStatus.notDetermined
  @Published var location: CLLocation?

  let manager: CLLocationManager
  let publicist: CLLocationManagerCombineDelegate

  var cancellables = [AnyCancellable]()

  init() {
    let manager = CLLocationManager()
    let publicist = CLLocationManagerPublicist()

    manager.delegate = publicist

    self.manager = manager
    self.publicist = publicist

    let authorizationPublisher = publicist.authorizationPublisher()
    let locationPublisher = publicist.locationPublisher()
    ...

Next, we can actually deal with receiving and handling events from our Publishers. Firstly, let’s deal with the CLAuthorizationStatus.

Receiving and Handling Events with Sink and Assign

As far the CLAuthorizationStatus, there are two things we need to do when the authorization status changes:

Trigger Location Update when CLAuthorizationStatus is valid
Assign the CLAuthorizationStatus to our @Published CLAuthorizationStatus Property authorizationStatus

Using Sink For Calling Methods

Let’s first deal with triggering location updates by creating a method to begin those updates:

class CoreLocationObject: ObservableObject {
  @Published var authorizationStatus = CLAuthorizationStatus.notDetermined
  @Published var location: CLLocation?

  let manager: CLLocationManager

...

  func beginUpdates(_ authorizationStatus: CLAuthorizationStatus) {
    if authorizationStatus == .authorizedAlways || authorizationStatus == .authorizedWhenInUse {
      manager.startUpdatingLocation()
    }
  }
}

Our beginUpdate method will take in the CLAuthorizedStatus as it comes in from the Publisher. As a result, if the status allows for location update then it calls startUpdatingLocation on the CLLocationManager.

With this in mind, let’s connect the authorizationPublisher to the beginUpdates method:

class CoreLocationObject: ObservableObject {

  ...
  var cancellables = [AnyCancellable]()

  init() {
    let publicist = CLLocationManagerPublicist()

    ...

    let authorizationPublisher = publicist.authorizationPublisher()

    // trigger an update when authorization changes
    authorizationPublisher
      .sink(receiveValue: beginUpdates)
      .store(in: &cancellables)
    ...

In this case, we are using sink and passing a reference to our new method. sink returns a Cancellable which we’ll need to make sure is disposed properly. Therefore, we use .store to make sure that Cancellable is stored correctly in our cancelables\ Array.

Now we should be correctly starting location updates when permission is granted. Next, let’s store the CLAuthorizationStatus in our @Published property so we can display it in our SwiftUI view.

Receiving and Handling Events with Assign (in iOS 13 and iOS 14)

One of the first things you learn as an iOS developer using UIKit is the importance of making UI updates on the main dispatch queue. In other words, failure to do this results in incorrect UI updates or even crashing your app. Likewise, in SwiftUI, you need to specify UI updates on the main dispatch queue. Therefore we can use receive to ensure updates are on the main DispatchQueue.

...
      authorizationPublisher
        // since this is used in the UI,
        //  it needs to be on the main DispatchQueue
        .receive(on: DispatchQueue.main)
        ...

As far as assigning we have a few options, we can stick with sink to assign our value the published property:

...
      authorizationPublisher
        // since this is used in the UI,
        //  it needs to be on the main DispatchQueue
        .receive(on: DispatchQueue.main)
        .sink(receiveValue: {
          self.authorizationStatus = $0
        })
...

However, we could simplify this with assign:

...
      authorizationPublisher
        // since this is used in the UI,
        //  it needs to be on the main DispatchQueue
        .receive(on: DispatchQueue.main)
        // store the value in the authorizationStatus property
        .assign(to: &$authorizationStatus)
...

This new assign available in all the new 2020 OSes (iOS 14, macOS 11, watchOS 7, etc…) allows us to assign the value directly to the publisher using the & (for an in-out parameter) and $ (for the publisher).

Additionally no Cancellable is returned and therefore not needed to be stored.

Sink vs Assign when Receiving and Handling Events

Choosing the correct method can be difficult but here's some guidelines:

If you are doing some additional logic besides just assigning a value, use sink
For just assigning a value, use assign
When assigning a value which is being used directly by the UI (i.e. UIKit View or SwiftUI View), use .receive(on: DispatchQueue.main)
Make sure when using sink or the 2019 version of assign (i.e. assign(to:on:)), save the resulting Cancellable by using .store
When there's more than one AnyCancellable property, consider using a Set or Array for storing the Cancellables

In the next blog post, I'll cover some more advance functional programming techniques in Combine when we transform our CLLocation to something more useful.

Combine & CoreLocation, Part 1 – Publishers & Delegates

leogdion — Wed, 26 Aug 2020 21:03:38 +0000

Most of the APIs from Apple come from an era of Objective-C and the Delegation Pattern. With this in mind, the challenge is figuring how to adapt for SwiftUI. Specifically we want to create Publishers from delegates using Combine.

For instance, my app Heartwitch is an Apple Watch app for live streamers. In this case, It uses HealthKit which implants the delegation pattern frequently. Additionally, I am using newer technologies such as Vapor 4, Independent Watch Apps, and most importantly SwiftUI.

In this series of articles, I’d like to go into detail regarding the process of adapting an older API for Combine. Specifically we are going to be building a basic SwiftUI app which displays your latitude and longitude with CoreLocation. This includes:

Creating Publishers from Delegates
Using Function Reactive Programming to Transform Values
Understanding FlatMap and Built-In Publishers

For this part, we'll be getting into how to create a Protocol and Class which will act as a go-between for the Delegation Pattern and the Reactive Functional Programming of SwiftUI and Combine.

Gonna Delegate Like It’s 2009

For over a decade, Apple frequently used the Delegation Pattern for giving developers the ability to respond, update, and act in place of a UI object. This pattern has a plethora of benefits especially in Objective-C. However, with Swift and especially SwiftUI, this pattern becomes awkward.

This is where it becomes necessary to make a delegate respond in such a way that SwiftUI can handle updates.

With Apple’s older APIs, we typically see this:

protocol NSDelegate : NSObjectProtocol {
  func manager(_ manager: NSManager, doneWith data: AnyObject)
  func manager(_ manager: NSManager, grantedPermission: Bool)
}
class NSManager : NSObject {
  weak var delegate : NSDelegate?

  func requestAuthorization() {}
  func doThing () {}
}

In the case of CoreLocation we see this:

protocol CLLocationManagerDelegate : NSObjectProtocol {
  func locationManager(_: CLLocationManager, didUpdateLocations locations: [CLLocation])
  func locationManager(_: CLLocationManager, didChangeAuthorization status: CLAuthorizationStatus)
}
class CLLocationManager : NSObject {
  weak var delegate : CLLocationManagerDelegate?

  func requestWhenInUseAuthorization() {}
  func startUpdatingLocation () {}
}

In other words, we’ll need to create Combine Publishers which our ObservableObject can listen or react to. Once the ObservableObject reacts properly, then the View will update accordingly. In the end, we should see this in our application:

Before we setup our publishers, let's scaffold our View and ObservableObject.

SwiftUI Scaffolding

Let's first start by building our SwiftUI View. In this case, we'll be creating a SwiftUI view along with an ObservableObject.

struct LocationView: View {
  // CLLocationManager is basically a singleton so an EnvironmentObject ObservableObject makes sense
  @EnvironmentObject var locationObject: CoreLocationObject
  var body: some View {
    VStack {
      // use our extension method to display a description of the status
      Text("\(locationObject.authorizationStatus.description)")
        .onTapGesture {
          self.locationObject.authorize()
        }
      // use Optional.map to hide the Text if there's no location
      self.locationObject.location.map {
        Text($0.description)
      }
    }
  }
}

This LocationView will simply display one line with a description of the location with a line describing the CLAuthorizationStatus using this extension:

extension CLAuthorizationStatus: CustomStringConvertible {
  public var description: String {
    switch self {
    case .authorizedAlways:
      return "Always Authorized"
    case .authorizedWhenInUse:
      return "Authorized When In Use"
    case .denied:
      return "Denied"
    case .notDetermined:
      return "Not Determined"
    case .restricted:
      return "Restricted"
    @unknown default:
      return "🤷‍♂️"
    }
  }
}

Now let's go ahead and define our ObservableObject, named CoreLocationObject:

import Combine
import CoreLocation
import SwiftUI
class CoreLocationObject: ObservableObject {
  @Published var authorizationStatus = CLAuthorizationStatus.notDetermined
  @Published var location: CLLocation?
  init() { }
}

Lastly, make sure that you set the EnvironmentObject in your application using:

LocationView().environmentObject(CoreLocationObject())

Now, we have our scaffolding setup, let's plug-in CoreLocation.

Extending Delegates into Combine Publishers

With the Delegation Pattern, the Delegate (in this case CoreLocationManagerDelegate) will receive location updates. Therefore it is the ideal object to create publishers for our ObservableObject.

In order for our ObservableObject to react to CoreLocation changes, the delegate will have to create Publishers for us. With this in mind, I have extended to delegate to be a Publicist. That is to say the Delegate will also be a Publisher Factory.

protocol CLLocationManagerCombineDelegate: CLLocationManagerDelegate {
  func authorizationPublisher() -> AnyPublisher<CLAuthorizationStatus, Never>
  func locationPublisher() -> AnyPublisher<[CLLocation], Never>
}

In the case of our application, we are displaying the authorization status of Core Location as well as the latitude and longitude. Therefore, we only need two methods implemented for our publishers.

Here is the implementation of our new protocol:

class CLLocationManagerPublicist: NSObject, CLLocationManagerCombineDelegate {
  let authorizationSubject = PassthroughSubject<CLAuthorizationStatus, Never>()
  let locationSubject = PassthroughSubject<[CLLocation], Never>()
  func authorizationPublisher() -> AnyPublisher<CLAuthorizationStatus, Never> {
    return Just(CLLocationManager.authorizationStatus())
      .merge(with:
        authorizationSubject.compactMap { $0 }
      ).eraseToAnyPublisher()
  }
  func locationPublisher() -> AnyPublisher<[CLLocation], Never> {
    return locationSubject.eraseToAnyPublisher()
  }
  func locationManager(_: CLLocationManager, didUpdateLocations locations: [CLLocation]) {
    locationSubject.send(locations)
  }
  func locationManager(_: CLLocationManager, didFailWithError _: Error) {
    // Implement to avoid crashes
    // Extra Credit: Create a publisher for errors :/
  }
  func locationManager(_: CLLocationManager, didChangeAuthorization status: CLAuthorizationStatus) {
    authorizationSubject.send(status)
  }
}

Let’s breakdown how this class works.

The Power of Type Erasing Publishers

Our Publicist doesn’t need to hold onto any values. In the end, it solely serves the purpose of transforming data from the CoreLocationManager to the ObservableObject. For this reason, we’ll be using a PassthroughSubject for the CLLocation and CLAuthorizationStatus. That is to say, PassthroughSubject doesn't hold any values as they receive values but passes them on.

With the PassthroughSubject properties in place, our delegate can send the values received from the delegate methods to the subjects.

Creating our first publisher for CLLocation is fairly simple:

class CLLocationManagerPublicist: NSObject, CLLocationManagerCombineDelegate {
...
  let locationSubject = PassthroughSubject<[CLLocation], Never>()
  func locationPublisher() -> AnyPublisher<[CLLocation], Never> {
    return locationSubject.eraseToAnyPublisher()
  }
  func locationManager(_: CLLocationManager, didUpdateLocations locations: [CLLocation]) {
    locationSubject.send(locations)
  }
...
}

What’s important to realize is that we need to implement type erasure using eraseToAnyPublisher. The introduction of SwiftUI and Combine included improvements to Swift. These improvement allow for powerful transformations which can result in fairly complex Generic Types. For instance our authorizationPublisher has a return type AnyPublisher:

  func authorizationPublisher() -> AnyPublisher<CLAuthorizationStatus, Never> {
    return Just(CLLocationManager.authorizationStatus())
      .merge(with:
        authorizationSubject.compactMap { $0 }
      ).eraseToAnyPublisher()
  }

Without eraseToAnyPublisher, the return type would be:

Publishers.Merge<Just<CLAuthorizationStatus>, Publishers.CompactMap<PassthroughSubject<CLAuthorizationStatus, Never>, CLAuthorizationStatus>>

Likewise with the locationPublisher, the return type would be:

PassthroughSubject<[CLLocation], Never>

In the end, this makes creating Protocols and Return Types fairly complex. As far as the ObservableObject is concerned, it doesn’t care how the publisher is transformed but the result types returned.

Therefore our Protocol only needs a AnyPublisher return type. In the end, we can both simplify and hide the method of functional transformation using eraseToAnyPublisher. Likewise, the implementation calls eraseToAnyPublisher to reduce the return type and match the Protocol's method signature.

Now that we have figured out how to creating matching Publisher types, let’s transform CLAuthorizationStatus so it is usable within the view.

Transforming Authorization Status into a Publisher

While our locationSubject reflects the values from CoreLocation, the authorizationSubject will be out of sync from the reality of CoreLocation’s status. For this reason, we’ll need to write some code include the initial status along with whatever the PassthroughSubject receives.

  func authorizationPublisher() -> AnyPublisher<CLAuthorizationStatus, Never> {
    return Just(CLLocationManager.authorizationStatus())
      .merge(with:
        authorizationSubject
      ).eraseToAnyPublisher()
  }

While CoreLocationManagerDelegate sends updates to authorizationStatus, we need to have access to the initial status via CLLocationManager.authorizedStatus. Luckily, Combine includes a built-in Publisher for single values using Just.

Just gives us the initial value published however we need to include the remaining published values from our PassthroughSubject. For this reason, we can use merge to join the intial value with the result from the our authorizationSubject:

We have the publisher factories setup now!

Interested in learning more about Combine, check out my podcast episode with Donny Wals:

Practical Combine with Donny Wals

EmpowerApps.Show

Your browser does not support the audio element.

1x initializing... ×

What's Next?

In our next part in this series, we'll learn how to use this implementation in our ObservableObject CoreLocationObject. Specifically, we'll be getting into power of function programming within Reactive Functional Programming. Enjoy!

flatMap, Double Optionals, and Functional Programming

leogdion — Thu, 23 Apr 2020 11:50:08 +0000

A while ago I did an article on the basics of Optionals and how they work in Swift. However, it seems there's some confusion as to how one particular method works in Swift when it comes to a collection of Optionals: flatMap.

With all the talk regarding flattening the curve, today I want to explain exactly what it means to flatten in the context of functional programming. Additionally, it not only can be used on Arrays but single Optionals as well. In the end, using them correctly will make your code easier to read.

flatMap vs map and Generic

Before we dive into what flatMap does, let's talk about what flatten actually means. Most importantly, flatMap is typically a map coupled with a flatten operation. The flatten operation typically is used in the context of Generics, such as Arrays, Promises, Publishers, and even Optionals (remember Optionals are Generic enums).

Let's create our own Generic to show how this would work:

struct Foo<Value> {
  let value : Value
}

Here's a simple Generic Foo which contains a value. Therefore, let's add a simple map function in case the developer wants to convert the value into something else:

extension Foo {
  func map<Output>( _ callback: (Value) -> (Output) ) -> Foo<Output> {
    let output = callback(self.value)
    return Foo<Output>(value : output)
  }
}

Now we have simple map method which works similar to others, where the developer can convert the Foo into some other type. For instance:

let firstItem = Foo(value: 3.0)
let secondItem = firstItem.map{ $0.description }

In this case, we have a Foo<Double> which is converted into a Foo<String> using our new map function.

However there are instances where this can cause issues.

Arrays of Arrays

The simplest case where map doesn't quite do what you want would be when you need a flat list. For instance, let's say you want to get a flat list of books from their authors:

struct Author {
  ...
  let name : String
  let books : [String]
}

Then you have a list of authors and their books in JSON:

[
  {
    "Franz Kafka": [
      "Stories",
      "The Trial",
      "The Castle"
    ]
  },
  {
    "Fyodor Dostoevsky": [
      "Crime and Punishment",
      "The Idiot",
      "The Possessed",
      "The Brothers Karamazov"
    ]
  },
  {
    "Leo Tolstoy": [
      "War and Peace",
      "Anna Karenina",
      "The Death of Ivan Ilyich"
    ]
  },
  {
    "William Shakespeare": [
      "Hamlet",
      "King Lear",
      "Othello"
    ]
  }
]

Unfortunately, map would only return an Array of an Array or Jagged Array of books (i.e. [[String]]):

let authors : [Author] = ...
let books : [[String]] = authors.map {
  $0.books
}

As a result, we get:

[
  [
    "Stories",
    "The Trial",
    "The Castle"
  ],
  [
      "Crime and Punishment",
      "The Idiot",
      "The Possessed",
      "The Brothers Karamazov"
   ],...

However, this is where a flatMap would be useful:

let authors : [Author] = ...
let books : [String] = authors.flatMap {
  $0.books
}

Now, rather than returning an Array of Arrays, flatMap automatically flattens the result. Not only does this work with Arrays but other Generics as well. A great example of this is in use with asynchronous methods.

If you are interested in learning more about how SwiftNIO and Google Futures does this with Promises and Futures, check out my article on asynchronous programming here. Additionally Combine, which is frequently used with SwiftUI, contains a map and flatMap for its Publishers as well.

Besides Arrays, Promises, and Combine Publishers, there was one other Generic we are forgetting to cover which often can cause issues. If you have run into the elusive Type?? value then you have probably run into an instance where flatMap should be used on Optionals.

flatMap and the elusive Double Optional??

So let's say we have a generic function which returns an optional:

func maybe<T>(_ value: T) -> T? {
  Bool.random() ? value : nil
}

Then you've created a optional value:

let optionalValue : Int? = Int.random(in: 0...10)

Next, you decide to call that function which returns an optional on the option value and you end up with something that makes very little sense:

let optionalOptional : Int?? = maybe(optionalValue)

What is an Int??...?

As stated earlier an Optional is really another Generic type. Here's a small snippet of the Generic Enumeration behind the scenes:

public enum Optional<Wrapped> {
    case none
    case some(Wrapped)
}

As you can see the '?' is simply syntactic sugar. So for instance an Int? is really an Optional<Int>. Therefore, we can surmise that an Int?? is really a Optional<Optional<Int>>.

Therefore, we need to make sure that our result is flattened in order to use it. Luckily, Optional provides a flatMap function as well. For this reason, we can use Optional.flatMap to fix our result:

let betterOptionalValue : Int? = optionalValue.flatMap(maybe(_:))

By using flatMap, it flattens the result to return a single Optional. It's important to note, that optionalValue does not contain the ? suffix since we want to call flatMap on Optional<Int> as opposed to Int. Likewise, Optional also contains a map function for when your method will return a non-optional value and does not require flattening.

flatMap, parsing, and conversion

There are a few use cases where flatMap on an Optional are useful. For instance, when you are parsing a value, there are cases where you wish to throw an error depending whether the value is invalid or missing (i.e. nil). However in some instances, you don't care whether the value is invalid or nil and want to just return nil if it fails. In this case, flatMap fits perfectly well:

func parse (_ rawValue : RawType) -> ParsedType?

let parsedValue = optionalRawValue.flatMap(parse)

For instance, parsing UUID from a String, rather than:

let uuid : UUID?

if let uuidString = dictionary["VCS_UUID"] {
  uuid = UUID(uuidString: uuidString)
} else {
  uuid = nil
}

... we can use:

let uuid = dictionary["VCS_UUID"].flatMap(UUID.init(uuidString:))

Besides parsing, I've used flatMap in instances where I need to convert a successful Result or value to a SwiftUI View as well:

  var iconImage: some View {
    return self.icon.flatMap { icon in
      guard case let .image(name) = icon else {
        return nil
      }
      return name
    }.map {
      Image($0).renderingMode(.template)
    }
  }

In this case if the self View contains an icon with the case image then use the name and create templated Image for the View.

While there are instances where flatMap is useful, more often than not you may just wish to filter the Optional results from a map operation. This is where compactMap comes in.

flatMap vs compactMap

In many instances, you probably want simply remove Optionals from your Array or having a map return only non-Optional values. Before Swift 4.1, there was only one method for doing this as well as the traditional flatMap mentioned previously. Unfortunately as stated in the implemented proposal, this caused much confusion. Therefore compactMap was added in Swift 4.1.

While flatMap concerns the returning of a flat Array of values, compactMap is specifically for instances where you need to make sure the Array returned contains no Optional values. In effect, if the closure for each item can return multiple items then a flatMap is right; otherwise if the closure can return either no items (i.e. nil) or one then compactMap makes the most sense.

So for example, if we have Node struct and an Array of optional Nodes:

struct Node<Value> {
  let value : Value
  let children : [Node<Value>]
}

let items : [Node<Int>?]

Therefore, let's see what happens when we use a combination of flatMap and compactMap in various ways:

// returns an array with no Optionals
let array : [Node<Int>] = items.compactMap{ $0 }

// returns and array of array of Nodes
let arrayArray : [[Node<Int>]] = items.compactMap{ $0?.children }

// assumes same as previous compactMap and issues a warning
let arrayArrayWithWarning : [[Node<Int>]] = items.flatMap{ $0?.children }

// returns flat array of Nodes from children
let flatArray = items.flatMap{ $0?.children ?? [Node]() }

// returns flat array of Nodes from children as well
let flatCompactArray = items.compactMap{ $0 }.flatMap{ $0.children }

Most importantly, flatMap is not supposed to return a nil (otherwise the compiler assumes it's compactMap and issues a warning). Therefore, you can either use the nil-coalesce operator to return an empty Array or use compactMap beforehand to ensure there will never be nil.

flatMap and flattening the Optionals and Generics

In this article, you've learned a few key points with regards to flatMap and its relationship to Generics and specifically Optionals:

The term flatten in functional programming means to remove a secondary generic into a one-dimensional result such as returning a Value? rather than Value?? or [Value] rather than [[Value]]
flatMap is to be used when you have an Array of Arrays and wish to flatten those Collections into a simple one-dimensional Array
Use flatMap when you are returning a result of the same Generic type as opposed to map when you are just returning a value such as a Promise, Future, or Combine Publisher
flatMap is important for Optionals in removing Double Optionals (i.e. **Type??**) from your code
flatMap is also useful for Optional when you are mapping an Optional value and don't need to distinguish between a nil or invalid input value
compactMap is specifically for the removing nil results from an one-dimensional array
If a flatMap closure can return nil, return an empty Array instead

Feel free to reach out if you have any additional questions on Twitter @leogdion or signup for the newsletter below to get the latest tutorials and guides on Swift development.

What You Should Know About iOS Software Architecture

leogdion — Mon, 06 Apr 2020 15:39:36 +0000

You’ve made the decision to build your own iOS app. Therefore, you’ve started out with an idea based on a customer need. Also how the app will meet that need and what it will look like. It’s at this point you should think about iOS software architecture.

Software architecture is the term we use to describe how major components of an app work together. The structure and design of modern software are usually too complex to consider. Therefore, we use the term ‘architecture’ as an abstraction. In practice, ‘software architecture’ means “the parts of the app we need to get right.”

The reason well-planned architecture for your app is critical is that by investing time in planning, it pays off over time. In the end, you create a shared understanding between you and your developers. This includes how they structure and design the app. As a result, you are saving you time and money.

In this post, I cover three essential concepts for good iOS software architecture:

Patterns & Practices
Code Modularization
Code Quality

I’ll be explaining a bit about each, how you can put them in place for your app.

iOS Software Architecture Patterns

Choosing a certain architecture for your iOS app determines the design of different aspects of your software. Within that, it also determines what kind of design patterns you will want to use. A Pattern in the context of software is a common response to a recurring problem. It uses a common language to outline the elements needed to solve a software challenge.

Patterns are particularly useful when working with a large team of developers. They can make your developers substantially more efficient by using a refined approach to solving problems. Patterns ensure changes to the code are consistent and reduce risk for major changes.

Good use of Architecture Patterns makes it easy for developers to understand the software. In the end that makes it easy to change it. This means new features can be delivered faster, with fewer bugs, and therefore easier fixes.

There are a few architectural patterns that are very useful when making iOS apps:

Delegation and MVC with iOS Software Architecture

Delegation is a pattern we use in iOS user interface (UI) development for displaying tables of information in an app. The Model-View-Controller (MVC) pattern uses Delegation. Additionally, MVC is the most popular iOS Software architectural pattern for developing Apple apps. This is how it works:

A user performs an action within the user interface (ie View).
View passes it to the Controller to deal with.
The Controller makes decisions about what to do with the action it's been given. If needed, it makes changes to the state of the Model, which will change its data values in response.
The Controller then sees these new values and sets them for View.

Delegation allows you to control how the Controller provides both the data and the way that data needs to be displayed to View in the final step. This makes it easy to break apart the functionality of the code to display table information to your user the way you want.

Protocol-Oriented Programming

This is fundamental to developing any app written in Swift (ie all native apps for iOS). Protocols allow you to group together and separate functionality. Additionally it shows how data and their objects work together.

Protocols are useful tools for creating functionality for your app. Instead of building a whole new object (which you might with other kinds of architecture), you add different protocols until your objects can do what you want. Protocol-oriented programming means using an architecture where you design your app around protocols. This makes it easy to test the different parts of your app and use Test-Driven Development.

Functional Programming

Functional programming is the idea of having your app work based around information supplied to it and rules it must follow. What this means is you want the app to react to what your user is doing. In contrast other kinds of programming styles, such as Imperative which follow a set of instructions, this can be a challenge. For instance, if there are multiple data sources and multiple views. The result is an app that can adapt to your user’s behavior, which is always a desirable trait in a well-designed app.

Reactive Programming in iOS Software Architecture

This pattern has become popular with the introduction of SwiftUI, which encourages developers to use functional reactive programming. For this reason, Apple introduced the Combine framework and the Subscriber-Publisher model. Specifically, this allows you to sort and filter values into your UI. Additionally, it's also used with Model-View-ViewModel, which removes the Controller in the MVC pattern mentioned above. With Model-View-Model, the Controller is replaced with a ViewModel. Conversely, the ViewModel automates how the Model can be rendered directly into the View by making changes to the Model data and reacting accordingly. This is useful for iOS apps that need to use a resource library that isn’t written in Swift. It allows you to bridge from another programming language into Swift.

WWDC 2019 - Swift UI with Jason Anderson

EmpowerApps.Show

Your browser does not support the audio element.

1x initializing... ×

Why Code Modularity Matters in iOS Software Architecture

Another key component of great architecture is modularity.

Modularity is the idea that different parts of your app should be able to work independently of each other. As a result, this makes it easier to both test and reuse pieces of code in different parts of your app. Additionally, makes it easy to use the same piece of code for different platforms, so your iOS code could work on macOS too.

There are three ways I recommend for creating modularity in iOS app development:

Framework Targets

In Xcode (the development environment for macOS), Framework Targets are a way to easily move your app’s code from the testing environment where it was built to the production environment your users can see. Ordinarily, you have to swap out all the URLs and APIs from the testing version of your app to the production one. With Framework Targets, this is done automatically.

Projects and Workspaces

You have a specific piece of code that doesn’t fit into an existing framework but might be used in many apps. A way to deal with this is to have more than one project and workspace. This allows you to organize pieces of code like this and show how they are related to different development projects.

Swift Packages

The newest and simplest way to achieve modularity. Although limited to Swift and not compatible with older apps, Apple is encouraging a shift toward using only Swift for new apps. As a result, this means Packages will likely become the default to create modularity for iOS apps. If you are interested in learning how to use Continuous Integration with your Swift Packages, check out our developer article here.

Modularizing in Xcode with Abbey Jackson

EmpowerApps.Show

Your browser does not support the audio element.

1x initializing... ×

Why Maintaining Code Quality Matters

This isn’t so much about app architecture as it is the ability of other to maintain your code. If you have high-quality code, it will make development faster, easier, and cheaper.

There are a few are great ways to ensure high-quality code:

Test-Driven Development

I recently did a piece about Test-Driven Development (TDD), which you can find here. Committing to doing good testing and setting up a good testing environment is one of the most powerful things you can do to make your code top-notch.

Ensure Good Code Coverage

Code coverage, measured as a percentage, refers to how much of your app’s code is executed during testing. A high degree of code coverage indicates a low number of possible undetected bugs in your app. This is a great measurement for determining code quality, although you shouldn't be too strict about it. While it’s obviously great if you reach 100% coverage, it might come at a cost when there are more important things you could be doing to serve your users.

Complexity

In software development, there are two kinds of complexity we want to observe and measure:

Cyclomatic Complexity – this metric looks at the number of linear paths it is possible for data to take through your app’s source code. While there are going to be times when it's necessary to have many paths, you generally want to limit this kind of complexity. The reason is that more paths mean needing more test cases to make sure they all work, and more paths mean more opportunities for bugs.

Cognitive Complexity – this metric simply refers to how easy it is for people to understand your code. Easy-to-understand code is always going to be easier to maintain. This is especially true if the person who wrote the code and the person maintaining it are different people.

Overall, keeping your complexity low by limiting file and function length means adding features and fixing bugs takes less effort.

Managing Code Quality with Anne Cahalan

EmpowerApps.Show

Your browser does not support the audio element.

1x initializing... ×

Code Reviews

A code review is when someone other than the code’s creator reads the code, looking for errors or anything unclear. While simple to do, this often gets missed because it takes time to sit down and review code someone else has written —time you might feel you don't have. Having someone review what you’ve written is a great way of spotting mistakes and ensuring better-quality code.

Continuous Integration

This is something I’ve written about recently, explaining what Continuous Integration (CI) is and why it’s important. If you are able to deploy the code frequently, it means you can deliver features more rapidly. Additionally, if there are problems or bugs, you will discover them faster and will be easier to fix. Therefore, using CI is a great way to shorten the time it takes to get feedback from your users.

The Components of Good iOS Software Architecture

By thoughtfully choosing an architecture for your app, using effective patterns and modularity, as well following good code quality practices, you will find:

bug fixes become easier;
adding new features becomes straightforward;
your app becomes easier to test and maintain; and,
your developers will have an easier time understanding the code.

I believe these are things we should all try to observe. You’ll find it not only improves the morale of your developers, but it will also save you a lot of time and money in the long term.

Want more about iOS software architecture on how to create better iOS apps?

If you want to learn ways to save time and money and make smart decisions about developing an iOS app for your business, I invite you to sign up for my newsletter. I will let you know when I put out new content like this and if there are important things you should know.

Productivity Apps for Developers (and Everyone Else)

leogdion — Fri, 13 Mar 2020 20:15:26 +0000

As a remote software developer who’s transitioned to many roles as a self-employed freelancer, it’s important to keep a set of great software tools. Most importantly tools which help me optimize rather than distract me. Therefore, here’s a list of productivity apps and services I use to keep my workflow going. In contrast, these are not development tools necessarily but rather software which helps with other office work which I do. To begin with, you’ll need an easy way to install, run, and track your application as well as your computer’s disk space.

Managing Productivity Apps and Disk

For many developers, we live in the command line. Therefore, using a package manager is a great way to install apps without the need to load a distracting web page. For instance, on Linux there’s apt or yum; Windows has Chocolatey and on the Mac is Homebrew which is what I use. Altogether, this allows you also to track what you have installed especially using Homebrew Bundle. Outside of the Mac App Store, Homebrew is a great way to install and manage your productivity apps.

Secondly, one of the first apps I install on my Mac is Alfred. In essence, Alfred not only is superior to the Spotlight search but also offers a plethoria of different services you can integrate with. Thereupon, you can simply map a hot key to that service and it’ll allow you to search for apps, contacts, do math problems, or give you directions.

016. Productivity Apps Episode

OK Productive

Your browser does not support the audio element.

1x initializing... ×

While installing all of your productivity apps, you may need to watch your disk space. That’s where Daisydisk comes in. In short, DaisyDisk gives you great visualization of how your disk space is used as well as how to cleanup your disk. In contrast to tracking your disk space, let’s talk about a real productivity challenge - tracking your time.

Time Tracking and Scheduling Apps

With many of my clients and partners, I need to schedule meetings and track my time. Specifically, there’s one app I use for arranging meetings - that is Doodle. That is to say, Doodle is a platform which allows for easy polling and basic surveys including scheduling. For instance, I can easily share a poll which asks participants the best time to meet from a set of times available. Once votes are placed, I can send them an invite easily.

As far as tracking my time, I currently use Toggl. Generally speaking, Toggl doesn’t come with a lot of bells and whistles, however its open API and simplicity make it ideal for reporting and tracking.

Reminders and Todo List Productivity Apps

For tracking my tasks, currently I use a combination of weekly Spreadsheets and Todoist. In particular, Todoist offers the ability to share tasks easily with others whether it’s a podcast episode I am working on or a shopping list with my wife. Additionally, I can easily group tasks as well set priorities and due dates.

007. List #2 – Top Apps Episode

OK Productive

Your browser does not support the audio element.

1x initializing... ×

Conversely I also use spreadsheets to track my weekly items. (I use Numbers - of course you can use Excel or Google Sheets) As an example I simply add the name of the task (Write a Development Tools) and assign a priority and desire between 0-100 (99) as well as approximate minutes (3 hours?). Lastly, I sort by priority and desire and then based on my availability, work on the top items for that week. Then, each week I copy the sheet into a new one, delete the completed items, copy the old priorities over, set new priorities for the week, and repeat.

Notes and Writing Productivity Apps

For developers, MarkDown has become the most convenient way to organize as well as create documents. If you are not familiar with Markdown, I highly recommend taking 30 minutes and becoming familiar with it:

Whether it’s communications, documentation, blogging, or note taking, Markdown is a great way to keep your text organized and formatted. Therefore many note taking apps use Markdown, including the one I use - Bear. To point out, Bear works only on iOS and Mac and a web front-end is in the works. However, Bear’s strong point is its simplicity, versatility as well as UI.

Conversely, if you prefer to use something besides Bear or any Markdown specific app, there’s always Google Docs. Most importantly, since Google Docs is so widely accepted, sharing documents has become easy and painless. For instance, I’ll explicitly use Google Docs for show notes and any long form writing which needs to be shared.

For other long-form writing, I am a big fan of Ulysses. Just as with Bear, Ulysses is specifically for macOS and iOS, however its purpose is explicitly long-form distraction-free writing. Most importantly, it has a great UI and has helped keep my writing organized and flow easily. Additionally, it can export to several formats such as Word Doc, HTML, PDF, Wordpress, Medium, and more. Besides my writing, I also record podcasts and do video as well.

Creative Apps

For doing any multimedia, including podcasting, I recommend two suites: Adobe or Apple. First, Adobe’s Creative Cloud is great if that is a focus of what you do. For instance, I’ve used Photoshop, Illustrator, Premier, and Audition and each have helped with artwork, video production, and podcast production. However if its steep price is too much for you, I’d recommend looking at what Apple provides for free with iMovie and GarageBand. Most importantly, both offer plenty for beginners as well as intermediates before you move to Apple’s Logic or Final Cut Pro.

Similarly, for recording video I use OBS as well as FiLMiC Pro. OBS is great for live streaming demos or tutorials as well as on-screen recording. Conversely, OBS has a learning curve but there’s a lot you can do as a beginner. On the other hand for recording my presentations or video of myself, I use FiLMiC Pro on my iPhone. For one thing as advanced as iPhones are, you can do videos at 4K resolution and 60 Frames Per Second. In addition, I also use FiLMiC Remote on a second iPhone to preview and control the recording as it is being done.

Afterwards once I’ve edited the video or audio recording, I’ll need to share it with my audience.

Marketing Apps

Social media can be quite overwhelming, which is why I have a set of productivity apps to keep me active as opposed to distracted. For instance, Buffer is a great way to make sure your social media queue is active without constantly being reminded by what’s out there. Furthermore, Buffer can connect with several social media accounts as well as allow you to schedule posts with existing media. Besides social media, email is still actively used by many folks. Therefore, Mailchimp is a great service for starting your own email list. For instance, whenever I need to update folks on products, services, content; Mailchimp allows for me to automate and schedule email out to my various audiences.

Along with email, there are other ways to contact my business partners and clients.

Communication Apps

Besides email I use Slack pretty frequently. Slack is a great way to communicate with a team, find a community, or share documents. Notably, there is practically a Slack community for all sorts of developer languages, frameworks, and tools. In addition, Slack also uses Markdown for text formatting, has great shortcuts to channels and folks, and a decent bot and developer ecosystem for customization.

When a Slack message or email won’t do, I typically setup video meetings with Zoom. Most importantly, what Zoom brings to video conferencing is simplicity and the ability to just work. Besides its app (which is offered on multiple platforms), Zoom requires nothing else. After finding the right time for the meeting, I’ll schedule a time and send a link to the meeting using Zoom. Zoom also allows for recording of video calls for later reference.

Avoid Over Optimizing Productivity Apps

Finding the best productivity apps can be great but avoid being sucked in by it’s endless list of features. Have it do the job you want and be done with it. One of the biggest time sucks is over optimization of apps as well. Don’t spend too much time finding the right app or learning every shortcut and feature it offers.

I hope this list of productivity apps is helpful to you or wherever you work. If you are interested in learning more check out my podcast episodes with Erik Gillespie OK Productive. Especially episodes #7 Top Apps and #16 Productivity Apps

Swift Package Continuous Integration Guide

leogdion — Fri, 13 Mar 2020 14:27:53 +0000

Swift packages offer an easy manageable way to share code and functionality. If you wish to create your own package, it’s important to make sure your code works where it's supposed to and the quality is good. Most importantly, continuous integration is a great way to ensure that. If you are interested in learning why continuous integration is important, check out this article on avoiding merge hell. Therefore, in this article I am going to show you how to setup Swift package continuous integration.

Specifically, I am going to break down the following:

Basics of Creating a Package
Designating Platforms and Operating Systems
Setting Up Travis-CI and GitHub Actions
Adding Linux Support
Testing and Code Coverage
Linting, Formatting, and Code Quality
Automating Code Documentation
Distributing and Sharing
Samples and Examples

What's important to realize is that Swift packages are reusable pieces of code which encapsulate a set of functionality. In the end, there are two ways to create a Swift package: via Xcode or command line.

Getting Started

Under the Xcode menu, go to File > New > Swift Package and follow the corresponding dialog. Alternatively, you can use the swift command line tool to create your package. First, create an empty directory and run the create package subcommand:

> mkdir New-Package
> swift package init

In the end, you should have:

A Source directory for your main source code
A Tests directory for your testing code
A Package.swift containing the configuration in Swift of your code

Specifying Platforms and Devices

Before distributing your Swift package, it’s important to note which operating systems or platforms your code can run on. In the past I’ve reasonably assumed a Swift package would work on watchOS or Linux for instance. Only after adding the dependency and attempting to compile, did I realize the incompatibility issue. If you use an API that is limited to certain platforms, you have two options.

Specify via Package

Firstly, you can specify an operating system and version in the Package.swift under the platforms property:

...
    platforms: [
        .macOS(.v10_15),
        .iOS(.v13),
        .watchOS(.v5),
        .tvOS(.v13)
    ]
...

Using Attributes and API Availability

On the other hand, you may want to offer some functionality on some devices. With this in mind, you can use the attributes and API availability checks. In other words the available attribute allows you to mark certain functionality of your Swift package unavailable on certain operating systems and versions.

In addition, by doing API availability checks you can supply the correct implementation based on operating system and version. Furthermore, whenever you may need to import certain frameworks which may be required but may not be available, you can use canImport, as well.

Here's an example of extending CGFloat for all operating systems, but importing CoreGraphics, when possible:

#if canImport(CoreGraphics)
  import CoreGraphics
#endif

extension CGFloat {
  var clean: String {
    truncatingRemainder(dividingBy: 1) == 0 ? String(format: "%.0f", self) : description
  }
}

Be that as it may, if you are planning on supporting all operating systems which support Swift then there is no need to do this. Regardless, it may be worth spending some time verifying and updating this property accordingly.

Why Continuous Integration?

Having properly setup your package and provided correct compatibility, it’s important to make sure your package works. Additionally, you may want to make sure each change to your code works correctly. Luckily, this is where Continuous Integration comes in.

Continuous integration (CI) is the software practice where small code changes are frequently tested with the rest of the code to ensure nothing breaks as it changes. In other words, with CI we can make sure each change works correctly by integrating a service with our code.

Continuous Integration with Kyle Newsome

EmpowerApps.Show

Your browser does not support the audio element.

1x initializing... ×

Choosing a service for Swift Package Continuous Integration

What’s important to realize is that by using a cloud service for your Swift package, you can make sure your package works everywhere. Often times, we may be have some source, artifact, or tool required to build our code. However with a cloud service, you can ensure that if your Swift package builds and tests in the cloud it will work for anyone else.

Luckily, there are some great services out there to help your Swift package especially if it’s a public GitHub repository. At the present time, unfortunately, some services only support Continuous Integration for iOS Applications rather than Swift packages such as Circle CI and Bitrise. Be that as it may, Travis-CI as well as the most recent GitHub Actions allow for Swift Package Continuous Integration.

Travis-CI

Travis-CI is one of the older Continuous Integration services out there. Most importantly for public repositories, Travis-CI is completely free. In other words, you can configure your Swift package on Travis-CI. In order to configure your repository, signup with Travis-CI by linking your GitHub account or organization. Next you need to setup your .travis.yml file.

Notably, there are three key components for setting up a Swift package in Travis-CI:

Specifying the correct operating system and Xcode version
Building and testing your code

For example, here is a simple .travis.yml file:

language: objective-c
os: osx
osx_image: xcode11.3
script:
  - swift build
  - swift test

The first three properties setup the virtual machine which Travis-CI uses. Next, the lines under script specify the commands Travis-CI needs to run to verify the Swift package is working. In this case, since we are not building from an Xcode project or workspace, we need to specify our own custom commands. In other words, rather than using xcodebuild, the Swift command line tool will build and test our package.

While Travis-CI is the most experienced cloud CI service out there, recently GitHub has also offered its own service with GitHub Actions.

Github Actions

With the fairly recent release of GitHub Actions, you can setup Swift package continuous integration right from your repo. Most importantly GitHub Actions is completely free for public repositories. Therefore, let’s breakdown the functionality of GitHub Actions.

GitHub Actions Components - Workflows, Actions, Jobs and more

In order to setup our Swift package continuous integration in GitHub Actions, we need to understand the components. Similar to Travis-CI, GitHub uses YAML for its configuration. Specifically these YAML files are known as workflow files. For example, here is a sample with the name macOS:

name: macOS

on: [push]

jobs:
  build:  
    runs-on: macos-latest
    steps:
    - uses: actions/checkout@v2
    - name: Build
      run: swift build
    - name: Run tests
      run: swift test

In contrast to Travis-CI, you can setup multiple of these files. Therefore as long as you store them in your repository under the .github/workflow folder, GitHub Actions will execute each of these workflow files on trigger.

Speaking of trigger, you can specify many triggers. However in the case of our Swift package, we will only be using the push trigger to activate this workflow.

Below the on trigger, we have setup one job under jobs called build. With in the build job, we have specified the runner type (i.e virtual environment) of macOS-latest. In other words, it will be using the latest version of macOS to run the series of steps.

...
    steps:
    - uses: actions/checkout@v2
    - name: Build
      run: swift build
    - name: Run tests
      run: swift test

GitHub Actions - Step By Step

Below the runner type property are the series of steps specified. In this case, the first step with the single uses property checks out the code from the repository. While the following steps have a name label and a run command to execute: first building the Swift package (swift build) then running tests provided (swift test).

What’s important to note is that each needs a custom command (via run) with a name or to use a prebuilt action from the GitHub repo such as actions/checkout@v2 to pull the source code from the repository. Unfortunately many of the GitHub Actions provided on GitHub may not be compatible with macOS due to various requirements.

Luckily you should have Continuous Integration setup for your Swift package in both Travis-CI and GitHub Actions. However if you wish to support Linux with your Swift package, it is import to configure the Swift package continuous integration for a Linux environment as well.

Linux Support for Swift Package Continuous Integration

If you wish for your Swift package to be supported everywhere, it might be a good idea to support Linux. Therefore, it’s important to have your Swift package Continuous integration to extend to Linux. Thankfully both Travis-CI and GitHub Action support Linux (i.e. Ubuntu) as well as the configuration of more than one environment per repository. First, let’s understand how build matrices work in Travis-CI.

Configuring Travis-CI for Linux

With Travis-CI, we can use a build matrix to include more than one environment. In other words, Travis-CI will run each environment in the build matrix in parallel. Therefore, let’s swap the top section specifying only macOS from above with a build matrix including both macOS and Linux (i.e. Ubuntu 18.04-bionic):

jobs:
  include:
    - os: linux
      dist: bionic
      sudo: required
    - os: osx
      osx_image: xcode11.3

Now, it will run each phase in parallel on Ubuntu as well as macOS. However we'll need to make changes to both of the these sections in order to support Linux. Most importantly, we will need to install Swift.

Therefore, we will move or create the script and before_install phases into separate bash scripts and update .travis.yml accordingly:

jobs:
  include:
    - os: linux
      dist: bionic
      sudo: required
    - os: osx
      osx_image: xcode11.3
before_install:
  - ./Scripts/before_install.sh
script:
  - ./Scripts/script.sh

Next let’s create a script for before_install named before_install.sh under the Scripts folder with the following code:

#!/bin/bash

if [[ $TRAVIS_OS_NAME = 'osx' ]]; then
  # install macOS prerequistes
elif [[ $TRAVIS_OS_NAME = 'linux' ]]; then
  # download swift
  wget https://swift.org/builds/swift-5.1.3-release/ubuntu1804/swift-5.1.3-RELEASE/swift-5.1.3-RELEASE-ubuntu18.04.tar.gz
  # extract the archive
  tar xzf swift-5.1.3-RELEASE-ubuntu18.04.tar.gz
  # include the swift command in the PATH
  export PATH="${PWD}/swift-5.1.3-RELEASE-ubuntu18.04/usr/bin:$PATH"
fi

Within the bash script, we check the environment variable TRAVIS_OS_NAME setup by Travis-CI. With the variable, we check whether it is osx for a macOS environment or linux for the Ubuntu environment.

Since Xcode is not available on Ubuntu, we need to manually within the bash script, download and extract Swift. Lastly we need to include the directory path of the Swift command tool within the environment PATH variable.

Correspondingly we need to make sure the PATH is updated in the Scripts/script.sh file:

#!/bin/bash

if [[ $TRAVIS_OS_NAME = 'osx' ]]; then
  # What to do in macOS
elif [[ $TRAVIS_OS_NAME = 'linux' ]]; then
  # What to do in Ubunutu
  export PATH="${PWD}/swift-5.1.3-RELEASE-ubuntu18.04/usr/bin:$PATH"
fi

swift build
swift test

Therefore the only major change within the script section of the Travis-CI configuration is including the path to the Swift command line tool.

As a result, each time a push is made to the repository, Travis-CI will run both a macOS and Ubuntu process. In effect, we have setup Swift package continuous integration for both operating systems in Travis-CI. Accordingly, let’s do the same thing for GitHub Actions.

Configuring GitHub Actions for Linux

While Travis-CI requires us to check the operating system within the build script, GitHub Actions allows us to use separate workflow files for each operating system.

name: ubuntu

on: [push]

jobs:
  build:

    runs-on: ubuntu-18.04

    steps:
    - uses: actions/checkout@v2
    - name: Download Swift 5.1.3
      run: wget https://swift.org/builds/swift-5.1.3-release/ubuntu1804/swift-5.1.3-RELEASE/swift-5.1.3-RELEASE-ubuntu18.04.tar.gz
    - name: Extract Swift 5.1.3
      run: tar xzf swift-5.1.3-RELEASE-ubuntu18.04.tar.gz
    - name: Add Path
      run: echo "::add-path::$GITHUB_WORKSPACE/swift-5.1.3-RELEASE-ubuntu18.04/usr/bin"
    - name: Build
      run: swift build
    - name: Run tests
      run: swift test

In this case, each command is stored within an individual step. As can be seen, the one custom part is the method we use to add the path using GitHub Actions logging commands and variables. With echo "::add-path::$GITHUB_WORKSPACE/swift-5.1.3-RELEASE-ubuntu18.04/usr/bin", we update the PATH variable.

As a result, your Swift package continuous integration should support Linux via Travis-CI and GitHub Action. However, there are a few steps in order to support Linux when it comes to testing.

Testing, CI, and Linux

When it comes to verifying whether your package works correctly, having the right unit tests are a major component of that. Luckily, if you are using the XCTest framework and setup the CI scaffold previously described, you should be good to go. However with Linux, XCTest will not automatically provide all the correct tests in your application without some modifications. There are a few ways of doing this:

Manually update your XCTestManifests.swift and LinuxMain.swift :(
Run swift test --generate-linuxmain before commit on your macOS machine to let the swift command line tool update your LinuxMain.swift.
Update your CI for Linux to run swift test --enable-test-discovery which will automatically discover and run your tests.

If you are interested in learning more about this check out Ole Begemann’s piece on keeping XCTest in sync as well as how automatic test discovery works.

Now that we have our unit tests working correctly, let's look into keeping tracking of code coverage.

Integrating Code Coverage

Code coverage is a good way to keep track of how well your unit tests are handling. Luckily there are some great services out there to keep track of your code coverage as you build your Swift package.

CodeCov

CodeCov.io is one such service which we can plugin into our Swift Package Continuous Integration setup. However, once you have signed up and added your public repository, it will take some configuration to make it work completely.

For instance, we must make sure that the tests, build a report, convert the report to a compatible format, then lastly upload the the report to CodeCov.io. Building the report when you run the unit tests is fairly easy. In this case, we simply need to add the flag --enable-code-coverage to our swift test for both Travis-CI and GitHub Actions; macOS and Linux:

swift test --enable-code-coverage

Next, we need to prepare the report for upload using llvm-cov. With this in mind, on macOS you can use xcrun to run llvm-cov:

xcrun llvm-cov export -format="lcov" .build/debug/${{FRAMEWORK_NAME}}PackageTests.xctest/Contents/MacOS/${{FRAMEWORK_NAME}}PackageTests -instr-profile .build/debug/codecov/default.profdata > info.lcov

Corresponding in Linux, we can run llvm-cov manually:

llvm-cov export -format="lcov" .build/x86_64-unknown-linux/debug/${{FRAMEWORK_NAME}}PackageTests.xctest -instr-profile .build/debug/codecov/default.profdata > info.lcov

Simply replace ${{FRAMEWORK_NAME}} with your Swift package name or even better setup an environment variable in Travis-CI and GitHub Actions.

Lastly, we need to upload the report using the Bash script provided by CodeCov.io:

bash <(curl https://codecov.io/bash)

While Travis-CI automatically integrates with CodeCov.io, GitHub does require manually setting up the token for CodeCov.io:

First, go to your project in CodeCov.io and copy the token from the project overview.
Go to your GitHub repository settings and under Secrets add the token under the name CODECOV_TOKEN.
Under both the macOS and ubuntu workflow files, add the CODECOV_TOKEN as the environment variable under the upload step.

For example, here’s the Ubuntu workflow file which uses an environment variable for the Swift package name and maps the CODECOV_TOKEN secret to the uploader command environment variable:

...    
    - name: Run tests
      run: swift test --enable-code-coverage
    - name: Prepare Code Coverage
      run: llvm-cov export -format="lcov" .build/x86_64-unknown-linux/debug/${{ env.PACKAGE_NAME }}PackageTests.xctest -instr-profile .build/debug/codecov/default.profdata > info.lcov
    - name: Upload to CodeCov.io
      run: bash <(curl https://codecov.io/bash)
      env:
          CODECOV_TOKEN: ${{ secrets.CODECOV_TOKEN }}

Now that we have completed setting up a code coverage report with CodeCov.io, Let’s talk about ensuring good code quality.

Code Quality and CI

There are some great automated ways we can keep up code quality inside our Swift package continuous integration. However, nothing replaces a good code review. If you can, have some sort of code review process by someone else. If it’s difficult to find someone else, I suggest reviewing a Swift package’s code after some down time to ensure you can have a fresh look at your code.

Regardless, let’s look at some of the ways we can automate code quality checks.

Formatting, Beautification, and Linting

There are two command line tools I use to maintain quality code while keeping formatting consistent: SwiftFormat and SwiftLint. Fortunately, each application can be installed via Homebrew. Therefore, we can use Homebrew bundle to automate the installation of both applications inside our Swift package continuous integration. With this in mind, add a file called Brewfile to the root of repository with the following text:

brew "swiftformat"
brew "swiftlint"

Next we need to add the installation these applications in the earliest part of our CI setup. However these applications will only work on macOS and we need to verify that as well. Therefore we modify our before_install.sh script for Travis-CI with:

...
if [[ $TRAVIS_OS_NAME = 'osx' ]]; then
  brew update
  brew bundle
elif [[ $TRAVIS_OS_NAME = 'linux' ]]; then
...

Meanwhile, for Github Actions, we simply need to add steps to our macOS workflow file:

...
  steps:
    - uses: actions/checkout@v2
    - name: Prepare Build
      run: brew bundle
...

Lastly we need to add the following command to verify code quality after the installation:

swiftformat --lint . && swiftlint

In short, this command will run both applications in the CI process. Specifically we run swiftformat in linter mode, since our expectation is that the developer has already formatted the code correctly before commit. Correspondingly, with swiftlint, you can use the autocorrect subcommand to fix some linter errors in your code before commit.

Again, for Travis-CI, verify the $TRAVIS_OS_NAME is osx, so the CI doesn’t run the tool in Linux.

Beside installation and execution of the tools within the Swift package continuous integration, you should probably add configuration files for both tools. In brief, these are .swiftformat and .swiftlint.yml. Futhermore, check out both the SwiftFormat and SwiftLint projects for details on how setup these configurations.

Managing Code Quality with Anne Cahalan

EmpowerApps.Show

Your browser does not support the audio element.

1x initializing... ×

Cloud-Based Code Quality Services

Besides SwiftFormat and SwiftLint, there are a few cloud based code quality tools which easily integrate with your public GitHub repository. Therefore, you may be interested in:

After having setup these various tools, it’s worth taking a look at some various issues which may crop up.

Common Code Quality Issues

Now that we have setup our Swift package continuous integration and plugged in several services, there are few issues you could resolve which will show up:

Cyclomatic Complexity

Cyclomatic Complexity refers to the complexity of the code specifically when it comes to testability. In the end, if your code contains several logical paths, it is best to break these up. For instance, using Protocol Oriented Programming, you can have a protocol to test the case. Then, for each case use individual implementations and store them in an array. For instance, rather than:

if a == 0 {
    if b == 0 {
    } ...
...
} else if a == 1 {
...
} else if a == 2
...
}

Use a protocol which does:

protocol Doer {
  func test (_ a: Int, _ b: Int) -> Result?
}

let implementations : [Doer] = [FooDoer(), BarDoer()]

var result : Result?

for implementation in implmentations while result == nil {
  result = implementation(a, b)
}

As a result, testing and maintaining this code becomes much more simple.

Cognitive Complexity

While Cyclomatic Complexity determines how difficult your code will be to test, Cognitive Complexity is how difficult it is to read and understand. Therefore much of this involves breaks in logic, and unnecessary loop statements. However by making your code flow clearly from top to bottom this can be avoided.

File and Function Too Long

One of the easiest metrics of complexity is the length of your files and functions. In the end, simply refactoring should resolve the issue. To put it differently, break down large functions, classes, and structs into smaller components. At the same time, you may find a class which is difficult to split up such as a UITableViewController. In this case, Swift extensions are a great way to resolve this.

Assignment Branch Condition

Assignment Branch Condition typically is calculated based on the number of assignments, branches, and conditions as opposed to simply length. Therefore, this can be resolved by separating your functions into smaller pieces. In other words, reduce these complex elements from one function into several.

Many of these code quality issues should be resolved, however it is good to not be overly concerned with some of these metrics. Similar to code coverage, it is much more a case-by-case need for resolution.

Additionally there can easily be instances of false positives such as identical code issues. In the end, it’s important to have a measured but determined approach to code quality.

Documenting Your Swift Package

If you intend to distribute your Swift package to the public then it’s important to document your code and make that documentation easily available. In the first place, take a look at Apple’s guidance on documenting Swift code as well as:

Once you’ve properly documented your Swift package API, let’s add code documentation to our Swift package continuous integration.

Primarily, you have the option of using either Jazzy by Realm or SourceDocs. Each has their advantage depending on whether you wish to build a complete static HTML site. In that case, I would recommend Jazzy. Especially considering the maturity of Jazzy, it can be an excellent tool. On the other hand, if you wish to simply output Markdown for your package documentation, I’d recommend SourceDocs.

Using SourceDocs

To build documentation using sourcedocs, first build your Swift package using swift build. Once your package is built, you run sourcedocs using:

sourcedocs generate --spm-module PACKAGE_NAME

Additionally, you can use a different output directory besides Documentation, such as docs. In order to do that, you can use the flag --output-folder like so:

sourcedocs generate --spm-module PACKAGE_NAME --output-folder docs

Furthermore, we can take the next step and integrate sourcedocs into our Swift package Continuous Integration.

Adding SourceDocs to Swift Package Continuous Integration

Similar to our other tools, we need to add sourcedocs to our Homebrew bundle file:

brew "swiftformat"
brew "swiftlint"
brew "sourcedocs"

Next in our macOS GitHub Action workflow file, we can add a step to build the documentation:

    - name: Build Documentation
      run: sourcedocs generate --spm-module ${{ env.PACKAGE_NAME }} --output-folder docs

Lastly, in order to make sure our change is pushed, we need to add a step to commit and push any documentation changes:

    - name: Commit files
      run: |
        git config --local user.email "action@github.com"
        git config --local user.name "GitHub Action"
        git status
        git add [DOCUMENTATION DIRECTORY]
        git diff-index --quiet HEAD || git commit -m "[github action] Update Docs"
        git push

A point often overlooked, is that this will fail if there is an already existing push committed while this CI takes place. Therefore, in those cases, the CI will fail. If you are concerned, I would recommend looking at using a pull request rather than a direct push to the branch.

After having built documentation for our swift package, it is important to make our package discoverable to others.

Making Your Swift Package Available

Now that we have setup:

CI based on the supported platforms such as Linux
linting and code quality checks
code documentation

… let’s discuss how we can properly distribute the package to others.

SwiftPM

While Swift packages can easily be added simply as a few lines in a Package.swift, discoverability can be difficult. Luckily thanks to the work of Dave Verwer, the community has a great site with swiftpm.co.

However there are some checks we should add to make sure your Swift package is valid. Additionally we can add these checks to the Swift package continuous integration.

Using `jq` to Verify Products

With this intention, we need to make sure that our swift package has at least one valid product. For instance, under the product section of my Package.swift for my package AssetLib, it has a library product listed:

...
  products: [
    // Products define the executables and libraries produced by a package, and make them visible to other packages.
    .library(
      name: "AssetLib",
      targets: ["AssetLib"]
    )
  ],
...

Fortunately, we can automate this by dumping the JSON of the package and verifying the products listed using jq. jq is a fantastic command-line tool for processing JSON data similar to sed. Therefore by piping the JSON from the swift subcommand package dump-package to jq, we can check the number products:

swift package dump-package | jq -e ".products | length > 0"

As can be seen, we are using the filter string to check the length property of the property products to see if there is more than one product.

Lastly, we can submit our Swift package for review by:

Forking the Repo
Adding our repos to packages.json
Making sure packages.json is sorted via jq by running: echo "$(jq 'sort_by(ascii_downcase)' packages.json)" > packages.json
Run validate.sh
Create a pull request in GitHub

Then wait for acceptance to see your package listed at swiftpm.co.

Cocoapods Compatibility

While Swift packages are the future of dependency management, there are several reasons why Cocoapods is still in use. For this reason, it’s a good idea to add support for Cocoapods to your library. Luckily, there are only a few simple steps to add for making our Swift package is compatible.

Once you have Cocoapods installed, create the Cocoapods spec by running:

pod spec create $(git remote get-url origin)

At the present time, you should have a .podspec file named after your library. Inside the .podspec. file, add or set:

Long description under spec.description
Short summary under spec.summary
Create License File and set the set license type and file name under spec.license
Your name and email address under spec.author
The deployment targets for each operating system
The spec.source to the repository url and git tag of the target version
spec.source_files to Sources/**/*.swift
The spec.swift_versions

Lastly we can verify our package is valid in our existing continuous integration by including pod lib lint within the macOS sections of our script.

Setting Up An Example Project

Additionally I would encourage creating an example project using your library with targets in each operating system. Moreover, we can also verify our example project builds. After creating the example project in a directory called Example, create a Podfile using pod init. Then update the Podfile by adding a reference to your pod in the parent directory:

...
target 'iOS Example' do
  # Comment the next line if you don't want to use dynamic frameworks
  use_frameworks!
  pod 'PackageName', :path => '../'

  # Pods for iOS Example

end
...

Next to verify the build in our macOS continuous integration, include the following lines:

if [[ $TRAVIS_OS_NAME = 'osx' ]]; then
...
  swift package generate-xcodeproj
  pod install --silent --project-directory=Example
  xcodebuild -quiet -workspace Example/Example.xcworkspace -scheme "iOS Example"  ONLY_ACTIVE_ARCH=NO  CODE_SIGN_IDENTITY="" CODE_SIGNING_REQUIRED=NO  CODE_SIGNING_ALLOWED=NO
  xcodebuild -quiet -workspace Example/Example.xcworkspace -scheme "tvOS Example"  ONLY_ACTIVE_ARCH=NO   CODE_SIGN_IDENTITY="" CODE_SIGNING_REQUIRED=NO  CODE_SIGNING_ALLOWED=NO
  xcodebuild -quiet -workspace Example/Example.xcworkspace -scheme "macOS Example"  ONLY_ACTIVE_ARCH=NO CODE_SIGN_IDENTITY="" CODE_SIGNING_REQUIRED=NO  CODE_SIGNING_ALLOWED=NO
...

In other words, this script example for Travis-CI, will:

Generate the Xcode project Cocoapods needs.
Install the Cocoapod and create the workspace file
Build each application target for each operating system

Therefore, we have created a .podspec and added continuous integration for the pod as well as the example project. Lastly, we need to push the repository to GitHub and tag it with the proper version. Once that’s done, make sure you have a Cocoapods account setup and run: pod trunk push NAME.podspec to push our repo.

Examples and Integration

In the end, it's important to make sure your package maintains good quality, works on its designated platforms, is easily available, and is fully tested. If you are interested, you can check out packages which I have implemented using these practices:

Base32Crockford - the Swift implementation of the Base32Crockford encoding
AssetLib - which reads and updates app icon and image set information used in Xcode Asset Libraries
SwiftVer - reads version information from Bundles and Plists as well as information stored from version control using autorevision

Furthermore, you can use my GitHub template EggSeed, which automates most of what we've talked about here:

creation of a Swift package library
creation of Cocoapod spec
setup of example projects
SwiftLint and SwiftFormat tooling
code documentation setup
CI Integration with Travis-CI, GitHub Actions, and CodeCov.IO

brightdigit / EggSeed

Command Line Tool for Starting Your Swift Packages with Continuous Integration

EggSeed is a command-line tool for creating swift pacakges with continous integration support. While swift package init, creates simple packages, there is no guarantee that your package will work on everyone else's device. That's where continuous integration goes in.

By using eggseed, you can create a package with full integration into CI services such as: GitHub Actions, Travis-CI, BitRise, CircleCI and more. Not only that but EggSeed also sets up code documentation, linting, and more...

Check out the roadmap below for more details on future integrations.

Installation

Mint

mint install brightdigit/EggSeed

Swift Package Manager

Use as CLI

git clone https://github.com/brightdigit/EggSeed.git
cd EggSeed
swift run eggseed

Use as dependency

Add the following to your Package.swift file's dependencies:

.package(url: "https://github.com/brightdigit/EggSeed.git", from: "0.2.0"),

And then import wherever needed: import EggSeed

Usage

USAGE: eggseed [--package-type <package-type>] [--user-name

…

View on GitHub

Additionally, badges are included from shields.io to showcase the quality of your Swift package continuous integration.

Feel free to reach out if you have any additional questions on Twitter @leogdion or signup for the newsletter to get the latest tutorials and guides on Swift development.

SwiftUI: Everything is possible if you think like Apple

leogdion — Mon, 02 Mar 2020 21:53:58 +0000

SwiftUI is Apple’s new framework for building user interfaces (UI). It promises simplicity and consistency that's been difficult to find before now. I’ve been using it for several months now, and want to explain how businesses with an app, or want one in 2020, can benefit.

I’ll be covering:

What makes SwiftUI different.
When you should use it.
When you shouldn't.

In this episode, Leo talks about what he's learned using SwiftUI, where he sees it's the right fit, where it's not quite ready, and some solutions to common problems people have with it.

What makes SwiftUI different?

Before now, building a UI for an application for an Apple operating system (OS) has been a bit complicated. You often have to use various tools and frameworks. Most likely Interface Builder (for apps on iOS and MacOS) as well as UIKit (for iOS and tvOS), to build the interface you want. While these are not bad tools, they do have issues and limitations. Apple has clearly developed SwiftUI to overcome or do away these challenges altogether.

No more need for Storyboards or Imperative Programming

Interface Builder is well-known for using storyboards: visual representations of the UI. Unfortunately, storyboards don’t always accurately show what the code is doing. Storyboards do not structure information so it can be mastered or edited in one place. As a result, there is potential for misunderstanding because there’s no Single Source of Truth, a practice developers use to prevent confusion. Typically, the storyboard might not show what’s wrong if it’s not aligned with the code. For this reason, bug fixing becomes especially difficult

iOS App Architecture with René Cacheaux and Josh Berlin

EmpowerApps.Show

Your browser does not support the audio element.

1x initializing... ×

This worked fine in the early years of Interface Builder and UIKit, but the UIs of our apps have now become more complex. This is a problem because UIKit relies on a style of programming called imperative programming. In this style, the code describes exactly how the app must achieve a specific result.

With SwiftUI, we do away with storyboards altogether. Rather than using imperative programming, SwiftUI uses a different style: declarative programming. Declarative programming expresses what the result the software must achieve, but doesn’t describe how this must be done.

As a result, SwiftUI minimizes unintended results. Additionally, the code is more flexible because it's not limited to a specific procedure.

SwiftUI Works for all Apple Platforms

Tools for building Apple apps have often been limited to some, but not all, Apple platforms. Previously, it has been common to use a different Application Programming Interface (API) for each device. However, with SwiftUI, everything is in Swift and shared across all devices. As a result, it is possible to create an interface with a single API that works on all Apple platforms, from the Mac to the Apple Watch.

SwiftUI has a big advantage over other frameworks because you can build a complete UI with just SwiftUI using only one programming language. This is possible because SwiftUI works in Apple’s latest development environment, XCode 11.

WWDC 2019 - Swift UI with Jason Anderson

EmpowerApps.Show

Your browser does not support the audio element.

1x initializing... ×

What SwiftUI is good for?

As a result of the above, there are some clearly good uses for SwiftUI:

Apps with simple or cross-platform interfaces

As part Xcode 11, you can use a lot of design tools with SwiftUI, including being able to drag-and-drop visual elements. If you need a simple UI and don’t need custom functions, SwiftUI will probably work perfectly for you.

SwiftUI is really great for the Apple Watch, which is coming into its own now. Since the Watch requires a simple UI, SwiftUI is an excellent choice because it will not only work natively but will work with any other Apple OS too.

New Apps

If you’re going to build an app on for any Apple platform, you might as well start using SwiftUI. You will have all the functionality that Apple is able to provide within a single framework*. This also goes for anyone with an app who wants to migrate it to other Apple systems.*

For Tech-Savvy Users Using the Latest Apple Products

SwiftUI is a good choice for apps designed for tech-savvy users who are using the latest Apple OS's, like iOS 13. The reason is Apple has developed SwiftUI to take advantage of the latest functionality. This includes things like Apple’s improvements to UI design, UI transitions, animations, and how Dark Mode works.

SwiftUI being used to build an app for local developer meetups in Lansing

When is SwiftUI not a good choice?

That all said, SwiftUI is not always the right choice. There are a few instances where you’re either going to need something else, or you’re not going to see the benefits:

Older Apps

If you’re using an app that’s more than a few years old and still supports older Apple OS's, you’re not likely to see any real benefit. There’s nothing your users will really see or appreciate. You’re probably better off sticking with UIKit or whatever framework you’re using.

It’s worth mentioning a downside of using SwiftUI right now: there’s very little documentation. Because it's still so new, we’re still spending a lot of time figuring out how everything works and how to use it. For now, this means there is significant learning time if you want to develop with it. For an older app, you’re not likely to see a great return on investment.

Users using Older Operating Systems or Devices

Related to the above, one of the limitations of SwiftUI is it will only work with the latest Apple operating systems. It has no legacy compatibility. If you have users with older Apple products or who take a long time to update things, they are either going to struggle or simply not be able to use your new UI.

Apps that need to be Android-compatible

Finally, SwiftUI isn't going to help with apps that need to work on non-Apple systems. Swift is only used by Apple and SwiftUI only works in Swift. Therefore, you’ll need a different framework if you want your app to work on Android, Windows, or a website.

I generally recommend not building these kinds of apps anyway, as they rarely deliver the experience that a native app can. I’ve talked about this on my podcast and my blog if you’re interested in learning more.

2020 is going to be an interesting year for Apple apps

SwiftUI is likely going to make building apps for Apple products easier going forward. Especially if you’re comfortable working within the limits of Apple’s new framework. I think the people at Apple were thoughtful with this new framework and it will help create better interfaces for users.

If you're interested in learning more about SwiftUI, check out my Swift developer blog as well as:

If you’re interested in keeping up to date with what’s new for iOS and Apple development, I invite you to sign up for my newsletter. I will let you know when I put out new content and if there are important things you should know when it comes to creating or updating your apps.

Asynchronous Multi-Threaded Parallel World of Swift

leogdion — Tue, 01 Oct 2019 18:06:05 +0000

Over the last 15 years, CPU clock rate has plateaued due to thermal limitations in processors. As a result, CPU manufactures have instead chosen to add more cores or processing units. Therefore nearly every device has multiple cores: from a Mac Pro to the Apple Watch. For this reason, Swift developers should take advantage of asynchronous methods.

That is to say, with asynchronous methods, we can design applications which take advantage of multiple cores and deliver a better user experience. Therefore, let’s discuss:

Understanding Parallelism, Concurrency, and Asynchronous
How Operating Systems Breakdown Operations
Situations Swift Developers Run Into
Discrete APIs
Working with Queues
Dealing with Promises and Futures
Subscribers and Publishers with Combine
The Future with Coroutines

Understanding Concepts

First, we need to understand how operating systems handle tasks and how they can schedule them efficiently. As an example, lets look at the two independent operations. In this case, we have a pink one which is processing image A and a blue one which is processing image B.

Concurrency and Parallelism

When these operations are scheduled by the operating system, they can be run concurrently. Concurrency means that the operation can be partitioned and run at the same time on the same processor.

In addition, when the operating system has access to multiple processing units or cores, it can also run the operations in parallel. To put it differently both operations can be run on separate processing units. In essence, Parallelism differs from concurrency in that concurrency partitions each operation in order to continue different operations. Therefore, concurrency can be applied to a single processing unit. Conversely, Parallelism can only be applied to multiple processing units. Moreover, concurrency and parallelism can be applied at the same time by the operating system. Most importantly for developers is to make our operations asynchronous, in order to allow for concurrency and parallelism.

Asynchronous Operations

There are long operations, such as network requests, which are not well suited for standard synchronous operations. That is to say, by programming these calls synchronously, it will lock up other active operations such as user interface updates. Therefore making these calls asynchronous allows for other operations to be run concurrently. Specifically this is done in Swift, by including a completion closure or code block as a parameter. To put it differently, when the operation is completed that closure is executed on completion with a result passed.

For instance rather than actively waiting for a download to complete, the API allows the developer to pass what code they want the application to run when the operation is completed. Notably, this allows the operating system to schedule other operations in meantime like updating your UI. With this in mind, let’s take a look at the several ways Swift developers already run into this.

Where do we run into asynchronous operations?

Swift developers are already taking advantage of concurrency with asynchronous functions in their applications. Primary there are three APIs we commonly see:

Network Requests
NotificationCenter
Timers

Network Requests and URLSession

Network requests are the most frequent example where asynchronous calls make the most sense. While the developer can call a Data constructor to pull contents from a url, Apple already provides an asynchronous method to do this:

let url = URL(string: 
 "https://jaspervdj.be/lorem-markdownum/markdown.txt")!
URLSession.shared.dataTask(with: url) { 
 (data, response, error) in
  ...
}.resume()

In this example, a URLSessionDataTask is created with a callback which takes in the binary Data, the URLResponse, and possible Error. The API will handle the buffering of data and calculating when the request is complete. Additionally it will do it as a separate operation. As a result, the operating system can run other operations concurrently. Likewise NotificationCenter does this as well.

NotificationCenter

URLSession.shared.dataTask(with: url) { (data, response, error) in
  NotificationCenter.default.post(name: notificationDownloaded, object: nil)
}.resume()

NotificationCenter.default.addObserver(forName: notificationDownloaded, object: nil, queue: .main) { (notification) in
  print("Notification Sent")
  PlaygroundPage.current.finishExecution()
}

PlaygroundPage.current.needsIndefiniteExecution = true

In this example, when the download is complete, the application posts a notification to NotificationCenter. Additionally, theres an observer for the notification. Therefore, once the notification is received the Playground prints a message and finishes.

Timers

The application can take this further by adding a Timer, another asynchronous operation. Timer allows developers to delay or periodically repeat an operation. Once again, the API takes advantage of concurrency rather than locking up the application.

NotificationCenter.default.addObserver(forName: notificationDownloaded, object: nil, queue: .main) { (notification) in
  print("Notification Received")
  Timer.scheduledTimer(withTimeInterval: 1.0, repeats: false) { _ in
    print("Timer Activated")
    PlaygroundPage.current.finishExecution()
  }
}

In this example, the code doesn't print the message as before. Rather, a Timer is initialized with a 1 second delay. Therefore when the time approaches, the Playground prints the message and completes.

Although these asynchronous abstraction offer a convenient way to optimize your applications, there are problems which do come up. Primarily on iOS, the developer isn't able to prioritize each operation. As a result, this is most noticeable is when the developer attempts to update the user interface.

Asynchronous UI Updating with the Main Queue

One of the first lessons, developers learn when developing for the iPhone or iPad is necessity to make user interface updates on the main thread or DispatchQueue. Whether it’s simply updating a UILabel or a UITableViewCell, the UI update needs to be on the main DispatchQueue. Therefore, the operation needs to hop to another queue in order to complete the update to the user interface.

let timerSource = DispatchSource.makeTimerSource(flags: [], queue: .global())
timerSource.setEventHandler {
  DispatchQueue.main.async {
    viewController.label.text = "Timer Activated"
  }
}
timerSource.schedule(deadline: .now() + 1.0)

NotificationCenter.default.addObserver(forName: notificationDownloaded, object: nil, queue: .main) { (notification) in
  print("Notification Received")
  timerSource.activate()
}

In this example, DispatchSourceTimer is created. DispatchSourceTimer is similar to Timer, however the developer has more control over the priority and the queue. As with the previous Timer, when the Notification is observed, the Timer is started with a 1 second delay. However since the DispatchSourceTimer is designated for using the global queue, it is nessecary to hop to the main DispatchQueue and update a UILabel with the text Timer Activated. Consequently if this is not done, the user interface will not update correctly. Before I explain further how DispatchQueue and Grand Central Dispatch works, let’s breakdown how operating systems schedule operations.

How Operating Systems Handle Operations

Operating System have two level of controlling operations: Processes and Threads. A process is a running instance of an application such as this running instance of Activity Monitor listing out actual processes_:_

Moreover, a developer can breakdown a process into threads. A thread is a small sequence of instructions within a process which the operating system can schedule individually. In other words, a developer can breakdown a running application into parts which give the operating system more leeway in scheduling tasks.

Therefore, let's discuss the various ways developers can organize individuals operations in Swift. Firstly let's discuss the most direct control of threads and processes and slowly evolve into the more abstract and easy to manage.

Original Apple APIs

Over the years, Apple has evolved its API for giving developers control over their operations and their scheduling. At first, the API was pretty basic and direct but has become increasing developer-friendly and given more control to the operating system as to how to manage it.

Thread Class

Although this may be true, let's start by at least touching upon that most direct API: Thread (or NSThread in Objective-C). The Thread class gives the developer direct access to creating actual threads. Their are two ways to do this: pass in a closure to the initializer or subclass and override the main method.

Although this API is available, I would recommend against using it unless you absolutely have to. As you'll see, there are better abstractions which give better control to the operating system and are easy to maintain for the developer.

Process Class (for macOS only)

However there are occasions on the Mac, where you need to run a command or external application. In that case it's best to use the Process class (or NSTask in Objective-C). With the Process class, you provide a url to the executable and run:

let process = Process()
process.executableURL = URL(fileURLWithPath: "/bin/ls")
process.terminationHandler = {
  _ in
  PlaygroundPage.current.finishExecution()
}

try process.run()

While directly creating threads takes control away from the API and operating system, I think this is perfectly reasonable. In instances where a piece of functionality is already available on macOS running another outside process makes sense. As with many operations, it is important to make sure it does not interfere with the user experience. While there's the function waitUnitExit in order which provides a synchronous result from the operation, using the property terminationHandler, allows for asynchronous callback. That is to stay, using terminationHandler allows the application to do other operation as it waits for that process to finish.

Working with Queues and Asynchronous Operations

While the Process and Thread class gives developers direct control, Apple has introduced more abstract ways of dealing with operations. At the top of those abstraction is the all important Grand Central Dispatch.

Grand Central Dispatch

Grand Central Dispatch is by far the most used API for dealing with parallelism and concurrency through asynchronous operations. Specially, the most important class in that API is the DispatchQueue class. DispatchQueue allows for the developer to control the scheduling of operations. Additionally, the developer can guide some more abstract aspects regarding how the operating system organizes the operations.

For instance, if we were to count from 0 to 1000 within a Playground in two different DispatchQueues: the high-priority main queue and the lower-priority global queue, the code would look like this:

PlaygroundPage.current.needsIndefiniteExecution = true

DispatchQueue.global().async {
  var value = 0
  repeat {
    print("glob", value)
    value += 1
  } while(value < 1000)
}

DispatchQueue.main.async {
  var value = 0
  repeat {
    print("main", value)
    value += 1
  } while(value < 1000)
  PlaygroundPage.current.finishExecution()
}

By doing this, we would see the counting for each queue interleaved with each other:

...
main 947
glob 814
glob 815
main 948
glob 816
main 949
glob 817
main 950
glob 818
main 951
glob 819
main 952
main 953
...

In the example above the developer can control the priority or queue of the code block, however there are more ways we can control the DispatchQueue through the use of flags, quality of service and attributes:

let barrierQ = DispatchQueue(label: "barrier", qos: .default, attributes: .concurrent)
…
barrierQ.async{
  markdownFiles.append(text)
}

As we can see, we've created our own DispatchQueue and noted that it is concurrent. In other words, while the each operation we add is run in order, the following operation will not wait for the previous operation to complete. What must be remembered is that running multiple operations concurrently can result in what's called a Race Condition.

Dealing with Race Conditions in GCD

A Race Condition is where multiple operations are dependent on a single changeable object or variable resulting in the possibility in an error. For instance here's an example of a Race Condition issue using the Thread class API:

func increaseTo(_ max: Int) {
  var next:Int
  repeat {
    next = (items.last ?? 0) + 1
    Thread.sleep(forTimeInterval: 0.1)
    items.append(next)
  }
  while (next <= max)
}

As a result of running this in two separate threads, we could get something like this:

1
2
3
4
5
6
7
8
9
10
10 // 😱 Oh No! 😱 
11 // 😢
11 // 😭

Luckily Grand Central Dispatch provides two ways of resolving this through barriers: semaphores and flags.

Semaphores in GCD

A great use of the DispatchSemaphore is in the Thread example:

let semaphore = DispatchSemaphore(value: 1)

func increaseTo(_ max: Int) {
  var next:Int
  repeat {
    semaphore.wait()
    next = (items.last ?? 0) + 1
    Thread.sleep(forTimeInterval: 0.1)
    items.append(next)
    semaphore.signal()
  }
  while (next <= max)
}

In this example, we are more or less locking down the reading and writing to the array so it only can be executing by one thread at a time. In other words, the operation between .wait() and .signal() is executing atomically.

Barriers using DispatchWorkItemFlags

In contrast, with a DispatchQueue, we can provide a flag to ensure the markdownFiles is accessed atomically, we can use the .barrier flag:

let barrierQ = DispatchQueue(label: "barrier", qos: .default, attributes: .concurrent)
…
barrierQ.async(group: nil, qos: .default, flags: .barrier) {
  markdownFiles.append(text)
}

Organizing Multiple Operations with DispatchGroup

Besides DispatchQueue another great use of Grand Central Dispatch is DispatchGroup. For instance, if you have multiple asynchronous operations which are not dependent on each other such multiple url calls, DispatchGroup is perfect. DispatchGroup allows the developer to track their asynchronous completion as a whole:

let group = DispatchGroup()
let count = 20
var markdownFiles = [String](repeating: "", count: count)

for index in (0..<count) {
  group.enter()
  DispatchQueue.global(qos: .background)
  .async {
    markdownFiles[index] = 
      try! String(contentsOf: url)
    group.leave()
    print(index)
  }
}

In the example above, we create a DispatchGroup. Next, the code asynchronously downloads 20 markdown files and sets the result in the array. Markedly, each time group.enter() is called when the process starts and group.leave() is called to note that particular operation is completed. Lastly, the developer can call either [notify](https://developer.apple.com/documentation/dispatch/dispatchgroup/2016084-notify) or [wait](https://developer.apple.com/documentation/dispatch/dispatchgroup/1780590-wait) on the DispatchGroup depending on whether to wait asynchronously or synchronously.

One of the more complex natures of multiple asynchronous operations is organizing dependencies. Therefore let's discuss the next level of abstraction which specialized in dependencies - OperationQueues.

Operation Queues

An older yet more abstract API for dealing with multiple Operations is the OperationQueue (or NSOperationQueue in Objective-C). A preferred method for dealing with operations, OperationQueues are fairly to simple to get started:

let operation = BlockOperation {
  for index in 1...100 {
    print(index)
  }
}
OperationQueue.main.addOperation(operation)

In this example, we simply add a BlockOperation to the main queue and it will automatically start printing out 1 to 100. Most importantly, its with dependencies where OperationQueue shows their potential:

let operation = BlockOperation {
  for index in 1...100 {
    print(index)
  }
}
let anotherOperation = BlockOperation {
  for index in 101...200 {
    print(index)
  }
}
anotherOperation.addDependency(operation)
OperationQueue.main.addOperation(anotherOperation)
OperationQueue.main.addOperation(operation)

In the above example, we add a dependency of one operation (0...100) to another (101...200) to ensure that the counting is in the correct order. As a result, regardless of the order of how the operations are added, dependent operation is executed first. For this reason, the developer can add operations in whatever fashion as long as their dependencies are setup beforehand.

Problems with OperationQueue

While dependency management is easier with OperationQueues, there a couple of issues which showcase it's dated Objective-C outlook. Firstly, there is no native method for doing asynchronous operations in the Operation (or BlockOperation) class. In other words, the developer must subclass the Operation and optimize the code for asynchronous operations or convert the underlying method to an synchronous method. Secondly, there is no native way to deal with results or errors of each operation. Therefore, the developer must handle the result of each operation outside of the operation.

Instead a more modern and functional method for handling asynchronous methods and their results or errors comes in the form of Promises and Futures.

Promises and Futures of Better Asynchronous APIs

While Apple provides some abstractions for asyncronous operations, Swift developer will often run into the dreaded callback hell

doThis{
  thenThis{
    andThenThis{
      lastlyThis{
      }
    }
  }
}

This awful mess of code can be difficult to manage especially when catching error and dealing with various logic. As much as closures are superior to Objective-C code blocks, other programming languages such as JavaScript and C# have improved on this with the concept of promises and futures. In short, where a synchronous function returns a value, this abstraction allows for the returning of a promised future value.

let thatPromise = doThis(...)
let thenThisPromise = thatPromise.then(thenThis)
let andThenThisPromise = thenThisPromise.then(andThenThis)
let lastPromise = andThenThisPromise.then(lastlyThis)

Therefore, let’s take a look at a couple of Swift libraries: SwiftNIO and Google’s Promise library.

SwiftNIO - Asynchronous on the Server

While Swift's largest focus has been on the iPhone, it is important to note that the server is where asynchronous operations often occur. Whether the server is making HTTP calls to the outside or accessing a database, it has to wait for the completion of network requests. Therefore, it’s no wonder that SwiftNIO the backbone of the main server-side frameworks, Kitura and Vapor, employs its own Promise and Future infrastructure. While server-side Swift mostly uses SwiftNIO, Apple devices such as the iPhone can also use the package.

public func setupSite(_ site: Site, withTheme theme: Theme, _ completed: @escaping (Error?) -> Void)

public func setupSite(_ site: Site, withTheme theme: Theme, using eventLoop: EventLoop) -> EventLoopFuture<Site> {
  let promise = eventLoop.makePromise(of: Site.self)
  eventLoop.execute {
    self.setupSite(site, withTheme: theme) { error in
      if let error = error {
        promise.fail(error)
      } else {
        promise.succeed(site)
      }
    }
  }

  return promise.futureResult
}

In this example, there is an asynchronous function which sets up a website based on a theme. Namely, this function takes as parameters, the site, the theme, and a closure which takes in an Error if the operation failed. Given that, for the purpose of using Futures, there is a new method which returns SwiftNIO’s Future or EventLoopFuture with the resulting Site object.

Notably, in Swift, some sort of queue, thread, or loop must be specified in order to assign where the operation will be executed. Likewise, SwiftNIO uses the EventLoop to designate where the operation will be executed. Therefore, from the EventLoop, an EventLoopPromise is created. Next, from the EventLoop a closure is passed where the original asynconous setupSite function is called. From inside the closure, a success or failure state on the promise is set using .fail and .succeed. Lastly, the promise has a property which contains the future using .futureResult.

let future = setupSite(site, withTheme: theme, using: eventLoop)
future.whenComplete {
  ...
}

In most cases, the EventLoop is accessed from originating HTTPRequest or Application. In any case, to call our Future returning function and do something with the value, whenComplete to set the callback on the resulting operation.

Functional Programming in SwiftNIO

The other advantage of promises and futures, is being able to apply functional programming concepts to future results.

let futureSite = setupSite(site, withTheme: theme, using: eventLoop)
// returns a Future<String>
let futureString = futureSite.map{
  $0.name
}

// flatMap "flattens" the Future<Future<String>> to just
// Future<String>
let futureHTML = futureSite.flatMap{
    // return Future<String>
   promise(fromAsyncLoadingSite: $0)
}

let sites: [Site]
// flatten "flattens" [Future<String>] to Future<[String]>
let siteNamesFuture = sites.map{ site in site.map{ 
  $0.name   
}.flatten(using: eventLoop)

let nameAndHTML : Future<(String, String)> = futureString.and(futureHTML)

Therefore, with SwiftNIO:

.map
- converts Future<A> to Future by
- taking in a closure of type: (A) -> (B)
.flatMap
- converts Future<A> to Future by
- taking in a closure of type: (A) -> (Future)
.flatten
- converts [Future<A>] to Future<[A]> by
- taking in an EventLoop
.and
- on Future<A> and takes in a Future or B
- returns a Future tuple of type Future<(A,B)>

Unfortunately since network operation and server-side communication are at the center of SwiftNIO, the only way currently to create an EventLoop on iOS is by using a MultithreadedEventLoopGroup:

let pool = MultiThreadedEventLoopGroup(numberOfThreads: 5)
let eventLoop = pool.next()

However, a better library to implement promises on iOS (and other client devices) is Google’s own Promise framework.

Google Promise - Asynchronous on the Client

While Apple makes SwiftNIO and it contains a great implementation of Futures and Promises, it is focuses on server-side and networking related implementation. However, on the client, Google Promises might be amongst the best Promise APIs for Swift.

public func setupSite(_ site: Site, 
  withTheme theme: Theme, 
  on queue: DispatchQueue = .main) -> Promise<Site> {
  return Promise<Site>(on: queue) { success, failure in
    self.setupSite(site, withTheme: theme) { error in
      if let error = error {
        failure(error)
      } else {
        success(site)
      }
    }
  }
}

While SwiftNIO required the proprietary EventLoop, Google Promises requires the familiar DispatchQueue. Therefore to create a Promise oriented version of setupSite, the function needs a DispatchQueue parameter and needs to return a Promise on that DispatchQueue with a closure that calls either success or failure depending on the result. Therefore to call the method, the code needs to pass a DispatchQueue and on the Promise call .then to use the result.

let futureSite = setupSite(site, withTheme: theme, on: .main)
// returns a Promise<String>
let futureString = futureSite.then{
  $0.name
}

// returns a Promise<String>
let futureHTML = futureSite.then{
    // return Promise<String>
   promise(fromAsyncLoadingSite: $0)
}

let sites: [Site]
// `all` "flattens" [Promise<String>] to Future<[Promise]>
let siteNamesFuture = all(sites.then{ site in
  site.map{ 
    $0.name     
  }
)

let nameAndHTML : Promise<(String, String)> = all(futureString, futureHTML)

Functional Programming in Google Promise

Additonally while SwiftNIO differentiated .map, .flatMap, and .whenComplete, Google Promise simplifies it into .then:

.then
- converts Promise<A> to Promise by
- taking in a closure of type:
 - (A) -> (B) or
 - (A) -> (Promise)
all
- converts [Promise<A>] to Promise<[A]> or
- converts (Promise<A>, Promise, …) into Promise<(A,B,…)>

Additionally, Google Promises also has a specific method for dealing with Error or failure states:

.catch
- a Void method which takes a closure of type: (Error) -> Void

As a result to fulfill a Promise, use either then and catch or fulfill and reject:

let future = setupSite(site, withTheme: theme, on: .main)
future.fulfill {
  // on success
  ...
}.reject{
  // on error
  …
}

However while Promises and Future are certainly a better way to avoid callback hell, there are recent updates which emphasis the important of user interface responsive. That is to say rather functional emphasis on optimal operations, this emphasizes the reactive nature of UI development: Combine

Combine-ing It All Together

With SwiftUI, Apple has snuck in a whole other framework for managing asynchronous tasks: Combine. With Combine, Apple is introducing an asynchronous model more reflecting the Subscriber-Publisher model used in reactive programming.

Reactive UI Focused Asynchronous Operations

While Promises and Futures handle how to deal with the results of asynchronous operations, Combine focuses on reacting to multiple changes in multiple locations. For instance, a Publisher issues changes to data and a Subscriber listens to the those changes. Therefore SwiftUI becomes the ideal use case for using Combine with data changes. For instance, if we have a SwiftUI View which displays the header from a downloaded markdown file:

struct ContentView: View {
  @ObservedObject var nameObject: ContentObject

  var body: some View {
    Text(nameObject.name)
  }
}

In this case, this SwiftUI View contains a ObservedObject with a name property, which is the name or header of the ContentObject. Therefore, let’s take a look at the content object:

class ContentObject: ObservableObject {
  let publisher : AnyPublisher<String, Never>
  var cancellable : AnyCancellable!
  @Published var name : String = "" {
    willSet {
      objectWillChange.send()
    }
  }

  static fileprivate func markdownTitlePublisher(fromURL url: URL) -> AnyPublisher<String, Never> { … }

  init () {
    self.publisher = ContentObject.markdownTitlePublisher(fromURL: ContentObject.url)
    self.cancellable = self.publisher.receive(on: DispatchQueue.main).assign(to: ContentObject.name, on: self)
  }
}

In this instance, there is an initializer which creates the publisher for the markdown file’s h1 name . Inside the initializer, we create a publisher for the name, followed by setting up the assignment of the result to the name property. Firstly, it creates the publisher. Next, similar to before with UIKit updates, the code tells the publisher that it must receive the changes on the main DispatchQueue. Lastly, it tells the publisher to assign the value to the name property on self. With the initializer, the code has setup the publisher for the name of the content, a cancellable for the publisher assignment, and the @Published property of the name. Therefore, let’s breakdown how the publisher is created in ContentObject.markdownTitlePublisher(forURL:):

static fileprivate func markdownTitlePublisher(fromURL url: URL) -> AnyPublisher<String, Never> {
  return URLSession.shared.dataTaskPublisher(for: url).tryMap { (arg: URLSession.DataTaskPublisher.Output) throws -> String  in
    let (data, _) = arg
    let text = String(data: data, encoding: .utf8)
    guard let value = text?.components(separatedBy: .newlines).first else {
      throw InvalidTextError()
    }
    return value
  }.catch({ (error) in
    return Just(nil)
  }).compactMap{ $0 }.eraseToAnyPublisher()
}

Functional Programming with Combine

Luckily, Combine provides already built-in methods for publishers for the three main asynchronous APIs, which I talked about previously: NotificationCenter, Timer, and URL tasks. In this case, let’s look at how URL Task publisher transforms to useable String value for the name property:

tryMap reads the first line of text by decoding the binary data into text and reading the first line.
catch converts the useless error into nil... For a SwiftUI View to use a publisher, the publisher must always handle the error in order to assign the value.
compactMap removes any nil values from the publisher pipeline
eraseToAnyPublisher uses type erasure to remove the specifics conversions taken place.

Therefore, with all the plumbing in place, SwiftUI and Combine will display the display the first line of the markdown file.

In conclusion, Combine really shows it’s power when it comes to UI updates (not just SwiftUI but UIKit, AppKit, etc…) and any situation where reactive programming makes sense such as when there are multiple publishers and subscribers. However if you are comfortable with Promises and Futures and your code is more simple and straightforward it’s perfectly reasonable to go with that method.

Coroutines - The Future of Asynchronous Operations

Before closing out, there has been proposals for making Promises and Futures native in Swift along with the syntactic sugar some common in other languages known as Coroutines. (Read more about Coroutines in Chris Latner’s proposal.) Let’s take a look at our earlier example:

let url = URL(string: 
 "https://jaspervdj.be/lorem-markdownum/markdown.txt")!
URLSession.shared.dataTask(with: url) { 
 (data, response, error) in
  …
}.resume()

In this case, a closure is based as a parameter along with a task. However a Promise or Future might look something like this:

let url = URL(string: 
 "https://jaspervdj.be/lorem-markdownum/markdown.txt")!
let promise : Future<(Data?, HttpResponse?, Error?)> = URLSession.shared.data(with: url) 
promise.

With syntactic sugar like async and await, it become even cleaner with:

let url = URL(string: 
 "https://jaspervdj.be/lorem-markdownum/markdown.txt")!
let response = await URLSession.shared.data(with: url)

To declare a method as being asynchronous and wrap a previous method (using a callbackWrap method for now) such as setupSite previously:

public func setupSite(_ site: Site, withTheme theme: Theme) async throws -> Site {
  return await callbackWrap { continuation in
    self.setupSite(site, withTheme: theme) { error in

      if let error = error {
        continuation(error)
      } else {
        continuation(site)
      }
    }
  }
}

With async and await along with Combine, Swift can really take advantage of asynchronous programming both from the simple Promise/Future mindset as well as the Reactive programming paradigm.

What’s the Right Toolset?

In conclusion, developers have some key decisions when it comes to the best way to deal with asynchronous, parallelism, and concurrency:

Take Advantage of Your Hardware - make sure not to lock down the whole device or application with one thread but allow for many actions to take place simultaneously
Avoid Convoluted Logic in favor of Easy Maintenance - make it easier for the next developer to update your code, don’t over optimize without componentizing
Provide Fast UI Experience over a Speedier Logic - giving healthy feedback to the user of what’s going on is more important than a faster application - again avoid freezing your app and device
Use Abstractions As Much As Possible - unless you are into highly processor intense applications - use Apple’s provided abstractions (i.e. Combine, etc..) rather lower-level direct APIs (i.e. Threads)
Avoid Callback Hell with Promises and Futures - for simple non-UI code use Promises and Futures to organize multiple asynchronous calls as opposed to a pyramid of callbacks
For UIs on the latest Operating Systems (iOS 13, watchOS 6, tvOS 13, Catalina) use Combine - Combine gives the OS better control of the flow multiple asynchronous operations using reactive patterns

Hopefully this article gives you more guidance on how to better manage multiple operations and optimize your application for a better user experience. I am looking forward to even better APIs with Swift in the future.

If you have any questions, reply to me on Twitter @leogdion and if you want to learn more fill out the form below:

Best Backend for your iOS App

leogdion — Wed, 21 Aug 2019 12:00:07 +0000

Choosing the best backend for your iOS App can be a challenge? The options are robust and depend on a number of questions like-do you need a cloud service? Should you run your own server? Should you use Cloudkit, Firebase, or another option? We dig into these questions and the other things you should consider when looking into back-end and cloud services for your iOS app.

First, it’s important to point out that cloud services aren’t needed in every case when it comes to an iOS (or any mobile) app. So, what can you do without them? A lot, actually.

So one thing to consider is — there’s a lot you can get away with without even doing cloud services. The thing with an iOS app is you can store your data in something like iCloud or in a lot of cases people really don’t need the cloud to store their data. They can just store it on their phone itself. EmpowerApps.Show — Episode 8 — Cloud and Backend Services

Best Backend is No Backend?

Is the best backend for your iOS app, no backend? In many cases, you don’t need cloud services for storage as you can just use the phone itself. When you’re building an app, you should consider whether you really need something stored in the cloud or are you able to use a manual mechanism to back up the data? If you can create a mechanism that saves the data into cloud storage as a file, it could save you a lot of time and money.

In cases where you are dealing with private or sensitive data, it’s a good idea to stick with your phone. This is especially true when dealing with third-party apps like Twitter or YouTube or another API where you’re not really storing data but storing in the third party’s structure. You can use that API as your database.

As an example, in an app built for doctors and nurses to receive continuing education for their career, all the data was essentially stored using Core Data which is a SQLite database abstraction layer. It was all stored locally because their time and budget didn’t allow for anything else. There was a manual backup process put in place that would run and create a zip file of the data and save it on the device. If they needed to restore it, they could sort it in the cloud and restore it back to their phones.

Cloud and Backend Services For Apps

EmpowerApps.Show

Your browser does not support the audio element.

1x initializing... ×

Choosing Cloud Services for Your Best Backend

The best backend for your iOS app can be really helpful if you’re storing data or syncing across multiple devices. For example, note-taking apps that are available on all Apple devices (phones, iPads, computers) use a combination of iCloud and CloudKit to store information on the back-end. When a user opens their notes on their Mac or their iPhone, they are all available and accessible because they are stored in the cloud.

If you’ve decided that you do need back-end storage-what are some things you should consider when choosing the right path? Let’s take a look.

One thing to consider is timeline and budget and specifically what is the purpose of this app? Is this just a simple MVP or is it more of a long-term app that needs to be well architected when I first starts off?**EmpowerApps.Show — Episode 8 — Cloud and Backend Services**

The Purpose of Your App: MVP Vs. Enterprise

Take a look at the app you’re designing. Is it an MVP or a more robust Enterprise app?

An MVP (Most Viable Product) is a simple app that is just proving it’s something your customers will actually want. It’s something you need to get out quickly and is most likely a bare-bones version of the basic features you think your customers will want.

Or, does the app need to be well-architected right from the beginning, like an Enterprise app for a Fortune 500 company? If you’re going this route, you’re going to want something that is more robust and customizable and it should be something you’ll want to work with for the long-term.

If you’re looking to get out an MVP, the best backend for your iOS app is something that’s simple, easy, and cheap and will just get the job done. It should be something that can be easily tested by your audience so you can see if it works with the needs of your users.

You’ll also want to make sure you have some healthy abstraction with your API communication when you are writing your Swift of Objective-C code to talk to the back-end. That way, you will be able to pivot easily if you decide to use a different service at a later date and your users won’t see anything different on the front end.

Supported Devices

Are you only supporting Apple devices? Are you also going to support the web? Are going to support Android? Are going to support Windows and Linux desktops? Are you going to support the internet of things? These are all questions to consider when deciding what back-end services to use.

If you’re only supporting Apple devices, you may want to consider CloudKit, an option we’ll discuss in more detail below.

Complex Vs. Simple Queries

Some tasks, like relational data, are best performed through some sort of SQL database. However others might work better with a document storage type database. Most importantly, you should consider whether you need to aggregate your data or whether you need to create filters. In other words, do you need to view your data in a lot of different ways to combine your data set.

Conversely many simple document-based cloud storage options are cheaper. Therefore, if you’re willing to offload a lot of the complexity of a good query over to the device like your iPhone document-based storage like Firebase might be a good option. Additionaly, you could consider caching your complex data for later rather than querying the data each time. Remember, a simple query would need to lookup data with a particular ID only.

You need to ask yourself if you’re willing to offload a lot of the complexity of a good query over to the device like your iPhone, or is it more important to have that information on the server. The best backend for your iOS app might not be the easiest to query but the cheapest and easiest to maintain.

Outside Communication

Besides storage, you should also ask yourself if you will need any outside communication or outside scheduled jobs. This may occur if the user does something that creates data and then you need to be able to access that data even if they have their phone off such as email newsletter, shipping orders.

The Expertise of Your Team

This is a big factor because if their expertise is.net, you’re probably better off using a Windows back end with an SQL Server and C#. If you’re already getting a decent price on Azure, for instance, use it because that’s what your team is an expert in. If your team is well versed in Swift, you may want to consider Vapor for your backend. Check out our review of Vapor here for more details.

User Interface (UI)

We also recommend doing some user-focused design to come up with the kind of data that your users will need. Afterwards, work your way back towards how you would need to store that. For instance,yYou can start by building out the UI of the app and essentially fake the data to make sure that data is what the customers want and then go back from there. Get your UI taken care of because that’s the thing the users are going to see.

These factors, plus the budget you’re working with and the time you have to spend are all factors to consider when thinking about back-end storage.

Cloud and Backend Services For Apps

EmpowerApps.Show

Your browser does not support the audio element.

1x initializing... ×

The Options

Once you’ve asked yourself all the necessary questions, you’ll want to start looking at the options that fit your needs and budget. If you feel you need back-end support, you’ll need to decide the best option for your app and your user. Here are some options to consider.

…Some of the advantages of hosting your own is the fact that you can customize everything down to the minutiae, I mean you basically have a whole machine that you can work with that is also the disadvantage because the burden is on you to make sure everything is set up correctly wear as a lot of these other services. They pretty much can take care of everything. All you need to do is write your app code and get your database setup. EmpowerApps.Show — Episode 8 — Cloud and Backend Services

Hosting a Server For Your Backend

The most customizable and robust option is just to host your own server. You can buy your own server and host it at a site with a virtual machine like AWS EC2, Linode or DigitalOcean. Linode is an affordable option at $5/month. However, you may not want a complete server both due to the cost but also the need for maintenance.

Kubernetes is owned by Google but is open source and even AWS, Linode and Digital Ocean also host Kubernetes instances. This is a popular option for good reason, especially in the dev-op space.

If you’re starting from scratch and want something to play with, Heroku is a great option. Their free tier which includes a PostgreSQL database is plenty to start with.

Speaking of PostgreSQL, you’ll need to set up your own database, as well as other server software. Here are some specific options to consider:

Databases

You’ll need something to server content whether it’s images, JSON, or HTML:

Server Software

Also consider some other services such as:

Cloudflare for monitoring, caching and CDN
New Relic for monitoring and security
Supervisor for services

If you’re working with a simple MVP or releasing only for Apple, we would not recommend hosting your own. If you have simple needs go with the simplest solution and then plan on scaling out from there according to the growth of your own needs.

CloudKit as Your Backend

One really affordable option worth exploring in more detail is Apple’s back-end storage system, CloudKit. CloudKit is fairly simple to use if you’re sticking with iOS. It comes with push notifications and is completely native to Apple. If you’re running a Mac app or an iPad app or using an Apple Watch or Apple TV, it’s really easy to use. It also includes a JavaScript component for the web. It is an easy yes is if you’re just going to target Apple devices. When using CloudKit, you would be fine offloading some stuff onto the iPhone itself if the data isn’t too complex.

If you absolutely need to run outside backups or outside cron jobs and can’t do it on an iPhone or an iPad, then you might want to consider another option.

Firebase as Your Backend

Another popular option is Firebase. Firebase is the most popular mobile back-end as a service not only because of price but also because it’s available on a plethora of devices. But beware, on the surface, it seems really appealing but we would hesitate when recommending it for projects that might scale. If you want to learn how to do real-time database integration in a web browser and you don’t want to introduce apps where you have to create a lot of extra code in order to access data, Firebase is a great way to go about it.

But, while it is popular, after some research it appears that not a lot of enterprise-grade companies are relying on it. We recommend using it for very very simple situations where you have data that is not going to change in structure over time, data that’s generally flat, and when you don’t have to do lots of complex queries. Really study the limitations before you jump into it as it may not be a good fit for what you are looking for.

Cloud and Backend Services For Apps

EmpowerApps.Show

Your browser does not support the audio element.

1x initializing... ×

Final Tips

We know we’re leaving you with a lot of information, so as a final tip, we wanted to add this piece of advice-when considering any storage solutions, check to see if there are any big companies using it. The best backend for your iOS app needs to be something that’s rock solid and stable and gets a lot of support, just check out what the big guys are doing. You can be sure that the companies with a lot of money to spend will have taken the time to research and vet these solutions so you can consider anything they are using, a little bit safer than an under-researched option.

Typically they’ll go with one of the big three: AWS, Azure, IBM. Or, they’ll decide to host their own.

Whatever you choose, remember, if you need to pivot, do it early. Don’t do it when it’s too late. If you feel like your data isn’t a good fit for whatever you end up, make the change as quickly as you can because you’re not going to want to be burnt out by constantly trying to get your data to fit in particular space.

Want even MORE info? Check out the entire conversation here and subscribe to our newsletter to stay informed.

Originally published at https://brightdigit.com on July 30, 2019.

Podcasting — Getting Started — Whys and Hows

leogdion — Tue, 25 Jun 2019 12:36:56 +0000

It has been at least 15 years but I remember as soon as iTunes came to Windows, I downloaded podcasts. For example, it could have been the software development podcast, dotNet Rocks, or the financial podcast, Planet Money, giving a narration and analysis of the 2008 Financial Crash as it happened. Generally speaking, podcasting as these podcasts do, gives specific audiences an in-depth specialized analysis without the need to appeal to the general audience.

Therefore in 2017, I decided to jump into podcasting and start two podcasts:

OKProductive — my podcast with Erik on personal productivity

My Podcast about Apple, Business, Apps, and Development

one on personal productivity and another for my business on software development for Apple hardware. Important to realize, both podcasts are some sort of combination of passion, business, and expertise. And so, I want to talk about the ins and outs of podcasting.

That means:

Why should you start a podcast
How to build content
How to stay organized
Recording and editing audio
Hosting and Publishing
Reaching Your Audience

Recent Talk I did at Lansing Marketing Hackers on Podcasting

First of all, the #1 question you should ask is why you should start a podcast.

Why Should You Start a Podcast?

Podcasting may sound simple at first but to really be successful at it you need perseverance. Therefore, you need to really have a good reason and passion to do for a while. For this reason, rather than discussing how to start podcast let’s discuss the why.

Most importantly, sharing your expertise on the web provides a great example to others. However, more so than a written format, talking about a topic is a more natural means for people. Uniquely, rather than giving a talk to 40 people, podcasting allows you to present on topic many times over. In addition, not only can you sell yourself but a product as well.

Sell A Product

Podcasting can be a great way to sell your products. By starting a podcast, you can give your products a narrative and showcase as to how they are helpful. However, the most important part of selling anything on the web is to provide actual informative valuable content. Don’t just sell but provide advice — You build trust as well as true expertise on the product’s subject matter.

Enjoy a Topic or Hobby through Podcasting

While selling yourself or your products are good reasons, you need to have some sense of enjoyment or passion to really carry out the momentum of producing a podcast show. Recently on Pat Flynn’s Smart Passive Income podcast, he interviewed MKBHD, a YouTube tech reviewer with over 8 million subscribers. MKBHD revealed on the show he produced 100 videos before he even had 100 subscribers. Building an audience with your show is going to be a long and slow process. For this reason, having enjoyment and passion in podcasting will give you the momentum to carry it through that long process. As a result, if you do decide to start a show though, it’s important to know where to start.

How To Get Started Podcasting?

Podcasting involves five components: content, organization, audio, hosting, and reaching your audience. With this in mind, having engaging content is perhaps the most important.

Building Content

Based on why you starting your podcast and the type of show you are doing, you need to build a list of topics for your show. With this intention, you need build on your existing expertise and passion while also finding your audience and seeking their pain points.

Build On Your Existing Expertise and Passion

As a result, by building on your passion and expertise, you sound natural and engaging. Nevertheless, if you get stuck compiling a list of topics based on your expertise alone, you can look to your potential audience online. Additionally your audience online will give you insight into their questions or challenges.

Find Your Audience and Their Challenges

The web is a great way to reach your audience but it’s also a great way for you to find your audience and the challenges they face. For example, Reddit, Quora, Stackoverflow, Slack Workspace, Youtube Comments, Twitter, Facebook Groups, and any website forum — as long as there is engagement there — is a great opportunity to see what your audience is facing as far as difficulties and where their pain is. They don’t need to be listeners of your podcast already — they just need to be the people you are targeting. Along with your knowledge, you should have enough content to get started. The important thing is to keep that content organized.

Staying Organized

There are two key components to staying organized with your podcast: having prepared notes before you record and having a consistent recording and publishing schedule.

Have Prepared Notes Before You Record

Behind the scenes of every great show are some sort of notes when it comes to the topic of each episode. Moreover, even when talking off-the-cuff, it’s important to have anchor points for your discussion. Furthermore, some shows even go so far so to have a complete script. In the end, it really depends on you and the type of show you are producing. Most importantly, the worst flaw is losing your train of thought and having not enough to talk about. Therefore, the most natural way of doing this is by talking about what you are an expert at and passionate about. As a result, there are several methods of breaking down any topic into prepared notes:

5 W’s — Who, What, Where, Why, HoW
Chronological Narrative
Essay Format — Thesis Statement with Three Points

With this in mind, whatever format you choose make sure you have a structure and stick with it. If your content has structure, it will give your audience an easier way to organize the content and make it memorable. In addition, building these pre-show notes are a great way to indicate to yourself that you have enough content. Afterwards, these pre-show notes give you an skeleton you will fill in later for the show notes which will be posted publicly with your episode’s metadata. For example, check out this sample from the episodes Erik and I did for OK Productive on the book Atomic Habits by James Clear. In the same way pre-show notes give you a skeleton to work with, consistency in your schedule can help continue your show’s momentum.

Have A Consistent Schedule

Having a consistent schedule, both in recording and publishing, sets your audience expectations and makes sure you build a habit and flow with recording. For example, what I do set aside every Thursday morning to record an episode of each of my podcasts and publish every other week each podcast. By doing this, I have built a habit and expectation on my part that I’ll record every week. Additionally, with the recording to publishing ratio being 2:1, I have now a buffer of episodes, in case something happens: sickness, vacation, etc…. As far as publishing, I have a pretty consistent schedule, publishing every Saturday night or early Sunday morning. Based on playing around with different days, it seems most folks download episodes at the beginning of the work week. This could differ with your audience but clearly setting those expectations are helpful to your audience. Now that we have pre-episode notes and a regular recording schedule, let’s talk about recording.

Working with Audio

The most technical aspect of podcasting is recording and editing your episode. However before we began, I want to reiterate one point: don’t sink money in the best equipment until you are sure that you’ll stick with podcasting. Surprisingly, you may already have much of the equipment and there is plenty of free software to do this. As a result, I’d recommend spending some money on better equipment and software perhaps around the 6 month — 9 month time range or once you’ve recorded approximately 10–12 episodes and have a rhythm in your schedule. Firstly, the equipment which takes in your voice before anything else is going to be your microphone.

Your Podcasting Microphone

Your microphone is going to be your first connection to your audience. When first starting off, I’d recommend using a microphone — any microphone. Most importantly, don’t rely on your laptop microphone and webcam microphone for your audio. In addition, test your audio recording before moving to an editing phase. As far as microphone upgrades, the next step is spending money ($50 — $99) on something like what I use: Audio-Technica ATR2100-USB In addition, they also sell a combo which include a pop filter and studio, that I use and highly recommend.

Once you’ve reached a point where you wish to go even more professional, you’ll want to look a more expensive microphones and a mixer/pre-amp. These will give an even better sound, more control, and better realtime feedback of your audio. Here are some links which you might find helpful: Therefore, once you have a good microphone for recording, you’ll need software to record your audio.

Recording and Editing Your Audio

Recording software can be fairly simple and inexpensive. For example, there’s free software such as Garageband and Audacity for macOS and Windows/Linux respectively. However, if you are planning to edit your podcast then it maybe worth your money to purchase something like: Apple’s Logic Pro or Adobe Audition which give you more granular control over editing functionality.

Remote Interviews

Specifically, remote interviews can present its fair share of challenges. For example there are recording apps such as Zencaster which specialize in this. Additionally, you could also record your interview over a conferencing service like Zoom or Google Hangouts strip the audio portion and turn that into an episode. Surprisingly though, the conferencing choice of most podcasters is Skype. However you’ll want to record you and your interviewee on separate tracks. For instance as a macOS user, I use Soundflower to map my audio channels properly (i.e. my microphone and Skype audio to separate tracks). Furthermore, I also encourage my guest to record there own audio since sound quality via Skype isn’t the best.

Editing Audio

Therefore, once you’ve recorded your audio, the next step is editing. Most importantly, having a great recording helps increase the quality of the recording overall. That is to say avoiding filler words, dead air, and meandering rants will improve the quality over any recording. However, in the end, editing will typically be needed. In the end, with editing, you want to make sure your sound is clear (and there are a variety of filters to do this) and is worth the effort. It can also be the most time consuming which is why I’ve started outsourcing my editing. As a result, we have a decent audio waveform for our episode, we’ll need to export the file.

Exporting and Tagging Your Files

An often forgotten step is including helpful metadata and proper formatting of the resulting mp3 file. Therefore, include the correct podcasting metadata and be sure to export as a mono 64kpbs mp3 file. Luckily, most editing tools provide a means to attach metadata such as podcast title, episode title, summary, and chapters with your episode. In the end, you’ll have your brand new episode as an mp3 file. The question then becomes where to upload your file.

Podcasting Hosts and Publishing

Hosting your show can tend to be a bit of a maze:

a place to put your mp3 file
a place to host your show’s website
a way to broadcast to various MP3 players

Hosting Your Mp3 Files

First thing first, do not try to host your own mp3 files. In contract to simple web pages, these can take several MBs of data and when as many as a hundred people are downloading your episodes you can be bitten by download limits, speed issues, and various other issues. For example, when I first started out, I hosted the website on WordPress and the mp3 files on Amazon S3. In reality, this involved a lot of manual processes with each episode. Therefore, once my WordPress sites were hacked, I knew I had transition to a dedicated podcast hosting provider. As a result, I moved to Transistor, which has worked out fantastically. Other services which do this are:

Significantly, remember with all these hosts, there could be download caps, ad insertion, speed throttling and more which could hinderacne your experience. In the end you’ll get what you pay for.

Be that as it may, each host will provide a place to upload your mp3 files, provide additional metadata, as well as more elaborate public show notes (as opposed to the pre-show notes you use for talking points). In the end you should have a publicly available RSS feed for your show.

Publishing to the Web

As far a website, services like Transistor, come with a website of some sort and other services like Blubrry integrate with WordPress. However what’s even more important than a website is making sure your audio is delivered to the numerous podcast clients. Therefore, each podcasting host will deliver an RSS feed which contains metadata about the show as well as continually updated list of episodes. As as result, you’ll use this to claim ownership of your podcast. Consequently, before submitting, make sure you have at the very least 3 episodes uploaded as well as a correct author email address setup with your podcast host. With this in mind, while most clients let you manually add RSS feeds, most users will expect to find your show by searching. Therefore, here is a brief list of clients and how to get your show posted there:

iTunes

Google Play Music

Sign up at Google Play Music with your show’s RSS feed and validate with your author email address.
Google Podcasts
As long as your website is easily searchable, Google should add it automatically. Use Google WebmasterTools to verify this and be patient as it can take several days.
Spotify
Go to Spotify for Podcasters and submit yourRSS feed and validate. Some podcast host services offer this automatically such as
Transistor.FM .
Stitcher
Submit your RSS feed through the partner portal and validate your email address.
Breaker
Submit your RSS feed through BreakerUpstream and verify your email address.
Pocket Casts
Submit your RSS feed to Pocket Casts and validate your email address.
CastBox.fm
Apply through creatorstudio and confirm with email address.
Radio Public
Submit your RSS feed for Radio Publichere and validate your emailaddress.

Tune In
Submit your RSS feed and other info to Tune Inhere.

Most importantly, for many of these services, it could take days for submissionto work. Surprisingly, some clients like iTunes Connect, actually mirror, ordownload and re-host your podcast on their platform. Additionally, if you areinterested in reaching Alexa, check out this talk I hosted recently where PaulSchmidt talks about turning podcast episodes into Alexaskills. As a result, now that we have our podcast available on a variety of platforms the next step is reaching your audience.

Reaching Your Podcast Audience

Congrats on getting your show recorded, edited, and hosted. However the realchallenge in podcasting comes from growing your audience. In that case, part of that is SEO tricks which can take advantage of Google and various podcast clients. Rather, you can go back to how you found your audience earlier and answer those questions with summaries and subscribable links to your episodes. By this means, you can realiably reach your audience directly.
Social media has its advantages and disadvantages. However, if you don’t have anexisting audience, it can lead to not much return on your time. Nevertheless if you do post to social media, make sure it’s a platform your audience uses. Forinstance, converting 30 second clips into videos are a great way to capture youraudiences attention. Such as, this script I have written to convert 30 second mp3 files into videos for social media.Additionally, Erik, my OK Productive co-host and I use tools likeBuffer to automate the process. Surprisingly, the other way to reach your audience is by an email newsletter.

Emailing Your Audience

Email may seem antiquated but newsletters are more guaranteed to reach your audience then any social media channel. Accordingly, with email addresses, you can also directly reach your audience and get their feedback. As a result, once you have enough of a large audience, you begin to focus other written content as well and gauge interest accordingly.

The Whys and Hows of Podcasting

Now you have a roadmap for discerning and getting started podcasting — from idea to publishing. Firstly, before jumping in, make sure the audience is there as well as your passion and expertise on the topic. Most importantly, have basic recording equipment and test recording an episode before posting. At the same time, begin having talking points and a schedule for recording. Consequently, find a good hosting provider for your mp3 and make sure to export in the correct format. As soon as, you have at least 3 episodes posted to your host, publish your RSS feed to various services. As a result, share your episodes on social media, in various audience websites and forums, and perhaps start an email newsletter to keep your subscribers in touch. to sum up, while podcasting is work, it can be lots of fun. Most importantly, you can always put in as much work as wish. If you have any questions, please be sure to reach out to me. I’d love to hear your podcasting stories and lessons you’ve learned.

DEV Community: leogdion

Swift Packages – Dependency Management of the Future

Modularity and Reuse - Benefits of Package Management

What Came Before... and is Still Around

Why Swift Package Manager?

Why Publish with Swift Package Manager?

Full Stack Swift

Testability

Command Line Tools

Power of SPM

Combine & CoreLocation, Part 3 - Integrations with flatMap

Using Combine for Complex Transformations

Built-In Publishers from Combine

Integrations in Combine

Combine System Publishers with flatMap

Combine with other Delegates

Other Resources

Practical Combine with Donny Wals

EmpowerApps.Show

Combine & CoreLocation, Part 2 - Receiving & Handling Events

Receiving and Handling Events in our ObservableObject

Receiving and Handling Events with Sink and Assign

Using Sink For Calling Methods

Receiving and Handling Events with Assign (in iOS 13 and iOS 14)

Sink vs Assign when Receiving and Handling Events

Combine & CoreLocation, Part 1 – Publishers & Delegates

Gonna Delegate Like It’s 2009

SwiftUI Scaffolding

Extending Delegates into Combine Publishers

The Power of Type Erasing Publishers

Transforming Authorization Status into a Publisher

Practical Combine with Donny Wals

EmpowerApps.Show

What's Next?

flatMap, Double Optionals, and Functional Programming

flatMap vs map and Generic

Arrays of Arrays

flatMap and the elusive Double Optional??

flatMap, parsing, and conversion

flatMap vs compactMap

flatMap and flattening the Optionals and Generics

What You Should Know About iOS Software Architecture

iOS Software Architecture Patterns

Delegation and MVC with iOS Software Architecture

Protocol-Oriented Programming

Functional Programming

Reactive Programming in iOS Software Architecture

WWDC 2019 - Swift UI with Jason Anderson

EmpowerApps.Show

Why Code Modularity Matters in iOS Software Architecture

Framework Targets

Projects and Workspaces

Swift Packages

Modularizing in Xcode with Abbey Jackson

EmpowerApps.Show

Why Maintaining Code Quality Matters

Test-Driven Development

Ensure Good Code Coverage

Complexity

Managing Code Quality with Anne Cahalan

EmpowerApps.Show

Code Reviews

Continuous Integration

The Components of Good iOS Software Architecture

Want more about iOS software architecture on how to create better iOS apps?

Productivity Apps for Developers (and Everyone Else)

Managing Productivity Apps and Disk

016. Productivity Apps Episode

OK Productive

Time Tracking and Scheduling Apps

Reminders and Todo List Productivity Apps

007. List #2 – Top Apps Episode

OK Productive

Notes and Writing Productivity Apps

Creative Apps

Marketing Apps

Communication Apps

Avoid Over Optimizing Productivity Apps

Swift Package Continuous Integration Guide

Getting Started

Combine System Publishers with `flatMap`

Using `jq` to Verify Products