Post not yet marked as solved
Installing the app has become worse.
It'll be fine one minutes, will install and run quickly, and then next go it'll take about 10 minutes. It knows its taking a long because it says its taking longer than usual and do you want to proceed? If you say yes, you still have 10 or more minutes to wait.
Once its started doing this I've not found any way of making it right again other than to restart the Mac and the phone. The problem is, whenever you restart a phone, then you then have to wait 5 minutes while Xcode says "Preparing the iPhone", even if its already prepared it a trillion times before.
So you can't win.
Post not yet marked as solved
I'm going to have to raise an official Apple support ticket, my MacBooks been out of action all day long because of this.
Post not yet marked as solved
Thanks @BornP for answering and making some suggestions, more than any of the Apple folks have done.
Unfortunately none of these do anything to rectify the issue. Once again I'm unable to do anything, things were going fine one minute, then the next Xcode threw one of these episodes. I have 6 iPhones and its stopped working with all of them, that was several hours ago and since then just cannot install/run the app at all (same app as was working just before, no changed made).
I also have 3 Macs and have observed this on all 3 of them. The one thing they all have in common is they all have Xcode 15 on them. None of these issues started until I started using Xcode 15 beta, its been present in every Xcode 15 beta and every Xcode 15 release version, including 15.2.
Post marked as Apple Recommended
My (company supplied) MacBook has lots of software on it for data security type things i.e. like detecting the browsers are not connecting to malicious web sites etc.
One of them is called Forecepoint, I've long suspected it of causing lots of hassles with internet usage.
Could software of this type interfere with Xcode/the virtual network when an iPhone is connected via USB causing connection and slowness issues?
@eskimo
Post not yet marked as solved
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
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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
Post marked as Apple Recommended
@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.
Post not yet marked as solved
@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")
}
Post not yet marked as solved
@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
Post not yet marked as solved
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
Post not yet marked as solved
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.
Post not yet marked as solved
@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?
