You don't say what version of RN you're using. There's several issues people encountered when first using Xcode 15 https://github.com/facebook/react-native/issues/37748. https://stackoverflow.com/questions/77192195/react-native-0-71-8-build-failed-on-xcode-15

"Can we trust that this update will be executed on the defined schedule". Absolutely not, read the documentation more closely. It'll probably run, but you can't specify when, nor be sure it will. You can also just update it when the user loads the app? Surely it's not going to take hours to download, or even minutes, even if there's a lot of data. You can start a background thread when the user launches the app so it wouldn't hang the ui.

You have a major misunderstanding about compilation errors, if you had a compilation error then your app would not even run. A compilation error means there is a syntactical error in your code, and it is nothing to do with a run time error. You probably have an exception, in which case add code like this at the start of your app and then add a breakpoint to the logging line. The breakpoint will be hit when you run the app if that is the problem, then you can see the call stack. func registerExceptionHandler() { NSSetUncaughtExceptionHandler { (exception) in NSLog("‼️‼️ Uncaught exception (String(describing: exception.reason))") } } You can also extract a crash stack from the phone using Xcode

And here's another problem with notification service extensions is if it has the entitlement com.apple.developer.usernotifications.filtering then it can NEVER detect the light/dark mode because com.apple.developer.usernotifications.filtering ALWAYS returns light. This isn't the first time I've seen com.apple.developer.usernotifications.filtering interfere with things, this is now the 3rd bug I've found that only manifests when a NSE has this entitlement.

This is a developer forum, not an Apple user complaint forum. But maybe you have just got the Call on Other Devices feature turned on, which absolutely is turnoff able in iOS 17. I have 7 iPhones with iOS 17 with the same account, the call history is not synchonized on any of them.

What sort of problems are people having? If you have an error in what/how you are registering the numbers in the extension then that can manifest in users being able to initially turn on the extension in settings. If people have just downloaded your app for the first time then you presumably don't have content yet though? You said you attempted to reproduce in the simulator.This feature doesn't exist in the simulator. Are you therefore saying you released this without fist testing on hardware?

Make sure you don't have VPN enabled - VPN can radically affect in a bad way Xcode's ability to connect with, detect a phone, or accurately detect a phone's connected state. If ever you're in a situation where something like Apple Configurator can see a device and says its connected, but Xcode disagrees with this, then its probably VPN.

Is b1 a non-negative integer

There is an API to obtain the phone number(s) in the phone and whether a number is active or not. However it's a carrier api, this means Apple allows apps to use it provided they are developed by a carrier. Presumably you are not a carrier, therefore there is no way you can determine the phone number nor when a sim is changed.

Background tasks don't behave as you want it to, there's no such thing as deterministic background scheduling in iOS, it simply just does not exist. The time you specify to run is not an absolute time, it is an earliest possible time, totally not the same thing. The documentation says "The delay between the time you schedule a background task and when the system launches your app to run the task can be many hours." That does not go far enough in explanation, not only can it be many hours later than you specified, the OS may not run the task at all, there are no guarentees it will get run. If the user isn't regularly engaging with your app, then the OS will stop running the tasks. This question comes up time and time and time again, people want to know how to regularly perform a task at repeating deterministic internals in the background, well you cannot, iOS just does not provide the ability to do that.

I have one, it's fine for running Xcode and large projects. Though browsers/webpages can take up quite a lot of memory, which maybe can topple things over the edge sometimes if you have lots going on. Nobody can comment on the hard drive space and how much you might need, certainly enough for development, it's what else you're using the MacBook for that is relevant.

And a little more that couldn't fit in the original post Thread 0 crashed with ARM Thread State (64-bit): x0: 0xfffffffffffffffc x1: 0x0000000000000000 x2: 0x0000000000005d02 x3: 0x0000000000000000 x4: 0x0000000000000000 x5: 0x000000016bb30d20 x6: 0x0000000000000032 x7: 0x00000000000a0400 x8: 0x0000000000005d02 x9: 0x0000000000005d03 x10: 0x0000000000000200 x11: 0x0000000000000003 x12: 0x0000000000000003 x13: 0x00000000001ff800 x14: 0x00000000000007fb x15: 0x00000000b620b829 x16: 0x0000000000000203 x17: 0x00000001f63c25e0 x18: 0x0000000000000000 x19: 0x0000000000000103 x20: 0x0000000000000000 x21: 0x00000001f4c74048 x22: 0x0000000001000002 x23: 0x0000000000005d02 x24: 0x0000000000000000 x25: 0x00000000ffffffff x26: 0x0000000000000103 x27: 0x000000019858f17c x28: 0x000000016bb31128 fp: 0x000000016bb30dc0 lr: 0x00000001fe05efb0 sp: 0x000000016bb30d80 pc: 0x00000001dd27b7dc cpsr: 0x40001000 far: 0x0000000b9c861208 esr: 0x56000080 Address size fault

@eskimo People running React Native can't turn off Wifi on the iPhone. Metro, a fundamentally integral and important part of running/debugging React Native applications, needs Wifi enabled when connected via Cable in order to function.

@Polyphonic Here's a code example illustrating what I mean. In the code below, which of the Cocoalumberjack lines that get logged can be controlled by what level is set in DDLog.add(consoleLogger, with: .warning), if this code is run only two lines of CocoaLumberjack output will be displayed, this can be increased or decreased by changing what is pass to DDLog.add(). My question, is is there an equivalent for the iOS native logging? let consoleLogger = DDOSLogger.sharedInstance DDLog.add(consoleLogger, with: .warning) NSLog("NSLog Cocoalumberjack:") DDLogVerbose( DDLogVerbose") DDLogInfo("DDLogInfo") DDLogDebug("DDLogDebug") DDLogWarn("DDLogWarn") DDLogError("DDLogError") if #available(iOS 14.0, *) { NSLog("NSLog Native:") let defaultLog = Logger() defaultLog.trace("Logger TRACE") defaultLog.info("Logger INFO") defaultLog.debug("Logger DEBUG") defaultLog.notice("Logger NOTICE") defaultLog.warning("Logger WARNING") defaultLog.error("Logger ERROR") }

@Polyphonic what I mean is having the ability to turn on or off certain levels of logging without have to change the code or a setting and recompile and run again. i.e. suppose the app is released on the App Store and consequently it has verbose logging turned off. But if a user reports a bug customer support could instruct them to long press in a support screen for example and that has the effect of turning on verbose logging for say 24 hours and customer support could instruct the user to recreate the issue. There are various libraries that can capture the console output and can send it off for analysis. The iOS native equivalent of Cocoalumberjack's DDLogLevel.setLevel(level). I know I could implement a mechanism like this by building in if statements etc., but it would be cleaner and easier if there's some native functionality that will just do it with a single line change. CocoaLumberjack logging can be directed to the console and be affected by the set level, but it's a bit funky and I'd like to explore using iOS native logging instead. (CocoaLumberjack logging can also be directed to a file, so verbose logging could be piped there and that file sent when the user contacts customer support, but I'm looking at all angles.) P.S. I'm seeing this line appearing often in the console "Shutting down live logging", would you happen to know what that means and its cause? Cheers