I am using CloudKit in my iOS 9 app and I have a CKQueryOperation that work fine and performs as expected when plugged into the Mac. As soon as the query is run when it is not plugged in to the Mac, it does not finish. There is no error message, the activity indicator I added never stops and the results are never displayed.
If I start the operation when unplugged, then plug it in it completes too.
The code was copied and adapted from an app built in Xcode 6.4 and works as expected in that app.
Any ideas why this could be happening? Could it be anything to do with app thinning in iOS 9?
Thank you
ANSWER
Adding this fixed the issue:
queryOperation.qualityOfService = NSQualityOfService.UserInitiated
The default QoS changed in iOS 9. If the query operation is user initiated, then it needs to be marked as such.
See CKOperation.h and the QualityOfService property.
Related
After upgrading to iOS 14.5 I've noticed a strange behavior in my implementation of CXCallDirectoryProvider. I call a CXCallDirectoryManager.sharedInstance.getEnabledStatusForExtension(withIdentifier: identifier) when the app starts in sceneWillEnterForeground. On a new iOS version first call to CXCallDirectoryManager.sharedInstance.getEnabledStatusForExtension(withIdentifier: identifier) after the app has started consistently results in a long wait and a subsequent error com.apple.CallKit.error.calldirectorymanager Code=1 "(null)". All subsequent requests to the same method, however, execute normally, as they should.
This errorneous behavior is consistent on a new iOS 14.5 version. I've tried multiple iPhones. I'm sure that the extension identifier is valid because subsequent requests do execute normally and issues do not reproduce on any previous versions. Did someone stumble upon a similar issue?
I just noticed that after having updated Xcode to version 10.2.1, I'm unable to see the permission request for Library and Apple Music when launching a couple of projects of mine on the simulator.
Debugging, I realised that the authorization request call goes unanswered
MPMediaLibrary.requestAuthorization { status in
// switch on status and handle it - never gets there
}
I didn't change anything in the code or configuration of my projects, and I'm very sure that this wasn't happening with previous versions of Xcode.
Just for the record, everything works fine on a real device.
Does anybody have any idea?
Am I the only one who's experiencing this?
Looks like it doesn't work on the simulator. It now just hangs, and the closure is never executed.
It did, at one time, but I guess that it no longer does.
Sort of unsurprising, as the basic media capabilities aren't really supported on the simulator anyway.
I have tested my code on device, and verified that it works, but it is annoying (not a showstopper) that it doesn't work on the simulator.
NOTE: I have seen many other posts on Stack Overflow about NSUserDefaults being renamed to UserDefaults in Swift or not working on simulator until a restart. This is not a duplicate by anyway. Many of the questions SO is tagging against is from 4 years ago. My question is specific to iOS 10 from this year as this has always worked in older versions. I have mentioned in my question already that my question is not a duplicate of those questions as those were simulator bugs in swift and my issue is on device objective C bug. Please read the questions before marking as duplicate
My issue is different as I am able to reproduce this on objective C and on physical device itself.
I created a brand new project from scratch for this test. I placed this code in the viewDidLoad of a view controller:
if (![[NSUserDefaults standardUserDefaults] valueForKey:#"checkIfInitialized"]){
NSLog(#"setting checkIfInitialized as not exist");
[[NSUserDefaults standardUserDefaults] setValue:#"test" forKey:#"checkIfInitialized"];
[[NSUserDefaults standardUserDefaults] synchronize];
self.view.backgroundColor=[UIColor redColor];
self.mylabel.text=#"NSUserDefaults was NOT there, try running again";
} else {
NSLog(#"checkIfInitialized exists already");
self.view.backgroundColor=[UIColor blueColor];
self.mylabel.text=#"NSUserDefaults was already there this time, try running again";
}
Now if I run the app about 10 times, few times it finds the checkIfInitialized and sometimes it doesn't. No exact number on how many times it fails as it might work 3 times then fail next 2 times then work 4 times and fail once and so on.
Now something I have noticed (not 100% sure though) that the issue only seems to happen when I am testing connected via Xcode. If I run by launching the app by clicking the app icon on device without Xcode, then it seems to work fine but I can't be 100% sure.
I noticed this error occur sometimes:
[User Defaults] Failed to write value for key checkIfInitialized in CFPrefsPlistSource<0x1700f7200> (Domain: com.xxxx.appname, User: kCFPreferencesCurrentUser, ByHost: No, Container: (null)): Path not accessible, switching to read-only
I have this very simple project on my dropbox if you want to test it out.
I would suggest testing about 10-15 times to reproduce this issue.
https://www.dropbox.com/s/j7vbgl6e15s57ix/nsuserdefaultbug.zip?dl=0
This works completely fine on iOS 9 so definitely something to do with iOS 10.
EDIT
Bug logged: 28287988
Response from apple DTS team:
First off, you should first determine whether standardUserDefaults or
valueForKey is failing. My guess is that “standardUserDefaults” is
returning NULL and, if that’s the case, then that’s something you
should be guarding against generally. Notably, standardUserDefaults
will return NULL if the preference file is encrypted in the
environment the app is currently running in (for example, preferences
is set to “NSFileProtectionComplete” and the app is running in the
background). That shouldn’t be an issue for standard foreground-only
apps, but it’s something to be aware of anyway.
It’s very likely that Xcode is actually inducing the problem here.
Xcode vastly complicates the app launching environment in a way that’s
VERY different than a standard app launch. My guess is that this is
basically being triggered by Xcode’s timing inducing an an expected
situation during the app launch, but if you want a more formal test of
that try setting a single breakpoint in applicationDidFinishLaunching
and continuing in the debugger as soon as you hit it. My guess is
just adding that disrupts the timing enough to stop the problem from
happening. Sort of. It’s iOS 10 only in the sense that iOS 9 will
never print that log message, but that’s because the log message was
added in iOS 10. The code itself is similar enough to iOS 9.3 that I
suspect exactly the same behavior is (at least in theory) possible in
iOS 9.
Yes, this is definitely a reproducible bug.
It happens with the GM release of Xcode 8 and iOS 10.
It is not the linked question referring to Swift.
It is not the linked question referring to beta versions of the Simulator.
The bug happens on devices and on the Simulator. It is intermittent: saving will work six times and then fail. Unlike you, I did not get the "failed to write key" message.
The bug also occurs when operating directly on the device without Xcode. This is in fact how I discovered it.
You should report a bug to Apple, especially since you have a short program that will reproduce it. I will do the same.
One key difference: In my case the failure is in writing the default. The previously written value remains in NSUserDefaults. Sometimes one key is successfully written while another is unchanged.
A similarly very intelligent DTS response from my own support request. Basically, killing using Xcode is more murderous than anything that would naturally happen on the device (even the double-Home-click-and-upswipe method) and since everything is abruptly crashed when Xcode halts it, the lazy writing of NSUserDefaults can fail, or be only half completed.
And indeed, pure on-device testing of the app, without Xcode involved, shows that everything does get correctly written to NSUserDefaults when the app is terminated.
I have closed my own bug report.
I've got an AppleWatch app that is working fine in Simulator and Device, but when I call openParentApplication, it appears that the parent app is crashing immediately because I see this in the console output:
The UIApplicationDelegate in the iPhone App never called reply()...
When I try to manually launch the parent iOS app in the Simulator it crashes there too immediately. I don't have time to attach the debugger (which is already attached to the AppleWatch app) to see what is crashing it. Note that the parent app runs fine when the AppleWatch is running and I'm using a real iPhone. I can also run the app fine on the Simulator when not debugging the AppleWatch app.
I've tried resetting the Simulator, but problem persists.
I'm just not sure how to debug this. Any help is appreciated.
Start an explicit background task in handleWatchKitRequest. Otherwise, your app gets killed before it reaches reply().
Refer to this post for a code example on how to create a background task.
In turns out that after commenting out all code in the parent app's didFinishLaunching and stripping almost all code out of the watch extension, the problem was indeed at a lower level.
The Simulator has a
Debug | Open System Log...
menu option that showed the crash logs, which contained:
Dyld Error Message: Library not loaded:
#rpath/MyCore.framework/MyCore Referenced from:
/Users/me/Library/Developer/CoreSimulator/Devices/A2061705-DDDF-477C-9AAA-E50GG43A6350/data/Containers/Bundle/Application/DEB7FB25-8233-4B9F-8DAB-9FF8AE42BF33/MyApp.app/MyApp
Reason: no suitable image found. Did find:
/Users/me/Library/Developer/CoreSimulator/Devices/A2061705-DDDF-477C-9AAA-E50FF43A6350/data/Containers/Bundle/Application/DEB7FB25-8553-4B9F-8DAB-9FF8AE95BF33/MyApp.app/Frameworks/MyCore.framework/MyCore:
mach-o, but wrong architecture
My Swift app has a few dependent Swift projects that are used by the app and extension. Getting the Swift frameworks to link has been a major pain. I've included the dependent frameworks (compiled in the same workspace) as embedded binaries. This works when running on the device, or on the Simulator, but not when running in this hybrid watch app + parent app Simulator context.
I changed the embedded binary references to point to the frameworks under ...DerivedData...Debug-iphonesimulator, as opposed to ...DerivedData...Debug-iphoneos, and the problem went away.
Still hoping the Swift framework story will improve.
Are you seeing an actual crash? That message has appeared for me plenty of times without the host app crashing.
99% of the time, that error appears because developers aren't opening a background task to complete their work in handleWatchKitRequest. Without the background task, the OS kills your app in the background before it has a chance to reply.
I've got an app that crashes even before the debugger can connect.
I placed a break point on the first line of main(). (I added an NSLog statement as very first statement in main() and set the break point there.
The app seems to start. The main screen with some ui elements becomes visible on the screen. Then it disappears.
There is no crash log found on the devices.
Xcode message:
Could not launch "appname"
process launch failed: failed to get the task for process xyz
Debugging is enabled of course.
The same for the profiler Instruments.
Code signing works fine so that the app can be deployed to the devices.
(Same for enterprise distribution. And the app validates for store submission.)
It does work on the simulator though.
The app used to work fine. I was just about to build it for the store. For final tests on iOS 8.1 I upgraded to Xcode 6.1 with SDK 8.1. But the problem did not occur directly after the upgrade. It worked just fine.
Then it crashed when building for release for enterprise distribution.
The AppStore build crashed in the same manner (according to Apple, the app was rejected of course.)
But it ran nicely in debug modes.
Now I was trying whether compiler options for optimization may make all the difference and I was trying to build in release mode with debugging enabled etc and end up with a debug build crashing as well. (No optimization in debug).
So it may well be that the migration to Xcode 6.1 did cause it but the problem may have come effective only after Xcode cleaned and rebuild the project in response to changes to compiler settings for code optimization.
Sorry for the long text. I tried to put everything in that may be of importance.
Reason is most likely some incompatibility of Crackify and iOS 8.1.
Therefore it may be of interest for others, altough my problem along with these symptoms may be very special.
Very early within AppDelegate didFinishLaunchingWithOptions we have had the following statement.
if ([Crackify isCracked] || [self isCertificateUnvalid])
exit(173);
That, as such, is not really well designed. The app is just terminated rather than any error message displayed to the user. Thus, it appears as if the app has crashed. But it has not crashed and therefore no crashlog is provided.
For reasons which I don't yet understand and which may not be related to this error, my debugger did not manage to hook up into the executed app. Once that was overcome (suddenly the debugger worked without any changes made to any of the debugging related settings) the error was found rather quickly.
This is Crackify: https://github.com/itruf/crackify
Within Crackify it was this code sniplet that caused the problem:
static NSString *str2 = #"ResourceRules.plist";
BOOL fileExists3 = [manager fileExistsAtPath:([NSString stringWithFormat:#"%#/%#", bundlePath, str2])];
if (!fileExists3) {
return YES;
}
For reasons that I did not further investigate, the file, that is tested here, apparently does not exist in iOS 8.1 any more.