Post not yet marked as solved
I was just referring to my background refresh code: getting JSON data from CloudKit, parsing, processing, etc. It's not a specific API that's timing out, it's that it appears that I'm timing out, since processing will just stop - and it's not while waiting on data, it's during processing of it. Surprisingly, the time elapsed is only a few seconds sometimes. I'm only able to tell from logging that the processing starts, stops for some reason (I've presumed this to be a timeout), and when the next silent push notification comes in, the processing picks back up right where it was suspended.
If it matters, I've tended to see this occur more - but not exclusively - on older devices (iPhone 6, 6s,...)
Had a separate exchange via Apple Feedback Assistant, and concluded part of this was user error with respect to file protection levels.
I had been using an NSPersistentContainer, with the defaults - i.e., FileProtection = completeUntilFirstUserAuthentication.
My mistake was in keying on UIApplication.shared.isProtectedDataAvailable, which - when the device is once authenticated but subsequently locked - is FALSE.
But in that case - if the device had once been authenticated - the NSPersistentContainer IS available.
It was my misinterpretation of when the file was available, separate from what isProtectedDataAvailable told me. So - it’s not a bug, though it would be useful if there was a way to tell - whether by notification or a property somewhere - if the device has been authenticated. I don't know that that is available from any APIs/properties.
Appears to have been fixed in a subsequent version. No issues in the release versions of iOS 14, watchOS 7
Still persists in iOS 14 beta 6, FYI
Incidentally, this is iOS 14 beta 4
Solution: use applicationWillResignActive/applicationDidBecomeActive to automatically pause/play the video or any active content that might be occluded by the injected TestFlight onboarding screens.
Post not yet marked as solved
Hi - I realize this was an old issue, but I'm seeing this myself now. The first fetch for a single record takes over 10s, but is subsequently much much MUCH faster. Did you ever find a reason/solution for this? Thanks
Post not yet marked as solved
FYI, I just ran this on hardware with iOS 12 beta 6, and there's improvement in that release (versus the beta 5 simulator in the latest Xcode).I now get OK, requested. SiriKit says: "<my parameterized response text>"
Post not yet marked as solved
I realize this post is over a year old, but I'm running into something similar. Did you )or anyone) find a fix for this?
Post not yet marked as solved
Hi - checking in to see if there was ever any progress on this issue?? I'm experiencing something similar, but not sure if it's exactly the same thing. I have a macOS app that uses CloudKit, and I want to be able to test it on another machine against the development CloudKit container. I'm exporting using Development (not Developer ID). This generates an .app file that works on my development machine, but cannot be deployed/tested elsewhere.Same thing?
No - I filed a bug with Apple, that is a duplicate of another, so they're evidently aware of it. I ultimately had to bail on the concept - my hangup was that I have a UITabViewController that has a UINavigationController for each tab, and they all are similar. It looked too weird to have one tab transition from Large to Small, and then switch to the next tab and get Large again. Not important enough of a feature to fight any further on, unfortunately.
So yes, it appears the magical - yet broken - combination is:In the storyboard, set "Large Title: Never" for the first view controller in the UINavigationController chainIn viewDidAppear, set "navigationItem.largeTitleDisplayMode = .always" for that same view controller.That first step seems odd, right? But I get the desired behavior throughout now...
Thanks so much for replying (...your post appeared while I was typing my previous post). But I'm playing with your code now. One thing I noticed, is you have largeTitleDisplayMode="never"in your storyboard for the "Hello 1234" navigation bar. That seems to make the difference - in terms of it collapsing properly. But I would have thought "Never" should have meant never ever EVER show the large title, right?? I have been setting it to "automatic".
So - more info on this. I have a sample app that I'll send to Apple:v1: UINavigationController: prefersLargeTitles=truev2: UITableViewController: Large Title = automatic in Storyboardv3: UIViewController containing a UICollectionView as a child viewv4: UIViewController (empty)Selecting a row in v2 pushes v3.Selecting a cell in v3 pushes v4.Scrolling up in either v2 or v3 does not collapse the large title.Scrolling up in v2, selecting the bottom row to push v3, and then hitting Back to v2: collapsed title FINALLY DOES show up in v2, only on the way back in. Scrolling up in v3, selecting the last cell to push v4, then hitting Back to v3: collapsed title MOMENTARILY shows up in v3, but it shifts immediately to the large title.Any other insights out there? Hopefully there will be progress in the next beta...
This does not work in Beta 5 either.Should it?
