In the beginning, the screen width was 320 pixels, and it was good. Favorite rolls and formulas fit into 320 pixel. Later header/footer views were added, again fixed at 320 pixels. And even multiple tabs of rolls/views, all at 320 pixels and it was good.

Then came the iPod - and one could make a single column 320 pixels, or, if rotated into landscape, divide the screen up into something with the same aspect ratio as the original iPhone and use the remaining area as if it were 320 pixel wide (it was actually a bit wider, but everything was scaled). And things were still good(ish).

But the desire to put character information into the screen background came along, and it was designed for a 768 x 1024 pixel screen, and it looked good until it was shrunk to fit into landscape. And there was no way to put that feature easily into a 320 pixel wide screen. So this was not good.

And then when it was put into a resizable OS X window, it became even worse - sure, everything could be stuffed into a 320 pixel side bar, but OS X layout and iOS layout aren't the same (your fingers and a mouse are totally different).

And then along came other sizes - 375 pixels, and 414 pixels - and other than scaling from 320 pixel, it didn't look good.

The problem, then, is the fixed layout of "character sheet" <view> elements. It didn't work well for other sizes, or other platforms. The solution for this, then, is to drop <view> elements, and replace them with a brand new <form> element (which does everything that a view can, but isn't tied to a single width or architecture).

<form> elements are a bit more like HTML - they specify content (and provide styling information for metrics and appearance) but don't need to specify absolute pixel layout. More specifically, a <form> is composed of <sections>. <sections> are composed of <rows> (or, in general, horizontal strips of content). <rows> are composed of a variety of things, such as text, variables that can be edited, things that roll when you click/tap them, etc.... These rows are played out via a flex-box style layout (where various items have relative or absolute width). Those rows are vertically stacked to form the sections, and the sections are laid out in the available content using a "masonry" style packing algorithm.

As a result, one can create a form where some of the sections are wider than others, but on an iPhone, it'll get compressed and wrap as need (styling can be customized for iOS, OS X and "printed" output, as well the "single column" mode or multi-column mode). And if one looks towards iOS 9's multitasking where you can split the screen, you can see where this adaptive width sizing will work.

There are some drawbacks - first, <view> based character sheets are deprecated (they will continue to work, but may be ugly looking in some cases or otherwise limited). Secondly, the minimum system requirement will be bumped up to require at least iOS 6 (possibly iOS 7) - so those of you with original generation iPads/third generation iPods, sorry, no upgrades for you.