@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

I've got 16GB Mac Book pro 2021. All I'm running is Outlook and Teams and Xcode 15.8 Beta and recently I've been getting messages saying I've run out of application memory. Never had this problem before, including with the 15.1 to 15.7 betas, its only the very latest Xcode that has started causing this. Turning off Outlook and Teams in order to free up a little more memory is just totally unfeasible as it means one if disconnected from work contact.

Look at the section "Detecting the originating widget" here https://developer.apple.com/documentation/widgetkit/linking-to-specific-app-scenes-from-your-widget-or-live-activity

Try it and examine the launch options in didFinishLaunchingWithOptions to see if there's anything there. If not then if you widget gets the chance to, then it could write a flag to group defaults which the app reads on launch.

There are very often crashes that only appear on hardware that don't appear on the simulator. Or crashes that only appear on release builds of hardware that don't appear on debug builds of hardware. To have released something for App Store review when you have not even run it on hardware is a very very risky dangerous thing to do, and now you are discovering why.

I don't understand. You just find it (in the Applications folder, if that's where its installed), then drag and drop to the trash can or right click and move to trash, same as any app. What's the problem you are encountering? After deleting 14.3, you should rename the XCode-beta app to Xcode

My Objective-C code all runs just fine with Xcode 15. Objective-C is still supported with Xcode. What does "doesn't work" mean specifically.

The entitlement is added to the entitlements file as: However it will only work if the entitlement is within the provisioning profiles for the app. You have to apply to Apple and request the entitlement, if they grant it then it will get added to your profile. Have you requested it from Apple? You don't specify in the entitlements file what pushes you want filtered, you do that at run time in your notification service extension, you examine the push payload and then decide if you want the notification displayed to the user or not.

DispatchQueue.main.async is, as it says in its name, asynchronous. Therefore your code is not executing in a linear line-by-line manner. You think the code is being executed in this order don't you: 1) DispatchQueue.main.async { 2) self.stillLoading = true } 3) print(stillLoading) It is NOT the case the line 2 is guaranteed to execute before line 3. Because line 1 is asynchronous, after 1 has executed, then control will jump to line 3 and meanwhile line 2 is dispatched to execute in parallel.

What does this question even mean? What architectures are you talking about?

Have you tried relaunching Xcode? That worked for me, it says it downloading but actually it isn't, relaunching and trying again display a progress bar

So I deleted Xcode and re-installed it, and also used a different phone, the result is the exact same thing - Xcode says "Installing app" forever, literally forever. Its unusable.

UPDATE: after updating from iOS 16.6 to 17 beta 5, its started working as expected again. Hence the assumption this is a 16.6 bug

@DTS Engineer "It will reset itself every ~24 hours but you can also reset it "manually" by either restarting the device or deleting and reinstalling the app." (on iOS 16.6) neither deleting and then re-installing the app, nor restarting the phone, resets the "Application will not be launched because it failed to report an incoming call too many times". Is there any other way to reset this (during development) other than wait 24 hours?