Ever considered developing an iOS app, but not sure where to start? In this 360|AnDev presentation, Sarah Olson provides a brief overview of developing an app in iOS9 using Swift 2 and discusses some of the differences from Android development, including design considerations, navigation idioms, IDEs, layout, and deployment. Get tips and tricks on learning Swift and iOS, including Swift Playgrounds, blogs, podcasts, online courses and more. Sarah also shares her story of moving from a decades-long career in Java development to full-time mobile development, and why she chose iOS over Android as her primary platform.

Introduction (0:00)

I’m Sarah Olson, a senior software engineer at the Nerdery. I’m also director of Women Who Code in the Twin Cities. Today I’m going to give you a brief introduction to iOS development. I know that there’s a lot of contention between iOS and Android, so thank you for coming to the dark side. Or the light side probably. Android seems more dark themed.

The hardest part that I find when learning something new is not having the vocabulary I need to find the information. I’m trying to search on Stack Overflow and the internet, but I don’t know the words to use. And when I have had mentors at work or in other spaces, they have provided me with that vocabulary. I have this thing I’m trying to search for it; I can’t find anything; and they go to Google and type in the words that magically make the information appear.

Over time you learn what words to use. My goal for today is to give you some words. Then you can take those words and learn more about iOS. There are a lot of great tutorials out there. There’s a lot of information. I’m not going to get super coding specific. We’re not going to create an app today.

I want to give you an overview of what the platform is like, what kind of hurdles you’ll run into, and how it relates to Android.

You need a Mac (1:33)

The first rule of iOS development is that you need a Mac. I’m sorry, you’re not going to get Xcode on anything else. You need a Mac. When I started out, I was a backend Java developer for fifteen years; I was heavily into database administration, XML processing, all very backend-y things. But I was really interested in mobile.

When I started at the Nerdery, four years ago, I wanted to learn mobile. At the time we had a huge demand for iOS work, so I started that first. I probably would have picked Android if I’d had the choice back then, but I actually really fell in love with iOS development. It’s much more visual. There’s a lot of aspects to it that drew me in over Android development.

I’ve done both. I haven’t done a heavy amount of real Android development. It’s been a lot of tinkering and tutorials. I think I fixed one bug at work in Android, so that’s the extent of my real world Android development experience. But I do know the platform a little bit. I work with Android guys every day. I see their code.

Apple will become both your best friend and your worst enemy. It’s like a marriage that’s working but kind of not. At first you fall in love and you’re like, “This is amazing.” You’re so dependent on Apple that it’s great when everything works, but when it doesn’t, you’re stopped in your tracks. Some of the pain points are unavoidable because there are no other options. You’re stuck with Apple.

It’s a good and bad thing. You don’t have the crazy amount of devices that you have to support in Android. You don’t have to support all these different versions and flavors of Android. Another good thing is the high adoption rate. When Apple releases a new version of iOS people switch really quickly; they don’t stick to some of the older versions for very long.

Apple helps this along. They’re super annoying with their upgrade messages now: “We stopped supporting old devices and you kind of are stuck.” I have an iPad mini 1 and I can’t get iOS 10 on it and I’m heartbroken. But that’s Apple.

These are all the devices that you really support. There are a few older versions that you might need to support as well. But this is what you have to test on. For the iPhone there are four different screen sizes, and that’s it. For iPad you have three. A couple of them are doubled up. There’s really not a lot of variability compared to the Android space. Here are all the devices that are currently in use.

Now this is an app developer who released these statistics, because Apple doesn’t really get this granular. But this is what he’s seeing on his app and it seems fairly consistent across other apps. There are a few older devices out there, but the majority of people are on the current ones. Here is the same thing for the iPad.

Here are all the current versions of Xcode, iOS and Swift. The new versions are in beta. They’ll probably be released sometime in September. There will be two new versions of Swift. Swift 3 is being called “the grand renaming” by Apple. There will be a lot of changes, and very big breaking changes. They’re releasing 2.3 to help with that transition period, so people can still get some of the new functionality but not have to deal with the colossal renaming.

Swift has been changing quite a bit. We actually were developing an app during their beta last year. It was awful because every two weeks they changed again, but it’s also good for advancing the language. Play around with the beta. Just don’t develop a real app on beta.

Xcode is the IDE that you will mainly use for iOS development. It’s free and provided by Apple. It is a huge beast of an app. It’s not super well documented. I think that was one of my biggest pain points. How do I actually do all this stuff in here? It’s something that just takes trial and error, and hopefully you have a mentor. But it has a lot of really cool functionality in it.

There’s also AppCode. This is a JetBrains product. If you’ve used IntelliJ or Android Studio it will look very familiar to you. The problem with AppCode is that it doesn’t have a lot of the features that Xcode has. If you’re going to be doing any design work in the app with either story boards or nibs and zibs, which are the design files that we have, it will actually open up Xcode because it doesn’t have that functionality. Same with Core Data, which handles persistence within Xcode: AppCode doesn’t have that framework, so that would open up in Xcode as well.

For the most part, if you’re doing stuff in AppCode, it’s going to be more backend processing logic kind of stuff. It does really well at refactoring and renaming things, which Xcode is not so good at. A lot of developers will mostly work in Xcode, and then when they have to do some more refactoring stuff, will open up AppCode. It’s not free. You have to purchase it. I don’t remember how much it is–$100 or $200. I only know a few iOS developers that use it, because most of the functionality you can get from Xcode.

iOS mostly subscribes to the MVC pattern. We have view controllers that are where we put most of our logic models for persistence and database and business functionality; the views are called views. That’s where we put our visual stuff. You’ll see a lot of that familiar terminology.

Swift versus Objective-C (8:36)

A lot of apps, frameworks, and libraries are written in both Swift and Objective-C, but most new projects now are developed in Swift. Most people have made that jump to the new programming language. Swift was created by Apple, but it’s now open-source.

You can use both Swift and Objective-C within your app at the same time. If you have an old Objective-C app and you want to slowly bring it up into Swift, you can do so incrementally. Swift is much closer to Java than Objective-C would be, so the learning curve going from Java will be much smaller. Swift is cleaner and it’s easier to read and easier to maintain. It’s safer with its use of optionals. Faster.

Here’s just a little bit about the difference between the two.

Swift

func getLabelText() -> String? {
	return helloLabel.text
}

Objective-C

- (NSString *)getLabelText
{
  return self.textLabel.text;
}

At the top is what a basic function looks like in Swift. And at the bottom is the Objective-C version. Objective-C uses pointers, so when you see the stars that’s pointer notation. That was a bit hard to wrap my head around. We don’t have to deal with that in Swift.

Here’s an example of a very basic view controller with just a label.

Swift

import UIKit

class FirstViewController: UIVewController {
	@IBOutlet var helloLabel: UILabel!

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

Objective-C

EventsViewController.h

#import <UIKit/UIKit.h>

@interface EventsViewController : UIViewController

@end

EventsViewController.m

#import "EventsViewController.h"

@interface EventsViewController ()

@property (weak, nonatomic) IBOutlet UILabel *helloLabel;

@end

@implementation EventsViewController

- (void)viewDidLoad
{
	[super viewDidLoad];
}
@end

In Swift we have this small, concise bit of code. With Objective C we actually have two files: we have a header file and an implementation file. So a .h and a .m. The .h is the interface, defining what properties can be accessed outside of the .m file. If it’s in the .m you can’t reach it from other classes, so it’s making it public. It was hard to deal with and manage twice as many files. Swift is much more concise, easier to use and maintain. I like it a lot more.

Closures

In Swift, closures are used pretty extensively and they’re very nice. This is just passing in a block of code to a function where you can return it from a function. It’s passing it around instead of only using variables. Closures in Swift are similar to blocks in C and Objective-C.

func applyMultiplication(calue: Int, multFunction: Int -> Int) -> Int {
	return multFunction(value)
}

applyMultiplication(2, multFunction: {value in
	value * 3
})

Tuples

Tuples aggregate a bunch of variables within one. This allows us to return multiple values from a function using a tuple.

let person = (firstName: "John", lastName: "Smith")

let firstName = person.firstName // John
let lastName = person.lastName // Smith

func getPersonName() -> (String, String) {
	return person
}

At the top I’ve defined a person with a first name and a last name. I can actually access those through person.firstName or person.lastName. Then if I call getPersonName() I can return that object because it conforms to that string format.

Optionals

Optionals are amazing and horrible at the same time. It’s a pretty steep learning curve to figure out exactly how to use them and not destroy your app. But it’s gotten a lot better then when Swift first came out. They were changing the format a lot, so every time you get a new release it would break everything. This was in beta. But they’ve finally figured that out now.

var firstName: Strong? = "Sarah"

if let firstNameValue = firstName {

	// there is an value
	print("My first name is: \(firstNameValue)")
  
} else {
	
	//firstName is nil
}

With Objective-C you could pass a nil value to something and it would ignore it. There were a lot of problems trying to figure out why something wasn’t working because it would just be like, “yeah, that’s fine, whatever” when you actually expected a value somewhere.

With Swift they’re making sure, does this always have a value or does it not? And you have to be very careful if anything is optional that you’re always “unwrapping” it. That if let statement is what they call unwrapping: getting the value out of here if there is one, otherwise do something else.

Generics

func swapTwoValues<T>(inout a: T, inout _ b: T) {
	let temporaryA = a
	a = b
	b = temporaryA
}

var someString = "hello"
var anotherString = "world"

swapTwoValues(&someString, &anotherString)

// someString is now "world", and anotherString is now "hello"

Generics are something you probably know from Java. Swift has that as well. This is being able to pass in an object of any type and be able to perform functions on it not knowing the explicit class.

Protocols

public protocol UITableViewDelegate : NSObjectProtocol, UIScrollViewDelegate {
	
	// Called after the user changes the selection.
	@available(iOS 2.0, *)
  optional public func tableView(tableView: UITableView,
                                 didSelectRowAtIndexPath indexPath: NSIndexPath)
}

extension FirstViewController: UITableViewDelegate {
	
	func tableView(tableView: UITableView,
                 didSelectRowAtIndexPath indexPathL NSIndexPath) {

		// do something
	}
}

Protocols are used really heavily in both Objective-C and Swift. It’s the interface for Java. You’re defining this thing that must have these methods or functions. You’ll see this a lot with table views and other objects that Apple provides to you. When you’re using a table view you have a table view delegate. When things happen to that table view, it will call these delegate methods, and that’s how you respond to a user selecting a cell or other functionality like that.

Last year at WWDC, the Apple Worldwide Developer Conference, they did a session on protocol-oriented programming. That was really good. I would recommend watching that if you get into iOS development.

Extensions

import UIKit

public extension UIColor {
		
		public convenience init(_ rgbHex: UInt, alpha: CGFloat = 1.0) {

			letrawRed = Double((rgbHex >> 16) & 0xFF) / 255.0
			letrawGreen = Double((rgbHex >> 8) & 0xFF) / 255.0
			letrawBlue = Double((rgbHex >> 0xFF) / 255.0

			self.init(red: CGFloat(rawRed),
						green: CGFloat(rawGreen),
						blue: CGFloat(rawBlue),
						alpha: alpha)
		}

		// mARK - Theme colors

		static func labelBackgroundColor() -> UIColor {
			return UIColor(0x802023)
		}
}

Extensions are really fun. This is taking an existing class: UIColor is a class that Apple provides. It’s an implementation of a color. We created a new initializer to pass in a hex code because we use hex codes a lot. We can pass that in to UIColor to get the correct color that we want. Then from there beneath it we have different themes.

We always want our labels to have a certain background color. When we set the color we can say UIColor.labelBackgroundColor and then it knows exactly which color we picked. Using extensions, you can add functionality to existing classes that you don’t really own.

Vocabulary lesson (15:16)

More vocabulary. Screen elements. Android names things differently. Some of the things are similar, some are not.

If you look at the screen, the very top 20 pixels is the status bar. It has your WiFi signal, the time, and a battery status. Beneath that is the navigation bar. Navigation bars are for navigating between screens in a hierarchical fashion. So I’m going this way or I’m going this way, but I can’t jump around or do anything else. It’s that kind of backward-forward motion.

Beneath that is called a collection view. We have table views and collection views in iOS. Table views are the list format. Collection views are used more for images and other data that is grouped like this. The dates between those images are sections, so the collection view has sections and then cells within each section. Each image is an instance of a cell. Each of those dates is an instance of a section and cells belong to a particular section.

At the very bottom is the tab bar. I’ve heard that Android is adding a tab bar for the next release. But otherwise it’s been pretty much an iOS thing. It’s very common in iOS, so you see it a lot.

Let’s talk about navigation. Most apps are broken up through tab bars and through navigation controllers. The tab bars are used to create landing pages for different areas of content. I want all this content grouped here, I want all this content grouped here. Clicking on a tab will get you to that landing page. Then from there you would use a navigation controller to navigate through that data. That’s a very typical design pattern that we use.

Another navigation element that you’ll see is the page view controller. You can see something that looks like pages and it has that curl when you’re flipping through. But you can also see how that slides instead. I see that a lot with onboarding pages, when people are giving a walkthrough of the app’s functionality. You can see at the bottom there’s a series of dots that’s a page control that you usually see with the page controller. You see that on a home screen of an iOS device when you slide through the different pages of your apps. That’s what that element is.

We don’t have tabs in iOS. We have segmented controls. Clicking on those different buttons would show different content usually. And then there is a toolbar at the bottom. This is not a tab bar. It’s not actually for navigation. For example, with mail, doing actions so you’re not moving the user around. You’re performing actions.

Storyboards are for the most part how we lay out the flow of our app. It’ll tell you how screens navigate to other screens. It’ll show your design elements. It’ll show your constraints. How your elements grow or shrink and where they’re located. Are they connected to the top by 20 pixels or do they have a specific height or do they grow? All those different things are usually done in either storyboards or you can have a nib or zib depending on what you like to call it.

That’s basically one screen at a time so it doesn’t have the navigational stuff, which we call segues. There are two ways to do that. Most people have moved to storyboards now because we have this concept of storyboard references. Storyboard references are on the right there. So I have a tab bar here, it’s got a bunch of tabs. And when they click on those tabs it opens up a new storyboard to get that functionality. We’re breaking up the storyboard into more manageable chunks.

The reason this is really important is we have lots of problems with merged conflicts with storyboards. It generates XML behind the scenes. When you have multiple developers working in the same storyboard and you’re trying to figure out which thing wins and which doesn’t, with storyboards it’s really terrible. We try to break things up as much as we can. Storyboard references was new last year with iOS 9, so that’s why we’re seeing a lot more of it now.

Interface Builder is within Xcode. It’s the thing that shows the storyboards or zibs and nibs. It’s a drag-and-drop tool. You can take elements, drag them under the screen, and you create constraints by dragging lines to other views or to different areas. There’s a lot of dragging. You can also add elements programmatically.

import UIKit

class FirstViewController: UIVewController {
	
	override func viewDidLoad() {
		super.viewDidLoad()

		// Create and add button
		let testButton = UIButton(type: .Custom)
		testButton.setTitle("Test Button", forState: .Normal)
		testButton.addTarget(self, action: @selector(testButtonFunction),
			forControlEvents: .TouchUpInside)
		self.view.addSubview(testButton)
	}

	func testButtonFunction(sender: AnyObject) {
		print("The test button was tapped.")
	}
}

In this example I have a view controller and then I added a button to it. This is just adding the button to the view, but it’s not telling it exactly where that button should go or how it should grow or any of that. This is pretty basic functionality.

Then I also added a target to it. What happens when someone clicks that button and it calls the test button function? This is what a storyboard looks behind the scenes. There’s lots of generated identifiers and other things. It’s pretty unwieldy. We don’t really ever do anything with this besides merge conflicts. No one actually goes in here. I’ve never seen it and actually edited XML to add an element to it. That would be kind of scary. I don’t think you can even see the XML within Xcode. I had to open this up in TextEdit.

To create connections in Interface Builder, I drag a line from a label to my code. It’s physically connecting them. I do the same with the button function. I have a button and I want to add what happens when that thing gets pressed. I give it a name and then it adds that code with that connection in Interface Builder.

How we handle different screen sizes is through layout constraints. This is something I think Android is going to be getting soon. This took a while to really get right in Xcode, so it’ll probably be a while before it’s okay in Android too. But it is pretty powerful now.

Once you start adding layout constraints you can say, where does this thing anchor, how does it grow, is it centered, is it not? And it’ll tell you if there are not enough constraints to really figure out what you want to do. Right now there’s a little yellow arrow next to “first scene,” and that’s saying I’ve got constraints in here, but they don’t quite match what I’m showing you. It’ll tell you when things are wonky.

UI elements (23:40)

There are a bunch of other UI elements out there. I don’t want to go through every single one of them. Apple has a document online called the Human Interface Guidelines (HIG). It goes through all of these and tells you exactly what’s okay and what’s not okay to do with it. It’s very important as an iOS developer to read this document, because when you submit your app to the App Store they will reject you if you do not follow their guidelines.

Apple is very strict, but not necessarily consistently strict. Sometimes they’ll reject you and you’ll be like, “What?” And other times that same thing will go through. If you have a client, say, “I can’t guarantee you that this will be approved when it’s submitted. So it could take two weeks for them to review it. It could get rejected.” What happens if that happens? How does that affect your timeline? You have to build that into your actual timeline of work to go, “okay, I need at least two weeks for the review process.”

What happens if it gets rejected? We need a another week or two to fix things. It’s something to keep in mind. But reading the HIG also will give you a really good understanding of what Apple deems important and how they want you to use the elements that they’ve given you. It’s a good read especially for an introduction. It’ll give you a lot of the information about what are all these different elements and what is the vocabulary. It’ll link to how you implement things if you’re interested in it.

Asset Catalogs are how you use images and other things within your app. You would add an image in here and it groups each one by the three different sizes that Apple wants you to put in there. So we have 1x, 2x, and 3x. If you want to know exactly what those requirements are, you can look on the website. They’re different pixel sizes and such. So for devices with more screen resolution, you can display the right asset.

Core Data is the persistence framework that comes with Xcode. They have a table-based editor and a graphical editor for creating a database. It can be in-memory or it can be actually persisted. Core Data is a little wonky to use. A lot of people have been switching to Realm lately. It’s definitely something that a lot of apps use and you’ll probably want to at least play around with a little.

Sharing content is a little harder in iOS. They’re very strict about putting apps in sandboxes, so you really can’t have that same level of connectivity that you can have on Android. They give you some tools for doing that. One is this activity view that comes with the standard set of things that you can do. You can also create your own share extensions and action extensions. You can say “this app can share through this method.” But if you’re doing some more involved logic where you need to pass data to another app, or you have a website that needs to interact with your app and send data to it, you have to do that through custom URL schemes.

Some common libraries and frameworks that we use include Cocoapods for dependency management. We bring in all our libraries through there. We can set what version levels we’ll accept, whether or not they upgrade, or if you stick with a particular version. AlamoFire is a Swift library for networking stuff. We used to use AFNetworking when we did more Objective C stuff. I’m not sure if they’ve moved to Swift or not. Realm for database and Firebase I’m assuming you’re familiar with on Android.

iOS development (27:56)

The worst part of iOS development is dealing with Apple at the end of your project. iOS development is really smooth until you get to the point where you want to either give someone your app or submit it to the App Store. We call this “provisioning hell” where things are supposed to be magic and they’re supposed to just work, but it all just goes to hell.

To avoid that you could use simulators. All of the devices that are current, and I think even some older ones, have simulators through Xcode. They all come with it. You can do that for most of your development. If you’re doing more device specific things like using your camera or GPS stuff, it doesn’t work in a simulator.

You can get a free Apple ID and that will allow you to run your app on your phone, but you have to actually plug it in to your laptop and run it through Xcode to do that. If you want to give the app to someone else, you need a paid developer license. It’s $99 a year. With that you can export the IPA file, which is the file that you would use to give someone your app. You can submit to the App Store or you can submit for beta testing. That’s required for anything beyond just running on your device.

Again, Apple will test your app when you submit it, and they might reject it. TestFlight is the app that they give you for submitting to the App Store. It’s through iTunes Connect, so you would log in to their website online. They also have options if you want to test internally. I think they let you pick 16 different email addresses that you can send it to and they can download the app. External testing gives you a little bit more users. Then from there you can submit your app to the App Store. They do have a review process. It’s gotten a lot faster recently, but it used to take up to two weeks, and they might reject it.

Conclusion (30:26)

Here are some resources that you might want to use for learning more about iOS or Swift or other things. Apple has a lot of documentation, and it’s usually pretty good, such as developer.apple.com/swift. They also have created the Swift education course. It looks like it’s geared towards teachers, but you can look at the content and learn it. That’s on GitHub.

iOS has developer.apple.com. They have a whole bunch of stuff on there. Read the HIG. For blogs, Ray Wenderlich has a lot of good iOS content. Also iOS Dev Weekly and NSHipster. I found this “design differences between iOS and Android” link really helpful. It lays out, here’s what it looks like on Android, here’s what it looks like on iOS, and what the names might be.

Then there’s a bunch of podcasts. I don’t listen to podcasts, so I asked all my coworkers what they listen to, and that’s what they gave me. Then I found that link that had some good explanations about why you might want one over the other. Check those out if you like podcasts. That’s all I have.

Intro to iOS for Android Developers Resources

• Swift
• Swift Education course
• iOS
• Design differences between iOS and Android
• Podcasts