Developing Enterprise iOS Applications

Chapter 1. Enterprise iOS Applications

Enterprise application development is never a particularly fun endeavor. You tend to end up in large teams. There’s lots of process to follow and layers of management all eager to make sure things are proceeding on course. There are lawyers who have to get involved with every piece of paperwork that you need signed. And, of course, you’re frequently stuck having to slap a fresh coat of paint onto aging legacy software that can be fragile and difficult to interface with.

By contrast, the entire Apple development universe is about making thing fun and easy to use and producing eye-popping user interfaces that do incredible things. Unfortunately, when these two worlds collide, one or the other of the philosophies tends to end up on the losing end of the stick. Either you abandon all the practices that your management chain places such value in, and hope they can be understanding about it, or you have to sacrifice speed and functionality to appease the Gods of Process.

But there is a middle ground! Over the last year, I’ve been involved in a pioneering mobile application at a large, established software vendor. It’s the first mobile product the company ever created, the first use of Apple technology by the company, and the first time Objective-C has ever found its way into the source control system. And in spite of the steep learning curve that was required to get the processes and people up to speed on the Way of Apple, we shipped on time and with a full feature set.

This book is an attempt to distill some of the lessons learned and best practices that we developed over that year (and continue to evolve as we head toward our 2.0 release). But before we jump in to the nuts and bolts of iOS development in an enterprise environment, it’s worth noting some of the reasons that it can be such a difficult effort.

Apple Developers—An Army of One

To start with, the Apple model of development, as embodied by Xcode, strongly favors a single developer model. That isn’t to say that it is impossible to create applications using concurrent development, and in fact, recent versions of Xcode have drastically improved support for source control and merging. But the project-central nature of Xcode makes it easy for people working on the same project to get out of sync with each other, and some resources such as translation files are almost impossible to jointly develop, for reasons that you’ll see in the next chapter, on concurrent development.

There are tricks you can use, involving the new Workspace features that were introduced in Xcode 4, as well as splitting out code with static libraries, that can make your code more modular and amenable to simultaneous development by more than one coder. We’ll talk about those in depth in Chapter 2.

Build Automation Is a Bit of a Challenge

Apple has a very specific view of how applications should be developed, at least if you take Xcode as a guidepost to their philosophy. While Java developers, for example, have spent years using tools such as Hudson and Ant to automate the compilation, unit testing and deployment of their applications, Xcode puts it all under one roof. This is great if you’re flying solo: you can compile, test and archive your code with a push of a button. But if you want to employ continuous regression testing, you need to really work at it. The same goes for building and packaging Ad Hoc builds for testers. In most big companies, handing out binaries that you compiled on your development machine won’t win you many friends.

There are ways that you can compile and test from the command line, and even integrate Xcode builds into integration tools such as Hudson. Some of them are even officially supported! In Chapter 3, you’ll see how you can create a reliable continuous integration system, and learn what you can and can’t do with it.

Objective-C Doesn’t Play Well with Others

Enterprises love SOAP. It has built in support through frameworks such as CXF and JAX-WS for Java, and .NET developers can leverage the rich support for SOAP in modern versions of Visual Studio.

The iPhone and its cousins support it not a whit. Unless you want to construct your XML by hand, there is no native support for SOAP in iOS. Even the XML support in iOS is a pure pull parser model, when what you frequently want is a DOM parser. Thankfully, iOS has finally introduced support for JSON in iOS 5!

Luckily, there are good third-party libraries for most of these, even SOAP. If you’re willing to make use of open source libraries, you can talk to just about anything from iOS, although it may take a bit of work.Chapter 4 looks at how to talk to SOAP, REST, JSON and pure XML backend servers.

Code Coverage Is for Weenies

Does your company use Coverity to measure code complexity? Super, but Objective-C isn’t supported! What do you do when your manager asks you for code coverage figures on your OCUnit tests, something that was broken for most of iOS 4 and just came back to life in iOS 5? Smiling and offering chocolate chip cookies is only going to get you so far.

Xcode and Objective-C are often the odd man out in enterprise development. Outside of the Xcode tool chain, there’s little to no commercial support for the language. And the tools built into Xcode have a habit of breaking between releases. UIAutomation broke for a while in early Xcode 4 builds, and there are features still limping along in it, a year later.

By picking and choosing (and with a little elbow grease), you can get most of the metrics that your company might demand of you. Chapter 5 takes you through code coverage, CCN metrics, and other associated issues with testing.

iTunes Connect Is a Great Way to Keep Your Legal Staff Employed

Ever had to run a contract through your legal department? Are you still waiting to get it back? Before you can do anything with products in iTunes, there’s a passel of paperwork you’ll need to wade through, especially if you plan to charge for your app. There are also ongoing issues that you should think about and discuss with your management before embarking on an iOS development project.

Beyond that, there are questions you’ll need to think about in regards to internationalization, product messaging (at which point marketing will get involved), how to demonstrate the product, and a host of other issues to consider. Chapter 6, although by no means a comprehensive checklist, does try to hit the high points on what to watch out for as you move your product into the store.

You Can Have Any Style of Distribution, as Long as it’s iTunes

Now we come to the most interesting issue, as far as enterprise distribution goes. Apple, unlike the other mobile platforms, has a “my way or the highway” approach to application distribution. You can put your app in the store, distribute it in-house with major restrictions, create an Ad Hoc build for up to 100 devices, distributing it inside your own company using an Enterprise license, and…well, that’s it. Significantly, there’s no way for a developer to create an application for a diverse population of customers that they can install directly, without downloading it directly from the App Store.

For companies used to shipping code and managing stock, the iTunes ways of life is going to come as a bit of a shock. Getting a product up and released through the store is a delicate dance that needs to be well planned, especially if you need to hit a launch date precisely. Because of the “only ever one version in the store” reality, you need to think carefully about how to manage client-server version mismatches. If you’re going to use Ad Hoc provisioning for your testers, you can end up spending half your life managing the UDID list in iTunes, so that the app can be tested on a new device. Enterprise licenses can relieve a lot of this headache, but they come with their own complications, including having to juggle keychains to create your builds.

There’s only so far that technology can help with these problems; strategy may prove a better ally. Chapter 7 talks about how to provision and distribute your application without going insane, and the hard decisions you may have to end up making.

The Road Is Long and Winding

Just because you have your first release out doesn’t mean your headaches are over. When dealing with client-server architectures, it’s important that the client and server stay in sync, and that’s hard when iTunes insists that you can only have one version of your software available for sale at any one time.

Chapter 8 deals with the travails of maintaining iOS applications over the long haul, and offers some strategies for how to attack the problem.

A Few Caveats

Given the glacial pace of the Java Community Process, you can write about Java development without much fear the language is going to slip out from under you overnight. Objective-C is much more…dynamic.

It is almost a sure thing that something (or several somethings) discussed in this book will be overtaken by changes to the development environment. It’s as up to date as I can make it, especially in reference to the recent release of iOS 5. Note that because people are still discovering how some things have changed (for the good or not) in iOS 5, it’s possible that there will be information that will need to be updated in the errata (see http://shop.oreilly.com/product/0636920021759.do) or future reprints as things move forward. Honestly, iOS is always a moving target, both from a development and licensing standpoint.

Also, although I may talk about something as a best practice, your mileage may vary. Different companies have different comfort levels about change. Company A might be fine with using git as a source control system, while company B insists on CVS. You’re going to need to temper the desire to “do the right thing” with the realities of how your workplace operates.

Finally, this is not a general book on Objective-C and iOS best practices. In particular, I’m going to be doing the bare minimum as far as UI treatments go. There are a ton of good books on how to make beautiful iOS applications, and this book isn’t about that. It’s about the messy backend and logistical stuff that makes Enterprise applications work. Doing a lot of cavorting with UIViewContainers would only clutter up the program listings, and distract from the code and concepts I’m trying to highlight.

For the same reason, you won’t see me running a lot of strings through localization, and I may even (gasp) forget to do the right thing with retain and release on occasion (not that this will matter any more, once people have cut over to the automatic reference count compiler!) I’m going to assume you know how to do both, and I’m going to try to emphasize code clarity rather than pristine correctness.

Now that you know all the reasons that iOS enterprise development can drive you nuts, let’s go through each of the problems, chapter by chapter, and see what we can’t do to improve things.