Like any other year the new Xcode GM came out and everybody started rushing to submit their apps. This year, I was also one of these early adopters. Things were going relatively smoothly, except for a weird issue with xattr when trying to export archives. Regardless, I uploaded the build and was ready to see it processed… And then…

The Problem

Invalid Bundle - Disallowed LLVM instrumentation. Do not submit apps with LLVM profiling instrumentation or coverage collection enabled. Turn off LLVM profiling or code coverage, rebuild your app and resubmit the app.

LLVM instrumentation? What? I thought that gets striped out on Archive?

Well it turns out, that it does get stripped out, but only for the main application. I use Carthage for dependency management and Carthage doesn’t build targets with the Archive action (or rather it can’t) and Xcode 9 enables code coverage by default:

The

Well it’s been awhile, but I’m back to doing my own projects again.

Prelude

So lately I’ve been feeling left out of the gaming world and thought to myself: “Hey why not build a sweet new gaming rig and jump right back into all of the fun?”. Well, knowing myself I knew that after playing a couple of games, I would get bored and this rig won’t see much use after that.

To counteract that I need to be able to do work on it. But I’m an iOS developer and practically there’s only one platform that I can do my work on - macOS.

Alright, so it’s a Hackintosh then!

Apple hasn’t released significantly improved hardware for “pros” in years now, so this might actually be good timing to build one.

But let’s not make things too simple. Remember those older Mac Pros? The cheese graters? Those cases look awesome and sleek, wouldn’t it be awesome to build a pc in one of them? There’s other people...

Ever since Swift 1.0 was released, I have been struggling with finding a way to introduce some proper dependency injection into my code. The previous methods that were popular in objective-C like Swizzling or property overloading no longer works or require far too many changes to your code to make them actually worth it.

Natasha Murashev posted some nice ideas about dependency injection through default property values in functions, you can read more about that here.

But there’s one problem with this solution, the default values require that the concrete implementation be dragged in and linked with your testing target, and that might be something that you don’t want to do.

Today I bring you a way to solve these issues: by using default property values, (convenience) initilizers and type extensions to introduce some really convenient dependency injection.

The Example

Let’s start with...

Intro

I’ve been doing some work with a fair amount of crypto for an my upcoming application. Now as you all probably know, the standard for doing any crypto is with OpenSSL. I’m not much of a hipster so I immediately went with that.

The Good

x2on’s OpenSSL-for-iPhone is an excellent tool of convenience. It downloads the latest version of OpenSSL, builds both libssl and libcrypto for all available architectures and glues all slices into one universal library each. It even comes with a script to generate openssl.framework from the resulting libraries.

The Bad

The resulting framework runs great on any device, sadly, the linker just didn’t want to link for the simulator. The linker spewing:

Undefined symbols for architecture x86_64:
  "_OPENSSL_ia32cap_P", referenced from:
      _AES_cbc_encrypt in openssl(aes-x86_64.o)
ld: symbol(s) not found for architecture x86_64
clang: error: