iOS/Web Developer's Life in Beta

At the suggestion of my friend Scott McWhirter, I decided to go to Ideas On Tap and keep an eye on the pulse of the Vancouver technology community. And after spending an evening drinking beer and talking with various people from companies around Vancouver, I began to feel like the only married guy in the middle of a speed dating session.

I have a stable and intellectually stimulating day job that I have no plans of leaving anytime soon, but it was still a nice ego boost to be flirted with by so many companies looking for bright talent. In Vancouver, at least, it seems like if you’re smart and you are a creative developer, there’s work out there to be had. In fact they can’t seem to get enough. But unfortunately for them, a lot of developers here are in the same situation I’m in – happy with their current jobs, challenged but not over-worked, and not too interested in changing anytime soon.

I had an opportunity to meet John Chow with his camcorder, trying to get footage of women kissing one another, but the whole evening was basically one giant sausage-fest, as this tweet from him can attest.  I managed to meet one of the guys behind Mobify.me which seems to be quite an interesting product.  In fact, part way through the conversation he mentioned a great project called “PhoneGap” that they were recommending to people looking for more from their mobile platforms.  We both got a kick out of the irony that I’m one of the main developers of its iPhone branch, but nevertheless it was good to hear that other companies see the value in PhoneGap that we do.

The amazing thing was that the entire night was almost exclusively focused around mobile development and the mobile web.  It makes me confident that I’ve decided to play in the right area.  Not only is mobile development a blast, but it seems to be where the biggest focus is of entrepreneurs are these days.

My interactions with marketing has been very spotty throughout my career. I know and accept that marketing plays a huge role in business, both online and offline, but I just can’t seem to wrap my head around it. I’m one of the types of people that create. Those that sell, and those in the middle that help both types around them either create or sell, are very useful. I just can’t figure out what the hell it is that they do.

So when Jen posted a tweet about a YouTube video about Enlightened Stupid Marketers, I first laughed, and then figured I had to post it here. I don’t have anything else to say. Just watch and enjoy the video.

I’m a big fan of all things Apple, and as you can tell from my past blog posts I’m a big fan of iPhone development. I’ve even dusted off my aging C skills, and have learned to love Objective-C. The one thing I haven’t learned to love, like all other iPhone app developers, is their application release process, and the seemingly arbitrary app store acceptance department.

Don’t get me wrong, I think how Apple fiercely guards the App Store to prevent bad, buggy, or offensive material from getting on there is a great thing. Some of my mother-in-law’s students in the class she works in have iPhones or iPod Touches, and these little 10-year-olds love the little apps I’ve put out. They’re fun, light-hearted, and they get a lot of enjoyment out of these and other apps. It’s reassuring to know that if I install an app, it won’t crash my phone (too badly) or that a child won’t be offended by them (too much).

However, the level of detail they give in their rejections seem both arbitrary and unnecessary. You develop an app and have to throw it over the fence to Apple, after which you wait with no level of detail as to the status, or success, or any sense of progress through whatever queue they have. Finally, you more often than not get a big fat rejection letter that gives you no detail as to why your app didn’t meet their secret criteria.

In my experience so far, this has actually been a virtue. My apps actually did have minor race conditions, or problems on specific platform versions. So, fair enough, I fix my changes and submit them in. But recently, the framework I work with and have been helping develop seems to be under fire from Apple for no apparent reason. And it’s the contradictory nature of their message that is what gets under my skin.

In this long thread on the PhoneGap mailing list, a number of developers writing their applications under PhoneGap have been given rejection letters saying something like:

Upon review of your application, cannot be posted to the
App Store due to the usage of private API. Usage of such non-public
API, as outlined in the iPhone SDK Agreement section 3.3.2 is
prohibited:

” An Application may not itself install or launch other executable
code by any means, including without limitation through use of a plug-
in architecture, calling other frameworks, other APIs or otherwise.
No interpreted code may be downloaded and used in an Application
except for code that is interpreted and run by Apple’s Published APIs
and built-in interpreter(s).

The PhoneGap API implemented in your application is an external
framework.

For those new to PhoneGap, it’s a project that gives you an XCode project directory with Obj-C classes pre-made that allow you to develop iPhone apps in HTML / JavaScript. It wraps up several of the iPhone’s native controls and exposes those capabilities to JavaScript. In this way, an application developer could write their app in a hybrid of native Objective-C code and the iPhone’s own native browser control, the UIWebView.

It seems though that Apple constitues the use of their own controls as a 3rd-party library. Apple’s own developer documentation includes code sample projects, much like PhoneGap’s, intended to get a developer started on using their SDK. Is it incorrect to assume that others can do the same?

Additionally, there are 3rd-party companies such as AdMob, Medialets, and a number of others that provide ads, application tracking, and other resources to iPhone developers. Their code is given to you as pre-compiled libraries, that are most certainly not included on the iPhone when you pull it out of its shrink-wrap. So how is it that all these apps are released to the App Store with these 3rd-party libraries linked in, and an app framework whose source code is freely available and uses officially documented features can’t be?

I decided to put an end to the speculation, and wrote a letter to Apple’s developer support on this matter. I’ll give it a chance to percolate through their support department, and if I don’t hear an answer back via email, I plan to call their support department until I can get an answer.

For future reference, and in the interests of keeping the discussion open, here’s a copy of the letter I sent in to Apple.

From: Michael Nachbaur
Date: May 17, 2009 6:04:28 PM PDT (CA)
To: idp-dts@apple.com
Subject: Library classification clarification

Hello, I’m an iPhone software developer, and one of the core developers of the PhoneGap project. A number of users of PhoneGap – a set of Objective-C classes aimed at leveraging the UIWebView to access iPhone-supported hardware features – have reported that their apps have been rejected from the App Store because they supposedly use a “3rd-Party Library”. I wanted to get some clarification about this, as this is not only untrue, it is completely at odds with the goals of our project.

PhoneGap only uses officially-supported features of the iPhone, as documented within XCode’s iPhone SDK documentation. We even make sure that we don’t even use deprecated features of the iPhone, as we want to ensure 100% compatibility. All the software we use is exposed natively by the iPhone, and is in use in many other apps on the App Store.

So I wanted to get an official clarification from Apple as to why these apps are being rejected, and what, if anything, we as the maintainers and developers of the PhoneGap project can do to rectify the situation. We are trying to empower developers with quality starting-blocks for developing their own applications, much as the Apple sample applications do.

So please, if there’s anything we’re doing wrong, we would more than happily change our code to accommodate Apple’s policies. As far as we can tell, we support Apple’s licenses even better than other apps on the App Store, because we don’t import 3rd-party libraries such as AdMob, Medialets, or any of the other ad and tracking libraries that are obviously featured on almost every app in the App Store. And these are quite plainly 3rd-party libraries, and as such should they not be even more restricted than we are?

As a community, of both software developers and of business-people, we are very anxious to hear back from you, and would like to discuss this with someone at Apple to get an official answer, instead of the conversation being one-sided and filled with speculation.

Thank you for your time, and I look forward to hearing back from someone soon.

What are your thoughts on the matter? Can anyone reading this find some reason why Apple would target PhoneGap?

Update: I got an update on this problem from Steve, one of the app reviewers, over at Apple.

Like many people before me, and I’m sure many more after, I’ve had an ungodly amount of difficulty with Apple’s iPhone certificate provisioning system. I personally think it’s a brilliant solution to a difficult problem, but unfortunately for us they made it a pain in the ass to deal with. I’ve only run up against a few basic issues with them, and thought I’d document my solutions to them here.

And before you say it, yes I know there’s already tons of people complaining about iPhone app certificates, and there’s plenty of pages describing how to fix them on the ‘net to go around. But it was like finding a needle in a haystack for me. There were too many hits on forums and mailing lists that gave bad advice, or weren’t relevant anymore due to updates in XCode and the iTunes Connect website. So I’m summarizing here what works for me, and I’ll leave it up to the reader to figure if it works for you.

Entitlements.plist

These aren’t to be used for Debug builds. This file is necessary for some sort of magic when you deploy an app on the phone for either distribution or release mode. A lot of documentation will explain how you have to create it and add it to your Info.plist file.

This is great, but if you’re trying to figure out why your Debug profile isn’t working anymore, don’t attempt to add the Entitlements file to that build profile. It just makes things come to a screeching halt.

Debug vs Distribution vs Release

This one is annoying, and keeps popping its ugly head up. Say for instance I’ve got my developer certificate that I’ve been using for debug builds. Then I want to test my app on a few phones, so I go about creating a distribution certificate for it. In the project settings pane I change the drop-down to the new certificate, hit build, and *bam* I hit a certificate signing error when it tries to install the app on the phone.

As many people on the ‘net have pointed out, XCode is dumb and doesn’t assign the certificate to the correct profile. Some people manage to play around with it enough to get it to work, usually involving lots of restarts of XCode, removing and re-adding certificates, etc. I find some of that works, but when I get frustrated I just drop to VIM on the console, edit my project.pbxproj file, and change my cert settings manually.

If I’m really in a bind and I can’t get XCode to do what I want, I change my debug certificate to use the one I want for distribution and then drop into VIM. From here I can copy and paste the certificate lines it put in there to represent my distribution cert, and I copy it to my distribution or release build section. Then I change my debug cert back to my developer certificate.

Removing old certs from your system

Sometimes you just need to rebuild a cert. You might have made a mistake, or more often you have another phone you’d like to test your distribution build on. This means going into the iPhone Developer Portal and adding a device to the certificate. This means that the cert will now be different, and you’ll need to download the new provisioning profile.

Ah, but you already have that cert in XCode and, as you might have guessed, XCode isn’t smart enough to replace the old cert with the new one. You’ll just get two certs that will fight it out, and will always lose. So go into the XCode organizer and delete your old certs. You add the new cert, it compiles and signs itself, but when you try to install it on the phone it falls flat on its face.

You can go into the Organizer, select your phone, and remove provisioned apps and provisioning profiles from there. Or you can go onto the phone itself, and go to Settings -> General -> Provisioning, and you can delete your certs manually. Once that’s done, you might want to give XCode a restart for good measure and then add the new certificates from the iTunes Developer Portal.

Wildcard Certificates

I haven’t tried this myself personally, but when I started writing iPhone apps I was under the false impression that a more specific certificate was a good thing, as opposed to using wildcard certificates. But I’ve seen tons of references on the web of people recommending using them, and “You’re just asking for trouble if you create different certs for each of your apps”.

All I can say is…Whoops! I already released two apps to the appstore, and I don’t think I can change my certificates after the fact. Plus, I’m not sure if suddenly switching to wildcard certs for the rest of my apps will be a bad thing. Either way I’ll be doing this for my next app. If I only have 2 apps that will give me certificate pain when I maintain them, then so be it.

Image via Wikipedia

I’ve said it many times before, but as programmers we tend to spendthe bulk of our time working with broken software, and we try to endeavor to make it less broken. When it’s not broken enough to keep people from using it on a day-to-day basis, you release your software. Some places do this better than others, and at my day job we’re really good at it. We are very dilligent about our software releases, we have tons of unit tests, system test automation, a nightly test “dashboard” that shows us how well our tests passed, and so forth.

But even though we rock at our tests, regardless, there are things that we would like to have work better than they do now. That’s what differentiates players in the marketplace. You can have a product that works, but if it doesn’t work as well as your competitors, or it doesn’t solve problems your customers have, then you might as well not be in the game at all.

When to refactor?

So when do you refactor your code? When do you decide that what you have could be improved and you should change the way it functions? Usually this happens as a customer suggestion, request, or demand. Product management may decide that a feature should be added, or an existing feature should be improved. That’s when we programmers dive in, and change what’s there while trying not to break it. Hopefully, in the process, you’ll come out the other side with better test coverage, and will have or improved the code around the areas you were working.

Sometimes this isn’t enough though. What if fundamental design decisions about the section of code you’re working on isn’t up to the task of the refactor? Or perhaps the code has just outlived its usefulness, and needs to be thrown away with the bath water?

When to throw it all away?

Inevitably we just need to set fire to the whole thing and write something new in its place. Slash & burn. This is the decision I’m faced with now. We have a feature that hardly any of our customers use. Some people say it’s because other sections of our product work so well, that this troubleshooting interface just isn’t all that necessary after our customers gain confidence in how well our product works.

I personally think people don’t use it because, well, it’s slow and ugly. It works perfectly well, and all of our tests confirm that it works exactly as designed. But I think the design itself is flawed. Plus, there’s tons of additional features we could develop on top of this code if we re-wrote it.

Why haven’t people asked for this rewrite though? Well, because they frankly haven’t thought of it. As developers, we know more about what is possible and what is there, and it’s our duty to let our users and product management know what could be made possible.

I just had a long chat / discussion / argument with one of our product managers. In the end, I had him excited about what we could build…but it took a lot of convincing.

Frankly, I’m not happy if I just build the features fed to me through the management pipeline. I’m an inventor at heart, and I’m just not satisfied if I’m doing just I’m told. If you give me an established product, with a large customer base, and a sales force that is poised to strike when they get a feature with which they can hit the pavement running, I’ll come up with a ton of ideas to make that happen.

I suppose what I’m saying is it’s not always the right decision to do the obviously safe approach. Sometimes you just have to set fire to something that, on the surface, looks healthy and “good enough”. Learn from what you have, and replace it with something 10x better. From the ashes, hopefully you’ll build something that nobody else in the market place has. From that your company gets a competitive advantage, and as an inventor, I get personal satisfaction that I’m making our product better, and am earning my keep.

I’m now a registered iPhone App Developer! After the usual waiting, emailing, phoning, and faxing that I won’t bore you with because blogs all over the world are full of people ranting about Apple’s registration process, I now have my developer key. (Personally, I don’t see what people are complaining about…it wasn’t all that painful.)

So now that I’ve written two iPhone applications, the first thing I wanted to do was load them on the phone and see how they actually behaved on real hardware. The results were, lets just say, less than thrilling. While they ran and did everything I would have expected of them, there are strange inconsistencies between the rendering of WebKit on the phone vs the desktop.

What went wrong

First off, let me state for the record that these are development versions of my apps, and I hadn’t figured on them working well right away. Lets face it, as developers we spend most of our lives working with broken crap, and try our best to make it less broken. That being said, I’m still an optimist and I had hoped.

First, what worked:

1. The app’s icon, start-up screen, and general layout all behaved. Everything was where it was supposed to be.
2. The app started up fairly fast. The only other app I’ve used that’s based on PhoneGap is the Translink public transit app (since I take a combination of a bus and train to get to work). It takes far longer than most apps to start, so I had expected the worse for my app.
3. Clicking on buttons and other UI elements in my first app worked just fine. My second app, which uses more complicated gestures (pinch, rotate, etc) also worked without a hitch.
4. My JavaScript ran quite well, with only a few minor exceptions.

Now on to what didn’t work. Keep in mind, the list above is a lot longer than I’d expected, so the oddities below are tolerable, for the time being.

1. My CSS transitions are behaving very oddly. Instead of smoothly fading from 0% to 100% opacity, they jump between 0% and 100% immediately, back down to 0%, and then fade gracefully back up to 100%.
2. The toolbar of my app, which is implemented as HTML/CSS, flickers whenever I click on buttons anywhere on the screen. This is especially weird since the events for those buttons, located in the center of the screen, don’t touch or interact with the HTML or CSS attributes of the toolbar in any way.
3. For one of my apps I use an element with CSS sprites. None of these seem to work. When I change CSS classes, instead of changing the background position of the sprite image, it stays in the same skewed position.

Next steps

From here, I think I need to either use CSS classes, or set style properties from JavaScript exclusively. Mixing and matching might be causing problems. What do you think?

However, as I finish this, my wife and my in-laws want to go to the pub. So screw this hacking on frustrating code from home. I’m going for a pint and some appies!

Before I go though, I’m going to appeal to the iPhone and PhoneGap developer community at large: Have any of you encountered these problems before? Do you have any suggestions on how to make things work better?

On the train ride to work today I was listening to “Daft Punk” on my iPhone while reading my blogs, my usual morning activity. And as my mind wandered, the song “Harder, Better, Faster, Stronger” came on; it’s one of my favourites, as I’m an avid electronic music fan. But since I was reading Ajaxian and several other software industry business blogs at the time, the song seemed strangely appropriate. Everyone is trying to find ways of working harder, developing better software, releasing to market faster, and having a much stronger market position (honestly, this is what was running through my head). This made me think more about what I do to fulfill those 4 business goals, so well voiced by Daft Punk.

“Work it harder”

Personally, I like having a life. I have a wife, hobbies, Open Source projects I like to contribute to. And of course I have my day job where I do more than I’m asked to do, always trying to come up with creative side projects to help make more sales, improve the product, or visualize our usage data in a way to help us build a better product.

So given the cliché that we all have 24 hours in a day, and you have sleep, meals, and commute time involved, how do you optimize your daily work habits to maximize that time?

The way we do this at work is through Extreme Programming or Agile Software Development, both are complementary techniques to eliminate waste from the traditional development cycle. Planning documents, requirements analysis, task assignment and many other wasteful planning processes are typically eliminated.

Coming up with a comprehensive specification before the project is even started is dreadfully wasteful. They typically become a hindrance because no developer can possibly foresee what problems they’ll encounter part-way through. These development practices allow a team as a whole to be flexible, to adapt to changes mid-way through the development cycle, and develop the important bits first. If you haven’t heard about or tried Extreme Programming, I highly recommend you go read up on it. Extreme Programming Explained is a great introduction for people used to more conventional development practices.

The important thing I’ve found is that these practices can even be adapted to single-person teams. You have to alter a few things in order to get it to work for a solo team, but adhering to the principles of “Build the simplest thing that works end-to-end first, then refactor later” is perhaps the most important practice I can suggest. For myself, it’s hard to get lost in developing “Teh Bestest Softwares Evar!” Sometimes you have to take a step back, and question yourself as to what is truly important to your project? Go build that, and don’t waste your time with unnecessary frills.

“Make it better”

Cutting out what isn’t necessary, or building the simplest possible thing doesn’t mean eliminating best practices. Quite the contrary, Extreme Programming pushes very heavily on test-driven development. The ultimate goal is to write your tests before you write a single piece of code. It doesn’t have to be a difficult test, but when you first run it, the test should fail. Once you get a failing test, you write the corresponding code for your project to make the test pass. Then you move on to the next task, rinse and repeat. One of the books on our bookshelf here at work is Test Driven Development, and it’s a great book on learning how using tests to drive your development can really help. I actually need to re-read it again, since my test-writing skills are getting a bit rusty.

By stepping through your project one bit at a time, writing tests as you go, you ensure that any regression in your code is caught by your test coverage. If you’re developing applications that a user will interact with, either through a GUI or a web interface, then automated tests are needed to be able to programatically exercise your interface.

We use Selenium within a series of Windows VMWare instances. Our test runner machine spawns VM instances on our VMWare server, as well as installs fresh copies of our software on our test servers. It then runs our tests using a test harness I developed called Test::A8N to be able to execute our tests, remote-controlling the browsers from within Windows.

Along with all these tests, you need visibility into how your tests are performing. There’s no point in writing all those tests, if you never run them. So we have a nightly process that runs all of our tests in parallel across several servers (so that they can complete in a single night), and then renders an HTML “Dashboard” showing which tests passed and failed, summed up as Red, Yellow or Green. A wide-screen LCD display is easily visible by the entire team, and shows us at a glance just how we’re doing. If you see large patches of red, then you know you’ve got some bug fixing to get to today.

There are other philosophies behind both Extreme and Agile programming, but I won’t get into them here. I highly suggest you read one of these books, as they’re really eye-opening into how you can develop better software without the traditional pain and bureaucracy found in more traditional methods.

“Do it faster”

With all this attention to detail and automated tests, it’s important that your development is still faster than the traditional ways of writing code. Sometimes you have to throw out what isn’t working, and this includes your preciously-written code. If something that served your purposes a year, 6 months, or even 2 weeks ago isn’t serving you anymore, then it’s time for it to go!

Refactoring is the process of taking something that worked before, and altering or culling what doesn’t fit anymore, and writing fresh code to replace it. Many times this means throwing entire chunks of code away. It’s important to not be married to your software. It’s just work, you’ve got plenty more where that came from. Just write what is needed, and nothing more. Don’t over-engineer, since that future “Maybe” feature you’re coding for most likely won’t be needed or used anyway.

Case in point: here at work, a former employee had written a UI framework that all our UI pages were built upon. It handled navigation, Ajax code execution, and so forth. It served its purposes very well at its time, but as features were added it became more and more brittle. Finally, shortly before I was hired, they added localization support, and it broke the camel’s back. Developing new pages was tedious, time consuming, and was littered with unused features that no one knew how or even if they worked.

After a short time of dealing with this, I cut it all out and replaced it with something smaller, lighter, and custom-fit to what it was we needed to do. It cleaned up our URIs so they were easy to understand, sped up development significantly, and gave us a stable platform to continue our subsequent refactoring on top of. All of this, and we eliminated approximately 3,000 lines of code. We’ve settled on the MooTools JavaScript framework for our code, and extend it liberally to build our client-side Ajax UI.

The framework is still holding up a year later, though I know it will have to go through some growing pains later. It’s currently Apache2/mod_perl based, and we’ll eventually be ripping this out and replacing it with a lighter FastCGI wrapper. But the important thing to take from this is that we weren’t so tied to our code that we weren’t afraid to throw it away when it started to smell.

“Makes us stronger”

The end result of all of this is to improve everyone’s lives. The developers have more fun at work, the project gets completed faster, more value is delivered to the customer in a timely fashion, the shareholders make more money, and the business improves.

Therefore I like to find areas in which I can help the company. Partly because there are many more interesting problems than just what I work with in my day job. So I write tools to help the salespeople sell more software. I write tools to help the product managers identify what our customers need and use. I’m currently working with our documentation team to find new ways to represent our documentation to make it more visible to our customers when they need help.

Ultimately, if you think outside the box and thing about your project from your customer’s perspective, it opens up a much bigger world for you to find your niche. Forget about what your job title is or what you’re being tasked to do. What problems do your customers have? If you had to use the software you’re developing on a day-to-day basis, would you enjoy yourself? Or would you pick up the phone and try to find a new vendor?

There’s a great rant over on Seth Godin’s blog titled “Just doing my job.” Don’t hide behind your job title as an excuse to justify your company’s actions, and don’t use it as an excuse to be lazy. Expand your skills, help your customers solve real problems, and don’t write bad software.

“More then ever after, our work is never over”

Most importantly than anything, never blindly accept that what you’re doing now is the best there can be. Newer technologies are developed, better strategies for developing or planning software can be invented, and people become complacent. Always read, always learn. Attend conferences, teach others what you know so you can understand your craft better.

So it’s very fitting that the last phrase in Daft Punk’s “Harder, Better, Faster, Stronger” is this: “Our work is never over”.

Yesterday at the Elephant & Castle Pub I was talking with a friend who’s decided to finally take the leap and move into doing business as a free agent. He’s filing all the business applications, getting consulting jobs (he already has 2 long-term gigs lined up), and is going through the motions of becoming his own business entity. All that’s left is a name.

Web businesses aren’t bound by the same requirements of conventional businesses to have a relevant name, but we have different problems. Do we pick a name from a bag of industry buzzwords, and sound like we’re the company from Office Space? Do we create a name that accurately reflects what you do as a business, and sound like a group of pocket-protector-wearing dweebs? Or do you go to an extreme and invent a unique name that means absolutely nothing, and gives the customer no inkling of whether or not you’re a business or a toilet scrubber? That last one feels like the DotCom days all over again, and while it may have worked then, I doubt it would lend much credibility these days.

We do have a lot more leeway when it comes to naming technology businesses though. We can stray a bit towards the “Funky Widget” sounding names from the DotCom era, but too comical and you sound, well, like a joke.

Domain names are also an issue. Once you have a name, you have to check and see if it’s available. I’ve always been too cheap to bid on a squatter-owned domain, and have always preferred to change my business name rather than buy an already registered domain.

When I was discussing this with my friend however, I realized it’s been a while since I tried to pick a business name. My last business I just gave up, and named it after myself. “Michael Nachbaur Consulting” sounds really bland, but when you know your customers on a first-name basis, and you’re a one-man shop, there isn’t much need to get too crafty.

If you’re reading this, what would you use as a business name, and how would you pick one? Do you take words describing things you love and combine them? Or do you pick, for instance, a colour and something from nature? (BlueWave immediately comes to mind). How would you come by your business name?