Category Archives: Uncategorized

Hey, Forbes, Get real (sources).

When it comes to Apple and Google, I’ve come to expect a lot of sensationalist journalism.  Apple is hot, their success stories are hotter, and their losses burn brightest of all.  Facts and accuracy go out the window in the name of clicks.

When reading a source as prominent as Forbes, however, I would expect a bit more where accuracy is concerned.  Recently, they published an article stating that Android’s web share had exceeded Apple’s.  While the article was well-written, their source, an article from Pingdom, is a cluster of completely fictional data, with nothing to back it up.

Let’s begin with the assertion that Android is leading in mobile web usage.  This is wishful thinking at best, but it could be extremely costly when it misguides the mobile development efforts of a large corporation.  The truth is that the gulf between the two platforms is still massive and possibly growing; Android is nowhere near iOS.  Here’s some recent NetMarketShare data and CNN context:

On to the next assertion: Samsung as the top smartphone manufacturer.  This, too, is false.  In smartphone sales, Apple is top, and increasing its lead.

“Android is everywhere you look.” They’re definitely not looking in the same places as me… maybe Korea?  Let’s ask our youth:

Here’s some truth:  The only statistic in which Android bests iOS is in number of units moved, and that’s because they come free in specially-marked boxes of Cheerios.

The only reason to use an Android device is because you’re a geek who has the savvy and desire to do the work required to administer and manicure the Android experience; someone who understands what a process manager is and why you want and need one on Android; and, based on statistics, someone who doesn’t think they should have to pay for software.  There are plenty of people like that who want a smartphone.  I’m easily geeky enough to be one of them; however, I have an appreciation for the work Apple does to bring complex solutions to the masses.

I see non-geeks struggling with Android devices constantly, putting up with little glitches, crashes, and inconsistencies whenever they use their devices, even to do something as simple as change a contact’s information or send a text.  For them, for me— for the vast majority of consumers, who just want a phone that works for them— an iOS device is a better fit.

Those Who Do Not Remember History…

It seems like there are two groups of mobile developers out there.  The first group thinks that using HTML5 with PhoneGap (or a similar tool) will save them time and money.  The second group feels that such a setup adds complexity, removes a lot of the polish from your app, and ultimately adds significant costs to development.  I find myself in the second camp, despite a rapidly-growing number of developers who would disagree with me.  As I watch mobile developers (mostly former web app jockeys) gush about the potential of hybrid HTML/Native apps, flashbacks of every write-once-debug-everywhere toolkit I’ve ever used spring immediately to mind.  They’re not pleasant memories.

I can certainly understand a lot of the arguments.  If, for example, you’re doing native iOS development, you have to hire people who know Objective-C/Cocoa.  It can be hard to find good people with that skill set.  There’s also the tendency for native development— when tackled by inexperienced resources— to be more expensive than web development.  So, you might figure that since you can find a ton of HTML developers, you’ll just switch to HTML5, wrapped with something like PhoneGap for access to native-only features not available via the web.  Problem solved, right?  Perhaps, but now you have a whole new set of challenges.

Proponents of hybrid development tend to ignore several important factors that are sure to impact both the cost and quality of their applications.  First, it’s just as hard to find really good HTML developers as it is Cocoa Touch jockeys, and if you want any kind of polish at all, you’ll need the best web talent.  Second, these teams are actually increasing their staffing requirements from a single core competency to four of them:

  • Core web skills (HTML5 / CSS / JavaScript)
  • A rich web app framework (Sencha Touch, JQuery Mobile, etc)
  • The PhoneGap framework and tools
  • Apple’s iOS development suite (Xcode, the Objective-C language, and the Cocoa Touch frameworks)

Good luck with your hiring.  Third, you’ll spend a ton of time with caching and loading strategies to make the app feel smooth, not to mention all the UI tweaking and everything you’ll need to do to get it just right.  It’s so much effort that, in my experience, most hybrid development teams simply don’t do it— their apps ship with a depressing lack of polish.

Finally, you’re at the mercy of a third-party compatibility layer to be timely with updates when a new system version lands, or when bugs are discovered; if you want to get the newest features in the latest iOS integrated with your app as quickly as possible, native is the only way to go.  Any other approach will automatically put you in “fast follower” territory, at best.

Please note that I’m not saying that if you’re doing native development, your app is automatically good. There are a lot of ways to do native development wrong, and indeed, it seems that most native development groups are working far harder than they have to in order to bring their apps to market, while still ultimately releasing mediocre products.  If you want to save time and money, there are myriad ways to improve your approach to native development without hopping aboard the “Native development BAAAD!” bandwagon, and you can improve your customer experience at the same time.

Start by getting your house in order from the bottom, upward:

  • Make sure your web services are smart enough that you don’t have to code a ton of client-side business logic to decide what UI elements to present.
  • Clean up your model and networking layer so you can avoid a potential mess of spaghetti code every time you add a feature.
  • Simplify and unify your component library, eliminating or merging all of the one-off UIView and UITableViewCell subclasses you’ve got floating around that probably all do the same thing.

Most importantly, strive to create application designs that allow you to use as many built-in framework objects and patterns as possible.  I’m not saying that your app should be boilerplate; devoid of style or brand. I’m saying that you should go get the human interface guidelines for your platform, and follow them.  Learn your frameworks, and understand which customizations are easy, and which might be avoided to prevent headaches.

If you’re creating a ton of objects and patterns to sidestep the framework, it’s likely that you’ve entered the “should be avoided” category, and your app needs to be redesigned.  Those “workaround” objects are expensive twice: they’re difficult and time-consuming to plan and create, and then they’re the first objects to break when an OS update lands, causing you to spend time and money patching them to preserve functionality that probably shouldn’t be there at all.

Designed in the USA. Made in the USA.

On my quest to find an awesome iPad 2 case, I have discovered that the spirit of entrepreneurship and craftsmanship are still alive here in the USA. The guys at grove, who are based in Portland, OR, do absolutely amazing work, and ultimately, I gave them my business.  However, I wouldn’t want to sell short companies like Blackbox, who are located in Golden, Colorado; or Rustic Case, which is in Templeton, MA.

I went through dozens and dozens of case options before picking grove’s, and I know it’ll be worth the wait to get it.  The best part of the search, though, was finding that the most beautiful, elegant, innovative products were designed and hand-built by happy workers, with genuine quality and safe materials, by companies right here at home.

Microsoft How-To: “Porting” From iPhone to WinMo.

Microsoft has released an article detailing how to port a particular Cocoa Touch to Windows mobile. The catch: the app in question relies particularly little on the Cocoa framework, it handles its own widgetry and visual display. This is rarely the case in an iPhone app… most of them make heavy usage of UIKit and Foundation objects to get the job done. The best advice for porting these apps? Don’t.

There is no analog to most of the Cocoa Touch frameworks on Windows Mobile, and most WinMo devices simply can’t DO at the hardware level what a lot of iPhone apps take for granted as basic device functionality. Porting an app of any complexity will usually be nigh impossible… it will require a complete rewrite. The rewrite process is basically what Microsoft’s article details. The same goes for Pre, Android, or Blackberry.

For any given app, when you’re beginning development, Microsoft would probably advise that you not use any of the frameworks Apple has provided, outside of basic executable functionality, opting instead for custom drawing routines handwritten by the developer, or using only the most basic shared libraries. This would definitely benefit their platform, as your app would be easier to port, but it would entirely negate the rapid app development advantage offered by the iPhone (and Mac OS X, for that matter) frameworks over every other API out there. And to top it off, you’d be going through all this extra effort for what is becoming an ever smaller marginal increase in revenue.

While I do recommend creating code with an eye toward portability (especially stuff like custom drawing or OpenGL code), my advice to developers seeking to do a multiple-platform release is the same advice I’d give to a desktop developer: create a common C library for handling proprietary data formats, specialized encryption, custom communication protocols, etc. Then, build your UI using the native frameworks available on each device, taking advantage of each platform’s special functionality, and maximizing the fit and finish for each.