Every year, Apple ships a major iOS release that breaks something. Every few months, App Store policy adds a new compliance requirement. Every quarter, an SDK your app depends on gets a privacy change that needs a manifest update. iOS maintenance isn't passive. We keep your app current, compliant, and working for your users — from a rolling monthly retainer starting at £675/month.
Apple ships a major iOS release every September. Each one deprecates APIs, adds Privacy Manifest requirements, and updates App Store submission rules. The April 28, 2026 Xcode 26 SDK deadline is a hard cutoff: after that date, any update submitted without SDK compliance is automatically rejected. No exceptions, no grace period.
Around 46% of the 1.8 million apps on the App Store haven't had a binary update in over two years. Many face a significant remediation effort now, not a routine SDK bump. Privacy Manifests alone accounted for 12% of all App Store rejections in Q1 2025, and 47.2% of apps integrate at least one third-party SDK with non-compliant privacy practices. The violations often come from code the developer didn't write.
Most iOS maintenance clients are in one of three situations: a developer is leaving, they've received an App Store rejection or compliance warning, or an app hasn't been actively maintained in over a year. All three are straightforward to handle. We start with a code review: Xcode SDK compliance status, Privacy Manifest completeness, dependency health across CocoaPods and Swift Package Manager, current crash data, and any Swift deprecation warnings heading towards build errors. We document everything and scope any remediation separately before the retainer begins. Onboarding takes 3 to 5 working days. From £675/month, 3-month minimum.
If you need broader maintenance covering Android alongside iOS, our cross-platform App Care retainer covers both under one agreement.
Written by Gareth Reese, Founder and CTO of Foresight Mobile. Gareth oversees App Care engagements and has personally managed iOS maintenance transitions from departing developers, App Store compliance recoveries, and legacy Objective-C codebase modernisation projects.
An actionable four-week plan with clear deliverables and an unbeatable £3,500 price point, credited against your first development sprint.
Total client time commitment: 5-7 hours across 4 weeks
We meet with your key stakeholders to understand your business goals, user needs, and technical constraints. You'll share any existing research, designs, or documentation you have.
Our engineering team assesses the technical feasibility, identifies integration points with your existing systems, and evaluates architecture options.
We determine whether Flutter, native development, or another approach makes the most sense for your specific requirements.
We create clickable prototypes so you can experience your app before it's built. You'll test navigation flows, validate the user experience, and gather feedback from stakeholders.
Alongside this, we prioritise features based on business value and technical complexity, mapping out a phased delivery plan with a detailed cost estimate.
You receive your complete Gameplan pack, plus a presentation walkthrough with Q&A. Your team walks away with everything needed to make a confident decision.
A named iOS team who stays ahead of Apple's compliance requirements, monitors your app's performance with MetricKit, and handles the App Store review process so you don't have to.
Taking over an iOS app from an offshore team or a departing developer is one of the most common situations we handle. Apps in this situation typically have suppressed deprecation warnings that are now approaching hard-error status, Privacy Manifests that were either never created or cover only partial data flows, and dependency trees that haven't been touched since the initial build.
We start with a code review covering: Xcode SDK compliance (which SDK version the app targets vs the current requirement), Privacy Manifest completeness, Swift Package Manager and CocoaPods dependency health, current crash data if MetricKit or Crashlytics is already configured, and any deprecated APIs that are on track to become build failures in the next Xcode release.
We document everything we find. If there's remediation work needed — and there usually is — we scope it separately so you know what it costs before committing. Onboarding takes three to five days from when we have App Store Connect access and a copy of the codebase. We support apps written in Swift, Objective-C, and mixed Swift/Objective-C codebases.
Swift and Objective-C Support • Structured Code Review • Privacy Manifest Audit • 3–5 Day Onboarding • App Store Connect Access Management
Every maintenance release we ship goes through TestFlight before it hits the App Store. For annual iOS compatibility updates, we use the developer beta programme to test against pre-release iOS builds from June, giving us three months to identify and fix any regressions before they affect live users. For feature releases and bug fix batches, we use an internal TestFlight group with your team before widening to a broader beta pool.
TestFlight beta management is also the right approach for App Store compliance migrations. When we make Privacy Manifest changes, Swift concurrency updates, or SDK swaps, testing through TestFlight lets us validate the changes in a production-equivalent environment before the App Store review clock starts. App Store submissions that fail review cost time; TestFlight validation catches issues before that point.
We also manage the App Store Connect configuration: app versions, release notes, phased rollout settings, and build expiry dates. When a TestFlight build is ready for App Store submission, the metadata is already prepared.
Developer Beta Testing • iOS June Beta Programme • Phased Rollout Management • App Store Connect Configuration • Pre-Submission Validation
MetricKit is Apple's native framework for collecting performance and diagnostic data directly from production devices, and it captures signals that third-party tools miss. While Firebase Crashlytics captures crashes, MetricKit also reports hang rates (how often the app freezes for more than 250ms), disk writes per day, CPU usage, and battery impact — the metrics Apple uses internally to evaluate app quality.
We configure MetricKit in every iOS app we maintain, set up automated alerts for threshold breaches, and review the diagnostic payloads after each iOS release. New iOS versions often change energy accounting or introduce new hang conditions in previously stable code — MetricKit is where we see that first, before it shows up in App Store reviews.
For P1 incidents — complete crashes on the latest iPhone model, App Store rejection blocking a live release, a critical security vulnerability — we acknowledge within 15 minutes and target resolution within four hours. Monthly health reports include MetricKit trend data, any hang or crash patterns, what we investigated, and what we fixed.
MetricKit Integration • Hang Rate Monitoring • Energy Impact Tracking • P1 SLA: 15min/4hr • Monthly Health Reports
Swift deprecations that earlier Xcode releases only warned about become hard errors in the current release cycle. The most common pattern: UIKit-era code accessing shared mutable state across threads without actor isolation, which Swift 6's strict concurrency model now refuses to compile. The longer these are deferred, the more disruptive the fix — we address them incrementally during the maintenance retainer before they become blocking issues.
For apps with significant UIKit codebases, we use a hybrid architecture approach: SwiftUI for new features, incremental migration of high-traffic UIKit screens. SwiftUI reduces development time by 36.8% and code complexity by 40% compared to equivalent UIKit implementations. Practically, that means maintenance updates on SwiftUI screens ship faster and with fewer regressions than on their UIKit equivalents.
The "Liquid Glass" design update in iOS 26 is a concrete example of why incremental modernisation matters. System components update automatically on recompile. Custom UIKit views often don't — navigation bars appear transparent, custom buttons clash with the new translucency. Apps that have already moved high-impact screens to SwiftUI handle this with minimal effort. Apps that haven't face a full custom view audit.
Swift 6 Concurrency • Actor Isolation • UIKit-to-SwiftUI Migration • Liquid Glass Compatibility • Incremental Approach
App Store policy changes arrive continuously, and the rejection consequences range from a blocked update to permanent removal. Privacy Manifests (the PrivacyInfo.xcprivacy file) are now mandatory for every app. The NSPrivacyAccessedAPITypes declarations must accurately reflect every sensitive system call in your code and in every third-party SDK you integrate. In Q1 2025, 12% of all App Store submissions were rejected specifically for Privacy Manifest violations — and 47.2% of apps integrate at least one third-party SDK with non-compliant privacy practices.
We maintain your Privacy Manifest as a live document, updating it whenever your dependency tree changes. When a third-party SDK ships a new version with different data practices, we review the privacy impact before updating, not after a rejection. We also manage the App Tracking Transparency (ATT) prompt implementation and the App Store's data practices declarations, which must match your actual data flows.
For rejections that do happen — the App Store rejects around 40% of submissions for performance-related issues like crashes on launch, and 28% for spam or low-value detection — we handle the response to Apple's review team, implement the required change, and resubmit. Most rejections have a known resolution; the challenge is navigating the review team communication efficiently, which we've done enough times to know the fastest path.
Privacy Manifests • NSPrivacyAccessedAPITypes • ATT Compliance • Rejection Management • Data Practices Declarations
Apple's annual iOS release cycle isn't optional. Each major version brings API deprecations, new permission requirements, App Store submission rules, and — in the iOS 26 cycle — a significant UI overhaul with the "Liquid Glass" design language that causes visual regressions in custom components. Apps that aren't actively maintained fall behind this cycle, and the gap compounds: each skipped year adds more deprecated APIs, more manifest requirements, and more SwiftUI migration debt.
We test your app on the iOS developer beta from June each year, identify breaking changes and regressions, and have compatibility updates ready before the September public release. For the iOS 26 cycle specifically, we handle the Xcode 26 SDK migration, 64-bit arm64 compliance verification (removing any legacy 32-bit library slices), and Liquid Glass UI regression testing on your custom views and navigation components.
Apple's April 2026 deadline for Xcode 26 SDK compliance is a hard cutoff — apps that miss it can't submit any updates. We track these deadlines and ensure you're never in a position where a critical bug fix can't be shipped because a compliance migration wasn't done.
Xcode 26 SDK Migration • 64-bit arm64 Compliance • Liquid Glass UI Testing • September Beta Testing • No Submission Blocks
Yes. We maintain apps written in Objective-C, Swift, and mixed Swift/Objective-C codebases. Objective-C is still supported by Apple and remains the foundation of many long-running iOS apps, particularly those built before 2014–2016 that haven't been fully migrated.
Objective-C apps face specific maintenance considerations: the language isn't getting new features, which means any Swift-era APIs eventually need bridging headers or wrapper code; some modern SDKs have reduced or eliminated their Objective-C support; and Privacy Manifest requirements apply equally regardless of language. None of these are blockers, but they're worth knowing about when scoping maintenance work.
If an Objective-C app would benefit from incremental Swift migration — and many do, particularly if new feature development is planned — we can include that as part of the maintenance retainer, prioritising the areas of the codebase that are touched most frequently.
Yes. Taking over iOS apps from other developers, agencies, and offshore teams is one of the most common situations we handle. We support apps in Swift, Objective-C, and mixed Swift/Objective-C codebases, and we work with both Swift Package Manager and CocoaPods dependency management.
We start every takeover with a structured code review covering Xcode SDK compliance status, Privacy Manifest completeness, dependency health, current crash data, and Swift deprecation warnings that are on track to become hard errors. We document everything we find and scope any remediation work separately before committing to the retainer.
Onboarding takes three to five working days from when we have App Store Connect access and a copy of the codebase. After that, the rolling monthly retainer begins. The three-month initial period exists to make the onboarding investment worthwhile for both parties.
App Store rejections fall into a few common categories: performance issues like crashes on launch or incomplete submissions (around 40% of unresolved issues), privacy and compliance violations including Privacy Manifest problems, and policy violations related to in-app purchases or data handling. The App Store review team typically provides a rejection reason with a guideline reference.
For clients on a maintenance retainer, we handle the rejection process: we review the rejection reason, identify the root cause (which isn't always the stated guideline — sometimes the stated reason is a symptom of a deeper issue), implement the fix, test it through TestFlight, and resubmit. For most common rejection types we have established resolution playbooks.
For apps not yet on a retainer that have received an unexpected rejection, we offer a one-off triage and resolution service. If the rejection reveals underlying compliance work that needs addressing, we can scope that separately before you commit to a retainer.
A Privacy Manifest (PrivacyInfo.xcprivacy) is a structured file that declares your app's data collection practices — specifically, which "Required Reason APIs" your app accesses and why. Required Reason APIs are system APIs that access sensitive data like file timestamps, system boot time, disk space, and user defaults. Apple introduced mandatory Privacy Manifests in iOS 17 and has been progressively enforcing them in App Store submissions since 2024.
Yes, all iOS apps need a Privacy Manifest. The complexity is that the declarations must cover not just your own code but every third-party SDK you integrate. If you use Firebase, a payment SDK, an analytics library, or any other third-party framework that accesses Required Reason APIs, their privacy practices must be reflected in your manifest. In Q1 2025, 12% of App Store submissions were rejected for Privacy Manifest violations, and 47.2% of apps integrate at least one third-party SDK with non-compliant practices.
We treat Privacy Manifests as a living document in every iOS retainer. When your dependencies change, we review the privacy impact and update the manifest before you submit an update. This prevents rejections from appearing as surprises during a time-sensitive release.
Apple sets an annual deadline requiring all App Store submissions and updates to be built with the current Xcode SDK. The April 28, 2026 deadline requires Xcode 26 SDK compliance — after that date, any app update submitted without it is automatically rejected.
The Xcode 26 SDK requirements include: exclusive 64-bit arm64 architecture (removing legacy 32-bit library slices), signed Privacy Manifests for any Required Reason APIs, compatibility with the iOS 26 "Liquid Glass" design system, and Swift 6 concurrency enforcement. Each of these has practical implications: apps with native libraries from vendors who haven't published arm64-compatible builds will fail validation; apps with third-party SDKs that haven't signed their privacy manifests will get rejected; apps with custom UI components may have visual regressions under Liquid Glass.
If your app hasn't been actively maintained, this deadline may represent a significant sprint of remediation work rather than a routine SDK bump. We assess the scope of work for any app as part of the onboarding code review.
iOS app maintenance in the UK typically costs between £675 and £1,495 per month on a retainer. Our App Care retainers for iOS start at £675/month for an Essentials plan covering a single-platform app.
The industry benchmark for annual maintenance is 15–25% of the original development cost. For an app that cost £80,000 to build, that's £12,000 to £20,000 per year for baseline maintenance. A fixed retainer is usually more cost-predictable than ad-hoc billing, particularly for Apple's compliance cycles which create non-negotiable annual work regardless of whether anything else has changed.
For context, the UK market standard for a "Standard" iOS maintenance retainer (covering roughly 10 development hours per month, full QA, and OS release testing) is £675 to £1,500/month with 24-hour SLA response times. Premium retainers with 4-hour P1 SLA, real-time monitoring, and beta testing typically sit between £2,000 and £5,000/month.
iOS app maintenance covers the ongoing technical work needed to keep a live App Store app functional, compliant, and performing well. At minimum this includes: annual Xcode SDK compatibility updates (to meet Apple's spring submission deadlines), Privacy Manifest maintenance (PrivacyInfo.xcprivacy and NSPrivacyAccessedAPITypes declarations), security patches and dependency updates, App Store compliance monitoring, and crash/hang monitoring.
A full maintenance retainer typically also includes: MetricKit performance monitoring with monthly health reports, TestFlight beta management for release testing, App Store Connect management (build submissions, release notes, review response), incremental Swift and SwiftUI modernisation, and a shared Slack channel with a named iOS engineer.
Some retainers cover feature development alongside maintenance. This is useful when you want the same team that knows the codebase to build new features — it eliminates handover friction and ensures maintenance work and feature work don't conflict.
At a minimum, every iOS app needs maintenance once a year — in September when Apple releases a major iOS update, and in spring when the new Xcode SDK compliance deadline hits. In practice, active maintenance work happens monthly: dependency updates, security patches, Privacy Manifest updates when third-party SDKs change, and any bug fixes that surface from crash monitoring.
The volume of work varies by how mature and actively developed the app is. A stable app with a small dependency tree and no legacy UIKit debt might need four to eight hours of monthly maintenance work. An app with a large dependency tree, significant third-party SDK usage, and ongoing feature development typically needs more — closer to 20 to 40 hours per month when you include regression testing and documentation.
Apps that haven't been maintained for over a year typically need a one-off remediation sprint before moving to a regular retainer, to bring the SDK compliance, Privacy Manifests, and Swift deprecations up to current standards. We assess this as part of the onboarding code review.
You've got a working app and nobody reliable to look after it. Maybe your developer handed in their notice. Maybe the offshore team stopped responding. Maybe the freelancer who built it has gone quiet at the worst possible time.
App Care onboarding gets you from that situation to a UK-based team who knows your codebase inside out, with a shared Slack channel and agreed response times. The onboarding fee is typically £500 to £1,000 depending on complexity. After that, you're on a rolling monthly retainer from £675/month with no long-term lock-in after the initial three months.
We start with a short call to understand what your app does, what platforms it runs on, and what the handover situation looks like. Then we request access to the repository (GitHub, GitLab, or Bitbucket), your App Store Connect and Google Play accounts, and any backend infrastructure. If a departing developer is still available, we'll use some of that time to fill in gaps. If not, we work from the code.
We review the architecture, third-party dependencies, security posture, and anything that looks fragile. If there's technical debt that needs fixing before we can support the app properly, we scope that separately so you know what it'll cost. We also build internal documentation covering how the app is structured, where the critical logic lives, and how deployments work.
We instrument the app with Firebase Crashlytics and Sentry for crash reporting, and set up Datadog for backend API monitoring where applicable. We configure CI/CD pipelines, TestFlight distribution for iOS builds, and deployment processes that don't rely on a single developer's laptop. Snyk and SonarQube scans catch dependency vulnerabilities and code-level security issues before they become incidents.
Your retainer covers OS updates, security patches, App Store compliance, crash investigation, and proactive monitoring. Feature work is scoped and priced separately so you always know what you're paying for. The initial commitment is three months, then rolling monthly with no long-term lock-in. You stay because the service is good, not because you're contractually stuck.
Your app, your way. Here's how we make it happen.
Fixed price agreed upfront, with regular progress calls and live demos so you always know where your project stands.
From first build to App Store submission and beyond, we offer App Care retainers from £675/month so your app keeps pace with your business. We're with you all the way.
Real users from your target audience test your app throughout development, not just at the end. Their feedback shapes decisions before they become expensive to undo — so you launch with confidence rather than hope.
You know your business. We know how to build apps that succeed. The two together is where good products come from.
Our founder has been building mobile products since 2003, and our core team has been together since Foresight launched in 2017.
We're based in Manchester with offices in London and Birmingham, and believe face-to-face time makes better products. Drop in whenever you like.
