I am using CLServiceSession(authorization: .always) to start a service session for tracking Zone entry and exit in the background in my app. It has been working fine on iOS 18 until recently when we added some BGProcessingTasks. The task runs when the user is not moving and the device is on charge, this task runs fro a bit in the background, however we are seeing that even though we are reinitializing then session upon app launch. We have even tried to just explicitly reinitialize a session within the background task callback, but the zone tracking still continues to fail. Significant location changes are unaffected. Timeline of events: User Opens App, CLServiceSession(authorization: .always) is called (assume permissions have already been granted.) App is backgrounded User moves outside zone and app captures the data correctly (this can happen any amount of times) User plugs in Phone BGProcessingTask callback is run, it may or may not be terminated early. The service session is recreated as the first action in the callback. (we have also tried putting it in the main init() function for the app, same outcome) User moves outside zone later and app does NOT capture the data. User is sad :( The session seems to be reinitialized correctly when the app is launched due to CoreLocation updates. Is this expected behaviour or a bug? Is there a good way to debug what is happening with the sessions? Unfortunately, the WWDC sessions on this have not enlightened us about the cause of this behaviour.

I have a requirement to get all records changed after a certain date. I have set modifiedTimestamp as Queryable, but when I attempt to do any query at all using the following operators: > < >= <= no results are returned. I have confirmed there are records that should be returned. The only operator that works is == and !=. I have tried the following: NSPredicate(format: "modificationDate > %@", lastFetched as NSDate) NSPredicate(format: "___modTime > %@", lastFetched as NSDate)

I have been using the basic NSPersistentContainer with 100k+ records for a while now with no issues. The database size can fluctuate a bit but on average it takes up about 22mb on device. When I switch the container to NSPersistentCloudKitContainer, I see a massive increase in size to ~150mb initially. As the sync engine uploads records to iCloud it has ballooned to over 600mb on device. On top of that, the user's iCloud usage in settings reports that it takes up 1.7gb in the cloud. I understand new tables are added and history tracking is enabled but the size increase seems a bit drastic. I'm not sure how we got from 22mb to 1.7gb with the exact same data. A few other things that are important to note: I import all the 100k+ records at once when testing the different containers. At the time of the initial import there is only 1 relation (an import group record) that all the records are attached to. I save the background context only once after all the records and the import group have been made and added to the context. After the initial import, some of these records may have a few new relations added to them over time. I suppose this could be causing some of the size increase, but its only about 20,000 records that are updated. None of the records include files/ large binary data. Most of the attributes are encrypted. I'm syncing to the dev iCloud environment. When I do make a change to a single attribute in a record, CloudKit reports that every attribute has been modified (not sure if this is normal or not ) Also, When syncing to a new device, the sync can take hours - days. I'm guessing it's having to sync both the new records and the changes, but it exponentially gets slower as more records are downloaded. The console will show syncing activity, but new records are being added at a slower rate as more records are added. After about 50k records, it grinds to a halt and while the console still shows sync activity, only about 100 records are added every hour. All this to say i'm very confused where these issues are coming from. I'm sure its a combination of how i've setup my code and the vast record count, record history, etc. If anyone has any ideas it would be much appreciated.

While updating my app for iOS 18 I have run into some major issues with how CLMonitor and visit tracking are handled in the background. I have implemented the new CLServiceSession (i think) correctly. In my @main App struct's init method I call CLServiceSession(authorization: .always) to create a session. This is done in the foreground when the app is launched and also in the background. From what i understand this is the intended way to create a session as when the app is relaunched by the system the existing session is terminated a few moments later. What im seeing in iOS 18 vs iOS 17 is drastically less location updates being delivered to the app. i see around the same significant updates being delivered (around 1 per mile - 5 miles) but the CLMonitor.CircularGeographicConditions are being triggered at about 1 per 1 to 2 minutes regardless of the radius. When a zone is left the condition is removed in the background and a new condition is created at the next place it should be tracking. For visit tracking, it only reports a visit correctly about 10% of the time. my guess is the app is getting suspended and/or terminated and the CLServiceSession isn't correctly being reinitialized (or something completely different, i'm really not sure at this point) I would love some guidance as to the correct way to handle these updates in iOS 18. It is unclear if these are intentional limitations imposed in iOS 18, incorrect implementation on my part, or a bug in the betas. Note: startUpdatingLocation is not appropriate for this app as it is way too power hungry.

Our test devices running the Dev Beta 1 for iOS 18 no longer recieve updates from the CLMonitor async stream (for try await event in await monitor.events) when the app is in the background and suspended. This works fine in iOS 17. I only have one CLMonitor.CircularGeographicCondition active at any given time, they switch out dynamically in the background based on the user's location. Another thing is that visit tracking and significant location changes continue to work as expected in the background. I have submitted feedback (FB13883553) but I'm curious if this is an undocumented policy change or a bug.