NotTooBad Softwarehttp://blog.nottoobadsoftware.com
Sun, 28 May 2017 20:22:27 +0000en-GBhourly1https://wordpress.org/?v=4.9.894135541SwiftShell 3http://blog.nottoobadsoftware.com/swiftshell/swiftshell-3/
http://blog.nottoobadsoftware.com/swiftshell/swiftshell-3/#respondSun, 28 May 2017 20:22:27 +0000http://blog.nottoobadsoftware.com/?p=1274SwiftShell 3 is finally out of beta, with a much improved readme.

So much so it may even be too long now.

]]>http://blog.nottoobadsoftware.com/swiftshell/swiftshell-3/feed/01274Moderator: parsing commandline arguments in Swifthttp://blog.nottoobadsoftware.com/swift/moderator-parsing-commandline-arguments-in-swift/
http://blog.nottoobadsoftware.com/swift/moderator-parsing-commandline-arguments-in-swift/#commentsThu, 16 Mar 2017 23:52:40 +0000http://blog.nottoobadsoftware.com/?p=1248There are a lot of command line argument parsers written in Swift available on Github, so when I needed one for a client project I was surprised I could not find any which fulfilled these requirements:

handle --tag=value.

treat unrecognised arguments as an error and list them.

Nor could I find any where it would be relatively easy to add these features, since most just loop through the arguments from first to last and have one big function trying to find out what to do with each of them. That becomes messy quickly.

I think it’s much simpler to create multiple small argument parsers, where each one in turn takes in the list of arguments, removes the ones it wants to handle and passes the rest on to the next one. Any arguments left over are then unrecognised and can be handled accordingly. This way the end user does not need to worry about the order of the arguments. The developer however needs to be careful about the order of the parsers.

]]>http://blog.nottoobadsoftware.com/swift/moderator-parsing-commandline-arguments-in-swift/feed/81248FileSmith: Type-safe file handling in Swifthttp://blog.nottoobadsoftware.com/swift/filesmith-type-safe-file-handling-in-swift/
http://blog.nottoobadsoftware.com/swift/filesmith-type-safe-file-handling-in-swift/#respondWed, 22 Feb 2017 17:31:31 +0000http://blog.nottoobadsoftware.com/?p=1239Dealing with file paths in Swift is cumbersome. Using only the standard library leaves us with Strings, which we can join together or split by /. It gets the job done but it’s not pretty, and we need a separate type so our methods can accept file paths exclusively and not just any old String. Foundation gives us this in NSURL/URL, which are also used for internet URLs so their method names are very general and long. E.g. url.deletingPathExtension().lastPathComponent to return the file name without the extension.

The Swift Package Manager has separate types for absolute paths and relative paths, because in their opinion these are fundamentally different. I can see their point, but I think it should be up to the callers of an API and not the creators whether to use absolute or relative paths.

The best alternative I’ve been able to find is JohnSundell/Files, because it gets an important thing right: it differentiates between files and directories. These are fundamentally different things (even though the internal representation of their paths are identical) and should have different types with different functionalities. You can’t read from or write to a directory itself, nor can you add a directory to a file.

What I am looking for however has separate types not only for files and folders, but also for paths (which may or may not exist) and filesystem items (which do), and for files you just want to read from and not change and files you want to write to, rename, move and/or delete. Because filesystem access, maybe more than any other task solved by programming, has the potential to irrevocably mess things up. And one way to prevent this is extra type safety, leading to fewer programmer errors.

So I made the FileSmith library with FilePath/DirectoryPath, ReadableFile/WritableFile and Directory.

Paths

Paths are like potential files and directories, addresses to things that already exist and things that soon will, if all goes well. They should be easy to create and combine:

Note that if you use the + operator with a String you need to define the return type, otherwise Swift won’t know if it is a file path or a directory path. And you can only append to directory paths.

There is also AnyPath for when you don’t know or care what type a path is. All the Path types are lightweight immutable value types conforming to the Path protocol. They don’t access the file system, with a few exceptions like .exists.

Files

File and Directory objects on the other hand access the file system when they are created, to verify that the file or directory they represent actually exists (otherwise they throw an error). This doesn’t necessarily mean there is still something there when you start reading and writing obviously, but it’s at least good to know there very recently was.

A ReadableFile can only be used for reading from a file, never to change, move or delete it. But you can do whatever you want with a WritableFile, including reading and overwriting it.

Directories

For directories there is just the Directory class for both reading and writing, no WritableDirectory and ReadableDirectory like with files, because it’s not really clear what that means. If you have a ReadableDirectory it should not be possible to make any changes with it, but you can still use it to get the paths of the files and directories it contains, turn them into writable files and writable directories and then make changes to them. The separation is much more clear-cut with files because they can’t contain other files.

Safety

By default Directory.sandbox == true and you can only change files or create new files and directories if they are under the current working directory. Trying to make changes elsewhere throws an error. I like to know there are at least some limits to how badly I can mess things up with a bug.

It reads all the markdown files in the “chapters” directory, joins them together using each filename as a heading and converts everything to HTML. This is actually a very nice and clear* shell script, I especially like how the “for” loop is piped directly into the shell command so I did the same in the SwiftShell version.

I think this is more readable and more explicit about what is going on, though a lot wordier. I especially like how each “try” makes it clear where things can go wrong. Also this is mostly standard Swift and Foundation code, the only parts from SwiftShell are “open” and “run”.

Note that top-level Swift code which can throw does not need to be enclosed in a “do … catch” clause, but the resulting error messages printed to standard error are quite ugly and hard to read. The exit method from SwiftShell makes them prettier.

]]>http://blog.nottoobadsoftware.com/swiftshell/combine-markdown-files-and-convert-to-html-in-a-swift-script/feed/01138Building the Swift compiler and Foundation on Linuxhttp://blog.nottoobadsoftware.com/swift/building-the-swift-compiler-and-foundation-on-linux/
http://blog.nottoobadsoftware.com/swift/building-the-swift-compiler-and-foundation-on-linux/#respondSun, 24 Apr 2016 22:12:12 +0000http://blog.nottoobadsoftware.com/?p=1123Before building the Swift compiler it might be a good idea to check https://github.com/apple/swift to verify the build is currently passing. And to free up as much memory as possible first you can shut down the graphical interface with sudo service lightdm stop.

I really don’t like using the ‘rm’ shell command – one misplaced character and you can do some serious damage. But when working in the Finder I don’t think twice about deleting files, because I know I can always get them back from the trash. So here is a Swift shell script which does exactly that – it moves files to the trash instead of deleting them permanently.

The syntax is very simple – all parameters refer to file system items which should be moved to the trash:

The script is based on this gist but updated for Swift 3 and uses SwiftShell for output to standard error. The actual work of moving the files to the trash is performed by NSWorkspace.sharedWorkspace().recycleURLs. Since this is an asynchronous method we need to launch it in a Grand Central Dispatch block and then have the run loop wait until the method is finished so we get a chance to print any errors before the script exits.

We call removeDuplicates on the arguments list to avoid an error message if we try to trash the same file item twice. Then in the callback from recycleURLs we check for errors – if there are any we print the names of the file items that could not be trashed, and then the error.

Update 2016–10–09: converted to Swift 3.

Update 2017-04-28: updated to SwiftShell 3.0.

]]>http://blog.nottoobadsoftware.com/swiftshell/move-files-to-the-trash/feed/01108Cross-platform command line arguments syntaxhttp://blog.nottoobadsoftware.com/uncategorized/cross-platform-command-line-arguments-syntax/
http://blog.nottoobadsoftware.com/uncategorized/cross-platform-command-line-arguments-syntax/#respondFri, 26 Feb 2016 12:27:58 +0000http://blog.nottoobadsoftware.com/?p=1098I’m rewriting Moderator (yet another command-line argument parser), and with Swift now being available for both OS X and Linux (Ubuntu) it should support a syntax which enables applications to fit in on both platforms.

POSIX* is I think the closest thing to a standard for this, so it will be the basis, with some modifications (The Python documentation also has some good insights).

Long option names

POSIX states that all options must be of the form -a and contain only one character. But --long-name is also widely used and often preferable. After all,

transmogrify --input file1 --output file2

is easier to understand than

transmogrify -i file1 -o file2

Notably Apple does not follow this norm. Their command-line applications, like swift* and xcodebuild, use only one - in front of their long option names (as in swift -help). And, presumably to avoid ambiguity, they do not allow combining several single character options after a single -.

* but not swift build.

Option names should not begin with a number

Each option name should be a single alphanumeric character (the alnum character classification) from the portable character set.

This means that -4 is a valid option name. But what if the application also takes negative numbers as one of its arguments? This could get confusing, not necessarily for the argument parser, but for us humans. Also I don’t think any programming language allows identifiers to begin with a number.

Allow weird characters in option names

The portable character set mentioned in the previous quote seems rather restrictive (for one it’s missing 2 characters from my name). I don’t think we should restrict command-line applications to only the English alphabet, there’s no reason they can’t be in other languages too.

Allow joining option and argument together with =

It is also quite common to join options and option arguments together:

transmogrify --input=file1 --output=file2

I even prefer this to the standard syntax because it makes it clear what is an option argument and what is a stand-alone argument. Also it makes it possible to have option arguments that begin with a - without being mistaken for an option.

Conclusion

I think good command line syntax should be designed first and foremost with the writers and readers of commands and shell scripts in mind. It should be as clear as possible not only for computers, but also for people reading the commands, even if they are unfamiliar with the application. Hopefully these commonly used additions brings us closer to this goal.

In the previous post we implemented lazy splitting of collections, very useful for say splitting large texts into lines. But in SwiftShell I need the same functionality for text which is acquired piecemeal, like the output of a long-running shell command read sequentially, when needed. Because shell commands which are piped together in the terminal should get to work right away, and not just hang around waiting for the previous command to finish. Like this:

Both scripts start at the same time. The left one uses the functionality implemented below, while the right one reads the entire input into a string first, and therefore has to wait for the ‘linemaker’ command to finish before doing any actual work.

The problem

This functionality can be used to split any collection over any Equatable element, but it is easier to visualise it if we think of it as splitting text over the newline character:

In how many pieces the text is read is completely arbitrary, it can take several of them just to complete a line or one piece can contain everything. All we know is we want the same results no matter how the text is divided.

I struggled with coming up with a nice and clean implementation for this. When each piece is split individually the results can be turned into a sequence of sequences, which sounds like a job for the built-in flatten method. The problem is, after splitting, the last part of one piece must be joined with the first part of the next, and I don’t know of any generic concept for that.

The end result is a bit messy, but fairly simple. Though I’m not really satisfied with any code which feels like it needs comments to be comprehensible.

To keep this as generic and reusable as possible, input ‘bases’ is a function returning the next piece of the collection every time it is called, until it is empty and returns nil. gs is a generator of generators, lazily turning each input collection into a LazySplitSequence. g is the LazySplitSequence we are currently working on.

If g is empty, get the next LazySplitSequence from gs. If gs is empty then we are done, return nil.

If there is no remaining part of the current LazySplitSequence to split further, but there is more left in gs, then split off the first part of the next LazySplitSequence and join it with the current head, which is the last part of the current LazySplitSequence.

Here is the complete code including LazySplitSequence, with unit test.

There are already methods for splitting collections in the Swift Standard Library, but they do all the work immediately and return the results in an array. When dealing with large strings, or streams of text, I find it better to do the work lazily, when needed. The overall performance is not necessarily better, but it is smoother, as you get the first results immediately instead of having to wait a little while and then get everything at once. And memory usage is lower, no need to store everything in an array first.

The original

This is how the CollectionType.split method in the Standard Library splits strings over “,”:

The results when allowing empty slices may seem a bit strange, but think of it as text split on the newline character into separate lines, and consider there may be several empty lines in a row plus they may be at the beginning and/or the end.

The first step

So what is the simplest operation needed here, and will it be useful on its own? When splitting collections into smaller pieces the smallest possible operation is to split the collection once into 2 pieces. And yes I believe that operation will be useful on its own:

extension CollectionType where Generator.Element: Equatable {
/**
Return everything before the first occurrence of ‘separator’ as 'head', and everything after it as 'tail'.
If ‘separator’ is first, ‘head’ is empty. If it is last, ‘tail’ is empty.
If ‘separator’ is not found then ‘head’ contains everything and 'tail' is nil.
*/
public func splitOnce (separator: Generator.Element) -> (head: SubSequence, tail: SubSequence?) {
guard let nextindex = indexOf(separator) else { return (self[startIndex..<endIndex], nil) }
return (self[startIndex..<nextindex], self[nextindex.successor()..<endIndex])
}
}

Pretty straightforward, just find the first separator and return everything before it and everything after it.

The output

This functionality naturally belongs in LazyCollectionType. We will be following Apple’s guidelines for extending it (they are the same as for LazySequenceType), except we will use the same struct for the sequence and generator because I don’t want to write this monster of a generic where clause more often than strictly necessary:

This defines restrictions on the source collection’s subsequences which you would think must be valid for all subsequences. All sequences, and therefore collections, should satisfy them, so I don’t think we are excluding anything here. These restrictions are in any case necessary for the following code, which deals entirely in subsequences and their subsequences:

In the initialiser we set remaining to a subsequence of the entire collection. Then for every iteration we return everything before the next occurrence of separator, set everything after it to remaining and optionally skip empty results.

You may have noticed this sequence does not have a ‘generate’ method even though it is a required part of the protocol. That is because of this clever little extension in the standard library, which automatically generates one for us.

The actual method

Then all that remains is the method itself, where we meet the monstrous generic where clause again:

Asynchronous

Launch a command and continue before it’s finished. You can process standard output and standard error, and optionally wait until it’s finished and handle any errors.

If you read all of command.stderror or command.stdout it will automatically wait for the command to finish running. You can still call finish() to check for errors.

Parameters

The 3 run functions above take 2 different types of parameters:

(executable: String, _ args: Any …)

If the path to the executable is without any /, SwiftShell will try to find the full path using the which shell command.

The array of arguments can contain any type, since everything is convertible to strings in Swift. If it contains any arrays it will be flattened so only the elements will be used, not the arrays themselves.

run xcodebuild install from the project’s root folder. This will install the SwiftShell framework in ~/Library/Frameworks.

or run xcodebuild and copy the resulting framework from the build folder to your library folder of choice. If that is not “~/Library/Frameworks”, “/Library/Frameworks” or a folder mentioned in the $SWIFTSHELL_FRAMEWORK_PATH environment variable then you need to add your folder to $SWIFTSHELL_FRAMEWORK_PATH.

]]>http://blog.nottoobadsoftware.com/swiftshell/swiftshell-2-0-readme/feed/01046How to use Swift for shell scriptinghttp://blog.nottoobadsoftware.com/swiftshell/how-to-use-swift-for-shell-scripting/
http://blog.nottoobadsoftware.com/swiftshell/how-to-use-swift-for-shell-scripting/#respondWed, 16 Sep 2015 23:48:05 +0000http://blog.nottoobadsoftware.com/?p=999To be honest I’m not very good at shell scripting. It’s very useful for automation so I would like to be, but I just don’t like the syntax. For instance, this is how you check if a variable is greater than 100:

#!/bin/bash
if [ $var -gt 100 ]
then
<do some stuff>
fi

And here’s how to check if the file referred to in the first argument is readable and not empty:

if [ -r $1 ] && [ -s $1 ]

Enough said.

So I would much rather use Swift, as the syntax is nice, very nice indeed. But the things that bash shell scripts actually are good at, like running shell commands and accessing the shell environment, are not that straightforward in Swift. Here’s how you can perform the various tasks using only the Swift Standard Library and Foundation:

Run shell commands

NSTask (Apple, raywenderlich.com) is actually an excellent API which launches asynchronous external processes and has customisable environment, input and outputs. But it definitely needs some helper functions to make it easier to use.

There is also the system function (which has been deprecated) and posix_spawn which is a C API with lots of inout parameters. Again; enough said.

Read input and provide output

Swift’s readLine function reads standard input line by line. And print (previously known as println) prints to standard output.

For more direct control, like seeking and reading and writing binary data, you can use file handles:

readSome takes whatever text is available in the file handle and returns it, whereas read waits for the file handle to be closed and then returns all its contents. If the file handle is never closed it never returns.

Most of the code here is from SwiftShell, a library which makes shell scripting in Swift much simpler.

// SwiftShell 1
run("echo piped to the next command") |> run("wc -w") |>> standardoutput
// print out line number and content of each line in standard input
var i = 1
standardinput.lines() |> map {line in "line \(i++): \(line)\n"} |>> standardoutput

But Swift 2.0 is here, and it’s clear the way forward is protocols, method chaining and error handling. And being more explicit about what is going on. So for SwiftShell 2 I’m planning something like this:

Maybe SwiftShell 1 looks cooler ( |> is after all very cool), but I think SwiftShell 2 is cleaner and shows more clearly what’s going to happen. It also makes it easier to take advantage of the Swift standard library, and most importantly is more in keeping with the spirit of Swift 2.0.

As of Xcode 7 beta 6, Swift no longer requires variadic parameters to be last in the function definition. Also argument labels are no longer required when combined with parameters with default values. So this all works fine now:

It works, but run("cmd", "arg1", "arg2") is inarguably much prettier than run2("cmd", args: "arg1", "arg2").

So to sum up: if you’re going to have both parameters with default values and variadic parameters the variadic parameters must have an argument label.

]]>http://blog.nottoobadsoftware.com/swift/mixing-default-values-and-variadic-parameters/feed/0968New theme and new hosthttp://blog.nottoobadsoftware.com/uncategorized/new-theme-and-new-host/
http://blog.nottoobadsoftware.com/uncategorized/new-theme-and-new-host/#respondSat, 27 Jun 2015 20:05:00 +0000http://blog.nottoobadsoftware.com/?p=965Did not post anything last week, as I have been busy moving the site over to BlueHost and setting up a new theme. All because I wanted Swift code highlighting, and WordPress.com doesn’t support that. This of course took a lot longer than anticipated, but it’s finally done and if I do say so myself the new theme is simpler and easier to read. So all in all it was worth it.
]]>http://blog.nottoobadsoftware.com/uncategorized/new-theme-and-new-host/feed/0965Parser combinator operators in Swifthttp://blog.nottoobadsoftware.com/footlessparser/parser-combinator-operators-in-swift/
http://blog.nottoobadsoftware.com/footlessparser/parser-combinator-operators-in-swift/#respondMon, 15 Jun 2015 00:33:49 +0000http://blog.nottoobadsoftware.com/?p=847This is part of a series on FootlessParser, a parser combinator written in Swift.

Parser combinators must be one of the best things to come out of functional programming. They let you define intuitive parsers right in the code, without any need for pre-processors.

Like this:

let parser = function1 <^> parser1 <*> parser2 <|> parser3

where function1 and parser3 return the same type.

parser will pass the input to parser1 followed by parser2, pass their results to function1 and return its result. If that fails it will pass the original input to parser3 and return its result.

Definitions

Parser

a function which takes some input (a sequence of tokens) and returns either the output and the remaining unparsed part of the input, or an error description if it fails.

Token

a single item from the input. Like a character from a string, an element from an array or a string from a sequence of command line arguments.

Parser Input

most often text, but can also be an array or really any collection of anything, provided it conforms to CollectionType.

Parsers

The general idea is to combine very simple parsers into more complex ones. So char("a") creates a parser which checks if the next token from the input is an “a”. If it is it returns that “a”, otherwise it returns an error. We can then use operators and functions like zeroOrMore and optional to create ever more complex parsers. For more check out FootlessParser’s list of functions.

Operators

<^> (map)

function <^> parser1

creates a new parser which runs parser1. If it succeeds it passes the output to function and returns the result.

<*> (apply)

function <^> parser1 <*> parser2

creates a new parser which first runs parser1. If it succeeds it runs parser2. If that also succeeds it passes both outputs to function and returns the result.

The <*> operator requires its left parser to return a function and is normally used together with <^>. function must take 2 parameters of the correct types, and it must be curried, like this:

func function (a:A)(b:B) -> C

This is because <*> returns the output of 2 parsers and it doesn't know what to do with them. If you want them returned in a tuple, an array or e.g. added together you can do so in the function before <^> .

If there are 3 parsers and 2 <*> the function must take 3 parameters, and so on.

<*

The same as the <*> above, except it discards the result of the parser to its right. Since it only returns one output it doesn't need to be used together with <^> . But you can of course if you want the output converted to something else.

*>

The same as <* , but discards the result of the parser to its left.

<|> (choice)

parser1 <|> parser2 <|> parser3

This operator tries all the parsers in order and returns the result of the first one that succeeds.

Example

]]>http://blog.nottoobadsoftware.com/footlessparser/parser-combinator-operators-in-swift/feed/0847FootlessParser: updated documentation and readmehttp://blog.nottoobadsoftware.com/footlessparser/footlessparser-updated-documentation-and-readme/
http://blog.nottoobadsoftware.com/footlessparser/footlessparser-updated-documentation-and-readme/#respondMon, 08 Jun 2015 00:25:16 +0000http://blog.nottoobadsoftware.com/?p=833The FootlessParser project is finally becoming usable and now has brand-new documentation generated by jazzy. The readme has also received some attention and is now actually useful:

FootlessParser is a simple and pretty naive implementation of a parser combinator in Swift. It enables infinite lookahead, non-ambiguous parsing with error reporting.

begins with a “, then contains anything, including commas, tabs and newlines, and ends with a ” (both quotes are discarded)

or is unquoted and contains anything but a comma or a newline.

Each row then consists of one or more cells, separated by commas and ended by a newline. The extend function joins the cells together into an array.
Finally the csvparser collects zero or more rows into an array.

To perform the actual parsing:

let result = parse(csvparser, csvtext)
if let output = result.value {
// output is an array of all the rows,
// where each row is an array of all its cells.
} else if let error = result.error {
println(error)
}

The parse function returns a Result which if successful contains the output from the parser, or in case of failure contains the error.

By defining types (and protocols) around capabilities, and writing functions that target those capabilities, we end up with cleaner and remarkably reusable code when compared to implementing functionality targeting a specific type. The bulk of our final implementation has nothing to do with distances, time intervals, apples, oranges, or anything else. It reads more like a set of statements of fact that any future programmer could adopt if they so chose.

Type parameters force everyone to know the types involved and specify them repeatedly (when you compose with them it can also lead to an explosion in the number of type parameters). They’re part of the public interface. The code that uses the concrete thing (class/struct/enum) makes the decision about what types to select.

By contrast an associated type is part of the implementation detail. It’s hidden, just like a class can hide its internal ivars. The abstract type member is for the concrete thing (class/struct/enum) to provide later. You select the actual type when you adopt the protocol, not when you instantiate the class/struct. It leaves control over which types to select in a different set of hands.

But I do think he is too harsh on the functional programming hipster kids.

]]>http://blog.nottoobadsoftware.com/uncategorized/swift-associated-types/feed/0814Add Result type and operatorshttp://blog.nottoobadsoftware.com/footlessparser/add-result-type-and-operators/
http://blog.nottoobadsoftware.com/footlessparser/add-result-type-and-operators/#respondWed, 06 May 2015 23:18:06 +0000http://blog.nottoobadsoftware.com/?p=789This is part of a series on FootlessParser, a parser combinator written in Swift.

Add Runes and LlamaKit using Carthage

Footlessparser is using operators for map ( <^> ), flatmap/bind ( >>- ) and apply ( <*> ). Luckily the Runes framework has already defined these, and implemented them for optionals and arrays.

Each parse returns a Result, which has either a tuple containing the output and the remaining unparsed part of the input, or an error description if parsing fails. The Result enum is in the Llamakit framework, later replaced by antitypical/Result.

Add Runes+Result.swift

To implement the operators mentioned above for parsers it is very helpful to first implement them for what parsers return, i.e. Result. Gordon Fontenot did just that in this pull request to Runes. It was never merged, so it’s included here.

Switch from LlamaKit/LlamaKit to antitypical/Result.

the success and failure functions for making a Result moved to the Result type and became static instead of global. Which is good, functions only involved with one type should be defined in that type.

Result became a struct, not an enum. Which seems strange as it is either a success or a failure, never both. It was made back into an enum later.

the Result framework brought with it the micro frameworks robrix/Box, robrix/Prelude and robrix/Either. Especially Prelude has some basic functional programming functionality that will come in handy.

]]>http://blog.nottoobadsoftware.com/footlessparser/add-result-type-and-operators/feed/0789Set up an open source Xcode framework projecthttp://blog.nottoobadsoftware.com/footlessparser/set-up-an-open-source-xcode-framework-project/
http://blog.nottoobadsoftware.com/footlessparser/set-up-an-open-source-xcode-framework-project/#respondMon, 27 Apr 2015 17:14:11 +0000http://blog.nottoobadsoftware.com/?p=697This is part of a series on FootlessParser, a parser combinator written in Swift.

I find these steps helpful when setting up any new open source framework project in Xcode.

Create project

Create a new project in Xcode, and select OS X framework if it is for both iOS and OS X. The iOS framework target can be added later, besides OS X frameworks are more practical for unit testing. No simulators needed.

Create root folders “tests” and “source” and move stuff in place in Xcode

The file structure of Xcode projects looks better, especially on GitHub, if the code for the product itself is in “source” and the test code in “tests”. It’s better than just dumping all Xcode targets in the root folder. Especially for this project, as it will have test targets for both unit tests, speed tests and integration tests.

Share the only scheme.

Schemes are not shared by default in Xcode. It’s best to share this now since you’re bound to be making changes to it in the future, and if it’s not shared no one else will receive those changes. While you will be merrily coding along, assuming what you see everyone else sees too.

Add license.

Which licence to release open source code under is of course entirely a matter of preference. Personally I agree most with the Eclipse licence because I would prefer anyone who make any changes to make them public and open source as well. But I also want my open source projects to be available to as many people as possible, and the MIT license is very popular and compatible with most other licences, including GPL. And it is used by all the open source frameworks this project uses. It is also very short, which is always a good thing for legalese text.

Upload to GitHub

After adding some actual code it’s time to share the work with the world. It is easiest to use GitHub for Mac as it both creates the project on GitHub and uploads the code.