xCode 9 discussion

macOS & Mac Apps

Hello all!
So, let's discuss xCode 9 here. I haven't updated yet, but I heard there were some problems with the new editor. Do these still persist or have these been fixed?
Any accessibility improvements / htings we should be aware of before updating to xCode 9?




Submitted by Vincenzo Rubano on Friday, September 22, 2017

Yeah, from an accessibility point of view Xcode 9 is simply amazing. You wouldn't expect to be able to read code line by line as soon as you open the source code editor, would you? You wouldn't expect to be able to know which line of code is affected by a certain build issue, would you? You wouldn't expect to be able to jump quickly between fragments of your code exhibiting issues, would you? You wouldn't expect to use VoiceOver commands to quickly jump in )potentially long) source code files, would you?

O yeah, I know what you are thinking: we were able to do all of this in Xcode 8! And this is exactly the point: Xcode 9 is full of accessibility regressions. Given that blind developers depend on this piece of software as their sighted peers for productivity, educational and professional reasons, the only advice I can give you is to stay away from Xcode 9 and blame Apple for their mix of bad practices in software development shown in Xcode 9.

But you wouldn't think this hasn't any consequences, would you? There will be a point in time when apps built with Xcode 8, thus not linked against the latest SDKs, are not accepted within Apple's app stores. You may wonder when this time will be: if you find out let me know. Just to increase the frustration of blind developers Apple hasn't given any feedback on this aspect since the date is not stated explicitly in Technical notes and QA. And before you ask: they didn't reply anything to all of the reports I sent them about this, including the question on the future of our apps. That's what we are talking about: the future of our work as developers that pay a program membership with the same money sighted developer use, but get a second/third/forth/fifth/... class treatment.

FYI, for brevity I have not mentioned all of the accessibility issues/regressions Xcode 9 introduced, just a few of them.

Submitted by Oriol Gomez on Friday, September 22, 2017

Damn. Sounds pretty bad. Let's hope this stuff is fixed soon though with the way this is going, it doesn't look like it. Maybe in a bugfix release?..

Submitted by Kyle on Friday, September 22, 2017

I use Xcode every day. Honestly i can't really comment to much on the issues you mention. i just use Xcode for the editor and compile with the commandline. i don't use projects or anything like that. I'm also using c++ and not objective C or swift.
all that being said, i've been using the Xcode 9 beta for near on a month now and it works fine for me. no accessibility issues.

Submitted by Greg Wocher on Friday, September 22, 2017

So I guess they want us using their OS's but they don't want us to develop for them? I wanted to try and learn swift but I don't know if I want to now. I also noticed that the playgrounds is still not all that accessible which would be a great feature if they made it accessible to us.

Greg Wocher

Submitted by dvdmth on Sunday, September 24, 2017

Club AppleVis Member

Before I judge what’s happening here, I have a quick question. Are you using Xcode 9 with Sierra, or High Sierra? If you’re using it with Sierra, and you haven’t tried it with High Sierra, then I would withhold judgment until you try it with High Sierra, in case the new OS is required for VoiceOver compatibility. On the other hand, if High Sierra is affected as well, then that is definitely a bummer. I haven’t tried out Xcode myself just yet, but I intend to within the next week or two.

Submitted by Vincenzo Rubano on Monday, September 25, 2017

In reply to by dvdmth

Wether we test Xcode 9 with Sierra or High-Sierra is completely irrelevant for judging its accessibility: if it works on a certain OS it should also be accessible under that OS. But in any case I tested it under High-Sierra...

Submitted by gfish103 on Tuesday, September 26, 2017

I tested Xcode 9 on High Sierra and found it impossible to locate an issue any more. With previous versions of Xcode, the ruler controls just before the source code editor simply told me the line where the issue occurred, but now it's impossible. I know it's visually intuitive but it's a serious regression for blind developers.

Finally I found a workaround. It's a bit tricky but it works for me

  1. Navigate to an item in the Issue Navigator.
  2. Navigate to the source editor, and find an image named like "DVTStatus Error image".
  3. Route the mouse cursor to this image.
  4. Stop moving the cursor left/right until you hear "source editor...". I use a mouse simulator to ensure horizontal movement.
  5. press the mouse button.

Now you are in, or at least near, the line where the issue occurred.

Submitted by Zsolt Torma on Wednesday, September 27, 2017

Hi all,

I've created a little script that not too smart, but enough for me now.
This script communicates with Xcode and gets the first error message (not warning) after building the currently loaded project and speaks the message and the line number where the error can be found.
So, if more than one file contain errors, this script speaks the first error, so you have to know which is the first error and where can be found.
I use this primitive solution to get the error in the file I'm currently working on.
I know that there are several additional features that could be added to this script to be more powerful, but it is enough for me now.
The script can be assigned to a keystroke in Keyboard Commander as you may did with the sayBattery or with another scripts.
If you want to use this solution, please contact me through this website and I'll send you the script.

Zsolt Torma

Submitted by gfish103 on Thursday, September 28, 2017

I did some research on Xcode's dictionary and also plan writing a script to do the build. I found it really feasible.

Submitted by Andy B. on Thursday, September 28, 2017

Try going to the issues navigator to find build problems. It works like a dream.

Submitted by robin24 on Thursday, September 28, 2017

Hello all,

following all the different comments / criticisms / suggestions here, I thought I'd chime in with my personal opinion.

First of all, I do agree to the fact that a lot has changed in Xcode 9.0 and yes, there are a few accessibility regressions in this release, most of which are related to the new source code editor.
The most important thing to consider here is that a lot has changed in Xcode 9.
The source code editor was rewritten from scratch, GitHub integration was added, wireless deployment and debugging is finally here, support for Swift code refactoring was introduced, support for all the new SDKs and frameworks was added... Those are only the most obvious additions to Xcode, point being that this is a pretty huge update.

With so many things being overhauled, I think it is pretty reasonable to have some regressions in this .0 release, with some of those regressions affecting all users and others affecting VO users specifically.

Personally speaking, I've only been developing in Swift since the beginning of this year.
I think that my knowledge of Swift and Apple's key frameworks is pretty solid at this point, but I also know that there's still loads of new stuff for me to learn.
In Xcode 9, I most definitely noticed many of the VO issues which you guys have mentioned, it was clear that I would need to change parts of my workflow, as some things are handled differently in Xcode 9 than in Xcode 8.
However, with a bit of trial and error, I managed to work around all those things, enabling me to take advantage of Xcode's new features as well as the new frameworks, including CoreML and Vision.
Yes, it's no fun when things that used to work in an older version suddenly break in a new release, or when certain ways of accomplishing a specific task change, especially when the new way is seemingly less intuitive or trivial than the old way.
But to be fair, it's exactly the same for sighted users, whether in Xcode or any of Apple's many other apps and OSes.

I also would like to say that I very strongly disagree with the notion that Apple no longer cares about Xcode accessibility, or that blind developers are at risk of loosing their ability to create apps in the future. Although there are some accessibility regressions in Xcode 9.0, there's honestly no reason whatsoever why those regressions wouldn't be fixed as Xcode matures in the coming weeks. It's simply necessary sometimes to go through a couple iterations in order to squash all those bugs and seriously, no one should know this better than those of us who have come into contact with software development or actually, anybody who's used Apple products for a longer period of time, experiencing all the various software and OS updates.

If you find a bug, visit bugreport.apple.com and outline your findings. Granted, some of those bug reports may just stick around and remain seemingly untouched, but you might get lucky and find your problem that you reported in an new version's release notes, listed as either a known issue (in which case you'll know that Apple is working on a fix) or as a resolved issue, in which case you'll know that you've made a valuable contribution towards fixing a problem that was annoying you in the past.

Believe me when I say that this is absolutely possible, I reported the Interface Builder issue mentioned by another user to Apple, it has not been resolved just yet, but it is listed as a "known issue" in the Xcode 9 release notes, including a workaround that is reliable.
And if you really do encounter a problem that prevents you from pursuing your objective, ask for help on here, or reach out to Apple's dev support, or the developer forums, Stack Overflow, etc...
Those options are of course not guaranteed to always lead to a solution that will move you forward, I'm only sharing ideas which worked very well for me in the past, so I think all of you should give them a try!

Have a wonderful day everyone and happy coding to all you developers out there!


Unfortunately, I can't give you a page number as I looked at the HTML version of the release notes which is available here: https://developer.apple.com/library/content/releasenotes/DeveloperTools…

You'll find the issue description as well as the workaround in the "Source Editor" section, where it is listed as a known issue.
Here's what it says:

Known Issues
Using VoiceOver to drag a connection from Interface Builder to the source editor sometimes fails to create the connection. (33198923)
Workaround: Declare the IBAction or IBOutlet in the source editor, and then drag the connection from the source editor to Interface Builder.

Let me know if this helps, happy to provide more detailed instructions in case it doesn't.


Submitted by Andy B. on Thursday, September 28, 2017


Writing the code for an outlet, then dragging it to the interface builder fails. VO can't just grab a line of code... It drags the entire assistant editor.

Hey Andy,

what version of macOS are you on? This workaround worked fine for me on Sierra but yep, I just tried again on High Sierra and was able to reproduce the behavior you described.

I've just figured out another workaround though, haven't really tested it extensively yet but it seems to work, this one doesn't require you to write your outlet definitions manually.
Steps are as follows:
1. When your Storyboard is open, bring up the assistant editor with your view controller's .swift file.
2. In your source code file, use the arrow keys to navigate to a blank line where you'd like to insert your new outlet definition.
3. Go to your Storyboard, find the element that you'd like to connect and open up Connections Inspector.
4. Drag your referencing outlet connection out from Connections Inspector, just as before. Then, navigate back to the assistant editor, VO should announce something like "ViewController.swift group".
5. Interact with this group and find the "source editor" text field, do not interact with the text field.
6. Press VO+CMD+F5 to route your mouse to this text field, then release the mouse. Xcode should bring up the usual dialog for creating the outlet. Upon saving, Xcode should then insert the outlet definition in the line where you've previously placed the cursor and you should be good to go.

So basically, it's similar to how it used to work, except that you need to first put the cursor on the line where you want your new definition and you should not interact with the actual text field when dragging the outlet.
Not a perfect solution, but it seems to work for me and I sure hope it does for you as well!


Submitted by Andy B. on Thursday, September 28, 2017

Hi Robin,

Your idea above worked. However, I noticed a few strange things: The @IBOutlet statement doesn't appear in the source code, and navigating through the source editor with quicknav off results in lines of code getting repeated. Do you have a workaround for this? I am currently using OSX 10.13.

Submitted by robin24 on Friday, September 29, 2017

In reply to by Andy B.

Hey Andy,

very glad to hear we're getting closer to a solution! :-)

To be honest, I'm not sure at all why you wouldn't be able to see the newly declared IBOutlet in your code, as that always works for me once I've created a new outlet...

In regards to the issue where VO is repeating some lines of code when navigating with the cursor keys, I was actually able to find a workaround which doesn't seem to solve the problem completely, but makes it appear less frequently.

In Xcode, go to the menu bar, open the "Window" menu, then find and activate the "Zoom" menu item.
In case you find that it got even worse after doing this, just do it again and see if anything changes.

As far as I know, this happens mostly when you have a very long line of code, e.g. a function call with lots of parameters. I'm not sure what exactly is happening here, but I'm guessing that it has to do with how lines wrap in the new editor.
So, maybe you could even improve things further by running Xcode in full screen mode, though I haven't tried that yet so don't know if it actually helps.

Let me know if this works for you, hope I could help!

Submitted by PaulMartz on Friday, September 29, 2017

Member of the AppleVis Blog Team

Hi all - I'm a long time command line user, doing cross platform development. I recently decided to (finally) try to learn the XCode interface. To that end, I upgraded to High Sierra and installed the very latest XCode 9.1 beta.

Someone in a previous comment said the text editor did not read lines of code. This seems to work in the 9.1 beta.

I wish I could report on other issues you all have mentioned, but I'm such a noob that I don't know 90% of the features you're referring to. Wish me luck and maybe I'll continue to learn.

Hey Paul,

kudos for your decision to give Xcode and Swift a try!

Don't worry if the Xcode interface seems a little overwhelming to you at this point, I've been there and know exactly how you feel. :-)

In case you're completely new to Swift, I highly suggest that you start out by learning about the language and its fundamental principles and syntax for starters.
Apple has published a great eBook covering all of that, which can be found at https://developer.apple.com/library/content/documentation/Swift/Concept….

You don't need to read through all of it in one go, but it should get you acquainted with the most important aspects pretty quickly.
Also, since you do have programming experience already, my feeling is that you'll probably be able to easily adjust to the new language.
In addition, I highly recommend you check out RayWenderlich.com, they have loads of iOS programming books and tutorials that will get you up and running with the most important iOS frameworks, including Foundation and UIKit. Also, they do a great job updating their tutorials, so that they should always be compatible with the latest updates from Apple.

I wish you best of luck on your journey into Swift as well as Apple's frameworks, hope you'll find it to be a fun and rewarding experience!
And in case you do get stuck or run into any problems, just ask for help on here. I'll be happy to answer whatever questions I can, plus there are other devs around who might be able to help.

Have a wonderful weekend!

Submitted by PaulMartz on Saturday, September 30, 2017

Member of the AppleVis Blog Team

I appreciate your post very much. You've just expanded my knowledge of XCode by a factor of ten. AppleVis - what an awesome community.

Submitted by tay tay on Sunday, October 1, 2017

So I think I have a grasp on the outlets now, but how come actions don’t work? Am I the only one that can’t connect my IB action to a button? What should I do? I tried the same steps as the outlets, but no luck what so ever.

Submitted by robin24 on Sunday, October 1, 2017

In reply to by tay tay

Hey Tay,

sorry you're having issues creating your IBActions!
Unfortunately, I'm not sure what's happening there, as the steps I provided above for creating IBOutlets do in fact work for me even when creating IBActions.

In case you really can't get this to work, you could always create an IBOutlet for the UI control and then add the action as a target in code, for example as part of your viewDidLoad() method.

So for instance, if you created an IBOutlet for a button named okButton, you can type
okButton.addTarget followed by pressing return, which will auto complete the function call for you with all the necessary parameter names, you can then go through them and add values for those parameters.



Submitted by robin24 on Sunday, October 1, 2017

In reply to by robin24

Hi again,

I just decided to code up a small app that demonstrates the workaround described above (using addTarget() instead of creating an IBAction).
As accomplishing this may not seem trivial at first glance, I hope that this little bit of code will be of help.

Here's the link to the .zip file containing the Xcode project with the sample code: https://www.dropbox.com/s/wjq13333u44w17x/Control-Target.zip?dl=0.

Again, you only need to do this if you find yourself unable to create IBActions from within Interface Builder, as using Interface Builder is definitely much more straightforward.

Happy Sunday!


Submitted by Greg Wocher on Sunday, October 1, 2017

Hello all,
I see a lot of negativity when it comes to using Xcode to code for Apple. I am guilty of this at times myself. For me it is probably because I come from learning to code on Windows where we have Visual Studio which is a great IDE. I wish we could get more podcasts of blind developers showing how to use Xcode to code a project. I think this might help to combat some of the negativity when it comes to the effectiveness of using Xcode to complete a project.

Greg Wocher

Submitted by Jim Homme on Friday, October 27, 2017

I installed XCode 9 last weekend. I've never used it. Maybe it is a bit too much to bite off for a fairly new user. How relevant is the long post on this site?

Submitted by Socheat on Saturday, October 28, 2017

Hi everyone, I think I'm going to download xCode and give it a try. The question is, can I code in C++ within xCode? I'm asking this, because I was learning to code in C++ when I was a Windows user.

Submitted by splyt on Sunday, January 28, 2018


A good news and a type for you guys. First the good news:

For me, XCode 9.1 b55 it is no longer necessary to go to the library, select a component, cmd vo shift f5 to lock the mouse and all that stuff.
If you want to place a component on the view just go to the library then cmd + c on the component. Go back to the document outline, select the component where you want to place on the object and then cmd + v. As good as that. You can even place several components of the same kind on the view, just make cmd v several times and voila, there you have them.

Now, the type:

I needed to create a flow where one clicks on the add button and a new view controller is loaded.
I embedded the first view controller created into a navigation controller via the embed into navigation controller on the editor menu.
A Navigation Controller was then created automatically.
A Navigation Item was also created and added to the view I embedded into the controller view.
All is good, but the navigation item did not have any button and I need an Add button on the right hand side of the navigation bar, just the way almost every other iOS application does include for showing my next view.
And Now the thing begins. I tried to go to the library and picked a Bar Button Item. Placed it inside of the navigation item by going to the navigation item on the document outline and making a cmd + v.
A group called ToolBar Items was created and my button item was placed inside it. I them selected the button, went to the attributes inspector and in the bar button item group changed the system item to add.
CMD + r ... and well, nothing happened. VoiceOver could not read the button.
By examining carefully what happened I realized that the tool bar items group was not created inside the navigation item but ratter below it.
In order to fix up things I needed to vo right on the button created, rout the mouse and lock the mouse left button down with cmd vo f5 and cmd vo shift space. VO up two times to reach the button to thhe right of the navigation item and them cvo cmd f5 and vo cmd shift space to unlock the left mouse button. After that, my button was placed on a new group just automatically created inside the navigation item called left bar button items. Right below my button another group, still inside the navigation item, was also automatically created. This one is called right bar button items. I then moved my button, by going vo right on it then routing the mouse then locking the left button just like I did and going vo down and routing the mouse and unlocking the left button ... and ... well, thanks to God the button is now at the apropriate place.


Submitted by splyt on Wednesday, January 31, 2018

In reply to by robin24


The zoom did not work.

However, your assumption that VoiceOver is behaving extremely bad with very long lines is indeed correct. This happens because line wrapping is not being handled the way it should be.

Aparently, VoiceOver gets one line as a big single unity and reads it when the cursor is on the first physical line. When the cursor goes to the second physical line, VoiceOver queries the current line and, unsurprisingly, gets the same line because it is in reality still on that line ... it is wrapped visually so the keyboard cursor has moved but the logical unity is the same.
Because the query still returns that line, voiceover reads again the current line gfrom the beginning awards all again. This makes reading code a very frustrating experience.

To minimize problems, I figured out that the horizontal space on screen is very important. I really tried to set line wrapping off but could not find an option on XCode to do it. Then, I went to the view menu, selected assistant editors and select assistant editors on botton instead of on right.

This reduced the repeated lines to almost no ocurrences at all. I am still verifying wheter this will cause any other issue. Until the current moment none identified.

Submitted by Chi Kim on Monday, February 19, 2018

I also confirmed. Connecting reference outlet works, but not the action. Every time they release new Xcode, workarounds for connecting action/outlet/segue changes for VoiceOver users. Imagine if they did this to sighted users! :)
For hobby programmer, this is fine, but it's not acceptable especially your living depends on having to use Xcode.

Submitted by Chi Kim on Monday, February 19, 2018

In reply to by splyt

Apparently you can uncheck line wrapping from Xcode. I got the following response from accessibility-dev.
"Right that VO doesn’t honor soft returns in Xcode editor, but if you are a VO user, you probably want to turn  soft returns off anyway.
To do that, uncheck Preferences -> Text Editing -> Indentation -> Line wrapping: Wrap lines to editor width. Hope that it helps."

Submitted by Laura Tosetto on Friday, February 15, 2019

Hi guys,
I've just started to learn the Swift language and Xcode, mainly as a hobby, because I don't have a lot of programming experience, but I found a book by Apple education about Swift and building IOS apps and I'm trying to follow it.
I know this forum topic relates to Xcode 9, but I've tried all the instructions and steps mentioned here, to no avail. So I thought I'd ask the most experienced of you here if they can help me out :).
Here is my question: how do I create an outlet, or a connection in general, for that matter? I followed the steps that have been suggested here to create the connection: locked the mouse on the connect button in the connections inspector of the storyboard element for which I want to create the outlet, went to the source editor text field where I previously placed the cursor on a blank line, and unlocked the mouse, but nothing happened. I noticed that the mouse pointer doesn't seem to position on that line, but stays at the very top of the text, even if I route the mouse to the blank line with VO command F5.
Sometimes I managed to make VoiceOver announce that Xcode has a new window, but I don't know if it is the dialogue for creating the outlet, as when I select it with VO+F2, VoiceOver seems to loose focus and navigation commands just do nothing as if there is no element in the VoiceOver cursor.
Any ideas on what I'm missing here?
Thanks a lot in advance! :)