Dear all, My name is Akifumi Takata. Regards, Akifumi Takata

Did you try removing and re-adding the linked binary? It could be that the changes required for the newer versions to work would not function because of an API change if you wanted it to work on

Thanks, I have managed to get it working, but the reason is something of a mystery. Xcode 9 showed the same problem, so that wasn’t it. I created a new project and just added the CCToneGenerator

what I usually do to debug these things is pull the link line from the detailed build log, go to the same directory, run it by hand and ensure I see the same result. Then I

All looks OK. I’m going to try Xcode 9, just in case (grasping at straws perhaps). I did upgrade Xcode and the OS separately, but this particular project wasn’t recompiled until

It sounds like the one of a few things might help. Look in your "link to binaries” build section to see if any binaries are added twice, or are missing. Also, check to see in the build file phases

I’m using 8.3.3 ;) Yes, that was an update! Maybe I should try 9, but somehow an issue like this doesn’t quite seem like an Xcode problem. —Graham

Which version of Xcode? I haven’t had problems with Xcode 9.0, but 9.0.1 was released and some people are reporting various errors. Are you using 9.0 or 9.0.1?

Hi all, I’m suddenly running into some linker errors against AudioToolbox on a project after upgrading Xcode and installing High Sierra (not sure which of these did it). Undefined symbols for

Yup. When the target you’re building has enough of its own header files to affect compilation speed, it becomes useful to precompile them. There are also a lot of C and C++ headers in the OS (and in

Except of course that the tradition of *pure C* programming has assimilated this as standard programming technique: the compilation of one package is modified by pre-inserting macro definitions that

I want faster builds. We all want faster builds. The question is whether precompiling text-substituted inclusions is the best we can do with a modern development system. The answer was yes when

Exactly. I’ve never heard anyone say they should no longer be used. Why wouldn’t you want faster builds? Steve via iPad

Wait, what? I never got the memo on this. I put constants in the headers for the classes/APIs they are used with. If you look at Cocoa headers you can see Apple does the same thing. Also, this is a

Alex Zavatone: Pre-compiled headers are now considered to be a bad idea, yes, but although traditionally the *prefix* header was usually pre-compiled it doesn't have to be. So what I use in some of

Thanks Steve. That’s one option I’ve been considering. It’s a balance between knowing where to look for everything and properly scoping some constant to the one place where I use it. If

I use constants a lot, but I put their declarations and definitions into the "owner" class files. For example if one object sources notifications and others consume them. Foo.h extern NSString*

I’ve read the Apple docs and looked around and can’t find definitive sources on what the preferred method is and how to do it. Do we use modules? If so, how? I understand that a .pch is now a

The reason that I took all this trouble with sandboxing is: In iOS 11 this shows a cat: htmlString = <h1>Cat</h1><img alt=“Cat” src=“cat.gif” /> [wkWebView loadHTMLString: htmlString

It sounds like the framework is being too eager to check for this entitlement. It’s definitely worth filing a bug report with Apple! —Jens