Tag Archives: iphone

Judging an App by its Cover – Techniques and Tools for Creating and Testing a Professional App Icon

Posted on by

When I redesigned the KEYBOX icon for version 2.2, I promised to write about the icon design approach I took. It’s taken me some time to get around to it but here it is. In this post I want to talk about optimizing your app icon so that it has greater visual impact in the App Store. This is not an article showcasing a handful of awesome icons, there are already plenty of those.

The Basics

Most sales of iPhone apps are made via the App Store app present on each iPhone. When designing your app’s icon, how it will appear in this store is of utmost importance and as you can see from the image below, there are four important elements that introduce your app to the world…

  1. Icon
  2. App Name
  3. Price
  4. Review count and rating
App Slot

 

People are visual by nature. Our eyes are drawn naturally to images and shapes.

When an iPhone user is quickly scrolling through a list of apps in the App Store, an icon that grabs the user’s attention may be the only thing preventing the remaining three elements and most importantly your app’s detail screen from being overlooked.

 

Before & After

The old KEYBOX icon is an example of how not to design an icon. It was my first attempt at iOS app icon design and, admittedly, a bad one at that. As you can see from the below image, it was flat and almost the same color as the App Store background. It’s almost as if it were hiding from the iPhone user and in retrospect it’s a miracle KEYBOX sold any units at all prior to the icon redesign.

Old KEYBOX Icon

Below is the new KEYBOX icon.

New KEYBOX Icon

I’m not claiming that it’s the most impressive icon out there but it’s a far cry from the original. I wanted to retain the spirit of the original icon (a secure place to safeguard your secrets) while also communicating how advanced KEYBOX actually is. Even though the image of a safety deposit box is familiar and trusted it was beginning to feel…. well, old.

The new icon keeps the signature keyhole (which has been there since the J2ME version back in 2005), and adds a foggy glass window through which we can just barely make out the many secrets represented by colored lights. The exterior of the box appears sturdy and the orange lit lock lamp communicates the box’s locked state. The grooved black panel rising slightly above the white box denotes that it is where the user unlocks the box. I could go on forever but what I’m getting at is the detail this icon now offers gives it a tangible feel and almost looks as if it could be plucked right out of the screen.

 

Real Testing

As you might have already guessed, when I redesigned the new KEYBOX icon I wanted to be sure it stood out from not only crowd but also the App Store itself. The most important advice I can offer in this post is this: From day one, understand how icons (not just your own) will appear in the App Store.

To demonstrate what I mean, the iPhone App Store (the native app, not the browser-based iTunes app page) offers two background colors, dark gray (#98989C) and light gray (#ADADB0). On the left, right and bottom sides of the icon is a drop shadow. Below is a blown-up image of the KEYBOX icon as it appears in the App Store. Compare it to the icon above and note the drop shadow on both sides and below the icon.

Drop Shadow Blown Up

Since translucency isn’t supported, you’ll need to emphasize your icon’s false sense of depth (the object casting the shadow) along these edges if you want a professional look.

 

Overcoming The Unnatural Icon

It should be obvious that an icon which doesn’t populate the bottom, left and right sides will look unnatural. We are forced to fill up those boundaries. I know I said this article wouldn’t be about existing examples of great looking icons but I just want to link to some creative icons that took this forced shape constraint and made something delightful with it. The lesson is let this constraint push you to be creative.

 

Porting Considerations

At some point you may want to port your app to the Mac, to Windows or maybe even to Android. At the time of this writing, iOS is the only platform that forces the rounded rectangle shape on us. If you’re porting your app away from iOS you’ll no longer be constrained this way. However offering the identical icon on a different platform can provide instant recognition with users already familiar with your iOS app so there is some merit in keeping the icon identical.

 

Standing Out

It goes without saying that you want people to notice your app. Once you have ensured that your icon fits well in the App Store you can now concern yourself with competing with other apps for attention. Below are some techniques other apps are already using. Your app icon should also follow suit.

  1. Using the drop shadow to provide depth.
  2. Using contrasting colors.
  3. Use alarming colors like red and yellow if appropriate.
  4. Using gradients to provide a sense of texture.

Below I’ll examine each of these techniques in detail…

 

Depth

As I mentioned earlier, people are visual and react to shapes and images. Objects that cast shadows appear to stand out. Since Apple renders a drop shadow under each icon we should use it by adhering to the rounded rectangle shape. The one element to be careful of is that this drop shadow also forces us to apply the correct lighting upon the object that is casting that drop shadow (from above, obviously). The only exception is when an icon is intended to be a flat window into a scene.

Another lesser used depth technique is the sink-into-screen icon.

Sunken Depth Icons

Apple’s Photo Booth and Newsstand apps are excellent examples of this. Rather than protrude out of the screen towards the user they sink into it. The Photo Booth icon cleverly uses a border to create a small booth/room and shows the floor to give a sense that it can be walked into. The Newsstand icon appears as the typical magazine stand one might find in a street kiosk. The only caveat with this approach is that it leaves less room for the objects within the sunken space. Lastly, a sense of depth can be achieved by casting inner shadows. KEYBOX’s black panel casts two such shadows onto the white box to which it is attached.

The worst way to destroy the sense of depth is to opt for Apple’s default glossy effects.  This effect encases your app icon in an chiclet-like button.  To turn this off, select “Prerendered” in the project’s Target Summary Window (near App Icons).  If you’re using a version of Xcode that doesn’t support this try setting the “UIPrerenderedIcon” preference to YES in Target Properties.

 

Contrasting Colors

The human eye is driven to contrasting colors. One of the best app icons※ to demonstrate this is the ever popular Temple Run by Imangi Studios. Its use of yellow and black helps it both stand out from the App Store’s gray background as well as pull the eyes of any iPhone user to it. Even if the game is not of interest to the user this icon simply cannot be ignored.

Temple Run App Icon

KEYBOX’s new icon also employs a contrast of white and black. The white contrasts with the App Store’s gray background and the black contrasts with the white.

 

Alarming Colors

Color psychology teaches us that some colors induce a sense of alarm in people. Red and yellow indicate spiciness, high temperature, danger, and even anger. Adding a white halo around these colors can amplify their effects. The topic of color psychology is too deep for this post but it is worth studying the effects certain colors have on a target audience and whether those effects are appropriate.

 

Gradients

In reality, your app’s icon is a flat array of pixels. To provide the illusion that objects in your icon are tangible use gradients. They trick the eye into believing that light is refracting off surfaces at different angles, angles that should only be possible if the object itself were not flat. Take the aforementioned Photo Book icon’s red curtain. It appears to ripple but of course this is just an illusion.

 

The Tools & Techniques

We’ve discussed theory long enough. Now for some tools and techniques.

As you are probably aware, the App Store requires that you prepare your icon in a variety of resolutions…

  • 57×57 for non Retina display iPhones
  • 114×114 for Retina display iPhones and iPod touches
  • 512×512 for the App Store (will be resized at display time to a smaller size)

Obviously you won’t make the same icon 3 times but will instead resize it to each of these resolutions. Some people dabble only in raster graphics for this but I prefer vector graphics perfectly rasterized at the end to the right size.

I might be the only developer who isn’t using Photoshop / Illustrator to create app icons. I like to support Indie Developers and I’m an Acorn user. As for my vector graphics needs I discovered Inkscape and SVG years ago and never looked back. Inkscape is originally intended for Linux and on the Mac it has to run as an X11 application. This leaves a lot to be desired in terms of look and feel but it is a very capable SVG editor and gives me numerical precision over all my icons’ elements.

If you don’t spend much time doing graphics editing and don’t feel justified in forking over the amount of cash to buy Illustrator check out Inkscape. If you’re already in possession of Adobe software or any other software capable of the job by all means go with what you have.

I’ve prepared an Icon Template SVG file in Inkscape that provides the dimensions and rectangle rounded corners just the way Apple likes them. You can use this as a container for your icon and to export the various raster graphics at their respective resolutions. If you inspect the SVG XML you’ll find the exportable area to use with the “Export Bitmap” function. In this file I used a 512×512 rectangle with rounded corners (rx and ry set to 70.0).

 

A Modeling Contest

My approach for judging the visual appeal of my app icons is much akin to a modeling contest. Up until now I’ve made it sound as if creating an optimized app icon is down to a science. Nothing could be further from the truth. As if tweaking this or that element in isolation would eventually yield the perfect icon. Models in a beauty pageant are not judged in isolation, they are judged in tandem against one another, and so must our app icons!

The steps described below put you in charge of a modeling contest, for icons!

  1. Scour the iPhone’s App Store and take full 640×960 screenshots of screens with the most attractive icons you encounter.
  2. Of all these icons pick what you consider to be the best four. Any given App Store screen can only display five apps so yours will be the fifth competing for eye-balls against these four.
  3. Using Acorn, Pixelmator or any other graphics editor create a 640×705 image within which you’ll drop each 640×141 app slot.
  4. Place your app icon in the middle slot. If your app is not already available in the App Store you’ll need to get creative and override another app’s slot with your icon. Don’t worry about the app name or other text, we’re just concerned with the icon for the time being.
  5. Walk away from your Mac for at least 15 minutes and come back to gain a fresh and unbiased view. Remember, you want to see what App Store patrons who are otherwise indifferent to your app will see.
  6. Judge which icon is the most attractive.

At the end of this process, if your app icon doesn’t even come close to contending identify why that is not the case. From there, decide what actions to take in order to close the gap.

I’d love to provide you with a template full of beautiful icons against which you could compare your own but I don’t own the rights to those icons. I can only provide you with these instructions for creating your own template.

In Closing

Creating an app is no small task and takes weeks if not months from beginning to release. Regardless if you are selling your app or giving it away for free you want to get it into people’s hands and everyday it is getting harder to gain the awareness needed to accomplish this. Your app’s icon is the gateway to impressing potential users and you owe it to yourself to put as much effort into it as you did your app.

Speaking personally, KEYBOX’s sales have more than doubled in response to the new icon design. I wish I knew what I know now when I first released it. Hopefully you’ll be able to apply these techniques from the beginning for your app.

 

※Temple Run app icon used here with written permission of Imangi Studios.

Open Source Code for Developing Sudoku for iPhone and OS X

Posted on by

My Love For Sudoku

I’m a Sudoku addict. My love for Sudoku has most certainly surpassed unhealthy levels.  Naturally, being a developer I at one point had an interest in developing my own Sudoku game just to see what it entails.

The concept of Sudoku is a very ancient one but the game’s recent popularity is attributed to the company NIKOLI which owns the copyright to the word “Sudoku” and the Japanese “数独” (lit: “number alone”) within Japan.

Game concepts, in and of themselves, cannot be copyrighted and to get around any copyright disputes I considered calling my game “9 Lives” and varying the gameplay enough by employing a strict rule of allowing up to 9 mistakes before the player loses. Essentially I was interested in making a Sudoku game for pros (no hints or anything).

However, I later learned through the Quinn/Tetris debacle that even though game concepts cannot be copyrighted, the owners of such games still show their legal fangs if you encroach on their territory and considering that my presence here in Japan is also where NIKOLI is based I reconsidered developing my own game.

That was 5 years ago, when I was just beginning to learn Objective C and OS X development. While cleaning some things up on my Mac I recently rediscovered my old Sudoku board generator code and it feels like a waste to just let it sit there unused.  Instead I decided to rewrite it (the original code is too embarassing to release) and donate it to others interested in making their own Sudoku games.

Most of the Sudoku games I have played only offer pregenerated boards. My code creates random ones each and every time. As such it depends on a random number generator, in this case my JFRandom utility class which is available on github.

If you are outside Japan and interested in making your own sudoku game check out my Sudoku Board Generator.

 

How To Use It

This one line is all you need to generate a random Sudoku board…

SudokuBoard *board = [SudokuBoardGenerator generate];

Outputting the resulting Sudoku board with NSLog will show the board in full like below…

7 1 8 5 4 3 6 2 9 

6 9 3 2 1 8 5 7 4 

5 4 2 9 7 6 3 1 8 

4 3 5 7 9 1 8 6 2 

1 6 7 8 3 2 4 9 5 

2 8 9 4 6 5 7 3 1 

8 5 1 6 2 7 9 4 3 

9 2 6 3 5 4 1 8 7 

3 7 4 1 8 9 2 5 6 


The board exposes 9 sectors (3×3 grid) and the numbers contained within for you to display in your game.  That’s all there is to it.  The details are all abstracted away from you.  If you have any questions please don’t hesitate to contact me at jay [AT] this domain.

Generating Random Numbers, Strings and Data in Objective C

Posted on by

Today I’m open sourcing JFRandom, a powerful utility class for creating random numbers, arrays of these as well as random strings and data.  It’s available for free download over at github.

I’ve been using this class in my KEYBOX product for nearly a year now and I can attest to its robustness.  JFRandom works in both ARC and non-ARC projects for both iOS and OS X.

Whether you need random data for encryption purposes, video game AI, shuffled music playback or just lucky lotto ticket numbers, JFRandom has you covered.

 

How to Use JFRandom

JFRandom is very simple so I’ll just illustrate one-liner examples of the main functionality below.

 

For single random numbers…

NSInteger number = 0;
BOOL worked = [JFRandom generateNumberBetweenLow: 0 andHigh: 100 intoReceiver: &number];

 

For arrays of random numbers…

NSInteger sequence[100];
BOOL worked = [JFRandom generateNumberSequenceOfLength: 100 into: sequence betweenLow: -1000 andHigh: 1000 withOnlyUniqueValues: NO];

 

If you need each number in the array to also be unique do this…

NSInteger sequence[100];
BOOL worked = [JFRandom generateNumberSequenceOfLength: 100 into: sequence betweenLow: -1000 andHigh: 1000 withOnlyUniqueValues: YES];

Note that creating unique number arrays can cause performance issues as the existing selection must be first examined for instances of the next random number to place within.

 

JFRandom also generates random NSData instances…

NSData *data = [JFRandom generateRandomDataOfLength: 16];

 

If you need the bytes to be signed rather than unsigned…

NSData *data = [JFRandom generateRandomSignedDataOfLength: 16];

 

And of course if you need a string full of random characters it’s this easy…

NSString *text = [JFRandom generateRandomStringOfLength: 64];

 

These are the basic capabilities of JFRandom.  There are a few more methods that allow for randomly picking of numbers within a pre-determined array etc…  Check out JFRandom now and save yourself the trouble of coding and testing this yourself!

iOS and Android Fragmentation – A Developer’s Perspective

Posted on by

Disclaimer: The impetus for writing this article is in response to the naysayers in the Android camp who would have consumers and developers alike believe that Android fragmentation is a myth. I’m here to prove that it is not only very real but very costly to dismiss as a myth. In short, I want to arm people with the correct information. I’m an iOS developer and an Apple fan. I have never owned an Android device although I’ve participated in a development project where Android fragmentation reared its ugly head and I’ve also developed extensively for feature phones which exhibited the same characteristics as Android with regard to fragmentation.

What Is Device Fragmentation?

It helps to define fragmentation before going any further.

In a broader context, fragmentation is simply taking one thing and splitting it into fragments. In the context of technology, fragmentation is the act of offering instances of one thing that, while labeled as a single brand, are distinct enough from one another to be considered separate.

By this definition Android is fragmented, as is iOS (albeit to a much lesser degree which will explored later on), and even computers.

Android Fragmentation

So what makes Android so fragmented?  The short answer: Android device makers.

They have to fragment Android in order to compete. Consider the alternative. If Sony offered essentially the same device as Samsung with the same technical specs what advantage would there be in purchasing one over the other? The only alternative would be to compete only on price but that could start a price war resulting in diminished profit margins for both companies. It is therefore in the interest of every serious Android device maker to innovate and outgun its competitors in the Android space (as well as against the offerings of Apple and Microsoft).

Now that I’ve established that the only thing Android device makers share in common is the word “Android” and that they have little choice but to fragment, it’s time to ask the next pertinent question: How does this fragmentation actually take place?

Since Google doesn’t itself manufacture Android devices (Google does work closely with some manufacturers however) there is a lot of wiggle room for device makers. To understand this better let’s look at the breakdown of an Android device…

  • The maker specific hardware
  • The base Android OS
  • The maker specific platform added to the base Android OS

The hardware plays the biggest role in fragmentation. Device makers cater to their respective markets. Some devices lack bells and whistles in a bid to remain affordable for consumers not willing to pony up for a premium phone for instance. At the other end of the spectrum are the Samsungs and Sharps of the world. Below is a list of some areas where makers customize their devices.

  • CPU speeds
  • RAM memory capacity
  • Antenna strengths
  • Storage space
  • Storage I/O speeds
  • Display resolution
  • Display color output
  • Display input accuracy/sensitivity
  • Presence/absence of hardware accelerated graphics
  • Presence/absence of various ports for external media and devices
  • Camera resolutions
  • Battery life
  • The list goes on…

The base Android OS is arguably the area with the least fragmentation. This is the part for which Google is responsible. Some like to view the low penetration of the latest Android OS on newer devices as a kind of OS fragmentation. It’s not quite the type of fragmentation I want to discuss here but it is true that since device makers stand between Google and the consumer, OS updates don’t occur as optimally as with iOS.

The maker specific platform that is slapped on top of the base Android OS is an interesting topic. It renders Android more a meta-platform than a real platform. The Kindle Fire is an example of an Android device that takes great liberties with regards to the UI. In fact, it almost doesn’t expose its Android heritage at all. The look and feel of this layer is one apps that hold themselves to high standards should strive to match when possible and this forces the apps to choose certain devices to support. As an aside, Ars Technica recently reported how Amazon’s market leadership is rendering Google’s control of Android weakened.

 

iOS Fragmentation

Okay I’ve discussed Android a bit, it’s time to take a look at iOS. Unlike the multi-party affair that is Android, iOS and the devices on which it runs are made only by Apple. While this leads to a much less fragmented platform, iOS is not perfectly immune to fragmentation.

Each new iOS device boasts a slew of hardware improvements over its predecessor and with them, you guessed it, fragmentation. Even at a single point in time there are 3 flagship iOS devices: iPhone, iPod touch, iPad with different specifications.  Most of the elements I mentioned for Android above are present on iOS as well.

Supporting many generations of iPhones or iPads can be tedious. However one generation per year is more manageable on the pocketbook. The 4th generation iPod touch is relatively cheap at $199 US and aside from its lack of telephony components is essentially an iPhone 4 and can substitute it for most testing.

Wikipedia has a comprehensive list of iOS devicesand their specs but I’ll focus on the types of fragmentation I have personally found on iOS.

  • The color output on my iPod touch is slightly bluer than that of my iPhones and I’ve had to take that into consideration when designing icons and graphical elements.
  • The iPod touch has only 256MB of RAM despite offering Retina Display resolution which means developers of memory hungry apps need to hand test them thoroughly and optimize for these constraints.
  • GPS accuracy diminishes with the iPod touch and Wi-Fi only iPad since they cannot avail themselves of cell tower triangulation.

And that is basically where fragmentation ends.

To the delight of developers, the resolution of the iPhone and iPod touch has remained 320×480. When Retina Display was introduced the only change was the resolution unit from pixel to point (1 point being a 2×2 pixel area). The new iPad has followed the same approach of staying with a resolution of 1024×768. The iPad’s split view design with its left side table view having the same width as the iPhone’s screen makes it easy to port iPhone apps to the iPad while retaining the same look and feel.

Why should all this make developers happy? We have only ever needed to consider one resolution for our apps on each device class. This gives us the time and freedom to strive for a pixel perfect look without having to contend with container based stretching and contracting layouts that adjust to match various resolutions but look less polished.

 

Ramifications of Fragmentation

I make fragmentation sound like a bad thing. I indeed view it that way. As a developer fragmentation introduces more work and incurs more cost to deliver a quality product.

You could argue that fragmentation is innovation by a different name and that it is good for consumers. More choice, more competition and all that. However there are also grave demerits for consumers. The sheer selection of options can be a dizzying experience comparable to buying a DIY computer with all the trimmings. At the time of this writing Google lists 225 Android devices on its web site.

 

My Experience with Fragmentation

I now want to take the word “fragmentation” from being just a distant, technical concept to what it is really is, a mental and financial burden. Let me share a couple real live experiences I have had with fragmentation. Only then can you relate to the pain and truly understand what awaits you.

Before making its way to the iPhone, KEYBOX was a J2ME app for the Vodafone Japan market. J2ME was, in its day, the only real platform for mobile phone development (BREW wasnt a real competitor). But it was fraught with the identical fragmentation issues that Android developers now face. Each device had a different screen resolution, different color output, different CPU etc… But it was worse, some devices didn’t even support transparent/translucent PNG files or floating point math operations. There was no rich UI toolkit to speak of and if you wanted to make information-based apps with text boxes, buttons and the like you had to contend with the limited selection of device-specific controls with different look and feels. Sun has never been a leader in user interfaces the way Apple or Adobe/Macromedia have and didn’t think to standardize the UI the way Macromedia did with Flex.

I hold myself to a higher standard so rather than settle for inconsistent controls I rolled my own tile-based UI kit that detected the optimal dimensions for windows and such for each device. It was a pain to say the least.

J2ME KEYBOX J2ME KEYBOX

 

I later parlayed my own creative development into professional work opportunities in mobile. The most challenging of which was a DoCoMo J2ME app named Harumin. Harumin was an avatar based television guide and remote control app for the then upcoming Foma 900i series.

(Harumin character – Designed by Spring Design)

Of the 5 devices in this lineup the flagship was the Sharp SH900i and the worst was the Fujitsu F900i. Getting the same code to send infrared signals to a TV from all the handsets was impossible. The Sharp unit was too fast and the Fujitsu unit too slow. We ended up writing device detection logic to throttle the speed. Antenna strength was flaky with the Fujitsu unit and caused us to refactor our network communications logic and last but not least button clicks were interpreted as presses on the Fujitsu unit whereas all other devices considered button releases (the correct way) as clicks.

Long story short, had we not had access to all the devices there is no way we could have made the app accessible across the entire series. Fragmentation was a pain for us, not a plus. It cost us double the time to develop and test our app because of it.

Going Forward

Where I fault Android is that it had J2ME’s failure to learn from but chose not to. Google has now dug itself into a hole from which it will prove difficult to escape.

What attracted device makers like Samsung, HTC, and Sharp to Android was its openness/cost and branding. However if Google were to begin dictating conventions and standards to device makers in a bid to steer Android in a single direction the way Apple does, it may find them abandoning Android and perhaps even spawning a competing fork of it. Even without such moves, Amazon has forked it and it has been speculated that the openness Google prizes could very well be Android’s undoing.

 

Cutting Apple Some Slack

Regardless of how you feel about openness you cannot deny that Apple is in an enviable position. It only needs to answer to developers as it steers the iOS platform forward. There are no device makers to appease.

Apple has kept fragmentation under control but has fallen victim to criticism concerning its tight control over its platform.

Prior to the iPhone if you wanted to make slick games that reached the masses you had to buy a development kit from Nintendo at the ever affordable cost of tens of thousands of dollars. And you had to prove you were worthy of one as well. Nintendo’s pre-sale curation process makes Apple’s look like the wild wild west.

Coincidentally, the only reason one would want to make a game for a Nintendo console like the Wii is the almost complete lack of fragmentation. If your game works on the development Wii it will work on every Wii unit in the wild. The savings in development, testing and support time might just justify the price if you have a hit game and have the money upfront. The Android of this scenario is PC gaming with DirectX or OpenGL which is harder (testing graphic cards etc…) but doesn’t require permission from anybody.

All in all, Apple has successfully struck a balance between the democratization of development for the masses and the offering of a simple platform. For less than $100 a year (and the one-time cost of a Mac and an iPhone) developers can make games and apps. $100 is quickly recuperated even with zero advertising/marketing.

The App Store is such a success that even Nintendo is feeling the heat of Apple’s foray into portable gaming.

Android has tried to emulate the success of the App Store but it has been hit and miss. Independent developers cannot afford the full gamut of even the current generation of Android devices and must pick and choose which devices to target if they are serious about ensuring full support. Such choices are not trivial and involve much research into demographics and device preferences. By the time the project is finished the devices against which it was tested are no longer the latest and greatest as well.

Potential for Further Fragmentation

The rumors of an iPad mini or a slightly larger iPhone never quit. It’s called linkbait and puts food on the table of many a tech writer. Never say never, but so far such reports haven’t panned out. Just recently mock-ups of a purported iphone 5 with a longer screen were leaked. If Apple does go this route it’ll only be if it has found a proper way to allow for existing apps to work well on it and for it to not fall out of people’s pockets. Apple is famous for internally testing products before unleashing them on the public and the form factor we see now exists because it makes sense.

The reason so many deviating form factors exist on Android is not because people are clamoring for them. The marketing departments of device makers are simply looking to “BIGGER is better” as a way to make the public buy their offerings.

It’s still too early to conclude which is better but rather than listen to pundits I’m happy to sit back and watch the market decide.

Conclusion

Android and the innovation it promises are great for the average technology enthusiast but for developers this means dealing with the resulting fragmentation. This can come back to hurt consumers as well. We developers either need to raise prices to justify buying more devices (recipe for failure, especially on Android) or choose certain devices and hope the user base will be big enough.

Apple’s approach is simple and well thought out. It doesn’t need to eliminate the problems that saddle Android because it never created them in the first place. The fragmentation that is present is emergent from obsoleting older models of same device but minimal and even under a severely constrained budget a developer can target a single device and still reach millions of users around the world.

 

The Case Against Universal Apps

Posted on by

Since the advent of the iPad, iOS developers have had the option of distributing universal apps that bundle logic intended for both iPhones and iPads.  But is this a good thing?  In this post I quickly discuss the outcomes of going universal and why they might or might not make sense for your app.

Pricing

You’ve worked hard on your app and you’d like to be fairly compensated for that hard work.

It’s a known fact that iPad users are willing to pay more than their iPhone counterparts for apps specifically designed for the iPad.  If you go universal you’ll have to choose a single, shared price for both devices.  Considering the amount of effort you put in to making the iPad edition of your app that much better for the iPad don’t you think you deserve better?

To add insult to injury, an iPhone user who purchases your universal app will get it for free on the iPad and benefit from the iPad specific parts.  So instead of earning 99 cents for the iPhone edition and $1.99 for the iPad edition you’ll only receive 99 cents, period.

Pricing Experimentation and Sales

You’ll likely be experimenting with your price to find the sweet spot which generates the most revenue.  This number can never be the same on both device classes due to different demographics.

And what if you want to offer a sale for just one device class to bring more awareness to it?  You probably have already guessed that with a universal app you will have to offer your sale price to users of both device classes.

App Size

Why should an iPhone user consume storage space for the iPad specific logic or vice versa?  Storage is at a premium on these devices already.

Code Complexity

Your iPad logic will be living side by side in the same project as that of your iPhone.  You’ll need to detect the device class at runtime and switch between logic.

Staged development

If your time or development budget are strained, you can focus on one device class first by not going universal.  You can determine your app’s popularity after release and decide later on if the other device class warrants a port.

App Store Ranking

Apple views universal apps as being distinct on the iPad and iPhone.  They may share common logic but from the user’s perspective the UIs are very different and any reviews they give reflect the experience of only one of them.  Accordingly Apple separates the ratings and reviews of both device classes in the App Store.  Ratings are believed to major play a factor in App Store ranking so having them separated eliminates any potential for boosting your rank by opting for a Universal app.

When do Universal Apps make sense?

If you have a very simple app that you know will always be free the demerits I mentioned above don’t warrant as much concern.

One merit of going universal is that you can call your app by a single name without appending “for iPad” or “HD” to the title and this can make your app easier to find in the App Store.

Conclusion

In many cases Universal Apps don’t work in favor of developers and in some cases they don’t make much sense for users either.  Careful weighing of concerns should take place first before you commit to either approach.

One thing is certain however, divorcing an already universal app into two entails a lot of effort and can cause confusion for users.  Marrying two editions into a universal app, should circumstances later warrant it, is much simpler.  Just like marriage, you should stay single until you’re absolutely sure you’re ready for it.

When To Localize Your iPhone App

Posted on by

In the past I’ve highlighted some software design mistakes made by others and today I want to point the finger at myself and talk about a mistake I made in localizing my first iPhone app KEYBOX.  It is my hope that this article will help others avoid the same pitfalls I experienced.

I made KEYBOX to scratch a personal itch (digital privacy) and it was first released in 2005 as a J2ME app for Vodafone Japan’s market.As such it was never localized to any language other than Japanese.  That all changed this year when I ported it to iOS.  As the App Store is an international affair I naturally would like KEYBOX to benefit as many people as possible.  The main barrier to this is of course language.

For release 1 I decided to localize KEYBOX into the 4 languages with which I am familiar: English, French, Japanese and Spanish.

I now believe doing so this early was a huge mistake as it introduced two issues for me: serious delays in releasing and numerous layout changes.

In localizing KEYBOX, I underestimated the amount of effort it would take.  There are over 200 text snippets to translate from English.  Using online dictionaries to double check my translations and searching for real-world instances of each text snippet before issuing the final check of approval for each takes upwards of 20 hours for each language.  When you’re only doing this on the side (weekends and some evenings) you can imagine how much it delays the release of your app, which is otherwise feature complete and ready to go.

And then there was the EULA!  KEYBOX is unique in that it requires a rather lengthy EULA to protect myself from users who might be less than responsible with it.  Writing the English version was an experience in its own right.  Writing it in Japanese would’ve been a train wreck without help from my loving wife (also Japanese) and it took over 30 hours spread across 3 weeks.

An interesting surprise was that people in countries whose languages are not yet supported still download KEYBOX, and in droves!  Italy is perhaps one of the biggest markets and KEYBOX isn’t even in Italian yet.  I don’t know if support for Spanish and French is what makes this possible (the Romance language connection?) as KEYBOX is about privacy and I don’t solicit my users for such information.  While I’m sure that supporting multiple languages opens the door to more people enjoying my app, having so many languages supported from version 1 is perhaps less important than I initially thought.

Now to the issue of layout…  In comparison to English, Japanese can be an extremely compact language and most words are only 2 kanji characters in length.  And then there are French and Spanish whose words tend to be much longer than their English counterparts.  This naturally leads to sentences that expand and contract in length depending on the user’s locale.

Before translating the text I was tempted to avail myself of iOS’ ability to auto-adjust font sizes for a statically sized label.  I figured the sentence length wouldn’t vary so much and that an auto-adjusting font size could handle that difference.

I could not have been more wrong.  Doing so resulted in text so small that it was rendered unreadable and sometimes text that gets clipped off by the boundaries of the container label.

I learned, the hard way, that multilingual apps really are better off having multi-line labels with a fixed font size.

Going multiline however introduces a new problem.   It forces us to position controls spaced far enough from each other to compensate for the wordiest languages whose labels will expand the most.  Release 1 of KEYBOX followed this approach.  It worked for the most part but it took a lot of manual testing across languages to make sure the text was readable and that there were no overlapping elements.

I knew that I couldn’t take this approach forever and for release 2 I decided to change tactics.  I developed a high-level, goal-oriented layout utility class that lets me accomplish tasks such as “place this text field 10px under that label and center it on screen” or “left align this label 5px to the right of that icon”.  As a result I no longer have to consider the pixel locations of positionable elements across all locales at once and can focus more on the general look of the UI.  In some ways it works like HTML with the end result being one element following the last but unlike HTML it still retains simple, pixel perfect control.

 

Example:

KEYBOX 1 Without Dynamic Layout

KEYBOX 1 – Without Dynamic Layout

 

Keybox 2 import export

KEYBOX 2 – With Dynamic Layout (Text is directly under cloud image and the warning icon is to the left of the text)

 

I intend to open source this layout engine for those who want to maintain a professional layout for their multilingual apps but my best piece of advice would be to release one language at a time and just get your app out there first!  From there on, you can roll out new languages gradually.

How to Get the Local IP Address of an iPhone 4S

Posted on by

After a long 3 weeks of waiting, the iPhone 4S I pre-ordered has arrived and I’m in the process of thoroughly testing Release 2 of KEYBOX against it.

Today I have found what may be an issue with finding the local IP address of the iPhone 4S……. and a solution that worked for me.  KEYBOX has a built-in web server for exporting and importing backup files and it uses the IP address retrieval technique described in Erica Sadun’s wonderful book The iPhone Developer’s Cookbook to serve and accept these files.

In at least my case that technique is no longer usable for the iPhone 4S only.  The issue, as far as I can tell is that appending “.local” to a host name and attempting to retrieve the IP address via the gethostbyname function results in a NULL pointer to a hostent structure.  Removing the “.local” works but the IP address returned is not local and is not accessible from my Mac, as shown below.

Old gethostbyname

I could not reproduce this issue on my other iOS devices and googled until I stumbled upon the below alternative approach by Zach Waugh.

http://blog.zachwaugh.com/post/309927273/programmatically-retrieving-ip-address-of-iphone

Thanks to Zach, I am now again able to retrieve my iPhone 4S’ local IP address.  I have also tested this approach on my older iPhone 3GS and my 4th Generation iPod with positive results.

New gethostbyname

Hopefully I am alone in this issue but if others are experiencing it also, give this approach a try!