Thanks for your update.

We are reopening this report, and we'll see if any further action is possible.

If you have questions, please update your report at:

http://bugreport.apple.com

I know it's a reference to RAM.

It's still a critical issue.

That device has 6GB of RAM (and is the only device with 6GB), so it should be receiving the assets we've restricted to >=4GB of RAM devices.

If I were to guess, I'd say there's a == 4GB check in some apple code somewhere instead of a >= 4GB.

Please reopen this bug report

This issue behaves as intended based on the following:

The Memory is a reference to RAM, not the system storage capacity.

We are now closing this bug report.

If you have questions about the resolution, or if this is still a critical issue for you, then please update your bug report with that information.

Please be sure to regularly check new Apple releases for any updates that might affect this issue.

Engineering has determined that your bug report is a duplicate of another issue and will be closed. The open or closed status of the original report your bug was duplicated to appears in a text box within the bug detail section of the bug reporter user interface. For security and privacy reasons, we don't provide access to the original bug yours was duped to. If you have any questions or concerns, please update your report directly at this link: https://bugreport.apple.com/.

Marked a duplicate of 48205906.

This bug is opened since March 2016, it was already present in iOS 9. This is insane. Check out http://www.openradar.me/25433471 for more details.

Please verify this issue with the macOS Mojave 10.14.5 beta 2 and update your bug report at https://bugreport.apple.com/ with your results.

macOS 10.14.5 beta 2 (18F108f) https://developer.apple.com/download/ Posted Date: April 8th, 2019

If the issue persists, please attach a new sysdiagnose captured in the latest build and attach it to the bug report. Thank you.

macOS sysdiagnose Instructions: https://developer.apple.com/services-account/download?path=/OS_X/OS_X_Logs/sysdiagnose_Logging_Instructions.pdf

---

For a complete list of logging instructions visit: https://developer.apple.com/bug-reporting/profiles-and-logs/

Fixed in Xcode 10.2.

Hi, would you mind posting your sample project to a gist or something?

Mar 8 2018 Engineering has determined that your bug report is a duplicate of another issue and will be closed. The open or closed status of the original report your bug was duplicated to appears in a text box within the bug detail section of the bug reporter user interface. For security and privacy reasons, we don't provide access to the original bug yours was duped to. If you have any questions or concerns, please update your report directly at this link: https://bugreport.apple.com/.

Duplicate of 32944081.

This was fixed in a later Xcode 10 beta (beta 4 probably).

Jun 19 Engineering has provided the following information regarding this issue: Thanks for reporting this issue. We have removed support for the old GNU C++ library (stdlibc++) in Xcode 10. Because you’re targeting (iOS6), the compiler selects stdlibc++ by default, which is not longer supported. We will add a new warning in Xcode 10 that clarifies that. To fix your issue you can either upgrade the deployment target to iOS7+ or pass en explicit -stdlib=libc++ argument to your build command (Xcode’s “C++ Standard Library Setting”).

This looks like the expected behavior. It is not possible to have your tests reference symbols from an app target unless you use that app as the test host. If you wish to not use a host application, then you should put the code to be tested into a separate library or framework target which both your app and your tests can link against.

Filed again as 49809943 as it fails on the latest Xcode 10.2

NSURLAttributeModificationDateKey, kCFURLAttributeModificationDateKey, and ATTR_CMN_CHGTIME are all read only. We’ve fixed the header file comments (this bug covers those changes). We’ve filed these new bug reports to fix the documentation: NSURLAttributeModificationDateKey and kCFURLAttributeModificationDateKey are read-only ATTR_CMN_CHGTIME is read-only -- getattrlist man page says it is read-write. Please provide your response or results by updating your bug report and compress any bundled files (e.g. nested folders) prior to uploading.

Update. This issue continues to manifest. Apart from asking for a sysdiagnose, I have had no response from Apple.

To achieve some stability, I can confirm that the following steps work most of the time:

1. Reboot into recovery mode
2. Open a Terminal
3. Disable SIP by running csrutil disable
4. Restart into normal mode
5. Move /System/Library/Extensions/AppleThunderboltNHI.kext to /System/Library/Extensions/AppleThunderboltNHI.kext.bak
6. Repeat steps 1-4, but with csrutil enable

https://developer.apple.com/news/?id=04102019a

"We're working with developers to create a safer Mac user experience through a process where all software, whether distributed on the App Store or outside of it, is signed or notarized by Apple. With the public release of macOS 10.14.5, we require that all developers creating a Developer ID certificate for the first time notarize their apps, and that all new and updated kernel extensions be notarized as well. This will help give users more confidence that the software they download and run, no matter where they get it from, is not malware by showing a more streamlined Gatekeeper interface.

Learn how to get your software notarized" (https://developer.apple.com/developer-id/)

The original bug report (46045228) was reported to be closed on or about 2019-03-19. This implies that the issue has been addressed in macOS 10.14.4.

Performing the "Steps to Reproduce" on 10.14.4 with Activity Monitor open, the WhatsYourSIgn processes are observed to terminate after about 10 seconds, suggesting that the issue has been resolved.

Apple has marked the bug as closed. I have not been able to test it yet with Xcode 10.2