Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Building Commercial Frameworks - Swift Mumbai #3

Building Commercial Frameworks - Swift Mumbai #3

Modularising your codebase goes a long way in having a SOLID principles abiding architecture in your products. The Framework Consumers depend on Framework Engineers to write efficient, flexible, maintainable and well-documented code.
We'll discuss the current challenges in building private frameworks like setting up your development environment, utilising third-party open-source & commercial frameworks, current distribution channels available, deploying to Framework Vendors & Store Applications.

About the Speaker: Yogesh Singh is currently working as Senior iOS Engineer at Haptik. Graduating with CS degree from Mumbai University in '14, he joined Mumbai based startup Inspeero Technologies helping build Electrocompaniet Remote which was showcased at CES '14, '15, '16. You can find Yogesh at -

Presented at Swift Mumbai - Chapter #3 Meetup: https://www.meetup.com/Swift-Mumbai/events/249701161/

Watch the presentation at: https://youtu.be/NqG5Io3LHnI


Swift India

April 28, 2018


  1. Building Commercial Framework Yogesh Singh

  2. Aim To generate Curiosity about Frameworks Building Commercial Frameworks

  3. • What is a Framework? • Structure • Guidelines •

    Demo Items to be Covered
  4. What is a Framework? • Hierarchical Directory that encapsulates Shared

    Resources • Like dynamic shared library, nib files, image files, localized strings, header files and reference documentation in a single package • Created with the intention of distributing them to other developers • Provide routines that can be called by an application to perform a specific task
  5. What is a Framework? • You can create your own

    frameworks and use them privately for your own applications or make them publicly available to other developers • Public frameworks are intended for use by other developers and usually include headers and documentation defining the framework’s public interface • Private frameworks are appropriate for code modules you want to use in your own applications but do not want other developers to use • Can be packaged as Standard frameworks or Umbrella frameworks
  6. What is a Framework? • Frameworks are presented to the

    user as a directory and not as a file • Makes it easy for developers to browse any header files and documentation • Framework bundle directory ends with the “.framework” extension • Both Standard & Umbrella framework have the same basic structure and can contain resources(image files, strings files, plists, documentation, header files, etc) • Umbrella frameworks add minor refinement like the ability to encompass other frameworks
  7. Structure • Information property list for your framework -

  8. Structure • Simple framework bundle -

  9. Structure • Framework with multiple versions -

  10. Structure • Framework with additional resource types -

  11. Structure • Framework with additional resource types -

  12. Structure An

  13. Guidelines • Framework consumers depend on framework developers to write

    efficient, crashless, and well-documented code • API Naming Conventions - In global namespace, elements such as classes, functions, global variables should have unique names • Performance Impacts - Framework loading, initialization time, make reusable componenets, use async queues, analytics

  14. Guidelines • Framework should builds cleanly and runs in a

    simulator and on device with zero issues or warnings. • Sample project and framework should not require third-party tools such as CocoaPods/Carthage • Should be built with the latest non-beta stable version of Xcode • Should provide configurable debug log levels with the option to completely silence them
  15. Guidelines • Should support Bitcode and can be build with

    Bitcode enabled projects • Framework shouldn’t swizzle system API methods • Public Interfaces should have explanatory commented • Framework should include a Universal binary, the fat binary should support architectures: arm64, armv7, i386, x86_64
 (Use lipo -info on the binary)
  16. Guidelines • Should provide comprehensive documentation that describes SDK setup

    and Usage • Should provide a list of bundled third-party libraries used in the framework • Dependencies that must be built into your binary are name-mangled so we do not have symbol collisions • Should have a small memory and on-disk footprint • Should support iOS Beta Releases
  17. That’s Frameworks DEMO