Apple: App Store to iPhone, and how Apple ships

The developer builds in Xcode and signs the binary with an Apple-issued certificate and provisioning profile. They upload it to App Store Connect with metadata, privacy labels and a privacy manifest. TestFlight distributes it to internal testers, and to external testers after a beta review. The release then goes through App Review against the published guidelines. Once approved, it is published to the catalog and the binaries are pushed to a CDN. When a user taps Get, the App Store app authenticates them, downloads a thinned build for that exact device, and iOS verifies the signature before installing. Later updates follow the same path and can roll out in phases. I would highlight that trust is enforced at each layer: signing, review, and on-device verification.

Signing ties three things to the binary. The certificate proves identity: the developer's private key signs the code, and Apple's CA vouches for the public key. The provisioning profile, which Apple itself signs, binds an App ID, the allowed certificates and, for development or ad hoc builds, specific device IDs. Entitlements declare capabilities such as iCloud, push notifications or App Groups. They must match what the profile permits, or the OS refuses them. At install and launch, iOS checks the signature chain, the code hashes and the entitlements. For App Store builds, Apple re-signs the binary after review, so devices trust Apple's distribution signature. In interviews I add that private keys should live in a keychain or a managed signing service, never in a repository.

I key everything on originalTransactionId, which stays stable across renewals, upgrades within a subscription group, and restores. A transactions table stores each verified JWS transaction, keyed by transactionId, with its product, purchase and expiry dates, environment, revocation date and the appAccountToken. An entitlements table maps user to originalTransactionId and holds the derived state: active, in grace period, in billing retry, expired or revoked, plus the expiry time. The appAccountToken, a UUID the app sets at purchase, links the purchase to our account ID. Entitlement state is only ever derived from verified Apple data, whether that comes from the client upload, server notifications or the App Store Server API. It is never derived from a client saying 'I paid'. Updates are idempotent and ordered by signedDate.

First, verify every signedPayload's JWS chain back to Apple's root, and reject anything that fails. Next, deduplicate on notificationUUID and acknowledge quickly with HTTP 200, before doing heavy processing asynchronously through a queue. Apple retries failed deliveries for a limited period. For ordering, I don't apply notifications as blind state transitions. Instead, I treat each one as a trigger to refresh state, or I compare signedDate and the transaction's dates against what is stored and keep the newest. For gaps, a periodic job calls the Get Notification History endpoint to backfill missed events. For important users, I call Get All Subscription Statuses to reconcile. Alerts fire on verification failures and backlog growth. Entitlements fail safe: a missing notification must never grant access that Apple's data doesn't support.

I would never trust the client's word that a purchase happened. With StoreKit 2, each transaction comes as a signed JWS, so the app sends it to my backend, which verifies the signature and certificate chain, checks bundle ID and environment, and records the original transaction ID as the stable key for the subscription. Entitlements live on my server. I would subscribe to App Store Server Notifications version 2 to handle renewals, billing retries, grace periods, refunds and revocations, and use the App Store Server API to reconcile state if a notification is missed. Processing must be idempotent because notifications can be retried. Finally, I would test with sandbox and StoreKit testing in Xcode before release.

Publicly, Apple runs a predictable annual train: announce at WWDC in June, ship developer betas and a public beta through the summer, then release in the autumn alongside new hardware. The lesson is that a fixed date forces scope decisions; features that are not ready move to a later release rather than delaying everyone. Apple has also publicly described a functional organisation where experts own their area across products, which helps hardware and software decisions stay consistent. Privacy is treated as a design requirement, reviewed early rather than patched later. For my own team, I would borrow the fixed cadence, early external betas for partners, clear single owners for each area, and privacy reviews at design time, not at launch.

The privacy manifest is a PrivacyInfo.xcprivacy file inside the app and inside each bundled SDK. It declares the data types collected, whether that data is used for tracking, any tracking domains, and the reasons for using certain APIs. Apple maintains a list of required-reason APIs, such as file timestamps, system boot time, disk space and UserDefaults. These APIs can be misused for fingerprinting, so each use must cite an approved reason code. Since 2024, App Store Connect flags uploads that use these APIs without declared reasons. Commonly used third-party SDKs must also ship their own manifests and signatures. Xcode can aggregate all the manifests into a privacy report, which helps developers fill in the App Store privacy nutrition labels accurately.

I treat the labels as a build artefact, not marketing copy. First, I keep an inventory of every SDK, its version and its privacy manifest. Then I generate Xcode's privacy report on each release build and compare it with the declared labels, failing CI when something new appears. Any new SDK or new data field goes through a lightweight privacy review covering what is collected, why, whether it is linked to the user, and whether it counts as tracking under App Tracking Transparency. SDKs go through a server-side proxy where possible, so outbound traffic can be audited. A person on the product or legal side owns the labels, and they are reviewed whenever a version adds or removes data collection. Inaccurate labels risk rejection and erode user trust.

I would run it in rings. Internal testers are App Store Connect team members, up to 100 people, and they get every build within minutes of processing, with no review. That ring catches obvious breakage. External testers can number up to 10,000, invited by email or a public link. The first build of a version needs Beta App Review, so I submit early and push later builds once that review passes. I split external testers into groups, for example staff and friends first, then power users, then a broad public link, and I gate features with remote flags. Crash logs, screenshot feedback and the tester-count metrics feed triage. Builds expire after 90 days, so long-running betas need regular refreshes.

First, I read the rejection carefully. It cites specific guideline numbers, and often the reviewer's notes or screenshots show exactly what failed. If it is a misunderstanding, such as a missing demo account or a feature the reviewer could not reach, I reply through the Resolution Centre with clear steps and credentials. If it is a real issue, I fix the smallest possible scope, resubmit, and consider requesting an expedited review, which Apple grants at its discretion. If we genuinely disagree, we can appeal to the App Review Board, but that takes time. In parallel, I tell marketing about the risk. Next time, I would submit well ahead of the date and use scheduled release, so approval and launch are decoupled.

On each pull request, Xcode Cloud or another macOS CI runner builds the app, runs unit and UI tests on several simulators, lints, and checks the privacy manifest. On merge to main, it archives a release build with an auto-incremented build number. It signs using cloud-managed certificates or keys held in a secure store, uploads to App Store Connect, and distributes to internal TestFlight testers. A release branch then promotes a chosen build to external groups. After sign-off, the pipeline submits that same build for review through the App Store Connect API, together with versioned metadata and screenshots. I keep signing secrets out of the repository, keep builds reproducible with pinned Xcode versions, and upload dSYMs for crash symbolication. Release uses phased rollout, with dashboards watching crash-free sessions.

Use a multi-tier CDN. Edge caches sit close to users, regional mid-tier caches shield the origin, and the origin is object storage holding immutable, content-addressed artefacts. Before the release goes live, I pre-position the new variants at the edges, so the first million requests do not all miss the cache. Request coalescing ensures that concurrent misses for the same object produce a single origin fetch. Clients download in ranged chunks and can resume, with integrity checked per chunk and the signature verified at install. Rollout pacing helps too, through phased release and the OS scheduling automatic updates opportunistically, often overnight on Wi-Fi and power. Monitoring covers edge hit ratio, origin egress and error rates per region, with spare capacity or traffic shifting between providers for a regional incident.

Apple sends a REFUND notification, and the transaction gains a revocationDate and revocationReason. On device, StoreKit 2's Transaction.updates delivers the revoked transaction, and currentEntitlements stops including it. On the server, I mark the transaction revoked and recompute the entitlement. For a subscription, access ends. For a consumable such as in-game currency, I deduct the balance, possibly into negative, according to the published policy. Apple may also send a CONSUMPTION_REQUEST notification asking for consumption data before deciding a refund. That data should be sent only with the user's consent, as Apple's guidelines require. I log refunds per user to spot abuse patterns, but I never punish without evidence. All of this is idempotent, so a replayed notification doesn't double-deduct.

First, I pause the phased release in App Store Connect, which stops new automatic updates to the new version. I also remember its limits. Users can still update manually, new installs get the latest version, and you cannot roll a user back to an older binary. Next, I disable the offending feature with a remote flag if it is flag-gated, which is why risky code should ship behind flags. I triage with Xcode Organizer crash reports, MetricKit and our crash SDK, using dSYMs to find the failure. Then I ship a fix as a new build and request expedited review, explaining the user impact. Once it is approved, I release it, possibly at full speed. Afterwards, we hold a blameless postmortem covering why beta rings missed it.

Users update at their own pace, and some disable automatic updates, so the backend must serve many versions at once. I version APIs and make changes additive: new fields are optional and old fields are deprecated slowly. I also test old clients against new servers in CI. Every request carries the app version and build, so you can measure the population per version and decide when a version can be retired. Remote configuration lets the server switch features per version. Forcing an update is a last resort, for security fixes, breaking payment or legal changes, or a version that corrupts data. It is implemented as a server-driven blocking screen linking to the App Store, plus a softer nag for merely outdated versions. Note that a forced update cannot exceed device OS support.

I would store user data in the private database in a custom record zone, so I get atomic batch saves and change tracking. Each device fetches changes incrementally using a server change token persisted locally, and CloudKit subscriptions send silent pushes when something changes. Writes go first to a local store, which keeps the app offline-first, and an outbox pushes them to CloudKit. Conflicts surface as a serverRecordChanged error, which carries both the server record and the client record. I then merge, either field by field, by last-writer-wins on a modification timestamp, or with domain rules such as unioning set items. I treat deletions as tombstones. NSPersistentCloudKitContainer or SwiftData can handle much of this for Core Data-style models, with less control.

Advanced Data Protection extends iCloud end-to-end encryption to many more categories, including iCloud Backup, Photos and Notes, so Apple no longer holds the keys for that data. The benefit is that a breach of Apple's servers, or a legal demand, exposes much less. The cost falls on recovery. Apple cannot help, so the user must set up a recovery contact or recovery key, and losing both means losing the data. Some web access and server-side features are limited by default. For developers, CloudKit fields set through encryptedValues are end-to-end encrypted, so the server cannot index or query them. Your data model must keep queryable fields non-sensitive and push sensitive processing onto the device.

I see three risks. A compromised developer machine or CI could inject code before signing. Signing keys could be stolen. A dependency could be poisoned. Apple's controls cover distribution: App Store builds pass automated scanning and review, Apple re-signs them, and iOS verifies signatures at install and launch, so in-transit or on-device tampering fails. Code that the developer legitimately signed but that was poisoned upstream is the developer's responsibility. Mitigations include pinned and checksummed dependencies through Swift Package Manager lockfiles, keys kept in managed cloud signing or a hardware-backed keychain, least-privilege API keys for App Store Connect, protected release branches with review, and reproducible builds from clean CI images. If a certificate leaks, revoke it immediately and rotate. App Store builds remain safe because of Apple's re-signing.

Since iOS 14.5, apps must ask permission through ATTrackingManager before tracking users across other companies' apps and websites, which includes accessing the IDFA. If the user declines, the IDFA is zeroed, and you must not track by other means such as fingerprinting, which App Review and the privacy manifest rules target. Practically, I design so the app works fully without consent. I show the prompt in context, not at first launch, with an honest purpose string. I use SKAdNetwork or AdAttributionKit for privacy-preserving install attribution. Consent state is recorded and respected by every SDK. The privacy labels and the manifest's tracking domains must reflect this, or Apple can block network requests to undeclared tracking domains.

I would plan the year around it. In June, after WWDC, engineers watch the relevant sessions and install the developer betas on test devices. They run the current App Store build on the new OS early, because behaviour changes show up there first, and they file Feedback Assistant reports with minimal reproductions. Through summer, we build adoption work for new APIs behind availability checks while continuing to ship on the current SDK. When the release candidate and final Xcode arrive, we ship a version built with the new SDK, ideally on release day. We also track Apple's announced minimum-SDK deadlines for submissions, and drop support for old OS versions based on our usage analytics, not on guesswork.

I would make it a required gate early in design, not a launch checklist. The template asks what data the feature needs and why, whether it can work on-device, and whether data can be minimised, aggregated or made ephemeral. It also covers who can access the data, retention, encryption at rest and in transit, consent and transparency in the UI, and any third parties involved. These echo Apple's public principles: data minimisation, on-device processing, transparency and control, and security. A trained reviewer outside the team signs off, and the decisions are written down. The outputs feed directly into the privacy manifest, the nutrition labels and the data inventory. The review is re-triggered whenever data use changes.

Re-signing makes Apple the final authority on what runs from the App Store. After review, Apple applies its own distribution signature and FairPlay encryption to the exact binary it approved. A developer's leaked distribution certificate therefore cannot be used to push a different binary to App Store users, because devices only accept App Store installs carrying Apple's signature. It also enables per-device thinning and protects against piracy. The trade-off is that developers give up some control over the final artefact. That is why symbol files must be uploaded, or generated by Xcode, so crash reports can be symbolicated against Apple's processed build. Development, ad hoc and enterprise builds keep the developer's or organisation's signature because they skip review.

App thinning means a device downloads only what it needs. Slicing is the main part. From a single upload, the App Store produces variants for different device classes, keeping only the right architecture, image scales and Metal or GPU assets. This works best when resources are in asset catalogues. On-demand resources let the app fetch tagged content later, such as game levels, and the system can purge it when storage is low. Bitcode recompilation was removed in Xcode 14. For delivery, the CDN caches many variants per version instead of one universal file. Cache keys include the variant, and the client requests the variant matching its device traits. That raises origin storage but sharply cuts bytes transferred per install.

I would use these entities. An App has a stable app ID and bundle ID, and belongs to a developer account. An AppVersion has a marketing version string, a state (preparing, in review, approved, released) and release settings. A Build carries the build number, SDK, minimum OS, its signed artefact references and per-device variant manifests. It links to one version once that version is submitted. A Localization holds the name, subtitle, description, keywords and screenshots per locale. TerritoryAvailability maps an app to countries and pricing tiers. AgeRating, PrivacyLabel and InAppProduct records hang off the app or version. Reads vastly outnumber writes, so the editorial source of truth is denormalised into per-storefront read models and a search index, updated by events when a version's state changes.

I accept eventual consistency, but I control which inconsistencies can happen. The release is one authoritative state change in the catalogue database. That change emits an event carrying a version number, and every downstream projection consumes the event idempotently: storefront pages, search, CDN manifests and update feeds. The key invariant is that no projection may advertise a build whose artefacts are not already present and verifiable at the CDN. So artefacts are published first, and pointers move after. Each projection keeps the highest version it has seen and ignores older events. Clients may briefly see the old listing, which is harmless. A reconciliation job compares projections with the source of truth and repairs any lag, and lag is monitored per region.

When a renewal charge fails, Apple enters billing retry and keeps trying to collect for a period. You receive DID_FAIL_TO_RENEW, and the renewal info shows the retry state. If the developer has enabled Billing Grace Period in App Store Connect, the user keeps access for a configured window while Apple retries. The server tracks this as in grace with gracePeriodExpiresDate, and access continues until that date. Without grace, access ends at expiry, but I would still show a gentle 'update payment method' prompt. Apple also offers a system sheet for billing problems. If Apple recovers the payment, a DID_RENEW notification restores the active state seamlessly. If retry ends without payment, the subscription expires. Metrics on involuntary churn tell you whether grace is worth enabling.

StoreKit 2 keeps signed transactions on the device. Transaction.currentEntitlements returns the active ones, already verified by StoreKit, and VerificationResult lets the app reject anything unverified. So the app can unlock content offline and survive reinstalls. It should also listen to Transaction.updates for renewals and revocations, and call finish() once content has been delivered. For purely local features, that is usually enough. For anything of server-side value, such as cloud features, currency or premium API calls, the device is a hint, not the authority. The backend verifies the JWS itself or queries the App Store Server API, and enforces entitlement at the API layer. Jailbroken devices can tamper with the app's logic, which is why authorisation belongs on the server.

I state assumptions instead of quoting any Apple figures. Say we have 2 million subscribers, mostly monthly. Renewals alone come to roughly 2 million a month, or about 67,000 a day, which averages under one per second. Renewal timing is uneven, though, so I would plan for peaks many times the average. Add notifications for new subscriptions, failures, refunds, offers and plan changes, perhaps doubling the volume. Payloads are a few kilobytes each, so bandwidth is trivial. The real costs are JWS verification, database writes and downstream fan-out to analytics and CRM. Design for bursts: a stateless verifier behind a load balancer, quick acknowledgement, a durable queue, and idempotent workers. The hard problem is correctness and recovery, not throughput.

Once a CloudKit schema is deployed to production, record types and fields cannot be deleted or have their types changed, so evolution must be additive. You develop in the development environment, then deploy schema changes to production before shipping the build that needs them. New fields must be optional, because old app versions will keep writing records without them. To rename or restructure, add the new fields, dual-write for a while, read with fallback, and later stop using the old fields without removing them. A schema version field on records helps clients interpret the data. Index additions such as queryable or sortable flags are made deliberately. Every change is tested by running old and new app versions against the same container.

App Attest lets your server gain confidence that a request comes from a genuine instance of your app on a real Apple device. The app generates a key in the Secure Enclave, and Apple attests it. Your server validates that attestation once, then checks signed assertions on sensitive requests, such as redeeming rewards or high-value API calls, with a counter to prevent replay. DeviceCheck offers two per-device bits that survive reinstall, useful for flagging a device that already claimed a free trial bonus. Neither tells you who the user is, and neither replaces authentication. I roll out gradually and monitor failure rates, because attestation can fail for legitimate reasons. I treat failure as a risk signal rather than a hard block at first.

Apple's leaders have described, including in a 2020 Harvard Business Review article, an organisation grouped by expertise: hardware engineering, software, design and so on. Experts lead experts, and there is a single P&L at company level. The strength is deep craft and consistency across products, because one camera or silicon team serves everything, and decisions are made by people who know the domain. The costs are heavy cross-functional coordination, since every product depends on many teams, and leaders who must collaborate without owning all the levers. It also needs strong central prioritisation and a tightly managed release calendar. For most companies, the lesson isn't to copy the org chart. It is to value deep expertise in leaders and invest deliberately in cross-team integration.

I would watch crash-free sessions and users per version, launch time, hang rate, memory terminations and battery impact. Sources include Xcode Organizer, which draws on users who opt in to share analytics, and MetricKit payloads collected in-app. A third-party crash SDK can add real-time alerts, as long as it is declared in the privacy manifest. Server-side, I track API error rates and latency segmented by app version, plus funnel metrics such as sign-in and purchase success. App Store Connect adds downloads, conversion and phased-release progress. Dashboards compare the new version against the previous one at equal exposure. Alerts trigger the pause-and-flag playbook. All telemetry is minimised, aggregated and covered by consent.

Under Apple's Digital Markets Act changes in the EU, developers can distribute iOS apps through alternative app marketplaces or, under conditions, from their own website. Such apps skip full App Review. Instead, they go through notarization, which combines automated checks and human review focused on platform integrity, malware and security, not on business or content rules. They are still signed, and the system still verifies them at install. Marketplace developers must meet Apple's eligibility requirements. In-app payments can use alternatives to StoreKit, which shifts transaction verification, refunds and fraud handling onto the developer or payment provider. The business terms have changed several times, so I would check Apple's current documentation before designing around them.

1. AJSON Web Signature (JWS)Correct answer
2. BProtocol Buffers with HMAC
3. CPlain JSON over TLS
4. DXML plist signed with PKCS#7

Why: StoreKit 2 and the App Store Server API use JWS, with a certificate chain that leads to Apple's root.

1. AoriginalTransactionIdCorrect answer
2. BsubscriptionGroupIdentifier
3. CtransactionId
4. DnotificationUUID

Why: originalTransactionId identifies the subscription across renewals and restores, while each renewal gets a new transactionId.

1. ARemoving the privacy manifest
2. BExpedited App Review
3. CPhased release for automatic updatesCorrect answer
4. DTestFlight internal testing

Why: Phased release spreads automatic updates over several days and can be paused, so a regression reaches only part of the user base before it is caught.

1. AVerify the signed transaction on your server and track server notificationsCorrect answer
2. BAsk the user to send a receipt screenshot
3. CTrust a boolean flag stored in UserDefaults
4. DCheck that the app was downloaded from the App Store

Why: StoreKit 2 transactions are cryptographically signed, and server-side verification plus App Store Server Notifications covers renewals, refunds and revocations.

1. A60 days
2. B90 daysCorrect answer
3. C180 days
4. D30 days

Why: TestFlight builds are available to testers for 90 days after upload.

1. A3
2. B7Correct answer
3. C14
4. D30

Why: A phased release ramps through set percentages over seven days.

1. AUsers on older iOS versions
2. BUsers in the EU
3. CUsers with automatic updates on
4. DUsers who update manually from the App StoreCorrect answer

Why: A phased release only paces automatic updates, so anyone can update manually and new installs get the latest version.

1. AThe verifyReceipt endpointCorrect answer
2. BApp Store Server Notifications V2
3. CJWS signature verification
4. DTransaction.currentEntitlements

Why: Apple deprecated the verifyReceipt endpoint and recommends the App Store Server API and signed transactions.

1. AwebOrderLineItemId
2. BbundleId
3. CstorefrontId
4. DappAccountTokenCorrect answer

Why: appAccountToken is a UUID the app supplies at purchase, and it is returned in the signed transaction.

1. AEntitlements that must be permitted by the provisioning profileCorrect answer
2. BThe App Store category
3. CThe age rating
4. DThe app's marketing version

Why: Entitlements are embedded in the signature, and iOS honours them only if the Apple-signed provisioning profile allows them.

1. AiOS 14.5Correct answer
2. BiOS 16
3. CiOS 17.4
4. DiOS 13

Why: Apps had to request permission through ATT to track users and access the IDFA starting with iOS 14.5.

1. AThe data is recovered from iCloud Backup unencrypted
2. BApple resets the encryption keys
3. CApple support can restore the data after identity verification
4. DThe end-to-end encrypted data cannot be recoveredCorrect answer

Why: Apple does not hold the keys under ADP, so the data is unrecoverable without a recovery method.

1. ADID_CHANGE_RENEWAL_STATUS
2. BEXPIRED
3. CREFUNDCorrect answer
4. DREVOKE_ACCESS

Why: A REFUND notification is sent and the transaction carries a revocationDate.

1. AContact App Review
2. BAsk users to restore purchases
3. CCall the App Store Server API's Get Notification History endpointCorrect answer
4. DRe-upload the build

Why: Get Notification History returns past notifications so the server can backfill gaps.

1. Astorefront
2. BproductId
3. CnotificationUUIDCorrect answer
4. DbundleVersion

Why: notificationUUID uniquely identifies each notification, so retries can be handled idempotently.

1. AAutomatically release after approval
2. BRelease on a scheduled date
3. CAutomatically roll back to the previous version when crashes riseCorrect answer
4. DManually release after approval

Why: App Store Connect offers manual, automatic, scheduled and phased release, but no automatic rollback to an older binary.

1. ATo compress the app for faster download
2. BTo confirm the code comes from an identified developer and has not been alteredCorrect answer
3. CTo choose the right CDN region
4. DTo sync app data to iCloud

Why: Code signing ties the binary to an Apple-issued developer identity, and on-device verification blocks tampered or unsigned code from running.

1. A100,000
2. B100
3. C1,000
4. D10,000Correct answer

Why: Apple allows up to 10,000 external testers, invited by email or a public link.

1. AAnyone with a public link
2. BUp to 100 App Store Connect team members with an appropriate roleCorrect answer
3. COnly users in the developer's country
4. DUsers enrolled in the iOS public beta

Why: Internal testing is limited to up to 100 App Store Connect users on the team, and their builds need no beta review.

1. APrivacy.json
2. BInfo.plist
3. CPrivacyInfo.xcprivacyCorrect answer
4. DEntitlements.plist

Why: Apple's privacy manifest is the PrivacyInfo.xcprivacy property list file.

1. ASafety, Performance, Business, Design, LegalCorrect answer
2. BSecurity, Speed, Pricing, UI, Compliance
3. CContent, Code, Commerce, Craft, Contracts
4. DPrivacy, Stability, Revenue, Accessibility, Localisation

Why: The guidelines are organised into Safety, Performance, Business, Design and Legal.

1. AApple Developer Forums
2. BThe App Review Board appeal processCorrect answer
3. CFeedback Assistant
4. DAppleCare

Why: Developers can appeal rejections to the App Review Board.

1. ASlicingCorrect answer
2. BDelta compression
3. CBackground assets
4. DOn-demand resources

Why: Slicing produces device-specific variants from one upload.

1. AMarch
2. BJuneCorrect answer
3. CSeptember
4. DJanuary

Why: WWDC is held in June, and the OS releases typically follow in autumn.

1. APrimary, replica and archive
2. BUser, device and session
3. CPublic, private and sharedCorrect answer
4. DHot, warm and cold

Why: CloudKit containers have public, private and shared databases.

1. ADelete existing fields or record typesCorrect answer
2. BAdd an index
3. CAdd a new record type
4. DAdd a new field

Why: Production CloudKit schemas only allow additive changes, so fields and record types cannot be deleted.

1. ACFBundleShortVersionString only
2. BCFBundleVersion (the build number)Correct answer
3. CThe bundle identifier
4. DThe Team ID

Why: Each uploaded build of a version needs a unique, higher build number, stored in CFBundleVersion.

1. AThat the user has paid for a subscription
2. BThe device's precise location
3. CThe user's real-world identity
4. DThat requests come from a genuine instance of the app on a real Apple deviceCorrect answer

Why: App Attest uses Secure Enclave keys attested by Apple to vouch for app and device integrity, not for user identity.

1. ADisable signature verification
2. BSubmit to App Review
3. CUse a production Apple Account with a gift card
4. DStoreKit Testing in Xcode and the App Store sandbox environmentCorrect answer

Why: Xcode StoreKit configuration files and sandbox accounts simulate purchases, renewals and refunds without real charges.

1. ATo fix a critical bug or a time-sensitive event, at Apple's discretionCorrect answer
2. BFor every routine update
3. CTo bypass a guideline rejection
4. DTo beat competitors to a feature launch

Why: Apple considers expedited requests for critical fixes or time-sensitive events, and grants them at its discretion.

1. AIt became mandatory in Xcode 14
2. BIt was deprecated starting with Xcode 14Correct answer
3. CIt replaced app slicing
4. DIt is required for watchOS only

Why: Apple deprecated Bitcode in Xcode 14, and the App Store no longer accepts Bitcode submissions.

1. AEncrypting app binaries
2. BDownloading tagged content after install and letting the system purge it when neededCorrect answer
3. CRunning server code on device
4. DSharing data between apps

Why: On-demand resources are hosted by the App Store, fetched when needed, and can be purged by iOS to save space.

1. AA matrix of regional general managers
2. BIndependent business units each with their own P&L
3. CA functional organisation where experts lead expertsCorrect answer
4. DA holding company of separate product firms

Why: Apple has described a functional structure organised by expertise, notably in a 2020 Harvard Business Review article.