Namespacing. Modules have an implicit namespace; fear not about reusing
names, modulize instead.

Hierarchy. Once you start creating modules you automatically
arrange them so that some have more importance than others.
This naturally leads to a structured codebase where new files nestle into
their logical, encapsulated homes, effortlessly.

Organization. You no longer have to cram everything concerning an area of
responsibility into a single file to gain from file-private. Instead
separate all that code out into multiple files in its own module and use
internal access control.

Testability. Making a piece of functionality its own module means you can
make more of that module internal scope rather than private and this means
more of the module can be imported @testable making the functionality
easier to test without adopting practices that make your code less readable
for the sake of testing (like injection).

Cake makes working with Swift modules a breeze.

Xcode 10.2-beta Required

Support Cake’s development

Hey there, I’m Max Howell, a prolific producer of open source software and
probably you already use some of it (I created brew). I work full-time on
open source and it’s hard; currently I earn less than minimum wage. Please
help me continue my work, I appreciate it 🙏🏻

How it works

“The secret of getting ahead is getting started. The secret of getting started
is breaking your complex overwhelming tasks into small, manageable tasks, and
then starting on the first one.” —Mark Twain

Cake is an app that runs in your menu bar and watches your Xcode projects. If
you chose to integrate Cake into your App’s xcodeproj it will automatically
generate your module hierarchy based on your directory structure. For example:

Module hierarchies

“You’ve got to think about the big things while you’re doing small things, so
that all the small things go in the right direction.” —Alvin Toffler

Before long you will need some modules to depend on others. This is an important
step since you are starting to acknowledge the relationships between components
in your codebase. Cake makes declaring dependencies as easy as nesting
directories.

All other tools require you to specify relationships cryptically, either
textually or with a confounding GUI. With Cake, use the filesystem,
relationships are not only easy to read, but also, trivial to refactor (just
move the directory).

Carthage & CocoaPods

If your app uses Carthage or CocoaPods we detect that and integrate them so
your cake modules (the Batter) can use these dependencies.

Note, this only applies to cake modules (the Batter); for your App target
follow the instructions provided by CocoaPods and Carthage themselves; nothing
is different.

Op‐Ed—an era for Swift µ-frameworks?

CocoaPods and Carthage libraries tend to be on the large side, and this is at
least partly because being modular has been historically hard and tedious when
developing for Apple platforms and Swift. SwiftPM encourages smaller, tighter
frameworks and using Cake means making apps with Swift packages is now possible.

Choose small, modular, single‐responsibility libraries with 100% code coverage
that take semantic-versioning seriously. Reject bloated libraries that don’t
know how to say no to feature requests.

Constructing frameworks/dylibs

Since everything Cake builds is a static archive, you can simply link whichever
parts you like into whatever Frameworks or dylibs you need for your final
binaries.

This is a purely optional step, statically linking Cake.a into your App (which
Cake sets up by default for you) is perfectly fine. This more advanced option is
available to make apps with extensions more optimal in terms of disk usage and
memory consumption.