Xcode 10 feedback


After upgrading to Xcode 10, swapping buffers in openGL suddenly takes up almost a whole CPU core. Anyone else experience this?
After downgrading to 9 it works as expected.


You’ve probably exposed one of Apple’s redacting techniques. i.e. put massive for-loops in code they don’t like…:grinning: I’m only joking…:face_with_monocle:


Remember you’re under NDA with Pace about the details of their SDK.


Thanks for the information @hill_matthew I didn’t know it was part of the NDA since it was in the release note… I deleted my post.


Some very broad advice is to keep a copy of Xcode 9 around for now. Renaming Xcode.app to Xcode_9.app should be enough.


Assuming that most people here will want to support older versions of OSX that still support 32-bit apps then doesn’t “for now” turn into “for the next few years”? Or have I missed something?


In Apple-world, 32 bit is no longer such a big issue, the last 32-bit only was 10.6.8 (superseded by 10.7 in 2011), and from 10.8 it was 64-bit only. So the only people who care, are the ones with ProTools < PT10, because of their 32-bit accellerator hardware.

(just as a side note, don’t want to derail the thread)


Someone with 10.7 and gawd knows what DAW asked me for 32 bit the other day. It would be interesting to really know how many people actually bought into the Apple ethos, but can’t afford to continue investing.


I am not judging the policy, that’s completely Apples choice. But from the view of a plugin developer, when I start a new product now, I don’t think it is reasonable to ask for support of a 7 years deprecated format. It is a different story to try to keep old products alive. But I assume those people know about the problem (and hopefully know their solutions, as far as I know some people still build RTAS)

I have a running 10.6.8 machine from 2006, but since I miss out on all other later softwares there as well, I only use it sometimes to watch photos or surf. More or less a digital frame now.

About “can’t afford”… the question is, if the developer can afford to spend extra time for a few people, so they can save some money… in the end we all need something in our fridge… :wink:


The last thing I want, is 32 bit to hang around. I realise I’m not a charity, although I do offer free upgrades, which people still manage to bitch about :wink:. Anyway, like you said, derailing thread.


I guess the proof is in the pudding. I’m going to release 64-bit only updates with my next updates and see how many people complain.


Anyone tired the new Xcode 10.1 beta 3 that’s available to download now?
I’m interested to see if the relative paths crash has been fixed. Nothing in the release notes but that’s not unusual.


I don’t think anybody on here wants to go near it at the mo.
Why not try it for us! :grin:


Well that was a short lived experiment.
I had it open for about two minutes until clicking on a build error wouldn’t jump me to the line of code. So I quit and deleted it.


I couldn’t even get warning to take me to the line of code. Great job Apple


If you guys have bugs with Xcode take it to the Xcode developer forum, Apple’s dev tool team won’t look at these posts.

Sidenote, Xcode works fine for Swift. Apple doesn’t care about C++ and I doubt they’ll optimize it for massive C++ libraries like JUCE.

Full CLion/CMake support from the Projucer can’t come soon enough.


perhaps AppCode support?


AppCode is supported via the Xcode exporter.

Personally AppCode is ok but I prefer the simplicity of Xcode. To the best of my knowledge (this May have been added recently) AppCode still doesn’t have support for the sanitizers which is a bit of a deal breaker.


Also, xcode is free, and appcode isn’t. so, there’s that…


This is absolutely frustrating. Just adding an include to a JUCE project causes it to instantly crash.

Anyone find the workaround for getting auto-completion for includes back?

I know some of the JUCE devs were using Xcode for the longest time, anyone abandon ship yet and go to a new IDE?