Monthly Archives: October 2012

On CocoaPods

At first glance the CocoaPods library management system seems like a little bit of extra ceremony, an otherwise obscure configuration file that adds to the complexity of an OSX or iOS build without offering any obvious advantages. It does replay a little bit of study though.

Consider the one way of including an open source library in your build from Github.

  1. Google the library name to find the Github location.
  2. Download over the zipped source code.
  3. Unzip it and move it into your build directory
  4. Add the file to your XCode build 
  5. Repeat whenever the library changes

or with CocoaPods:

  1. Add the line ‘pod <whatever>’ to your Podfile
  2. type ‘pod install’

The CocoaPods system needs to be installed on your development Mac first of course. Here’s a handy Ray Wenderlich tutorial on how to do that. Note that Mountain Lion will throw an error about documentation while doing this. For the purposes of CocoaPods, that error can be ignored.

Advertisements

Return of the Native

I’ve been creating iPhone apps in a casual way since 2010. I’ve currently got 3 in the AppStore, another one in alpha – the Shangri-La diet timer – see my other blog for details, and one more in the early planning stages.

They are all native objective-c programs event though I’m perfectly comfortable with the alternative HTML5 website approach.

Until fairly recently, I made this choice without a great deal of introspection.  I write code personally and professionally, because I’m curious and interested, and for me that requires new ideas. I’ve got lot of experience wrangling HTML and HTML5 but only a couple of years with Cocoa, so the Cocoa way generally wins by default.

However, a friend of mine has been talking about a cross platform project for several months and the technical approach has never been entirely clear. Do you create a mobile website that in theory works on iOS, Android, and perhaps Windows 8 in days to come ? Or do you create a native version of your product one per platform ?

To my mind, the answer has never been entirely clear. Its only in the last few months that I’ve formed a definitive opinion, which is as follows:

Unless you have a content heavy product where the content is changing every few hours – go for native.

The fundamental reason is that on a mobile device or tablet, HTML5 generally represents a compromised user experience and it’s unlikely to improve for iOS or Windows in the near future. There can be no doubt as to the current state of affairs – Mark Zuckerberg’s remarks on the Facebook app may have opened the floodgates on the question, but the general discussion has been going on in the background for some time now.

I sat through a talk held in London last week by one of the people involved the the original ‘The Week’ – it’s a native app. During the Q+A session, the question of HTML5 v. Native came up and he mentioned that the FT took the HTML5 approach and had spent a great deal of time an effort trtying to replicate native mobile look and feel across platform with HTML5. To be fair to them, they seem to have pretty much reached their goal, but it seems they achieved that at huge cost.

If that’s the current situation, why won’t things get better in the future ?

It’s simply that there’s no economic forces driving Apple (and that perhaps will be driving Microsoft) to improve HTML5 beyond the current point on their mobile browsers. Every app that comes onto a mobile via a clever web site is an app that didn’t come through their app store and thus represents an opportunity cost. There are no laws requiring a company to implement a standard perfectly, and Microsoft in particular has a long history of slightly odd interpretations of public standards. Google of course would like HTML5 to work properly everywhere on mobile and it certainly will do on Android. But if a technique only works on Android, that’s not cross platform.

I can’t see this situation changing.

Which leaves the question of rapidly changing content, why the exception ?

One of the things I find very annoying about content sites is that when I happen to hit a story via a mobile browser and it offers me the ‘opportunity’ to acquire their mobile app – which is native of course. This is the point when my blood pressure soars and the urge to spit comes hurtling down from the brain. First of all, the opportunity is invariably in the form of an alert which I have to dimiss before doing what I wanted to do which was to read the story.

Second of all, if the content is changing rapidly, I almost certainly did not arrive directly but either by a news aggregating web site (Hacker news, reddit), or an aggregating app such as Flipboard, Tweetbot, or Firehose. I’m certainly not looking to read other stories on that destination site, just because they are on that site. When and if I come back again it will be via my aggregator.

I don’t want my tablet covered in apps, however lovely their UX, which simply give me content from the DailyTechTimesMail.com or whatever. So all they are doing is annoying me and making me less likely to look at the accompanying adverts.

A quick test post

I’m intending to use this blog to document my developments, and act as a resource for various niggley technical question for myself, and others.

Hello world!

Welcome to WordPress.com! This is your very first post. Click the Edit link to modify or delete it, or start a new post. If you like, use this post to tell readers why you started this blog and what you plan to do with it.

Happy blogging!