This is a beginner guide designed for Swift developers who want to create a scalable dynamic website with Continuous Integration of code and in Continuous Delivery.

At the end of this tutorial, you will be able to deploy your “hello world” website in production in just a few minutes:

The tools that have been chosen are:

• Vapor 3.x, one of the most elegant web frameworks for Swift
• Git as the version control system and GitHub as the remote storing platform
• CircleCI to set up the Continuous Integration pipeline
• Heroku as the deployment platform (since vapor.cloud has been officially demised)

Note: Heroku provides an all-in-one solution for git repo hosting and CI, but this guide intends to use different tools to not depend on a single provider. Besides, GitHub and CircleCI provide more advanced features and are widely used in the industry.

Bootstrap a new Vapor project

Reference guide:

macOS - Vapor Docs

Install Vapor through Homebrew:

brew tap vapor/tap
brew install vapor/tap/vapor

Then bootstrap a new project (e.g. a new website, using the available templates):

vapor new --template=web MyAmazingProject
cd MyAmazingProject
vapor xcode

Test the new website by running the generated Xcode project and navigating to http://localhost:8080:

Push changes on GitHub

Create a new empty GitHub repository to host your code, then set it as your default remote for the Vapor project:

git remote add origin git@github.com:mygithubaccount/my-awesome-project.git

Commit and push all your changes:

git add . && git commit -m "MyAwesomeProject bootstrap"
git push origin master

Set up the CI pipeline with CircleCI

Sign up with your GitHub account on the CircleCI website:

Sign Up

Then set up a new project by selecting the newly created repo. Ignore the templates offered and click on Start building, then choose to add the configuration manually.

From the root of your repo, move the generated CircleCI configuration file:

mkdir .circleci && mv config.yml .circleci/config.yml

Now you can commit and push the changes. Go back to the CircleCI dashboard and then click on Start Building. After a while, you should get a successful build, and you can also verify the integration of CircleCI on Github:

Deploy the website with Heroku

Everything it’s ready to deploy your website to the public.

Create a Free Heroku account:

Pricing | Heroku

Then Sign in, Create a new app and choose a region. Then from the app dashboard go to Deploy, Deployment method, select GitHub and connect your account and repository.

Choose automatic deploys from the master branch and enable the Wait for CI to pass before deploy option.

Install now the Heroku CLI:

brew install heroku/brew/heroku

Log in with your email address and install the Vapor buildpack (scripts that are run when the app is deployed):

heroku login
heroku buildpacks:set vapor/vapor

Set the swift version you’re currently using (e.g., using the current stable Xcode 11.4 version):

echo “5.2” > .swift-version

Then create the Procfile (a file that specifies the commands that are executed by the app on startup):

echo "web: Run serve --env production" \
  "--hostname 0.0.0.0 --port \$PORT" > Procfile

At the time of this writing, you might need also to run:

swift package update

to update all the dependencies and avoid potential issues with the buildpack scripts.

Commit all changes and push them to master. A build will start and you can see the deployment progress in the Activity tab of the app dashboard.

Once the build is successful, you can finally scale the website by running

heroku ps:scale web=1

Your new app is now finally available at https://my-amazing-project.herokuapp.com:

Point to your custom domain

If you’ve purchased a domain for your website, it’s now time to point it to your Heroku application:

Custom Domain Names for Apps

After verifying your account you have to execute:

heroku domains:add my-amazing-project.com
heroku domains

to get the DNS Target to use in your hostname provider.

Conclusion

Setting up a production CI/CD pipeline it’s a fundamental step for accelerated delivery. You can now focus on writing production code that can be automatically tested and deployed in a few minutes by embracing GitOps:

GitOps: versioned CI/CD on top of declarative infrastructure. Stop scripting and start shipping. — Kelsey Hightower

You can find me on Twitter & LinkedIn.

In almost every live software product, code evolves with dynamics that are driven by multiple factors, such as product requirements, architectural decisions, developers skills, tools adopted, dependencies, language maturity and others.

In medium/big size projects, this leads to a growth in complexity that is hard to control without measuring how the codebase is evolving. Assessing the growth of the total LOC (Lines of Code) or the degree of coupling between internal dependencies in a modularized application can give great help in understanding the bigger picture.

There are several paid and open tools for various languages. For Swift, I’m introducing swift code metrics, an open Python package that will analyze your project’s source code directly to inspect for two types of KPIs:

Synthetic metrics

They measure the absolute number of a specific entity, such as:

• LOC (Lines Of Code)
• NOC (Number Of Comments)
• POC (Percentage Of Comments)
• NOM (Number of Methods)
• Number of concretes (Number of classes and structs)
• NOT (Number Of Tests)
• NOI (Number Of Imports)

They can help to understand the distribution of the code inside the project (e.g. by assessing the relative size of a module) or to predict the growth of the software over time.

Modules coupling

For modularized codebases, they measure the degree of coupling between all imported libraries.

The most important one is probably the dependencies graph. It helps to immediately visualize the dependencies between modules (internal or external). The library computes the total number of import calls from each folder identifying a framework (instead of checking the imports from SourceKit) to immediately understand the general level of coupling.

Another important coupling metric is the distance from the main sequence, that it’s used to represent the relation between the instability and abstraction of an internal component:

D³ = abs( A + I — 1 )

The instability is defined as below:

I = FanOut / ( FanIn + FanOut)

where:

• FanOut: identifies the number of classes inside a component that depends on classes outside the component (outgoing dependencies)
• FanIn: identifies the number of classes outside this component that depend on classes within the component (incoming dependencies)

With I = 1, the component has no dependents and thus unstable and “irresponsible”, making it very easy to change. With I = 0, the situation is the opposite since it doesn’t depend on other components and it has dependents, making it very hard to change.

The abstraction is obtained by:

A = Na / Nc

where:

• Na: number of abstract classes and interfaces in the component
• Nc: number of classes in the component

Not all components should be stable because the system would be hard to change. In general, a component considered stable should be abstract so that it can be easily changed. At the same time, an unstable component should be concrete because its instability allows the implementation inside it to be easy to change.

In an I/A plot, it’s possible to represent the distribution of the components relative to the distance from the optimum ( D = 0 ) and therefore visually determine two areas that should be ideally avoided by a module:

• zone of usefulness: components very abstract with few dependents (mostly useless)
• zone of pain: components that are very ‘concrete’ with a lot of dependents, very rigid and hard to change (e.g. usually foundation libraries)

Additional metrics

In a versioned project (e.g. in a git repository) it can also be possible to compute metrics around code changes over time, such as the git churn rate of certain modules and classes or the overall number of commits/merges. There are already several tools available for scm (some of them provided directly from the host) that are outside the scope of this article.

Get involved

Swift Code Metrics is an open source Python tool available on GitHub (https://github.com/matsoftware/swift-code-metrics).

Please read the documentation and get involved in improving and extending it with your contribution by raising an issue or opening a pull request.

For a more detailed explanation of the distance from the main sequence and on components coupling please read “Clean Architecture: A Craftsman’s Guide to Software Structure and Design (Robert C. Martin Series)”.

📝 Read this story later in Journal.

🗞 Wake up every Sunday morning to the week’s most noteworthy Tech stories, opinions, and news waiting in your inbox: Get the noteworthy newsletter >

Localizing content in iOS apps seems a rather easy process at first. The NSLocalizedString API looks for the translated value of a given key in a plain text Localizable.string file if multiple languages are supported.

However, this mechanism can easily induce the developer to an error. When the project evolves, the complexity increases: new locales to support, hundreds of new keys, or a different and more complex build process that changes the structure of bundle resources might cause regressions in the app due to missing translations or worse, missing copies.

Ideally, the developer should use only keys that have their value translated in all supported locales and he should be safe that eventual corruptions of the localization mechanism (missing resources, formatting errors, erroneous key deletions, etc) should be caught at compile-time or by unit tests.

The main culprit is the manipulation of raw Strings in NSLocalizedString keys and in the Localizable.string file. The usage of plain raw Strings, in fact, defies the advantage of a compile time type safety check.

One solution to this problem is to implement an opaque type to represent a localizable String that internally makes use of a String enum that contains all the supported keys:

This will solve one half of the problem, but how is it possible to guarantee that the Localizable file is not corrupted or that a valid string is provided in all locales?

CaseIterable enums to the rescue

The CaseIterable protocol conformance in enum introduced in Swift 4.2 makes possible to enumerate through all the defined cases in an enum without implementing the array of all keys manually ( no more var allKeys: [EnumType] = [.case2, .case2, …] !🎊).

By conforming LocaleKey to CaseIterable then it will be possible to write a simple but effective unit test that will iterate through each case to check if LocalizedText is providing a translated value instead of returning the key itself:

This will flag missing translations and prevent accidental mistakes to be merged in the development branch.

Multiple locales

The LocalizedText struct can be extended to support the injection of specific tableNames in order to check that a translation is provided for each locale:

The LocaleKeyTests unit test can then check if all supported locales are configured properly:

A more extensive example that makes use of a LanguageTableProvider is included in the sample project available on GitHub: https://github.com/matsoftware/LocaleEnumerable

Conclusion

The implementation of CaseIterable enum protocol conformance it’s an important step in the evolution of a truly type-safe language. String’s localization is just one of the most simple scenario where its application will help in reducing the impact of human error and therefore time and frustration with a simple unit test in continuous integration.

Please follow me on LinkedIn: https://www.linkedin.com/in/matcamp/

This peace may however be threatened by some special conditions where the bridge between the two languages cannot be built correctly due to ambiguity, like in the case of circular references.

Take for instance this scenario:

1. The ObjcMainClass is composed by an object that conforms to the ComponentProtocol written in Swift, therefore it needs to import the ProjectName-Swift.h generated file
2. The ObjcMainClassTests is the Objective-C unit test class that will test the ObjcMainClass component. It will make use of a StubComponent object that will conform to ComponentProtocol in order to control the execution flow of the public methods to test.
3. StubComponent is defined in the unit test target, and it will need to include the @testable import ProjectName code in order to find the protocol definition.
4. Since StubComponent lives in the unit target and it’s written in Swift, the ObjcMainClassTests has to import the ProjectNameTests-Swift.h generated file.

Try to run unit tests and what you get is the “Module ProjectName not found in ProjectNameTests-Swift.h” error:

This scenario might be quite common in projects that embrace a mockist unit testing approach where concrete stubs for new Swift interfaces are passed to existing Objective-C entities.

The best solution is to reduce the number of bridges needed between your Objective-C and Swift code. Try to migrate the module or your object graph to Swift, or temporarily write the protocol and stubs in Objective-C before planning the migration itself.

This second approach is showed in the demo project available on Github, where you can find both failing and passing scenarios described here: https://github.com/matsoftware/TestObjcSwiftCircularReference .

Happy bridging☺