Name.framework/
Modules/module.modulemap Module map for the framework
Headers/ Subdirectory containing framework headers
+ PrivateHeaders/ Subdirectory containing framework private headers
Frameworks/ Subdirectory containing embedded frameworks
Resources/ Subdirectory containing additional resources
Name Symbolic link to the shared library for the framework
easier to split a library's public and private APIs along header
boundaries.
+When writing a private module as part of a *framework*, it's recommended that:
+
+* Headers for this module are present in the ``PrivateHeaders``
+ framework subdirectory.
+* The private module is defined as a *submodule* of the public framework (if
+ there's one), similar to how ``Foo.Private`` is defined in the example above.
+* The ``explicit`` keyword should be used to guarantee that its content will
+ only be available when the submodule itself is explicitly named (through a
+ ``@import`` for example).
+
Modularizing a Platform
=======================
To get any benefit out of modules, one needs to introduce module maps for software libraries starting at the bottom of the stack. This typically means introducing a module map covering the operating system's headers and the C standard library headers (in ``/usr/include``, for a Unix system).