If you're coming from Java, C++, or other object-oriented languages, chances are that you've never come across optional types or "optionals". And you might be quite surprised to know that such a concept exists in Swift.

Optionals are a fundamental topic that you need to thoroughly understand to code in Swift. If you're just getting started with Swift and you're learning about optional types for the first time, make sure to read this article until the end.

To understand what optional types are, let's quickly brush up on constants and variables.

Constants and Variables in Swift

A constant is a data item whose value, once assigned, cannot be mutated (modified or changed) throughout the scope of the program.

On the other hand, a variable is a data item whose value can be changed limitlessly.

There are some nuances in how declare constants and variables in Swift. Let's look at that syntax:

<data-item-type> <var-name>:<data-type> = <value>

Here's an example of a constant:

let pi:Double = 3.1415

And here's an example of a variable:

var message:String = "Hello, this is prajwal"
message = "Coding in swift is awesome" //variable value changed.

Notice that of the keywords we've used here for declaring constants and variables, you use let to declare a constant, and var to declare a variable.

The keyword is then followed by the constant/variable name, a colon and its data type, and then the assigning value.

Swift is a type-safety language, which means that you can assign variables and constants values without specifying the data type. It can make appropriate assumptions based on the assigned value, for example:

let const:String = "String"

can also be written as,

let const = "String"

And,

var speed:Int = 20

can be written as,

var speed = 35

You might be wondering, if you can omit the data type then what's the need to specify it anyway? Well, you're right to wonder that – but you need to specify the data type once you're working with optional types, which are different from conventional data types.

Optional types or Optionals in Swift

Coming to the main point, what are optional types in Swift?

Let's see what the docs have to say about it:

You use optionals in situations where a value may be absent. An optional represents two possibilities: Either there is a value, and you can unwrap the optional to access that value, or there isn’t a value at all.

That's a pretty straightforward definition. So optionals are basically used to handle null values at compile-time to ensure that no crashes occur at runtime.

Any operations on the optional variable are performed only if it contains non-null values.

An optional type can be of any data type, like a String, Integer, Double, Float, or any user defined non-primitive data type (object).

But, it is important to note that the Optional data type is not equivalent to its base data type. For instance, an Optional String is not the same as a string, an Optional integer is not the same as an integer, and so forth. This is because primitive data types cannot handle nil values, but Optional types can.

Optional Types Syntax and Usage in Swift

Here's the syntax for an optional type:

<data-item> <var-name>:<data-type>?

The declaration is similar to declaring regular variables, except that you add a question mark (?) beside the data type which makes it an Optional type.

Fire up your XCode playground and try running these snippets:

let someVal:Double?
someVal = 5.6324

print(someVal)
//Output : Optional(someVal)

var str:String? = nil

str = "Hello, World!"
print(str)
//Output : Optional("Hello, World!")

You can see that the outputs are not regular values. Instead, they're optional values.

How to Unwrap Optional Types in Swift

You won't use optional types upfront for any operations or tasks, as they should be cast in their primitives or user-defined instances before using it elsewhere (an optional string should be cast to a string, an optional integer should be cast to an integer, and so on).

This casting is what's known as unwrapping. You can better understand this concept by thinking about Schrödinger's cat.

In this thought experiment, a cat is placed in a closed box along with a vial of poison. Unless you open the box, you can't assure whether the cat is dead or alive ( nil or non-nil). This means that it is both dead and alive at the same time (nil and non-nil) according to your perception.

Only when you open the box (unwrapping) can you learn if the cat is alive or not (nil or not).

Unwrapping in Swift is essentially verifying if the Optional value is nil or not, and then it performs a task only if it's not nil.

You can perform unwrapping in the following ways:

1. Using an if else block
2. Using Forced unwrapping
3. Using Optional binding
4. Using Optional chaining
5. Using a nil coalescing operator

Unwrap an optional type with an if-else block

Unwrapping means to make sure that the Optional value is not nil. You can do this by using a simple if-else block like this:

var variable:String? //evaluates to nil

if variable != nil{
 print("Not nil")
}
else{
 print("Nil")
}
//Output : Nil

Unwrap an optional type with forced unwrapping

Forced unwrapping is quite contradictory because you're accessing the optional value regardless of its value (nil or not nil). If a nil optional is unwrapped, an error is thrown saying "Unexpectedly found nil while unwrapping an Optional value."

You're supposed to use forced unwrapping only in a pre-defined environment where you're certain that the optional value won't be nil.

You can forcefully unwrap an optional using the exclamatory(!) operator like this:

var color:String?;

print(color!) // Unexpectedly found nil while unwrapping an Optional value

color = "Black";

print(color!) // Black

Unwrap an optional type with optional binding

Optional binding is similar to using an if-else block. The only subtle difference is that if the optional value is not nil, the unwrapped value is assigned to a new constant and further operations are performed on the constant.

You can do this using the if-let statement:

var password:String? = "$tr0ngp@$$w0rd"

if let unwrappedpass = password {
    print("Password is \(unwrappedpass)") //Password is $tr0ngp@$$w0rd
}

An optional string password is assigned the value $tr0ngp@$$w0rd. Then in the if-let block, the optional value password is unwrapped and assigned to the variable unwrappedpass only if the optional value password is not nil. unwrappedpass now contains the unwrapped value and can be used within the block's scope.

var password:String?

if let unwrap = password{ // Block unexecuted, as optional password is nil.
    print("value is not nil")
}

Unwrap an optional type with optional chaining

You use optional chaining in places where you're dealing with multiple optional values at once. You use it to access and mutate or assign far-fetched attributes whose value depends on other constraints.

For example, we get our food from plants, which in turn get their food from sunlight and water.

This means that there is a chained dependency of events – we are dependent on plants for our food, and plants themselves are dependent on water and light for their food.

Optional chaining involves verifying at each dependency if the instance is nil or not.

Let's see how this works with a code example:

class ShipmentCar{
    var seats:Int?
    var quality:String?

    init(seatQty:Int){
        seats = seatQty
    }

    func displaySeatQuality(){
        if let seatQuality = quality{
            print("The seat covering is made of:\(seatQuality)")
        }
    }



}

class CheckSeats{
    var seatExists:ShipmentCar?

}


var obj = ShipmentCar(seatQty:4)
var obj2:CheckSeats?
obj2 = CheckSeats()
obj2?.seatExists = obj
obj2?.seatExists?.quality = "Leather" //Optional chaining, set leather quality of seats, only if seats exist.
obj.displaySeatQuality()
//Output: The seat covering is made of: Leather

In the above example, we have two classes, ShipmentCar which is cargo, and CheckSeats to check if there are any seats in the vehicle.

We first create an instance of the class ShipmentCar and pass the argument as 4 for the number of seats – meaning that there are 4 seats in the vehicle.

Further, we create an optional instance of the class CheckSeats and instantiate it. The attribute seatExists of the class CheckSeats is of the type optional ShipmentCar.

Next, we perform optional chaining on the instance obj2, which we write as obj2?.seatExists?.quality = "Leather". This means that we check if seats exist in the car, and if the seats exist, we define the quality of the seat cover which is Leather. Then we verify by calling the displaySeatQuality and get the desired result.

Here's a small caveat: in the above example, if you set the value of seatQty as 0 instead of 4, it'd still output the same result. This implies that the seat covers are made of leather even though there are 0 seats, which would make no sense.

So, I'd like to mention that this is just an example and the main objective here is to emphasize that the attributes are assigned values only if the dependent attributes are not-nil.

Unwrap an optional type with the nil coalescing operator

The nil coalescing operator works as shorthand notation for the regular if-else block. If a nil value is found when an optional value is unwrapped, an additional default value is supplied which will be used instead.

var text:String?

var output = text ?? "Default value"

print(output) // Default value

text = "This is a string"

output = text ?? "Default String"

print(output) // This is a string

You can also write default values in terms of objects.

Wrapping up

There you have it! In this article, you've learned all about optional types and how to use them.

I'd like to thank you for reading this far and I hope this article has helped you understand optional types in Swift.

If you've any queries, feel free to contact me on Twitter and/or LinkedIn. I'll be happy to help you. Cheers!

In a previous tutorial, you learned how to add Bluetooth to a Particle Xenon application. That way you could control the onboard RGB LED from a test app like nRF Connect or Light Blue Explorer.

In this post, we're going to take it one step further. We're going to develop a Swift app to control a Particle Mesh RGB led. If all goes well, you should have a working app in about 20 minutes!

Let's get started.

Don't have time right now to read the full article?

Download the PDF version here.

Getting set up

• Install Xcode. You can download it from the App store here.
• You'll also need an Apple login. I use my iCloud email. You can create a new account within Xcode if you don't have one yet.
• Install the RGB example code on a Particle Mesh board.

Create the project

Once everything is installed, let's get to the fun stuff!

Open Xcode and go to File → New Project.

Select Single View App.

Then update the Project Name to be to your liking. I've also changed my organization identifier to com.jaredwolff. Modify it as you see fit!

Select a location to save it.

Next find your Info.plist.

Update info.plist by adding Privacy - Bluetooth Peripheral Usage Description

The description I ended up using was App uses Bluetooth to connect to the Particle Xenon RGB Example

This allows you to use Bluetooth in your app if you ever want to release it.

Now, let's get everything minimally functional!

Minimally functional

Next, we'll get a minimally functional app to connect and do a services discovery. Most of the action will happen in the ViewController.swift.

Lets first import CoreBluetooth

    import CoreBluetooth

This allows us to control the Bluetooth Low Energy functionality in iOS. Then let's add both the CBPeripheralDelegate and CBCentralManagerDelegate to the ViewController class.

    class ViewController: UIViewController, CBPeripheralDelegate, CBCentralManagerDelegate {

Let's now create local private variables to store the actual central manager and peripheral. We'll set them up further momentarily.

    // Properties
    private var centralManager: CBCentralManager!
    private var peripheral: CBPeripheral!

In your viewDidLoad function, let's init the centralManager

    centralManager = CBCentralManager(delegate: self, queue: nil)

Setting delegate: self is important. Otherwise the central state never changes on startup.

Before we get further, let's create a separate file and call it ParticlePeripheral.swift. It can be placed anywhere but I placed it in a separate 'group' called Models for later.

Inside we'll create some public variables which contain the UUIDs for our Particle Board. They should look familiar!

    import UIKit
    import CoreBluetooth

    class ParticlePeripheral: NSObject {

        /// MARK: - Particle LED services and charcteristics Identifiers

        public static let particleLEDServiceUUID     = CBUUID.init(string: "b4250400-fb4b-4746-b2b0-93f0e61122c6")
        public static let redLEDCharacteristicUUID   = CBUUID.init(string: "b4250401-fb4b-4746-b2b0-93f0e61122c6")
        public static let greenLEDCharacteristicUUID = CBUUID.init(string: "b4250402-fb4b-4746-b2b0-93f0e61122c6")
        public static let blueLEDCharacteristicUUID  = CBUUID.init(string: "b4250403-fb4b-4746-b2b0-93f0e61122c6")

    }

Back in ViewController.swift let's piece together the Bluetooth bits.

Bluetooth bits

Everything to do with Bluetooth is event based. We'll be defining several functions that handle these events. Here are the important ones:

centralManagerDidUpdateState updates when the Bluetooth Peripheral is switched on or off. It will fire when an app first starts so you know the state of Bluetooth. We also start scanning here.

The centralManager didDiscover event occurs when you receive scan results. We'll use this to start a connection.

The centralManager didConnect event fires once the device is connected. We'll start the device discovery here. Note: Device discovery is the way we determine what services and characteristics are available. This is a good way to confirm what type of device we're connected to.

The peripheral didDiscoverServices event first once all the services have been discovered. Notice that we've switched from centralManager to peripheral now that we're connected. We'll start the characteristic discovery here. We'll be using the RGB service UUID as the target.

The peripheral didDiscoverCharacteristicsFor event will provide all the characteristics using the provided service UUID. This is the last step in the chain of doing a full device discovery. It's hairy but it only has to be done once during the connection phase!

Defining all the Bluetooth functions.

Now that we know what the functions events that get triggered. We'll define them in the logical order that they happen during a connection cycle.

First, we'll define centralManagerDidUpdateState to start scanning for a device with our Particle RGB LED Service. If Bluetooth is not enabled, it will not do anything.

    // If we're powered on, start scanning
        func centralManagerDidUpdateState(_ central: CBCentralManager) {
            print("Central state update")
            if central.state != .poweredOn {
                print("Central is not powered on")
            } else {
                print("Central scanning for", ParticlePeripheral.particleLEDServiceUUID);
                centralManager.scanForPeripherals(withServices: [ParticlePeripheral.particleLEDServiceUUID],
                                                  options: [CBCentralManagerScanOptionAllowDuplicatesKey : true])
            }
        }

Defining the centralManager didDiscover is our next step in the process. We know we've found a device if this event has occurred.

    // Handles the result of the scan
        func centralManager(_ central: CBCentralManager, didDiscover peripheral: CBPeripheral, advertisementData: [String : Any], rssi RSSI: NSNumber) {

            // We've found it so stop scan
            self.centralManager.stopScan()

            // Copy the peripheral instance
            self.peripheral = peripheral
            self.peripheral.delegate = self

            // Connect!
            self.centralManager.connect(self.peripheral, options: nil)

        }

So, we stop scanning using self.centralManager.stopScan(). We set the peripheral so it persists through the app. Then we connect to that device using self.centralManager.connect

Once connected, we need to double check if we're working with the right device.

    // The handler if we do connect succesfully
        func centralManager(_ central: CBCentralManager, didConnect peripheral: CBPeripheral) {
            if peripheral == self.peripheral {
                print("Connected to your Particle Board")
                peripheral.discoverServices([ParticlePeripheral.particleLEDServiceUUID])
            }
        }

By comparing the two peripherals we'll know its the device we found earlier. We'll kick off a services discovery using peripheral.discoverService. We can use ParticlePeripheral.particleLEDServiceUUID as a parameter. That way we don't pick up any services we don't care about.

Once we finish the discovering services, we'll get a didDiscoverServices event. We iterate through all the "available" services. (Though there will only be one!)

    // Handles discovery event
        func peripheral(_ peripheral: CBPeripheral, didDiscoverServices error: Error?) {
            if let services = peripheral.services {
                for service in services {
                    if service.uuid == ParticlePeripheral.particleLEDServiceUUID {
                        print("LED service found")
                        //Now kick off discovery of characteristics
                        peripheral.discoverCharacteristics([ParticlePeripheral.redLEDCharacteristicUUID,
                                                                 ParticlePeripheral.greenLEDCharacteristicUUID,
                                                                 ParticlePeripheral.blueLEDCharacteristicUUID], for: service)
                        return
                    }
                }
            }
        }

By this point this is the third time we're checking to make sure we have the correct service. This becomes more handy later when there are many characteristics and many services.

We call peripheral.discoverCharacteristics with an array of UUIDs for the characteristics we're looking for. They're all the UUIDs that we defined in ParticlePeripheral.swift.

Finally, we handle the didDiscoverCharacteriscsFor event. We iterate through all the available characteristics. As we iterate we compare with the ones we're looking for.

    // Handling discovery of characteristics
        func peripheral(_ peripheral: CBPeripheral, didDiscoverCharacteristicsFor service: CBService, error: Error?) {
            if let characteristics = service.characteristics {
                for characteristic in characteristics {
                    if characteristic.uuid == ParticlePeripheral.redLEDCharacteristicUUID {
                        print("Red LED characteristic found")
                    } else if characteristic.uuid == ParticlePeripheral.greenLEDCharacteristicUUID {
                        print("Green LED characteristic found")
                    } else if characteristic.uuid == ParticlePeripheral.blueLEDCharacteristicUUID {
                        print("Blue LED characteristic found");
                    }
                }
            }
        }

At this point we're ready to do a full device discovery of our Particle Mesh device. In the next section we'll test what we have to make sure things are working ok.

Testing our minimal example

Before we get started, if you run into trouble I've put some troubleshooting steps in the footnotes.

To test, you'll have to have an iPhone with Bluetooth Low Energy. Most modern iPhones have it. The last iPhone not to have it I believe was either the iPhone 4 or 3Gs. (so you're likely good)

First, plug it into your computer.

Go to the top by the play and stop buttons. Select your target device. In my case I chose my phone (Jared's iPhone). You can also use an iPad.

Then you can hit Command + R or hit that Play button to load the app to your phone.

Make sure you have your log tab open. Enable it by clicking the bottom pane button in the top right corner.

Make sure you have a mesh device setup and running the example code. You can go to this post to get it. Remember your Particle Mesh board needs to be running device OS 1.3.0 or greater for Bluetooth to work!

Once both the firmware and app is loaded, let's check the log output.

It should look something like this:

View loaded
Central state update
Central scanning for B4250400-FB4B-4746-B2B0-93F0E61122C6
Connected to your Particle Board
LED service found
Red LED characteristic found
Green LED characteristic found
Blue LED characteristic found

This means that your Phone has connected, found the LED service! The characteristics also being discovered is important here. Without those we wouldn't be able to send data to the mesh device.

Next step is to create some sliders so we can update the RGB values on the fly.

Slide to the left. Slide to the right.

Next we're going to add some elements to our Main.storyboard. Open Main.storyboard and click on the View underneath View Controller.

Then click on the Library button. (It looks like the old art Apple used for the home button)

You'll get a pop-up with all the choices that you can insert into your app.

Drag three Labels and copy three Sliders to your view.

You can double click on the labels and rename them as you go.

If you click and hold, some handy alignment tools will popup. They'll even snap to center!

You can also select them all and move them together. We'll align them vertically and horizontally.

In order for them to stay in the middle, let's remove the autoresizing property. Click the Ruler icon on the top right. Then click each of the red bars. This will ensure that your labels and sliders stay on the screen!

Next let's click the Show Assistant Editor button. (Looks like a Venn diagram)

Note: make sure that ViewController.swift is open in your Assistant Editor.

Then underneath the /properties section, Control-click and drag the Red Slider into your code.

Repeat with all the other ones. Make sure you name them something different. Your code should look like this when you're done:

        // Properties
        private var centralManager: CBCentralManager!
        private var peripheral: CBPeripheral!

        // Sliders
        @IBOutlet weak var redSlider: UISlider!
        @IBOutlet weak var greenSlider: UISlider!
        @IBOutlet weak var blueSlider: UISlider!

This allow us to access the value of the sliders.

Next, let's attach the Value Changed event to each of the sliders. Right click on the Red Slider in the folder view.

It should give you some options for events. Click and drag the Value Changed event to your code. Make sure you name it something that makes sense. I used RedSliderChanged for the Red Slider.

Repeat two more times. Your code should look like this at the end of this step:

        @IBAction func RedSliderChanged(_ sender: Any) {
        }

        @IBAction func GreenSliderChanged(_ sender: Any) {
        }

        @IBAction func BlueSliderChanged(_ sender: Any) {
        }

I've also selected each of the sliders to and un-checked Enabled. That way you can't move them. We'll enable them later on in code.

Also, this is a great time to change the maximum value to 255. Also set the default value from 0.5 to 0.

Back at the top of the file. Let's create some local variables for each of the characteristics. We'll use these so we can write the slider variables to the Particle Mesh board.

        // Characteristics
        private var redChar: CBCharacteristic?
        private var greenChar: CBCharacteristic?
        private var blueChar: CBCharacteristic?

Now, let's tie everything together!

In the didDiscoverCharacteristicsFor callback function. Let's assign those characteristics. For example

    if characteristic.uuid == ParticlePeripheral.redLEDCharacteristicUUID {
        print("Red LED characteristic found")
        redChar = characteristic

As we find each characteristic, we can also enable each of the sliders in the same spot.

            // Unmask red slider
            redSlider.isEnabled = true

In the end your didDiscoverCharacteristicsFor should look like:

    // Handling discovery of characteristics
        func peripheral(_ peripheral: CBPeripheral, didDiscoverCharacteristicsFor service: CBService, error: Error?) {
            if let characteristics = service.characteristics {
                for characteristic in characteristics {
                    if characteristic.uuid == ParticlePeripheral.redLEDCharacteristicUUID {
                        print("Red LED characteristic found")

                        redChar = characteristic
                        redSlider.isEnabled = true
                    } else if characteristic.uuid == ParticlePeripheral.greenLEDCharacteristicUUID {
                        print("Green LED characteristic found")

                        greenChar = characteristic
                        greenSlider.isEnabled = true
                    } else if characteristic.uuid == ParticlePeripheral.blueLEDCharacteristicUUID {
                        print("Blue LED characteristic found");

                        blueChar = characteristic
                        blueSlider.isEnabled = true
                    }
                }
            }
        }

Now, let's update the RedSliderChanged GreenSliderChanged and BlueSliderChanged functions. What we want to do here is update the characteristic associated with the Changed function. I created a separate function called writeLEDValueToChar. We'll pass in the characteristic and the data.

    private func writeLEDValueToChar( withCharacteristic characteristic: CBCharacteristic, withValue value: Data) {

            // Check if it has the write property
            if characteristic.properties.contains(.writeWithoutResponse) && peripheral != nil {

                peripheral.writeValue(value, for: characteristic, type: .withoutResponse)

            }

        }

Now add a call to writeLEDValueToChar to each of the Changed functions. You will have to cast the value to a Uint8. (The Particle Mesh device expects an unsigned 8-bit number.)

            @IBAction func RedSliderChanged(_ sender: Any) {
            print("red:",redSlider.value);
            let slider:UInt8 = UInt8(redSlider.value)
            writeLEDValueToChar( withCharacteristic: redChar!, withValue: Data([slider]))

        }

Repeat this for GreenSliderChanged and BlueSliderChanged. Make sure you changed red to green and blue for each!

Finally, to keep things clean, i've also added a function that handles Bluetooth disconnects.

    func centralManager(_ central: CBCentralManager, didDisconnectPeripheral peripheral: CBPeripheral, error: Error?) {

Inside, we should reset the state of the sliders to 0 and disable them.

            if peripheral == self.peripheral {
                print("Disconnected")

                redSlider.isEnabled = false
                greenSlider.isEnabled = false
                blueSlider.isEnabled = false

                redSlider.value = 0
                greenSlider.value = 0
                blueSlider.value = 0

It's a good idea to reset self.peripheral to nil that way we're not ever trying to write to a phantom device.

                self.peripheral = nil

Finally, because we've disconnected, start scanning again!

                // Start scanning again
                print("Central scanning for", ParticlePeripheral.particleLEDServiceUUID);
                centralManager.scanForPeripherals(withServices: [ParticlePeripheral.particleLEDServiceUUID],
                                                  options: [CBCentralManagerScanOptionAllowDuplicatesKey : true])
            }

Alright! We just about ready to test. Let's move on to the next (and final) step.

Test the sliders.

The hard work is done. Now it's time to play!

The easiest way to test everything is to click the Play button in the top left or the Command + R keyboard shortcut. Xcode will load the app to your phone. You should see a white screen proceeded by a screen with your sliders!

The sliders should stay greyed out until connected to your Particle Mesh board. You can check your log output if the connection has been established.

View loaded
Central state update
Central scanning for B4250400-FB4B-4746-B2B0-93F0E61122C6
Connected to your Particle Board
LED service found
Red LED characteristic found
Green LED characteristic found
Blue LED characteristic found

(Look familiar? We're connected!)

If you followed everything perfectly, you should be able to move the sliders. Better yet, the RGB LED on the Particle Mesh board should change color.

Conclusion

In this article you've learned how to connect your Particle Mesh board and iOS device over Bluetooth. We've learned how to connect to each of the available characteristics. Plus, on top of it all, make a clean interface to do it all in.

As you can imagine, you can go down the rabbit hole with Bluetooth on iOS. There's more coming in my upcoming guide: The Ultimate Guide to Particle Mesh. Subscribers to my list get access to pre-launch content and a discount when it comes out! Click here to get signed up.

Code

The full source code is available on Github. If you find it useful, hit the star button. ⭐️

IBM’s $34B acquisition of Red Hat closed last week, underscoring the huge and growing importance of hybrid cloud infrastructure. My colleague Marek Sadowski has become a subject matter expert in containers, Kubernetes and server-side Swift, although he started out as a full stack developer advocate, a robotics startup founder and an entrepreneur.

Marek has 20 years of enterprise consulting experience throughout the USA, Europe, Japan, Middle East and Africa, and he pioneered in research on VR goggles for the virtual reality system to control robots on Mars during his time at NASA. After founding a robotics startup, Marek came to work at IBM. I talked to him about his experience in DevOps advocacy.

Table of Contents

• How DevOps advocacy different from API/app advocacy?
• How do you focus on the DevRel community?
• What have you changed when moving to DevOps DevRel?
• How do you get developers to see Swift as server-side?
• How did you get into DevRel?

Q: One of your focus areas in DevRel is containers. How is advocating for a DevOps technology different than advocating for an API or application?

Good question. When working with containers, engineers think more in terms of the plumbing and ideas of DevOps and the ease of expanding your infrastructure footprint. In contrast, when you talk about APIs, you try to make application development the center of gravity for the discussion.

When discussing APIs with developers, you talk about how one could -- in a robust way -- consume the API. Let’s take the IBM Watson API as an example: our team will talk about how you can create and run SDKs for developers to consume APIs in their own language, for example, Swift (for mobile) or Java (for enterprise.) You’d look at the consumer of your API and discuss how you can produce the API, protect yourself and do the billing.

Getting back to containers: when discussing container technology, you speak more about plumbing of the cloud. How do you manage containers? Expand them? Manage their workloads? Deliver and test new versions?

It quickly becomes apparent that these are two separate concepts. Containerization deals with how your backend is working and proper maintenance of your application, which attracts people from a DevOps background. When you talk about APIs, that’s a completely different story. Your thought paradigm changes to the point of view of the consumer: How does the consumer find the API? How can developers consume the API?

I speak at conferences on both subjects areas. I’ve found that people who develop applications are more interested in the look and feel and developer experience of the application, whereas with containers it’s more about backend, load balancing, and seeing issues from a system administrator’s perspective.

Q: Many people are familiar with DevRel with a focus on software engineers, but DevOps is a different community entirely. How do you focus on that community?

There is a division — everybody is interested in new things like Kubernetes and Docker, but not too many will want to perfect their skills to the point that it’s their daily job. So many developers want to know how to spin up a container and a service inside the container, put it in their resume and be done with it. Developers may be interested because it’s fashionable or it’s a buzzword. However, you can find a lot of people who are running services in containers and have specific questions: sysadmins who want to monitor containers and assure security, load balancing, and other aspects of administration. It’s a completely different audience from developers who consume APIs and create a cool web application. They are two different communities, and you have to give each community different content.

For example, in a hackathon it’s very difficult to create large deployments in containers. It’s an optimization of development and operations more than application coding.

Q: How have you had to change your approach to DevRel when moving to DevOps advocacy?

Previously when I ran workshops focused on application developers, they’ll usually have a few goals: understand our API, consume data from API endpoints and create a simple “Hello World” types of applications. Developers in these workshops will ask questions about high-level ways of architecting applications, e.g. with Watson, in mobile applications or web applications, or a chain of processes.

On the contrary, when I speak about DevOps and containers, developers in the audience want to spin up the services, see how they scale up and scale down, investigate how the services behaving when something is failing and how to ameliorate security issues. It’s a completely different approach. They are not interested in building something new, they want to perfect their approach to deployment.

An analogy I can give to people new to this field: it’s like inviting a painter and a plumber to a party. They both do similar things, yet the painter wants to make a painting that you can hang on the wall, and the plumber will rarely speak about the type of piping he’s using inside your walls. Both are doing something in your house, but the painter is thinking about the people they will attract and the paint (our APIs) to ensure a pleasant viewing experience, while the plumber just wants to get the job done and never touch it again. The plumbers want to make changes as rarely as possible and focus on stability, the painter wants to create more new paintings. They have different approaches based on their different goals.

Q: You also give talks on Swift, specifically on the server side. Most people know Swift from the iOS development side, but why is it useful on the server? How do you get developers to think of it as a server language?

Server-side Swift is a relatively new development. I compare the current state of server-side Swift to where Java was twenty-four years ago. In 1996 I started writing a server-side application using Java -- it was a novel concept at that time! The same thing is happening now with Swift, as developers are moving the Swift language to the server. There are a lot of reasons why; one of the simplest is that you write in the same language on the server as you do for your mobile app, and in that way you can use the same data constructs, thought processes and personnel resources on both systems. You don’t need different systems or frameworks to talk to the database or the cloud.

Every mobile app nowadays asks you to connect to the internet for AI, messaging and social media. Even simple games allow you to exchange information or have a conversation with people all over the world. If your app and back-end are written in one language like Swift, it makes these data exchanges simple and transparent.

Some people are saying Swift is a fashionable language to learn. Since you have the option to write apps in Java or JavaScript, you can also write them in Swift. Swift has now been open-sourced by Apple, similar to the way Sun opened up Java. You can now write applications in the cloud or on any platform. For example, OpenWhisk allows you to write event-based Swift functions in the cloud without any DevOps code.

With Swift, developers are attracted to the beauty of the language and the ability to write one language from mobile to cloud to make your application better and easier to maintain. You can enjoy writing in your language of choice and expand the capabilities of the environment you love. If you are an iOS developer, maybe you can become a full-stack developer, and developers love the story that they can become something more and participate in the full stack development process.

Q: How did you get into developer relations?

I had just come to the United States from Poland as the founder of a startup, and the purpose of the move was to expand my company. They say that 99% of startups don’t succeed right away, and founders often need to bootstrap while in an existing job. I was told that working in the cloud is the key factor in a lot of industries, but I had little exposure to those technologies. On the other hand, I had built up skills talking to investors, and as an entrepreneur, I was able to understand what was important to startups. I also had a robust background in Java development and different IT technologies — I had a career as an architect supporting banks and other enterprises EMEA as a Java professional, demonstrating systems to customers.

There was an opening for a mobile-first developer advocate, and despite having no mobile or cloud experience, I convinced the interviewer that I was the perfect candidate due to my ease of speaking with developers and presenting technical subjects in an accessible manner. I enjoy explaining complex topics in a simple way through demos and example projects.

My hiring manager asked me to build a small mobile app as an employment test, which connected to IBM Cloud to exchange information between the user and a backend. I enjoyed the task and found I was good at it! After two years, I migrated to more cloud technologies and more and more IBM APIs. Eventually I started to find interest in Kubernetes and containers, and I realized containers are a field with amazing growth potential.

I must say, the thing that attracted me the most to DevRel was the opportunity to learn and convey new technologies to developers out there, and use my talent for explaining complex things in a straightforward manner.

Next Steps:

• Follow Marek on Twitter
• See Marek speak at an upcoming IBM Developer SF Meetup

Today we have something for you, iOS developers! Whether you are riding your Swift knowledge outside of iOS or keeping things steady with some battle-hardened Objective-C, there’s a community of developers just like you on Gitter. And, if you’re looking to get up to speed or to help the next generation, then there are plenty of learning resources to get involved with as well.

• PerfectlySoft/Perfect — Perfect is an application server which provides a framework for developing web and other REST services in the Swift programming language. The Perfect library, server, connectors and example apps.
• PromiseKit — Promises is a thoughtful and complete implementation of promises for iOS and OS X with first-class support for both Objective-C and Swift.
• IBM-Swift/Kitura — Kitura is a web framework and web server that is created for web services written in Swift.
• CocoaPods — CocoaPods manages dependencies for your Xcode projects.
• Appium — Appium is an open source, cross-platform test automation tool for native, hybrid and mobile web apps, tested on simulators (iOS, FirefoxOS), emulators (Android), and real devices (iOS, Android, FirefoxOS).
• BEMSimpleLineGraph — iOS library to create simple line graphs/charts (charting library).
• Ankurp/Dollar — A functional tool-belt for Swift Language similar to Lo-Dash or Underscore.js in Javascript
• Alcatraz — Open-source package manager for Xcode 5+. It lets you discover and install plugins, templates and color schemes without the need for manually cloning or copying files.
• Grunt-xcode — Build and export Xcode projects with Grunt
• Zero-push — ZeroPush is a simple service for sending Apple Push Notifications. This library wraps the API requests for use in NodeJS.
• Codefellows/sea-c24-iOS-F2 — Official repository for the iOS Foundations II course.
• mixi-inc/iOSTraining — Training course repository for iOS app development.

Are you looking for something else? Check out our Explore section or easily start your own channel here.

Did we miss an channel that you think should be featured? Drop us a line in the Gitter HQ and we will add it to the list.

Happy coding!