Setting Up Xcode

After getting my source control repository setup the next step was to create my project in Xcode. Since I want to build this app using Swift I have to use the beta version of Xcode (currently beta 5). The suite of beta software seems pretty stable at this point so I don't expect to run into many odd issues. The good thing is that this year Apple has opened up quite a bit and is allowing everyone to talk about pre-released software that used to be covered under the NDA (Non Disclosure Agreement).

The fist question you see when creating an app is what template do you want to start with. Apple provides good templates for navigation and tabbed based apps, but I chose a Single View App because that is as close as you can reasonably get to starting from scratch.

Another choice to make is the Product Name. I'm guessing this is going to be the name that you would see in the app store, or maybe it just pre-populates that field with this value when submitting the app but gives you the chance to change it in iTunes Connect. I don't know, but I'm going with a simple 'cthayes' for now.

The last interesting choice I have to make is whether I want to support iPhones, iPads or both. Normally for the sake of complexity I would just choose iPhone, however, Apple is really pushing developers to be size and more recently device agnostic when designing. The AutoLayout system makes it easier to layout what you see on screen and describe how the different elements should behave when the device rotates. In Xcode 6 there is a concept called size classes which allow you to specify how the view should behave at different sizes. The principles of size classes is similar to responsive design on the web, i.e. the code for what you see should adapt to size of the users screen. Anyone reading the tea leaves of the app store can tell that a Universal app is the way of the future, so that is what I am going to do. When this app eventually ships it will be available on both iPhones and iPads.

Source Control

Source control is a tool that keeps track of changes to files, allows multiple versions of the code to exist as well as a number of other useful features. Source control is very important for teams of developers, but there are still plenty of uses when I'm the only person working on the code and so within the past year I've started using it with my code.

I use source control on this site to keep work for new features separate from new articles. Then I update the files on the server without fear of accidentally putting something up that wasn't ready yet.

I use Bitbucket to host my private git repositories. So the first thing I did to start setting up my iOS app was create a repository there. At first I thought I might have to set the language as objective-c since Swift is not officially released yet, but Bitbucket has added it since the last time I looked.

Christopher Hayes

Next I created the repository on my local Mac and linked it to the Bitbucket server. This is very easy to do using SourceTree (an app that issues git commands for you).

Incidentally this is somewhat close to the toolset I use at work. We use git, SourceTree and several other Atlassian tools.

An Experiment

For the past few years my blog has been a playground for learning and practicing new web development skills. It's time I do the same thing for iOS.

You don't need an app for a blog.

But I'm going to make one anyway. The plan is to make it completely in Swift (Apple's new programming language) and play around with the newest technologies. In order to keep myself accountable and get my thoughts formulated, I'm also going to write about my process of discovery and learning, including some technical and non-technical content ranging from source control strageties and possible third-party libraries to server costs and mobile design.

What do I hope you will get out of this? Insight into what it takes to build an app, a peak about what goes on in the mind of a developer, and hopefully an appreciation for all of the work in the process of making software.