Igor Kulman

In all my iOS projects I use and strongly prefer Carthage. It is easy to use, does not do any changes to your project, all the dependencies are built just once and then linked to the project as dynamic frameworks. There are many good posts about the advantages of Carthage compared to CocoaPods so in this post I will just focus on the actual usage, mainly in CI.

Carthage basics

All your Carthage dependencies are listed in the Cartfile file in the root of your project. In case you split your app into multiple projects like I do, there is a Cartfile for every project in the workspace. Next to every Cartfile there is a Cartfile.resolved file pinning all your dependencies to a specific version.

You just need to keep those two files in your source control and then run carthage bootstrap when you clone the project so Carthage downloads and builds all the dependencies. This happens just once for a developer, but it is slow and time consuming. If you use a CI for automatic builds, it becomes a real time waste rebuilding all the dependencies before each build.

Carthage approaches

Developers typically try to speed things up with multiple approaches

• Keeping Carthage/Checkouts in source control. This makes the repository bigger by keeping unnecessary files, the checkout is faster but the build is still slow.
• Keeping Carthage/Build in source control. This also makes the repository bigger, potentially much bigger if you update your dependencies often, but the build times are super fast as there is nothing to actually build.
• Caching the Carthage builds in CI. This does not make the repository bigger and can be really fast when done properly
• Caching the Carthage builds using tools like Rome. This does not make the repository bigger and can be very powerful and flexible, but typically requires a paid 3rd party storage service like Amazon S3.

When you work on an iOS app localized into multiple languages one of the biggest challenges is making sure that everything is translated, no string is missing in any language. Xcode does not provide any tool to make this easier for you, but there are some 3rd party tools that you can integrate into your workflow.

verify-string-files

I have recently found a quite old project called verify-string-files. It is a command line tool take takes you base localization file and compares it to all the translations, informing you about missing strings. Altough the last commit to this project was way back in 2014 it still works reliably, there have not been any changes to the way iOS does localization.

The best thing about this tool is that you can integrate it to your build process.

Build process integration

The tool is available only as source code, so you have to build it first. I put the built binary to a support folder of my projects.

Then I have a Build-Phases folder with all the script used in the build process. I think it is a much better solution than embedding the script right into the Xcode project.

To integrate verify-string-files you just need a really simple script, providing the path to the base localization file

${PROJECT_DIR}/support/verify-string-files -master ${SRCROOT}/iOSSampleApp/Resources/Base.lproj/Localizable.strings

In Xcode, just add a new Run scrip phase and call $SRCROOT/Build-Phases/check-strings where check-strings is the script name. Just do not forget to chmod +x the actual file.

This will result in build errors when there are missing string, shown directly in the base localization file

I am a big fan of automation in software development so when I started doing iOS development one of my goals was to automate everything on the iOS project.

No more manual versioning, manual build distribution… let the computers do the work for me. Here is the setup I ended up with.

Separate app ids for development and distribution

Let’s say your app id is com.company.app. You can use that app id when developing the app, running it in the simulator or on your device and also when distribution the app using services like TestFlight or uploading it to the AppStore.

With just one app id you cannot have both the AppStore version and a development version installed on your device. This a problem when working on an app that you use daily for communication with your colleagues, but you are working on a feature that requires you to use a different server, or some MDM, etc.

There is also another problem you will encounter if you use push notifications. When you create a push notification certificate for production, push notifications for your app will work with AppStore builds, with ad-hoc builds in TestFlight and other services but you will not get any notifications when running the app on your device deployed from Xcode. At least not easily.

To counter that, I use separate app ids

• com.company.app with push notifications set to production for AppStore and ad-hoc distribution
• com.company.app.dev with push notifications set to sandbox for development

This of course requires your backend to support it by choosing the right push notifications certificate depending on the app id.

With this setup, I can

• use the AppStore version and the development version of the app on my device at the same time
• have push notifications working also in the development version of the app

Automatic builds and tests with Gitlab

The iOS project I work on uses self-hosted Gitlab instance, so using Gitlab CI was the obvious choice. You just need a machine with macOS that is always online, install the Gitlab runner, connect it to the Gitlab instance and you are done. Everything else is just a matter of configuration in a file in your repository.

Working on an iOS or macOS project in Xcode you typically create classes with the same structure over and over again.

I use coordinators so I am creating new UIViewControllers, each time referencing RxSwift, having methods for setting up UI, bindings .. most of the time also containing a delegate for the coordinator.

Having to create files with the same structure over and over again manually is a waste of time, a much better solution is creating Xcode file templates for those files.

Xcode file templates

File template location

All the Xcode custom file templates are located in ~/Library/Developer/Xcode/Templates/File Templates and grouped into sections by their folder name. If you want Xcode to show a “Custom” section at the bottom of the new file dialog, just create a ~/Library/Developer/Xcode/Templates/File Templates/Custom folder.

File template structure

Each file template is a separate folder with a name ending in .xctemplate. If you want to create a simple “Swift Class” file template, you have to create a folder named Swift Class.xctemplate in ~/Library/Developer/Xcode/Templates/File Templates/Custom.

Each file template folder should contain at least 3 files:

• TemplateInfo.plist - describing the template
• TemplateIcon.png - icon shown in the Xcode new file dialog
• ___FILEBASENAME___.swift - the actual template file

When developing any application it is a good practice not to hard-code your strings but to use some kind of a strings file. In iOS you typically use the standard Localizable.strings file as storage and some string based API to use those strings, like

extension String {
    var localized: String {
        return NSLocalizedString(self, tableName: nil, bundle: Bundle.main, value: "", comment: "")
    }
}

This of course works but it is not exactly “safe”, if you make a typo the compiler has no way to warn you and you, or worse your customers, will find out at runtime. There is a better way.

SwiftGen is a Swift code generator that will help you with that. It can generate enums for your strings, assets, storyboards. With a simple configuration SwiftGen reads your Localizable.strings file and generates a L10n enum with all the strings

internal enum L10n {

  /// Search colleagues by name or surname
  internal static let enterpriseDirectorySearchInfo = L10n.tr("Localizable", "enterprise_directory_search_info")
   /// Copyright © Igor Kulman\nAll rights reserved.\n\nVersion %@
  internal static func welcometxt(_ p1: String) -> String {
    return L10n.tr("Localizable", "welcometxt", p1)
  }
  ...
}

Simple strings are generated as properties and strings with formatting parameters as functions, so you always known how many parameters to use. It also makes it easier to find the correct string by showing the strings in Xcode intellisense

If you want a more complete example, take a look at my iOS sample app on Github

The iOS 11 has many bugs, more are introduced with every update. I only just recently discovered a bug in the registration part of the application I work on.

The registration flow contains a few screens to gather the user data. The navigation among those screens (managed by a coordinator) is done by Back and Next buttons in the UINavigationBar. The users can at any time get back to the previous screen, and if they are running iOS 11.2 they will see the bug:

The users tap the Next button to go to the next screen and when they get back, the Next button is faded. It works, can be tapped, but does not look right. This only happens on iOS 11.2.

When you have an iOS application running in production, you probably want to know if and why it crashes, so you can fix all your bugs as soon as possible.

There are many good services like HockeyApp that can help you with that, but sometimes you are not allowed to use any 3rd party service for this. In this case you have to look for another solution how to get info about all your iOS application crashes and process it by yourself.

PLCrashReporter

Looking for a crash reporting solution I found PLCrashReporter. This library seems to be kind of a standard for crash reporting, used by the already mentioned HockeyApp and many others.

It is a Objective-C framework with latest version from 2014, but it still works and you can use it in your Swift application.

Installation

After downloading the latest PLCrashReporter and adding it to your project as a linked framework, you need to import it in bridging header

#import <CrashReporter/CrashReporter.h>

Usage

In the application I currently work on I use CleanroomLogger for all the logging, giving the user the ability to export all the logs and send them using the standard iOS share.

If you are a macOS user you may be used to Time Machine as the standard for backups. Time Machine is fine if you want to backup your files and configuration, but if for example your disk dies or your hackintosh completely breaks with some bad update, there are better and faster ways to get it up and running again.

Requirements

Basically everything comes down to your backup requirements. These are mine

• full backup of the macOS SSD including EFI with Clover
• backups that can be restored without any additional configuration to the current macOS SSD or a new one in case of a disk failure
• no need for the ability to restore single files (all work data are in Git and Dropbox)
• reasonable backup and restore speed

Looking at different backup solutions I chose Clonezilla. It is not exactly the most user-friendly solution, but it is a very powerful one if you know what you are doing.

When switching from Windows Phone development to iOS I had about 3 months to learn iOS and Swift before starting the work on an actual iOS application. I had a chance to build the application from scratch with a colleague so I wanted the application to be really well written and architected.

I started to look at some iOS tutorials and other peoples’ iOS code. Learning and using Swift was easy (read more about my Swift experience in a separate blog post) but when reading about using the iOS SDK and especially application architecture I found stuff that I really disliked.

There were three big things in particular that I disliked, that I want to show you together with solutions I found. This first post deals with navigation.

The problem

When going through some iOS tutorials I found code like this a lot

class ProfileViewController: UIViewController {
  
  @objc func donection(sender: UIButton) {
    let vc = PreferencesViewController()
    navigationController?.pushViewController(vc, animated: true)
  }
}

When you are a long-time iOS developer, you may have seen and probably written code like this. All the tutorials contain code likes this. It may look perfectly OK to you. But for me, coming from the .NET world, this was a real WTF moment:

• Why would anyone write code like this?
• Why the strong coupling between those two view controllers?
• Why an assumption the view controller is embedded in a navigation controller and we always want to do a push?

This code looked absolutely awful to me and I never wanted to write a code like this. So I started looking for better approaches and solutions. And I found coordinators (sometimes called flow controllers).

The solution: Coordinators

The idea of a coordinator is simple. In your application you probably have some flows, like registration flow, user settings flow, product purchasing flow, etc. Every flow is managed by a coordinator. The role of the coordinator is to know which view controller to display at a certain time.

If you work on an iOS application intended for corporate environments, you are probably familiar with MobileIron AppConnect, because it is the most commonly used MDM solution. They have an SDK for iOS with stated support for Objective-C, Xamarin C# bindings and an Cordova plugin. If your application is written completely in Swift, there is some bad news in the documentation:

NOTE: The AppConnect for iOS API supports apps written in Objective-C. It does not support apps written in Swift.

Luckily, this is not true, you can integrate the AppConnect SDK to an application written entirely in Swift, you just need to do a few more steps.

First, add the SDK to the project exactly as the documentation says:

• Add AppConnect.framework to your Xcode project
• Add the libcrypto.a library
• Add the libProtocolBuffers.a library
• Link the Security framework
• Link the Mobile Core Services framework
• Link the Local Authentication framework
• Add linker flags
• Copy bundle resources from AppConnect.framework
• Register as a handler of the AppConnect URL scheme
• Declare the AppConnect URL scheme as allowed

When you encounter the Use AppConnect’s UIApplication subclass step you have a problem, you cannot do it in a Swift application the same way as in Objective-C. You need to use the Info.plist in your project and add a key called NSPrincipalClass with the value of AppConnectUIApplication instead. This ensures your main application class inherits from the required AppConnect class.

<key>NSPrincipalClass</key>
<string>AppConnectUIApplication</string>