App crash after update to IOS 18

It’s hard to say what’s going on here without more details. Please post a full Apple crash report. See Posting a Crash Report for advice on how to do that.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks for your reply, I login with my apple developer id, and please see the attached crash report. hoping to get your reply soon. thanks! Simonlll

Sadly, that crash report shows that you’re using a third-party crash reporter (see thread 8, frame 6) and that’s severely undermines my confidence in it. See Implementing Your Own Crash Reporter for an explanation as to why I don’t trust third-party crash reporters.

Are you able to reproduce this in your office? If so, try removing the third-party crash reporter and reproducing it again. Presuming it still crashes, post the resulting crash report.

If you’re not able to reproduce this, you have a decision to make: How wedded are you to this third-party crash reporter? If you can’t live without it, it’s going to be challenging to make progress on this crash. OTOH, if you’re not particularly wedded to it, I recommend that you ship an update to your app with it removed and then see what crash reports you get back.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi, Thanks for your reply, I have removed 3rd part crash report in the project and archived and reinstalled again. But I don't know why there are 3 reports, so I uploaded all of them.

Thanks for the Apple crash reports.

Looking at that first crash report, I see that it’s crashing due to an unhandled language exception. The Last Exception Backtrace section shows this:

Last Exception Backtrace:
0 CoreFoundation  … __exceptionPreprocess + 164
1 libobjc.A.dylib … objc_exception_throw + 87
2 Foundation      … -[NSFileManager createDirectoryAtURL:withIntermediateDirectories:attributes:error:] + 127
3 CFNetwork       … -[_NSHTTPAlternativeServicesStorage _onqueue_initializeDatabaseIfNotEmpty:] + 331

That’s an interesting crash. Frame 2 shows that the exception was thrown by -createDirectoryAtURL:…. The only likely explanation for that is that the incoming URL is nil. Which brings us to frame 3. The code for that looks something like this:

NSURL * lib = [NSFileManager.defaultManager URLsForDirectory:NSLibraryDirectory inDomains:NSUserDomainMask].firstObject;
NSURL * nested1 = [lib URLByAppendingPathComponent:name1 isDirectory:YES];
NSURL * nested2 = [nested1 URLByAppendingPathComponent:name2 isDirectory:YES];
[NSFileManager.defaultManager createDirectoryAtURL:nested2 withIntermediateDirectories:YES attributes:nil error:nil];

The only way that nested2 can be nil is if -URLsForDirectory:inDomains: returned @[] (or nil). It’s hard to see how that can happen if the app is behaving normally.

We’ve seen a few reports of problems like this before (r. 132595024) and our investigation suggests that this is caused by code within your app swizzling methods on NSFileManager. Swizzling methods in system classes is a bad idea, and something we most definitely don’t support [1].

I recommend that you first check to see if it’s your code that’s swizzling NSFileManager. If it is, please stop doing that.

However, I suspect that it’s not your code doing this, but some third-party library. You should look through the libraries you’re using to identify which one is doing this swizzling. Once you work that out, you can then raise this problem with its author.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] In this case it was broken by the significant implementation changes we made as part of this effort: What’s next for Foundation

If you were using Objective C and instantiating NSFileManager incorrectly(for example, alloc but no init), it would still work in earlier versions of iOS, but it will fail in iOS 18.

Hi, The problem is solved. Just as you said I found a third-party Framework which functioned as data collection. it's website explain the theory:By using the runtime characteristics of objective-c and the Method swizzle technology, the method implementation corresponding to the selector can be replaced at runtime to achieve the purpose of hooking the method. That is to say, after embedding the Keynote SDK, at the beginning of the program startup, the Keynote SDK will perform the swizzle operation on the corresponding method, so that when calling a swizzled function, the corresponding custom function of the SDK will be called first, and some data collection operations will be performed in the SDK function, and then the SDK function will be called back to the original function implementation, which will not affect the original program logic. I removed this framework, and app run smoothly in ios 18 now. Thanks for your help.