Great question—this is a common pain point when building location-aware iOS apps, especially since the significant-change location service is intentionally throttled (it relies on cell tower handoffs) to prioritize battery life, which is why you’re seeing infrequent updates.

Let’s break down the only feasible, App Store-compliant ways to get near-high-frequency location updates when your app is terminated (not foreground/background):

1. Background Location Updates with "Always" Authorization #

This is the primary approach for apps that genuinely need continuous location tracking (e.g., navigation, fleet management, fitness apps with live tracking). Here’s how to implement it:

• Authorization: You must request the Always location authorization (not just "When In Use"). This requires adding both NSLocationAlwaysAndWhenInUseUsageDescription and NSLocationWhenInUseUsageDescription to your Info.plist, with clear, specific language explaining why you need persistent location access.
• Background Mode: Enable the Location updates background capability in your Xcode project (under Signing & Capabilities > Background Modes).
• Handle Termination Wakeups: When iOS wakes your terminated app to deliver a location update, it will launch your app into the background. You need to:
  1. In AppDelegate.application(_:didFinishLaunchingWithOptions:), check if the launch was triggered by a location event using launchOptions?[.location].
  2. If yes, immediately initialize your CLLocationManager instance, set its delegate, and call startUpdatingLocation.
• Optimize for Consistency: Use a reasonable accuracy level (e.g., kCLLocationAccuracyHundredMeters if you don’t need centimeter-level precision) to balance update frequency and battery life. For navigation use cases, kCLLocationAccuracyBestForNavigation is acceptable.

Critical Notes: #

• iOS will still throttle updates if the device is stationary for an extended period, or if Low Power Mode is enabled. There’s no way to force 100% continuous high-frequency updates (Apple enforces this to protect battery).
• Your use case must be legitimate. Apple will reject apps that request Always authorization without a clear, user-facing need for persistent location tracking.

2. Motion Activity Triggers (Auxiliary) #

If you only need high-frequency updates when the user is actively moving (e.g., walking, driving), you can combine Core Motion’s activity tracking with location services:

• Enable the Motion & Fitness capability and request authorization.
• Use CMMotionActivityManager to detect when the user starts moving. When an activity change is detected (even in terminated state), iOS will wake your app, allowing you to start high-frequency location updates temporarily.
• This is a great way to conserve battery by only activating location services when necessary, rather than running them nonstop.

Why Significant-Change Isn’t Working for You #

As you noted, the significant-change service only updates when the device switches cell towers (typically every 500+ meters in urban areas, or much farther in rural areas). It’s designed for low-battery, low-frequency use cases (e.g., check-ins, geofencing triggers)—it’s never intended for high-frequency tracking.

Final Best Practices #

• Minimize Battery Impact: Only request the accuracy level you truly need, and stop location updates as soon as they’re no longer required.
• Test Thoroughly: iOS’s location throttling behavior can vary based on device model, iOS version, and user settings. Test on real devices (not simulators) to validate update frequency.
• Be Transparent: Clearly communicate to users why you need persistent location access, and give them control over when tracking is active.

内容的提问来源于stack exchange，提问作者Mahesh