Building & Maintaining a Family of Applications


Published on

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!

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Building & Maintaining a Family of Applications

  1. 1. Building & Maintaining a Family of Applications Code Reuse on a Platform that Supports One Binary per Application
  2. 2. Jessica Kahn Tapulous
  3. 3. Why is code reuse important?
  4. 4. 14 apps – soon to be 17. Five client engineers. Two server engineers.
  5. 5. I Know What You’re Thinking…
  6. 6. “I don’t have 14 apps in the App Store.”
  7. 7. “My couple of apps aren’t really like one another at all.”
  8. 8. 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?
  9. 9. Of course you do! What’s the basic methodology you need to apply?
  10. 10. Use a framework…
  11. 11. Psych!
  12. 12. Embed a loadable bundle…
  13. 13. j/k!
  14. 14. 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.
  15. 15. Static library it is.
  16. 16. 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
  17. 17. Plusses • Supported on the iPhone
  18. 18. 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
  19. 19. Demo
  20. 20. One Size Fits Most What to do when apps require slightly different versions of your static libraries.
  21. 21. Why is this needed?
  22. 22. Cosmetic Reasons
  23. 23. Cosmetic Reasons
  24. 24. Different Feature Sets
  25. 25. Different Feature Sets
  26. 26. Modified Behavior
  27. 27. Modified Behavior
  28. 28. 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
  29. 29. Demo
  30. 30. 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.
  31. 31. Demo
  32. 32. Source Control Using Subversion to maintain a stable base for some projects, while developing on the bleeding edge for others.
  33. 33. • 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
  34. 34. Demo
  35. 35. Bonus Points! Build and Unit Test Automation
  36. 36. Builds • Script your own, or… • Use a continuous integration package: • BuildBot, Cruise Control & Hudson • Both require knowledge of xcodebuild
  37. 37. Unit Tests • ocunit built into the OS X & iPhone developer tools, supported on the Simulator since SDK 2.2 • • Combine with continuous integration
  38. 38. In Summary…
  39. 39. • 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
  40. 40. Q &A