This guide is intended for hobbits, of all levels of experience and knowledge, who reside in Hobbiton who wish to destroy the One Ring. By following this guide, a hobbit will be able to optimally navigate himself from The Shire (Hobbiton) to Mt. Doom (Mordor) in order to destroy the One Ring of Power. Where relevant, this guide includes useful information on necessary waypoints. Pertinent data such as demographics and topography of specified regions can be found in the appendix.

The One Ring of Power was secretly forged by the Dark Lord Sauron in the forge of Mt. Doom during the Second Age. He created the ring and 19 others (given to 19 Kings) in an attempt to rule over all of Middle Earth. The One Ring can control all of the other rings which allowed Sauron to corrupt the rulers of Middle Earth. Sauron lost the One Ring during the War of the Last Alliance and for roughly 3000 years the ring corrupted all who wore it despite efforts to destroy it. In order to destroy Sauron, the One Ring must be destroyed. This guide assumes you currently possess this ring of power and that you intend to destroy it.

Materials Needed

1. The One Ring of Power
2. At least 1 companion
3. Gandalf (Grey or White)
4. Food (i.e. Lembas bread)
5. Weapons
6. Toiletries (optional)
7. Star of Earendil (acquire in Lórien)
8. Tent/Shelter
9. Boat w/ paddles
10. Mule (optional)
11. First Aid kit
12. Clothing and/or armor

Conventions:

Notes contain helpful suggestions related to the hobbit’s journey. Additionally, notes designate what information can be found in the appendix.

This symbol means reader beware. In this situation, the hobbit might bring harm to himself or others around him.

This symbol indicates danger. In this situation, the hobbit is in imminent danger of death or worse.

Path Alternatives

This guide assumes that the hobbit intends to travel to Mordor by foot. Any use of teleportation or giant eagles shall not be considered. Additionally, this guide assumes that the hobbit in question cannot pass through the realm of Isengard.

Below is a map of Middle Earth displaying 3 different paths one can take to get to Mt. Doom from The Shire. The red line indicates a path filled with extremely dangerous obstacles and thus, should be avoided. The green path shows the most direct path; however, the hobbit would have to cross through Isengard in addition to traveling on main roads (a poor choice for a ring bearer). Main roads are unfavorable since the Nazgul will be pursuing the ring bearer. The yellow path is the optimal path given the circumstances and conditions described above.

Walking to Mordor

• Step 1: Begin at The Shire and travel east approximately 150 miles towards Bree. You will cross the Brandywine Bridge after about 50 miles.
• Step 2: Once in Bree, seek out the Prancing Pony in order to replenish food supplies and rest before the next stretch of the journey.
• Step 3: From Bree, continue east another 300 miles to the elven city of Rivendell. Here, seek out the advice of the king of the elves, Elrond. This is a great place to acquire some quality Lembas bread, a boat and perhaps a few companions.

• Step 4: Upon the next sunrise, travel approximately 100 miles east to the Misty Mountains. Cross through the mountains, weather permitting.

• Step 5: In the event that the weather is not permitting, begin traveling south along the Misty Mountains until you reach the Mines of Moria (about 400 miles from Rivendell). Following the map provided, this is the undesirable path.

• Step 6: At the west gates of Moria (Doors of Durin), speak the word “friend” and enter.

• Step 7: Once inside, follow the path to the eastern gate of Moria (Dimrill Gate)

• Step 8: Once you make it past the Misty Mountains, travel directly east until you hit the River of Anduin. Both paths maintain a distance of approximately 100 miles between the Misty Mountains and the River of Anduin.
• Step 9: Both paths lead the traveler through the forest realm of Lothlórien (Denoted on the map as “Lórien”). Stop here but be mindful of the elven culture for it is much different from hobbit culture.

• Step 10: Upon sunrise, travel further south along the River of Anduin (by boat).

• Step 11: Begin traveling by land once the Dead Marshes appear on your left hand side.
• Step 12: Travel east through the Dead Marshes approximately 150 miles until you reach the Black Gate.

• Step 13: Travel south along the Mountains of Shadow for approximately 150 miles until you reach Minas Morgul.
• Step 14: If you have skipped from step 10, abandon your boat after traveling roughly 500 miles on the River of Anduin and begin traveling west towards Minas Morgul.

• Step 15: Travel 50 miles west (around Minas Morgul) towards Mt. Doom.

• Step 16: Climb to Sammath Naur (“Cracks of Doom”) and throw the Ring into the fires of the volcano.

• Step 17: Exit Mount Doom as soon as possible since it will, most likely, collapse around you. Congratulations, you have destroyed the One Ring of Power, vanquished Sauron, and you have brought peace to Middle Earth!
• Step 18: Travel home and write a book about your adventures…..or three.

Appendix

Balrog — A Balrog is large demon which shrouds itself in fire and darkness. Once angelic beings, the Balrogs were corrupted by the evil Vala Melkor. The Balrog in the Mines of Moria wields a sword and a whip. Defeating a Balrog requires great power (i.e. a dragon).

Black Gate — The Black Gate is the only entrance to the realm of Mordor. Any other entrance would be through a series of mountain ranges. The armies of Sauron use the Black Gate to exit and enter Mordor. The Gate is kept by the Mouth of Sauron.

Bree — Bree is an ancient settlement of men. It is a city east of The Shire. Predominantly, men and hobbits populate Bree. The Prancing Pony is an Inn in the town.

Dead Marshes — The Dead Marshes are an area to the northwest of Mordor. Many battles were fought in these marshes and, slowly, the marshes enveloped the dead bodies from these battles. Anyone who attempts to touch the bodies in the marshes will likely drown in them themselves.

Dimrill Gate — Dimrill Gate is the eastern gate of Moria.

Doors of Durin — The Doors of Durin are the western gates of Moria. The gate contains an inscription saying “Doors of Durin, Lord of Moria. Speak, friend, and enter” in Elvish.

Elrond — Elrond is the “half-elf” Lord of Rivendell. He is the son of Earendil and Elwing. He is over 6000 years old.

Elven Culture — Elves, unlike hobbits, are immortal. Hobbits eat significantly more than elves. Elven females tend to become healers while males become warriors and fight. Hobbits, on the other hand, are pacifists and do not fight. For the most part, hobbits drink and eat.

Elvish Language — There are several forms of Elvish, the most popular being Sindarin or Grey-Elvish. Most of the Elves in the western region of Middle-Earth speak Sindarin. The language derives from Common Telerin.

Galadriel — Galadriel is considered to be the greatest elven woman. She is known as the Lady of Light and has been described as the most beautiful elf in Middle Earth. She is the mother-in-law of Elrond and the grandmother of Arwen.

Lembas Bread — Lembas is a special kind of elven bread which stays fresh for as long as it is kept within the leaves it is wrapped in. It is intended for long journeys.

Lothlórien — Lothlórien is considered the fairest elven realm during the Third Age. It is located between the River of Anduin and the Misty Mountains. Galadriel, the greatest female elf, resides in Lothlórien.

Middle Earth — Middle Earth is the world in which this journey takes place.

Minas Morgul — Minas Morgul (once Minas Ithil) is home to the Nazgul and their lord, the Witch King. Minas Morgul is Sindarin for “The Tower of Dark Sorcery.”

Mines of Moria — An enormous underground mine in the Misty Mountains. Moria was home to the dwarves known as the Longbeards.

Misty Mountains — The Misty Mountains is an enormous mountain range (795 miles long) stretching from Mount Gundabad to Methedras.

Mordor — Mordor is a realm in the southeastern region of Middle Earth. Sauron and his armies reside in Mordor. The realm is surrounded on all sides by mountains.

Mount Doom — Mount Doom (Amon Amarth) is a volcano located in the realm of Mordor. The One Ring was forged, and can only be destroyed, in the Cracks of Doom (a chasm in Mt. Doom).

Mountains of Shadow — The Mountains of Shadow is the western mountain range of the realm of Mordor. It is home to many Orcs. The north-most point of the mountains is the Black Gate.

Mouth of Sauron — The Mouth of Sauron is a man who has served Sauron for most of his life (about 70 years) and has learned much sorcery. During this time, he forgot his own name. He is pure evil and commands the armies of Sauron.

Nazgul — The Nazgul (Ringwraiths) are the former kings of men who succumbed to Sauron’s power when they were given rings of power. They achieved immortality by becoming wraiths and are servants bound to the power of the One Ring.

One Ring — The One Ring is a ring of power forged in the Cracks of Doom by Sauron. The ring contains a mind of its own and much of Sauron’s power. The ring corrupts all who bear it. However, certain races are less susceptible to the corruption of the ring.

Orcs — Orcs are relatively dim-witted beings who serve as soldiers for Sauron. They serve out of fear of their masters.

Paper Cuts — Paper cuts are cuts received while handling paper. The cuts are normally slice wounds that can cut surprisingly deep. These cuts are extremely annoying.

Prancing Pony — The Prancing Pony is an inn located in the center of the town of Bree. The servers are hobbits and the Inn permits logging.

Rivendell — Rivendell is an elven realm to the east of the Misty Mountains. It was founded by Elrond in the Second Age. Rivendell serves largely as an outpost for the elves.

River of Anduin — The River of Anduin is the largest river in Middle Earth. The river stretches from the Grey to the Mouths of Anduin.

Sammath Naur — Also known as the Cracks of Doom, Sammath Naur is a chasm in Mt. Doom in which the One Ring was forged. The Cracks of Doom is the only place where the One Ring can be destroyed.

Sauron — Sauron was originally an angelic spirit. However, he fell victim to Melkor’s corruption. In an attempt to gain full control of Middle Earth, Sauron forged 9 rings of power for the rulers of men, 3 for the elves, 7 for the dwarves, and 1 for himself. Sauron’s ring (The One Ring) could control all of the other rings. As a sacrifice, Sauron put part of his power into the ring. This way, when Sauron wore the ring, he was more powerful but when he did not have the ring, he was very weak. By destroying the One Ring, Sauron can be destroyed.

Shire — Also known as Hobbiton, the Shire is the home to the hobbits. This realm is series of hills in which the hobbits built their homes. The Shire is located in the northeastern region of Middle Earth.

Star of Earendil — The Star of Earendil is an artifact which is owned by Galadriel. In its holder’s darkest hour, it is fabled to provide light.

Trolls — Trolls are large and stupid creatures who are considered to be completely evil. They turn to stone upon exposure to sunlight. For this reason, they tend to dwell in caves.

Witch King — The Witch King of Angmar is the leader of the Nazgul. He was once a great king of men but he fell victim to the corrupting powers of his ring of power. He serves as a chief servant of Sauron and resides in Minas Morgul. His original name and background are unknown. It is prophesized that the Witch King will not die at the hand of a man.

Troubleshooting/FAQs

• Why can’t you just fly from the Shire to Mordor?

The Nazgul can also fly. For this reason, it is unwise to use any means of flight in order to reach Mount Doom since you would most likely be intercepted.

• Why have hobbits take the ring if it is so powerful and dangerous?

Hobbits, though distant relatives of men, are less pragmatic than men. Men are greedy by nature and focus much of their attention on the future. Elves are also very pragmatic by nature. Neither of these qualities allows one to withstand the corrupting powers of the ring. For this reason, a hobbit is the optimal choice for a long-term ring-bearer.

• Why must the One Ring be destroyed right now?

Up until recently, Sauron was relatively inactive. He now has massive armies that are invading nearby realms. Both Rohan and Helm’s Deep have suffered the wrath of Sauron’s power. If Sauron were to acquire the One Ring, nothing would be able to stop him from conquering Middle Earth. For this reason, the One Ring must be destroyed as soon as possible.

• Has this journey ever been attempted? If so, why did they fail?

The destruction of the ring has been attempted before. However, the ring bearer was a human who carried the One Ring from the Battle of Dagorlad to Mt. Doom and chose not to destroy it. Even in this short time, the ring easily corrupted this man.

• What’s Tatters?

Potatoes, boil them, mash them, and stick them in a stew.

• What accommodations will a hobbit receive on this journey?

For most of your journey, you will sleep in ditches and you will eat Lembas bread primarily. Though it is unlikely that you will maintain the standard hobbit regiment of 7 meals a day (breakfast, second breakfast, elevenses, lunch, afternoon tea, dinner, and supper), you will visit many new places which will provide you with a myriad of unique culinary experiences.

Bibliography

Tolkien, J.R.R. The Fellowship of the Ring. New York: Ballantine, 1974. Print. Vol. 1 of The Lord of the Rings. 3 vols.

Tolkien, J.R.R. The Two Towers. New York: Ballantine, 1974. Print. Vol. 2 of The Lord of the Rings.  3 vols.

Tolkien, J.R.R. The Return of the King. New York: Ballantine, 1974. Print. Vol. 2 of The Lord of the Rings.  3 vols.

Kamb, Steve, ed. Nerd Fitness. Mike Bridgman, 23 July 2012. Web. 15 Nov. 2012.

About 24 hours ago, alongside some great friends, I began my last day as a 25-year-old with a sunrise hike up one of the volcanoes of Bali. Dressed in my signature red panda onesie, I stumbled up the side of the mountain to watch the sun rise over the mountains. As we ascended the still-active volcano, I kept thinking of something that one of these great friends had said which was that communal struggles make up some of the greatest bonds in our lives. Although the struggle was very evident as we sweatily tripped through the darkness, I couldn’t help but feel extremely thankful for the opportunity to build bonds with these people, in particular. Once at the top, the view was breathtaking and well worth the struggle. Additionally, the natural hot springs that followed our descent were nothing short of serene.

Over the last few months, I’ve been exploring Asia with a group called Hacker Paradise. When I started this journey, I meant it to be something of a vacation. However, 3 months in, I’m getting the same gut feeling that I experienced when I first attended MHacks at the University of Michigan as well as the same sense of wonder I experienced when I first visited Silicon Valley. With a simultaneous mix of excitement and anxiety, I am happy to announce that I won’t be coming home. Up until now, I only had one strong passion, building things that people want, but now I’ve realized that another passion is collective exploration. The last couple of months have been filled with instances of both cultural and personal exploration and I’m nowhere near done with either.

Over the next 6 months, after a brief visit to the US (for the winter holidays), I’ll be packing up and heading to South America for several months. After these months, I have no idea what I’m doing but one thing is for certain, I will not stop building. Silicon Valley and the hacker community have shown me how powerful user-oriented and iterative development can be for any idea. Every day, I deeply miss Silicon Valley, its community, and the friends (more like family) that I have gained through this culture of creation. However, traveling is what feels right at the moment. I am extremely fortunate for the friends I’ve made, especially through hackathons and Hacker Paradise. I couldn’t ask for a better group of people to be surrounded by during the beginning of this new quarter of my life, thank you.

An additional thank you goes out to the amazing people I work with at Barefoot Coders for being so cooperative while I work remotely. I truly believe that we are building something amazing together and I feel extremely gifted to work with such talented individuals every day. A final and tremendous thank you goes out to everyone I’ve talked to about this including my friends and family who have been so supportive of this decision despite the distance it puts between us. I love you all very much and I can’t wait to see you all this holiday season.

I begin this next journey with two lines from an old poem in mind…

“All that is gold does not glitter,
Not all those who wander are lost;”

- J. R. R. Tolkien

This is Part 2 of a 3 Part tutorial that follows Apple’s old “Your First iOS App” tutorial, but implements all of the user interface elements via XML Interface Builder (XIBs) using Swift. View Part 1 or check out the complete code on Github.

To learn more about my work, visit my website.

The next step is to familiarize ourselves with and setup our XIB.

1. Initial XIB Setup

Go back to your MainViewController.swift file. Similar to the app delegate, this comes with some helpful methods to handle different points in the life cycle of the UIViewController class. It should look a little like this:

One of the important aspects of a good developer is clean code. Thus, you want to remove any code that you don’t utilize. In this case, go ahead and delete lines 10 through 26 as they aren’t relevant to this project.

A key benefit to using XIBs is that it gives us a great separation of our business logic (calling APIs, manipulating data, assigning data, etc) and our views (definition of views, view properties, and their layout). In regards to our MainViewController, everything that deals with our views will go in “MainViewController.xib” and everything else will be in our “MainViewController.swift” file.

For now, we only care about defining our text field’s view; that is, its properties and its layout. So let’s navigate to our “MainViewController.xib” using the right side menu (Navigator). Once here, you should something like this:

• Section 1 is our Navigator, you can use this to move between the other files in the project.
• Section 2 is the Document Outline, it provides a simple hierarchal overview of what is in the current view.
• Section 3 is our actual playground (the Interface Builder), our current view.
• Section 4 contains our tools (Utilities) that we will use in conjunction with the current view to build our UI.

When working with a XIB, we will spend most of our time in sections 3 and 4.

First things first, at the bottom of the main view, find this

After clicking on it, change it to this

Once you’ve done that click the green circle to finalize the change. Your main view should change it’s size and should now look more like an iPhone.

This is not a necessary change but will provide us with a better understanding of what our view will look like when run on an actual device.

Your view should now look like this

Now we’re ready to work! We will now add elements to the user interface — a text field, a button, and a label.

2. The Text Field

In the Utilities, find the Object Library, it looks like the image to the adjacent image. Now, use the bottom “Filter” search bar and begin typing “text field.”

You will see the only result should be “Text Field.” Drag and drop this item into our main view, closer to the top of the page.

Once it’s on the page, you can make it larger by simply clicking and dragging the frame. Your view should look like the one below.

You will also notice that once you drag the text field into the view, it appears as a sub-branch in the Document Outline titled “Round Style Text Field.” We now want to adjust the properties and the layout of the text field.

First we’ll adjust a property of the text field. Make sure the text field is selected. The area above the Object Library in the Attributes Inspector is where you can modify the text field properties. Find the “Alignment” property and set the alignment to center by clicking this button.

As simple as that, now you have centered the text in the text field! Feel free to play around with the other properties like text color, placeholder text, etc.

Now, we’re gonna move onto adding layout constraints in Interface Builder so that our text field is properly placed on the screen. Once again, make sure the text field is selected and now look for these 3 buttons at the bottom of the main view.

From left to right, these buttons are as follows:

• Align — Allows you to align various axes of the current view to axes of its parent view. (Think center align horizontal and center align vertical)
• Pin — Allows you to create a new constraint between the current view and another view.
• Resolve Auto Layout Issue — I cannot, in good faith, recommend that you ever hit this button. Once you hit this button and select an option, you potentially throw all logic and reason out the window. I would only recommend using this if you are familiar with AutoLayout in Interface Builder and how it resolves issues.

We want to introduce 3 constraints using AutoLayout

1. Align Vertical Center of Text Field with Vertical Center of its Parent (View)
2. Set the Top of the Text Field to be 10% of its Parent View’s height
3. Set the Width of the Text Field to be 90% of its Parent View’s width

The numbered instruction sets below correspond to the numbered constraints above:

1. Ensure the text field is selected and click the Align button. Next, check the box that says Horizontally Center in Container and click Add 1 Constraint. If any red lines show up, disregard them for now.

• Red lines simply indicate that more constraints are required in order to properly layout the view.
• Yellow lines indicate that the current view doesn’t match the current constraints
• Blue lines indicate that the current view matches the constraints and that there are sufficient constraints to properly place the view

2. Ensure the text field is selected and right-click the text field, hold and drag to the parent view. Let go and you should see this window appear.

Go ahead and click Top Space to Container. However, this isn’t quite the constraint we want so we need to edit it. Click on the newly created vertical line that extends from the top of the text field to the top of the parent view. Now a window like this should appear on the right.

Your constant may be different than mine but that shouldn’t matter. Change the values on your page to match the ones below. This creates a constraint (layout relationship) ensuring that the top of the text field is 10% (See Multiplier) of the height of the screen (See Second Item).

Additionally, ensure that the value for Constant is set to zero.

Once again some colored lines may appear on the main view but disregard them for now. We will deal with them once we have introduced all of our constraints.

3. For our last constraint, again, ensure the text field is selected in the main view. Once again, right-click the text field and drag out to the parent view. This time when you let go and the screen below appears, click Equal Widths.

As before, this isn’t quite the constraint we wanted so we’re going to modify it a bit. You’ll notice that as you add constraints, they appear in the Document Outline under a parent group titled Constraints. Go ahead and click on our newly created constraint for the width (the only one with “width” in the name). When the constraint is expanded on the right hand side of your screen, change the value of Multiplier from 1 to 0.9.

Now, click back on to the text field and you should see quite a bit of yellow lines. You should also notice that a yellow arrow has appeared in the Document Outline.

Click on this yellow arrow and you will be taken to a screen that presents an overview of the layout conflicts. It will tell you what properties are expected to be versus what they currently are in the main view. There is also a yellow triangle on the right of this view. See below.

Mine looks like the following. To resolve the constraint issues, click on the yellow triangle. This will present you with several options. See below.

The issue is that, using the constraints we created, we have defined where we want the text field to be but the text field in the main view doesn’t match those constraints.

Instead of forcing a decision, Xcode allows you to decide whether to update the main view to match your constraints or to have Xcode adjust your constraints to match what the main view currently looks like. In this case, we know our constraints are right so we will select Update frames and click Fix Misplacements. If you click back into the main view, you’ll notice a lot of blue lines now! You will learn to love blue lines.

If you run the app, you should now see the text field at the top of the screen. Clicking inside will bring up the keyboard and allow you to type. While the keyboard appears automatically, we have to add to code make it disappear ourselves.

The key is implementing a “delegate method” of the UITextField. Delegate methods are like helper functions for the objects in your application, and can sometimes help pass data between two classes. In order to implement the UITextFieldDelegate, we add it to the line containing our class definition in MainViewController.swift

class MainViewController: UIViewController, UITextFieldDelegate {

And then we set MainViewController.swift as the delegate within our viewDidLoad method.

Right below super.viewDidLoad() line, add

textField.delegate = self

This lets the application know where to look for the implementation of the delegate methods, which in this case is inside Self — a reference to our MainViewController class.

Now that we implemented the text field delegate, the delegate method we need to dismiss the keyboard is called “textFieldShouldReturn.” This function is called every time the user presses the “return” button on the keyboard.

Information about a class’s delegate methods is in Apple’s documentation. You can find the “textFieldShouldReturn” method in the UITextFieldDelegate reference article.

Since this is more business logic than view work, we will add it below the viewDidLoad method in MainViewController.swift:

func textFieldShouldReturn(textField: UITextField!) -> Bool {

}

Dismiss the text field programmatically by adding the following lines:

func textFieldShouldReturn(textField: UITextField) -> Bool {

// Dismisses the Keyboard by making the text field resign
   // first responder
   textField.resignFirstResponder()
   
   // returns false. Instead of adding a line break, the text 
   // field resigns
   return false
}

However, we haven’t yet created a reference to our text field from the XIB. Xcode knows to add the text field upon building the app but in order to access and manipulate the text field from our .swift file, we need to create an IBOutlet linking the text field to our code. To do this, we will need to open the Assistant Editor. If you aren’t familiar with the Assistant Editor, it’s the middle button in this set of buttons at the top bar of Xcode.

If you haven’t already, navigate to the MainViewController.xib file and click the Assistant Editor button. Your view should now be split in two like this:

To make room, go ahead and hide the Utilities by clicking the right-most button in this set at the top of the screen:

And hide the Document Outline by clicking this button at the bottom of the XIB view.

Now, Xcode will look like this:

Go ahead and right-click the text field in the XIB file and drag your cursor all the way over to the .swift file just above the viewDidLoad method. You should see this little window pop up:

Since this will be an Outlet, just go ahead and name this “textField” and click Connect. Now, you should see the error icon go away and, if you run the app, clicking on the text field pulls up the keyboard and the Return button dismisses the keyboard. Additionally, we can now directly manipulate our text field from the .swift file.

In the next part of this tutorial, we will add the Label and the Button.

Part 3 Coming Soon!

This is Part 2 of a tutorial that follows Apple’s old “Your First iOS App” tutorial, but implements all of the user interface elements programmatically using Swift. View Part 1 or check out the complete code on Github. This tutorial is ported from an Objective-C implementation by Austin Louden. If you prefer Objective-C, please see Part 1 and Part 2 of that tutorial.

To learn more about my work, visit my website.

The next step is to add elements to the user interface — a text field, a button, and a label.

1. The Text Field

Go back to your MainViewController.swift file. Similar to the app delegate, this comes with some helpful methods to handle different points in the life cycle of the UIViewController class. It should look a little like this:

One of the important aspects of a good developer is clean code. Thus, you want to remove any code that you don’t utilize. In this case, go ahead and delete lines 10 through 26 as they aren’t relevant to this project.

Now, to add our text field, we’re going to lazily instantiate an Apple-provided class called UITextField. Lazy instantiation simply means that the object is only created when it is required by the program rather than having all the objects of a page created as soon as the page is created.

Below the viewDidLoad method, add the following code:

lazy var textField: UITextField! = {
    let view = UITextField()
    view.translatesAutoresizingMaskIntoConstraints = false
    view.borderStyle = .RoundedRect
    view.textAlignment = .Center
    
    return view
}()

We set translatesAutoresizingMaskIntoConstraints to false in order to set our own custom constraints for the text field. Additionally, we set the borderStyle to RoundedRect to style the text field the way we want it.

Now, within the viewDidLoad method, which is executed immediately after the view is created and loaded on screen — add the following line to introduce your text field.

view.addSubview(textField)

Now that you have instantiated the text field, we need to tell it where to display on the screen. In order to do this, we will use a tool provided by Apple called AutoLayout.

Auto Layout dynamically calculates the size and position of all the views in your view hierarchy, based on constraints placed on those views. For example, you can constrain a text field so that it is horizontally centered within a view and so that the text field’s top edge always remains 8 points below the view’s top. If the view’s size or position changes, the text field’s position automatically adjusts to match.

In order to introduce your AutoLayout code, we need to override some built-in Apple layout methods. In order to do so, add the following line to your viewDidLoad method:

view.setNeedsUpdateConstraints()

Now, add the following method to your MainViewController class:

override func updateViewConstraints() {
    super.updateViewConstraints()
}

The updateViewConstraints method is called when the view controller’€™s view needs to update its constraints. In order to add our own constraints, we override this method. Now, create a new method called textFieldConstraints under the updateViewConstraints and add the following constraints that will properly place our text field within our view.

Finally, add the following line to updateViewConstraints in order to call the layout code for our text field. Be sure to add it above the super.updateViewConstraints method.

override func updateViewConstraints() {
    textFieldConstraints()
    super.updateViewConstraints()
}

Your MainViewController class should now look like this:

If you run the app, you should now see the text field at the top of the screen. Clicking inside will bring up the keyboard and allow you to type. While the keyboard appears automatically, we have to add to code make it disappear ourselves.

The key is implementing a “delegate method” of the UITextField. Delegate methods are like helper functions for the objects in your application, and can sometimes help pass data between two classes. The delegate method we need to dismiss the keyboard is called “textFieldShouldReturn”, a function that is called every time the user presses the “return” button on the keyboard.

Information about a class’s delegate methods is in Apple’s documentation. You can find the “textFieldShouldReturn” method in the UITextFieldDelegate reference article.

Add it below your viewDidLoad method:

func textFieldShouldReturn(textField: UITextField!) -> Bool {

}

Dismiss the text field programmatically by adding the following lines:

func textFieldShouldReturn(textField: UITextField) -> Bool {   

   // Dismisses the Keyboard by making the text field resign
   // first responder
   textField.resignFirstResponder()
   
   // returns false. Instead of adding a line break, the text 
   // field resigns
   return false
}

We need to do a few more things before this works. Go back to the viewDidLoad method where you added the text field. Right below super.viewDidLoad() line, add

textField.delegate = self

This lets the application know where to look for the implementation of the delegate methods, which in this case is inside Self — a reference to our MainViewController class.

The last thing we need to do is update the “MainViewController.swift” file. There, you’ll find the line:

class MainViewController: UIViewController {

Change it to:

class MainViewController: UIViewController, UITextFieldDelegate {

This tells the MainViewController that it implements delegate methods of a UITextField object. The MainViewController should now look like

Run the app — pressing the return button should now dismiss the text field.

2. The Button

Now, add the button in the viewDidLoad method as well. Ensure that you add the button below the textField creation.

view.addSubview(textField)
view.addSubview(button)

Similarly, we’ll lazily instantiate the button. Add the following below the lazy instantiation of the text field.

lazy var button: UIButton! = {
    let view = UIButton()
    view.translatesAutoresizingMaskIntoConstraints = false
    view.addTarget(self, action: "buttonPressed", forControlEvents: .TouchDown)
    view.setTitle("Press Me!", forState: .Normal)
    view.backgroundColor = UIColor.blueColor()

    return view
}()

This takes care of most of the button’s properties. The addTarget, action, forControlEvents method allows you to specify a function that’s called when the button is pressed. The target is the object to which the action message is sent — in this case, self. The action performed after the button is pressed is identical to what would happen if you called

buttonPressed()

Wrapped in quotes is the name of the function to be called when the button is pressed — we still need to implement this.

The control event specifies the type of interaction required to trigger the button. Apple’s “UIControlEventTouchDown” is the way to specify just a simple tap.

We also need to add the layout constraints for the button. Add a buttonConstraints method below the textFieldConstraints method

Additionally, add the method call to the updateViewConstraints method.

override func updateViewConstraints() {
    textFieldConstraints()
    buttonConstraints()
    super.updateViewConstraints()
}

Now we can create the shell of the buttonPressed function. We need to create the label before we can implement the full thing.

In between viewDidLoad and textFieldShouldReturn, create the buttonPressed method:

func buttonPressed() {
 
}

We’ll come back to this after we create the label.

3. The Label

I’ve saved the easiest for last. We’ll create the label below view.addSubview(button) line in viewDidLoad

view.addSubview(textField)
view.addSubview(button)
view.addSubview(label)

Now to lazily instantiate the label:

lazy var label: UILabel! = {
    let view = UILabel()
    view.translatesAutoresizingMaskIntoConstraints = false
    view.text = “Hello World!”
    view.textAlignment = .Center
    
    return view
}()

add a labelConstraints method below the textFieldConstraints method

Finally, add the method call to the updateViewConstraints method.

override func updateViewConstraints() {
    textFieldConstraints()
    buttonConstraints()
    labelConstraints()
    super.updateViewConstraints()
}

Run the app, and you should see the familiar “Hello World!” above your button.

4. Changing the Label Text

Only one thing left to do. Since you’ve already created the shell of the button pressed method, we just have to add a line that sets the label text equal to the string in the text field. This is done with one line inside buttonPressed:

func buttonPressed() {
    // Print Hello followed by the user inputed string
    // The exclamation point is added to unwrap the optional
    label.text = "Hello, \(textField.text!)"
}

You can print a value within a string by adding

\(yourValue)

with your value in parenthesis. This is demonstrated in the buttonPressed method above.

That’s it! Run the app and try it out.

At the end of this tutorial, you will have an app that looks like the one on the left. Upon clicking on the text field at the top, the system-provided keyboard appears and the user may type in their name. The user may then dismiss the keyboard by clicking “Done.” Finally, when the user clicks “Hello,” the label displays “Hello,” followed by the user’s name.

The first step is to open Xcode and click on “Create a new Xcode project” In this tutorial, I am using version 7.2.

We’re going to use a “Single View Application.”

Fill out the relevant fields. Depending on your preference, you may select a specific device. We will be using Swift here. Core Data is not required and not recommended for this tutorial.

Prior to saving your project to your computer, ensure that “Create Git repository on” is checked and “My Mac” is selected.

By default, “Single View Application” is oriented towards using storyboards. Xcode creates some default files for us including “Main.storyboard” and “ViewController.swift.” With these files already hooked up, our app is ready to go.

If you click on the Run button in the top left, your application should build with a blank white screen.

This is all good and well but our application doesn’t show us anything.

However, we now have a view to modify both visually through our storyboard file and programmatically through our .swift file. In the next part of this tutorial, we’ll handle all of the on-screen elements.

Part 2 is coming soon!

To learn more about my work, visit my website.

To develop iOS apps natively, you need a Mac computer (OS X 10.10 or later) running the latest version of Xcode. Xcode includes all the features you need to design, develop, and debug an app. Xcode also contains the iOS SDK, which extends Xcode to include the tools, compilers, and frameworks you need specifically for iOS development.

Download the latest version of Xcode (currently 7.2) on your Mac free from the App Store.

To download the latest version of Xcode

1. Open the App Store app on your Mac (by default it’s in the Dock).
2. In the search field in the top-right corner, type Xcode and press the Return key.
3. The Xcode app shows up as the first search result.
4. Click Get and then click Install App.
5. Enter your Apple ID and password when prompted.
6. Xcode is downloaded into your /Applications directory.

Once you have downloaded Xcode, you are now ready to begin building your first iOS application. If you’d like to jump right into building your first app, please continue to one of the following tutorials. Each tutorial will have you build out the same app; the difference, however, will be which tools you utilize for building out the user interface (UI). The UI will be what your users see, what your app visually looks like.

Xcode provides two options for building out your UI, programmatic and Interface Builder. Furthermore, Interface Builder allows two sub-options, storyboards and XML Interface Builder (XIBs). So really, that makes three options for UI development (programmatic, storyboards, and XIBs). There are numerous pros and cons to each option but I won’t go into that here. If you’d like to learn more about the differences, please see my talk on Front End iOS Development at Blue Run Ventures.

Additionally, Xcode let’s you build your app with up to 2 languages, Swift and Objective-C. You may develop exclusively using one language or using a mixture of both. For simplicity, each of the following tutorials uses only one language at a time.

Please Note: At MHacks Refactor, I will be advocating the use of Swift and XIBs, the first option below.

Next Steps:

Interface Builder Options:

1. Your First iOS App: Using Interface Builder via XIBs (Xcode 7.2, Swift 2.1)
2. Your First iOS App: Using Interface Builder via Storyboards (Xcode 7.2, Swift 2.1)

Programmatic Options:

1. Your First iOS App: 100% Programmatically (Xcode 7.2, Swift 2.1)
2. Your First iOS App: 100% Programmatically (Xcode 7.2, Objective-C)

This is Part 1 of a tutorial that follows Apple’s old “Your First iOS App” tutorial, but implements all of the user interface elements programmatically using Swift. View Part 2 or check out the complete code on Github. This tutorial is ported from an Objective-C implementation by Austin Louden. If you prefer Objective-C, please see Part 1 and Part 2 of that tutorial.

To learn more about my work, visit my website.

At the end of this tutorial, you will have an app that looks like the one on the left. Upon clicking on the text field at the top, the system-provided keyboard appears and the user may type in their name. The user may then dismiss the keyboard by clicking “Done.” Finally, when the user clicks “Hello,” the label displays “Hello,” followed by the user’s name.

The first step is to open Xcode and click on “Create a new Xcode project” In this tutorial, I am using version 7.2.

We’re going to use a “Single View Application.”

Fill out the relevant fields. Depending on your preference, you may select a specific device. We will be using Swift here. Core Data is not required and not recommended for this tutorial.

Prior to saving your project to your computer, ensure that “Create Git repository on” is checked and “My Mac” is selected.

By default, “Single View Application” is not oriented for programmatic user interface development. Xcode creates some default files that we don’t want. Let’s go ahead and delete “Main.storyboard” by selecting it and clicking “delete” on the keyboard. When prompted, select “Move to Trash” instead of “Remove Reference.” Additionally, let’s go ahead and delete “ViewController.swift.”

In order to truly rid ourselves of the storyboard world, we need to modify the “info.plist.” Expand the sub-folder titled “Supporting Files” by clicking on the adjacent triangle. Select the file within the “Supporting Files” folder titled “Info.plist.” Select the row with the text “Main storyboard file base name” and delete it by hitting your “delete” key.

Now that we are free of the oppressive shackles of the storyboard, navigate to the “AppDelegate.swift” file by clicking the file browser on the left side of the screen.

The App Delegate file is your application’s way of communicating with the operating system, and includes several useful methods.

We’ll mostly be dealing with “application: UIApplication, didFinishLaunchingWithOptions launchOptions:”, which is called immediately after the application launches.

If you click on the Run button in the top left, your application should build with a blank white screen.

This is all good and well but our application doesn’t show us anything.

In order to begin building an app programmatically, we’ll need to introduce a ViewController class. Click ⌘N to create a new file.

In the “Source” under “iOS,” select Cocoa Touch Class and click “Next.”

You can choose the name of your class, but make sure to set it as a subclass of UIViewController below. I named mine “MainViewController”. The UIViewController is a fundamental class of iOS development, and is used to make and handle interaction with elements in the user interface. Ensure “Swift” is selected under “Language.” Click Next, and then Create.

You’ll notice that a new file has appeared in the Navigator on the left, “MainViewController.swift.” This file will include both your user interface and business logic code for this tutorial. You’ll also notice that “MainViewController.swift” has some boilerplate code.

We’ll come back to that in a bit — for now, go back to your “AppDelegate.swift” file.

Firstly, let’s take a look at the “application: UIApplication, didFinishLaunchingWithOptions launchOptions:” method — we’ll want to add some code matching the snippet below:

Line 4 instantiates an object of the UIWindow class set to the bounds of the iPhone’s screen.

Line 7 instantiates an object of our MainViewController class called “mainViewController.”

Line 10 sets “viewController” as the window’s root view controller.

Finally, line 13 makes the window visible.

Running the app again should give you a white screen and now you have a view to modify programmatically. In the next part of this tutorial, we’ll handle all of the on-screen elements.

Continue to Part 2

This is Part 1 of a 3 Part tutorial that follows Apple’s old “Your First iOS App” tutorial, but implements all of the user interface elements via XML Interface Builder (XIBs) using Swift. View Part 2 or check out the complete code on Github.

To learn more about my work, visit my website.

At the end of this tutorial, you will have an app that looks like the one on the left. Upon clicking on the text field at the top, the system-provided keyboard appears and the user may type in their name. The user may then dismiss the keyboard by clicking “Done.” Finally, when the user clicks “Hello,” the label displays “Hello,” followed by the user’s name.

The first step is to open Xcode and click on “Create a new Xcode project” In this tutorial, I am using version 7.2.

We’re going to use a “Single View Application.”

Fill out the relevant fields. Depending on your preference, you may select a specific device. We will be using Swift here. Core Data is not required and not recommended for this tutorial.

Prior to saving your project to your computer, ensure that “Create Git repository on” is checked and “My Mac” is selected.

By default, “Single View Application” is not oriented towards using xibs. Xcode creates some default files that we don’t want. Let’s go ahead and delete “Main.storyboard” by selecting it and clicking “delete” on the keyboard. When prompted, select “Move to Trash” instead of “Remove Reference.” Additionally, let’s go ahead and delete “ViewController.swift.”

In order to truly rid ourselves of the storyboard world, we need to modify the “info.plist.” Expand the sub-folder titled “Supporting Files” by clicking on the adjacent triangle. Select the file within the “Supporting Files” folder titled “Info.plist.” Select the row with the text “Main storyboard file base name” and delete it by hitting your “delete” key.

Now that we are free of the oppressive shackles of the storyboard, navigate to the “AppDelegate.swift” file by clicking the file browser on the left side of the screen.

The App Delegate file is your application’s way of communicating with the operating system, and includes several useful methods.

We’ll mostly be dealing with “application: UIApplication, didFinishLaunchingWithOptions launchOptions:”, which is called immediately after the application launches.

If you click on the Run button in the top left, your application should build with a blank white screen.

This is all good and well but our application doesn’t show us anything.

In order to begin building an app with XIBs, we’ll need to introduce a ViewController class. Click ⌘N to create a new file.

In the “Source” under “iOS,” select Cocoa Touch Class and click “Next.”

You can choose the name of your class, but make sure to set it as a subclass of UIViewController below. I named mine “MainViewController”. The UIViewController is a fundamental class of iOS development, and is used to make and handle interaction with elements in the user interface. Ensure that “Also create XIB file.” Additionally, make sure “Swift” is selected under “Language.” Click Next, and then Create.

You’ll notice that two files have appeared in the Navigator on the left, “MainViewController.swift” and “MainViewController.xib.” “MainViewController.swift” is the programmatic end of MainViewController while “MainViewController.xib” is it’s graphical user interface counterpart in which we can drag and drop user interface elements including layout constraints. You’ll also notice that “MainViewController.swift” has some boilerplate code.

We’ll come back to those in a bit — for now, go back to your “AppDelegate.swift” file.

Firstly, let’s take a look at the “application: UIApplication, didFinishLaunchingWithOptions launchOptions:” method — we’ll want to add some code matching the snippet below:

Line 4 instantiates an object of the UIWindow class set to the bounds of the iPhone’s screen.

Line 7 instantiates an object of our MainViewController class called “mainViewController.”

Line 10 sets “mainViewController” as the window’s root view controller.

Finally, line 13 makes the window visible.

Running the app again should give you a white screen and now you have a view to modify both visually through your XIB file and programmatically through your .swift file. In the next part of this tutorial, we’ll handle all of the on-screen elements.

Continue to Part 2

Part 1

This is an updated version of a tutorial created by Austin Louden. This tutorial follows Apple’s old “Your First iOS App” tutorial, but implements all of the user interface elements programmatically in Xcode 7.2.

Austin was kind enough to create a two-part tutorial but part 1 is quite outdated. This article is simply an updated version of part 1 and still leads into Austin’s part 2 which can be found here. As such, much of this article is paraphrased from his part 1.

To learn more about my work, visit my website.

This tutorial is intended for developers transitioning to iOS that don’t want to deal with Storyboarding or Interface Builder. It implements the “Hello World” app from Apple’s documentation entirely in code.

At the end of this tutorial, you will have an app that looks like the one on the left. Upon clicking on the text field at the top, the system-provided keyboard appears and the user may type in their name. The user may then dismiss the keyboard by clicking “Done.” Finally, when the user clicks “Hello,” the label displays “Hello,” followed by the user’s name.

The first step is to open Xcode and click on “Create a new Xcode project” In this tutorial, I am using version 7.2.

We’re going to use a “Single View Application.”

Fill out the relevant fields. Depending on your preference, you may select a specific device. We will be using Objective-C here. Core Data is not required for this tutorial.

Prior to saving your project to your computer, ensure that “Create Git repository on” is checked and “My Mac” is selected.

By default, “Single View Application” is not programmatically oriented. Xcode creates some default files that we don’t want. Let’s go ahead and delete “Main.storyboard” by selecting it and clicking “delete” on the keyboard. When prompted, select “Move to Trash” instead of “Remove Reference.” Additionally, let’s go ahead and delete “ViewController.h” and “ViewController.m.”

In order to truly rid ourselves of the storyboard world, we need to modify the “info.plist.” Expand the sub-folder titled “Supporting Files” by clicking on the adjacent triangle. Select the file within the “Supporting Files” folder titled “Info.plist.” Select the row with the text “Main storyboard file base name” and delete it by hitting your “delete” key.

Now that we are free of the oppressive shackles of the storyboard, navigate to the AppDelegate.m file by clicking the file browser on the left side of the screen.

The App Delegate file is your application’s way of communicating with the operating system, and includes several useful methods.

We’ll mostly be dealing with “application didFinishLaunchingWithOptions”, which is called immediately after the application launches.

If you click on the Run button in the top left, your application should build with a blank white screen.

This is all good and well but our application doesn’t show us anything.

In order to begin building an app programmatically, we’ll need to introduce a ViewController class. Click ⌘N to create a new file.

In the “Source” under “iOS,” select Cocoa Touch Class and click “Next.”

You can choose the name of your class, but make sure to set it as a subclass of UIViewController below. I named mine “MainViewController”. The UIViewController is a fundamental class of iOS development, and is used to make and handle interaction with elements in the user interface. Ensure “Objective-C” is selected under “Language.” Click Next, and then Create.

You’ll notice that two files have appeared in the Navigator on the left, “MainViewController.h” and “MainViewController.m.” Each file has some boilerplate code.

We’ll come back to those in a bit — for now, go back to your AppDelegate.m file.

First, make sure to import your MainViewController class at the top of the AppDelegate.m file:

Next, let’s take a look at the “application didFinishLaunching” method — we’ll want to add some code matching the one below

Line 3 instantiates an object of the UIWindow class set to the bounds of the iPhone’s screen.

Line 6 sets the background color of the window to white.

Line 8 instantiates an object of our MainViewController class called “viewController.”

Line 10 sets “viewController” as the window’s root view controller.

Finally, line 12 makes the window visible.

Running the app again should give you a white screen and now you have a view to modify programmatically. In the next part of this tutorial, we’ll handle all of the on-screen elements.

Part 2 of this tutorial is provided by @austinlouden. I hope you found this tutorial helpful in understanding programmatic iOS development.

Continue to Part 2

Recently, I have had quite a few people reach out to me regarding my crowd-funding campaigns (LA Hacks and YC Hacks) that I have used to get to my last two hackathons. Usually, hackers, concerned about travel expenses to a specific hackathon, ask me to share some of my strategies in successfully funding flights up to $850. This post aims to shed light on some of my go-to strategies regarding crowd-funding and provide guidance to hackers who are interested in giving it a shot.

A major expense for most hackathon organizers is travel reimbursement. The only thing worse than the allocation is the distribution. Usually, a hacker will only receive the funds well after the hackathon and only if they submit a hack during the competition. Thus, hackers are often forced to cover transportation and cross their fingers hoping that the funds show up in their bank accounts soon after the event. Flights are a very popular means of transportation but it is important to be mindful of the alternatives.

Generally, you should only start a crowdfunding campaign as an absolute last resort. Take some time to explore the multitude of travel options available based on your given situation. Major League Hacking (MLH) provides busses for a multitude of hackathons from various locations so reach out to them and see if there is one near you! Additionally, car-pooling and trains can be utilized to reduce costs. If you still need funds then you may consider crowdsourcing.

As a last resort, I started a Go Fund Me campaign from my girlfriend’s couch to attend LA Hacks in the Spring of 2014. I did not receive sufficient funding and even pulling strings didn’t get me anywhere near the $850 plane ticket from State College to Los Angeles. After launching the campaign, I messaged the organizers saying that I probably wouldn't be able to make the event despite the invitation. Much to my surprise, five hours later I had booked my flight to Los Angeles and was as giddy as a schoolgirl! For the next few weeks, I began to be referred to as “the guy who crowdsourced his way to LA Hacks.”

I saw this as a fluke and continued applying to hackathons with the hopes that I would never have to deal with funding issues again. And then, a few months later, I was accepted to Y-Combinator’s (YC) hackathon, YC Hacks!

At first, I was extremely excited but then I realized I was basically broke and YC wasn't offering any travel reimbursement. After exploring every last option, I turned, once again to crowdsourcing, this time using Tilt. I included some new sponsor prize ideas and set a modest goal of $600. With a better understanding of when people donated the most to a campaign, I was able to raise $610 in four days! At this point I knew I was onto something.

Now, you may ask, how can I do this?! It’s a simple three-step process. Start by understanding that hackathon goers are a community. Everyone wants to share the magic of hackathons with people, especially if that means getting you to a hackathon. Next, create a campaign with the goal of giving back. This is very important! If you simply ask for money, you are no better than a bum but if you offer something in return, you can be part of a community. Finally, thank your supporters and remember to pay it forward. Technically speaking, do the following:

1. Go to www.tilt.com and create an account, preferably by logging in with Facebook.
2. Click the “Create campaign” tab and select “Collect of Fundraise.”
3. Set the “minimum amount to tilt” and the “target amount.” Be sure to set “minimum amount to tilt” to $1 to ensure you get some money even if you don't reach your goal. The target amount should be your travel costs. Keep in mind, Tilt takes 2.5% of the money you raise so pick a target amount that includes this fee.
4. Select “Any amount is fine” and leave the next four bullet points empty.
5. Set an expiration date to approximately three weeks before your expected travel date to ensure that prices don't spike.
6. Create a captivating but simple “Title” for your campaign.
7. For the “Description,” you should introduce why you are crowd sourcing with about a paragraph and why this event is important to you. Following this paragraph, you should list multiple prizes for different amounts that people donate. Prizes may include teaching people to code, doing some basic freelance work, or something creative relating to your hack at the event. Remember, this is all about giving back!
8. Be sure to upload an image or a video to give your audience a visual representation of your campaign and so it stands out on social media.
9. Leave everything else as-is and hit “Create Campaign.”
10. Proceed to share this link on every single social media platform, in any groups you contribute heavily to, and especially with your family and friends! As you can see, my greatest contributors were relatives and friends. The most money is raised at the beginning and end of your campaign so be consistent with media posts and let people know if you are close! Encourage people to share your campaign if they can’t donate and definitely encourage those who donated to share. The more people that see your campaign, the better.
11. Finally, personally thank everyone that helped with your campaign even if you didn’t reach your target amount. They are all amazing people and they believe in you! Remember to pay it forward when you see a friend in need of a little help ☺

Once again, I recommend exploring all options prior to considering crowdsourcing as an option. Try getting the hackathon organizers to match the amount you raise so you don’t need to ask for too much. I wish you all the best of luck and I hope this post helped you in determining what option is best for your case. Never stop building.