Any progress on this? None of the workaround really seem feasible for me, and more and more users are on iPhone X sized/viewport-fit=cover devices.

We believe that this issue has been resolved through updates to the documentation.

Verificatin URL: https://developer.apple.com/documentation/uikit/uicontrol/1618259-addtarget

Please let us know whether the issue is resolved for you by updating your bug report.

Engineering has determined that your bug report (46959771) is a duplicate of 42114000 and will be closed.

The following code will swap the problematic dealloc method for one that does nothing. It will leak a little, but it's better than crashing ;)

import

@import WebKit;

• (void)RM_WKNavigation_dealloc_swizzleFix { Class class = [WKNavigation class];

  SEL originalSelector = NSSelectorFromString(@"dealloc"); SEL swizzledSelector = @selector(RM_WKNavigation_dealloc);

  Method originalMethod = class_getInstanceMethod(class, originalSelector); Method swizzledMethod = class_getInstanceMethod([self class], swizzledSelector);

  BOOL didAddMethod = class_addMethod(class, originalSelector, method_getImplementation(swizzledMethod), method_getTypeEncoding(swizzledMethod));

  if (didAddMethod) { class_replaceMethod(class, swizzledSelector, method_getImplementation(originalMethod), method_getTypeEncoding(originalMethod)); } else { method_exchangeImplementations(originalMethod, swizzledMethod); } }

• (void)RM_WKNavigation_dealloc {

}

I'm experiencing the exact same issue with my app.

Based on the fact that so far SourceTree was the only application I would say that they are using this bug as a scapegoat.

They even closed their own issue as resolved as https://jira.atlassian.com/browse/SRCTREE-4196

Find leaks in _StringGuts.withMutableStorage. This is any concatenation of String, or String's UnicodeScalarView. I see this issue in own project when variable string has append another part, and PMJSON project when parse and concatenate characters to UnicodeScalarView of String

`+0xb6 movq %rax, %rdi +0xb9 testq %rdx, %rdx +0xbc jne "specialized _StringGuts.withMutableStorage<A, B>(of:unusedCapacity:_:)+0xc5" << IN THIS FUNCTION WE CAN SEE LEAK +0xbe movq %rdi, 2056467(%rip) +0xc5 leaq 32(%r14,%r14), %rsi +0xca movl $7, %edx +0xcf callq "swift_allocObject" << LEAK HERE +0xd4 movq %rax, %r14 +0xd7 movq %r14, %rdi +0xda callq "_stdlib_malloc_size" `

This issue occurs without CocoaPods for any script phase that depends on folders for input or output paths.

Notable, is that this passes plutil -lint

` $ cat /tmp/boolean.plutil <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> Label co.kolide.runload Program /Users/me/run.sh RunAtLoad

$ plutil -lint /tmp/boolean.plutil /tmp/boolean.plutil: OK `

Attached project: https://github.com/designatednerd/FileARadar/tree/master/WKWebViewShenanigans

Attached this project to the radar as well: https://github.com/designatednerd/FileARadar/tree/master/WKWebViewShenanigans

I am facing the same issue as well. When more than an hour is remaining, it shows HH:MM. Once it is below 60 minutes it starts showing MM:SS. So when the complication shows 7:00, it can be either "7h 0m" or "7m 0s". This will confuse the hell out of the customer.

There is another problem as well with ".timer" style. For ".natural" style with units = [.hour, .minute], the remaining time gets rounded up. For example if the remaining time is 4:15:30, it will show "4HRS 16MIN". This is nice as it matches (adds up) with the time displayed on the clock. On the other hand the ".timer" style rounds it down and shows "4:15". Due to this, when both modularSmall (.timer) and modularLarge (.natural) complications are on the watch face, they are off by 1 minute.

I tried to compensate for this by adding 60 seconds to the endDate for modularSmall complication. Worked really well until the remaining time came down under 1 hour, at which point it started showing the MM:SS format, with the added 60 seconds making it appear wrong.

For the time being, my workaround is to split one timeline entry into the following two.

    * startDate       To     endDate + 60 seconds     // with units = [.hour, .minute]
    * endDate - 1Hr   To     endDate                  // with units = [.minute, .seconds]

When .second is included in the units, it seems to update the complication every second, instead of being frozen at random seconds.

This is good to know. Thanks

For all that come here and imagine that this bug could no longer be the case since it's now 5 years old: Yes, the bug still exists, the workaround still solves it.

Engineering has determined that this issue behaves as intended based on the following information:

Actually, this was discussed extensively as part of the design review process and the ultimate decision made was that ATV’s are secondary devices to HomePods. As a compromise the utterance “Play music on all of my devices” will include the Apple TV. We may revisit this at a later point, but for now design is pretty firm on this behavior. Hope that helps!

We have same issue, and standard reply from Apple stuff - Duplicate of 29281220. We need this functionality for our app. Does anybody know when this issue will be fixed?

I have exactly the same problem, but i've notice that other apps can correctly output to Airplay after wake up....so it must be a way to avoid this :)

If you find more info about this pls let us know.

Closed as a dupe of 28676479, which is still open, on 14 January 2019

Any solution...?

"We are closing this report since our engineers have determined that the issue is not going to be addressed."