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!

1. Building & Maintaining
a Family of Applications
Code Reuse on a Platform that Supports
One Binary per Application

2. Jessica Kahn
Tapulous

3. Why is code reuse
important?

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

6. I Know What You’re
Thinking…

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

8. “My couple of apps
aren’t really like one
another at all.”

9. 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?

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

11. Use a framework…

12. Psych!

13. Embed a loadable
bundle…

14. j/k!

15. 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.

16. Static library it is.

17. 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

18. Plusses
• Supported on the iPhone

19. 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

20. Demo

21. One Size Fits Most
What to do when apps require slightly different
versions of your static libraries.

22. Why is this needed?

23. Cosmetic Reasons

24. Cosmetic Reasons

25. Different Feature Sets

26. Different Feature Sets

27. Modified Behavior

28. Modified Behavior

29. Tactics for Customization
• 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

30. Demo

31. 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.

32. Demo

33. Source Control
Using Subversion to maintain a stable base for
some projects, while developing on the
bleeding edge for others.

34. • 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

35. Demo

36. Bonus Points!
Build and Unit Test Automation

37. Builds
• Script your own, or…
• Use a continuous integration package:
• BuildBot, Cruise Control & Hudson
• Both require knowledge of xcodebuild

38. 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

39. In Summary…

40. • 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

41. Q &A