Delivery, Analytics, and Product Operations

Introduction

Building an iOS application does not end when the code compiles or when an app runs successfully on a developer’s device. A professional product must be reproducible, securely signed, tested with representative users, submitted through Apple’s distribution systems, monitored after release, and improved using evidence. These activities form a delivery and product-operations discipline.

For iOS development, delivery connects source control, dependency management, Xcode archives, code signing, TestFlight, and App Store Connect. Product operations connects those technical processes with analytics, crash reporting, key performance indicators (KPIs), release governance, privacy, and decisions about what to build next.

A useful operating principle is:

Release reliable software, observe its real-world behaviour, learn from evidence, and improve it through controlled iteration.

This chapter presents the essential practices required to move an iOS application from a developer workstation to a managed production product.

Learning Objectives

By the end of this chapter, a learner should be able to:

1. Explain a Git-based workflow suitable for iOS projects.
2. Manage Swift packages and other dependencies responsibly.
3. Distinguish building, archiving, signing, exporting, testing, and releasing.
4. Describe certificates, provisioning profiles, entitlements, and App Store Connect roles.
5. Prepare an application for TestFlight and App Store review.
6. Select useful analytics, crash-reporting, and product metrics.
7. Interpret evidence while respecting privacy and data-governance obligations.
8. Apply a release-management process to a realistic iOS product scenario.

1. Delivery as a Software-System

Delivery is the controlled movement of a software change through environments and users. A simplified path is:

Idea → Code change → Review → Automated checks → Archive
     → TestFlight → Internal/external testing → App Review
     → Production release → Monitoring → Learning

Each stage answers a different question:

A delivery system is reliable when it is repeatable, auditable, and reversible. A developer should not depend on undocumented local settings or on a single person’s memory. Build configuration, release notes, dependency versions, test instructions, and ownership should be recorded in the repository or in an associated project-management system.

2. Git-Based Workflows for iOS Projects

Git is a distributed version-control system. It records snapshots of a project and permits developers to work in branches, review changes, and restore earlier states. A typical repository contains Swift source files, assets, configuration files, tests, and the Xcode project or workspace.

2.1 What belongs in version control?

The repository should normally include:

• Swift and Objective-C source code;
• unit, integration, and UI tests;
• asset catalogs and localised resources;
• Xcode project configuration required to build the product;
• package manifests such as Package.swift, when applicable;
• CI configuration and documented scripts;
• privacy manifests and release documentation where required.

It should not include passwords, private keys, signing certificates, API secrets, user databases, or machine-specific derived data. Files such as DerivedData, build products, and temporary user-interface state are generally excluded through .gitignore.

A common mistake is to treat a provisioning profile or certificate as an ordinary project asset. These credentials are security-sensitive. Their storage and distribution require an approved secret-management process, not an unprotected public repository.

2.2 Branching and review

A certificate-level team can use a simple workflow:

1. Start from the protected default branch.
2. Create a short-lived feature or bug-fix branch.
3. Make a focused change with clear commits.
4. Run tests and static checks locally.
5. Open a pull request.
6. Obtain review and automated checks.
7. Merge only when required checks pass.
8. Create a release branch or tag when a build is selected for distribution.

The exact branching model may vary. A small team does not need a complex hierarchy of long-lived branches. In many cases, a protected main branch plus short-lived branches is easier to maintain. The important principles are traceability, review, small changes, and a known relationship between a released binary and a commit.

Commit messages should describe intent, for example, “Handle expired session during checkout,” rather than “fix stuff.” Tags such as v2.3.0 can identify a release, although the App Store version and build number must also be managed according to Apple’s distribution requirements.

2.3 Merge conflicts and project files

Xcode project files can produce difficult textual conflicts because multiple developers may edit the same configuration structures. Teams reduce risk by avoiding unnecessary project-file changes, using Swift Package Manager where suitable, and resolving conflicts carefully rather than accepting an entire incoming version automatically. A conflicted project should be opened and built after resolution.

3. Dependency Management and Reproducible Builds

An iOS application may depend on Apple frameworks, Swift packages, or binary libraries. Dependencies provide capability but also introduce security, compatibility, licensing, and reproducibility risks.

Swift Package Manager is integrated with Xcode and can resolve package dependencies declared in a project. A dependency declaration should specify an acceptable version range or revision. The resolved versions should be recorded so that two developers do not silently build different dependency graphs.

Before adding a dependency, ask:

• Is the functionality genuinely needed?
• Is the package maintained and compatible with the target iOS versions?
• What licence governs it?
• Does it collect data or include tracking functionality?
• Does it introduce large binary size or slow build times?
• Is there a security response process if a vulnerability is found?

Updating all dependencies immediately before a release is poor practice. It combines unrelated risk with release risk. Instead, update dependencies in a controlled branch, run tests, inspect release notes, and review the resulting binary and privacy behaviour.

A reproducible build requires more than source code. It also depends on the Xcode version, SDK, package resolutions, build settings, signing configuration, generated resources, and environment variables. Teams should document supported tool versions and avoid relying on undeclared settings stored only on one workstation.

4. From Build to Archive

In Xcode, a normal build compiles source code and links an application for a selected destination. An archive creates a distributable bundle containing the application and associated metadata. An archive is not automatically a public release; it is a candidate artifact that can be validated, exported, uploaded, and tested.

A disciplined release sequence is:

1. Select the intended scheme and distribution configuration.
2. Confirm the marketing version and increment the build number.
3. Run unit, UI, and relevant manual tests.
4. Select a generic iOS device or another archive-supported destination.
5. Choose Product → Archive.
6. Inspect the archive in the Organizer.
7. Validate the archive and resolve warnings or errors.
8. Export or upload it using the intended distribution method.
9. Record the commit, archive, build number, and release notes.

The marketing version communicates a user-facing release such as 2.3. The build number identifies a particular uploaded build, such as 145. A new upload generally requires a build number that has not already been used for that app version. Teams should define who is responsible for incrementing and recording these identifiers.

An archive should be treated as an immutable release candidate. If source code changes after archiving, create a new archive rather than attempting to describe the old artifact as if it contained the new change.

5. Code Signing and Entitlements

Code signing allows Apple’s systems and operating systems to verify the identity associated with an application and whether it is authorised for a particular distribution context. Signing is often confusing because several related objects interact.

Automatic signing can simplify development by allowing Xcode to manage many settings. However, teams must still understand what is being managed. Manual signing may be appropriate where an organisation requires tightly controlled certificates, reproducible CI builds, or explicit separation of development, ad hoc, and App Store distribution.

Common signing failures include:

• a bundle identifier that does not match the registered App ID;
• an expired certificate or provisioning profile;
• a capability enabled in Xcode but not correctly configured in the developer account;
• a distribution profile used for the wrong purpose;
• missing permissions for the person or CI system performing the signing;
• a secret certificate installed only on one developer’s computer.

Signing credentials should have limited access, documented ownership, and an expiration-monitoring process. A certificate private key should never be placed in source control. Continuous-integration systems should use protected secret storage and, where possible, short-lived or narrowly scoped credentials.

6. TestFlight and App Store Connect

TestFlight is Apple’s beta-distribution mechanism. It permits internal testing by eligible App Store Connect users and external testing with invited testers, subject to Apple’s rules and review requirements for external testing.

A useful testing plan defines:

• the target tester population;
• supported device models and iOS versions;
• the build under test;
• scenarios and acceptance criteria;
• known limitations;
• a feedback channel;
• the period during which testing is valid.

Testers should receive focused instructions rather than a vague request to “try the app.” For example, they may be asked to create an account, complete a purchase simulation, disable network access, rotate the device, and report the observed result. Feedback should include the build number, device, operating-system version, steps to reproduce, and screenshots where appropriate.

App Store Connect contains several operational functions, including app metadata, pricing and availability, uploaded builds, testing, agreements, tax and banking information, analytics, and review-submission details. Access should follow least privilege. A person who needs to upload a build may not need financial or legal permissions.

Before submission, confirm:

• the app’s purpose and metadata are accurate;
• screenshots represent the current product;
• required privacy disclosures are complete;
• account deletion is provided where required;
• demo credentials or review instructions are available when necessary;
• in-app purchases and subscription information are configured correctly;
• the production backend is available and safe for review;
• the selected build is the intended one;
• known defects are documented in the release decision.

App Review is not a substitute for engineering testing. Passing review does not prove that an application is reliable for every device, network, accessibility setting, or user behaviour.

7. Release Management

Release management is the coordination of technical, product, operational, and communication activities surrounding a release. A lightweight release checklist is often more valuable than a complicated process that nobody follows.

A release plan should identify:

• scope and excluded work;
• version and build number;
• commit or tag;
• owner and approvers;
• test evidence;
• migration or backend compatibility requirements;
• analytics and crash-reporting readiness;
• privacy and accessibility checks;
• rollout strategy;
• rollback or mitigation plan;
• user-facing release notes.

iOS applications are not always instantly replaceable. Users may remain on older versions, and App Store review or phased release may affect timing. Therefore, backend changes should often be backward-compatible. A server should not remove a response field immediately if older app versions still depend on it. Compatibility windows and minimum-supported-version policies should be explicit.

A phased release can reduce exposure by making a new version available to a gradually increasing proportion of users. During the observation period, teams monitor crashes, key flows, support contacts, and business metrics. If evidence indicates serious harm, the release may be paused, the server feature may be disabled through a controlled configuration, or a corrective build may be prepared.

A rollback plan for a mobile app is different from restoring a web deployment. A developer cannot assume every installed binary can be remotely replaced immediately. Feature flags, server-side controls, safe migrations, and a rapid submission process are therefore valuable safeguards.

8. Analytics: Measuring Behaviour Without Losing Trust

Analytics is the systematic collection and interpretation of information about product use. Its purpose is not to collect everything possible. Its purpose is to answer defined questions that support product, engineering, or operational decisions.

An event should have a clear name, a documented meaning, and a controlled set of parameters. For example:

• onboarding_started
• onboarding_completed
• search_submitted
• purchase_started
• purchase_completed
• error_displayed

An event taxonomy should define when an event is emitted, whether it may occur more than once, which properties are permitted, and how the event is validated. Avoid placing email addresses, full names, message contents, precise location, or other unnecessary personal data in event parameters.

A good analytics question has a decision attached to it: “If completion falls below the agreed threshold, will the team inspect the form and run usability tests?” Without a possible action, a metric may become decorative rather than useful.

8.1 Common product metrics

Let:

• U be the number of unique users in a defined period;
• C be the number of users completing a specified action;
• S be the number of users starting that action;
• T be the number of users retained at a later time;
• N be the number of observations or sessions, where relevant.

A conversion rate is:

This formula applies when S represents the eligible population that started a defined funnel step and C represents those who completed it. The numerator and denominator must refer to the same period, population definition, and event specification.

A retention rate for a cohort is:

Here, U₀ is the number of users in the original cohort and T_t is the number of those same users active at time t. The time interval must be stated, such as day 1, day 7, or day 30. Retention is not the same as the percentage of all current users who happen to be active.

A crash-free user rate can be expressed as:

where U is the number of distinct users in the measurement period and U_c is the number of those users affected by at least one recorded crash. The definition depends on the crash-reporting system and period; it should not be compared across systems without checking their methods.

For example, if 800 users start onboarding and 520 complete it, the conversion rate is 520 ÷ 800 × 100% = 65%. If 1,000 users are in a day-7 cohort and 270 return on day 7, day-7 retention is 270 ÷ 1000 × 100% = 27%. These values describe observed behaviour; they do not by themselves establish why the behaviour occurred.

8.2 Interpreting metrics responsibly

Metrics can be misleading when definitions change, tracking fails, users are double-counted, or a result is interpreted without context. A rise in sessions may indicate improved engagement, repeated failures, or an automated process. A fall in crash reports may indicate improvement—or a broken reporting SDK.

Teams should maintain a metric dictionary containing the name, formula, event source, owner, refresh schedule, known limitations, and decision use. When a tracking definition changes, record the change and avoid treating a discontinuity as a genuine product trend.

9. Crash Reporting and Operational Health

Crash reporting captures failures that users experience in production. A report commonly includes a stack trace, app version, build number, operating-system version, device information, and diagnostic context. Symbolication translates memory addresses into useful function and line information, subject to the availability of the correct symbols.

Crash reports should be triaged by impact rather than by raw count alone. Useful questions include:

• How many unique users are affected?
• Is the crash concentrated in the newest release?
• Is a critical workflow blocked?
• Can the failure be reproduced?
• Does it occur on a particular device or OS version?
• Is the crash related to a recent change?

A high-frequency crash affecting one automated test device may be less urgent than a lower-frequency crash that prevents payment for many users. Severity, reach, trend, and recoverability should all influence priority.

Crash reporting is not the same as error logging. A handled network timeout may not crash the process but can still produce severe user harm. Applications should record structured, privacy-safe operational errors where appropriate, while avoiding passwords, tokens, payment details, or unnecessary personal content.

10. KPIs and Evidence-Based Product Decisions

A KPI is a selected indicator linked to an important objective. It is not simply any number available in a dashboard. A useful KPI has a defined population, time period, calculation, owner, target or comparison, and decision consequence.

A practical hierarchy is:

• Outcome metrics: user or business results, such as successful task completion.
• Driver metrics: behaviours expected to influence outcomes, such as onboarding completion.
• Guardrail metrics: measures that prevent harmful optimisation, such as crash-free users, support contacts, or uninstall rate.
• Diagnostic metrics: detailed indicators used to explain a change.

Suppose a team wants to increase subscription purchases. It might track purchase conversion as an outcome, trial-start rate as a driver, and crash-free users plus refund requests as guardrails. Increasing purchases by making cancellation confusing would be an unacceptable product decision even if the headline conversion number rose.

Evidence-based decision-making combines quantitative and qualitative evidence. Analytics may show that users abandon a form, while interviews or session observations may reveal that the validation message is unclear. Crash data may show a technical failure, while support tickets reveal its practical consequences.

Correlation does not establish causation. If conversion rises after a redesign, other events—seasonality, advertising, pricing, or a backend change—may also explain the result. Controlled experiments can provide stronger evidence, but they require clear hypotheses, stable instrumentation, appropriate eligibility rules, and protection against negative effects.

11. Privacy, Ethics, and Governance

Analytics and crash reporting involve responsibility toward users. Developers should follow data-minimisation principles: collect only what is necessary, retain it for an appropriate period, protect it, and explain its use clearly.

Important controls include:

• transparent privacy notices;
• consent mechanisms where legally or technically required;
• appropriate handling of Apple privacy declarations and tracking-related requirements;
• access control for dashboards and raw reports;
• encryption in transit and at rest where appropriate;
• retention and deletion policies;
• separation of production data from test data;
• review of third-party SDK behaviour;
• procedures for responding to data incidents.

A device identifier, precise location, account identifier, or diagnostic payload may become personal data depending on context and jurisdiction. Developers should not assume that a field is harmless merely because it is not a person’s name.

Accessibility and fairness are also operational concerns. A release that works well for recent devices but fails for users with older hardware, assistive technologies, or limited connectivity may produce misleadingly positive aggregate metrics. Segment analysis should be used carefully to identify unequal outcomes, while avoiding unjustified conclusions from very small groups.

12. Applied Case: The Illustrative “CampusReserve” Release

Background

CampusReserve is a fictional iOS application that allows students to reserve study rooms. Version 2.0 introduces a redesigned onboarding flow, push notifications, and a new reservation-confirmation service.

Problem

The team has a two-week release target. Previous releases have suffered from undocumented dependency updates, a signing failure during submission, and insufficient monitoring after launch. The product manager wants evidence that the redesign improves completed reservations without increasing failures.

Analysis

The team identifies the following risks:

1. The notification capability changes entitlements and signing requirements.
2. The new service must remain compatible with version 1.x clients.
3. The onboarding redesign may improve completion but could introduce accessibility problems.
4. A third-party analytics package has changed its data-collection behaviour.
5. The team has no agreed definition of “successful reservation.”

Approach and solution

The developers create a short-lived release branch from the protected default branch. The dependency update is placed in a separate reviewed change and its resolved versions are recorded. A metric dictionary defines onboarding_started, onboarding_completed, reservation_started, reservation_confirmed, and reservation_failed.

The team defines successful reservation as a confirmed reservation received by the client and recorded by the server. It excludes merely tapping the confirmation button. The release candidate is archived from a tagged commit, and the build number is recorded in the release checklist.

TestFlight testing covers current and older supported iPhones, poor network conditions, interrupted sign-in, VoiceOver navigation, notification permission denial, and repeated reservation attempts. External testers receive task-based instructions and are asked to include the build number in reports.

The backend accepts requests from both 1.x and 2.0 clients. A server-side control can disable the new confirmation path without removing the older path. Crash reporting is verified with a controlled test build before release, and production dashboards display crash-free users, reservation-confirmation conversion, and reservation-failure rate.

Outcome

During the phased release, onboarding completion rises from 60% to 68%, while reservation confirmation remains stable. However, crash-free users fall on one older operating-system version because of an unexpected notification-related defect. The team pauses expansion, disables the new notification path, and prepares a corrective build. The headline onboarding improvement is retained as a promising result, but the release is not declared successful until the guardrail issue is resolved.

Learning points

• A release objective must include guardrails, not only growth metrics.
• Compatibility planning matters when users retain older app versions.
• TestFlight scenarios should represent real operating conditions.
• A metric definition must specify the event and business meaning.
• Feature controls can reduce the impact of a mobile defect.
• Evidence should lead to a decision, not merely populate a dashboard.

13. Contemporary Practices and Best Practices

Modern iOS teams increasingly use continuous integration to build and test every pull request, with controlled workflows for signing and distribution. Automation may validate formatting, run unit tests, build an archive, check dependencies, and upload a selected artifact to TestFlight. Automation does not eliminate judgement: release scope, privacy impact, accessibility, and user harm still require human review.

AI-assisted coding can help draft tests, explain compiler errors, or generate release-note candidates. It can also introduce insecure code, incorrect API assumptions, licence concerns, or accidental exposure of confidential source. AI output must therefore be reviewed, tested, and governed like any other contribution.

Recommended practices include:

1. Keep the default branch buildable and protected.
2. Link every release to a commit, archive, version, and build number.
3. Separate secrets from source code and restrict access.
4. Treat dependency updates as reviewed changes.
5. Test realistic devices, networks, permissions, and accessibility settings.
6. Define analytics before implementing events.
7. Monitor both crashes and handled operational failures.
8. Use outcome, driver, and guardrail metrics together.
9. Maintain a documented rollback or mitigation plan.
10. Make privacy, security, and data retention part of release readiness.
11. Use phased release when the risk or user impact justifies it.
12. Conduct a short post-release review that records evidence and actions.

Challenges and Limitations

No delivery system removes all uncertainty. Automated tests may miss unusual user behaviour. TestFlight testers may not represent the full production population. Crash reports can be incomplete or biased toward users who permit diagnostics. Analytics can be affected by network failure, clock differences, duplicated events, privacy choices, and SDK changes.

Metrics can also create harmful incentives. Optimising a funnel may encourage dark patterns; optimising session length may reward unnecessary complexity. Teams should ask whether a metric reflects genuine user value and whether the measurement process itself changes behaviour.

Finally, operational maturity depends on organisational habits. A perfect checklist is ineffective if ownership is unclear or deadlines repeatedly override evidence. The appropriate goal is not bureaucracy but dependable learning: small, visible, reversible changes supported by trustworthy information.

Chapter Summary

Professional iOS delivery extends from Git and dependency management to archives, signing, TestFlight, App Store Connect, and production monitoring. Git provides traceability and review; dependency controls support reproducible and secure builds; archives create release candidates; signing connects an application to an authorised distribution identity; and TestFlight provides structured beta testing.

Release management requires version and build discipline, compatibility planning, phased exposure, mitigation controls, and clear ownership. Analytics should answer defined questions through documented events rather than collect data indiscriminately. Conversion, retention, and crash-free-user rates are useful only when their populations, periods, units, and definitions are explicit. Crash reporting and operational logs reveal real-world failures, but they must be interpreted by impact and protected as potentially sensitive data.

Evidence-based product operations combine outcome, driver, guardrail, and diagnostic metrics with qualitative research. Privacy, accessibility, security, and fairness are part of product quality. The central professional practice is a continuous loop: make a controlled change, release it safely, observe its effects, and use trustworthy evidence to decide what happens next.

Key Terms

Git: A distributed version-control system for recording and collaborating on source-code changes.

Branch: An independent line of development in a Git repository.

Pull request: A proposed change submitted for review before integration.

Dependency: External code or package required by an application.

Reproducible build: A build process whose declared inputs produce a consistent, identifiable artifact.

Archive: A distributable Xcode build artifact prepared for validation or upload.

Code signing: The process of associating an application with an authorised signing identity.

Certificate: A credential representing a development or distribution signing identity.

Provisioning profile: A signed configuration connecting an app identity, entitlements, certificates, and distribution purpose.

Entitlement: A capability declaration, such as push notifications or keychain access.

TestFlight: Apple’s service for distributing beta builds to testers.

App Store Connect: Apple’s portal for app distribution, metadata, testing, analytics, and operational administration.

Phased release: A controlled approach that makes a release available progressively.

Analytics event: A recorded product occurrence with a defined name and meaning.

Cohort: A group of users sharing a defined starting condition or time period.

Retention rate: The proportion of an original cohort active at a later specified time.

Crash-free user rate: The proportion of measured users who experience no recorded crash in a defined period.

KPI: A selected indicator connected to an important objective and decision.

Guardrail metric: A measure used to prevent improvement in one area from causing unacceptable harm elsewhere.

Data minimisation: Collecting and retaining only the data necessary for a legitimate purpose.

Review Questions

Short Answer Questions

1. Why should a release be linked to a specific commit and build number?
2. Distinguish an archive from a production release.
3. What is the purpose of a provisioning profile?
4. Why must analytics events have documented definitions?
5. Name two examples of guardrail metrics.

Long Answer Questions

1. Explain a suitable Git-based workflow for a small iOS development team, including review and release tagging.
2. Describe the relationship between certificates, App IDs, entitlements, provisioning profiles, and App Store Connect.
3. Explain how an iOS team should prepare, conduct, and evaluate TestFlight testing.
4. Discuss how dependency management affects security, licensing, compatibility, and reproducible builds.
5. Explain why privacy and data minimisation are essential in analytics and crash reporting.

Analytical / Application Questions

1. An onboarding funnel has 1,200 starters and 780 completers. Calculate the conversion rate and identify one additional piece of evidence needed before deciding that the redesign is successful.
2. A new release increases purchase conversion but also increases crash-affected users on older devices. Propose a release decision using outcome, driver, and guardrail metrics.
3. Design a release checklist for an iOS application that uses push notifications, a third-party analytics SDK, and a backend shared with an older app version.

Multiple Choice Questions with Answers

Question 1

Which artifact most directly represents a distributable iOS release candidate created in Xcode?

A. A Git branch

B. An archive

C. A pull request

D. A provisioning profile

Correct Answer: B. An archive

Question 2

What is the primary purpose of a provisioning profile?

A. To store user analytics events

B. To define App Store screenshots

C. To connect app identity, entitlements, signing credentials, and distribution purpose

D. To replace all unit tests

Correct Answer: C. To connect app identity, entitlements, signing credentials, and distribution purpose

Question 3

Which practice best supports reproducible builds?

A. Updating every dependency immediately before release

B. Recording dependency resolutions and supported tool versions

C. Keeping build settings only on one developer’s computer

D. Committing private signing keys to the repository

Correct Answer: B. Recording dependency resolutions and supported tool versions

Question 4

A funnel has 800 starters and 520 completers. What is its conversion rate?

A. 35%

B. 52%

C. 65%

D. 80%

Correct Answer: C. 65%

Question 5

Which is the best example of a guardrail metric for a purchase-conversion experiment?

A. Number of code comments

B. Crash-free user rate

C. Number of Git branches

D. Archive file size only

Correct Answer: B. Crash-free user rate

Question 6

Why should analytics event parameters avoid unnecessary personal information?

A. It makes Swift compilation slower

B. It prevents all crashes automatically

C. It supports privacy, minimisation, and reduced data risk

D. It guarantees App Review approval

Correct Answer: C. It supports privacy, minimisation, and reduced data risk

Question 7

What is a major advantage of a phased release?

A. It removes the need for testing

B. It exposes the new version progressively so evidence can be monitored

C. It allows private keys to be shared publicly

D. It guarantees that no user sees a defect

Correct Answer: B. It exposes the new version progressively so evidence can be monitored

Question 8

Which information is especially important when reproducing a TestFlight defect?

A. The tester’s preferred programming language only

B. The build number, device, operating-system version, and steps

C. The number of files in the repository only

D. The App Store description length only

Correct Answer: B. The build number, device, operating-system version, and steps

Question 9

Why should backend changes often remain compatible with older app versions?

A. Users may continue using previously installed binaries

B. Older binaries automatically update server code

C. Compatibility eliminates the need for code signing

D. App Store Connect rejects all new APIs

Correct Answer: A. Users may continue using previously installed binaries

Question 10

Which statement best describes evidence-based product operations?

A. Choosing features solely by intuition

B. Collecting every possible event without defined use

C. Combining trustworthy measurements and qualitative evidence with explicit decisions

D. Optimising one metric regardless of user harm

Correct Answer: C. Combining trustworthy measurements and qualitative evidence with explicit decisions