Guide to iOS Development Processes

Introduction

Building a high-quality iOS app requires a high-quality development process. Think of the process as a system of checks and balances applied to your iOS apps. Having great developers isn't enough; you need controls to help you steer. As a leader, you're responsible for the direction of the project.

You'll find many symptoms of a flawed development process:

• Obvious bugs or crashes in every release
• Features or fixes rarely ship when the developer estimates
• Frequent delayed releases
• Reliance on a single developer to understand and alter certain parts of the app
• Bugs discovered right before or right after a release
• Your team isn't sure if a release improved the business
• Your users don't use or complain about new features

If you experience any of these pains, it's time to work on your process. A reasonable upfront investment can create permanent productivity gains. Automation, tooling, and attention to the development process are the hallmarks of effective development teams.

Meetings are a common alternative to a modern software development process. Meetings might create an illusion of control but have minimal lasting results without a change in the process and a practical control system guiding it. You capture results in software development electronically, not verbally. For that reason, there are limits to what a meeting can achieve. A leader needs visibility and input into the process that builds your iOS app. Implementing a high-quality development process achieves that.

For a moderate-sized team (i.e., not Facebook or Amazon), the software development process's basic building blocks look the same. They make up a series of feedback loops that monitor each aspect of your work product: the code, the functionality, the product-user fit, and the business metrics. The software development process also produces metrics about itself, like the regularity of releases, or the number of defects found in the App Store. These, along with your team's feedback, will help guide improvements to how you work and what tools you use.

Keep in mind that these blocks define a minimal iOS development process. You can add sophistication where needed. For instance, you can easily add a designer, human-factors expert, customer success agent, or operations to the process to enhance user experience. Also, if you have a team of ten or more developers contributing to a single app, you may need more tools to assist collaboration.

What about Agile?

Agile methodologies like Scrum or Kanban are collaboration practices for software projects. So are non-agile methods, like "waterfall." Agile isn't a replacement for a software development process; they're complementary tools.

Agile helps your team decide what to work on (and when to perform that work) to deliver the highest business value. Your software development process enables you to implement that work and do it faster, more predictably, and with a higher quality level. You could say that agile helps you determine what work your iOS app needs, and your software development process helps that work get to the App Store.

In short, you need both a methodology to guide what you build, and a process to help you make it effectively.

Prioritize Rapid Feedback

Your developers need rapid feedback if they're going to build a better app. The sooner an engineer (or designer, or other team members) notices a bug or a bad user experience, the more predictable your results will become. Apps get into trouble when developers work in isolation for weeks or months before discovering flaws. Generating and using that feedback is one of the primary jobs of a software development process.

The issue of feedback doesn't just apply to developers. Your entire team should work within your development process. The list includes:

• Product managers -Supervisors -Designers
• Quality Assurance
• Operations

Apps run into issues when non-developers assume their engineers are "fire-and-forget." Some engineers have the design, business, systems, quality, and operations skills to work entirely independently, but this kind of "master" developer is rare and expensive. These developers are usually founders.

Even if your engineer team does have that kind of broad engineering talent, you probably still need the non-engineers involved with your development process. Every app has someone outside the engineering team who wants to offer feedback (or place their stamp) before release. This delayed feedback is where organizations get into trouble: when the app needs unexpected rework after the development team has invested days or months into a feature.

Don't think of your development process as a tunnel your engineers disappear into every Monday afternoon and reappear next Monday morning for planning. Instead, your engineers should collaborate with the designers, quality assurance (QA), and other team members as features evolve.

Project Management

The software development process starts with your software project management tool. Whether it is Jira, FogBugz, or Trello, you need a place to store your feature and bug list. This tool also tracks your team's progress.

No matter how tiny your team, or how early your project, you need a system to track your work. Your software project management software is a productivity tool, so you should find one that makes your team more productive. All team members must feel comfortable using it. Product managers, project managers, supervisors, engineers, QA engineers, and designers need to update their tasks, keep track of their work, and keep track of their progress.

If your team needs daily meetings to track progress, either your project management tool isn't working, or more training is required. Likewise, the project management tool probably isn't a good fit for your team if much work is missing from it. You'll struggle to manage your app if a team member views your project management tool as homework instead of a productivity booster.

If you're struggling with your project management software, try something new. Too many teams keep project software for familiarity rather than try some other tools which might better fit their workflow. Better tools can create significant productivity gains.

Planning

Regardless of your app's state and your software development methodology, you will need periodic planning sessions to pick what work comes next in priority. For this to work, you need all stakeholders (or their representatives) to participate. The stakeholder list typically includes designers, QA, engineers, and product managers.

Since planning involves every stakeholder, it's expensive. As much as possible, stakeholders should have already entered features and bugs to consider the project management software before this meeting. Your meeting is inefficient if your team spends more than a few seconds watching someone type.

A planning meeting's product is a list of the next features and bugs to execute. This list will include user interfaces to design, bugs to fix, changes to implement. Naturally, you capture this in the project management tool.

The Next Task

How each team member picks a task might seem trivial on the surface. This phase is where your ideal process and reality meet. Will the person choose a scheduled task or invent their own? Will they indicate what they're doing in the project management tool? Will they have all the information they need to begin that task?

The answers to those questions indicate the level of control your team has over your development process. In an ideal world, you want:

• your planning to determine what tasks get worked on
• your project management tool to track the state of all work
• your entire team and stakeholders to quickly understand the state of the project from your project management tool

In reality, there are tradeoffs to be made. Where do you want to live on the spectrum from chaos to micro-management? How much time and mental energy will you budget to tracking project status? What is the ideal set of project management tools?

You'll need to work with your team to find your sweet spot in these tradeoffs.

Implementation

After picking a task, the implementation work begins. Fix the bug, write the code, make the tests, or craft the assets.

This phase of the development process is often iterative. As you do the work, you also periodically measure it against your criteria and adjust. You might run unit tests, integration tests, or UI tests. In the case of user-facing functionality, it might also include Hallway Usability Testing or a designer feedback session.

Hallway Usability Testing

Hallway Usability Testing refers to showing your work to the first colleague you find in your office hallway. The goal is simple: you need to see if the UI is intuitive to someone unfamiliar with the design.

Hallway usability testing lets you quickly get feedback and adjust your implementation as early in the development process as possible. Even if you have more formal user feedback sessions later in your development process, hallway user testing still offers significant value in the feedback's immediacy. Implement the design and let a colleague try it. Improve your UI, get more feedback. You can repeat this process several times in one day.

Hallway usability testing is the bare minimum usability testing I expect for any new user interface. If you don't check to make sure at least one other person can use your UI, your app will suffer.

Pull Requests

Pull requests (PRs) are where you evaluate new code or assets before inclusion in your main branch (i.e., in git). A developer or designer creates a pull request when they believe work is complete on a task. A PR should be the only allowed method for merging new code into the main branch.

The PRs creation should trigger a build and automated tests, including unit tests, integration tests, UI tests, and linting tools. You should configure your source code management system (e.g., GitHub) so that all tests must pass before the new code can merge into the main branch. I also recommend preventing a merge if the build produces any warnings.

Peer code review is also an essential part of any PR. At least one new set of eyes should inspect and approve every change before merging into the main branch. Entire books exist on the peer code review subject, so this is a superficial summary of the benefits:

• discovering undetected bugs
• identifying new corner cases for testing
• improving the team's awareness of the codebase
• improving code documentation
• reducing code complexity
• disseminating new coding techniques to the team

Merging to the Main Branch

Once a PR is approved and passes all tests, it merges into the main git branch. On most teams, this should kick off an internal build and distribution. Internal distribution (e.g., TestFlight) allows non-developers to try the app as it develops, and quality assurance to evaluate new features or fixes in advance of the next release. Depending on how your quality assurance works, they may merge each of these internal releases from the main branch to a release branch after passing verification.

Periodic Releases

Most mature businesses prefer releases on a fixed schedule rather than asynchronously. For that reason, your process should aim to maintain the main branch or an offshoot release branch in a releasable state at all times. While the exact feature set for a future release can't be known, this ensures the release's quality and a fixed date.

It is equally valid to release with a particular feature set but unknown date. However, this can lead to coordination challenges with other teams (e.g., a web team), and can encourage a development team to work on an overly ambitious release rather than break it into a series of less-risky features which release every two or three weeks.

The periodic release typically means deploying to an internal or external TestFlight group for final sign-off.

Deploy to TestFlight

A candidate release is deployed to an internal or external TestFlight as a final opportunity to ensure a high level of quality. This TestFlight binary will be the exact binary also submitted to the App Store for approval and release.

Since your TestFlight is your last opportunity before App Store submission, this is an excellent point to let all stakeholders sign off:

• Product Managers
• Designers
• Beta testers
• API teams
• Quality Assurance

Submission to the App Store

Once QA and any other stakeholders sign off on the TestFlight, you submit the app to the App Store review. Unless Apple rejects your release, it is deployed to the app store either immediately or through a rolling release.

In the case of an App Store rejection or another significant issue, you might make a patch to the current release using an expedited version of the same software development process.

Monitoring

Closing the loop, each discipline on an iOS development team monitors the currently released app versions:

• Operations monitors availability and resource usage by APIs
• Product Management and Data Science monitors analytics for business impact
• Customer Success identifies any changes in support load created by each release
• Engineering or QA monitors crash reports and error logs
• This monitoring feeds back into the software project management tool, which informs planning for upcoming work.

Conclusions

We've traced the full path of an improvement to your iOS app, and the many feedback loops influencing its development. At every step along the way, checks and balances help improve efficiency and quality.

Without these controls, a tiny mistake or misunderstanding can escape detection until it becomes a more massive, costly problem.

Learn More