Building & Maintaining a Family of Applications

Preview:

DESCRIPTION

The iPhone platform currently prohibits typical means for creating shared code modules: frameworks, dylibs, and loadable bundles. If you're creating a suite of applications that have common core functionality, this presents something of a maintenance nightmare. Find out how Tapulous, the makers of Tap Tap Revenge (and several other applications all based upon the same core engine), solved this problem to cut costs, save time, and increase quality across the product line. Learn from our experience (including our initial missteps), and jumping through the right Xcode, Subversion, and code-signing hoops will be a breeze for you!

Citation preview

Building & Maintaining a Family of Applications

Code Reuse on a Platform that SupportsOne Binary per Application

Jessica KahnTapulous

Why is code reuse important?

14 apps – soon to be 17.Five client engineers.Two server engineers.

I Know What You’re Thinking…

“I don’t have 14 apps in the App Store.”

“My couple of apps aren’t really like one

another at all.”

Oh, so you don’t…

• Use categories or subclasses to extend classes like NSString, UIViewController, or UIWebView?

• Collect analytical data?

• Display advertisements?

• Use Facebook Connect or another third-party library?

Of course you do!What’s the basic methodology you need to apply?

Use a framework…

Psych!

Embed a loadable bundle…

j/k!

Tap Tap Revenge 2 Born by Emergency C-Section

You can’t hide “a baby” inside of an application. We learned this the hard way.

Static library it is.

Drawbacks

• Code size contributed to each product

• No self-containment of resources

• Must update every app to take advantage of a new version of your library

• If you don’t have the source, you have to trust its source

Plusses

• Supported on the iPhone

The Basics

• Create a static library project

• Embed this project into your application project

• Include the library’s resources in your application’s Copy Resources phase

• Set up the proper dependencies and linkages

Demo

One Size Fits MostWhat to do when apps require slightly different

versions of your static libraries.

Why is this needed?

Cosmetic Reasons

Cosmetic Reasons

Different Feature Sets

Different Feature Sets

Modified Behavior

Modified Behavior

• Look up values in the app’s plist(s) and/or strings file(s) at runtime

• Override library methods with app-supplied subclasses or categories

• Override library resources in the app project

• Compile the library in an app- specific way

Tactics for Customization

Demo

Gotchas & Hints

• Remove the default version of a resource from your project, to be sure to override with an app-specific one.

• Add all_load in OTHER_LDFLAGS for your application target, to ensure static library categories are loaded and linked properly.

• Use Xcode project templates.

Demo

Source ControlUsing Subversion to maintain a stable base for

some projects, while developing on the bleeding edge for others.

• svn:externals let you place your application adjacent to all its dependencies, no matter where they really live in the repository

• Trunk is the oft-unstable bleeding edge

• Tags are untouchable

• Branches lie somewhere in between

Demo

Bonus Points!Build and Unit Test Automation

Builds

• Script your own, or…

• Use a continuous integration package:

• BuildBot, Cruise Control & Hudson

• Both require knowledge of xcodebuild

Unit Tests

• ocunit built into the OS X & iPhone developer tools, supported on the Simulator since SDK 2.2

• http://developer.apple.com/tools/unittest.html

• Combine with continuous integration

In Summary…

• Most developers with more than one project can do more to reuse their code

• Spending some time up front saves time in the long run; teach Xcode, svn, and other tools to do the heavy lifting for you

• Development, support, and maintenance costs lowered through “economies of scale” and bug compatibility

Q & A

Recommended