Should I use Xcode 9.0.1 given the bad reviews in the App Store

30 points by oldmancoyote ↗ HN
There are more 1 and 2 star reviews than 4 and 5 start reviews on the App Store. This is deeply disturbing. I don't want to add additional problems while trying to finishing my current project. In your opinion should I upgrade or continue with 8.3.3?

33 comments

[ 0.21 ms ] story [ 45.1 ms ] thread
Personally, I've found it quite okay.

However, IMHO, if you have a commercial project with a deadline, don't take on board additional risk by installing it.

A lot of "project management" can be thought of as risk management. A risk is something that's hard to judge or unknown - e.g. will this developer finish on time? Is this implementation going to work?

Installing a new version of the dev tooling is definitely a risk. Think about it from the POV of risk management. Are there features of 9.x that you need to complete the project? What are the unknown parameters? It might not compile your code correctly? How do you mitigate it? Time? Money? Reverting back to a previous version? Some risks can be mitigated by the developer, some need to be passed upstream to the customer. e.g. "If you want to deploy on iOS11, we need to upgrade Xcode, which has documented issues, we expect this would require x hours to complete and have the following potential issues."

(comment deleted)
It’s extremely buggy. Downright broken at times. On a reasonably large project, autocompletion goes broken more often than not; jump to definition is broken beyond recognition. It’s just in line with the rest of what Apple has put up this year as “exciting” software; iOS 11, macOS High Sierra and Xcode 9. Really a shameful display.
That said, you don’t really have a choice if you want to support iPhone X, which you should.
All 64 bit apps are supported by iPhone X. You only need to upgrade to XCode 9 if you want a custom layout for the black band or whatever people are calling it. I'm sure many companies will update their apps, but I can't imagine the experience will be that much better in most cases.
Since the aspect ratio of the iPhone X is also taller, running unoptimised apps on the X will be a pretty bad experience - just as running iPhone 4 style apps on the iPhone 5 was a pretty bad experience.
Is it a different size class than iPhone 8? I guess it depends on your autolayout setup.

I still don't think most apps will make good use of the notch.

We had a similar experience. This article [1] was an absolute godsend. Autocomplete is working again and it is, as billed, a bit more reliable and snappier. I hope this helps you.

That said, it's absolutely ludicrous that fixing autocomplete is this difficult and involved. I would much rather see the Xcode team put their efforts towards building a great command-line toolchain and compiler daemon, and let the community plug it into various editors.

[1]: https://miqu.me/blog/2017/06/16/fixing-autocompletion-on-mix...

The ShowDVTDebugMenu setting no longer works for public releases.

Run "defaults write com.apple.dt.Xcode IDESourceKitServiceLogLevel 3" then clean your project and allow it to re-index. The log will be written to /tmp.

Locate the failing invocations in the log. Copy and paste them to terminal and run manually (in some cases you may need to substitute libclang for clang, etc). You should see the full error output.

The majority of autocomplete/indexer failures are actually sloppy includes, bad module maps, and other errors where the build system or compiler is more forgiving of the bad input. In some cases switching to the new build system will expose the errors.

* Make sure your includes are correct (frameworks should be using angle brackets and include the framework name).

* Make sure you don't have non-modular headers in modules (CLANG_ALLOW_NON_MODULAR_INCLUDES_IN_FRAMEWORK_MODULES = NO).

* Make sure you aren't relying on implicit imports, eg: If a header references CGSize make sure you're importing <Foundation/Foundation.h>. If using uint8_t, import <stdint.h>. Sometimes you can get away with being sloppy here and build but it still breaks the indexer.

* Make sure you have clean well-defined module maps. Use explicit @import syntax in Objective-C - you might find that your module map was broken (Swift requires modular frameworks)

If you are worried, make a copy of your current Xcode before you get 9.0.1. Different versions of Xcode can happily live side by side: an install of Xcode is completely self-contained. You will only have problems going back to an earlier version if you make new API calls or you use Swift 4. Unchanged projects can be compiled by 9.0.1 and, if that fails for some reason, you can go back to the previous version.
If it aint broke, don't fix it.

You can always buy a used mac mini for $400 and slap it on there.

It has bugs, and most frustrating are the regressions (for example, in some past Xcode they broke option-drag-to-copy-text editing but eventually fixed it; now in Xcode 9, it’s broken again — or at least so unreliable that I never bother to try copying that way anymore and it’s useless). While I’m partial to terminal-based editors anyway, I never felt like I required them until Xcode 8.x or so.

I really don’t understand Apple’s development tools strategy. In the old days, the “separation of concerns” that was Project Builder and Interface Builder with other developer apps and command-line tools, etc. made a lot of sense. Ever since they created the UI abomination that is Xcode 4.x and tried to shove every single thing into the same program, it’s been unstable and aggravating to use. And don’t let the 9.x version fool you; these are iTunes-style marketing versions, Xcode “9” represents AT BEST an Xcode 5.1.0.2beta3 level of usefulness.

One problem is that Xcode is written using AppKit, which was a state of the art technology 25 years ago and hasn't changed much since. Apple stopped caring about Mac development a long time ago and Xcode is the highest profile casualty.

Contrast with VSCode which is built with modern technologies. It has a much faster release pace, and is more stable and more responsive (despite being an Electron app!)

> "Apple stopped caring about Mac development a long time ago and Xcode is the highest profile casualty."

Xcode is also required for iOS development. I haven't used Xcode in a while. Are there aspects of Xcode that are only used in iOS that are better or more modern than those that are used only for MacOS?

I don't mean that. Xcode is itself a Mac app, but Apple hasn't cared about the technologies for building Mac apps for a long time.

The UI framework for building Mac apps (AppKit) was designed in the 90s. In ~2007 it was revamped for the original iPhone as UIKit, but crucially Apple never backported their modernization to the Mac. And even UIKit is starting to look outdated compared to modern innovations such as React Native.

So I don't envy the Xcode team, they are working with an old codebase and targeting an abandoned UI framework.

I'm sure if Apple could swallow its corporate pride and just fork VSCode, they could work miracles.

fwiw, Xcode 9.0.1 fixes the bug where unit tests written in Quick/Nimble don't show up or are unreliable. I write most of my code in AppCode though so I don't have much of an opinion about the editor surface.
If you're using Swift, stay on 8.3.3 until you have the time to update to Swift 4. There are some things that don't quite carry over, and you'll need to spend at least some time on migrating.
Swift 4 can compile Swift 3 code.
Yes, I'm aware of Swift 3.2 compatibility mode. Unfortunately there are still a couple breaking changes–even if my code doesn't do anything funky I can't guarantee that any of my dependencies isn't mucking around with a Dictionary's keys or anything else that isn't the same between 3.1 and 3.2. I have updated to Xcode 9, and that's in part due to the work you and your team has been doing to make this transition easy, but that doesn't mean that it doesn't take time to update.
Buggy but usable 99% of the time. I’m not sure what others are saying about jump to functions broke, works for me, 99% of the time
I have never seen or heard of any version of XCode that isn't riddled with bugs.

A daily ceremony when build iOS apps is to carefully rule out Xcode flaking when any issue is presenting.

Far too often it's XCode.

I think things may have been better in XCode 4.x but it would still crash pretty often.

You can download Xcode (and many versions past) here, directly: https://developer.apple.com/download/more/

Thus, you can have multiple versions installed simply by having Xcode.app in a different directory or renamed. Just remember to set the active Xcode for command line usage via `xcode-select` (can verify via `xcodebuild -version`).

This is precisely for jumping between various GM and beta versions in case of issues and such. Downloading from the Mac App Store does not give you this control.

Finally, Xcode 9.0.1 has worked smoothly for us so far FWIW.

From my experience, it starts to slow whenever I tried to open storyboard or XIB files. Other than that, I think it's pretty okay.
Were previous versions rated better? I though that Xcode had always been generally downvoted by the people using it...
Yes, the previous versions were rated bad, and many reviews ons the MAS are from the previous version.

Most people don't vote at all (why?), but lots of people use AppStore rankings as a bug report. That's not how it works.

In my opinion, Xcode 9 has been great, simply great, solved all the problems of Xcode 8 for me, and it's now my favorite IDE.

Of course it has it's problems, but which IDE doesn't have them?

Personal experience with Xcode is don't update if ain't broken or you absolutely have to.
They're just trolls. Xcode 9.0.1 is fantastic. Best Swift IDE out there (and I've tried a lot) and when I am forced to use "X" IDE because of the dev language I need to use for "Y" project I end up shuddering... and wishing I could use Xcode (yeah ok, and Swift).
It's got some problems to be sure, but xcode 8 had much worse problems in my experience.