Igor Kulman

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

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

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

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

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.

About a month ago I stumbled on a series of blog post called Let’s build a simple interpreter by Ruslan Spivak. In these blog posts the author write about building a simple interpreter for the Pascal programming language in Python. It is very well written and explained, I would even say that all the concepts are explained better than in the compiler course I took at the university.

In that class I had to write a Pascal compiler not interpreter in C++ and with tools like lex and yacc so I remembered most concepts but the interpreter is a bit different than a compiler and not using any external tools makes you think more about the problem.

Motivation

I felt a bit nostalgic and wanted to tackle an algorithmically challenging problem, especially because Pascal was my first programming language back in high school so I decided to follow along and write a simple Pascal interpreter in Swift, the language I switched to from C# nearly a year ago.

Swift is a different language than Python so I had to do many things differently, especially those where the Python implementation relayed on the dynamicity of the language.

But the biggest challenge was that the series ended before introducing function calling and the call stack so I had to come with a good way to do this. I also wanted to support recursion and basic loops and flow controls.

Goal

The goal was to be able to interpret a Pascal program like factorial computation or a simple number guessing game.

When your iOS application receives a push notification while in foreground, the didReceiveRemoteNotification method in the application’s AppDelegate gets called. You get the whole push notification payload and you can react to it. But there is a problem introduced in iOS 11, then fixed and then broken again (like many things done by Apple these days) that didReceiveRemoteNotification does not get called when a push notification arrives and the application is in foreground. This can be really bad if your application depends on reliable push notifications while running.

The worst thing about this problem is that everything seems to be working while you are debugging the application from XCode. The method gets called, the payload is available. But when you open the application in your iPhone or iPad without the debugger attached, didReceiveRemoteNotification just never gets called. There are many developers reporting this problem on the Apple forums and on StackOverflow.

If you run macOS side by side with Windows or have some drives formated with NTFS, you may not want them to get automatically mounted when you start macOS. I have a Windows 10 SSD with NFTS and a data HDD with NTFS next to my macOS SSD and I do not use any o those two drivers when booted in macOS, so I was looking for a way to have them not mounted at startup.

The main reason for this other than them not being shown in Finder is that macOS spins the data HDD from time to time for no apparent reason and I really do not want this.

In a classic Linux system you could edit /etc/fstab. This file can be also created on macOS, but Apple does not recommend editing it directly but to use sudo vifs. The drives should be addressed by their UUID as opposed to their “location” on Linux, so you first have to find that UUIDs.

When you have the drivers mounted, run diskutil info /Volumes/"Volume name" | grep 'Volume UUID' where “Volumne name” is the volume name as shown in Finder. This will get you just the UUID.

About 9 months ago I basically left the world of Windows development because of the death of Windows Phone and me being really fed up with Microsoft. I got a chance to work on a complete native rewrite of an iOS application so I turned my desktop PC into a hackintosh and started learning Swift and iOS development.

This post describes my experience and feelings about Swift, the language, tooling, resources after 9 months. I will probably write another post about my experience with iOS development and the iOS community.

Swift language

I think Swift is a nice modern language, it reminds me of a combination of C# and F#, so two languages I really like. The introduction of Swift got me first thinking about switching to iOS development, Windows Phone was already dying at that time.

I tried iOS development with Objective-C some time ago, did some tutorials but the language just felt wrong. Not only the strange syntax, I do not really care about that, but the expressiveness of the language compared to C#. I had to write so much more code to do anything. Swift is just much better with that.

As a side note I remember reading Masterminds of Programming a few years back, the interview with one of Objective-C authors and his hate about C++ saying he did everything better that Stroustrup and thinking “I really do not like this guy” (I do not remember if it was Cox or Love).