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.