B. Resources

I’ve tried to make this book thorough, but it isn’t comprehensive. Xcode is too big to cover exhaustively, and Apple constantly updates it. Further, your needs as a Cocoa programmer go beyond simply using the tools. This appendix is a brief reference to resources you can use to go further and keep current.

Buck, Erik, Cocoa Design Patterns (2009). Cocoa conforms to a few fundamental patterns, and once you have those down, you’ve gone a long way toward understanding most of iOS and OS X programming. Erik Buck’s book is six years old, but the fundamentals haven’t changed.

Conway, Joe, and Hillegass, Aaron, iOS Programming: The Big Nerd Ranch Guide, fourth edition (2014). What Aaron Hillegass’s Cocoa Programming for OS X (see below) did for Mac programmers, this book does for iOS. A stand-alone book from the ground up, it takes you from a dead start (or at least from C programming) to some advanced topics.

Hillegass, Aaron, and Preble, Adam, Cocoa Programming for OS X, fourth edition (2011), and Claude, Juan Pablo, and Hillegass, More Cocoa Programming for OS X: The Big Nerd Ranch Guide (2013). This book was a classic from the first edition. The series is where Mac programmers have started for more than a decade. A fine introduction, and a tour by example from beginning to advanced topics. Highly recommended.

Kochan, Stephen, Programming in Objective-C, sixth edition (2013). The leading book about Objective-C, teaching it as your first programming language—it does not assume you have any grounding in C or object-oriented programming. Kochan teaches the Foundation framework, but treads only lightly on the Cocoa application frameworks.

Lee, Graham, Test-Driven iOS Development (2011). Test early, test every day: Lee’s book shows you how.

Napier, Rod, and Kumar, Mugunth, iOS 6 Programming Pushing the Limits: Advanced Application Development for Apple iPhone, iPad and iPod Touch (2012). Napier goes deep into subjects that will get beginning-plus developers well into advanced techniques.

Neuberg, Matt, Programming iOS 8: Dive Deep into Views, View Controllers, and Frameworks (2014). Matt Neuberg offers an exhaustive (800 pages) introduction to all aspects of iOS programming. Many regard this as the capstone of iOS instruction: Other books will lead you through the steps to producing applications that exhibit some advanced features of iOS. Neuberg takes a thousand pages because he explains the underlying principles step by step. You will not merely have done; you will have understood.

Neuberg, Matt, iOS 8 Programming Fundamentals with Swift: Xcode and Cocoa Basics (2015). This is a lighter (400+ pages) book, more a tutorial than a text.

Sadun, Erica, The Core iOS Developer’s Cookbook, fifth edition (2014). Or any book with Erica as the author, particularly with the word “Cookbook” in the title. She is one of the clearest and most readable technical writers in the business. Many people swear by her iOS books.

Sharp, Maurice; Sadun, Erica; and Strougo, Rod, Learning iOS Development: A Hands-on Guide to the Fundamentals of iOS Programming (2013). This book starts you at the beginning of the development process and hits all of the major issues in bringing an iOS app to App Store quality.

Here are what I see in the preorder lists that look good to me, on the basis of blurbs and the reputations of the authors and publishers. I can’t offer details.

Kochan, Stephen, Programming in Swift (Developer’s Library), sixth edition (2015).

Manning, Jonathon and Buttfield-Addison, Paris, Swift Development with Cocoa: Developing for the Mac and iOS App Stores (2015).

Mark, David and Nutting, Jack, Beginning iPhone Development with Swift: Exploring the iOS SDK (2014).

Nahavandipoor, Vandad, iOS 8 Swift Programming Cookbook: Solutions & Examples for iOS Apps (2014).

Then, if you can’t find a good answer, consider whether the Cocoa API documentation makes the answer to your question obvious. Reread Apple’s documentation one more time. Then ask. If you can say you’ve made a diligent attempt to find the answer yourself, the people who can help you will be satisfied that you’ve done your homework, and you are worth helping.

I’ll put the second-best first. The Apple Developer Forums ought to be the main resource for finding solutions to OS X and iOS problems. They were established to solve the problem that, before iPhone OS 2 went public, there was no way to discuss unpublished API. As a paid developer-programs member, you can ask questions about nondisclosed topics freely. (The Developer Tools section is available to the general public with a free registration as an Apple developer.) Some Apple engineers, having started with the private forums, never branched out to public venues like mailing lists and Stack Overflow.

The drawbacks, however, are crippling. The forums are closed to external search engines, and the internal search facilities are ludicrous. The indexer is not customized to the subject of the forums, so if you look for a symbol declared in one of the Apple frameworks, the search engine may suggest that you really meant some technical term from veterinary medicine. You can narrow your search by time, but you can’t go back 12 months (unless you conduct your search on New Year’s Eve) because the search engine offers only the calendar year.

The big, universal search engines prioritize results by the number of responses they attract—solutions usually float to the top. Not so on the Apple forums: When you enter your search terms, some encouraging result might flicker past in the Web 2.0 windowlet that pops up, but when it settles down, most of what you get are single messages from other hapless seekers.

But if you’re looking for solutions for NDA software, the Apple Developer Forums are the only game in town. http://devforums.apple.com/.

Better, much much better: Stack Overflow, http://stackoverflow.com/. It’s open to search engines, the postings have usable metadata, and most of the threads you’ll find will have at least one high-quality answer (though it is sometimes a trick to decide which answer that is). Very little chat, a whole lot of solutions. If your mission is problem solving, and not just reference, save yourself some trouble and prefix your search queries with site:stackoverflow.com.

These three lists will probably be the most help to you:

xcode-users—Covers Xcode and the other Apple developer tools. It does not deal with programming questions; if you want to ask about what to do with Xcode, rather than how to use it, you’ll be better off asking in cocoa-dev. http://www.lists.apple.com/mailman/listinfo/xcode-users/

cocoa-dev—This is for questions about the Cocoa frameworks, for both OS X and iOS. http://www.lists.apple.com/mailman/listinfo/cocoa-dev/

objc-language—Handles questions about the Objective-C programming language. Questions about Cocoa programming (except for the primitive data types in Foundation) are not on-topic here.

http://www.lists.apple.com/mailman/listinfo/objc-language/

There is no consensus favorite for a Swift mailing list; there may never be one. The swift-language Google group, https://groups.google.com/forum/#!forum/swift-language, attracts just over a post a day. Swift questions also crop up in xcode-users and objc-language.

If you file a DTS incident, you will be assigned an engineer who will respond within three days. He will have access to OS source code and to the engineers who wrote it. He (usually) will be able to come up with a solution to your problem that works and will work even if Apple revises the OS under you.

DTS isn’t a gatekeeper for insider techniques. Almost everything that has an answer has (or will have) a public answer. What you’ll be getting is an engineer with good communications skills, and enough of a knowledge base to respond to your particular problem.

If you find a bug in Apple software, or need a feature, go to http://bugreport.apple.com (you’ll need to register with Apple as a developer, but the free program will do). Be sure to file a complete report (Apple has guidelines for you), and if you’re looking for a new feature, be sure to make a concrete case for how it will improve your product or workflow.

https://developer.apple.com/bug-reporting/ will bring you up to speed on the details.

Apple has an official blog for Swift: https://developer.apple.com/swift/blog/. Posts come a little more than once a month, but they go into detail, and of course, they are authoritative.

https://www.cocoacontrols.com—is a clearinghouse for UI components for iOS and OS X. As I write this, its catalog listed 1,763 components.

NSHipster, http://nshipster.com/, is a weekly blog of “overlooked bits in Objective-C, Swift, and Cocoa.” Each article surveys one aspect of Cocoa programming—#pragma directives, UICollectionView—and reduces it into a concise, accessible introduction. With just a little bit of irony.

You can get a commented listing of the interfaces in the Swift standard library by typing import Swift in a playground or Swift source file, and command-clicking on Swift. It’s nearly 10,000 lines in a single page. There’s a cleaned-up and organized version at http://swiftdoc.org.

Mike Ash’s Friday Q&A blog covers iOS and OS X topics in depth and breadth. The blog itself (updated, as you might expect, nearly every week) is at http://www.mikeash.com/pyblog/. You can buy it in ebook form from the links at http://www.mikeash.com/book.html. Send him money; he deserves it.

There are many sample-code projects on GitHub, https://github.com. Plug “ios sample code github” (or “os x” or “cocoa” instead of “iOS”) into your search engine, and browse at leisure.

NSCoder Night is more a movement than a user group; it has no central (and very little local) organization. Cocoa programmers gather as often as weekly in pubs and coffee houses to share experiences and code. The get-togethers occur in nearly 60 cities around the world. Unfortunately, the web site hasn’t been updated since 2011, and the link to a promised wiki is dead. Google NSCoder night your city, ask around at user groups and colleges, and if all else fails, start one!

Stanford University, CS 193, Developing Apps for iOS, available through iTunes U at https://itunes.apple.com/us/course/developing-ios-7-apps-for/penalty-@M%toendlongline~comp.id733644550. This is a 20-part lecture series from a course taught by the Computer Science department at Stanford University.

Big Nerd Ranch, http://bignerdranch.com/, Aaron Hillegass’s training company, provides week-long boot camps on OS X, iOS, Cocoa, Rails, Android, and OpenGL at locations in North America and Europe. Your fee (starting at $3,500) includes lodging, meals, and transportation to and from the airport.

Prices are US dollar equivalents as of late 2014, rounded to the nearest dollar (I have to round for Euro-denominated prices, so x.99 dollar amounts get rounded, too.)

Even if you’re happy with Xcode for most tasks, as a committed Cocoa programmer you’ll probably use one or more of these editors as well.

BBEdit, from Bare Bones Software, is particularly good with large files and HTML. It will open anything. Its support for AppleScript, Unix scripting, and “clipping” macros make it readily extensible. This book was written in LATEX with BBEdit. It is available from Bare Bones directly.

Click here to view code image

http://www.barebones.com/products/bbedit—$50.

Bare Bones provides a capable “light” version of BBEdit, TextWrangler. What you’ll miss are BBEdit’s extensive tools for web development, text completion, version-control support, built-in shell worksheet, and ponies.

http://www.barebones.com/products/textwrangler/ - Free.

TextMate 2 beta, from MacroMates, is a text editor with a huge capacity for customization. Syntax coloring and powerful keyboard shortcuts are available for dozens of languages and applications. TextMate has an active user community, and many developers whose products consume formatted text provide free TextMate extension bundles.

TextMate 2 was declared “90 percent complete” in 2009. A “pre-alpha” went public at the end of 2011, and it has attracted fans. The source was published under the GNU General Public License in August 2012. You can purchase a license for the current, supported build at http://macromates.com—$50 (EUR 39).

Sublime Text 2 is a GUI editor for Mac, Windows, and Linux. You can customize it with JSON-based scripts and Python plugins. It recognizes dozens of language syntaxes, and it indexes both source and library code. Multiple selection allows you to edit common occurrences of a string simultaneously. I hear that skeptics of the future of TextMate are gravitating to Sublime Text and finding that TextMate bundles carry over. http://www.sublimetext.com—$59.

emacs and vi are supplied with every standard installation of OS X. If you have any background in the Unix command line, you probably know how to use one of these and have nothing but contempt for the other.

There are graphical variants of both. Check XEmacs, www.xemacs.org, for an X Window graphical emacs. MacVim is the most popular Mac-native graphical editor in the vi family, available at http://code.google.com/p/macvim/ as source and installable binaries. Vico, http://www.vicoapp.com, is an editor with vi key bindings that can use TextMate language bundles. All are free of charge.

Dash styles itself a “documentation browser and code snippet manager.” You can start with Cocoa document sets, but you can add scores of references for Ruby on Rails, Java, jQuery, Arduino. . . on and on. The application is built around a search interface that leads you to matches in all the active documentation sets; you’re encouraged to build task-specific groups of the docsets you need for one project. Select a page (for instance, a Cocoa class reference), and all of the categories and entries on that page are displayed in a convenient index at the left edge of the window.

The snippet manager holds code in any of dozens of languages. Select the abbreviation for one, and trigger the Dash service. The selected snippet will appear in a heads-up window so you can edit placeholders. These are more intelligent than Xcode’s because editing one placeholder will edit other appearances of the same placeholder to match. Press Return to paste the completed code. Dash does a lot, and it’s getting better at making everything it does accessible to an untrained user—but it still routinely posts popovers (you can suppress them) explaining fundamental uses. http://kapeli.com/dash/, and the Mac App Store. Free to download, $10 for full features.

Hopper Disassembler, you remember, was the tool I used to produce pseudocode from a compiled C function in Chapter 5, “Compilation.” If you need an analytical disassembler for your work, you’re either an optimization wizard or in deep trouble with what you suspect is a compiler bug. Either way, you need it.

You present the app with your compiled code, and it presents its best-guess partition of the byte stream into data, dynamic-linkage jump tables, and code, which it tries to break down into functions and sub-blocks within them. Then it’s up to you to correct the partitions and to rename objects (including the stack offsets that define local variables) as you cycle through the task of making sense of the machine code.

As you saw, Hopper will give you pseudocode, which is great for presentation and essential to solving the puzzle.

It has hooks into the debugger. The promotional material says it works with gdb, but we can hope it can get by with lldb.

The developer (a very patient man as he dealt with me) designed the UI for his own needs. The application is meant to be run from the keyboard, using letter (not Command-key) commands. It takes some getting used to, but it’s the best game in town.

A limited demo is available for free from the developer’s web site, http://www.hopperapp.com. Purchase directly from the developer for $89.

Kaleidoscope is a first-class file-comparison and merging editor. The first time you use it, you’ll think of it as a glorified diff—a display of the differences between two files, little different from the comparison editor in Xcode. But the Xcode comparison editor goes only one way, to accept or refuse changes between versions of a file; it’s a merging tool. Kaleidoscope lets you transfer divergent lines of text from one file to the other. So it’s a general merge tool. It can be integrated into Versions, SourceTree, and the git and svn command-line tools.

And it does whole directories. And if you have more than two versions of a file, you can queue them up so you can select any two to compare.

And it compares images, giving you a flip comparison, a split view, or a bitmap of the changed pixels.

And that’s why it’s worth 70 bucks. http://www.kaleidoscopeapp.com—$70 from the Mac App Store or direct.

mogenerator—In Chapter 8, “Starting an iOS Application,” I showed you that even though Xcode’s Data Model editor can generate NSManagedObject subclasses from your data model, it’s much better to rely on mogenerator. There’s no reason to repeat the reasons. Use it.

PaintCode is just cool. At first glance, it’s a vector-based drawing application, moderately well featured. It’s interesting that you can define colors by name, base other colors on variants of the plain ones, and produce gradients from the defined colors. If you have a shape filled with the named gradient, and change the base color, the derived color and gradient change to match.

The thing is, this is a code editor. As you build your drawing, PaintCode generates the Swift, Objective-C, or C# code that will reproduce it. It includes expression editors for things like bounds or offsets, and variables that can be coded as locals or function parameters. I rarely use PaintCode’s code unchanged, but it saves me half a day’s fooling around to get my arcs to go the right way.

http://www.paintcodeapp.com—$100 from the Mac App Store.

OS X doesn’t have a package manager, but four volunteer communities’ projects provide the manager software and ports of many FOSS packages. All of them work from the command line; at their simplest, it’s just a matter of invoking the manager’s command (fink, brew, port, pod) with the package name. There are also graphical wrappers.

Third-party package managers have a problem in that they will not be the only mechanism for installing software on a system. If you run a makefile of your own, or open an installer package that installs its own components, or even use another package manager, the installed products will interfere with each other. Each manager has its own strategy for at least protecting its products from outsiders.

Fink is the oldest of the four, having been founded in 2000. It is a Mac/Darwin derivative of Debian’s package-management tools like apt-get. Build products go into the /sw directory. Fink has not had a binary installation since OS X 10.5 (Leopard); you will have to bootstrap by building the source distribution. The installation instructions list PowerPC as an available platform, which is good news if you are still nursing a PPC Mac along (as I did with my PowerMac G4, 2000-2013).

http://fink.thetis.ig42.org

CocoaPods is specifically for Objective-C projects. The client software is distributed as the cocoapods Ruby gem. The web site consists of some background information and a search field so large, you may not realize it is one. (It’s the red “SEARCH*” at the top.) Enter author, name, keyword, or other relevant information, and the incremental search shows you the matching pods.

http://cocoapods.org

Homebrew, “The missing package manager for OS X,” is the newest. Based on Ruby and Git, it’s clean, and many new projects make it their preferred method of delivery. Build products go into the homebrew directory of your home directory and are then linked from /usr/local. http://brew.sh.

MacPorts (formerly DarwinPorts) is old enough that it once identified itself with Darwin, not the Mac, when Darwin was still a serious contender as an open-source Unix. The project strives to keep its packages compatible with the current version of OS X, plus the two before. Its library has grown to nearly 18,000 packages. The MacPorts tree is rooted at /opt/mports. http://www.macports.org.

Xcode’s source-control system insulates you from the worst of it, but most developers find they still get into tangles, or need functions—tagging being the leading example—that Xcode simply doesn’t provide.

The people best equipped to deliver an easy way to use source-control systems are programmers. They are their own market, and this has produced a great number of finely crafted, feature-filled graphical source-control managers. Too many for me to evaluate and list here.

A few stand out.

Git itself comes with some cross-platform (Tk) tools for managing repositories. Before I switched to SourceTree, gitk, which you launch from the command line, was my favorite way to visualize the branching structure of a repository. It gives you diffs between a revision and its immediate predecessor. If you’ve installed Xcode, you’ve installed all the Git tools - Free.

SourceTree, from Atlassian, is a well-regarded, comprehensive application for managing Git and Mercurial repositories. When you first launch it, you give it your credentials for any of the major remote-repo providers, allow it to scan your directories for repositories, and approve the set of repos you’ll allow it to manage.

The UI is. . . busy, with 19 controls in the toolbar. But comprehensive management of a Git repo is a busy task, and the presentation becomes quite accessible after a few minutes. Ignoring the doc directory from Chapter 24, “Documentation in Xcode,” was a matter of a few clicks; the feature was easy to find.

It’s compatible with OS X 10.6 and up. Atlassian promotes its own cloud software-management services, including Bitbucket, a repository service that is free to projects with up to five participants. http://www.sourcetreeapp.com - Free.

GitHub is the dominant provider of public Git-repository hosting. It provides a simple interface for managing your GitHub-hosted repositories, showing version diffs and branches. It concentrates on keeping you up-to-date in synchronizing your projects with their remotes—on GitHub. GitHub means their app to be a simple, powerful interface for its product. Nothing wrong with that; it’s very good at what it does. http://mac.github.com - the application is free.

Versions is the leading Subversion client for OS X, having won an Apple Design award for its UI design. It provides the usual services—version comparisons, commits, branch management—and communicates with the Subversion repository using its built-in implementation of Subversion 1.7—there’s no need to install anything else, and no worries about possible mismatches between the app and whatever version of svn is installed on the system.

http://www.versionsapp.com—$59, $39 for students, and a free 30-day demo.

Xcode still does some things better. Its version-control facilities are easier to work with day to day. It has a better debugger. It supports an integration system that eliminates much of the pain of unit testing, analysis, and beta distribution. It has Interface Builder; AppCode has “UI Designer,” which works with storyboards and XIBs, but that requires faith in reverse-engineering those formats with every new release of Xcode. AppCode can’t build iOS distributions. AppCode can work off of Xcode projects, but Xcode is still the best way to create Xcode projects. So, frequently, developers who use AppCode use it as a complement to Xcode—an external tool—rather than make it their primary IDE. Even Xcode fanatics (if there are such) should root for AppCode, to keep up the arms race that Apple has to run against it.

There are four tiers of licenses, including $99 for individual use, $199 for organizations, and free for education. http://www.jetbrains.com/objc/

Titanium and PhoneGap are frameworks for writing cross-platform mobile applications, including iOS. Both are built around JavaScript. They provide callouts to native libraries for access to features like GPS, accelerometers, and cameras. Both are open source, with support from their parent companies—Adobe for PhoneGap and Appcelerator for Titanium.

You will still need an iOS Developer Program membership to run your apps on a device.

PhoneGap is praised as good, for what it is: a “write once, run everywhere” development tool. It restricts itself to common-denominator features among the target devices (in part driven by the fact that HTML browsers vary among platforms, even if they mostly use WebKit). The communication between the HTML and native sides pass through a narrow pipe of JavaScript injection (to the HTML side) and a specialized URL scheme (to the “real” app).

http://phonegap.com/—Open source; no charge, premium support and training are available through an “enterprise” service.

Shotts, Kerri, PhoneGap 3.x Mobile Application Development (2014).

You code a Titanium application in JavaScript, but that’s (mostly) not what the app runs. The build process translates parts of your JS code into Objective-C (for iOS) code, which is compiled into the application. There remains a JavaScript-like interpreter in your app to handle language features that only JS can do—it’s where your app gets the dynamism that JS provides. These shims call down into native code that implements most of your application. Slick.

Titanium UIs are built from JavaScript specifications. Independent developers are working on interface-building tools but, as I write this, there are none in Titanium Studio. You can build HTML views, but HTML is not the native form for Titanium—you simply feed your HTML source into a web view, which is the “real” view so far as Titanium is concerned. For native components—navigation bars, buttons—Titanium gives you the native objects, not images that are never quite lookalikes.

http://www.appcelerator.com/—Open source; no charge, premium support and training available for a fee.

Brousseau, Christian, Creating Mobile Apps with Appcelerator Titanium (2013).

This strategy is a disaster when applied to commercial products. The non-captive market has paid a premium for its iPhones (and Nexuses. . . ), and demands apps that pay off on the latest features and capabilities. Non-native development will never keep up, and native-code competitors will have a time-to-market advantage. The temptation is to believe that a WORA app can afford to work like one platform, or the other, or neither, and paying customers won’t care; they do. WORA tools are like any modern application frameworks—they can deliver prototypes that look pretty good, and run fairly well; then comes the remaining 95 percent of the development effort, making something worth charging money for. This can involve months of chasing down special cases on each platform (even WebKit behaves differently on different phones). By that point, performance becomes a serious problem: Facebook’s Mark Zuckerberg called HTML-only development “the biggest mistake we made as a company.”

And even for in-house development, you have to ask the question: You’re relying on a BYOD (bring your own device) policy. Did your people buy iPhones and iPads (and Nexuses. . . ) because they are portable, or because the apps on those devices are quick, efficient, and easy to use? If the latter, you have to deliver value on a par with those other apps, and WORA may be a waste of money.

Both frameworks tempt developers who want to avoid learning native APIs and (for iOS) a new language. It’s a false economy: You end up learning a large API anyway; to the extent the API is smaller, it reflects platform features you won’t have access to. A cross-platform framework is a different platform altogether, and the hope that you can just drop your web developer into a large mobile project, without a long learning curve, is likely forlorn.