4 ms·

Storyboard XML’s are not meant to be edited manually: no sane documentation or Xcode intellisense support exists. They are not source control friendly either. L

by sedatk 8y ago

Storyboard XML’s are not meant to be edited manually: no sane documentation or Xcode intellisense support exists. They are not source control friendly either. Lack of styling is also a problem. Compare that to VS WPF/UWP support which is the epitome of comfortable UI development imho.

bunnycorn 8y ago
The "lack" of styling is because you are supposed to declare the theming programmatically and be done with it (UIApperance) For your claim of Microsoft's superiority, I find it very unfounded, it's superior in which way? With Apple's tools, I can write my on controls, and change my own values and see them updated live in the designer.
- pjmlp 8y ago
  Just like you can when using Blend.
  - bunnycorn 8y ago
    No, Blend only works one way. What IB allows you to do is to subclass UIView, design your own controls in code and preview the results of changing instance variables directly in IB.
    - pjmlp 8y ago
      You can do that by implementing designer aware controls since .NET 1.0, so I don't see the difference, other than having a bit extra code maybe.
      - jchb 8y ago
        I suppose you are referring to this WPF functionality https://docs.microsoft.com/en-us/dotnet/framework/wpf/controls/creating-a-control-that-has-a-customizable-appearance https://docs.microsoft.com/en-us/dotnet/framework/wpf/contro..., and similarly in UWP: https://docs.microsoft.com/en-us/windows/uwp/design/controls-and-patterns/control-templates#specify-the-visual-behavior-of-a-control https://docs.microsoft.com/en-us/windows/uwp/design/controls...? While it looks powerful, I have to say that the Xcode interface builder and code annotation approach has a lot less friction.
        pjmlp 8y ago
        Yes, exactly that, but you don't need to go the full way. It depends on what kind of rendering one wants to present to the user/developer, even with DesignerAttribute one can provide a custom rendering for the control. Here with a forms example, but similar way can be done for the XAML variants. https://msdn.microsoft.com/en-us/library/ms171824.aspx https://msdn.microsoft.com/en-us/library/ms171824.aspx
jchb 8y ago
Lack of styling in terms of color and fonts is generally not a problem, but it is true that Apple limits more advanced styling for many standard UI components. For example iOS navigation bars (as in UINavigationBar) are not very customisable. If one wants to customise the look entirely, for example make the bar taller than the standard 44pt, one has to implement the component from scratch. My perception is that the limited customisability is done on purpose by Apple to enforce a common look-and-feel of UI elements across all apps on the system. Also it of course reduces the API surface that Apple have to maintain. I pretty much like it, both because it indeeds lead to a more consistent look and feel, but also because makes it easier for us to reject the weirdest design wishes from our clients - we can refer to that implementing the components from scratch will take a lot of time (= money).

by sedatk 8y ago

bunnycorn 8y ago

The "lack" of styling is because you are supposed to declare the theming programmatically and be done with it (UIApperance) For your claim of Microsoft's superiority, I find it very unfounded, it's superior in which way? With Apple's tools, I can write my on controls, and change my own values and see them updated live in the designer.

pjmlp 8y ago
Just like you can when using Blend.
- bunnycorn 8y ago
  No, Blend only works one way. What IB allows you to do is to subclass UIView, design your own controls in code and preview the results of changing instance variables directly in IB.
  - pjmlp 8y ago
    You can do that by implementing designer aware controls since .NET 1.0, so I don't see the difference, other than having a bit extra code maybe.
    - jchb 8y ago
      I suppose you are referring to this WPF functionality https://docs.microsoft.com/en-us/dotnet/framework/wpf/controls/creating-a-control-that-has-a-customizable-appearance https://docs.microsoft.com/en-us/dotnet/framework/wpf/contro..., and similarly in UWP: https://docs.microsoft.com/en-us/windows/uwp/design/controls-and-patterns/control-templates#specify-the-visual-behavior-of-a-control https://docs.microsoft.com/en-us/windows/uwp/design/controls...? While it looks powerful, I have to say that the Xcode interface builder and code annotation approach has a lot less friction.
      - pjmlp 8y ago
        Yes, exactly that, but you don't need to go the full way. It depends on what kind of rendering one wants to present to the user/developer, even with DesignerAttribute one can provide a custom rendering for the control. Here with a forms example, but similar way can be done for the XAML variants. https://msdn.microsoft.com/en-us/library/ms171824.aspx https://msdn.microsoft.com/en-us/library/ms171824.aspx

jchb 8y ago

Lack of styling in terms of color and fonts is generally not a problem, but it is true that Apple limits more advanced styling for many standard UI components. For example iOS navigation bars (as in UINavigationBar) are not very customisable. If one wants to customise the look entirely, for example make the bar taller than the standard 44pt, one has to implement the component from scratch. My perception is that the limited customisability is done on purpose by Apple to enforce a common look-and-feel of UI elements across all apps on the system. Also it of course reduces the API surface that Apple have to maintain. I pretty much like it, both because it indeeds lead to a more consistent look and feel, but also because makes it easier for us to reject the weirdest design wishes from our clients - we can refer to that implementing the components from scratch will take a lot of time (= money).