From Zero to App Store is a series that journals the development of Cocoacasts for iOS and tvOS. With this series, I aim to offer a look inside the workflows and processes I use to build and ship software. This series aims to touch every aspect of mobile software development, including source control, continuous integration, release management, and App Store deployment. It goes well beyond writing code.

From Zero to App Store won't focus on running a business on Apple's platforms, but it touches on a few ideas and concepts that relate to business. This episode focuses on defining the first version of the product. In the startup community, this is often referred to as defining the minimum viable product or MVP for short.

Even though Xcode makes it simple to set up a project, there's more to it than choosing a template and clicking a few buttons. The workflow I use to set up a new project is straightforward and easy to follow. In this episode, I show you what it looks like.

Most developers don't take pleasure in resolving code signing issues and that includes me. While managing certificates and provisioning profiles has become easier over the years, it can still be challenging. If you're working in a team or use a build server to create and distribute builds, then code signing can become complex.

Every Xcode project starts out with two build configurations, Debug and Release. The names of these build configurations speak for themselves. The Debug configuration is used to create debug or development builds. Builds destined for TestFlight and App Store are built using the Release configuration. Having a Debug and a Release configuration is sufficient for some projects. Most setups require more flexibility, though.

Every project I work on makes use of view controller containment. This isn't surprising since several UIKit components take advantage of this pattern, including navigation controllers, tab bar controllers, and split view controllers. But I'm not only referring to the components UIKit offers out of the box.

Logging is an integral part of my debugging workflow and it's therefore something I invest time in to get right. Swift's print(_:separator:terminator:) function works fine, but it isn't ideal for debugging issues. To use logging effectively in a debugging workflow, you need a powerful and flexible solution.

In the previous episode, I showed you the setup I use to log messages with CocoaLumberjack. There's a lot more CocoaLumberjack has to offer. In this episode, you learn how to forward log messages to a remote server. I show you how to integrate CocoaLumberjack and PaperTrail, a popular solution for managing logs. We also take a look at an alternative approach, that is, how to send log messages to Fabric. Logs can be very helpful in combination with crash reporting.

In this episode, we adopt the coordinator pattern. I won't cover the details of the coordinator pattern in this episode, though. Coordinators are covered in detail in Mastering Navigation With Coordinators.

The first episodes of this series have almost exclusively focused on creating a foundation for the project. While this may seem tedious or even premature, it allows anyone working on the project to focus on writing code. Automation is an important part of modern software development and it pays to set aside some time to create a foundation for the project you're working on.

We successfully fetched a list of episodes from the Cocoacasts API and converted the data into model objects. The code we wrote works, but it is far from finished. In this episode, we create a dedicated object that manages the communication with the Cocoacasts API.

The playground has been useful to create a prototype of the APIClient class. It's time to integrate the Episode struct and the APIClient class into the project. That is the focus of this episode.

We added quite a bit of code to the project in the past episodes and yet the user interface hasn't changed. It's time to use the data from the Cocoacasts API to populate the feed view controller's view.

Before we continue populating the user interface of the feed view controller, we need to resolve an issue we introduced in the previous episode. The feed view controller asks its view model for an Episode object every time it needs to configure an episode collection view cell. The project adopts the Model-View-ViewModel pattern, which means that the view controller should not have direct access to model objects. In this episode, I show you a simple solution to hide the Episode object from the feed view controller.

The Cocoacasts API returns a remote image for each episode. The problem we face is that the images are in the SVG format. SVG images are ideal for web, but the UIKit framework doesn't know how to handle the SVG format. The solution we implement in this episode uses Cloudinary, a service that manipulates and transforms media, including images. We also add Kingfisher to the mix. Kingfisher is a popular image library to download and cache remote images.

The collection view of the feed view controller now displays episode images. We are almost ready to build the user interface of the collection view and style the EpisodeCollectionViewCell class. Before we start with that task, I want to create a framework for styling the application. That is the focus of this episode.

Using a local server is a convenient solution during development because it makes it straightforward to set up a development environment. It also allows for flexibility, making it easy to tweak the implementation of the backend as you develop the client.

The MockClient class fetches its mock data from the application bundle. This works fine, but there are a few limitations. The most important limitation is the lack of flexibility. With the current setup, we can only test the happy path, that is, the application showing the user a list of episodes.

In the previous episode, we added the ability to define how the MockClient class responds. This added flexibility makes the MockClient class much more useful. In the next episode, I show you how we can use the MockClient class to unit test the FeedViewModel class.

In this episode, we use the MockClient class to unit test the FeedViewModel class. The unit tests for the FeedViewModel class will change as the project evolves. The primary goal of this episode is to show how the MockClient class helps us write unit tests for the FeedViewModel class.