3 ms·

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 introduce

by joeblau 10y ago

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.

dep_b 10y ago
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.
- joeblau 10y ago
  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.
  - dep_b 10y ago
    > 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.
- dangero 10y ago
  IB is still not a good tool when there are a lot of people working on a project because the files do not merge easily. I've had several people at Apple tell me they generally don't use interface builder internally.
  - dep_b 10y ago
    > I've had several people at Apple tell me they generally don't use interface builder internally. I heard the same claims about Swift. I have no idea what to believe.

by joeblau 10y ago

dep_b 10y ago

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.

joeblau 10y ago
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.
- dep_b 10y ago
  > 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.
dangero 10y ago
IB is still not a good tool when there are a lot of people working on a project because the files do not merge easily. I've had several people at Apple tell me they generally don't use interface builder internally.
- dep_b 10y ago
  > I've had several people at Apple tell me they generally don't use interface builder internally. I heard the same claims about Swift. I have no idea what to believe.