7 Tips for Web Developers and Software Engineers Learning iOS Development

Aaron Brager

Published in

iOS App Development

6 min readDec 16, 2015

Learning to write iOS apps and already know another programming language? Here are a few tips.

If you’re a beginner, “Should I learn Swift or Objective-C for iOS development?” may be more interesting.

1. Start by Exploring Xcode

Unlike many other development environments, an iOS application development environment is easy to configure. Here are the steps:

Download and install Xcode from the App Store
Create an Apple Developer Account (free)

There’s ample command-line access if you want automation or need advanced workflows, but most work can be done within Xcode.

Xcode combines a powerful code text editor with graphical interfaces to a compiler, linter, debugger, user interface builder, documentation, and more. If you’re coming from a world where those are all separate, you’re in for a treat.

2. Decide Between Swift and Objective-C

One of the first choices you’ll make is which language to learn: Swift or Objective-C. Swift is newer and more modern, but it’s conceptually different from many web programming languages. Unlike Ruby and JavaScript, for example, Swift requires nil-checking and has strict type safety, including for collections. Objective-C is a freer language, more similar to Ruby and JavaScript, but with some weird syntax, verbose language, and less intuitive conventions.

Objective-C has a few advantages:

Its syntax and usage is stable: tutorials and code samples from years ago work with only minor modifications.
It’s very popular: most iOS app code bases are primarily written in Objective-C.
Most iOS Developer job openings require Objective-C knowledge.

Swift has some strong advantages over Objective-C, though:

A REPL, with an accompanying graphical interface called a “playground”. (A REPL is a console interface to a programming language, like irb, Pry, or node.)
Swift has a great library from Apple of manuals, tutorials, and videos.
It’s open-source, so you can see how it works and change it.

This video explores the differences a bit more. Both languages are powerful and full-featured, and both have full use of the iOS SDK.

If you’re not sure, I recommend starting with Objective-C, since that’s where the bulk of the job openings are at the moment. But you can’t go wrong either way.

3. Learn the Debugging Tools

Xcode’s debugging tools are among the industry’s best. Learn to use them for fast and efficient debugging and performance improvements. Some quick tips:

Set a breakpoint by clicking on the line number. When the line is reached, execution will pause.
Hover your mouse over a variable to see into its contents.
Click a variable and press space bar to see a visual representation of its data (for example, if it’s an image or a color).
Use LLDB to debug your app while execution is paused.
Use Static Analysis to find logical flaws in your code.

Here are some resources to get started:

4. Learn to Decipher Square Brackets

This method syntax is widely considered to be ugly:

[self.view insertSubview:button atIndex:2];

Confused? Don’t be:

The first statement is the object that the method is called on (the receiver).
The remaining statements are the method name interwoven with arguments:

In Swift, the same method call looks a lot more like JavaScript or Ruby:

view.insertSubview(button, atIndex: 2)

Learning to quickly interpret Objective-C square bracket notation is critical to your success as an iOS developer. Even if you’re working on apps in Swift, you’ll likely read sample code in Objective-C.

5. Don’t Be Intimidated by Objective-C’s Verbosity

Say you have a string like ‘2,4,5’ that you’d like to convert to an array. In a language like Ruby you’d use split:

'2,4,5'.split(',')

Objective-C has a similar feature, but its syntax is much more verbose:

[@"2,4,5" componentsSeparatedByString:@","];

Want to turn that array back into a string? Objective-C doesn’t have join; it has:

[@[@"2", @"4", @"5"] componentsJoinedByString:@","];

Objective-C naming conventions are more verbose than those in many other languages. It’s tempting to think that these methods are more complicated — or harder — because they’re longer, but they’re not.

Just like with the previous tip, even if you plan to work solely in Swift, it’s important to understand Objective-C’s style so you can read and interpret it correctly.

6. Understand Object vs. Value Semantics

In Ruby, everything’s an object. The same is (mostly) true of JavaScript. But in Objective-C there’s an important separation between primitive (value) types and objects. To bridge the gap, wrap primitive types in an NSValue or NSNumber object. For example:

// ERROR: implicit conversion is disallowed
[mutableArray addObject:7];// Works great
[mutableArray addObject:[NSNumber numberWithInt:7]];// You can also use this shorthand
[mutableArray addObject:@(7)];

In Objective-C, object semantics are required. In Swift, you can use objects or values for most things, but values are strongly preferred. This is another strong difference between Swift and most web programming languages.

If you’re working in Swift, read Value and Reference Types, and watch the Building Better Apps with Value Types in Swift video.

7. Understand Automatic Reference Counting

Objective-C and Swift apps (mostly) manage memory using Automatic Reference Counting (ARC). This contrasts with languages like Ruby, JavaScript, and Java, which use Garbage Collection.

In ARC, objects stay in memory if there is at least one strong reference to it. For example:

self.label.text = @"Hello World";

In this example, the string object (@“Hello World”) will stay in memory because it has one strong reference (from label). Now consider this:

self.label = nil;

Two things will happen:

The label object will be deallocated because self is no longer referencing it
The string object will be deallocated because label no longer exists, and therefore is no longer referencing the string

Be careful not to create a strong reference cycle (also called a retain cycle). This is an error caused by a circular graph of objects pointing to each other. It wastes memory and can cause other negative side effects. Here’s an example:

Because all of these objects have at least one strong reference, none of them will ever be deallocated. To resolve this, switch one of the references from strong to weak: