Hi, I'm working on a trip detection and recording app that relies on CLLiveLocationUpdates for the location tracking. We've observed a recurring issue where trip recording eventually stops working if the app is not opened for an extended period of time (approximately 2–3 weeks). What we observe The app continues to be installed on the device. The user does not manually open the app during this period. Eventually, trip detection and recording stop. Location diagnostics indicate: Service Session Required At this point, CLLiveLocationUpdates no longer appears to deliver location events. Recovery attempts We've tried several ways to recover without launching the app: Turning Location Services off/on Rebooting the device Changing location permissions None of these restore location updates. The only reliable recovery method we've found is: Open the app manually. Leave it running for some time. Kill the app again. After doing this, location tracking resumes and works normally for 4-5 days before eventually failing again with the same "Service Session Required" diagnostic. Questions Why would a valid location setup eventually transition into a "Service Session Required" state after the app has not been launched for several weeks? Are there any documented conditions under which an existing CLServiceSession expires, becomes invalid, or requires recreation? Is there a recommended way to recover from this state programmatically without requiring the user to manually launch the app? Is this expected behavior or a potential issue with CLLiveLocationUpdates / CLServiceSession? Additional details iOS version: 26 App uses: CLLiveLocationUpdates, Beacon Ranging & Beacon Monitoring, SLC updates, Motion Activity Updates Background location enabled: Yes Authorization type: Always Device models tested: iPhone 14 Pro Max Service session creation code: private var serviceSession: CLServiceSession? serviceSession = CLServiceSession( authorization: .always, fullAccuracyPurposeKey: "Trip" ) Has anyone else encountered a similar issue after long periods where the app is not launched? Thanks.

Hi, I am creating a Driving Behaviour Monitoring app in which I range beacons and I require location updates in foreground, background and in terminated state all the time. I am using CLServiceSession with "Always Authorisation" to get location events. I create CLServiceSession object in the foreground and start monitoring driving and then re-create it when the app is relaunched after termination. Doing this works fine. But sometimes when app is terminated and is not opened again, the app runs on its own even when the device is stationary ( I can see the app is using Location in the Control Centre) and after that Location updates are not received and I am not able to track the driving behaviour. I tried to add diagnostics to know the cause and found "Insufficiently In Use" and then "Service Session Required" in the diagnostics. It would be of great help if the proper usage of CLServiceSession is provided. Important Question: When does the CLServiceSession gets invalidated or destroyed that was created when the app was in foreground ? What happens to the CLServiceSession which was created in the foreground if the app is not opened for long duration, let's say a day or two?

We’re planning to distribute our app outside of TestFlight because our testing period is expected to exceed the 90-day limit. Since we have an Apple Developer account, we’re considering using either Ad Hoc distribution or direct installation (debug/development builds) for longer-term testing. I have a few questions regarding this approach: Ad Hoc Distribution Validity What is the effective validity period of an Ad Hoc build? We’re aiming for long-term testing (4-5 months) and would like to avoid unexpected expiration—are there any constraints we should be aware of? Development/Debug Build Expiry & Limitations If we distribute the app using a development (debug) build via provisioning profiles, what is the expiration timeline? Are there practical limitations (e.g., device limits, performance differences, or provisioning renewal requirements) that could impact extended testing? Potential Complications & Best Practices Are there any issues we should anticipate when using these distribution methods for long-term testing? For example: Provisioning profile or certificate expiration Device registration limits Any policy or compliance considerations with Apple We’d appreciate any guidance or best practices for managing long-term testing outside of TestFlight while staying within Apple’s guidelines.

We are planning to distribute our app outside of TestFlight because our testing period exceeds the 90-day limit. Since we have an Apple Developer account, we are considering using Unlisted App Distribution for long-term testing. I have a few questions regarding this approach: After completing testing via Unlisted Distribution, is it possible to switch the same app to a public App Store release, or would we need to create and submit a separate app for public distribution? If a separate app is required, are there any restrictions from Apple on releasing essentially the same app under a different bundle identifier through another distribution channel? (Additionally, once testing is finalised, we plan to discontinue the Unlisted App version.) Are there any potential complications or limitations we should anticipate (e.g., app review concerns, versioning, or policy compliance) related to this matter? Any guidance or best practices in this matter would be greatly appreciated.

I am using Significant Location Change (SLC) monitoring to relaunch my app after it has been terminated. I have implemented SLC in two separate apps installed on the same device, and I would like to understand how the system delivers SLC events in this scenario. Specifically: Will both apps receive the SLC event at the same time, or can there be differences in the timing of delivery? If there are differences, what factors influence when each app receives the event? What criteria or system conditions determine how and when SLC events are delivered to different apps on the same device? Any clarification on the event delivery behavior would be greatly appreciated.

Hi, We are using beacon ranging methods to detect beacon in foreground and background in our app. We are using beacon's UUID, major and minor values to create a beacon region and then calling locationManager.startRangingBeacons to range beacons. We listen for beacon updates via the didRangeBeacons delegate method to get beacon data emitted. However, we've observed some inconsistent behavior: The beacon region frequently reports exit events even when the device is within close proximity (approximately 1.5 to 2 meters). There are instances where no beacon updates are received for extended periods (up to 15–20 minutes), despite the beacon being nearby. Generally, The distance between the device and the beacon is approximately 1.5 - 2 meters. What could be the reason for this behaviour and how can we avoid it and continuously receive beacon updates when the beacon is near without any delay? Thanks