Julius Parishy jparishy

So you want to add automated tests to your iOS app?

Awesome, that's a big first step in a very proactive direction towards making your app more reliable and new features easier to build. When the computer is testing to make sure that your changes and refactoring don't break existing features, your velocity skyrockets. This means shipping updates more often, with less effort, and a higher quailty experience for your users.

I'm not here to sell you on the idea of testing; you came here on your own after all. So let's just dive into the gritty details.

The iOS ecosystem and its community aren't rooted in the sort of 'testing culture' that other popular programming languages are, like Ruby or Python. Those langauges are dynamically typed, effectively meaning their source code is not statically checked by a compiler for type system level errors like the C family of languages and Swift are.

Thankfully, on iOS we have some initial assurance that our code will not unknowingly break because we changed the contra

Adopting map() & reduce() in Swift

Swift brings with it the ideologies of several programming paradigms. To Objective-C developers, the most obvious is likely to be a more functional style approach to solving problems. One of the fundamental aspects of functional programming is abstracting logic so that your code reads as a dictation of what it is doing, now how it is doing it. Unless performance becomes an issue, the implementation details of certain action are typically less important than the code being as declarative as possible.

One of the tools that makes this possible is the use of higher order functions, functions that take other functions and use them to perform transformations on a set of data. These include map(), reduce(), filter(), etc.

Swift includes these higher order functions and as you embrace the language itself it is also important that you begin to emprace them in order to make your code more idiomatic and easier to read and reason about.

The purpose of this article is show so

Variable types in Swift for Objective-C Developers

This introduction to generic types, protocols, and enums in Swift is part 2 of a series on Swift for Objective-C Developers. For part 1 about Optional Values, please click here. TODO LINK

This post assumes you are familiar with the idea of generics, but either haven't used them in practice or have been burnt by other languages' (looking at you, C++) implementations and are reluctant to embrace them in Swift.

In Objective-C we have the almightly id, the basic representation of all object types in the language. We often use it as a catch-all when we don't necessarily know the type of an object we're going to be working with. Most often, it is used as the type for objects managed by a collection. Because we do not want to have a different class for every object type we want to contain in an array we use an array type that accepts objects of type id, so we can use any type we like. This is certainly better than having multiple classes such as NSString

	//
	// Model.swift
	// Swerver
	//
	// Created by Julius Parishy on 12/11/15.
	// Copyright © 2015 Julius Parishy. All rights reserved.
	//

	import Foundation

	//
	// main.swift
	// Swerver
	//
	// Created by Julius Parishy on 12/4/15.
	// Copyright © 2015 Julius Parishy. All rights reserved.
	//

	import Foundation

	//
	// JLEInstagramAPI.m
	// WhenToPost
	//
	// Created by Julius Parishy on 6/27/15.
	// Copyright (c) 2015 Julius Parishy. All rights reserved.
	//

	#import "JLEInstagramAPI.h"


	//
	// #1 Adding things up
	//

	let numbers = [Int](0..<10)
	let total = numbers.reduce(0) {
	return $0 + $1
	}

	//
	// Genetics.swift
	// Genetics
	//
	// Created by Julius Parishy on 12/1/14.
	// Copyright (c) 2014 Julius Parishy. All rights reserved.
	//

	import Cocoa
	import CoreGraphics

	//
	// ViewController.swift
	// Tetris
	//
	// Created by Julius Parishy on 11/19/14.
	// Copyright (c) 2014 Julius Parishy. All rights reserved.
	//

	import UIKit