Heads up... You're reading this book for free, with parts of this chapter shown beyond this point astext.
You can unlock the rest of this book, and our entire catalogue of books and videos, with a raywenderlich.com Professional subscription.
By this point, you’ve come quite a distance on your app distribution journey. You know how to deploy your app on TestFlight and the App Store, and you’re well-versed in the process of automation. Distributing Emitron has been straightforward, without too many problems along the way — but that’s not always the case with app distribution.
In the diverse world of iOS app distribution, you’ll find companies of varying sizes and differing needs. Some companies build similar apps for many clients with client-specific branding. Others have a strong need for security and testing, such as large banks. Here, you’ll typically find a slow and strict release cycle. Small startups, on the other hand, are more comfortable with playing fast and loose with their releases.
In this final chapter, you’ll reference everything you’ve learned so far. You’ll test your new skills by exploring the needs of different organizations. Each section in this chapter is dedicated to problems that different companies face in the real world. So, get ready, it’s time to put what you’ve learned into practice!
How do you order a pizza from your favorite pizza place? You’ll find many popular pizza restaurants in every neighborhood, and they all share common needs. Every restaurant needs to manage stock, process payments and receive orders.
As an app developer, there’s an opportunity lying in those overlapping requirements. Since all pizza restaurants have the same needs, wouldn’t it be easy to build the same app for each restaurant? You’d only need to change the branding: the app’s icon, name and possibly some aspects of the design.
A white-label app is a generic app that you recompile and rebrand to fit the client’s needs. You could create apps for all the pizza places in your city by making a single, generic pizza restaurant app and then white labeling it for each specific client.
Using what you learned in Chapter 9, “Build Customizations”, white labeling is a breeze.
White labeling with build configurations
In Chapter 9, “Build Customizations”, you set up different build configurations for Emitron to create dev, beta and release builds. You use a similar trick for white labeling.
When you’re part of a small, scrappy startup, time to market is critically important. If you’ve completed work that brings value to your users, it’s best to get it into their hands as soon as you can. That means getting new features through the software development lifecycle as quickly as possible, from idea to implementation, testing and, finally, release.
While continuous integration helps you merge the team’s work and provide feedback on the build through automated tests, continuous delivery supports build distribution to testers.
Smooth app reviews
Continuous delivery provides a stable, predictable build pipeline. Sometimes, however, building your app is only half the battle.
A helpful addition to your CI/CD pipeline is a job that shares the build’s state. You can accomplish this in a few ways:
While some companies value quick releases, others have a stronger need for extensive testing. Companies dealing with sensitive information, such as banks and other financial institutions, go through rigorous testing cycles. Releases are larger and can take months to reach the App Store.
Implementing different environments
To swap out the environment, you’ll make use of build configurations, similar to the approach you use for white labeling.
While TestFlight is a remarkably convenient option for testing alpha builds, it isn’t the only choice available. Other platforms, such as AppCenter and Bitrise, also host builds for internal distribution. AppCenter facilitates analytics and crash reporting as well, making it a convenient solution for managing your app.
One app, many teams
Besides rigorous testing, large companies face another problem that can be solved with your newfound understanding of app distribution: the coordination of large teams. There’s a limit to how many iOS developers you can put in a room to work on the same app. With too many developers on one team, the team becomes increasingly prone to communication and coordination problems.
Building with frameworks
Leveraging frameworks is a great strategy to share code with others. In this context, each team builds its own framework to integrate into the main app. The codebase for the main app is, for the most part, an empty shell that integrates each framework.
Besides sharing between teams on the same iOS app, you can use frameworks to share code between platforms — for example, between the iOS, iPadOS, macOS, tvOS and watchOS team. To take things further, you can also create a framework to share code between an iOS and Android app.
Automating with fastlane
Distributing an app takes a great deal of work, but it doesn’t need to be that way every time. In Chapter 13, “Introduction to Fastlane”, you learned how to use fastlane to automate your build. Actually, fastlane can do a whole lot more than just building your app.
For many developers, one of the hardest aspects of app development has nothing to do with writing code.
- Different companies face different challenges. You can use the knowledge gained in this book to help solve them.
- White labeling lets you reuse the same code base for multiple clients.
- When time to market is a key factor, invest time in automating daily builds.
- For rigorous testing, consider setting up multiple environments.
- TestFlight is a convenient hosting solution for test builds, but some companies host their in-house builds for added security.
- Teams can share code using frameworks.
- Fastlane has a lot to offer in the world of automation, even from the first day of coding out a new idea.
- Your journey doesn’t end once your app is released. Managing your app is as important as writing the code.