UserDefaults.standard.integer(forKey: ) crashes the app with EXC_BAD_ACCESS (code=1, address=0x0)

With the 27 OSes using UserDefaults.standard.integer(forKey: )

can cause a crash with

EXC_BAD_ACCESS (code=1, address=0x0)

It has been seen on a Multiplatform app, up to now tested on iOS/iPadOS and visionOS 27 Beta 1.

In our code we use UserDefaults.standard.integer(forKey: ) from a singleton called during the SwiftUI app init(), and we don't know yet if this is the only moment there is a crash as we can't go farther.

The API should return 0 if it can't get a value. There is no reason the app should crash if the API conforms to its contract.

Running the same code from Xcode on iOS 26 runs it without issue.

FeedBack FB23310748

Answered by lAppliEnRose in 895380022

I created a new post Xcode 26.5 can't run apps on visionOS 27 and iOS 27 Beta 2

The issue is not related to UserDefaults.standard.integer(forKey: ) but is related to launching from Xcode.

FeedBack FB23310748

In your bug report you included a UserDefaults27 project, but it wasn’t clear if that project was meant to reproduce the crash. What I can say is that when I run this project in my set up — Xcode 27.0b1 running on macOS 26.5 targeting an iPhone 17 running iOS 27.0b1 — it didn’t crash. Rather, I see this:

day: 0
day: 0
day: 0
day: 0
day: 0
day: 0
day: 0
day: 0
day: 0
day: 0

So, does the UserDefaults27 project crash in your environment?


Oh, and regardless of your answer to the above, please reproduce the crash, immediately grab a sysdiagnose log, and then attach that sysdiagnose log to your bug report. See Bug Reporting > Profiles and Logs for advice on how to do that.

Share and Enjoy

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

Hello Quinn, Yes the project UserDefaults27 was created especially to reproduce the issue we have in our app, but a with a short sample we could send. That's why there are only print() instead of the real logic and the update of the values back to UserDefaults.

The project crashed in our environment on visionOS, iOS and iPadOS 27 Beta 1 but not on an iPhone with iOS 26.5.

Today I have another issue with iOS and iPadOS which stop in the Xcode debugger, but not when launching the app. I have sent Sysdiagnoses of these. I can still reproduce on visionOS and I have also sent a Sysdiagnose.

Thank you very much, don't hesitate to ask if you need anything.

PS: It's an honour for me to have you working on this issue. I use your precious advice on this forum on OS X and macOS since about 15 years (perhaps less I don't remember precisely the first time I've read you). Your work is very useful. Thank you.

Yes the project UserDefaults27 was created especially to reproduce the issue we have in our app

Hmmm. In that case I’m not able to reproduce the problem. Here’s what I did specifically:

  1. On macOS 26.5, I launched Xcode 27.0b1.
  2. I opened your project.
  3. In Signing & Capabilities I selected my Team ID and change the bundle ID.
  4. I ran your app on an iPhone 17 running iOS 27.0b1.

It ran just fine, printing:

day: 0
day: 0
day: 0
day: 0
day: 0
day: 0
day: 0
day: 0
day: 0
day: 0

I took a look at your bug (FB23310748) and it seems that the Foundation team is having similar problems reproducing the issue.

I then downloaded the sysdiagnose logs from the bug and looked for crash reports from the UserDefaults27 app. I found a bunch, but none of them match your description of the issue. Specifically, they all crashed like this:

Exception Type:    EXC_CRASH (SIGABRT)
Exception Codes:   0x0000000000000000, 0x0000000000000000

with a crashing thread backtrace like this:

Thread 0 name:   Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0  libsystem_kernel.dylib … __abort_with_payload + 8
1  libsystem_kernel.dylib … abort_with_payload_wrapper_internal + 104
2  libsystem_kernel.dylib … abort_with_reason + 32
3  libobjc.A.dylib        … _objc_fatalv(unsigned long long, unsigned long long, char const*, char*) + 116
4  libobjc.A.dylib        … _objc_fatal(char const*, ...) + 32
5  libobjc.A.dylib        … objc_defaultForwardHandler(objc_object*, objc_selector*) + 104
6  libxpc.dylib           … _xpc_serializer_pack + 408
7  libxpc.dylib           … _xpc_pipe_pack_message + 188
8  libxpc.dylib           … _xpc_pipe_routine + 140
9  libxpc.dylib           … _xpc_interface_routine + 168
10 libxpc.dylib           … _xpc_init_pid_domain + 892
11 libxpc.dylib           … _xpc_early_init + 68
12 libxpc.dylib           … _xpc_init_service + 292
13 libxpc.dylib           … _libxpc_initializer + 1412
14 libSystem.B.dylib      … libSystem_initializer + 256
15 dyld                   … invocation function for block in dyld4::Loader::findAndRunAllInitializers(dyld4::Ru…
16 dyld                   … invocation function for block in dyld4::Loader::findAndRunAllInitializers(dyld4::Ru…
17 dyld                   … invocation function for block in mach_o::Image::forEachInitializer(void (unsigned i…
18 dyld                   … mach_o::Header::SegmentInfo mach_o::Header::parse_segment_command<true>(mach_o::Hea…
19 dyld                   … invocation function for block in mach_o::Header::forEachSection(void (mach_o::Heade…
20 dyld                   … mach_o::Header::forEachSection(void (mach_o::Header::SectionInfo const&, bool&) blo…
21 dyld                   … mach_o::Image::forEachInitializer(void (unsigned int) block_pointer) const + 244
22 dyld                   … dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const::$_0::operator…
23 dyld                   … dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const (.cold.3) + 80
24 dyld                   … dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const + 652
25 dyld                   … dyld4::JustInTimeLoader::runInitializers(dyld4::RuntimeState&) const + 36
26 dyld                   … dyld4::APIs::runAllInitializersForMain() + 100
27 dyld                   … dyld4::prepare(dyld4::APIs&, mach_o::UnsafeHeader const*) + 4424
28 dyld                   … dyld4::start(dyld4::KernelArgs*, void*, void*, unsigned long long)::$_1::operator()…
29 dyld                   … start + 6536

That’s an interesting crash, but it’s not the EXC_BAD_ACCESS you’re seeing.

Please reproduce the problem using the UserDefaults27 test app, grab an .ips crash report, and post it here. 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"

Accepted Answer

Hello Quinn, I do not yet test Xcode 27, I' m still using Xcode Version 26.5 (17F42). Regarding the sysdiagnoses, the one made on Vision Pro was exactly the issue described with EXC_BAD_ACCESS.

But as I said, without Xcode, launching directly on the devices works fine (I didn't notice at first). And now I have the crash you describe (instead of EXC_BAD_ACCESS) on iPhone and iPad with the 27 beta with the app launched from Xcode.

Searching for the new error message, I found a web page describing "Fixing OS_dispatch_mach_msg _setContext: unrecognized selector on iOS 27 by Mick MacCallum" wich is the new error I see.

He says

In Xcode, open Product > Scheme > Edit Scheme. Select the Run action in the sidebar, then open the Options tab. Find Queue Debugging and uncheck Enable backtrace recording.

This is what I did and now the project UserDefaults27 runs fine from Xcode.

To recap, this is not an error with UserDefaults on the 27 OSes. The error is in fact that running apps from Xcode Version 26.5 (17F42) crashes the app on iOS, iPadOS and visionOS 27 including Beta 2 (and perhaps other 27 OSes).

This could be very useful to know for other readers of this forum, as many could have the same issue.

Please, tell me what you want me to do with the feedback. Should I open a new one on Xcode, can you change its category. Please let me know.

Thank you very much.

I do not yet test Xcode 27, I'm still using Xcode Version 26.5 (17F42).

OK, lemme make sure I understand you correctly. You’re using Xcode 26 to build and run apps on iOS 27 beta?

Share and Enjoy

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

Yes you are right.

We develop on the production Xcode (currently 26.5), but we test on every Beta OS (currently 27 OSes Beta 2) to be sure the user experience will be fine when they will update their OS.

This also allows us to report feedbacks on new bugs on the future OS before it is out. And it has already been useful ;-)

Unfortunately we often don't have time to also test the next Xcode, resources are limited in statups and clients await features in the apps.

This issue is Xcode 26.5 can't run apps on iOS/iPadOS and visionOS Beta 2. Do you wan't me to close the feedback and open another one on Xcode?

I created a new post Xcode 26.5 can't run apps on visionOS 27 and iOS 27 Beta 2

The issue is not related to UserDefaults.standard.integer(forKey: ) but is related to launching from Xcode.

UserDefaults.standard.integer(forKey: ) crashes the app with EXC_BAD_ACCESS (code=1, address=0x0)
 
 
Q