If we're comparing Apples-to-Apples (seriously, pun not (originally) intended), Apple continues to rev on the XCode IDE every year adding more features to it. Most recently, they added a nifty visual memory debugger[1] and have taken another stab at device & certificate provisioning.
You're right, Apple is revving Xcode, but feature wise and bug wise, Xcode needs serious TLC especially on their Swift side. The regressions that are introduced every version don't help and tools like Interface builder, while seemingly helpful, usually make development within teams worse. I still use Xcode every day, but it defiantly needs hardening.
There goes good ol' anti Interface Builder rant again. The real problem is that Interface Builder is too easy to use while there's real depth and challenges to using it just like with doing everything in code.
- Don't throw all your screens into one file, you can even use one screen per file just like xibs
- Use code to style items and create controls you use more than once
- Render all the controls in code dynamically in interface builder so you won't end up with "ghost town" storyboards but everything is visible at a glance
Unless you're working at "Facebook scale" Interface Builder in the hands of an expert will get you very far.
Would you throw all your code in one big 8kloc controller? Of course not, but somehow people manage to cram every screen into the same .storyboard file, just because you can do it. Then they'll complain about merge conflicts, which isn't really a surprise given the fact that you're managing an 8kloc file.
Would you set the background, border, font and color of every button every time you use it in code? Of course not. You specialise a button class. But somehow people are selecting every button manually and setting those properties time and time again once they start using Storyboards while you can use a specialized class that will render in Interface Builder exactly like it will look in the app.
I've been using Xcode since iOS 2 and once Apple introduced IB for iOS, I was all for it. There are a bunch of challenges with IB that are outside of the solutions you proposed.
How do you fix these issues?
- Fixing misplaced views when transitioning from retina / non-retina screens or even different retina screen resolutions.
Reasoning: When I worked at Amazon this was extremely annoying - You didn't even have to touch the storyboard, you only had to open it and tons of misplaced views showed up. This causes a problem when working with any version control system because the XML changes are reflected in git even though nothing actually changed.
- Rendering Snapshots
Reasoning: I use snapshot tests to verify all views via unit tests. You can use IB to capture the view and load it programmatically, but you end up having to load the whole storyboard just to render one view controller.
- Setting all properties via IB
Reasoning: When I setup a button or a view, if half of my properties are in IB and half of my properties are in code, how do you determine what goes where. Apple did add IBDesignable, but wiring that up is so that you can click a drop down is more complicated than just setting the property on the object (and it renders in snapshots correctly and it never suffers from misplaced view and property configurations are in one place).
The teams that I've worked on aren't that big, but I can say that teams I've been a part of that don't use IB have worked a lot faster than IB teams. You may be a lot better at IB than I am, I only stopped using it 1 year ago for my projects after about 4 years of using it.
> Fixing misplaced views when transitioning from retina / non-retina screens or even different retina screen resolutions.
No solution. Non-retina users should carefully commit :(
> Rendering Snapshots
I don't think I understand the problem. Nothing is stopping you from rendering just one of the view controllers alone?
> Setting all properties via IB
I'm doing more and more in code nowadays, including constraints that are also rendered in IB. Makes it easier to change things like ratios or heights all across the app.
Interface Builder then glues it all together and I can throw in some one-off items.
What I want to know as somebody trying to learn C/C++, is Xcode good for somebody who is wanting to try their hand at bare metal stuff? I always hear how bad it is outside of app dev. but can it help me be productive compared to CLI environment or just using a text editor with nifty add-ons?
I've written a lot of C++ code in Xcode. Xcode is a pretty poor IDE in general but it works reasonably well for C++. IMO things like autocomplete and a graphical debugger are enough of a productivity boost that I wouldn't want to use a plain editor.
Yes, and the ability to find call references (who is calling this function, where is it used) from the drop-down menu is really helpful. I miss the ease of access to that sort of functionality in Visual Studio.
Yes it is there for me, but the functionality is different on Xcode as it will find all references when you open the menu, so you can see the results straight away. One less click (and perhaps one less popup hidden "find symbol results" pane in VS).
That was what I was highlighting, not the fact that Visual Studio somehow doesn't have that functionality.
I would recommend using QtCreator if you want to do just pure C++ work done. It has less focus on app development and it has way better highlighting (semantic highlighting thanks to clang), refactoring and debugging.
Instruments, included with Xcode, is a really good tool. I used instruments for profiling and finding memory leaks... I think it was great... except for the lack of reverse debugging which is pretty much necessary these days.
I have used both Xcode and Text editor & Terminal for C/C++ development. In my opinion both work equally well but I would advise you to use the Text editor and Terminal method because it means you need to learn how things like build systems, LLDB, Valgrind and more work. This knowledge is essential when the IDE does something Unexpected and you need to fix it.
[1]: http://useyourloaf.com/blog/xcode-visual-memory-debugger/