Emerald Blog

    Notes from the developers at Emerald Sequoia LLC

    Browsing Posts in Development process

    Retina support and app size

    1 comment

    The new iPhone 4 support that Bill just posted about required a whole new set of artwork, which is why it took so long for us to get this support out. Most simple apps simply use built-in widgets and graphic routines to render their displays, and those apps got Retina support simply by recompiling. (Our own apps Emerald Time and Emerald Timestamp fall into that category, and we supported the Retina display in those apps when the iPhone 4 came out). But the displays you see in Emerald Chronometer are rendered using a “parts list” of display objects that is generated with a custom external tool.

    For example, here’s a parts list (this is really an OpenGL texture atlas, for the technically inclined) from Geneva’s front side, at the old resolution:
    Old display 'parts list' or texture atlas

    That image, and many more like it, are included with every copy of the app we ship.

    The only way to get higher resolution imagery with this scheme is to provide a higher resolution image of parts; because the Retina display has 4x the pixels of the older displays, that means these artwork images need to be about 4 times the size of the old ones, which turns out to be a pretty large number (40 MB of images). Here’s just a portion of the same artwork image at the higher resolution for comparison:

    We sympathize with those of you with older phones and slower connections who have to download all of the bytes of the new app with no appreciable benefit. For what it’s worth, we considered a couple of different options before settling on this one:

    1) Creating a separate app with the high-resolution artwork in it, and leaving the existing app as is. This would have removed any impact on owners of 3GS and earlier devices. But we didn’t think this was fair to our existing iPhone 4 customers, since they would have to pay full price for the new app for a relatively minor feature upgrade, and we didn’t see any other app developers do this.

    2) Making an in-app purchase option for $1 to get the higher resolution artwork. At first this seemed like a good idea (especially since it would bring in a small amount of revenue for our not inconsiderable effort generating the new artwork), and we spent a little time developing some store infrastructure to support it. But this would mean that users would have to download the additional 35 megabytes or so of Retina-specific imagery while running the app. This maybe wouldn’t be so bad, but the artwork typically changes in minor ways every time we release a new version, so it would mean that going forward as more and more people had iPhone4-class devices, we’d all be forced to do this extra step every time a new version was released.

    We finally decided that the right long-term architecture was to just support the Retina display as part of the normal app. Anyway we hope those of you with Retina displays like it.

    Why we code

    5 comments

    Emerald Sequoia LLC is the outgrowth of my 20-year friendship with Bill, the other half of the company, and a similarly-long appreciation for Apple products (Bill had one of the first Macs in 1984, and I joined that train in 1989).  When Apple announced the iPhone development kits in early 2008, we decided to have some fun and write an app for it (that was Emerald Chronometer, released the day the App Store opened in July 2008).

    In case there was any doubt, we’re not getting rich doing this.  The difficulty of turning an iPhone app into a revenue stream when there are over 150,000 apps competing for users’ attention is well documented elsewhere.  Even on its best day ever Emerald Sequoia made me less money than my average daily income over the past five years from my “real” job (and a more typical day earns the company about $40 before tax, which we split).

    So this is a hobby, let’s be clear.  But we’re trying to run it like a company, with professional customer support, solid testing, good development practices, etc., etc.  We have 55 years of development experience between us, and we try to apply all that we’ve learned.  And we’ve put in the hours, as well; typically about 20 hours a week for me over the past 2 years.

    And the end result is that it’s been the most satisfying development project I’ve ever worked on, because we’ve gotten to work on a product we use ourselves on a daily basis, and we’ve gotten to control all aspects of that product development ourselves.  And most importantly for me, we’ve gotten to interact directly via email with customers who love the product.  I guess this is something all small business owners are familiar with, but it’s a refreshing change for someone like me who’s previously been at least one level removed from the customer (although, truth be told, that has, at times, been a good thing…).

    So thanks for making it all worthwhile. :-)

    - Steve