Pegasus for Cocoa Touch - Framework to build UIKit view hierarchies in XML

1. Because the XML generated by IB is completely incomprehensible for the average (or even experienced) developer. The XML from IB was never intended to be modified by the end-user. If you're talking about why you'd want to use XML at all over IB, well there are several reasons: Firstly, many advanced developers have ended up ditching IB for anything more than the most trivial interfaces, because you can only do so much with point-and-click, sooner or later it is just easier to do everything in code. Secondly, IB can become confusing when working with lots of different views which have exotic properties; you inevitably waste time clicking through submenus to find the property you're looking for -- IB simply doesn't let you have a bird's-eye view of your project and hides options away. The XML approach on the other hand gives you a single file containing your entire view, all in one place -- a true embodiment of MVC.

2. Localisation can be done with the existing APIs that are already in place. Alternatively, one could (or I could) extend Pegasus to deal with localisation in a wide range of other interesting ways. For example, you could specify additional attributes to deal with each region, or specify a system whereby each tag is flagged with a token that relates to a string localisation table. Pegasus is simply a bridge between the XML and native UIKit controls, nothing more. You can still access all of the traditional UIKit classes and properties at runtime.

3. I wouldn't say that Pegasus reinvents the wheel, I'd say it just offers a different way of driving the wheel. For example, on Android users are able to create their views in XML, but this functionality has not (until now) been available to iOS developers. I'm simply providing a different approach to creating a view, and while I'm at it, looking at providing a better way of creating views, by completely separating code from the views, implementing useful features like hex-to-UIColor and JavaScript-CSS-Selector-style searching for views based on tags and IDs. Thanks to recommendations I've received today I'm also looking at creating layout attributes/tags whereby views can be laid out automatically according so predefined templates, something that just isn't possible currently. But it's important to remember Pegasus in its current state is just an initial proof-of-concept. I'm in the process of gathering feedback and ideas and looking to build upon it. This is definitely not the finished product.

4. I think that this is a product that transcendes the new/experienced developer divide. Instead, let's look at the complexity of the product. I think that what Pegasus provides right now is a very fast way to prototype a UI. For beginners, this means they can write a UI without needing to know the nuances of UIKit or the details of IB (which can be daunting at first). With Pegasus, what you write is what you get, and I've tried to remove excess "fluff" and boilerplate code wherever possible (e.g. I implemented "virtual properties"). For experienced developers, I think that -- in time (not yet!) -- Pegasus can provide a way to be able to strictly enforce an MVC workflow, and to refactor and design views in a fraction of the time it could otherwise take, without having the hassles of IB or the micro-management needed in Objective-C: I just don't see why developers should have to worry about creating object references, structs and enums when all they are doing is creating a view. This should all be a totally separate workflow.

And what's more, I think that Pegasus provides a way for non-developers to be able to design UIs. Even using IB requires some knowledge of Cocoa Touch/ObjC, but with Pegasus the ultimate goal is to create a powerful platform on which UIs can be designed and prototyped with only a basic knowledge of XML.

Having said that, I'm not sure that the readability of JSON (when producing an interface like in QML) is as straightforward as XML.