xcode-select

This is the most common way to get the path to the selected instance:

xcrun xcode-select --print-path

# Output
/Volumes/Extended/Archives/Xcode_12.5.app/Contents/Developer

According to the documentation:

Prints the path to the currently selected developer directory. This is useful for inspection, but scripts and other tools should use xcrun(1) to locate tool inside the active developer directory.

Note: If you wonder why I prefix the xcode-select with xcrun command, please, check the Multiple Xcode versions or Why xcrun is your friend article.

readlink

There is a trick to get the current selected Xcode version without the xcode-select tool. It can be helpful in some cases, but I recommend using xcode-select if you have no additional requirements. To check the current selected Xcode version without xcode-select, evaluate the following command:

readlink /private/var/db/xcode_select_link

# Output
/Volumes/Extended/Archives/Xcode_12.5.app/Contents/Developer

Every time you switch the default Xcode, xcode-select changes the link to the selected version. Perhaps, this is the fastest way to obtain the path, but it is not documented, and Apple can break it with any following Xcode release.

List of installed Xcode versions

Spotlight

The easiest way to get the list of installed Xcode versions is to ask the Spotlight with the following command:

mdfind "kMDItemCFBundleIdentifier = 'com.apple.dt.Xcode'"

# Output
/Volumes/Extended/Archives/Xcode_12.5.app
/Volumes/Extended/Archives/Xcode_12.4.app
/Volumes/Extended/Archives/Xcode_12.1.app
/Volumes/Extended/Archives/Xcode_12.3.app
/Volumes/Extended/Archives/Xcode_12.2.app

Note: This approach is usually not suitable for CI/Remote Builds because this is a popular option to disable Spotlight to improve performance.

system_profile

The less obvious way to get the list of installed Xcode versions is to use the system_profiler. It registers all the versions immediately when you extract them from the xip file.

system_profiler -json SPDeveloperToolsDataType

The problem here is the output. It is vast and looks like the following for each installed version:

{
  "SPDeveloperToolsDataType" : [
    {
      "_name" : "spdevtools_info",
      "spdevtools_apps" : {
        "spinstruments_app" : "12.5 (64544.130)",
        "spxcode_app" : "12.5 (18205)"
      },
      "spdevtools_path" : "/Volumes/Extended/Archives/Xcode_12.5.app",
      "spdevtools_sdks" : {
        "iOS" : {
          "14.5" : "(18E182)"
        },
        "iOS Simulator" : {
          "14.5" : "(18E182)"
        },
        "macOS" : {
          "11.3" : "(20E214)",
          "20.4" : ""
        },
        "tvOS" : {
          "14.5" : "(18L191)"
        },
        "tvOS Simulator" : {
          "14.5" : "(18L191)"
        },
        "watchOS" : {
          "7.4" : "(18T187)"
        },
        "watchOS Simulator" : {
          "7.4" : "(18T187)"
        }
      },
      "spdevtools_version" : "12.5 (12E262)"
    },
...
}

Parse the system_profiler output with jq

You have to parse the system_profiler output to provide meaningful information. One option is to use jq – a lightweight and flexible command-line JSON processor. For example, if you want to list paths:

system_profiler -json SPDeveloperToolsDataType | jq '.SPDeveloperToolsDataType[].spdevtools_path'

# Output
"/Volumes/Extended/Archives/Xcode_12.5.app"
"/Volumes/Extended/Archives/Xcode_12.4.app"
"/Volumes/Extended/Archives/Xcode_12.3.app"
"/Volumes/Extended/Archives/Xcode_12.2.app"
"/Volumes/Extended/Archives/Xcode_12.1.app"

Or for installed versions:

system_profiler -json SPDeveloperToolsDataType | jq '.SPDeveloperToolsDataType[].spdevtools_apps.spxcode_app'

# Output
"12.5 (18205)"
"12.4 (17801)"
"12.3 (17715)"
"12.2 (17535)"
"12.1 (17222)"

Tips & Tricks

How to get the installed Xcode version

When you have the path to the current selected Xcode, then you can use the following function to extract CFBundleShortVersionString or ProductBuildVersion:

#!/bin/sh -e

function xcodeBundleVersion() {
    defaults read "${1}/../version.plist" "CFBundleShortVersionString"
}

function xcodeBuildVersion() {
    defaults read "${1}/../version.plist" "ProductBuildVersion"
}

function xcodeVersion() {
    BUNDLE_VERSION=$(xcodeBundleVersion ${1})
    BUILD_VERSION=$(xcodeBuildVersion ${1})
    echo "Xcode ${BUNDLE_VERSION} (${BUILD_VERSION})"
}

# Note that you can replace the `xcode-select` call with other methods to extract the path
XCODE_VERSION=$(xcodeVersion $(xcrun xcode-select --print-path))
echo $XCODE_VERSION

Faster Xcode secure-archive expansion (xip)

When you download a xip secure archive, you can expand it from CLI with xip tool. In this case, the validation of the archive will not be attempted. On Mac mini M1, it takes around four minutes to expand it.

% du -h Xcode_12.0.1.xip
  10G    Xcode_12.0.1.xip

% time xip --expand Xcode_12.0.1.xip
xip: signing certificate was "Development Update" (validation not attempted)
xip: expanded items from "/Users/dive/Downloads/Xcode_12.0.1.xip"
xip --expand Xcode_12.0.1.xip  901.47s user 139.39s system 420% cpu 4:07.79 total

xcodes – a command-line tool to install and switch between multiple versions of Xcode

I can recommend xcodes as a tool to manage your Xcode installation. The tool itself has a few benefits:

• When aria2 (a lightweight multi-protocol & multi-source command-line download utility) installed, then xcodes will default to use it for downloads. It uses up to 16 connections to download Xcode 3-5x faster than usual
• xcodes written in Swift. Improve, fix and evolve if you need something from the tool

% xcodes installed 
12.1 (12A7403)           /Volumes/Extended/Archives/Xcode_12.1.app
12.2 (12B45b)            /Volumes/Extended/Archives/Xcode_12.2.app
12.3 (12C33)             /Volumes/Extended/Archives/Xcode_12.3.app
12.4 (12D4e)             /Volumes/Extended/Archives/Xcode_12.4.app
12.5 (12E262) (Selected) /Volumes/Extended/Archives/Xcode_12.5.app

It relies on xcodereleases.com data (JSON), so you can expect delays between releases and the tool updates. But usually, it takes 10–20 minutes for an update.

Note: The tool downloads Xcode versions directly from the Apple Developer Portal. And this is the only way to do so. Please, do not download Xcode versions from third-party storages.

I recently spent a few hours helping a friend of mine investigate a weird issue in their Continuous Development infrastructure. Builds were failing with different fatal errors mostly related to SDK paths and .platform directory locations. At first sight, it was clear that something is wrong with the current selected Xcode, but all our initial attempts to catch the problem failed.

In the end, we isolated the problem; one of the tools they use changes PATH silently for the environment to simplify access to Xcode tools. Due to their internal logic, the CD pipeline changes a current selected Xcode a few times on the way within the same script. In some cases, the pipeline ended with xcodebuild in the environment’s PATH that does not reflect the expected version after the xcode-select — switch command.

How? Pretty easy, actually. A simplified sequence looked like this:

# Innocent tool extends the `PATH`
# With the `bin` directory within the current selected Xcode
% export PATH=”/Xcode_12.5_beta_3.app/Contents/Developer/usr/bin:${PATH}”

# We change Xcode in a proper way
% sudo xcode-select — switch /Xcode_12.1.app/Contents/Developer

# Due to the overridden `PATH`, `xcodebuild` points to an incorrect version
% xcodebuild -version 
Xcode 12.5
Build version 12E5244e

# `xcrun` knows the truth
% xcrun xcodebuild -version
Xcode 12.1
Build version 12A7403

xcrun — Invoke Xcode tools in a safer way

According to the documentation:

xcrun provides a means to locate or invoke developer tools from the command-line, without requiring users to modify Makefiles or otherwise take inconvenient measures to support multiple Xcode toolchains.
The tool xcode-select(1) is used to set a system default for the active developer directory and may be overridden by the DEVELOPER_DIR environment variable.

In real life, it means that you can prefix all the calls to Xcode tools with xcrun on CI/CD to avoid the situation I described in the beginning. Want to run xcodebuild — call it via xcrun xcodebuild command, need to run/invoke simulators, use the xcrun simctl command.

It can save a few hours for your RE/DevOps team at the end of the day. And, depends on the company size, from 5 to 100 hours for your engineers.

What else?

xcrun has a few additional commands.

find — enables “find” mode, in which the resolved tool path is printed instead of the tool being executed.

$ xcrun — find xcodebuild
/Xcode_12.1.app/Contents/Developer/usr/bin/xcodebuild

$ xcrun — find clang
/Xcode_12.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang

A few helpers to print paths/versions of the selected SDKs.

# Print the path to the selected SDK
$ xcrun — show-sdk-path
/Xcode_12.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk

# Print the version number of the selected SDK
$ xcrun — show-sdk-version
10.15.6

# Print the build version number of the selected SDK
$ xcrun — show-sdk-build-version
19G68

# Print the path to the platform for the selected SDK
$ xcrun — show-sdk-platform-path
/Xcode_12.1.app/Contents/Developer/Platforms/MacOSX.platform

# Print the version number of the platform for the selected SDK
$ xcrun — show-sdk-platform-version
10.15.6

verbose option shows the logic behind the xcrun. For example, you can see that all the mappings are stored within a temporary xcrun_db and populated on the stage when you select a different Xcode version.

% xcrun — verbose — find git 
xcrun: note: PATH = ‘/Xcode_12.5_beta_3.app/Contents/Developer/usr/bin/:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin’
xcrun: note: SDKROOT = ‘/Xcode_12.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk’
xcrun: note: TOOLCHAINS = ‘’
xcrun: note: DEVELOPER_DIR = ‘/Xcode_12.1.app/Contents/Developer’
xcrun: note: XCODE_DEVELOPER_USR_PATH = ‘’

# The database with all the links
xcrun: note: xcrun_db = ‘/var/folders/gn/8j0pyrwj5j3ggxprkczkpwtc0000gn/T/xcrun_db’

xcrun: note: xcrun via git (xcrun)
xcrun: note: database key is: git|/Xcode_12.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk||/Xcode_12.1.app/Contents/Developer|
xcrun: note: lookup resolved in ‘/var/folders/gn/8j0pyrwj5j3ggxprkczkpwtc0000gn/T/xcrun_db’ : ‘/Xcode_12.1.app/Contents/Developer/usr/bin/git’
/Xcode_12.1.app/Contents/Developer/usr/bin/git

Side notes

- Check the previous note about xed — Xcode invocation tool
- Create a minor task for your DevOps team to prefix all the calls to Xcode tools with xcrun

Grammarly iOS Keyboard — Unboxing

Grammarly is a lovely writing assistant. Twenty million people use the tool across the globe according to the statistics available on the site. I use it too. No complaints, it does its job quite well, and I am a happy user. The only thing that always worried me is the Grammarly iOS Keyboard. As an iOS engineer, I know how easily you can collect different data, sensitive information, and even do not ask users about the consent. So, let’s check what is inside the Grammarly iOS application.

TL;DR

• Grammarly iOS uses at least three trackers (Adjust, AppsFlyer, Internal analytics)
• Grammarly Keyboard has access to keystrokes, sensitive data, and able to send them over the network

Frameworks

Facebook

From the Grammarly.ipa file it is clear that they are using Facebook SDKs:

➜ Grammarly.app_unzip $ find . -iname '*.framework'
./Frameworks/FacebookLogin.framework
./Frameworks/FBSDKLoginKit.framework
./Frameworks/FBSDKCoreKit.framework
./Frameworks/FacebookCore.framework

Yes, they are using Facebook as a Sign In/Sign Up provider, and Facebook explicitly said that this is the only way to authorise users. From the Facebook Platform Policy:

Section 8. Login

Point 2. Native iOS and Android apps that implement Facebook Login must use our official SDKs for login.

The only concern here is the way how Facebook treats users and applications that use their SDKs. During 2020, Facebook already damaged a lot of application twice. Check The big Facebook crash of 2020 and the problem of third-party SDK creep by Guilherme Rambo.

MSpell framework

This framework also ships with the application, and it seems that this is the engine the Grammarly uses for spell and grammar checks. Some exported functions from the framework, just as an example:

0000000000080808 T __ZN10Dictionary21_loadCommonlyConfusedERKNSt3__16vectorINS0_12basic_stringIcNS0_11char_traitsIcEENS0_9allocatorIcEEEENS5_IS7_EEEE
0000000000080d54 T __ZN10Dictionary24_loadProfanityDictionaryERKNSt3__16vectorINS0_12basic_stringIcNS0_11char_traitsIcEENS0_9allocatorIcEEEENS5_IS7_EEEE
0000000000082034 T __ZN10Dictionary24_loadSensitiveDictionaryERKNSt3__16vectorINS0_12basic_stringIcNS0_11char_traitsIcEENS0_9allocatorIcEEEENS5_IS7_EEEE
00000000000822ac T __ZN10Dictionary27isValidCommonlyConfusedPairERKNSt3__112basic_stringIDsNS0_11char_traitsIDsEENS0_9allocatorIDsEEEES8_

Trackers

No surprises here. There are at least three trackers within the application:

1. Adjust — Maximize the impact of your mobile marketing!
2. AppsFlyer — Attribute every app install to a marketing campaign and media source!
3. Internal tracker located by the https://f-log-mobile-ios.grammarly.io address

Also, worth to mention that NSAllowsArbitraryLoads is disabled for the application. This is good, at least there is no way to send the data to additional third-party services, etc. According to the documentation:

A Boolean value indicating whether App Transport Security restrictions are disabled for all network connections. Disabling ATS means that unsecured HTTP connections are allowed.

Grammarly Custom Keyboard

There is a helpful guide from Apple about custom keyboards — Designing for User Trust:

For keyboards, the following three areas are especially important for establishing and maintaining user trust:

- Safety of keystroke data. Users want their keystrokes to go to the document or text field they’re typing into, and not to be archived on a server or used for purposes that are not obvious to them.

- Appropriate and minimized use of other user data. If your keyboard employs other user data, such as from Location Services or the Address Book database, the burden is on you to explain and demonstrate the benefit to your users.

- Accuracy. Accuracy in converting input events to text is not a privacy issue per se but it impacts trust: With every word typed, users see the accuracy of your code.

To design for trust, first consider whether to request open access. Although open access makes many things possible for a custom keyboard, it also increases your responsibilities.

And the Grammarly iOS Keyboard uses the Open Access by default. To demonstrate the difference, this is a comparison with significant capabilities and restrictions for both modes:

Open access off (default)

• No shared container with containing app
• No access to file system apart from keyboard’s own container
• No ability to participate directly or indirectly in iCloud, Game Center, or In-App Purchase

Open access on

• Keyboard can access Location Services and Address Book, with user permission
• Keyboard and containing app can employ a shared container
• Keyboard can send keystrokes and other input events for server-side processing

So, the Grammarly iOS application has access to a lot of things. And what is more important, is able to send keystrokes to the server.

Network requests

To illustrate the situation with trackers and the Open Access, let’s check which requests are initiated when the Grammarly iOS Keyboard is enabled on your iOS device.

When you open the Spotlight and Grammarly is the default keyboard, you see the following sequence of requests:

https://f-log-mobile-ios.grammarly.io
https://gnar.grammarly.com
https://data.grammarly.com
https://f-log-mobile-ios.grammarly.io
https://t.appsflyer.com

All the requests made with the GRKeyboardExtension/1.9.2.3 CFNetwork/1185.2 Darwin/20.0.0 user-agent. Also, all the end-points use Certificate Pinning, so, there is no easy way to check the body of the requests. But it is not the point for the article.

To illustrate the point, I recorded a video with network activity. Main takeaways are:

• Connections to https://gnar.grammarly.com and https://f-log-mobile-ios.grammarly.com are active all the way when you use the keyboard
• It seems that all the actions (when you select a word to fix) are sent to Adjust

And yes, the sequence is the same for Safari when you fill in credentials, etc. But do not worry, Apple does not allow to use custom keyboards to fill in passwords. Though, for usernames, phones, emails, etc. Grammarly sends the requests above.

Grammarly Privacy Policy

Privacy Policy | Grammarly states that:

1. We do not and will not sell your information. We don’t help companies advertise their products to you.
2. We use a small number of trusted third parties to help provide our products.

But on the other hand, there is a Does Grammarly share my Information? section that states:

We only disclose Personal Data to third parties when we have your explicit consent to share your Personal Data.

Standard words, usual phrases. I am not a specialist in this field, but I did not find an option to opt-out in the mobile application.

Conclusions

To be clear, I do not think that Grammarly steals your passwords, selling the data, trying to spy on sensitive information intentionally. I am a user of their services for two years and will continue to use it. With one exception — no more Grammarly iOS Keyboard application on my iOS devices. This is too much.

Software I used

• nm tool — lists the symbols from object files
• otool — displays specified parts of object files or libraries
• ProxyMan — Modern and Delightful Web Debugging Proxy

Checked by Grammarly

Originally published at https://justsitandgrin.net.

xed is a command-line tool that launches the Xcode application and opens the given documents ( xcodeproj, xcworkspace, etc.), or opens a new document, optionally with the contents of standard input.

If you work from the command line, this tool is a better option than open (which can open Xcode projects as well). Why?

• xed knows about the current selected Xcode version (open behaves unpredictably if you have multiple Xcode installed)
• You can use it open all files from a specific commit (with a little help explained below). It is useful on code-reviews or when you want to explore significant changes in the repository
• You can use it as a “quick open” helper. Helps with monorepo phenomena, when you have hundreds of projects in the repository (I will show you an example below)

Note about the current selected Xcode version

The current selected Xcode is controlled by xcode-select tool. You can check the current selected version with xcode-select -p (or xcode-select --print-path) and change it with sudo xcode-select -s PATH_TO_XCODE (or sudo xcode-select --switch PATH_TO_XCODE).

Tips & Tricks: There is a trick to get the current selected Xcode version without the tool. But your command line has to have full disk access. In some cases, it can be useful, but I recommend to use xcode-select if you have no additional requirements. To check the current selected Xcode version without xcode-select, execute the following command:

$ readlink /private/var/db/xcode_select_link
/Volumes/Extended/Archive/Xcode_11.5.app/Contents/Developer

Base commands

xed --launch
# or
xed -x

Launches the current selected Xcode.

xed Client.xcodeproj
# or
xed Client.xcworkspace

Will open the project with the current selected Xcode and terminate (the process that invoked xed remains in control).

xed SourceFile.swift AnotherExample.swift

Will open the files. There are two possible outcomes:

• Xcode will navigate to these file within the project if the project that contains these files is already opened
• Xcode will open the files as separate units

There are more options, like --wait or --line. Please, consult the man page for xed.

Tips & Tricks: If you are browsing this article on macOS, you can open the x-man-page://xed link, and it will show you the man page for the command in Terminal.app. There is a special scheme — x-man-page - than can open man pages for any available commands on macOS.

Open all files with changes

You can browse the git history directly in Xcode, and this is a convenient way to navigate the history. But I am not too fond of the Xcode Code Review tool because of the layout (when they show the original source and the version side-by-side), and there is no option to open all the files in the editor. Sometimes it is useful to open all files changed by the commit as regular source files and navigate them one by one.

To do so, you need a hash of the commit you want to browse. The following command will list all the files in the commit and open them in Xcode:

xed $(git diff-tree --no-commit-id --name-only -r COMMIT_HASH)

You can use the command as an alias for your Bash or zsh configurations.

Note: if the Xcode project for these files is already opened then Xcode will open them in the context of the project. Otherwise, it will open each file in a separate window.

Quick search and open projects

You need a quick way to search and open projects when you have hundreds of them in your git repository. In my case, I work with two monorepos daily, and I have a significant number of different projects in my “projects” folder. To be able to navigate and open them as quickly as possible, I developed a script that scans the current folder for all .xcodeproj files, produces a list of them according to the provided search term and then open a specific project with the xed tool.

Let’s take the Firefox iOS project as a simple example. The project contains 65 .xcodeproj files in the repository (most of them are third-party Carthage dependencies). Imagine that I work with the repository every day and have to switch between these projects (check demos, run tests, apply fixes, etc.). To help myself, I am using the following script:

The script will produce the full list of projects when you run it in the Firefox iOS project and ask you to provide a number to select a project to open:

$ sh pxed.sh
...
60) ./Carthage/Checkouts/sentry-cocoa/Sentry.xcodeproj
61) ./Carthage/Checkouts/swift-protobuf/SwiftProtobuf.xcodeproj
62) ./Carthage/Checkouts/telemetry-ios/Telemetry.xcodeproj
63) ./Client.xcodeproj
64) ./FxA/FxA.xcodeproj
65) ./ThirdParty/Deferred/Deferred.xcodeproj
#?

If you run it with a search term, “demo” for example, the list will be limited to projects with the keyword in the name:

$ sh pxed.sh demo
Collecting .xcodeproj...
Please select a project:
1) ./Carthage/Checkouts/Fuzi/FuziDemo/FuziDemo.xcodeproj
2) ./Carthage/Checkouts/SDWebImage/Examples/SDWebImage Demo.xcodeproj
3) ./Carthage/Checkouts/XCGLogger/DemoApps/iOSDemo/iOSDemo.xcodeproj
4) ./Carthage/Checkouts/XCGLogger/DemoApps/macOSDemo/macOSDemo.xcodeproj
5) ./Carthage/Checkouts/XCGLogger/DemoApps/tvOSDemo/tvOSDemo.xcodeproj
6) ./Carthage/Checkouts/onepassword-app-extension/Demos/App Demo for iOS Swift/App Demo for iOS Swift.xcodeproj
7) ./Carthage/Checkouts/onepassword-app-extension/Demos/App Demo for iOS/App Demo for iOS.xcodeproj
8) ./Carthage/Checkouts/onepassword-app-extension/Demos/WebView Demo for iOS Swift/WebView Demo for iOS Swift.xcodeproj
9) ./Carthage/Checkouts/onepassword-app-extension/Demos/WebView Demo for iOS/WebView Demo for iOS.xcodeproj
#?

And, finally, the script will open the project straight away if there is only one search result for the keyword:

$ sh pxed.sh sent
Collecting .xcodeproj...
Opening ./Carthage/Checkouts/sentry-cocoa/Sentry.xcodeproj...

Thanks for reading

Let me know if you have questions or want to discuss something. Feel free to comment the script on GitHub as well.

Originally published at https://justsitandgrin.net.

Overview

I am a bit late to the party, but still. Robert C. Martin, colloquially known as “Uncle Bob”, gave an exciting talk in May 2016 about the future of programming. The relevance of his words still stands, and it is a beautiful history lesson about software engineering, programming as a profession with remarks about Agile and possible future of the industry.

Below you will find main topics from this talk that captured my attention, links to the facts, articles and papers he mentioned; plus, my personal opinion on some of them. Still, the best course of action is to watch the talk itself.

Objective C history

In the beginning, Robert briefly mentions his version of the Objective C history in early ’90s. From his point of view, Objective C had to die at that point because, in general, C++ was a better evolution of ANSI C and both languages competed on the same field. But a series of circumstances saved Objective C. Steve Jobs was forced out from Apple in 1985 and founded NeXT, Inc to compete with Apple. There were not many programmers available on the market, but Objective C specialists experienced some problems finding new jobs. As Robert said:

There were a bunch of guys on the street holding up signs “We will code Objective C for food.”

– Robert C. Martin

NeXT hired them, and all these programmers produced the NeXTSTEP operating system. Within a few years, Apple announced that it would buy NeXT for $427 million, bringing Jobs back to the company. And Steve brought all the NeXT team along including all Objective C programmers. NeXTSTEP OS was part of the deal as well. It was the team that started to work on the iPod prototype and, as you can imagine, Objective C was the primary language. So, in short, that is how Objective C was resurrected from the dead. Or saved.

Alan Turing

During the talk, Robert references Alan Turing a lot. Probably, the first person actually to write code that we can recognise as code, Robert said. In his works, Alan Turing defined variables, subroutines, floating-point principles, many things we use every day as programmers.

There is a remarkable paper from Alan Turing, “On computable numbers, with an application to the Entscheidungsproblem” (November 1936) that set the limits of computer science. It defined the Turing Machine, a model for all computations. On the other hand, it proved the undecidability of the halting problem and Entscheidungsproblem and by doing so, found the limits of possible computation.

If you want to learn more about the guy, I highly recommend “The Annotated Turing” book from Charles Petzold (the guy behind Microsoft Foundation Class Library (MFC) and former software engineer) that Robert mentions in the talk as well.

Robert says a lot about programming discipline and why it was supposed to be based on the shoulders of mathematicians. In his opinion, there are many problems with mentoring new programmers and lack of fundamental knowledge. This topic is a bit controversial but the funny is thing that Alan Turing predicted the problem after writing “a few hundreds of lines of code” more than 70 years ago:

“One of our difficulties will be the maintenance of appropriate discipline so that we do not lose track of what we are doing.”

– Alan Turing, Lecture to the London Mathematieal Society on 20 February 1947

A quick note about GOTO statement and what not to do

At the pre-ALGOL meeting held in 1959, Heinz Zemanek explicitly threw doubt on the necessity for GOTO statements; at the time no one paid attention to his remark, including Edsger W. Dijkstra, who later became the iconic opponent of GOTO. The 1970s and 1980s saw a decline in the use of GOTO statements in favour of the “structured programming” paradigm, with goto criticized as leading to “unmaintainable spaghetti code”.

– Wikipedia, GOTO

So, in 1968, Edsger W. Dijkstra wrote his quite famous “Go To Statement Considered Harmful” article. And it was one of the first examples of programmers starting to improve the technology and the discipline itself. I mention this fact as an example because I agree with Robert on his thoughts:

“What we have learned since the ’70s is more on what not to do than what to do.”

“If we have made any advances in software, since 1945, it is almost entirely in what not to do. Structured Programming was in what not to do — don’t use unrestrained GOTO. Functional Programming — don’t use assignment. Object-Oriented Programming — don’t use pointers to functions. What we have learned over the last 70-some years is more about what not to do, than what to do. There have been no radical advances in software technology. The craft of writing software remains roughly the same as it was in 1945 — a little more modern, but not essentially any different.”

– Robert C. Martin

See? Almost all modern paradigms were built on top of the “not to do” practices. From Robert’s point of view, we are more or less capable of agreeing on bad things but it is tough for us to agree on something new and go in the same direction, and this is one of the biggest challenges we have with the discipline:

“We have a problem: we do not agree on our own technical disciplines.”

– Robert C. Martin

We know a lot about which things to avoid, hundreds of bad practices and anti-patterns. But, on the other hand, there are too few general principles to follow. We are learning and creating new languages to solve specific problems, dancing with generics on top of the generics, copy-pasting templates and consuming articles about syntax sugar as best development practices. But fundamentally, since the ’70s, not many things have changed in software itself. In the end, your program will operate with if statements, assignments and while loops.

“You would recognise the code that Alan Turing wrote on the ACE machine. You would not like it, but you would recognise it.”

– Robert C. Martin

What happened to the discipline

It is quite interesting to listen to the guy who experienced all the changes in the discipline during all these years. For example, Robert stated that back in the ’60–70s the situation with programmers looked like this:

- Up to now programmers were disciplined professionals;

- They did not need a lot of management or process;

- They knew how to manage their time, communicate, and work together;

- They understood deadlines & commitments. What to leave in and what to leave out.

– Robert C. Martin

At that time, with the principles mentioned above, programmers built great software. Or, as Robert said, “They knew how to get big things done”:

• IBM 360 Virtual Memory OS — the first family of computers designed to cover the complete range of applications, from small to large, both commercial and scientific;
• NASA Project Mercury — the United States’ first man-in-space program;
• NASA Project Gemini — second human spaceflight program;
• NASA Project Apollo — human spaceflight program which succeeded in landing the first humans on the Moon from 1969 to 1972;
• Structured, Functional, Object-Oriented paradigms;
• Fortran, Cobol, Algol, Lisp, C, Unix;
• And many more.

I want to mention Margaret Hamilton — director of the Software Engineering Division of the MIT Instrumentation Laboratory, which developed on-board flight software for NASA’s Apollo program.

And, at this point, let’s talk a little about Agile.

Agile manifesto

In 2001, these seventeen software developers met at a resort in Snowbird, Utah to discuss lightweight development methods: Kent Beck, Ward Cunningham, Dave Thomas, Jeff Sutherland, Ken Schwaber, Jim Highsmith, Alistair Cockburn, Robert C. Martin, Mike Beedle, Arie van Bennekum, Martin Fowler, James Grenning, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, and Steve Mellor. Together they published the Manifesto for Agile Software Development.

– Wikipedia, The Manifesto for Agile Software Development

Note: By lightweight development methods they assumed rapid application development (RAD), from 1991; the unified process (UP) and dynamic systems development method (DSDM), both from 1994; Scrum, from 1995; Crystal Clear and extreme programming (XP), both from 1996; and feature-driven development, from 1997.

So, Robert was part of the group behind the manifesto, and his explanation fits well with my mind. Programmers were not just operators anymore, and they needed to be part of the whole process of creation. And Agile is about all the promises you make and not a list of tasks you follow. This perception has faded in the modern world, and Robert assumes that it happened when business got in the way. The business was totally in line with what the Agile movement offered, the whole set of principles made sense to them, and they understood discipline. However, the business started to take control of some of the engineering practices, and Agile helped them. In worst cases, programmers have to discuss technical debt, refactoring and technologies with the business and ask for permissions to control simple engineering things. The issue is that business does not always understand (and, frankly, should not) what programmers are doing. So, once project managers took control over Agile (via Scrum, for example), it became less technical. Ironically, one of Agile’s goals was to “heal the divide between business and programming” (Kent Beck).

Robert believes that Agile has failed and that things have to change. Again. Programmers have to step up and define their profession, their practices, and the discipline they use because they are the ones who have the expertise to do so. Programmers have to handle technical risks and take these risks as professionals.

There is a helpful article from Martin Fowler — Flaccid Scrum about more or less the same matters.

“The Scrum community needs to redouble its efforts to ensure that people understand the importance of strong technical practices. … If you’re looking to introduce Scrum, make sure you pay good attention to technical practices. We tend to apply many of those from Extreme Programming, and they fit just fine. XPers often joke, with some justification, that Scrum is just XP without the technical practices that make it work.”

– Martin Fowler

I can recognise a lot of failed/struggled projects from my experience in the way Robert describes the phenomena:

“Flaccid Scrum — an efficient business discipline coupled to an undisciplined engineering team, will very rapidly make a mess.”

– Robert C. Martin

Also, an interesting point was made about the fact that Agile is in line with Alan Turing’s thoughts on the future of the profession. Turing said that discipline and ability are essential parts of the prosperous future, and Agile declares that discipline, craftsmanship and professionalism are the directions to go.

Historical references

These are links to some hardware, software and events mentioned in the talk.

• Automatic Computing Engine (ACE) — a British early electronic stored-program computer designed by Alan Turing;
• Delay Line Memory (Mercury delay lines) — a form of computer memory that was used on some of the earliest digital computers;
• Cathode-Ray Tube — have been used as memory devices known as Williams tube;
• Lisp — the second-oldest high-level programming language in widespread use today that refuses to die;
• Simula 67 — considered the first object-oriented programming language;

Bottom line

Professionalism. Discipline. Attention to details.

These are the base principles for better programmers. It sounds easy and obvious. Why not to try?

P.S.

Sadly, this talk heavily foreshadows the situation with Boeing 737 Max.

Originally posted here.

Historical reference

According to Wikipedia, Emoji are ideograms and smileys used in electronic messages and web pages. Emoji exist in various genres, including facial expressions, common objects, places and types of weather, and animals. They are much like emoticons, but emoji are actual pictures instead of typographic. Originally meaning pictograph, the word emoji comes from Japanese e (絵, “picture”) + moji (文字, “character”); the resemblance to the English words emotion and emoticon is purely coincidental.

From 2010 onward, some emoji character sets have been incorporated into Unicode, a standard system for indexing characters, which has allowed them to be standardised across different operating systems.

I recommend you to read the “The modern emoji” section on Wikipedia. There are a lot of interesting facts about the standard, like:

Some Apple emoji are very similar to the SoftBank standard, since SoftBank was the first Japanese network the iPhone launched on. For example, U+1F483 💃 DANCER is female on Apple and SoftBank standards but male or gender-neutral on others.

How does the comparison work

It is tricky to convince iOS to tell you the truth about all the available emojis. To solve the problem, I took a shortcut and decided to use emojis from the Unicode standard. The current revision is UTS #51 Unicode Emoji, Version 12.1. There are some files with examples, and for testing purposes, emoji-test.txt looked like a complete set of all variants. So, I built a simple tool to generate images from all available emojis and compare them with a simple diff. You can read more about the process and check the implementation on GitHub - dive/emojis-over-time.

Notes

To avoid unnecessary noise, I use the following limitations for the comparison:

• Ignore all variations for skin tones (can be enabled in the tool);
• Skip all unqualified & minimally-qualified emojis from the standard (check the emoji-test.txt for explanation). Can be enabled in the tool as well.

Comparison

As I said, I generated all emojis for iOS 13.0–13.3, removed all emojis without any changes and then build diffs for the remaining characters. All comparisons were made retrospectively, means that I compare iOS 13.0 with 13.1, 13.1 with 13.2, etc.

All images follow the same pattern:

• The initial version is on the left side (e.g., for iOS 13.0 in the first example below);
• An updated version is in the middle (e.g., for iOS 13.1);
• Diff on the right.

iOS 13.0 → 13.1

Anti-aliasing

The most obvious difference is the fact that they change a bit how they render the final images. It seems that they improved anti-aliasing to make image borders more contrast and visible on the screen (especially, on dark backgrounds. Maybe, it is just a pending improvement for the dark mode). Check these light borders on the diff image.

Also, pay attention to the glare in the eyes. For some reason, it was decided to change their shape from round to semicircle.

The shape of the heart

The shape of the heart symbol was re-designed. It became more elongated in height, and they added a gradient.

Malaysia flag

Apple made a mistake in iOS 13.1, the flag of Malaysia was re-implemented with obvious errors (“Apple displays Malaysia flag emoji incorrectly on iOS 13.1 and 13.1.1”).

Mermaid

This is my favourite change. The mermaid now holds a trident like a merman counterpart. Also, they changed a bit the shape of her hair.

Hedgehog

The baseline for the hedgehog was slightly lowered. Apparently, that it fits better into the text.

Octopus

The octopus now has suckers on tentacles.

Squid

Previously, the squid emoji had some issues with the real-life, and The Monterey Bay Aquariums noticed it. Now it is fixed.

And that’s all for iOS 13.1.

iOS 13.1 → 13.2

Gender-neutral fashion

This is a new world to me and I was surprised by the diffs for iOS 13.2, but then I realised that it is somehow related to the gender. So, with iOS 13.2 all emojis without a specific gender in the description are gender-neutral. Let’s see how they look.

Noticeable and frequent changes:

• Haircuts were changed to the neutral style;
• Colours are more indifferent to avoid associations;
• Everyone began to wear clothes, and there is no more naked torso.

P.S. Check the “Unicode Brings Forward Gender Neutral Timeline” blog post from Emojipedia if you want to know more.

P.P.S. As before, iOS 13.1 emoji is on the left, iOS 13.2 in the middle, the diff is on the right side.

Malaysia flag

The flag of Malaysia now correctly displays a red stripe.

Ear

The ear emoji has been re-designed to appear more like the ear.

Hair colour

Blond hair now has realistic colour.

There are no changes in emojis between iOS 13.2 and iOS 13.3 releases. So, our journey ends here.

There is no practical benefit in the article, just my curiosity and desire to know more about the world around me. Anyway, I am surprised that companies like Apple pay a lot of attention to the Emoji world; also, I am impressed by the number of details in emojis and how they develop over time. Will follow the topic as a hobby.

Originally posted here. Follow me on Twitter!

How emojis evolve over time was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

Swift Package Manager builds iOS frameworks

(Updated. Xcode 10.2 Beta)

Swift Package Manager doesn’t work with iOS. That’s probably all you can say about the current state of SPM, but insomnia forced me to expand on the issue and compile the following essay.

TL;DR

• Yes, you can build iOS frameworks with Swift Package Manager;
• Yes, you can adjust settings via .xcconfig and reuse generated .xcodeproj in a real iOS application without 3rd party tools to parse a project structure, scripts on Ruby, etc.;
• Yes, you can use swift build to build your package but only as a library (but with some additional limitations);
• No, you cannot use swift test because you have to spawn a simulator to run them.

Current State of Swift Package Manager

iOS support is a hot topic in the Swift Package Manager community, and from time to time someone raises this same question again but the following comments sum up the community’s reactions (full thread on forums.swift.org):

@Rick Ballard
I think that this will be best provided by native IDE integration. However, in the meantime, I’d welcome contributions to help improve Xcode’s project generation support.

@Adrian Kashivskyy
The last thing I want from a platform-agnostic open-source package manager is built-in integration with a single-platform commercial closed-source IDE. :confused: I think this should be done independently by the DT team, without any special favouritism by SPM.

And you know what? I agree with these statements. Especially after some research. In general, SPM is a very ‘young’ and inflexible project. There are a lot of limitations, especially around generate-xcodeproj options of the swift package tool. And this is understandable given that Swift is a language, and all related tools need to be platform-agnostic as far as possible. Yeah, iOS is the biggest Swift consumer, and Apple contributes to Swift mostly because of iOS, but…

It’s going to be almost impossible to grow Swift into a mature technology if you’re limited and restricted by Xcode / iOS specific things / etc. And, it seems, this is the primary goal for Swift to remain just be a language. The fate of Objective C is a good example of why the Apple and Swift’s communities are trying to be agnostic. They are trying to build something big, and lack of iOS support is the price (among many others) at the moment. :kiss:

Having said this, we have exciting news about SPM and iOS friendship. SE-0236: Package Manager Platform Deployment Settings is accepted with some modifications. And the implementation of this proposal will help a lot to move forward in the case of iOS. The main goal is clear and straightforward:

Packages should be able to declare the minimum required platform deployment target version. SwiftPM currently uses a hardcoded value for the macOS deployment target. This creates friction for packages which want to use APIs that were introduced after the hardcoded deployment target version.

Why will it completely fail to solve the problem with iOS? Just read the “This option doesn’t resolve these problems” section.

Xcode 10.2 Beta

SE-0236 was accepted and implemented in Swift 5, and Apple shipped it with the latest Xcode 10.2 beta. This means that you can specify an iOS as a deployment target for your packages with a simple line in your Package.swift file:

See an example in xcode_10_2_beta branch in the example repository. It is still a beta implementation, and you will have a lot of issues with build command, and run doesn’t work either, but it is a step toward eventual iOS support.

I hope that Apple will announce something good at WWDC’19. A new IDE for Swift, perhaps? Or open-sourced xcodebuild? Or xcodebuild replacement based on llbuild? We’ll see. The current state is as complicated as it can be. We are trying to inject open-sourced platform-agnostic tools into a legacy (?) world of Xcode, and this problem can only be solved in one of two ways: either iOS specific build tools go open source, or Xcode team supports Swift infrastructure.

Is it possible to build an iOS framework with SPM? Yes! Absolutely!

Search for solutions for building iOS frameworks with SPM on DuckDuckGo and you will find some instructions (1, 2). But all of them have this one step that I hate: sudo gem install xcodeproj :disgusting:. Can we do any better? Let’s give it a try.

First of all, let’s generate a template:

Now we have to convince SPM that we want an iOS project when it generates xcodeproj. How? With xcconfig, of course. Create a file ios.xcconfig and add it to ./Sources folder. For example, let’s start with a basic version:

Looks good. Let’s see what SPM thinks of it:

Didn’t know about xcconfig-overrides? Me neither. It’s a hidden and undocumented feature (commit), thanks to @Daniel Dunbar! Time to ask Xcode what it thinks of it.

Note: You do not have to specify a custom .xcconfig file if you are using Xcode 10.2 Beta with Swift 5 Toolchain. Check the branch for more details.

It works! Let’s celebrate! But nope. We’re not there yet, need to dig deeper. Let’s check how the ‘Unit Tests’ target works, for example:

It doesn’t. Due to this strange and suspicious XCTestCaseEntry. What is this? According to the swift-corelibs-xctest source code:

This is a compound type used by XCTMain to show tests to run. It combines an XCTestCase subclass type with the list of test case methods to invoke on the class.

And the typealias looks like this:

Why doesn’t it work? For the same reason:

CoreLibs XCTest only supports desktop platforms

Thanks go to @larryonoff for his work on multi-platform support. But unfortunately we still can’t use it for our needs. Join this Add Unit Testing Infrastructure thread if you want to learn more about the current state of swift-corelibs-xctest. We will move on and apply the fix to XCTestManifests.swift:

See this && !os(iOS)? Let’s keep going. Run Tests again and… We got what we need.

Then I created a simple iOS ExampleApp and added the generated xcodeproj as a dependency. Of course, I’ve added some iOS specific code to the framework:

And then reuse it from the example app:

The full example is available on GitHub. Thanks to CLANG_MODULES_AUTOLINK, all iOS frameworks will be linked automatically. I didn’t try more complex scenarios (where one iOS module depends on another, etc.) because it’s not my goal here. But, in general, it does just work albeit some limitations. SPM doesn’t set up our xcconfig for some targets, and you have to include the SPM-generated .xcodeproj to your .xcodeproj, but all these tradeoffs seem reasonable in the interests of this research and achieving our current goal.

Back to Swift Package Manager

See. We can do better 🥳. But we forgot about SPM during this Xcode journey. Let’s close our fancy, dark-themed Xcode, open Terminal and run swift build for our iOS’ish package (I’m going to use the package from the example project mentioned above):

Okay. There’s no such ‘UIKit’ module. Can we do better? I doubt it, but let’s try. First of all, we have to find out where SPM gets all these environment variables from. We can ask it with swift build — verbose:

Nice. No smoke or mirrors. Let’s try to changing some swiftc options to build the project against proper sdk and target:

Looks better. We built the binary:

Let’s carry out some inspections, just to make sure that everything is OK:

lipo is a bit useless in this case because we were building for a simulator, but nm shows us everything we need to know — iOS frameworks symbols are available. Unfortunately, swift build doesn’t produce .framework by default. I think it’s doable even in this case but let’s look at that ‘next time’.

Epilogue: swift test

And the final call. We already have one unit-test for our package: it uses UIKit, and I would rate this experiment as successful if we could run the test target with swift test. It’s almost impossible though, because usually unit-tests for simulator have to spawn to a simulator process. I don’t even think that it’s possible for an actual iOS project. Anyway.

And there’s another problem. .xctest bundle is compiled but xctest tool gets confused with search paths:

Likely, swift build & test produce beneficial debug information and store it in .build/debug.yaml with all previous options and arguments. This goes for the options for a module itself as well, so it’s time for our command line friends again:

As you can see, for some reasons, it tries to link UIKit.framework twice:

• via the /System/Library/Frameworks path
• and via the expected @rpath/libswiftUIKit.dylib.

Let’s check the information from the module itself with otool, to be sure that load is describing the correct framework to link:

Seems correct to me. So, to eliminate the confusion let’s pass the linking option directly with -Xswiftc “-lswiftUIKit”:

Yep, but built for simulator (not macOS)). This is my final conclusion, my friend. It doesn’t take that much effort to link proper frameworks, but it’s impossible to run these tests for iOS device or simulator without SPM support. It seems that not even xcrun with xctest are up to the job. xcodebuild assistance is needed here. But enough of these weird logs and useless rants, let’s summarise.

Summary

Thanks for reading, first of all! So, what did we learn?

• We can use SPM in sporadic cases for iOS, just for integration, thanks to .xcconfig;
• The future of the friendship between iOS and SPM is unsure even with this SE-0236 proposal;
• Swift build and test helpers are useless to us without iOS-specific features and full Xcode support. And that’s unlikely to happen. Of course, SPM can be integrated on top of Xcode by Xcode team. For example, they will extend xcodebuild functionality. But concerning SPM, it is going to be a different story.

Regarding SPM. Generally, I think it’s doable, and we can improve SPM to support any platform you like. My best advice at the moment is to introduce pipeline plugins for SPM, enabling you to transfer the control flow to a separate tool, with expected input and output. Something like Xcode custom build phases but is smarter and more flexible. It will allow SPM to be platform-agnostic as now, but the Xcode team can create a plugin for the whole iOS flow support. Or Uber. Or Google. Or me. Whatever.

Stay tuned and hydrated!

Swift Package Manager builds iOS frameworks (Updated. Xcode 10.2 Beta) was originally published in Bumble Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

New betas are here and these are some of the most important things that I have learned about them.

Swift 5 for Xcode 10.2 beta

Swift

Firstly, the latest Xcode beta is bundled with the following Swift version:

Apple Swift version 5.0 (swiftlang-1001.0.45.7 clang-1001.0.37.7)
Target: x86_64-apple-darwin18.2.0
ABI version: 0.6

Let’s start with the most exciting news:

Swift apps no longer include dynamically linked libraries for the Swift standard library and Swift SDK overlays in build variants for devices running iOS 12.2, watchOS 5.2, and tvOS 12.2. As a result, Swift apps can be smaller when deployed for testing using TestFlight, or when thinning an app archive for local development distribution.

Application Binary Interface stability is coming! And this is excellent news. I think this is the one of the most significant issues at the moment with Swift. Not because of side-effects but because of Swift’s failure to deliver on previous promises. Anyway, I even know people who rewrite their Apple Watch extensions to Objective C to reduce the size of binary (something like 15MB vs ~1MB in Objective C). If you want to know more about the state of ABI, follow the links: Swift — ABI Dashboard and Swift ABI Stability Manifesto.

The @dynamicCallable attribute lets you call named types like you call functions using a simple syntactic sugar. The primary use case is dynamic language interoperability. (SE-0216)

Example:

@dynamicCallable struct ToyCallable {
 func dynamicallyCall(withArguments: [Int]) {}
 func dynamicallyCall(withKeywordArguments: KeyValuePairs<String, Int>) {}
}

let x = ToyCallable()

x(1, 2, 3)
// Desugars to `x.dynamicallyCall(withArguments: [1, 2, 3])`

x(label: 1, 2)
// Desugars to `x.dynamicallyCall(withKeywordArguments: [“label”: 1, “”: 2])

This is a huge topic and I have mixed feelings about the feature. So, do read the “What’s new in Swift 5.0” post from Paul Hudson if you want to know more about what is coming.

Swift 3 mode has been removed. Supported values for the -swift-version flag are 4, 4.2, and 5.

The time has come. Source compatibility with Swift 3 is no more. It was expected and announced with Swift 5 Roadmap, but still. I highly recommend that you refresh your memory with “Swift 5.0 Release Process” because Swift 5 is almost here. Get ready.

In Swift 5 mode, switches over enumerations that are declared in Objective-C or that come from system frameworks are required to handle unknown cases — cases that might be added in the future, or that may be defined privately in an Objective-C implementation file. Formally, Objective-C allows storing any value in an enumeration providing it fits in the underlying type.
These unknown cases can be handled by using the new @unknown default case, which still provides warnings if any known cases are omitted from the switch. They can also be handled using a normal default case.

If you’ve defined your own enumeration in Objective-C and you don’t need clients to handle unknown cases, you can use the NS_CLOSED_ENUM macro instead of NS_ENUM. The Swift compiler recognises this and doesn’t require switches to have a default case.

In Swift 4 and 4.2 modes, you can still use @unknown default. If you omit it, and an unknown value is passed into the switch, the program traps at runtime, as does Swift 4.2 in Xcode 10.1. (SE-0192)

It was, and is, a pain especially if you use no default approach within switches. I remember the ugly workarounds for the new .provisional option of UNAuthorizationOptions property that was introduced in iOS 12. Now, with an unknown case it’s much easier to handle such scenarios.

Swift Package Manager

Packages can now customise the minimum deployment target setting for Apple platforms when using the Swift 5 Package.swift tools-version. Building a package emits an error if any of the package dependencies of the package specify a minimum deployment target greater than the package’s own minimum deployment target. (SE-0236)

The most important news for me concerns Swift Package Manager. Technically, this change can solve a lot of issues that prevent SPM to be useful in the iOS world. In my previous article “Swift Package Manager builds iOS frameworks” I tried to analyse the current state of SPM in the context of iOS development. And now it seems that I’m going to have to reevaluate my thoughts and conclusions.

There are some bad issues as well:

Some projects might experience compile time regressions from previous releases;

Swift command line projects crash on launch with “dyld: Library not loaded” errors.
Workaround: Add a user-defined build setting SWIFT_FORCE_STATIC_LINK_STDLIB=YES.

A lot of issues have been resolved and as well as other points in the changelog related to Swift 5, but they are specific to what you do. Check them, maybe you want to use inherit designated initialisers with variadic parameters, or you were blocked by the deadlock problem due to complex recursive type definitions involving classes and generics, or you are struggling with generic type alias within a @objc method.

Xcode 10.2 beta

Apple Clang Compiler

There are a lot of new warnings for Apple Clang Compiler. And most of them are related to frameworks and modules. It’s quite interesting because it can be associated with Swift Package Manager integration as a dependency tool. The most important ones, in my opinion, are:

A new diagnostic identifies framework headers that use quote includes instead of framework style includes. The warning is off by default but you can enable it by passing -Wquoted-include-in-framework-header to clang;

Public headers in a framework might mistakenly #import or #include private headers, which causes layering violations and potential module cycles. There’s a new diagnostic that reports such violations. It’s OFF by default in clang and is controlled by the -Wframework-include-private-from-public flag;

The use of @import in framework headers prevent headers being used without modules. A new diagnostic detects the use of @import in framework headers when you pass the -fmodules flag. The diagnostic is OFF by default in clang and is controlled using the -Watimport-in-framework-header flag;

Previously, omitting the framework keyword when declaring a module for a framework didn’t affect compilation but it silently did the wrong thing. A new diagnostic, -Wincomplete-framework-module-declaration, and a new fix-it suggests adding the appropriate keyword. This warning is on by default when you pass the -fmodules flag to clang.

Firstly, how to turn them on: Goto to Build Settings for your application target, find “Apple Clang — Custom Compiler Flags” and put the desired flag to “Other C Flags”.

I tried to build an old, Objective C-based application and found a lot of issues with private headers in public framework headers:

And some issues with double-quoted imports within frameworks:

I recommend you run such diagnostics as well and, at least, create issues for your backlog. One day, all these problems will cause you a real headache.

Build System

There is also a nice, new Build System feature:

Implicit Dependencies now supports finding dependencies in Other Linker Flags for linked frameworks and libraries specified with -framework, -weak_framework, -reexport_framework, -lazy_framework, -weak-l, -reexport-l, -lazy-l, and -l.

It’s really interesting as well. In general, it means that you can define your implicit dependencies via .xcconfig or even with xcodebuild options and avoid these Link / Embed phases within Xcode.

Debugging

Debugging has got new features:

UIStackView properties are now presented in the view debugger object inspector;

The view debugger presents a more compact 3D layout.

Xcode can now automatically capture a memory graph, if a memory resource exception is encountered while debugging. To enable memory graph captures go to Diagnostics tab of the scheme’s run settings;

On iOS and watchOS, Xcode shows the memory limit for running apps in the Memory Report as you approach the limit;

See the red line? Watchdog sends applicationDidReceiveMemoryWarning(...) when you reach the edge. But I thought it would be more useful than it is, to be honest. For now, it just looks like a minor, nice improvement.

LLDB Debugger

And LLDB Debugger got some love as well:

You can now use $0, $1, … shorthands in LLDB expression evaluation inside closures;

The LLDB debugger has a new command alias, v, for the “frame variable” command to print variables in the current stack frame. Because it bypasses the expression evaluator, v can be a lot faster and should be preferred over p or po.

I haven’t noticed any performance improvements, but v produces a better output in some cases although it’s not a replacement for po in general, it’s only for the current stack frame with some limitations. See the examples below.

Playgrounds

My favourite section? Playgrounds! Let’s start with known issues:

Playgrounds might not execute! 😭

Unfortunately, this is the only news concerning Playgrounds in the current beta.

Simulator

Some notes about Simulator:

Siri doesn’t work in watchOS and iOS simulators;

Pasteboard synchronisation between macOS and simulated iOS devices is more reliable;

I really hope it is.

You’re now only prompted once to authorise microphone access to all simulator devices.

This is a nice improvement because many people get issues with CI and build agents due to this problem. Now a workaround can be automated or, at least, we can update our guides to set up build agents with “Run a simulator once” step.

Testing

xccov supports merging multiple coverage reports — and their associated archives — together into an aggregate report and archive. When merging reports, the aggregate report may be inaccurate for source files that changed since the time the original reports were generated. If there have been no source changes, the aggregate report and archive will be accurate;

xccov now supports diffing Xcode coverage reports, which can be used to calculate coverage changes over time. For example, to diff the coverage reports before.xccovreport and after.xccovreport, invoke xccov as follows: xccov diff — json before.xccovreport after.xccovreport;

Static library and framework targets now appear in the coverage report as top-level entries, with line coverage values that are aggregated across all targets that include the static library or framework. This also resolves an issue where the source files for a static library or framework target would be included in the coverage report even if the target itself was excluded from code coverage in the scheme.

These changes are excellent news for Continuous Integration. Especially differing. Let your release engineering team know and anyone else responsible for such things.

However, there are some limitations related to testing parallelisation:

Recording doesn’t work from Clones when Parallelisation is on;

Profiling tests don’t behave correctly when test parallelisation is enabled;

There are also some promising bug fixes:

If testing fails due to the test runner crashing on launch, Xcode attempts to generate a rich error message describing the failure. This failure is present in the test activity log and appears in stdout if you’re using xcodebuild. The error is also present in the structured logs contained in the result bundle.

We get a lot of such issues, and usually, it’s not clear at all what is happening. Sometimes, it’s related to incorrect linking, sometimes to system overload. It should help to reduce flakiness.

Crash reports collected during testing no longer omit important fields such as the termination reason and description.

No comment just 😘 and 🥰.

And the last point about Xcode, useful for companies with a lot of developers, Xcode now supports macOS content caching service. This means that you can have a caching server with Xcode application in your local network.

Issues

I encounterd some problems with the beta. Mostly with third-party tools: Carthage, for example, which doesn’t work, with the following error:

Could not find any available simulators for iOS

I checked the available simulator, and it appears that something is broken in the current beta; it’s also impossible to download other runtimes from Xcode, the list of available simulators is just empty (a radar filled):

$ xcrun simctl list devices --json | grep -A16 12.1
    "com.apple.CoreSimulator.SimRuntime.iOS-12-1" : [
      {
        "availability" : "(unavailable, runtime profile not found)",
        "state" : "Shutdown",
        "isAvailable" : false,
        "name" : "iPhone 5s",
        "udid" : "DDD36346-A76F-42E8-80F4-6F11E1EE4BEB",
        "availabilityError" : "runtime profile not found"
      },
      {
        "availability" : "(unavailable, runtime profile not found)",
        "state" : "Shutdown",
        "isAvailable" : false,
        "name" : "iPhone 6",
        "udid" : "21794717-BC89-45E4-9F57-8CF9D14A87D1",
        "availabilityError" : "runtime profile not found"
      },
--

It is a beta, of course. And the changelog is enormous. Be patient and reasonable :)

P.S. Carthage already has a fix (#2691).

iOS 12.2 beta

Okay. It seems like they are polishing their tech-debt and applying security patches. Two things are broken:

You might be unable to authenticate within Wallet after selecting a card;

You might be unable to purchase a prepaid data plan using cellular data.

And Apple News will be available in Canada. Stay tuned.

macOS Mojave 10.14.4 beta

The only new thing here is a potential issue with Safari 12.1. After upgrading from Safari 10.1.2:

After updating to Safari 12.1 from Safari 10.1.2, web pages might not display.
Workaround: Run the following command in Terminal:
defaults delete com.apple.Safari

With the following consequences:

Warning: You will lose your previous Safari settings after running the command above.

Final cut

This article turned out to be much longer than I thought. Well, I did give you all my thoughts on all the sections above. A short version of the whole article is simply, ‘Swift 5 has arrived!’

Stay tuned and hydrated! And thanks for reading.

Xcode 10.2, macOS Mojave 10.14.4, iOS 12.1 and other betas was originally published in Bumble Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.