DEV Community: Matheus Cardoso

iOS Passwordless Chat Application with Auth0

Matheus Cardoso — Tue, 01 Jun 2021 15:16:31 +0000

Almost every application needs an authentication strategy. The most common being the classic username and password combo. However, there's a new approach some apps are taking to avoid handling or storing user passwords: passwordless authentication. It generally involves sending a one-time PIN (OTP) through a user-owned channel such as their phone or email. If the user inputs the correct PIN, we give them access to the system.

In this article, we'll build an iOS chat application with Stream Chat, for its fully featured iOS chat components and Auth0's passwordless features for authentication.

You can see the final result in the screenshot below and download the complete source code in the Passwordless Chat App iOS GitHub repository. Let's dive in!

Requirements

To follow this tutorial, create an account with Stream, Auth0, and Ngrok. You'll also need Xcode, NodeJS, and Ngrok installed.

Stream takes care of the chat features, Auth0 provides the passwordless authentication we need, and Ngrok lets us quickly expose our local NodeJS backend to the external world via HTTPS.

A Stream account account
An Auth0 account
An Ngrok account
Node v14 installed
Ngrok installed
Xcode 12 or later

Auth0's free plan includes the passwordless feature, and if you're an independent developer or with a small team, you may be eligible for Stream's free maker account. So, remember to sign up for it!

Create iOS Project

Since we'll need some details of the iOS project to configure the Auth0 dashboard, let's first create a UIKit project on Xcode with the UIKit App Delegate lifecycle.

Configure Auth0 Account

Before we can dive into the code, let's visit our Auth0 account to enable passwordless authentication and get the credentials we need.

After you've created your Auth0 account and you're in the dashboard, go to Authentication > Passwordless and enable "Email". Also, make sure to set the Default App’s switch to “on” for passwordless authentication in the Applications tab. You can also use SMS if you have a Twilio account.

After you've enabled Email authentication, go to your Default App in Applications and copy your Domain and Client ID. We'll need these later in the iOS code section.

After that, scroll a bit down to Application Properties and change your application type to Native.

Once that's done, scroll further down to Advanced Settings > Device Settings and paste your Team ID (DEVELOPMENT_TEAM) and App ID (PRODUCT_BUNDLE_IDENTIFIER), which you can find in your Xcode .pbxproj file, which is contained within the .xcodeproj file. To reveal the .pbxproj file, right click the .xcodeproj file and select Show Package Contents.

Next, move to the Grant Types tab, enable Passwordless OTP, and hit save.

After that, move to the Certificates tab, download your PEM certificate, name it public.pem, and place it in the same folder as your backend's index.js. You will use this certificate to verify the authentication request in your backend.

Create Backend Project

The backend consists of a single endpoint that generates a Stream JWT for a given user id. When the iOS app makes this request, it must also include an Auth0 ID Token to be verified. If the verification fails, we return 401 (Unauthorized) instead of the token. If it succeeds, we produce the Stream token, thus providing our user access to the chat feature under the given user id.

Install the dependencies with npm install express stream-chat jsonwebtoken --save or yarn add express stream-chat jsonwebtoken, then run your backend with node index.js.

Using Ngrok

To access this endpoint outside our local machine and serve it under HTTPS (ideal for iOS apps), we can use Ngrok. You can install Ngrok through homebrew by running the command brew install ngrok, or visit the Ngrok website. You'll also need an account and the auth token set up.

After you have Ngrok and your account set up, run ngrok http 3000. If your backend is running on a different port than 3000, make sure to use that number instead. After you run the command, you should copy the https URL. You'll need it in the next section.

iOS Dependencies

Add the following dependencies to your iOS project.

You can install the dependencies with Xcode's built-in Swift Package Manager integration or CocoaPods.

iOS Code

First, we need code to ask our backend for the JWT. You can write a stand-alone function that does it like below. Remember to replace the Ngrok URL. You can paste the function anywhere you want. For example, you can create a fetchStreamJWT.swift file and paste it there.

After that, we also need a function that creates our Chat's UI stack. After reading Stream Chat's iOS Tutorial, we can quickly write a stand-alone function that sets up our UI. As with the last function, you can create a makeChat.swift file and paste it there.

In the ViewController.swift file, we'll use Auth0's Lock.swift SDK to show the authentication UI. Once the user inputs the OTP, the onAuth callback is triggered, giving us the Auth0 ID token. We then call fetchStreamJWT to hit our endpoint and makeChat to display our chat UI.

Testing Your App

If everything is right and your backend is running, you should be able to run your project in a device or simulator. Type in your email, and you'll receive a code. After typing the code correctly and pressing submit, it will take you to the chat screen.

Next Steps with the Passwordless Chat App

Congratulations! You've built the basis of a functioning passwordless chat app with Stream Chat and Auth0. I encourage you to browse through Stream Chat's docs, Auth0's iOS passwordless docs, and experiment with the project you just built. Good luck on your app development!

Generate JWTs with Swift on AWS Lambda

Matheus Cardoso — Fri, 12 Mar 2021 13:07:48 +0000

Authorization is one of the essential parts of any iOS application. Once a user is logged in, it's your authorization scheme that will make sure users can't interact with your app in ways they're not allowed to. Without a robust authorization scheme, hackers could easily access sensitive user data and engage in other damaging activities such as scamming.

Thankfully, the widespread use and standardization of JWT (JSON Web Tokens) have made robust and cryptographically secure authorization more straightforward to achieve.

In this article, we'll use Stream Chat as an example service to authorize our users for using Swift Lambda to generate JWTs. You can then use the JWT for interacting with the Stream Chat service via the REST API or by configuring the iOS Chat SDK.

What is JSON Web Token?

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.

Introduction to JSON Web Tokens

How does it work?

After authenticating with a login and password or another method, the user receives a JWT. After authentication, the user will attach this JWT to every request as a way of proving their identity and permission to access a particular resource. This JWT was signed by your server during authentication using a secret key and is verified in subsequent requests.

Set Up Swift Lambda

Since JWTs should be generated and verified server-side, we can set up an AWS Lambda written in Swift to do that job. You can choose an alternative method and language, but the next steps will be different. By the end, we'll have an HTTP endpoint that outputs a JWT for a specific user id to access Stream's chat service.

Install Kitura's Swift-JWT

To generate a JWT, we'll use Kitura's Swift-JWT package, which takes care of the heavy lifting of building a JWT.

To install it, open your Swift Lambda's Package.swift in its root folder and add .package(name: "SwiftJWT", url: "https://github.com/Kitura/Swift-JWT.git", from: "3.6.2") to the package's dependency list. Also, add "SwiftJWT" to the Lambda target's dependency list. By the end, your Package.swift will look similar to the one below.

Install OpenSSL

Swift-JWT depends on the OpenSSL library to perform cryptographic operations. To install it, add RUN yum -y install openssl-devel to your Swift Lambda's Dockerfile which can be found in its root folder. The Dockerfile should look similar to the one below.

Configure Endpoint

Finally, we'll need our endpoint to accept POST requests, since we'll send credentials in the request body. To do that, change the Swift Lambda's serverless.yml line from method: get to method: post. It will look similar to the snippet below.

Parse Request

After you're done configuring your Swift Lambda, we can start writing code in Sources/Lambda/main.swift. The code we need will parse a POST request and extract the user_id field from its JSON body. After that, it will generate a JWT for that user id and return it.

We'll implement the generateJWT(for userId: String) function in the next steps.

Sign Up to Stream

Before we can generate a JWT, we need a secret to sign it. You can get one by signing up to Stream or by accessing the dashboard.

Generate JWT

To generate a JWT, we'll use SwiftJWT. First, we need to declare a struct conforming to the Claims protocol with a user_id property of type String. That's the only claim required by Stream. After that, we create a JWT object with the user_id claim and sign it using your Stream secret.

Note: Before you generate a JWT, it's essential to verify the request with some form of authentication such as a password and return 401 Unauthorized if it's wrong.

Deploy

The main advantage of using Swift Lambda is that it's possible to iterate fast with it. After writing the JWT code, just run the ./Scripts/deploy.sh script again and wait a few seconds.

Test the Endpoint

To test the endpoint and get a JWT, you can use the following curl command in your terminal. Don't forget to replace the URL with the one you got in the deploy step and change the user id if you want to.

After running that command, you should get a valid JWT. If it has a % at the end, ignore it.

Conclusion

Congratulations! You've generated a valid JWT for interacting with the Stream Chat service via the REST API or by configuring the iOS Chat SDK. This logic can be adapted to work with other JWT-based services such as Auth0 and Dolby.io. To find out what else you can build with Swift on AWS Lambda, check out the Swift Lambda repository on GitHub.

Swift WebSockets: Starscream or URLSession in 2021?

Matheus Cardoso — Tue, 02 Mar 2021 17:37:43 +0000

Building applications such as online games and real-time chat has never been easier since the standardisation of the WebSocket protocol in 2011. Before that, most app experiences were plagued with manual refreshes in order to access the latest data available (remember F5?). Since then, most apps use WebSockets in some form to update their user interface with new data as soon as it is generated.

For Swift programmers targeting iOS, macOS, and other Apple platforms in 2021, there are two main libraries that can be used to connect to a WebSocket server: Starscream and URLSession. While both are capable libraries, they also have advantages and disadvantages which are important to consider before choosing one over the other.

In this article, we'll go over several positive and negative characteristics of Starscream and URLSession to help you decide which fits best with your requirements. Let's dig in!

What is the WebSocket Protocol

The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or s and long polling).

RFC 6455 - The WebSocket Protocol

Starscream

Image from https://github.com/daltoniam/Starscream

Starscream is a conforming WebSocket (RFC 6455) library written in Swift targeting the iOS and macOS systems. Years before Apple's URLSession even supported WebSockets, Starscream was the Swift library of choice. For reasons we'll go over shortly, it is the library we use at Stream for building our iOS Chat SDK.

Pros

Legacy support

Starscream will compile for iOS 8+ (7+ with some tweaks) and macOS 10.10+. If supporting devices with old operating systems is a requirement, you have almost no choice but to go with this library. This is the one of the main reasons we chose to go with Starscream for the Stream Chat iOS SDK which supports iOS 11 onwards.

Battle tested

Starscream has been around for a long time. It's been tested by thousands of apps and improved upon for years. It presents a reliability that may be currently unmatched among WebSocket libraries. This is another important point in our decision to stick with Starscream and it will be obvious (spoiler alert) when we talk about URLSession's reliability issues for WebSockets.

Open-Source

Starscream is fully open-source up to its usage of CFNetwork calls, so it's possible to make changes if you need. It's also possible to use URLSession underneath for supported systems, but that's not enabled by default.

PS: Technically, CFNetwork and URLSession are open-source, but you're not meant to compile your own version of them for production use in Apple platforms so it doesn't count, right?

Cons

Binary Size

Since Starscream is not shipped with Apple's operating systems, including it in your project will cause an increase in your binary size of about 500kb which is not terrible for regular apps, but could be a real issue for size-restrictive targets such as the new App Clips.

Maintenance

Since the release of URLSession support for WebSockets in 2019, the Starscream repository has seen a steady decrease in activity with many unanswered issues and pull requests, with the last commit merged in August 2020. This is a sign that if you run into bugs or need a new feature it could be a dead end unless you handle it yourself.

URLSession

URLSession is Apple's own high-level networking library for HTTP(S) requests. To be more precise, URLSession is really a class that's part of the Foundation library. It coordinates a group of related, network data-transfer tasks, and, as of iOS 13 and macOS 10.15, it supports WebSockets as one of those tasks (URLSessionWebSocketTask).

Pros

Binary size

Using URLSession in your app will not cause any noticeable increase in your final binary size since it's included in the system's Foundation library. When you need to optimize for size, such as when building an App Clip, then URLSession is your library of choice!

Maintained By Apple

URLSession is maintained by Apple and should receive regular updates for the foreseeable future, though they can only be taken advantage by installing new operating system patches. You can also ask for support directly from Apple if you are enrolled in their paid developer program.

Cons

No Legacy Support

URLSession only received WebSockets support in 2019 when iOS 13 and macOS 10.15 were released. As such, using it for Web Sockets will restrict your app to those versions and up.

Closed-Source

URLSession is closed-source, so it's not possible to make any changes to the underlying implementation in case you need them. Again, using a looser definition of close-source, since technically you can get the source code on GitHub, but it's not viable to compile your own version of it.

Unreliability & Crashes

It's expected that a function developed not long ago still presents rough edges. If you search the web for "URLSessionWebSocketTask crash" or "URLSessionWebSocketTask bug", you'll find many instances on StackOverflow and even Apple's forums of developers reporting crashes and other issues.

Which You Should Choose

Given URLSession has implemented support for WebSockets relatively recently, it's not currently as reliable as Starscream which existed for years prior. Many projects that migrated from Starscream to URLSession reported mysterious bugs and crashes. This alone gives Starscream the top spot among Swift WebSocket libraries. But keep on reading, there are other things to consider.

When Apple fixes the reliability issues, the most defining point in choosing these libraries is going to be about legacy support. If your app needs to support system versions lower than iOS 13 / macOS 10.15, your best bet will be to use Starscream. If your app only supports those versions and up, it will be better to take advantage of the native URLSession framework and Apple's extended support of it.

For App Clips, URLSession is currently preferred due to Starscream's 500kb binary size impact. With just a little bit of luck, you might escape its reliability issues.

Singleton vs Dependency Injection in Swift

Matheus Cardoso — Tue, 16 Feb 2021 14:03:04 +0000

When coding iOS apps, we often create classes that manage a particular aspect of the application. For example, it's common to develop "manager" classes that encapsulate methods for interacting with a specific application aspect. These aspects commonly include the REST API, WebSockets, database, caching, notifications, chat, etc. That is what's called the Facade pattern, and it's a prevalent way to organize code.

During the creation of a "manager" class, one of the first thoughts is: "How do I access these methods from somewhere else in my app's code, such as inside a view controller?". There are two common ways to go about this: the Singleton and Dependency Injection patterns.

This article will compare the Singleton and Dependency Injection patterns to help you decide which one is best for your use case. For context, we'll use Stream Chat's iOS SDK, which supports both patterns.

Singleton

Image from https://refactoring.guru/design-patterns/singleton

The Singleton pattern is known for its simplicity. It consists of a Facade class with a public static instance, often called shared, accessible throughout the app's code via MyFacade.shared. Generally, the Facade's class initializer is made private, so the shared instance is the only one in the app.

Check out the snippet below to create a shared instance for Stream Chat's ChatClient class by extending it with the shared static property.

Pros

The main advantage of the singleton pattern is its ease of access. Wherever you need the shared instance, you can access it without modifying your code further.

It's also possible to enforce a single instance if you make the Facade class's initializer private. That is a simple way to avoid common conflicts such as concurrent writes to a database.

Cons

The disadvantages of the singleton pattern become apparent the more complex your app gets. The more places in your app access the shared instance, the more unpredictable your app's behavior becomes and the harder it is to keep all your code in sync with the singleton's global state. Though it can be handy for more uncomplicated use cases, it's often considered an anti-pattern by those who want to be more careful with their code and increase predictability.

It's also possible that limiting the Facade class to a single instance is not what you'll want as your app scales up, and it can be tough to undo that choice.

It's also harder to write unit tests without the possibility of instantiating a mock instance of your class. The last point is not valid for Stream Chat Swift SDK's ChatClient, since its initializer is public to support the Dependency Injection pattern, which we'll discuss next.

Dependency Injection

Image from https://stackify.com/dependency-injection/

Dependency Injection can be a great alternative to the Singleton pattern for medium to high complexity apps as it scales with your app with less risk of adding unpredictability. Instead of providing a shared instance that can be accessed without restriction throughout the app, each component or class that needs access to an instance must hold its reference via a parameter or property. This property can be assigned during instantiation or after.

Check out the snippet below to instantiate a ChatClient and a ViewController with the former going into its initializer. Alternatively, we can assign the ViewController's chatClient property after initialization. It would be best if you prefer using the initializer approach to avoid making the property public.

Pros

There are multiple advantages to the Dependency Injection pattern. Since instantiation is not limited, it's possible to create mock instances to use in unit testing. Additionally, you're not locking yourself out of using multiple instances at the same time in case it's necessary now or in the future.

An injected dependency behavior is also more predictable since its accesses are restricted to pieces of code that explicitly hold an instance to it. Hence, you get to think twice about where to access it.

Dependency Injection doesn't add a global state to your code, so it becomes more reusable. If your code component

Cons

The disadvantages of Dependency Injection are debatable, depending on your use case. For instance, to access the object, you need to add a property or parameter to hold its reference. That can break API in existing projects, if it's something important, or be an additional step in the development process.

With Dependency Injection, it's not possible to enforce a single instance in compile-time. If multiple instances of an object can cause conflicts in runtime, it's necessary to handle those potential issues.

Though not necessarily complicated, some Dependency Injection implementations do get quite robust and can be hard to grasp if you're new to the project.

Which You Should Choose

It depends. Dependency Injection is widely considered the cleaner option, but it can get tricky. Singleton is regarded as an anti-pattern by Clean Code advocates, but it's easy, and it works. Still, developers use both patterns to great success. You should choose the one that fits your current project best while avoiding its common pitfalls.

Finally, as important as choosing the right pattern, don't let your Manager/Facade class become a "god class" with too many responsibilities. Try to make it as single-purposed as possible by interacting with a single aspect of your app.

Migrate Your iOS Project From Carthage To Swift Package Manager

Matheus Cardoso — Wed, 02 Dec 2020 16:25:24 +0000

Since Swift 5 and Xcode 11 were released, SPM became a viable dependency manager for many iOS projects. It's also been heavily improved upon in Xcode 12 with the support of binary frameworks and resource files such as storyboards, nibs, localization folders, asset catalogs, and core data models. It's now possible to use it in most if not all iOS projects. And most actively maintained dependencies such as Stream Chat support it.

A Twitter poll showed that, while CocoaPods is number one at 46.5%, 11.4% of iOS developers still use Carthage as their preferred dependency manager. Swift Package Manager, though released most recently, is just behind with 42.1%.

It's clear that SPM, with all its recent updates and deep integration with the official iOS toolchain, will soon take over the other options. In this article, I'll present a process that you can use to fully migrate your projects from Carthage to Swift Package Manager. If you're also interested in migrating from CocoaPods, here's a CocoaPods version of this article: Migrate Your iOS Project From CocoaPods To Swift Package Manager.

Remove Carthage

Unlike CocoaPods, removing Carthage is an entirely manual process. You'll delete files and remove settings in your Xcode projects that reference Carthage. Most of these, you or someone on your team created manually, so what you must change can vary slightly.

Before you remove Carthage, it's important to note each dependency in your project and their versions. In my case, I was only using Stream Chat in version 2.5.0.

Now, let's remove Carthage from your project. After you took note of the contents of your Cartfile, you can remove it alongside Cartfile.resolved and the Carthage folder using the rm -rf command. In my case, I also had an Xcode 12 workaround script called carthage-build.sh that I won't be needing anymore.

Those commands removed all the Carthage-related folders and files but didn't remove the Carthage-related settings in your .xcodeproj.

Now, let's open the Xcode project and remove all frameworks in "Frameworks, Libraries, and Embedded Content" in your targets.

Your .xcodeproj likely contains an additional Build Phase for Carthage to copy the frameworks. You should remove it as well.

After you're done with these steps, you likely removed all Carthage references from your project. There could be more since the usage of Carthage can vary per project. Thank you, Carthage; you've been a good friend. 😢

Add SPM

After you've mourned the loss of Carthage, let's replace it with Swift Package Manager. Hopefully, you've taken notes of all the dependencies you had before.

Open your .xcodeproj, choose the option "Add Package Dependency" in File > Swift Packages, and paste the URL of your dependency's git repository. For example: "https://github.com/getstream/stream-chat-swift".

After pressing next, Xcode will look for the repository and automatically select the latest version tagged. If this version is compatible with the one you were using, you can press next. Otherwise, type the version you were using. After that, Xcode will download the dependency.

A repository may contain multiple targets. If that's the case, you should select only the ones you use.

After you press finish, it's done! Though, you must repeat this process for each dependency you had.

It's possible that a dependency doesn't provide a Package.swift. In that case, it can't be used with Swift Package Manager. However, you can clone the repository and add Package.swift yourself or request the maintainers to do so. For example, see the commit adding SPM support to the Stream Chat iOS SDK.

Conclusion

I hope you were successful in transitioning your project to the future. It's only getting better from now on. If you need any help converting your project from Carthage to Swift Package Manager, feel free to reach out to me on Twitter: @cardosodev.

Migrate Your iOS Project From CocoaPods To Swift Package Manager

Matheus Cardoso — Wed, 18 Nov 2020 17:41:38 +0000

As of Swift 5 and Xcode 11, Swift Package Manager supports the iOS, macOS, and tvOS build system. This support has also been greatly improved in Xcode 12 with the addition of non-source files, including asset catalogs, storyboards and nibs, core data models, and localization folders. It also supports binary frameworks. It's clear that it's now viable for most iOS projects, and many dependencies such as Stream Chat have implemented support for it.

A quick Twitter poll showed that 46.5% of iOS developers still use CocoaPods as their primary dependency manager. Swift Package Manager follows just behind with 42.1%.

It's clear that SPM, with its recent improvements and deep integration with the official iOS toolchain, will soon take over the other options. In this article, I'll present a process that you can follow to migrate your projects to Swift Package Manager fully.

Remove CocoaPods

To remove CocoaPods, you'll need the CocoaPods plugins cocoapods-deintegrate and cocoapods-clean. To install them, run sudo gem install cocoapods-deintegrate cocoapods-clean.

Before you remove CocoaPods, it's important to note each dependency in your project and their versions. In my case, I was only using Stream Chat in version 2.4.2.

Now, let's remove CocoaPods from your project. You should run the command pod deintegrate in the same folder the Podfile is in.

That command removes the Pods folder and removes the settings CocoaPods inserted in your .xcodeproj.

Now, run pod clean. That command will remove some leftover files like Podfile.lock and the .xcworkspace originally generated by CocoaPods.

It's possible that your .xcodeproj still contains a reference to the Pods folder. You can remove it by right-clicking the folder and selecting 'delete'. It will be gone instantly.

After you're done with these commands, you can put the last nail in CocoaPods's coffin with rm Podfile. Thank you, CocoaPods, you've been very useful. 😢

Add Swift Package Manager

After you've mourned the loss of CocoaPods, let's replace it with SPM. Hopefully, you've taken notes of all the dependencies you had.

Open your .xcodeproj, select the option "Add Package Dependency" in File > Swift Packages, and paste the URL of your dependency's git repository. For example: "https://github.com/getstream/stream-chat-swift".

A repository may contain multiple targets. If that's the case, you should select only the ones you use.

After you press finish, it's done! Though, you must repeat this process for each dependency you had.

Conclusion

I hope you were successful in transitioning your project to the future. It's only getting better from now on. If you need any help converting your project to Swift Package Manager, feel free to reach out to me on Twitter: @cardosodev.

How to Use an SDK Built for UIKit in Your SwiftUI App

Matheus Cardoso — Wed, 11 Nov 2020 17:31:38 +0000

SwiftUI becomes more popular as it gets more capable with each iOS release. However, it may take some time until it's a better option than UIKit to build complex user experiences such as chat and video calls. That doesn't mean you need to stick with UIKit until all the SDKs you use support SwiftUI. In this tutorial, you'll learn how easy it is to use SDKs built for UIKit in your SwiftUI app.

In this tutorial, I'll use Stream Chat's iOS SDK inside a SwiftUI app. It provides a fully-featured chat user interface in the form of a UIViewController subclass. If you're using a different SDK, the process may be similar if it provides the UI components in the form of UIKit views or view controllers.

Configuring the SDK

Typically, in UIKit, we would put any SDK initialization code inside the AppDelegate's method applicationDidFinishLaunching(_:).

If you chose to go full SwiftUI and used the SwiftUI App lifecycle, which doesn't contain an AppDelegate, the best place to configure the SDK is inside the App struct's initializer:

Wrapping a UIViewController in SwiftUI

To display the ChatViewController provided by the Stream Chat SDK, we need to wrap it in a SwiftUI view struct. To do this, create a struct that conforms to the protocol UIViewControllerRepresentable and inside the makeUIViewController function, instantiate and configure the view controller as you would in a UIKit app. Additionally, you can add properties to the SwiftUI view, as I did below with channelType and channelId.

Displaying the UIViewController

Now, you can use the SwiftUI view you created as you would any other SwiftUI view. In this case, I added it as the root view in my app's ContentView. If you added any properties to your wrapper, you need to pass them now.

Wrapping a UIView in SwiftUI

In some cases, you may want to use a single UIView. The process is similar to wrapping a UIViewController. To do it, create a struct that conforms to UIViewRepresentable and inside the makeUIView function, instantiate and configure the view as you would in a UIKit app. In this case, I'm wrapping Stream Chat's AvatarView. I also added the name property to make it customize it inside the SwiftUI view hierarchy.

Displaying the UIView

Displaying the wrapped UIView is also similar to displaying the wrapped UIViewController. Just reference it as you would any other SwiftUI view. If you also added properties, make sure to fill them out.

Next Steps with UIKit on SwiftUI

Congratulations! You now have the entire library of SDKs built for UIKit at your SwiftUI app's disposal. If you want to check out two great examples of SDKs built for UIKit that you can use in your SwiftUI apps, see Stream Chat's iOS SDK and Dolby.io's Audio and Video SDK.

End-to-End Encrypted iOS Chat with Apple's CryptoKit

Matheus Cardoso — Fri, 06 Nov 2020 18:05:34 +0000

In most cases, when building a chat app, it's essential to provide adequate privacy and security to your users. This can be done using cryptographic methods such as end-to-end encryption. End-to-end encryption is becoming a mainstream expectation, as it's featured in the biggest chat apps, such as WhatsApp and Telegram.

In this article, you'll learn how basic end-to-end encryption works in an iOS chat app using Apple's own CryptoKit framework for its secure and high-level encryption methods and Stream's flexible iOS chat SDK for its ready-made chat networking and UI components.

Please note that this tutorial is very basic and strictly educational, may contain simplifications, and rolling your own encryption protocol is not advisable. The algorithms used can contain certain 'gotchas' if not employed properly with the help of security professionals. Still, reading this article is a great start to get practical knowledge.

You can find the completed project on GitHub: encrypted-ios-chat. And if you have any questions, feel free to reach out to me on Twitter: @cardosodev :).

What Is End-to-End Encryption?

End-to-end encryption is a communication system where the only people who can read the messages are the people communicating. No eavesdropper can access the cryptographic keys needed to decrypt the conversation—not even a company that runs the messaging service.

Hacker Lexicon: What Is End-to-End Encryption

What Is Apple's CryptoKit?

CryptoKit is a new Swift framework that makes it easier and safer than ever to perform cryptographic operations, whether you simply need to compute a hash or are implementing a more advanced authentication protocol.

WWDC19: Cryptography and Your Apps

Hacker Lexicon: What Is End-to-End Encryption

What You Need

Xcode 11 or later
iOS 13 or later
A Stream account

Basic Encryption Methods

Before we get to the chat part, let's start by defining the basic encryption methods we need. We'll integrate these methods in the next section.

1. Generating a Private Key

A private key is essential to end-to-end encryption. It is used alongside a public key to generate a symmetric key which is used for encryption and decryption of data. Each user in your application has a private and public key. They share their public keys with each other so that they can generate the same symmetric key. Alice shares her public key with Bob, and Bob uses his private key and Alice's public key to generate a symmetric key. Conversely, Bob shares his public key with Alice, and Alice uses her private key with Bob's public key to generate the same symmetric key. As long as Alice's and Bob's private keys are a secret to each of them, no one can generate the same symmetric key to decrypt their conversations.

To generate a private key, we'll use the P256.KeyAgreement.PrivateKey() initializer.

Additionally, I chose the P256 algorithm for its cross-platform availability, as it is supported by the Web Crypto API in case you need a web version. Also, it's a good balance between performance and security. This preference can change with time as new algorithms become available.

PS: The public key can be extracted from the private key using privateKey.publicKey. We'll touch on this in the integration part of this article.

The private key must be saved somewhere safe. In order to do this, you may need to turn it into a string format to save it and back to perform the cryptographic operations. You can do this with the following exportPrivateKey method:

And the importPrivateKey method:

2. Deriving Symmetric Key

Once a user (message sender) has the public key of the other user it wants to communicate with (message recipient), that user can generate the symmetric key using the methods: privateKey.sharedSecretFromKeyAgreement(with: publicKey) and sharedSecret.hkdfDerivedSymmetricKey.

This process is called a Diffie-Hellman Key Exchange and ensures the symmetric key can be shared between two users without ever leaving their devices.

3. Encrypt Text

Now, we use that symmetric key for encrypting texts using the AES.GCM.seal method. We also encode it in a Base64 string, so it can be sent as normal text using the Stream Chat SDK in the integration step.

After the text is encrypted and encoded, it can be safely sent through the network.

4. Decrypt Text

After the recipient receives the encrypted text, they will decode it from Base64 and decrypt it using the AES.GCM.SealedBox and AES.GCM.open methods.

After the text is decrypted, it should be readable and can be displayed in the UI.

Stream Chat Integration

In this section, you'll learn how to use the methods implemented above to achieve end-to-end encryption with Stream Chat's Swift SDK.

You can follow the "iOS Chat SDK Setup" step in the official tutorial to get a basic chat app working in minutes.

1. Public Key Extra Data

We need to define a custom publicKey field for the User object so that users can share their public key with others. To do this, create the PublicKeyExtraData type.

After that, you should set the User.extraDataType to PublicKeyExtraData.self before you initialize the Stream Chat Client in AppDelegate.swift:

2. Custom Set User Method

Now, let's define our custom setUser method so that the user can be registered in Stream Chat alongside its public key.

Additionally, the public key must be exported in a string format. You should define an exportPublicKey method to do this.

We're percent-encoding the public key after encoding to base64 to ensure the + sign is not ignored in case the public key is used in the URLs of specific requests.

In a future step, after we fetch another user's public key, we'll need to use the importPublicKey method, which does the reverse of the exportPublicKey.

3. Encrypted Chat View Controller

Now that we generated the private key and registered our user with a public key, we need a custom ChatViewController that encrypts messages before sending and decrypts messages before displaying.

To do this, let's create the EncryptedChatViewController, which inherits from ChatViewController.

As you can see, it contains an additional symmetricKey property, which will be used for the encryption and decryption. In the viewDidLoad we set the messagePreparationCallback, which encrypts the messages before they're sent. We also override the messageCell method to decrypt the message before displaying it.

3. Present Encrypted Chat

After implementing our custom ChatViewController, now we can present it.

To present the EncryptedChatViewController, we query the user we want to communicate with to get its public key and generate a symmetric key. After that, we set the symmetricKey and presenter properties and push the view controller into the navigation stack.

Next Steps With CryptoKit

Congratulations! You just learned how to implement basic end-to-end encryption in your iOS chat apps. It's important to know this is the most basic form of end-to-end encryption. It lacks some additional tweaks that can make it more bullet-proof for the real world, such as randomized padding, digital signature, and forward secrecy, among others. Also, for real-world usage, it's vital to get the help of application security professionals.

Choose Your iOS Dependencies Wisely

Matheus Cardoso — Thu, 22 Oct 2020 14:31:46 +0000

Dependencies are vital for most iOS projects. They allow us to speed up development and not reinvent the wheel every time we need components such as networking, rendering, chat, calendar, and many others which can be common to different types of projects. It's also an efficient way of deferring code maintenance to a company or open source community, since they'll fix bugs, add new features, and update the code for you. Using dependencies, we're able to focus our working hours on what sets our iOS app apart from the rest.

However, any seasoned iOS developer knows dependencies can often hold your iOS project back and negate the time saved if you don't choose them wisely.

Fortunately, there are rules which you can follow when choosing iOS dependencies to avoid most, if not all, of the downsides. In this post, I present five rules for iOS dependencies that can save you many hassles in the future.

Open-Source or Source-Available

You should always prefer using dependencies that are Open-Source or Source-Available. These will allow you greater freedom to accommodate changes in requirements, fix bugs yourself, step through code, and debug things easily. It will also help you find out undocumented behaviors, know what it does for sure, and not risk undesired malicious code or analytics to run in your apps.

Closed-Source dependencies distributed in a compiled format such as .xcframework, are an opaque box. It's hard to know for sure what it's doing. What data is it collecting? What is it sending to the server? Can it crash my app under certain circumstances outside my control? How long will the maintainer take to fix a bug?

Closed-Source SDKs are constantly harming productivity and reducing the choices that iOS developers can make. For example, Facebook's iOS SDKs frequently crash other apps for no good reason, without any possibility for developers to act on it other than removing the SDK altogether. Another SDK was found to steal user data and attempt to cover its tracks. They're best avoided if there are competent alternatives.

Active Development

Before you decide on a dependency, check how long ago its last updates were made. If it's days or weeks, it's more likely that it's compatible with the latest iOS versions, and you'll be able to count on updates for a while. It's also more likely that the maintainers are still around to help if you have a question.

On the other hand, if it's been months or years since the last updates, you should consider not using this dependency. It's unlikely that it's still compatible with the latest iOS or Swift versions, and even less likely that the maintainer is around to help you or provide any new updates.

Inactive projects are generally bug-ridden and should be avoided, but it's still possible to use them if you're willing to fork them, fix the bugs you encounter, and become a maintainer. However, most of the time, it can be more productive to build the component you need from scratch.

Built with Swift

Swift has been around for five years. It's now considered a mature language and has greatly increased productivity and code correctness over its ancestor, Objective-C. It's no mystery that these improvements are carried over to the dependencies you use. Dependencies built with Swift are likely to be more stable and fit in seamlessly with the Swifty patterns and features developers know and love, such as protocol oriented programming, optionals, generics, collection types, first class functions, and others.

Alternatively, if you choose to use a dependency written in Objective-C, you'll likely run into old patterns and naming conventions that are not as nice to work with. Objective-C dependencies are also more likely to contains bugs related to null references.

It's not a complete deal breaker if a dependency is written in Objective-C, as long as it's still actively maintained. Yet, I've found that every Objective-C dependency I wanted to use had an excellent and newer alternative written in Swift. For example, over the years, I've replaced SDWebImage with Nuke in almost all my projects with great benefit.

Company-Maintained

Dependencies that are maintained by a company tend to be more reliable when compared to dependencies that are supported by a community. It's less likely that a company-maintained SDK or library will be abandoned if it's vital to that company's business.

For example, it's highly unlikely that a library like Realm or IGListKit will be abandoned, as they're maintained by a business as well as an active community. In some cases, companies may also offer dedicated support in case you need the extra commitment.

Welcoming Community

A welcoming community also goes a long way in ensuring a smooth experience with an SDK or library. Most of the time, except for company support or paid support plans, you'll rely on this community to help you when you're having problems or when you want to contribute back to the project. If it's a community that is patient with newcomers and is receptive to new ideas, then you're more likely to have a good time depending on them.

Conclusion

These are the characteristics I look for when searching for iOS libraries and SDKs. It's challenging to find a library which checks all these boxes, but keeping these in mind helps compare the options and choose the one that will give you fewer problems in the future.

Build a Psychotherapy App with Video and Chat for iOS

Matheus Cardoso — Thu, 15 Oct 2020 15:03:43 +0000

In this guide, we'll create the a basic Psychotherapy App for iOS with Stream Chat, for its fully featured chat components, and Dolby.io, for its excellent audio and video capabilities. Both offerings are HIPAA compliant. When you finish following the steps, you'll get an app like in the image below. Additionally, it will be compatible with iOS's light and dark mode features.

If you get lost while following this guide, you can get the completed Xcode project in this GitHub repo: psychotherapy-app-ios. Let's get started with our teletherapy app development!

What is Stream Chat?

Build real-time chat in less time. Rapidly ship in-app messaging with our highly reliable chat infrastructure. Drive in-app conversion, engagement, and retention with the Stream Chat messaging platform API & SDKs.

Stream Chat & Messaging

What is Dolby.io's Client SDK?

Dolby Interactivity APIs provide a platform for unified communications and collaboration. In-flow communications refers to the combination of voice, video, and messaging integrated into your application in a way that is cohesive for your end-users. This is in contrast to out-of-app communications where users must stop using your application and instead turn to third-party tools.

Dolby.io Documentation

Requirements

Xcode 11 or later
iOS 13 or later
A Stream account
A Dolby.io account

Set Up Project

Create the Xcode Project

First, we open Xcode and create an iOS App project.

And make sure to select 'Storyboard' for the User Interface.

Install Dependencies

To install the Stream Chat and Dolby.io's Client SDK dependencies, we'll use CocoaPods. If you prefer Carthage, both frameworks support it as well.

In the folder where you saved the project, run pod init and add StreamChat and VoxeetUXKit to the Podfile. It should look similar to this:

Note: if you're not seeing the Podfile below due to a bug in dev.to, refresh this page.

After you do that, run pod install, wait a bit for it to finish, and open the project via the .xcworkspace that was created.

Configure the Stream Chat Dashboard

To make things simple for now, let's disable both auth checks and permission checks. Make sure to hit save. When your app is in production, you should keep these enabled.

For more information, visit the documentation about authentication and permissions.

Now, save your Stream credentials, as we'll need them to configure the chat in the app. Since we disabled auth and permissions, we'll only really need the key for now, but in production, you'll use the secret in your backend to implement proper authentication to issue user tokens for Stream Chat, so users can interact with your app securely.

As you can see, I've censored my keys. You should make sure to keep your credentials secure.

Configure the Dolby.io Dashboard

Configuring the Dolby.io dashboard is simpler. Just create an account there, and it should already set up an initial application for you.

Now, save your credentials, as we'll need them to power the audio and video streaming in the app. As with the Stream credentials, you use these for development. In production, you'll need to set up proper authentication. It's described in detail here.

Configure Stream Chat and Dolby.io's SDKs

The first step with code is to configure the Stream and Dolby SDK with the credentials from the dashboards. Open the AppDelegate.swift file and modify it, so it looks similar to this:

That code initializes the Dolby.io and Stream Chat SDKs with credentials you got in the previous two steps.

Create the Join Screen

Let's start building the "Join" screen. This screen consists of two UIButton instances. One to join as the Patient, and the other to join as the Therapist. This is, of course, an oversimplification to make this tutorial short and get to the chat, audio, and video features faster. In your complete app, you'll need proper registration, database, and all that. For this tutorial, the screen will look similar to the screenshot below.

Go to the storyboard, select the default view controller, and click Editor > Embed In > Navigation Controller. That will place it under a navigation controller, which we'll use to navigate to the channel screen.

Make sure to rename ViewController to JoinViewController, so you don't get confused later on. You can do this easily by right-clicking on ViewController in ViewController.swift and selecting refactor.

To make things simple, let's leave the storyboard like this and use only code from now on. To set up the two buttons, we need the following code in JoinViewController.swift:

That code sets up the views, the constraints, and the handlers we need. Let's start by extending JoinViewController to define setupViews:

That code will create the buttons and add them to the controller's view. Next, we need to define constraints between the three. Let's do this by extending JoinViewController to define setupConstraints:

That code will make sure the patientButton stays in the center of the screen and the therapistButton below it. Now we need to set up the handler for when the user presses the buttons. Let's do this again by extending the controller to define setupHandlers:

That code will make it so when the user presses the button a TherapyViewController is created and set up for the therapist or patient, depending on which button was pressed. We'll create TherapyViewController in the next step.

Create the Therapy Screen

Now, let's create the screen where the patient and therapist will talk via chat and where they can begin a video call. We'll start by defining TherapyViewController. It will look similar to the screenshots below.

The first step is to create a TherapyViewController.swift file and paste the code below.

That code defines a subclass of ChatViewController, which provides most of the chat behavior and UI we need. It also defines the patient and therapist User objects and a Channel object between the two. These objects will be used to interact with the Stream API. On viewDidLoad, we also call setupViews and setupHandlers to set up the views and handlers needed. We'll define those functions next.

But, let's first define the setupPatient function that sets the current Stream Chat user as the patient, and the setupTherapist function that sets it as the therapist.

Now we define setupViews to set up the views we need.

Those functions will display a button which starts a call. For it to work, we'll need to define setupHandlers as well.

Those functions set callButtonPressed as the function to be called when the call button is pressed, which in turn calls startCall, which we define next.

Finally, that function uses the Dolby.io SDK to start a conference call.

Configure Usage Descriptions

If you use the app now, you'll be able to chat, but pressing the call button will crash the application. That happens because we need to configure the usage descriptions for microphone and video in the Info.plist file. To do this, just open Info.plist and set the NSMicrophoneUsageDescription and NSCameraUsageDescription keys as pictured below.

Finally, we open the app in two devices, and, from the chat, we can start a call.

Next Steps with the Psychotherapy App

Congratulations! You've built the basis of a functioning psychotherapy app with Stream Chat and Dolby.io. I encourage you to browse through Stream Chat's docs, Dolby.io's docs, and experiment with the project you just built. If you're interested in the business side of things, read about how Stream Chat provides HIPAA compliance and how Dolby.io provides HIPAA compliance. Good luck on your teletherapy app development!

End-to-End Encrypted Chat with the Web Crypto API

Matheus Cardoso — Thu, 08 Oct 2020 13:26:05 +0000

When transmitting or storing user data, especially private conversations, it's essential to consider employing cryptographic techniques to ensure privacy.

By reading this tutorial, you'll learn how to end-to-end encrypt data in web applications using nothing but JavaScript and the Web Crypto API, which is a native browser API.

You can also find the full project in this GitHub repo if you happen to get lost. And if you have any questions, feel free to reach out to me on Twitter :).

What Is End-to-End Encryption?

End-to-end encryption is a communication system where the only people who can read the messages are the people communicating. No eavesdropper can access the cryptographic keys needed to decrypt the conversation—not even a company that runs the messaging service.

Hacker Lexicon: What Is End-to-End Encryption

What Is the Web Crypto API?

The Web Cryptography API defines a low-level interface to interacting with cryptographic key material that is managed or exposed by user agents. The API itself is agnostic of the underlying implementation of key storage but provides a common set of interfaces that allow rich web applications to perform operations such as signature generation and verification, hashing and verification, encryption and decryption, without requiring access to the raw keying material.

W3C: Web Cryptography API

Onto the Basics

In the following steps, we'll declare the essential functions involved in end-to-end encryption. You can copy each one into a dedicated .js file under a lib folder. Note that all of them are async functions due to the Web Crypto API's asynchronous nature.

Note: Not all browsers implement the algorithms we'll use. Namely, Internet Explorer and Microsoft Edge. Check the compatibility table at MDN web docs: Subtle Crypto - Web APIs.

Generate a Key Pair

Cryptographic key pairs are essential to end-to-end encryption. A key pair consists of a public key and a private key. Each user in your application should have a key pair to protect their data, with the public component available to other users and the private component only accessible to the key pair's owner. You'll understand how these come into play in the next section.

To generate the key pair, we'll use the window.crypto.subtle.generateKey method, and export the private and public keys using window.crypto.subtle.exportKey with the JWK format. The latter is needed to save or transmit these keys. Think of it as a way of serializing the keys for use outside of JavaScript.

PS: if you don't see generateKeyPair.js below due to a bug in dev.to, refresh this page.

Additionally, I chose the ECDH algorith with the P-256 elliptic curve as it is well supported and the right balance between security and performance. This preference can change with time as new algorithms become available.

Note: exporting the private key can lead to security issues, so it must be handled carefully. The approach of allowing the user to copy and paste it that will be presented in the integration part of this tutorial is not a great practice and only done for educational purposes.

Derive Key

We'll use the key pair generated in the last step to derive the symmetric cryptographic key that encrypts and decrypts data and is unique for any two communicating users. For example, User A derives the key using their private key with User B's public key, and User B derives the same key using their private key and User A's public key. No one can generate the derived key without access to at least one of the users' private keys, so it's essential to keep them safe.

In the previous step, we exported the key pair in the JWK format. Before we can derive the key, we need to import those back to the original state using window.crypto.subtle.importKey. To derive the key, we'll use the window.crypto.subtle.deriveKey.

In this case, I chose the AES-GCM algorithm for its known security/performance balance and browser availability.

Encrypt Text

Now we can use the derived key to encrypt text, so it's safe to transmit it.

Before encryption, we encode the text to a Uint8Array, since that's what the encrypt function takes. We encrypt that array using window.crypto.subtle.encrypt, and then we turn its ArrayBuffer output back to Uint8Array, which we then turn to string and encode it to Base64. JavaScript makes it a little bit complicated, but this is just a way to turn our encrypted data into transmittable text.

As you can see, the AES-GCM algorithm parameter includes an initialization vector (iv). For every encryption operation, it can be random, but absolutely must be unique to ensure the strength of the encryption. It is included in the message so it can be used in the decryption process, which is the next step. Also, though unlikely to reach this number, you should discard the keys after 2^32 usages, as the random IV can repeat at that point.

Decrypt Text

Now we can use the derived key to decrypt any encrypted text we receive, doing precisely the opposite from the encrypt step.

Before decryption, we retrieve the initialization vector, convert the string back from Base64, turn it into a Uint8Array, and decrypt it using the same algorithm definition. After that, we decode the ArrayBuffer and return the human-readable string.

It's also possible that this decryption process will fail due to using a wrong derived key or initialization vector, which means the user does not have the correct key pair to decrypt the text they received. In such a case, we return an error message.

Integrating in Your Chat App

And that is all the cryptographic work required! In the following sections, I'll explain how I used the methods we implemented above to end-to-end encrypt a chat application built with Stream Chat's powerful React chat components.

Clone the Project

Clone the encrypted-web-chat repository in a local folder, install the dependencies and run it.

After that, a browser tab should open. But first, we need to configure the project with our own Stream Chat API key.

Configure the Stream Chat Dashboard

Create your account at GetStream.io, create an application, and select development instead of production.

To simplify, let's disable both auth checks and permission checks. Make sure to hit save. When your app is in production, you should keep these enabled and have a backend to provide tokens for the users.

For future reference, see the documentation on authentication and the documentation on permissions.

Please take note of the Stream credentials, as we'll use them to initialize the chat client in the app in the next step. Since we disabled authentication and permissions, we'll only really need the key for now. Still, in the future, you'll use the secret in your backend to implement authentication to issue user tokens for Stream Chat, so your chat app can have proper access controls.

As you can see, I've redacted my keys. It would be best if you kept these credentials safe.

Change the Credentials

In src/lib/chatClient.js, change the key with yours. We'll use this object to make API calls and configure the chat components.

After this, you should be able to test the application. In the following steps, you'll understand where the functions we defined fit in.

Set the User

In src/lib/setUser.js, we define the function that sets the chat client's user and updates it with the given key pair's public key. Sending the public key is necessary for other users to derive the key required for encrypting and decrypting communication with our user.

In this function, we import the chatClient defined in the previous step. It takes a user id and a key pair, then it calls chatClient.setUser to set the user. After that, it checks whether that user already has a public key and if it matches the public key in the key pair given. If the public key matches or is non-existent, we update that user with the given public key; if not, we disconnect and display an error.

Sender Component

In src/components/Sender.js, we define the first screen, where we choose our user id, and can generate a key pair using the function we described in generateKey.js, or, if this is an existing user, paste the key pair generated at the time of user creation.

Recipient Component

In src/components/Recipient.js, we define the second screen, where we choose the id of the user with whom we want to communicate. The component will fetch this user with chatClient.queryUsers. The result of that call will contain the user's public key, which we'll use to derive the encryption/decryption key.

KeyDeriver Component

In src/components/KeyDeriver.js, we define the third screen, where the key is derived using the method we implemented in deriveKey.js with the sender's (us) private key and the recipient's public key. This component is merely a passive loading screen since the information needed was collected in the previous two screens. But it will show an error if there's an issue with the keys.

EncryptedMessage Component

In src/components/EncryptedMessage.js, we customize Stream Chat's Message component to decrypt the message using the method we defined in decrypt.js alongside the encrypted data and the derived key.

Without this customization of the Message component, it would show up like this:

The customization is done by wrapping Stream Chat's MessageSimple component and using the useEffect hook to modify the message prop with the decrypt method.

EncryptedMessageInput Component

In src/components/EncryptedMessageInput.js, we customize Stream Chat's MessageInput component to encrypt the message written before sending it using the method we defined in encrypt.js alongside the original text.

The customization is done by wrapping Stream Chat's MessageInputLarge component and settings the overrideSubmitHandler prop to a function that encrypts the text before sending to the channel.

Chat Component

And finally, in src/components/Chat.js, we build the whole chat screen using Stream Chat's components and our custom Message and EncryptedMessageInput components.

The MessageList component has a Message prop, set to the custom EncryptedMessage component, and the EncryptedMessageInput can just be placed right below it in the hierarchy.

Next Steps With Web Crypto API

Congratulations! You just learned how to implement basic end-to-end encryption in your web apps. It's important to know this is the most basic form of end-to-end encryption. It lacks some additional tweaks that can make it more bullet-proof for the real world, such as randomized padding, digital signature, and forward secrecy, among others. Also, for real-world usage, it's vital to get the help of application security professionals.

PS: Special thanks to Junxiao in the comments for correcting my mistakes :-)

Moderate Chat Content with Swift on AWS Lambda

Matheus Cardoso — Fri, 02 Oct 2020 12:28:03 +0000

Most of the time, when building a chat application, it's essential to have some level of control over what your users can share and say to each other.

In this tutorial, we'll use Swift Lambda and Stream's powerful chat API to build a content moderation system that can prevent users from sending unwanted content. In this case, we'll filter out possible credit card data to prevent our users from sharing it with scammers. However, you can adapt it to other sensitive data or to block bad words.

You can find the completed project on GitHub in the Samples folder inside the Swift Lambda repository.

Requirements

Set the Presend Webhook URL

After you've built your iOS chat app and the Swift Lambda is up and running, you need to configure the Presend Webhook URL using the Stream Chat REST API. To do this, you'll need your API Key, a server-side JWT, and your AWS Lambda URL.

To get the API Key, go to the Stream Chat dashboard. It will be there, similar to the image below.

Also, copy the secret, as it is needed to generate the server-side JWT. You can use jwt.io to generate it. Just paste the secret inside the text field on the right side and copy the JWT on the left side.

Finally, to set the Presend Webhook URL, you can run the curl command below in the terminal. Make sure to replace [api_key], [jwt], and [aws_lambda_endpoint_url].

Configure Swift Lambda

At first, your Swift Lambda will handle GET requests. Change it to process POST requests instead, which can be done by editing the serverless.yml file and swapping the line method: get with method: post.

Filter out credit card numbers

Now that the Swift Lambda is configured, we can get to the code part.

First, we need a function to redact credit card numbers from a message by replacing the numbers with asterisks. The code below does just that by using regular expressions to match valid numbers of known credit card operators.

You should add that to the main.swift file.

Handle the message

When the POST request hits your lambda, it will contain a JSON object describing the new message. To see which fields you can expect in this payload, see the documentation.

In the main.swift file, paste the code below.

That code will parse the JSON body into a dictionary and modify the message object by running its "text" field through the credit card redaction function. As specified in the documentation, we return this modified message object to submit the redacted version.

Deploying and testing the content moderation

The main advantage of using Swift Lambda is that it's possible to iterate fast with it. After writing the moderation code, just run the ./Scripts/deploy.sh script again and wait a few seconds.

After the upload is finished, you can run the chat app and type something in any channel. If it contains a seemingly valid credit card number such as 6011881485017922, it should be replaced with asterisks.

Next steps with Swift Lambda

Congratulations! You've just uploaded a real Swift backend to AWS. This moderation code is simple and made to demonstrate a usage of Swift Lambda to empower your chat apps. There are many ways to build even richer use cases with Swift Lambda. To find out more, check out the chatbot tutorial with Swift Lambda and Stream Chat's documentation.