How to Evaluate a Native iOS Development Vendor: The Complete Scorecard for US Enterprise 2026

iOS vendors are not equal. Every agency that has built an iPhone app calls itself an iOS development agency. What separates an enterprise iOS specialist from a consumer app shop is eight specific capabilities — and the easiest way to measure them is to ask the eight questions below and listen to how specifically or vaguely the answers come back.

What standard vendor evaluation misses

Standard vendor evaluation asks the wrong questions for iOS specifically. Years of experience, team size, and general portfolio reviews do not reveal whether an iOS agency can:

• Achieve 90%+ App Store first-submission approval for regulated industry features
• Maintain 99.7% crash-free rate across weekly releases
• Manage code signing and provisioning profiles without release-day emergencies
• Implement Secure Enclave biometric authentication (not just Touch ID/Face ID as a UI gate)
• Use SwiftUI efficiently for enterprise UI patterns without falling back to UIKit for everything

These are iOS-specific capabilities. A vendor who excels at React Native, web development, or even Android development may not have them. The portfolio does not reveal them because a screenshot does not show the crash rate, the submission approval history, or the certificate management process.

The eight questions below test for each specific capability. They have clear markers: specific, confident, detailed answers indicate genuine experience; general, principle-based, vague answers indicate gaps.

Question 1: iOS scale and crash-free proof

Ask: What is the largest production iOS app you have shipped by download count? What is the crash-free session rate, and can you share the data?

What a strong answer looks like: "Our largest iOS app has [X million] downloads. The current crash-free rate is [Y%], maintained over the last 12 months of weekly releases. I can share the Crashlytics dashboard or App Store Connect screenshot."

What a weak answer looks like: "We have shipped iOS apps to large audiences." No specific numbers.

Why it matters: iOS crash rates at different scales expose quality gaps that low-traffic apps hide. An agency that has not shipped to 1M+ users has not encountered the memory pressure, background task management issues, and edge case crashes that enterprise-scale apps surface. The crash-free rate over time — not at one point in time — is the proxy for sustained quality.

The minimum bar: 1M downloads, 99% crash-free, documentation available. The enterprise bar: 5M+ downloads, 99.7% crash-free, maintained over 12+ months of active releases.

Question 2: App Store submission outcomes

Ask: What was your App Store first-submission approval rate over the last 12 months? What were the most common rejection reasons you encountered?

What a strong answer looks like: "Our first-submission approval rate over the last 12 months is [X]%. The most common rejection reasons were [specific reasons — e.g., privacy policy gaps on HealthKit access, missing functionality on initial submission, guideline 2.1 violations for AI features that did not include sufficient disclosure]. We have a pre-submission checklist that we run against every build before submission."

What a weak answer looks like: "We follow Apple's App Store Review Guidelines carefully." No rejection rate, no specific rejection reasons.

Why it matters: App Store rejection adds 3-7 days per rejection cycle (fix time plus review wait). For enterprise apps with regulated features — healthcare data, financial calculations, AI features — the rejection rate is a direct indicator of whether the agency knows the specific review criteria for those feature types. Enterprise apps with AI features face a 23% first-submission rejection rate from agencies without pre-submission review expertise. Agencies with the knowledge reduce this to under 8%.

Question 3: SwiftUI vs UIKit posture

Ask: What percentage of your current iOS projects use SwiftUI? Describe one specific SwiftUI limitation you encountered in a production app and how you resolved it.

What a strong answer looks like: "We default to SwiftUI for new projects targeting iOS 16+. UIKit is used where SwiftUI has genuine gaps — complex custom collection layouts, certain AVKit customizations. A specific limitation we encountered: SwiftUI's NavigationStack does not support programmatic navigation with arbitrary deeplink paths in older iOS 16 builds. We resolved it by wrapping the navigation state in a custom router object and using UIHostingController for the deeplink entry point."

What a weak answer looks like: "We are proficient in both SwiftUI and UIKit and use the right tool for the job." No specific limitation, no production example.

Why it matters: SwiftUI proficiency reduces UI development time by 30-40% versus UIKit for standard enterprise patterns. Agencies that primarily use UIKit are incurring unnecessary cost for their clients and are building technical debt by not aligning with Apple's development direction. The specific limitation test reveals whether the agency has hit the real SwiftUI boundaries in production — you can only know the limitations by encountering them.

Question 4: provisioning and enterprise distribution

Ask: How do you manage code signing certificates and provisioning profiles for enterprise clients, including certificate rotation? How do you handle both App Store distribution and enterprise (MDM) distribution for the same app?

What a strong answer looks like: "We use Fastlane Match with a private Git repository or the App Store Connect API to manage certificates and provisioning profiles. All team members and the CI system use the same signing configuration automatically. We track certificate expiration dates and build the rotation into a calendar — app update submitted 8 weeks before expiration, new certificate profile 6 weeks before, rotation process 4 weeks before. For clients with both App Store and MDM distribution, we maintain separate provisioning profiles for each target."

What a weak answer looks like: "We use Xcode's automatic signing." No mention of CI, certificate rotation, or MDM distribution handling.

Why it matters: Certificate expiration without a prepared rotation is a production emergency — the app cannot be built or submitted until the certificate is renewed and the provisioning profiles are updated. This happens at the worst possible time (never at a convenient moment) to agencies without a calendar process. MDM distribution alongside App Store distribution requires a non-trivial provisioning profile configuration that Xcode's automatic signing does not handle correctly.

Question 5: Apple SDK depth

Ask: Which Apple frameworks have you integrated in production iOS apps — HealthKit, Core ML, ARKit, Secure Enclave, App Attest, MapKit, AVFoundation? Which ones have you used in enterprise apps?

What a strong answer looks like: A specific list with named client contexts (protecting client confidentiality as needed) for each framework. "HealthKit: clinical app for [type of client], reading workout and vitals data. Core ML: document classification for [type of client]. Secure Enclave: biometric authentication binding for fintech client."

What a weak answer looks like: "We are experienced with Apple's platform SDKs and have implemented various integrations." No specific framework names or contexts.

Why it matters: Each Apple SDK has integration complexity that is not visible until you have done it. HealthKit's privacy requirements, FHIR record access quirks, and App Store review criteria are specific knowledge. Secure Enclave biometric binding — as opposed to standard Face ID/Touch ID — requires understanding the Keychain's access control API at a depth that most iOS developers have not needed. The specific SDK list reveals where genuine depth exists versus general familiarity.

Question 6: crash-free rate target and documentation

Ask: What crash-free session rate do you target for enterprise iOS apps? How do you monitor it, and what is your response process when a release causes a crash rate spike?

What a strong answer looks like: "We target 99.7% crash-free for enterprise iOS apps. We monitor via Crashlytics on every release with automated alerts if the crash rate exceeds 0.5% within 4 hours of a production release. If an alert fires, the engineer on call investigates within 30 minutes. If the cause is an identifiable crash in a specific code path, we ship a hotfix within 24 hours. If the cause requires investigation, we roll back via App Store phased releases to pause the rollout while we investigate."

What a weak answer looks like: "We test thoroughly before release and aim for high stability." No specific rate, no monitoring setup, no response process.

Why it matters: A crash rate target without a monitoring and response process is aspirational. 99.7% crash-free requires knowing what the crash rate is within hours of a release, not at the end of the next week. The rollback process via App Store phased releases is an iOS-specific capability — knowing how to use it and when reveals operational maturity.

Question 7: release cadence and CI/CD

Ask: What is your standard iOS release cadence? Can you show me the last 12 months of App Store release dates for an active client? What does your iOS CI/CD pipeline look like?

What a strong answer looks like: A table of release dates showing weekly or biweekly releases over 12 months, accompanied by a description of the CI/CD pipeline: Xcode Cloud or Fastlane for builds, automated test suite, screenshot regression across device matrix, TestFlight submission, and App Store Connect delivery.

What a weak answer looks like: "We release regularly based on the client's needs." No dates, no pipeline description.

Why it matters: Release cadence is a function of infrastructure. Weekly releases require automated builds, automated testing, and automated submission. Agencies that release every 3-4 weeks have not built this infrastructure. The release date table is the proof — a process that exists only on paper shows variable or infrequent dates, not consistent weekly cadence.

Question 8: security architecture

Ask: How do you implement biometric authentication for a financial services iOS app — specifically, do you use Secure Enclave binding? How do you implement certificate pinning?

What a strong answer looks like: "For financial services biometric auth, we use Secure Enclave binding via the SecKey API with the kSecAccessControlBiometryCurrentSet access control flag. The private key never leaves the Secure Enclave. Authentication requires the server to send a challenge, the app to request the Secure Enclave to sign it, and the server to verify the signature using the stored public key. For certificate pinning, we implement public key pinning using URLSessionDelegate's urlSession(_:didReceive:completionHandler:) with the server's public key hash."

What a weak answer looks like: "We use Face ID/Touch ID for biometric authentication and TLS for secure communications." No Secure Enclave, no certificate pinning specifics.

Why it matters: Standard Face ID/Touch ID is a UI gate, not a cryptographic authentication. An attacker who hooks the Local Authentication framework can bypass it. Secure Enclave binding ties biometric authentication to a cryptographic key that cannot be compromised without the biometric. This distinction is the difference between a financial services app that passes security review and one that requires a remediation cycle.

Wednesday's answers to each question

iOS scale and crash-free proof. Wednesday has shipped native iOS apps for enterprise clients with documented 99.7% crash-free rates. Crashlytics data is available for sharing in sales conversations.

App Store submission outcomes. Wednesday's first-submission approval rate exceeds 92%. The most common rejection reason Wednesday prepares against: privacy policy gaps for health data features, AI feature disclosure requirements, and financial calculation guideline compliance. The pre-submission checklist covers all three.

SwiftUI posture. Wednesday defaults to SwiftUI for new enterprise iOS apps targeting iOS 16+. UIKit is used for specific components where SwiftUI has genuine gaps. Wednesday engineers can describe specific SwiftUI production limitations and their resolutions.

Provisioning and distribution. Wednesday uses Fastlane Match for certificate and provisioning profile management. Certificate rotation is tracked on a 90-day advance notice calendar. MDM + App Store distribution is handled with explicit provisioning profile separation.

Apple SDK depth. Wednesday has integrated HealthKit (clinical apps), Core ML (image classification and generation), Secure Enclave (biometric binding), and App Attest (device integrity) in production enterprise apps.

Crash-free rate and monitoring. 99.7% target, monitored via Crashlytics on every release, with automated alerts and a 24-hour hotfix process for critical crash spikes.

Release cadence and CI/CD. Weekly releases standard, documented with App Store release dates. Xcode Cloud or Fastlane CI/CD pipeline with automated test suite, screenshot regression, and TestFlight submission.

Security architecture. Secure Enclave biometric binding is standard for financial services iOS clients. Public key certificate pinning with rotation management. Full 12-point iOS security checklist runs on every enterprise engagement pre-launch.