Forem: Mrugesh Tank

iOS Privacy Manifest & Required Reasons APIs: A Compliance Checklist

Mrugesh Tank — Sat, 02 May 2026 04:54:05 +0000

There's a specific kind of frustration that comes from an App Store rejection you didn't see coming.

Not a crash. Not a guideline violation. Not a metadata problem. Just a cold rejection email with an error code — ITMS-91053 — and a list of APIs your app called without declaring a reason for calling them.

APIs you've used for years. APIs that work perfectly. APIs like UserDefaults.

What Changed and Why It Matters

Starting May 1, 2024, Apple began enforcing a requirement that had been announced but, frankly, underestimated by a lot of developers: every app must ship with a PrivacyInfo.xcprivacy privacy manifest file. And if that app — or any SDK it bundles — touches certain system APIs without declaring a reason, the submission is rejected outright.

No warning. No grace period. Just a rejection and a list of undeclared APIs.

The requirement exists for a good reason. Third-party SDKs — analytics tools, crash reporters, ad networks — have always had the ability to call sensitive system APIs silently, without any visibility at the app layer. Developers trusted the SDK and moved on. Apple decided that transparency needed to be enforced, not just encouraged.

That's fair. The implementation, though, catches a lot of developers off guard — because the APIs on the required reasons list aren't obscure. They're everyday tools.

The Five APIs That Are Blocking Submissions

Apple currently defines five categories of required reason APIs. If your app uses any of these, you must declare it in your privacy manifest with a specific reason code:

File Timestamp APIs — creationDate, modificationDate, getattrlist(). If you read file metadata anywhere in your app, this applies.

System Boot Time APIs — mach_absolute_time(), systemUptime. Used for timing events, measuring elapsed time, calculating absolute timestamps. More common than you'd think.

Disk Space APIs — volumeAvailableCapacityKey, statfs(). If your app checks available storage before downloading or writing files, you're calling these.

Active Keyboard APIs — activeInputModes. Narrower use case, but catches keyboard-aware UI work and custom keyboard apps.

UserDefaults — The entire UserDefaults class. This is the one that gets almost everyone. Feature flags, user preferences, shared app group settings, SDK internal state — it's all UserDefaults. If your app runs on iOS, it almost certainly uses this.

For each category, you don't just declare that you use it — you declare why you use it, using a specific reason code from Apple's list. CA92.1 means you're reading defaults within your own app. 1C8F.1 means you're accessing a shared app group container. The codes are precise, and picking the wrong one is as much of a problem as not declaring at all.

The Part That Surprises Developers Most

Your own code is only half the story.

Every third-party SDK your app bundles is your responsibility. If Firebase, Amplitude, your crash reporter, or any other SDK on Apple's commonly-used list ships without a privacy manifest — or ships with an outdated one — your submission fails. Even if your own PrivacyInfo.xcprivacy is perfectly complete.

The safest move before every archive: update all your dependencies to their latest versions, then run Product → Privacy Report in Xcode. This generates a combined PDF of every manifest in your app bundle. Any SDK missing a manifest simply won't appear in the report. That absence is your signal to investigate before submitting — not after.

I've seen a particular edge case with static CocoaPods where the manifest file exists in the repository but doesn't get correctly bundled by Xcode due to how static library resources are handled. In those cases, the fix is to manually copy the SDK's required API declarations into your own PrivacyInfo.xcprivacy. Inelegant, but it works.

It's A One-Time Investment

Once your manifest is in place and your SDK dependencies are updated, the ongoing maintenance is light. Before each release: check for new API usage you've added, verify any newly integrated SDKs, regenerate the Privacy Report. Five minutes at most.

The harder part is the first time — understanding which categories apply to your app, reading each reason code carefully to pick the right one, and auditing every SDK in your bundle. That's where most of the time goes.

Apple has also signalled that this list of required reason APIs can expand in future OS releases. Treating it as a living compliance checklist — rather than a one-time fix — is the right posture.

I documented the full process: all five API categories, every reason code table, the SDK verification workflow, a 9-point pre-submission checklist, and the common mistakes that cause re-submissions.

If you're shipping an iOS app and haven't looked at your privacy manifest yet, this is the place to start.

Read the full article in idiotswithios.com

iOS 26 SDK Migration Guide: What Every App Needs to Update

Mrugesh Tank — Sat, 25 Apr 2026 12:51:56 +0000

I published a full migration guide on idiotswithios.com and wanted to cross-post the key highlights here — because the April 28 deadline is real, and I've already seen teams caught off guard by how much has changed.

Apple now requires all new App Store submissions and updates to be built with the iOS 26 SDK. Miss the deadline, and your next update gets rejected. Your existing app stays on the store — but you can't push a single update until you're compliant.

Here's a quick rundown of the 7 steps the full guide covers.

Step 1 — Update to Xcode 26

Everything starts here. You can't build with the iOS 26 SDK without Xcode 26 or later. Verify your install:

xcodebuild -version
# Xcode 26.0

If you use CI/CD (Xcode Cloud, Bitrise, GitHub Actions) — update your build agents too. A passing local build with a stale CI pipeline will block your App Store submission.

Step 2 — Fix Deprecated APIs

This is where most of the work is. Open your project in Xcode 26 and build. The warnings are your checklist.

UIKit:

UIWebView — fully removed. Won't compile. Migrate to WKWebView.
UIScreen.main — deprecated. Use windowScene.screen.
SceneKit — deprecated. Migrate to RealityKit.

SwiftUI:

NavigationView — deprecated since iOS 16 but still everywhere. Migrate to NavigationStack or NavigationSplitView.
actionSheet — broken in iOS 26. Replace with confirmationDialog.

Quick example — the NavigationView fix:

// ❌ Before
NavigationView {
    ContentView().navigationTitle("Home")
}

// ✅ After
NavigationStack {
    ContentView().navigationTitle("Home")
}

And if you're still on Combine for network calls, now is a good moment to migrate critical paths to async/await. Also: swap print for Logger — it integrates with Instruments and performs better.

Step 3 — Deployment Target

Building with the iOS 26 SDK does not force you to raise your minimum deployment target. These are two separate settings. That said, this is a natural moment to audit your analytics and drop versions with near-zero user share.

While you're in there: remove #available guards for versions you no longer support. Dead guards are noise — and removing them is a clean YAGNI win.

Step 4 — Privacy Manifest and TLS

Two things to check:

TLS 1.3 is now the default. If your app or any SDK you depend on still uses TLS 1.2, those connections will fail silently. Check your dependencies before you archive.

Privacy Manifest (PrivacyInfo.xcprivacy): If your app uses UserDefaults, file timestamps, or disk space — you must declare the approved reason codes. Missing entries fail both Xcode validation and App Store review.

<key>NSPrivacyAccessedAPICategoryUserDefaults</key>
<!-- reason: CA92.1 -->

<key>NSPrivacyAccessedAPICategoryFileTimestamp</key>
<!-- reason: C617.1 -->

<key>NSPrivacyAccessedAPICategoryDiskSpace</key>
<!-- reason: 85F4.1 -->

Step 5 — Handle Liquid Glass

This one is unique to iOS 26. When you rebuild with Xcode 26, standard UIKit and SwiftUI components — nav bars, tab bars, sheets, buttons — automatically adopt the Liquid Glass look. Translucent materials, dynamic blurs, refined controls.

For apps using standard system UI: this just works.

For apps with heavy custom UI: navigation bars and sheets behave differently. If you're not ready, Apple gives you a temporary opt-out:

<!-- Info.plist -->
<key>UIDesignRequiresCompatibility</key>
<true/>

This preserves the iOS 18 visual style on iOS 26. Use it as a bridge — Apple will remove this key in a future major release.

When you're ready to adopt it, SwiftUI makes it easy:

Text("Featured")
    .padding()
    .glassEffect()

Step 6 — Test Before You Archive

Build warnings catch API deprecations. They won't catch:

Visual regressions from Liquid Glass
Layout shifts on navigation and tab bars
Networking failures from TLS 1.2 → 1.3 changes
Permission flows on a fresh iOS 26 install

Test all of these on the iOS 26 simulator before you touch the Archive button.

Step 7 — Validate and Submit

Set scheme to Any iOS Device (arm64)
Product → Archive
Organizer → Validate App
Distribute App → App Store Connect

Common validation blockers: missing Privacy Manifest entries, lingering Bitcode references (fully removed in Xcode 26), and third-party SDKs that haven't updated yet.

Submit at least a week before April 28. Review takes 24–48 hours in normal conditions — don't cut it close.

The Short Version

Step	Action
1	Update to Xcode 26
2	Fix `UIWebView`, `NavigationView`, `actionSheet`
3	Audit deployment target and `#available` guards
4	Check Privacy Manifest and TLS 1.2 dependencies
5	Decide: adopt Liquid Glass or use the opt-out key
6	Test on iOS 26 simulator
7	Validate and submit before April 28

Most apps will get through this in a few focused days. Legacy UIKit apps with heavy customisation will take longer — especially if third-party dependencies haven't updated. Start now.

The full guide — with complete code examples, PrivacyInfo.xcprivacy snippets, Liquid Glass UIKit + SwiftUI code, and all Apple documentation references — is on idiotswithios.com.

→ iOS 26 SDK Migration Guide: What Every App Needs to Update

Written by Mrugesh Tank — @mrugeshtank on dev.to

SwiftUI Debugging: 6 Techniques Every iOS Dev Should Know

Mrugesh Tank — Sat, 14 Mar 2026 08:27:03 +0000

SwiftUI Previews are magical when they work. When they don't,
staring at "Preview crashed" with no clue why is one of the
most frustrating things in iOS development.

After debugging thousands of preview crashes across multiple
production apps, here are the 6 techniques I reach for every time.

Why Do SwiftUI Previews Break?

Previews run in a sandboxed environment separate from your app.
They have stricter resource limits, no access to your app's
environment by default, and their own compiler pipeline.
Once you internalize this, most failures become predictable.

Four root causes cover 90% of cases:

Compile-time errors (one broken file cascades across the project)
Runtime errors (force unwraps, nil crashes)
Missing environment dependencies (environmentObject not injected)
Complexity/timeout (view does too much, exceeds preview's time limit)

Technique 1 — Build explicitly first

Hit Cmd+B before anything else. The preview compiler sometimes
fails silently while your main target builds fine. Check the build
output for errors in files you weren't even editing.

Technique 2 — `Self._printChanges()`

This underused API tells you exactly why SwiftUI re-evaluated
your view's body:

var body: some View {
    let _ = Self._printChanges()
    // your view...
}

The console will log which @State or @ObservedObject property
changed and triggered the re-render. Invaluable for infinite
re-render loops.

Technique 3 — Use `Logger`, not `print()`

import OSLog

struct ProfileView: View {
    private let logger = Logger(
        subsystem: "com.yourapp", 
        category: "ProfileView"
    )

    var body: some View {
        let _ = logger.debug("body evaluated")
        // your view...
    }
}

Logger is type-safe, shows up in Console.app with filtering,
and gets stripped from release builds automatically.

Technique 4 — Isolate by binary search

Comment out half your view body. If preview works → problem is
in the commented half. Still crashes → problem is in the remaining
half. Keep halving until you find the exact line.

If you can't isolate a view without breaking everything,
your components are too tightly coupled. That's the real bug.

Technique 5 — Inject mock dependencies

Never make real network calls from previews. Use protocol-based
injection so you can swap in a mock:

protocol DataFetching {
    func fetchUsers() async throws -> [User]
}

class MockDataFetcher: DataFetching {
    func fetchUsers() async throws -> [User] {
        [User(id: 1, name: "Mrugesh Tank", email: "m@test.com")]
    }
}

#Preview {
    UserListView(dataFetcher: MockDataFetcher())
}

Technique 6 — Centralize preview mock data

Instead of scattering mock objects across every preview block,
create a single PreviewHelpers.swift:

#if DEBUG
enum PreviewData {
    static let user = User(id: 1, name: "Test User", role: .admin)
    static let users = [user, User(id: 2, name: "Jane", role: .member)]
}
#endif

Your previews become clean and consistent:

#Preview { ProfileView(user: PreviewData.user) }

The Bigger Lesson

Views that preview reliably are almost always well-architected views.
Preview instability is usually a symptom of tight coupling,
missing dependency injection, or views doing too much.

The path to stable previews is the same as the path to
maintainable, testable SwiftUI code.

I wrote a more detailed version of this with additional
patterns on my blog:
👉 Full article on idiots With iOS