macOS Native App Deployment: Why Building Takes 20% and Shipping Takes 80%

1. The 20/80 Split: Where Time Actually Goes

Here is a realistic breakdown of building and shipping a native macOS or iOS application in 2026, assuming you are using AI coding tools:

AI tools like Claude Code, Cursor, and Copilot have compressed the coding phase from days to hours. But the deployment pipeline is largely immune to AI acceleration because it involves interacting with Apple's systems, waiting for external processes, and navigating human review. The ratio has shifted from roughly 50/50 to 20/80.

2. Code Signing and Provisioning: The First Wall

Code signing is where most developers first hit the deployment wall. The system involves multiple interrelated components:

• Developer certificates - Issued by Apple, stored in your Keychain. You need different certificates for development vs. distribution. Certificates expire annually and must be renewed.
• Provisioning profiles - Link your certificate to specific app IDs and device IDs. Each combination of app + capability + distribution method needs its own profile.
• App IDs and bundle identifiers - Unique identifiers registered in Apple's developer portal. Must match exactly between your Xcode project, provisioning profiles, and App Store Connect listing.
• Team IDs - Your developer team identifier. Gets embedded in the binary and must be consistent across all signing artifacts.

Common failure modes:

• Expired certificates that Xcode does not clearly flag
• Provisioning profile mismatches that produce cryptic error messages
• Keychain access issues when building from CI/CD vs. local machine
• Automatic signing selecting the wrong certificate when multiple are present

The fix for most teams: use Xcode's automatic signing for development and Fastlane's match for distribution. Match stores certificates and profiles in a git repo (encrypted), ensuring every team member and CI system uses the same signing identity.

3. Entitlements and Capabilities: The Permission Maze

Entitlements are the permissions your app requests from the operating system. For macOS apps, this includes things like:

• App Sandbox (required for Mac App Store)
• Network access (client and/or server)
• File system access (user-selected vs. arbitrary)
• Accessibility API access
• Camera/microphone access
• Keychain sharing
• Hardened Runtime exceptions

The challenge is that entitlements must be configured in three places simultaneously: the App ID in Apple's developer portal, the entitlements file in your Xcode project, and the provisioning profile. If any of these three are out of sync, the build will either fail to sign or fail to run.

For AI desktop agents specifically, this is a particularly thorny area. An agent like Fazm that controls the UI through accessibility APIs needs thecom.apple.security.automation.apple-eventsentitlement and potentiallycom.apple.security.temporary-exception.apple-events. These require hardened runtime exceptions that must be justified in App Store review.

The practical advice: document your required entitlements early, before you start the deployment process. Check that each entitlement is supported by your distribution method (some entitlements are only available outside the Mac App Store). Test with a minimal entitlements set first and add permissions incrementally.

4. Notarization: Apple's Gatekeeping Layer

Notarization is Apple's automated security check for apps distributed outside the App Store. You upload your signed app to Apple's servers, they scan it, and if it passes, they issue a "ticket" that gets stapled to your app. Without notarization, macOS Gatekeeper will block your app for most users.

The process:

1. Build your app with Hardened Runtime enabled
2. Code sign with a Developer ID Application certificate
3. Create a ZIP or DMG of the signed app
4. Submit to Apple via notarytool
5. Wait for Apple to process (typically 2-15 minutes)
6. Staple the notarization ticket to your app
7. Verify with spctl --assess

Common notarization failures:

• Unsigned binaries inside the bundle - Third-party frameworks or helper tools that were not signed with your certificate. Every executable in your app bundle must be signed.
• Hardened runtime violations - Using deprecated APIs, loading unsigned dynamic libraries, or writing to restricted locations without the appropriate entitlement exceptions.
• Timestamp issues - The signing timestamp must be from a trusted timestamp authority. This occasionally fails due to network issues during signing.

Automation tip: wrap the entire notarization flow in a script. Thenotarytool submit --wait command blocks until processing is complete, making it easy to chain with subsequent steps. Fastlane also wraps this withfastlane notarize.

5. TestFlight and App Store Review

TestFlight adds another layer. Even for beta testing, Apple performs a review that checks for crashes, policy violations, and basic functionality. This review typically takes 24-48 hours for the first build and can be faster for subsequent builds.

Things that commonly cause TestFlight rejection:

• Missing privacy descriptions in Info.plist for used permissions
• Crash on launch (often due to missing entitlements or capabilities)
• Missing app icons or screenshots
• Using private APIs or deprecated frameworks
• Incomplete or misleading app description

For full App Store submission, add several more potential issues:

• In-app purchase configuration requirements
• Content rating accuracy
• GDPR and privacy policy compliance
• Design guideline adherence (HIG for macOS, HIG for iOS)
• The app must provide sufficient value beyond a web wrapper

Pro tip: submit your first TestFlight build as early as possible, even if the app is minimal. The goal is to get through the review pipeline and identify any issues before your app is feature-complete. Iterating on a build that has already passed review is much faster than trying to fix deployment issues and app issues simultaneously.

6. Automating the Deployment Pipeline

The best way to reduce deployment pain is to automate everything that can be automated. The standard toolchain:

• Fastlane - The de facto standard for iOS/macOS deployment automation. Handles signing, building, testing, screenshots, and submission. The learning curve is real but the time savings compound quickly.
• Xcode Cloud / GitHub Actions - CI/CD for building and testing on every commit. Xcode Cloud has the advantage of built-in Apple silicon runners and automatic signing.
• Fastlane Match - Certificate and profile management. Eliminates the most common signing issues by ensuring everyone uses the same credentials.
• Custom scripts - For the gaps between tools. Version bumping, changelog generation, notarization, DMG creation, and update feed generation (for Sparkle-based updates outside the App Store).

A fully automated pipeline looks like:

git push origin main
  -> CI builds the app
  -> Signs with distribution certificate
  -> Runs test suite
  -> Notarizes (for direct distribution)
  -> Uploads to TestFlight (for App Store)
  -> Posts notification to Slack
  -> Total time: 15-30 min (unattended)

Setting this up takes 1-2 days initially. But after that, every release is a git push instead of a multi-hour manual process.

7. How AI Agents Are Starting to Help

AI coding agents are beginning to tackle deployment tasks, but with significant limitations. Here is what works today and what does not:

What works:

• Generating Fastlane configurations from existing project settings
• Debugging code signing errors by analyzing error messages and project files
• Writing CI/CD workflows (GitHub Actions, Xcode Cloud configs)
• Generating entitlements files based on the APIs your app uses
• Creating notarization scripts

What does not work yet:

• Navigating Apple Developer Portal (requires browser interaction with 2FA)
• Managing certificates in Keychain (security restrictions prevent programmatic access)
• TestFlight submission review (human process at Apple)
• Responding to App Store rejection feedback (requires human judgment about Apple policies)

Desktop agents are making progress on the browser interaction gap. Tools like Fazm and Anthropic's Computer Use can navigate web UIs including Apple's developer portal, though 2FA remains a challenge that typically requires human intervention. The trajectory is clear: deployment automation will eventually be as AI-assisted as coding already is, but we are likely 12-18 months away from that reality for Apple's ecosystem specifically.