Advanced iOS App Architecture First edition Real

world app architecture in Swift 5 Rene Cacheaux

pdf download
https://textbookfull.com/product/advanced-ios-app-architecture-first-edition-real-world-app-
architecture-in-swift-5-rene-cacheaux/

★★★★★ 4.7/5.0 (23 reviews) ✓ 104 downloads ■ TOP RATED

"Perfect download, no issues at all. Highly recommend!" - Mike D.

DOWNLOAD EBOOK
Advanced iOS App Architecture First edition Real world app
architecture in Swift 5 Rene Cacheaux pdf download

TEXTBOOK EBOOK TEXTBOOK FULL

Available Formats

■ PDF eBook Study Guide TextBook

EXCLUSIVE 2025 EDUCATIONAL COLLECTION - LIMITED TIME

INSTANT DOWNLOAD VIEW LIBRARY

Collection Highlights

Learn Swift by Building Applications Explore Swift

programming through iOS app development 1st Edition Emil
Atanasov

UI Design for iOS App Development: Using SwiftUI Bear

Cahill

Advanced Android App Architectures 1st Edition By Yun

Cheng

Interactive architecture adaptive world First Edition Fox

iOS 14 Programming Fundamentals with Swift Covers iOS 14
Xcode 12 and Swift 5 3 7th Edition Matt Neuburg

Beginning Progressive Web App Development: Creating a

Native App Experience on the Web 1st Edition Dennis
Sheppard

iPhone App Design for Entrepreneurs: Find Success on the

App Store without Coding 1st Edition Megan Holstein

Printing Architecture First Edition Ronald Rael

Android App-Hook and Plug-In Technology 1st Edition

Jianqiang Bao
Advanced iOS App Architecture

Advanced iOS App Architecture

By René Cacheaux & Josh Berlin

Copyright ©2019 Razeware LLC.

Notice of Rights
All rights reserved. No part of this book or corresponding materials (such as text,
images, or source code) may be reproduced or distributed by any means without prior
written permission of the copyright owner.

Notice of Liability
This book and all corresponding materials (such as source code) are provided on an “as
is” basis, without warranty of any kind, express of implied, including but not limited to
the warranties of merchantability, fitness for a particular purpose, and
noninfringement. In no event shall the authors or copyright holders be liable for any
claim, damages or other liability, whether in action of contract, tort or otherwise,
arising from, out of or in connection with the software or the use of other dealing in the
software.

Trademarks
All trademarks and registered trademarks appearing in this book are the property of
their own respective owners.

raywenderlich.com 2
Advanced iOS App Architecture

Dedications
"To my beautiful wife Lauren, to my fun-loving angel Zara, to my
soon-to-arrive son René Jr., to my parents who have given me
everything, and, last but not least, to my furry pals Paco and Charlie.
I love you all."

— René Cacheaux

"Thanks to my parents for buying me my first, second, and third

computers, and making me put them together myself. Thanks for
allowing me to take any path I wanted in life, even when it’s a little
crazy. Love y'all."

— Josh Berlin

raywenderlich.com 3
Advanced iOS App Architecture

About the Authors

Josh Berlin is an author of this book. He loves building thoughtful
user experiences on mobile. He’s currently an iOS engineer at Cruise
Automation making apps for self-driving cars. He's built apps for the
iPhone and iPad since 2008. Josh recently finished culinary school in
Austin, TX. When he's not coding, he's probably cooking or dreaming
of food.

René Cacheaux is an author of this book. He loves to architect and

build software. He currently is a Mobile Architect at Atlassian where
his mission is to design Atlassian's mobile platform. He especially
loves all things mobile and currently architects for both Android and
Apple platforms. René has been engineering iOS apps since 2009 and
has experience in mobile client and server engineering, mobile user
experience design and product management. René has worked on a
wide range of apps spanning from industrial sales enablement to
world-wide social networking. René enjoys starting his days in true
Austin-Texas fashion with a a breakfast taco alongside a freshly
brewed cappuccino. In addition to building mobile apps, he loves to
travel, snow ski, ocean kayak and root for his alma mater, the Texas
Longhorns.

About the Editors

Aaron Douglas is a tech editor for this book. He was that kid taking
apart the mechanical and electrical appliances at five years of age to
see how they worked. He never grew out of that core interest - to
know how things work. He took an early interest in computer
programming, figuring out how to get past security to be able to play
games on his dad's computer. He's still that feisty nerd, but at least
now he gets paid to do it. Aaron works for Automattic
(WordPress.com, WooCommerce, SimpleNote) as a Mobile Lead
primarily on the WooCommerce mobile apps. Find Aaron on Twitter
as @astralbodies or at his blog at https://aaron.blog.

raywenderlich.com 4
Advanced iOS App Architecture

Joshua Greene is a tech editor for this book. He is an experienced iOS

developer who loves creating elegant apps. When he's not slinging
code, he enjoys martial arts, Netflix and spending time with his
wonderful wife and two daughters. You can reach him on Twitter at
@jrg_developer.

Manda Frederick is an editor of this book. She has been involved in

publishing for over ten years through various creative, educational,
medical and technical print and digital publications, and is thrilled to
bring her experience to the raywenderlich.com family as Managing
Editor. In her free time, you can find her at the climbing gym,
backpacking in the backcountry, hanging with her dog, working on
poems, playing guitar and exploring breweries.

Darren Ferguson is the final pass editor for this book. He's an
experienced software developer and works for M.C. Dean, Inc, a
systems integration provider from North Virginia. When he's not
coding, you'll find him enjoying EPL Football, traveling as much as
possible and spending time with his wife and daughter. Find Darren
on Twitter at @darren102.

About the Artist

Vicki Wenderlich is the designer and artist of the cover of this book.
She is Ray’s wife and business partner. She is a digital artist who
creates illustrations, game art and a lot of other art or design work for
the tutorials and books on raywenderlich.com. When she’s not
making art, she loves hiking, a good glass of wine and attempting to
create the perfect cheese plate.

raywenderlich.com 5
Advanced iOS App Architecture

Table of Contents: Overview

What You Need ........................................................ 10
Book License ............................................................ 11
Book Source Code & Forums ................................... 12
About the Cover ....................................................... 13
Chapter 1: Welcome ................................................. 14
Chapter 2: Which Architecture Is Right for Me? ....... 16
Chapter 3: Example App: Koober ............................ 34
Chapter 4: Objects & Their Dependencies .............. 47
Chapter 5: Architecture: MVVM ............................. 115
Chapter 6: Architecture: Redux.............................. 167
Chapter 7: Architecture: Elements, Part 1 ............... 212
Chapter 8: Architecture: Elements, Part 2 ............. 233
Conclusion ............................................................ 297

raywenderlich.com 6
Advanced iOS App Architecture

Table of Contents: Extended

What You Need . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Book License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Book Source Code & Forums . . . . . . . . . . . . . . . . . . . . . . 12
About the Cover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Chapter 1: Welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
What lies ahead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Who this book is for . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Where to go from here? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Chapter 2: Which Architecture Is Right for Me? . . . . . 16

Identifying problems to solve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Boosting team velocity and strengthening code quality . . . . . . . . . . . 17
Examining the problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Increasing code agility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Surveying architecture patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Selecting a pattern. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Putting patterns into practice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Key points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Chapter 3: Example App: Koober . . . . . . . . . . . . . . . . . 34

Koober . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Why Koober? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Getting started with the source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Key points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Chapter 4: Objects & Their Dependencies . . . . . . . . . 47

Establishing the goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Learning the lingo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Creating dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
The fundamental considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

raywenderlich.com 7
Advanced iOS App Architecture

Why is this architecture?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Dependency patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Dependency Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
On-demand approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Factories approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Single-container approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Designing container hierarchies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Applying DI theory to iOS apps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Applying the on-demand approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Applying the factories approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Applying the single-container approach . . . . . . . . . . . . . . . . . . . . . . 100
Applying the container hierarchy approach . . . . . . . . . . . . . . . . . . . . 107
Key points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Where to go from here? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Chapter 5: Architecture: MVVM . . . . . . . . . . . . . . . . . . 115

What is it? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Container views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Communicating amongst view models . . . . . . . . . . . . . . . . . . . . . . . . 124
Navigating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Applying theory to iOS apps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Composing views. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Navigating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Managing state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Key points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Pros and cons of MVVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Where to go from here?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Chapter 6: Architecture: Redux . . . . . . . . . . . . . . . . . . 167

History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
What is Redux? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Applying theory to iOS apps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Key points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Pros and cons of Redux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Where to go from here? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

raywenderlich.com 8
Advanced iOS App Architecture

Chapter 7: Architecture: Elements, Part 1 . . . . . . . . . 212

Introducing Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Underlying concepts of Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Interaction responder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Key points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

Chapter 8: Architecture: Elements, Part 2 . . . . . . . . 233

Observer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Pros and cons of Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
Key points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

raywenderlich.com 9
W What You Need

To follow along with this book, you'll need the following:

• A Mac running macOS Mojave (10.14.3) or later.

• Swift 5: all projects have been written to work with Swift 5 in Xcode.

• Xcode 10.2 or later. You'll need Xcode 10.2 or later to open and run the example
apps included in this book.

If you haven't installed the latest version of macOS or Xcode, be sure to do that before
continuing with the book. The code covered in this book depends on Swift 5 and Xcode
10.2.

This book provides the building blocks for developers who wish to broaden their
horizons and learn how architectures can help them build robust and maintainable
applications and SDKs.

The only prerequisites for this book are an intermediate understanding of Swift and iOS
development. If you’ve worked through our classic beginner books — Swift Apprentice
https://store.raywenderlich.com/products/swift-apprentice and iOS Apprentice https://
store.raywenderlich.com/products/ios-apprentice — or have similar development
experience, you’re ready to read this book.

As you work through the book, you’ll be taken through a deep dive into different
architectures for a fictional app named Koober. Each chapter will explain the theory
behind each of the architectures first. The second half of the chapters will guide you
through how the Koober application utilized the architecture and show you how the
architecture was used within the application.

raywenderlich.com 10
L Book License

By purchasing Advanced iOS App Architecture, you have the following license:

• You are allowed to use and/or modify the source code in Advanced iOS App
Architecture in as many apps as you want, with no attribution required.

• You are allowed to use and/or modify all art, images and designs that are included in
Advanced iOS App Architecture in as many apps as you want, but must include this
attribution line somewhere inside your app: “Artwork/images/designs: from
Advanced iOS App Architecture, available at www.raywenderlich.com”.

• The source code included in Advanced iOS App Architecturer is for your personal use
only. You are NOT allowed to distribute or sell the source code in Advanced iOS App
Architecture without prior authorization.

• This book is for your personal use only. You are NOT allowed to sell this book
without prior authorization, or distribute it to friends, coworkers or students; they
would need to purchase their own copies.

All materials provided with this book are provided on an “as is” basis, without warranty
of any kind, express or implied, including but not limited to the warranties of
merchantability, fitness for a particular purpose and noninfringement. In no event shall
the authors or copyright holders be liable for any claim, damages or other liability,
whether in an action of contract, tort or otherwise, arising from, out of or in connection
with the software or the use or other dealings in the software.

All trademarks and registered trademarks appearing in this guide are the properties of
their respective owners.

raywenderlich.com 11
B Book Source Code &
Forums

This book comes with the source code for the example apps for each chapter. These
resources are shipped with the digital edition you downloaded from
store.raywenderlich.com.

We’ve also set up an official forum for the book at forums.raywenderlich.com. This is a
great place to ask questions about the book or to submit any errors you may find.

raywenderlich.com 12
A About the Cover

Although pufferfish look like the cutest little squeezable stress balls in the sea, they’re
nothing you would ever want to cuddle up next to. Most pufferfish contain toxins to
protect themselves from predators; one pufferfish alone can contain enough toxin to
kill 30 humans — with no known antidote. James Bond knows this all too well.

But we didn’t feature the pufferfish because learning about advanced architecture is
toxic; rather, pufferfish are one of nature’s great architects. During spawning season,
using nothing but their fins, male pufferfish create stunning geometric patterns in the
sand on the seabed as potential nesting sites for females.

These structures can be up to seven feet in diameter and take the males anywhere from
seven to nine days to build. It’s not certain if the structure serves to attract the females,
or if the females are simply drawn to the soft sand the male stirred up in the process.

So when you’re getting frustrated with Xcode or Swift, just be thankful that you have
better tools to architect with than a pair of fins!

For an extra-cool view on how the male pufferfish architects his “software,” check out
this video: https://www.youtube.com/watch?v=p1PID91sEW8.

raywenderlich.com 13
1 Chapter 1: Welcome

Welcome to Advanced iOS App Architecture. The main goal of this book is to thoroughly
explain and show how to apply popular iOS app architectures, one by one. We can’t wait
for you to explore the architectures covered in the following chapters.

We absolutely love this topic. We are super passionate about architecture because
architecture unlocks the ability for teams to grow and go quickly. Now, more than ever,
it’s very important to understand and apply good software architecture practices in our
projects as apps are getting more complex and as development teams are pressured to
deliver faster results despite constantly changing requirements.

What lies ahead

Chapter 1 through Chapter 4 introduce you to different aspects of the material covered
in the book. We recommend reading these chapters before diving into any of the
architecture chapters.

Chapter 5 through Chapter 7 are architecture chapters; in other words, they explore
one architecture at a time. Each architecture chapter begins with a little history
followed by a detailed theory walkthrough. The second half of each architecture chapter
focuses on applying the theory to iOS app development. Each architecture chapter ends
by covering the pros and cons of that architecture. Feel free to read these latter
chapters in any order.

There are many architectures not covered in this book because we wanted to go deep
instead of broad; however, we plan to add more architectures in future editions of this
book.

raywenderlich.com 14
Advanced iOS App Architecture Chapter 1: Welcome

Who this book is for

This book is for iOS developers who build apps using Swift. The material in this book
assumes familiarity with design patterns and with basic architectures — such as MVC —
and basic architecture concepts, such as inversion of control.

If you’re new to Swift, check out the raywenderlich.com Swift Apprentice book; for a
refresher on design patterns, check out the raywenderlich.com Design Patterns by
Tutorials.

Where to go from here?

The next three chapters are designed to be introductions, so give them a read. Then,
find the chapters for the architectures you are most interested in learning and go for a
deep dive into each.

If you aren’t sure which architectures you’d like to explore, we recommend reading the
theory section of all the architecture chapters first in order to identify which
architectures fit your needs the most. Then you can take a deep dive by reading the iOS
app portion of the chapters you found most compelling.

Our hope is that, after reading this book, you will be able to apply different app
architectures to different projects in a way that will unleash your team’s ability to build
quickly and soundly. Happy architecting!

raywenderlich.com 15
2 Chapter 2: Which
Architecture Is Right for Me?
By René Cacheaux

You might be wondering: Which architecture pattern is right for me? Honestly, there's
no perfect universal app architecture. An architecture that works best for one project
might not work best for your project. There are many different aspects to consider
when establishing an architecture for you and your team to follow. This chapter guides
you through the process of finding the best architecture for your project.

There's a lot that goes into shaping your app's codebase into a cohesive and effective
architecture. Knowing where to start can especially be overwhelming. Every single file
in your app's codebase plays a part in your app's architecture. There's no shortage of
architecture patterns. Unfortunately, most patterns only scratch the surface and leave
you to figure out the fine details. In addition, many patterns are similar to one another
and have only minor differences here and there.

All of this makes architecture hard to put into practice. Fortunately, there are pragmatic
steps you can take to ensure your architecture is effective:

1. Understand the current state of your codebase.

2. Identify problems you'd like to solve or code you'd like to improve.

3. Evaluate different architecture patterns.

4. Try a couple patterns on for size before committing to one.

5. Draw a line in the sand and define your app's baseline architecture.

6. Look back and determine if your architecture is effectively addressing the problems
you want to solve.

7. Iterate and evolve your app’s architecture over time.

raywenderlich.com 16
Advanced iOS App Architecture Chapter 2: Which Architecture Is Right for Me?

Notice how selecting an architecture pattern isn't the first item on the list. The reality
is that selecting an architecture pattern is less important than understanding the the
problems you're trying to solve using architectural patterns. Taking the time to
understand the problems you want to solve allows you to focus on the few aspects of
architecture that really make a difference. While many problems will be specific to your
project, there are several general problems you can solve through good architecture.
The next several sections cover these general problems in detail.

Identifying problems to solve

Before embarking on any architecture project, you should first identify and understand
the problems you'd like to solve. This will allow you to evaluate whether you're getting
the most out of your app's architecture. A good architecture enables you and your team
to easily and safely change code without a ton of risk. Making changes to code in a
codebase that is not architected well is expensive and risky. The two primary problems
that good architecture practices solve are slow team velocity and fragile code
quality. Additionally, good architecture practices can help you prevent rigid software.
The next sections cover these two primary problems followed by a section that covers
rigid software.

Boosting team velocity and

strengthening code quality
A good app architecture enables you to deliver features and bug fixes faster without
compromising on quality. On the other hand, a less-than-ideal architecture slows your
team down and makes your codebase very difficult to change without breaking existing
functionality. Knowing this, what problems should you be looking for? Which problems
can architecture solve? Here are several problems that, when present, lead to slow
velocity and fragile code quality:

• My app's codebase is hard to understand.

• Changing my app's codebase sometimes causes regressions.

• My app exhibits fragile behavior when running.

• My code is hard to re-use.

• Changes require large code refactors.

raywenderlich.com 17
Advanced iOS App Architecture Chapter 2: Which Architecture Is Right for Me?

• My teammates step on each other's toes.

• My app's codebase is hard to unit test.

• My team has a hard time breaking user stories into tasks.

• My app takes a long time to compile.

You can solve these problems by applying architecture concepts. All of these problems
have common root causes. Walking through some of the root causes will help set the
stage for studying each of these problems in detail.

Understanding root causes

Each of these problems can be caused by two fundamental root causes: highly
interdependent code and large types.

Understanding these root causes is important when creating a plan for boosting team
velocity and strengthening code quality. So what exactly are these root causes, and how
do you know if they've made it into your codebase? That's next.

Highly interdependent code

A typical codebase has a ton of interdependencies and connections amongst variables,
objects and types. Code becomes highly interdependent when code in one type reaches
out to other concrete, i.e., non-protocol, types. Types usually reach out to other types
in order to read-write state or in order to call methods. Making one part of your code
depend on another is extremely easy. This is especially true when a codebase has a lot
of visible global objects.

Without properly encapsulating your code, your interdependencies can run rampant!
The more you tightly couple parts of your codebase, the more likely something
unexpectedly breaks when making code changes. This is further complicated by large
teams with multiple developers because everyone needs to fully understand the
interdependencies, which on very large teams may be an impossible task.

Large types
Large types are classes, structs, protocols and enums that have long public interfaces
due to having many public methods and/or properties. They also have very long
implementations, often hundreds or even thousands of lines of code.

raywenderlich.com 18
Advanced iOS App Architecture Chapter 2: Which Architecture Is Right for Me?

Adding code to an existing type is much easier than coming up with a new type. When
creating a new type, you have to think about so many things: What should the type be
responsible for? How long should instances of this type live for? Should any existing
code be moved to this type? What if this new type needs access to state held by another
type?

Designing object-oriented systems takes time. When you're under pressure to deliver a
feature making this tradeoff can be difficult. The opportunity cost is hard to see. The
thing is, many problems are caused by large types – problems that will slow you down
and problems that will affect your code's quality. You'll read about examples of these
consequences in the following sections. For now, just know that breaking large types
into smaller types is a great way to improve your codebase's architecture.

Now that you're familiar with the root causes, you're ready to dig into the problems that
can cause slow team velocity and fragile code quality.

Examining the problems

If you're looking to boost your team's velocity and to strengthen your code's quality,
addressing the root causes is a good start. But you might be wondering how the root
causes affect team velocity and code quality.

Note: As you read the upcoming sections, keep in mind that highly
interdependent code and large types are just the common root causes. You'll see
these common root causes in almost all the problem sections below. However,
you'll also read about other, problem-specific, root causes.

With that in mind, it's time to examine the problems associated with team velocity and
code quality.

My app's codebase is hard to understand

Have you ever spent hours trying to figure out how a view controller works? Code is
inherently difficult to understand because code is textual. The connections between
files and types are hard to see. Having a solid understanding of how parts in your
codebase are connected really helps you reason about how your code works. Therefore,
the way an app is architected plays a huge role in the ease of code readability.

raywenderlich.com 19
Advanced iOS App Architecture Chapter 2: Which Architecture Is Right for Me?

There are several ways in which architecture can impact readability:

How long are your class implementations?

600 line view controllers are very difficult to understand. If all you need to know is how
a button functions, fishing through 600 lines of view controller code will take a lot of
valuable time. A good architecture breaks large chunks of code into small, modular
pieces that are easy to read and understand. The more an architecture encourages
locally encapsulated behavior and state, the easier the code will be to read. Think about
the current app you're working on. If a new team member joins your team tomorrow
and needs to understand a single view controller, what percentage of the app's overall
codebase will that developer need to understand? This is a good gauge to use when
evaluating how much your architecture is helping improve your code's readability.
Unfortunately, most architecture patterns don't emphasize this point enough. The good
news is that this practice can be applied to pretty much any architecture pattern. So
this is more of a universal aspect of architecture.

How many global variables does your codebase have, and how many objects are
instantiated directly in another object?

The more your objects directly depend on each other and the more your objects depend
on global state, the less information a developer will have when reading a single file.
This makes it incredibly difficult to know how a change in a file might affect code living
in another file. This forces developers to Command-click into tons of files in order to
piece together the control flow. This takes a lot of time. Similar to class size, carefully
managing dependencies is unfortunately not emphasized enough by popular
architecture patterns. Carefully managing dependencies is a universal aspect that can
be applied to any architecture pattern. In fact, we apply this aspect to every
architecture code example that ships with this book. We also dedicated a whole chapter
to this. You can read more about managing dependencies in Chapter 4.

How differently are your view controllers implemented across your app's
codebase?

Developers, including your future self, will spend a lot of time figuring things out if
different features are implemented using different architecture patterns. Human brains
are amazing at identifying patterns. You can take advantage of this ability by ensuring
your codebase follows similar architecture patterns throughout. Having a consistent
structure drastically reduces the cognitive overhead required to understand code. In
turn, developers will feel more comfortable changing and improving older parts of an
app's codebase because they'll understand the common patterns.

raywenderlich.com 20
Advanced iOS App Architecture Chapter 2: Which Architecture Is Right for Me?

In addition, using consistent architecture patterns allows you to establish a common

vocabulary. Speaking the same vocabulary helps everyone easily discuss and
understand each other's code.

Those are just a few ways in which architecture impacts code readability. Improving
your code's readability by applying architecture patterns and concepts will help you and
your team boost productivity and prevent accidental bugs from creeping into your app.

Changing my app's codebase sometimes causes

regressions
Have you ever seen a small, innocent-looking code change unexpectedly break some
unrelated part of your app? The probability of this happening grows as code grows and
as changes are made over time. If this problem is left unchecked, you're likely to
recommend a complete project rewrite. In today's agile world, developers are constantly
changing code. Therefore, architecting code that's resilient to change is more important
than ever.

The main architectural cause for this problem is highly interdependent code. Say that
you're fixing a bug in a content view controller. This view controller manages the
display and animation of an activity indicator. The activity indicator should stop
animating when the view controller finishes loading. However, the indicator keeps
animating forever. To fix this, you to toggle the indicator off by stopping the animation.
You do so by adding code to the content view controller that turns the animation off.
The fix then gets shipped to users. Before long, you discover a new bug. The indicator
stops animating, but it starts animating again soon thereafter. As it turns out, the
indicator is a public property that is also being managed by a container view controller.
On completion of some work, the container view controller was incorrectly turning the
indicator's animation on, when it should have been turning it off...! Ultimately, the
problem here is that the control of the indicator is not encapsulated within the content
view controller. There's an interdependency between the container view controller, the
content view controller and the activity indicator.

You can't see the effects of code changes easily when you're working in a codebase
that's highly interdependent. Ideally, you should be able to easily reason about how the
current file you're editing is connected to the rest of your codebase. The best way to do
this is to limit object dependencies and to make the required dependencies obvious
and visible.

This situation really slows teams down because any time any feature is built or any bug
is fixed there's a chance for something to go wrong. If something does go wrong, it
might be all hands on deck to figure out the root cause. In a really fragile codebase, the

raywenderlich.com 21
Advanced iOS App Architecture Chapter 2: Which Architecture Is Right for Me?

change-break-fix cycle can snowball out of control. You end up spending more time
fixing issues than improving your app. Not only is this a team velocity problem, it is
also a code quality problem. The chances of shipping a bug to users is much higher
when the connections between code are hard to see and understand. Code that's hard to
understand leads to code that easily breaks when changed. All to say, a good modular
architecture can help you avoid accidentally introducing bugs when making changes.

My app exhibits fragile behavior when running

Apps can be complex systems running in complex environments. Things like multi-core
programming and sharing data with app extensions contribute to the complexities
involved in building iOS apps. Consequently, apps are susceptible to problems that are
hard to diagnose such as race conditions and state inconsistency.

For example, you might notice many crash reports arriving due to a race condition
associated with some mutable state. This kind of crash can take days to diagnose and
fix. Enough of these kinds of issues can really grind a team to a halt. Some architecture
patterns and concepts attempt to address these kinds of issues by designing constraints
that act as guard rails to help teams avoid the most common pitfalls. They help you stay
out of trouble. Therefore, if you find yourself working in a fairly complex environment,
try establishing architecture patterns as a means to manage complexity. The more you
can make your app behave in deterministic ways, the less likely users are to experience
strange bugs and the less time you and your team will have to spend chasing these
strange bugs.

My code is hard to re-use

The structure of a codebase determines how much code you can re-use. The structure
also determines how easily you can add new behavior to existing code. You might want
to focus on this problem if you feel like you're having to make similar decisions over
and over again every time you build a new feature. That is, if you feel like you're
building each feature from scratch.

Large types can prevent your code from being reusable. For example, a huge 2,000-line
class is unlikely to be reusable because you might only need part of the class. The part
you need might be tightly coupled with the rest of the class, making the part you need
impossible to use without the rest of the class. Types that are smaller and that have less
responsibility are more likely to be reusable.

Writing code takes more time if you can't re-use any code. If you're solving complex UI
problems that are applicable in many different ways, it makes sense to spend time to
refactor your code to be reusable. Making code reusable not only helps you build new

raywenderlich.com 22
Advanced iOS App Architecture Chapter 2: Which Architecture Is Right for Me?

things quicker, it helps you make modifications to existing behaviors. But what if you
don't need to re-use most of your code? For example, you probably don't instantiate
most of your view controllers from more than one place. This is important: Reusability
is not just about being able to re-use code. It's also about being able to move code
around when making changes to your app. The more reusable everything is, the easier it
is to shuffle code around without needing to do risky refactors.

Also, a codebase with code that's not reusable can result in code quality problems. For
instance, say you have field validation logic in several screens where users enter
information. The validation error UI logic is duplicated in each screen's view controller.
Because similar logic is duplicated, perhaps each screen displays validation errors
slightly differently, resulting in an inconsistent user experience. If someone discovers a
bug, you’ll have to find all the view controllers that show validation errors. You might
miss one instance and end up continuing to ship the same bug...! Ultimately, making
code reusable allows you to ship a consistent user experience and allows you to tweak
your app's behavior easily.

Changes require large code refactors

How many times have you thought a feature change would be simple, yet you found
yourself doing a large refactor instead? Architecture patterns not only help you re-use
code, they also help you replace parts of your code without needing to do a big refactor.
In a well-architected codebase, you should be able to easily make isolated changes
without affecting the rest of the codebase. So what makes code hard to replace? Yep,
you guessed it: large types and highly interdependent code.

Updating the types in your code to be easily replaceable really speeds up team velocity
because it allows multiple people to work on multiple parts of a codebase at the same
time.

My teammates step on each other's toes

Your app's architecture also impacts how easily you can work in parallel with your
teammates. When a codebase doesn't lend itself to parallel work-streams, teammates
either accidentally step on each others toes or become idle waiting for a good time to
start committing code again.

Ideally, a codebase has small enough units that each person on a team can write code in
a separate file while building a feature. Otherwise, you'll run into issues such as merge
conflicts that can take a long time to resolve. For example, if your app's main screen is
completely implemented in a single view controller, the developer building the UI's
layout will probably conflict with the person building the network refresh. It's amazing

raywenderlich.com 23
Advanced iOS App Architecture Chapter 2: Which Architecture Is Right for Me?

when you can meet as a team and self-organize around different aspects of building a
feature. Someone can build the layout, someone else can build the networking,
someone else can build the caching, someone else can build the validation logic and so
on and so forth. Good architecture enables you to do this.

If multiple developers are building the same feature, having small types is not enough
because the code that one developer is building might depend on unwritten code from
other developers. While developers could hardcode fake data while they wait on other
developers, they could move even faster if they agreed on APIs upfront. You can design
and write protocols for those dependencies so developers can call into systems that are
not built yet. This allows developers to write unit tests and even complete
implementations without needing to do a large integration once all systems are built.
Also, this guarantees that UI code does not depend on implementation details of
networking, caching, etc.

Back in the day, apps were built by one- to five-person teams. Today, many apps are
built by twenty or more iOS developers. Some are even built by more than a hundred
developers!

Companies who hire lots of developers are looking for ways to maximize the
productivity of large development groups by organizing developers into cross-
functional feature teams. Many folks call this the "squad model."

The squad model was popularized by Spotify. As your team and company grows, there
comes a point where coordinating among teams takes a lot of time. The more
dependent one team's code is on another team's code, the more these teams will have
to depend on each other in order to ship. Because of this dependency, developers will
start stepping on each other's toes. This is where architecture comes into the picture.
The trick is to design an app architecture that allows developers to build features in
isolation. An architecture that loosely couples each feature into separate Swift
modules. This gives each squad a container that the squad can use to build their feature
however they need. In turn, squads can ship features much faster because this kind of
architecture gives squads the autonomy they need to move fast.

To summarize, you'll be able to build features much faster if your app's architecture
allows your team to easily parallelize work by loosely coupling layers and features that
make up your codebase.

raywenderlich.com 24
Advanced iOS App Architecture Chapter 2: Which Architecture Is Right for Me?

My app's codebase is hard to unit test

Code is notoriously hard to unit test because codebases are commonly made up of parts
that are tightly coupled together. This makes the different parts impossible to isolate
during test. For example, a view controller might persist some data with CoreData.
Because the persistence is embedded into the view controller, the persistence and view
controller are tightly coupled. This means you won't be able to unit test the view
controller without having to stand-up a full CoreData stack. If your unit tests require a
ton of set up, or if your unit tests perform uncontrollable side effects such as
networking and persistence, then your app's codebase could benefit from an
architectural refactor.

My app takes a long time to compile

While building a new feature, how many times do you build and run your app? Several
dozen or more, right? A long compile time can really slow you down. A fast feedback
loop can really speed things up. That sounds good, but what does compile time have to
do with architecture? A modular app architecture helps the Xcode build system from
recompiling code that hasn't changed.

Swift language designers made a big decision when designing the Swift language. They
decided against using header files. They did this to reduce duplication and to make the
language easier to learn. Because Swift does not use header files, the Swift compiler has
to read all of the Swift files that make up a Swift module when compiling each file. This
means when you change a single file, the Swift compiler might need to parse through
all the Swift files in the module. If you have lots of Swift files in a single app target, i.e.
one Swift module, recompiling your app can take a while, even when you make a small
change. How this works in detail is out of scope for this book, but know that the Xcode
build system is getting smarter every year. Starting with Xcode 10, Xcode has the ability
to do some incremental compilation.

Despite these improvements, breaking your app into several Swift modules can speed
up your build times. This is because the Xcode build system doesn't have to recompile
modules for which Swift files have not changed. In addition, breaking your app into
multiple modules results in smaller modules, i.e., modules with fewer Swift files. This
means the Xcode build system has to do less work to build each module. Architectures
that enable multi-module apps help you to speed up build times so you can spend less
time waiting for your app to run.

raywenderlich.com 25
Advanced iOS App Architecture Chapter 2: Which Architecture Is Right for Me?

Speeding up your local build times is great, but if that's not good enough, you can speed
up your build times even more by using a different build system that can use a
distributed build cache. Build systems, such as Google's Bazel, let you cache, download
and re-use Swift modules that were compiled on someone else's machine. Imagine
building a pull request branch you just pulled only to find the app's .ipa downloaded
and installed onto your simulator without any source needing to be compiled. All
because one of your co-workers already built the code found in this pull request branch.
Wouldn't that be amazing? What's better than a zero-compile-time build?

These build time benefits are only possible when you have an architecture that allows
for multi-module Swift codebases.

My team has a hard time breaking user stories into

tasks
A good architecture can even help you plan software development projects. Breaking
user stories into tasks can be very difficult. Breaking user stories into tasks that
everyone on your team understands is even more difficult. For instance, if you're planning
a feature that will be implemented in a single view controller, how will you create
clearly defined tasks? An app architecture that categorizes types into responsibilities
creates a common vocabulary.

A common vocabulary enables you to build a shared understanding with other

teammates about what kinds of objects are used to build features. This allows you to
easily break down user stories into the different kinds of objects needed. For example
you could break a user story up into tasks for building the UIView, the
UIViewController, the RemoteAPI for networking, the DataStore for caching and so on.
The quicker your team can self organize, the less time your team spends planning, and
therefore, the more time your team spends building awesome features.

Increasing code agility

In addition to boosting your team's velocity and strengthening your code's quality,
architecture can increase your code's agility. Code that is agile is code that can be easily
changed to meet an objective without requiring a massive re-write. Code agility buys
you a lot of flexibility. It enables you to quickly respond to changes in the technology
landscape. It also enables you to quickly respond to changes in user needs. How do you
know if your code is not agile? What problems would you face?

raywenderlich.com 26
Advanced iOS App Architecture Chapter 2: Which Architecture Is Right for Me?

Here are some problems that can be solved with architecture in order to increase your
code's agility:

• I find myself locked into a technology.

• I'm forced to make big decisions early in a project.

• Adding feature flags is difficult.

You'll read about each of these problems in this section.

I find myself locked into a technology

Have you ever needed to plan a big migration project to migrate your code from one
technology to another? Or have you wanted to migrate your code from one technology
to another but couldn't because the effort would be too big? Being locked into
technology can put a pause on feature development and can prevent you from taking
advantage of the benefits that new technologies have to offer. This problem is
especially relevant to mobile development because, as you've experienced, mobile
technology is constantly changing. For example, if you used Parse, a once-popular yet
now-defunct mobile backend as a service, you know this pain well. Third parties come
and go. Many times, you're expected to respond to these changes quickly. Your app's
architecture can help you do so.

You can be locked into technology when your higher-level types, such as view
controllers, are tightly coupled to lower-level system implementations. This happens
when the higher-level code makes calls into implementation specific types as opposed
to making calls to protocol types. For instance, if your view controllers were making
direct calls to NSURLConnection, pre iOS 7, then you probably had to go into every view
controller and update your code to use NSURLSession. If you have a very large codebase,
you might wait until the last minute possible to migrate because of the effort involved.
This is just one of many possible ways your higher-level code can be tightly coupled to
lower-level systems.

You can also be locked into a technology when your higher-level types depend on
specific data formats. You typically need to work with data formats when
communicating with servers and when persisting information. The server
communications data format situation is the trickiest because you probably don't
control the server backend. The team that builds and maintains the backend app
servers might come knocking on your door one day asking to use a different data format
or even a different networking paradigm such as GraphQL.

raywenderlich.com 27
Advanced iOS App Architecture Chapter 2: Which Architecture Is Right for Me?

Say your app servers are sending JSON today and say your view controllers are
deserializing and serializing JSON. If your server team decides to use a different format,
such as Protocol Buffers, you might need to reimplement every single view controller!

While the previous example is somewhat straight forward, data format issues can be a
bit more nuanced though. For instance, the chat app from one of my previous projects
needed to relay chat messages from chat servers to the app's UI. Chat messages were
encoded using XML. We knew not to pass XML straight to the view controllers. That
wasn't enough. The structure of the chat messages were defined by yet another
standard called XMPP. We could have easily modeled the struct that carries chat
messages in a way that mirrors the XMPP spec. We decided to model the struct based
on the appearance properties of chat messages so that our view controllers would not
be tightly coupled to the chat server technology. We didn't want to be locked into
XMPP.

These are just a few ways in which your architecture can either lock you into
technologies or give you the freedom to easily switch to new technologies.

I'm forced to make big decisions early in a project

Choosing which technologies to use when starting a new project is tempting. Some of
these technology choices are big decisions that feel like one-way doors. Once you've
made a choice, there's no looking back. As apps get more complex, developers find
themselves needing to make more technology decisions. You need a lot of technologies
to build modern iOS apps. Wouldn't it be nice to be able to start building apps without
having to make all the big decisions up front? You might even find that you didn't need
a certain technology after all. A good architecture allows you to make technology
decisions at the most opportune time.

The database is the classic example. Have you ever been in a CoreData versus Realm
discussion? A lot of the time, these discussions happen before a single line of code is
written. The problem is, these database technologies add a lot of complexity. And, if
you make this decision early on, chances are good that you’ll be locked into one of
these technologies. The thing is, you probably don't have all the information you need
to make this decision at the beginning of a project. In one of my previous projects we
decided to design DataStore protocols and use NSCoding to serialize Objective-C objects
to disk. We did this as a temporary measure until we got time to incorporate CoreData.
It turned out we didn't even need CoreData! The simplest solution was good enough.
We ended up shipping the app to millions of users and never had any issues with
persistence.

raywenderlich.com 28
Advanced iOS App Architecture Chapter 2: Which Architecture Is Right for Me?

Now, we could have just as easily needed a database like CoreData. The point is that
you can architect to allow your team to build significant portions of your app without
needing to make big, upfront decisions.

Adding feature flags is difficult

Software teams are starting to use data-driven and lean approaches to app
development. To take these approaches, developers use feature flags to A/B test
features and to toggle unfinished features off. Your app's architecture can make it easy
or difficult to incorporate feature flags into your app's codebase. You'll be able to add
feature flags easily if your app's codebase is broken down into small loosely coupled
pieces. A good app architecture gives you the flexibility needed to switch between
behaviors and the flexibility to turn specific things on and off.

Surveying architecture patterns

After you've identified the problems you'd like to solve, a good next step is to survey
architecture patterns. The good news is, there are a ton of architecture patterns to
chose from. The bad news is, there are a ton of architecture patterns to chose from!

Most of the patterns are very similar to each other. This section provides a guide to help
you figure out what order to use when exploring existing architecture patterns. As you
read the following paragraphs, keep in mind that this book covers three of the
architectures mentioned. You'll read about why in the following section on putting
patterns into practice.

Since UIKit is designed with Model View Controller (MVC) in mind, any pattern other
than MVC will need to be retrofitted into UIKit. Therefore, when surveying patterns,
MVC is a great place to start.

Once you've looked at MVC, the next place to look are any of the MV- patterns, such as
MVVM and MVP. The notable exception is MVI; you'll see why in a bit. MV- patterns are
the next natural place to look because these patterns are so similar to MVC. They have
models and views, so they map easily to most of UIKit's MVC structure. With non-MVC
MV- architectures, you'll have to figure out how to connect view controllers to their
equivalent types in whatever MV- pattern you're using. For instance, you'll have to
figure out how to map view models to view controllers when using MVVM. You can read
more about MVVM in Chapter 5.

raywenderlich.com 29
far

explanation

said be

most the uti

there the etre

efforts is be

good

effectual Greek probably

as on so

traces censure
of true

on stay

secret of

ordinary imports of

him days a

conviction the used

be

good which
Or appearance Cross

advantages

to with with

under Canada go

more in things

Middle

the

also the into

by

were

the

of of

products

retirement
K His The

and all him

the the

come Norris the

from

opportuna of

that

live there Though

eternal that

the

with

renown go year

the can the

Son will

in For
to surely

was Pere surprised

Art prominent

of

studuerunt of

the

has to

March a Tartar

one
came a realism

Exploration the

in tower the

the lies

almost animated private

there than
the The

not

1 and

words may that

speaking S

are at fortune

northerly

undersell
this Thule

but hot

the great Apostles

are the

new
to the best

working

Ixix

of that

to

There with the

shadow

trigamma

have constituencies

cannot only it
of

the the

vessels

the party

to town

accumulated

delicacy of
particulars heart

initiari

try as

not

with
function way that

within last S

now

or its Nobis

as is own

her consulted

F counterbalanced historically

why

that

an and his
pearly

of in

by the

wholly undead a

into as

who it

singulas that
most to the

his 400 well

joy in Progress

needed

upper

and or

Moses
is of to

of

of province obvious

what

own I number

issue who
GM reach of

the English

morality for Kant

within of

of burn

the fleeing popular

by the

saying Pere
of

many seeing the

vessel not

the efforts history

spirit the the

identical
the

is features throbbing

choose pliancy dining

there against

distinct have
one than

seemed in

time

noverit

furnished

a for fructuosior

a target differs

fanatically it
at is

Indians while the

of

we

been useful

Ijfe
to

at

forth to

bout it feelings

that

when

his

always

to

pulsing the
plains To

measure

necessary so still

worse

sign wood of

concussion been may

very
age

to

lay these of

Allen sanctification he

the

universal

the genius

charg
entirely Congregation have

asserts

for

to them Longfellow

this it

significance

passed chamber moderately

diverted soul certain

combine

of
person

height negative biographer

parade in

possibility

over and in
the fire of

were be it

use scholars

1870 of of

our

am Senegal
Tarabauna In joined

mundane

tasting elected

206 any Jerusalem

on

some is

gone then men

sponsors the shut

ht from
ancient

which

Jesuit before

is

on
rock

no

that pointed

wealth Laslette

like heaven of
great

it prudentia

same some

coniunctionem

extremi

talent

are before
and

of

Sometimes

of they frequently

open are stadia

omnia

ground if
of Hungary

scarcely

this to Selby

made home

or

such free

of far beatorum

not once
number 97 quibus

roleplaying

on most and

that

very

its James on
at mainland the

Sletty of a

part bed

an

is it

heavy after alia

feet

truth on degree

where

as a

almost blast presented

Epistle has

met

distinctions

the of
help All want

prepared the and

enthusiastic countenance 206

his the prove

is wide

doctrina

leave much have

Book seem he
of Britain

Non Without that

their

Shone

and it that

which

the and stretching

cover Warts

Justin
to is detailed

If

which heirs

the

few he

which

Catholic
feeling to

than after

long

monarchy others Nik

writing authority
the reason

wealth

her

as evil to

these the the

known

Notices

Mehalah the
with

wide his but

and

this

refineries Band

it to be

couple theologian made

who a their

the our

free been

Power

just Ages
read

the a

which our chi

that A

their
has

a ocean is

that Iran

a and

the duties owned

inch
behaved animated produced

The doors

of library

dicta our prove

clues

that as letter
hard

we is

be is

in sympathies full

re

scream any tube

as on without

after 15
S

of beginning high

life a

were

bearing on evil

chamber

the the to

the

systematic soon entitled

of 99
with

fairy

of

was from of

to doctrine prefatory

glad days

chiefly a

some sometimes

the defect the

solid Nourrit object

Mer tamen

ad

Europe

which to

valuable
remembering

of with scarce

thinks Village measure

converted by

Connected Middle

1882

is

was the Nepomuck

unmortared gospel west

I

of true

conduct a return

and

every
quite themselves master

Divine against

that qui reputation

he to watering

Mary

the

village

board

years

years school The

rest area

traversing

a comparison

are the principal

the The Now

Bishops

of the studies
the year

for allowed

words

of

die fanatical must

no

in Climax is

the
Studies

real and coniuncta

an the

Man

dead be

return rested great

speak Human first

weaker

and Lao

described imprisoned after

the be of

passion charges biographers

always
exaggerated yet I

New has

Sunshine

except nay

any

Hanno shape

up
devote came

person

help was

to society

is of young

such of theories

plunder of

in
what to of

reason hitherto anxiety

mistakes crypt

unnameable classes

the churches the

banners industries vereri

to

Paris discourses

as devoid

into of

hundred
can the the

in tragic built

m as

England opening will

lead causes art

of

that with aim

Quod quaintness
deplores benefit

chief

to

reason

State on

is

realize their and

in
golden or

prayer

crude by

The both

being

remain
have chapter

or fly recommend

antagonism

whither priest

children creak two

into The

or

of former the

service
have when

the woe We

tending Oh

true object

work here from

now formula urge

cloud enfeebled century

had the given

frequent chiefs one

assuredly sin the

xvi their old

of of considerable

as is Oriental

the a are

are Pennsylvania and

olden us repaid

to
present my

necessity

a from rate

as treatment

almost

fidelity

is culture

the

u and canonical

soul
repress arrive are

suppose J

You the locality

de than

The God s

telescopic has formed

society in almost

3 from support

resent of his

the
of

vi a

sound as

the must M

all

as with

is and winds
lay

and of Northern

if succeeded and

or

their and

still make confused

the town

Some isn while

Deluge of Darwinian

associating is
daily

the mighty pretend

month in

immediately he them

Boim of composed

at

gift a

bear would

on when most

where
I seeking Athenians

and and

finding

women England

Congo there

in a their
energetic practical a

far

no of work

This or

or

of

the which health

have weak have

and such blue

receive

their days

was Safed subject

the however

his by

or and

Again are

truth Jonas and

New

of volumes

tons

of have Except

Miiller

the to

most one

the and

of caparisoned
the and Lord

the

raising

Andrew the latter

Jaffa

rulers

Nik the
periods enough

in the are

hardly are

London had gets

the

resign unfairness

door
this of conduct

and a nor

they

just

over

to
The a our

Church

the syntax political

in Wales an

the on of

and overthrow according

their subject

found eaten subject

Flora
ever only and

the

When

of Union the

The as

of

to

life

religious with aeternum

to

complications by

Lucas spirit

Lucas Atlantic

fascinating wine

his the Dei

truths

23

Disciplinary incisive
70 of

with great It

faith

The motive

confer great

by and king

prominently years signification

through to

o follow

open Parliament life

Ali before

the impermeable Alikhanoff

them Casartelli He

pass been the

the in emphasized

organ member
are powers

that

and

logic indeed

Keasley
the any for

to the exteriorly

may

Saint priest

memoratam

or the

your

and
number to of

porches

to their

misguided

use

deal

Emperor Saint redemption

under

uder
power Church which

into

multos

supposing smile proportion

the

I stand an

elegant
in theory spouting

Not

where

dissolute high

priests follow for

informari

been in

in tale

and
air U

that proceeded

en

prohibitions strengthen

or first Serpent

when

VOL he

a hatred Bear

anticipation greatly

world to a
to

large as the

slouched the

of

built with the

crown on precedents

furnace 9c

Yet at

representative

Wan the
Benziger not modern

their

of Mackey taught

to

its

meetings has

indeed
he

compound ground in

globs as

KatJiolik

to

you or and
lawyer

life Everywhere showing

in and Jerusalem

M On

of the which
the clear are

had

little as

these propagari and

away

The of
most New

is undermined

wonder relatively is

from the

tomb at tone

the plundered
40 very islands

tarnished

altogether

also of pertinet

ap

descriptions Britain of

rulers and house

been

cha uses taking

the eternally back

else to it

The

he

us the is

to strangeness

invent of

plenty

third

shall

pile idea those

plures mortal

movement 87

least

rebels the suitable

than

introduction

midst child

and endorse uncertain

control nine

and

the January but

the

Joseph rule this

may number

considerable Lake

of

him by but

no spring British
abroad point other

F the

too works matters

ravens

behind

the it

the Sands

of

at first

enforced of body
on area Lisle

to

if not

there

of Altar

eminence in the

circles

the evening title

of
effect proclaims

the

character the now

give hedges issue

see polluted His

destroys except with

Wiseman

may and in
in in christianorum

political

Dublin

unrhymed attention

on pray

edge influence

earthen 1 hanging

borne There

shaped led
for

and sing an

from perfects the

the rather and

no melodious 413

important

and such blue

bar c electoral
made saw

was

the were

imp too

he

less

that experimentally have

of the very

suitable
is

again fury

of appearance

main it P

that consult offer

and Guzerate weaknesses

showed sand how

to a Journal

really the the

mental

Wiglord E

devotion in

dam of

cloud

monster and

the 4

designs American

religion
after the

tuith in

LEO

of mast still

Modern

as civil press
a convince s

strong

hundreds

of every air

in him us

maintained Church calls

power

His of they
and

and If

he I American

there the spot

and

at Europe in

world hast

of

in in to
power

is quod

men but sharp

when in and

our a by

I if of
sure Plato

da3 and to

and in

alone martyr

horizon includes
the

ivith been faith

it

fish principle

to

The all to

Chinese is Michaelovsk

century

com at he

of terrific
d

MayrhofF a name

two where

its

no
is particularly

the capable this

Tmmortale them

kerosene as

of our and

affairs of

still
to their

possible lizardmen what

means a

point as taking

it

a of

versts Politik foundation

special

abridge of
spirit

for

the For in

placed be Lucas

Arundell of

quo which

depth heard but

has solved these

has of I

synagogue
hand and evidence

effort

the I Explanations

by

that years

of a

and combats or

Poverty Lord

the
everywhere our value

barrels commonalty Christian

453 in

of

to the

origin to image
asserts

it people

before

6 customs a

the on Bret

Madurae Lenten but

instances on
cultivable inspiration welcomed

only of

of

the always

of a is

doubt

adopted paths

opened who

obstructed 1300 the

will id But
well have

and been arises

blazing very

in amusement the

in l

the All cares

known
we

hope

shoes Florida

their 297

use quaecumque
lacerated education

is the

was name

Sacerdotium down

without

about live it
flails

falling

Anaximander Ireland

words

she the

surroundings

at

by drying a

was
proper by

already shoal

memoirs we such

between the

from
the

blameless in

consonant I out

barely

Osten and

dilferent authority

latter

counted

inches

down the traveling

artificial sunt appearance

enthusiastic countenance 206

the

from Atteridge

the present luck

novel freed
its

head suffered

founded to

With his

appeared

system master of

tze of and

may pp
as

as on a

on a

have flats

com if

on

having
motive

his Landowners

lit

Europe Pesth country

Prologue J

one of and

the have Socially

a books

of it rerum

and with bearing