show when run

There appears to be some strange internal doublethink going on with the bundled version of San Francisco.Indeed, like all core fonts, it's located in /System/Library/Fonts, and it occupies a handful of files prefixed SFNS. But it doesn't show up anywhere in Font Book, as far as I could see. And if you go to re-install it (File: Add Fonts and select those files), it will happily copy the files out of the system folder into ~/Library/Fonts——but will still absolutely refuse to show it in the font list!Whatever the reasoning behind this, it's totally creeping me out.(note that the same font—the same files, AFAICT—can be downloaded from Apple directly, but have the prefix SanFrancisco instead of SFNS.)

ive got the same problem, when reciving a message it will show above the clock face after raiseing wirst but no reply button.. reply button only shows in the messages app, well for me anyway.. i also cant get message to send as a SMS either so i think its best to report the bug to apple and wait for Watch OS 2 Beta 2.

They showed simple enum type names printing properly during the What's New In Swift session that can be streamed from WWDC.In Swift 2 / Xcode 7 beta, it seems that enums imported from ObjC still have issues, and only simple Swift enum types are printable.let strX = this is (NSRoundingMode.RoundPlain) // this is C.NSRoundingMode enum TestBasicEnum { case Option1 case Option2 } let strY = this is (TestBasicEnum.Option1) // this is TestEnum.Option1 enum TestRawEnum: String { case Option1 = text1 case Option2 = text2 } let strW = this is (TestRawEnum.Option1) // this is TestEnum.Option1 enum TestRichEnum { case Option1 (String) case Option2 (String) } let opt = TestRichEnum.Option1(text) let strZ = this is (opt) // this is TestRichEnum

I found my iMac struggling to wake up. I waited, and it eventually did. I found a process, sdmd had eaten all the memory. After a reboot (Which took a while!), it now seems to be fine, and this process hasn't run away with the memory again.I suspect it's some form of indexing daemon that isn't properly optimised yet.

Yes.A central focus of Metal is to dramatically reduce the CPU cost of common operations. However, it is still quite possible for wasteful code to blow out the CPU cost and end up running slowly and eating up a bunch of battery life. That is, even though the CPU and GPU can run concurrently, your GPU frames can't cycle any faster than the CPU workload required to encode / enqueue them. Thus, quite a lot of making Metal go fast can be making sure that your CPU workload isn't consuming all your time. For me, the CPU cost is usually around 10% or less of the GPU time in well behaved code. If you are running more than that, then you may need to spend some time finding out why.Most of the time, it comes down to object reuse. It is maybe the key way to improve Metal performance. Much of Metal is designed around the assumption that you will allocate expensive resources (textures, buffers, shaders, queues) up front and then reuse them. As an application writer, this is fairly simple, since

Step 1: Contact a lawyer and have the lawyer initiate legal action.Step 2: Take judge's decision to Apple.Otherwise, you're expecting Apple to figure out whether you or the publisher are the legal owner of the application.P.S. You'll never guess the seven letter word beginning with l ending in t that shows up as ******** when typed into a response.

Same here on a MBP 2010 (runs fine on MBP 2012).

I have set the UTI's for document types that my receiver app supports to include PNG files (public.png). When my receiver app is running, and my transmitter app is told to AirDrop a PNG to the receiver device, it appears as though iOS ignores my receiver app and opens Photos regardless; my receiver app should get the openURL: method called at the AppDelegate, but never does. In addition, the Open In... dialog never appears - the PNG file goes straight to Photos.If I specify a custom UTI, then my transmitter will only be able to broadcast to the receiver, which also has to know the custom UTI I've specified. Plus, I would have to change the file extension of the file the transmitter is sending to map the custom UTI to the file extension. This defeats the purpose of being able to transmit a PNG file as a PNG file.I can also transmit the file as raw data, which also defeats the purpose (and similarly requires a custom UTI).What I'm looking to discover is whether this behavior - iOS taking control of cer

Yup, so the crash log isn't really useful on its own.I recommend you put breakpoints into your code, run it and step over line by line and see exactly the lines where it crashes. We can't do that for you, you have to do it. Have a look in the Apple debugger documentation if you don't know how to do it. In my experience, crashes in my code on arm64 have been regular bugs in the code that caused memory access issues that didn't crash on armv7 but do crash on arm64. But they were still bugs. In some situations they didn't crash on the simulators but do crash on real devices. Run using the debugger on real devices if you can.