I attended my first NSConference this year after grabbing the first ticket that became available to people on the waiting list. The conference had sold out in record time before I was able to make a decision. So I jumped at the chance when they gave me a second chance.

NSConference is held annually in Wokefield Park in the middle of a golf course. Scotty, the conference host, informed us that the reason for this is simply to force the 200 attendees to network amongst each other if only because you cannot easily drive to town.

After the conference we were asked to provide feedback via e-mail, but I am a firm believer doing so publicly because this enables the valued reader to form his own opinion and whether he should attend NSConference 2013.

When I knew the dates I will be at the conference I booked my journey to include the day before and the day after simply for the fact that I don’t like to stress myself travelling to and from the venue. 5 days in total is about the duration that I can go with only a small trolley while still having fresh clothes every day. Travelling Pros swear by this technique of not having to give up their suitcase on the airplane.

Arrival

You fly into London Heathrow. The most comfortable direct route involves taking a Railair.com bus from Heathrow to Reading (pronounced “Redding”) and a short train ride from there to Mortimer station. Though we did what most Apple fanboys would do shortly after release of a new Apple product: we took the underground to Covent Garden to visit the new Apple store located there.

A short time thereafter we had acquired several new Retina-iPads “for testing!”, Apple seems to get the hang of distributing their iOS devices, there where plenty available as we could see from several stacks arranged on the table behind the counter, sorted by WiFi/4G, size and color. I would have been nice to have a dedicated WiFi to restore an iCloud backup right then and there, but with only the overloaded free Apple Store WiFi available I left my iPad 3 in the box to perform the unboxing ceremony later in the hotel.

http://www.youtube.com/watch?v=b12o4R4c8mo

From central London you take the tube to Paddington station, but you should plan your route before starting your journey because London transport is frequently shutting down entire lines for work. We ran in to such a dead end once. From Paddington you again take the railway to Reading.

Good Causes

The event itself is organized in a single stream of talks interleaved with so called “Lightning Talks”. I was told that in previous years you had to go elsewhere to view the short talks, but this year you could simply stay put and only leave your seat around large round tables for lunch. Speaking of food, that was quite excellent as well, with a good sized buffet-style meals for breakfast, lunch and dinner. Dinner was organized such for Monday and Tuesday with Monday set up as more luxurious gala diner and Tuesday being Casino night.

Casino as in gambling, though only with paper money. The person who had the most paper capital at the end of the evening would win an iPad. I would have loved to be able to re-buy more chips in the course of the evening because I lost all of my starting capital on the first Black Jack table I went to.

Scotty is always doing a charitable thing as well, this year one cause that aims to provide safe drinking water. The raffle winner go a MacBook Air that was donated by Marcus Zarra of Cocoa is my Girlfriend. I bought a couple of raffle tickets, but as I said before I would think that allowing me to re-buy on the casino evening would have increased contributions even more.

Conferencing

There is one trap that most conferencing beginners fall into. You stick with the organized program and thus you stay glued to your chair. But the videos of the talks will be made available later anyway. So if all you do is attend the talks you are missing out on more than 50% of such a conference’s value.

This I had already realized when I attended the 2011 WWDC, but found myself sucked into the single-stream just the same. With the brain turned into jelly with all this valuable information you find yourself mostly unable to make sensible human connections later in the day. Not even helped by strong coffee or lubricated by alcoholic beverages.

Away from the main stream there where several small gatherings that where titled “Labs”. I found myself drawn to the CoreData lab manned by Marcus Zarra and I stayed there for a major portion of Tuesday afternoon. On the Labs we’d know from WWDC you would bring your code and tackle individual issues one-on-one with an Apple engineer. The NSConference Labs work differently, more akin to a Q&A session where you learn just as much from other people’s questions. Mine revolved around background-updating a CoreData database and I found the differences between iOS 4 and 5 quite enlightening. (Yes, I’ll blog about that once I get a chance to)

Alex Blewitt did a series of excellent summaries on the 3 conference days:

• Day 1
• Day 2
• Day 3

The great opportunity for an NSConference-newbee is to get to know the European All-Stars and try to take on a bit of the wisdom of the likes of Aral Balkan, Matt Gemmel, Marcus Zarra, Nathan Eror, Ross Carter, Mike Lee, Jeff LaMarche, Daniel Pasco and Fraser Spiers. Naturally those where the ones with the best presentation skills as well. Again, the presentations can be seen on video, but only attending the conference allows you to also approach these guys and ask more detailed questions.

The main message that I got was that I realized that I am a “Subject Matter Expert” on CoreText. This is a topic that I know really really well through my work on DTCoreText and where companies have hired me in the past to help them with it. Daniel Pasco’s talk was the first time I saw somebody include pictures of himself doing the face-palm in combination of mentioning the Radars he filed for severe CoreData shortcomings.

The talks of the above mentioned experts all where amongst the creme de la creme of presentations. One example was the one of Fraser Speirs who provided insight into developing apps to be used in schools. Fraser is one of few Apple Distinguished Educators for his efforts in being amongst the first schools in Great Britain which established a program providing one iPad per pupil. This was the talk for which I took the most notes for.

In between those presentation giants you would also find the occasional gem of a newcomer for whom a lightning talk would be the first time speaking in front of 200 people. Given these circumstances most did a good job, in particular I would like to highlight Peter Steinberger – who I know from Cocoaheads Vienna – whose presentation about selling iOS components contained much valuable information for myself, selling components too. For one thing – thanks to Peter – I am now pondering automating the sales process with Fastspring.

Other take-aways included an NSConference T-Shirt and a mug. And about 70 new followers for me on twitter.

Critique

With all the greatness there were a couple of things I didn’t like. The 3 design talks would have been brilliant by themselves, but next to each other they were a bit redundant. Seeing pictures of real-world UI-failures is funny the first time, but much less three times in a row.

Then there were some talks where you would watch and wonder where they are supposed to go to. For one design talk the speaker employed a keyboard to show at great length how a certain melody of a Guns&Roses song would be constructed. Puzzled faces all around. Yes, nice idea, but much too long and much too little relevant for iOS development. Other speakers would blab on without aim making me wish I would possess the guts to stand up and walk out.

In the future NSConferences should maybe split off the design stream into a parallel stream. As I mentioned above I am not a fan of the single-stream concept. Having to pick which talks to attend from two streams would give people more reason to mingle and chat and ask for each other’s opinions. At the same time you wouldn’t watch all design talks in a row – unless you are totally into it – and thus avoid the feeling of redundancy.

The “Labs” are also great to loosen it out a bit. If you know that a conference is offering these then you are usually wise to come prepared and have some concrete problem and/or questions. We didn’t know that there would be labs and so some of their value were lost to us.

Just like designing a compelling app requires you to choose which features not to implement, you should also chose times when you don’t sit passively in a talk but rather use the time to mingle or go to a lab. This keeps your mind fresh and will also give your conversations more spice.

Though at times I felt a bit embarrassed when going for such a mingle-break (and coffee) but almost all other attendees having other plans. I cannot say whether this was because of the single-stream concept or because almost all talks where appealing to the mainstream audience. Or because most people didn’t know that they are not doing themselves a favor by slavishly attending all talks. Or because of a sudden addiction to playing “Draw Something” that made people forget that there are actual new friends to be made instead of playing with virtual ones.

As for all conferences it pays to be prepared. Thought his preparation shouldn’t be simply to chose the talks to attend to, but rather have some topics that you are interested to explore given access to an appropriate expert. It certainly helps if you have source code to discuss. But if you don’t have any code project you can have them look at then you should at least try to have a few good questions to ask.

It also helps if you put your apps and demos on the iPhone and iPad you are carrying around at the conference. You could see groups of people form around people who were showing off BETA versions of their current work in progress. By the same token your apps are sort of your calling card. “Oh cool, YOU are the guy who made this app I love?”

Some Ideas

If I had only one suggestion to give, it would be to intentionally break up the single stream concept. I’d love to attend some afternoon-long workshops to work with like-minded developers on actual code. Many iOS developers are interested in expanding their horizon towards also developing for the Mac app store, but lack an introduction on how to approach this transition.

A few other conference attendees suggested that Scotty should be doing a live taping of the iDeveloper podcast. With all the conference audio equipment already set up it would probably be any easy thing to have the moderators sit around a round table on stage and record the show. Maybe even include Q&A from the audience.

As design is stressed more and more it would have also been nice to have sort of an NSConference design award open for apps by developer who attended the conference. The audience could be voting on their iOS device and thus have participation in the appreciate of good app design.

Scotty seems to have understood that the need for networking and access to experts is beginning to outweigh the need for a single-stream talk-show. Hopefully I am not alone giving him this sort of brutally-honest feedback so that he can avoid NSConference losing its status as the premier European conference for developers on Apple’s platforms.

When the Carinthian branch of WKO – a public office supporting the local economy – contacted me to hold a workshop at a tech fair I jumped at the chance. Not just because I like the limelight, but also because it was my first opportunity to make extensive use of Keynote.

I had only played a bit around with Keynote so far, but did not have any reason yet to put together a full slide deck, animations and all. It took me a day or so to figure out all the features of Keynote I needed to make my presentation worthy of one representing Apple. To top it off I was wearing a black T-Shirt with a white Apple on my chest.

Due to bad weather we had less than half of signed up people actually attend the workshop, so I was able to include several of the attendees and their personal reasons for looking into app development. Funny, how I feared that I could never fill 4 hours with interesting material. Only to find out that I did and I ended perfectly on time.

Due to the setup in the workshop room I could not have stood behind the bar table on which my MacBook Air rested. People would either not have seen me, or I would have been casting a large shadow onto the slides. Instead I had to stand on the other side of the stage. From this distance you want to be able to control your slideshow and possibly be able to see the currently showing slide without having to turn around all the time, thus losing your audience connection.

You can either use the Apple Remote to control Keynote, or way cooler, the remote control app which is available on the app store. I had to have the WiFi technician disable Access Point isolation so that my iPhone would be able to my MacBook. Strangely it does not work over Bluetooth even though both devices have that.

For speaking I had a headset hanging over both ears and with the sender in my back pocket. The friendly local media technician provided a hand microphone to pass around so that people would be able to hear their peers’ questions. It was a very good idea to check out the stage and tech on the evening before the event to familiarize myself with the setup. Also I was able to make sure that my Mini-Displayport-To-VGA dongle would work well.

To avoid being disturbed on my iPhone I disabled push notifications for tweets as well as set it to airplane mode. Then I re-enabled WiFi. This way the battery easily lasted the entire duration of the presentation.

Sorry if the presentation is of little use to you being in German, but you can still look at the pretty pictures and infer some meaning from them.

Von der App Idee zum App Store Erfolg

If you recognize some of the contents then that might be because I heavily borrowed from some talks held by Apple, especially “Ingredients of Great iPhone Apps” which you can view on the iOS Development Videos site.

I found that one great way of including snippets from other sources simply by means of adding them as screenshot and then putting a photo frame around it. If it is a picture to have the frame with the shadow at the bottom. For snippets the torn edge looks fabulous. In some instances it made more sense to quickly transcribe the percentages for a pie chart or the cells of a table into Keynote to have a more consistent look.

Taking a page out of Steve’s book I liberally sprinkled several slides throughout the presentation just containing a single word or number as well as several that quoted a popular adage. I couldn’t avoid having some bullet lists, but having them mixed with other types of content worked rather well, as opposed to a presentation that would consist of nothing BUT bullets.

Apparently my presentation was well received, quite a few attendees where interested in getting my slides. So to them I provided the original Keynote file as well as a PDF “Printout”. But for the general public I uploaded the PDF version to Scribd where it now resides for your viewing pleasure.

Lastly I want to give some props to the advertising agency fussi.at organizing the e_day for WKO. Their professionalism and friendly manner in which they helped me get organized and set up was clearly part of the reason why the 4-hour event went so well.

I was given the compliment today that when asking a question on Twitter I would usually give an answer for all other people interested in the topic. I didn’t do that consciously until now, but I want to start this tradition with this article. Also if I was not following the respondents until now, this prompted me to do so.

You know, the situation is dim, we have too many developers attending WWDC and yet not enough to go around letting themselves be hired.

In preparation for a brainstorming on this subject I asked this question: “Looking for some good suggestions where a company looking to hire fixed staff iOS devs would find people. What would you recommend they do?”

These are all the answers I received, if there are more I will add them to this post.

Network

I’m too thinking that social networking might be one of the better ideas. In the USA LinkedIn seems to be the professional network of choice, whereas in Europe people tend to hang professionally in Xing. Some people also swear by Facebook, but I still cannot see the point of using it professionally.

Twitter is an excellent place. just say there’s an opening in “xxx” and post a link to more details about the offer. - @chronic

Xing? - Steffen Kluge

Start Young

If you cannot find fully formed iOS pros, then it might make sense taking a step back and seeing if you cannot find some “raw materials” and form them into diamonds yourself. I’ve myself seen several youngsters learn the ropes at record pace and quickly surpass me in “mad skillz”.

Go to universities I think it’s kinda hard to find iOS devs quickly. Some propaganda on universities would probably help. - Jernej Strasner

Have an open mind about telecommuting and in addition to the normal staffing strategies, find blogs and contact devs directly. I think at this point, having an onsite staffed iOS dev team is incredibly difficult. Unless the hiring company is willing to hire people with no experience but a passion to learn and teach them. - Anthony Zatelli

Financial Incentives and Faith

Money might be one of the most fundamental motivators. I’m also thinking that every developer likes to be courted and pampered like an undecided bride.

pay lots of money? - Martin S

Whatever method you choose, I suggest adding “hope and pray” to the list. - Jerry Jones

One gem came in e-mail, specifically about relocation help and incentives.

I wanted to give my two cents in regards to your post about hiring on
staff iOS devs as I just went through this process. Because the talent
pool is so small here in the US compared to the demand the incentives
have got to be huge. I don’t just mean money. But money is part of it.

Two weeks ago I went through a very lengthy interview process with
████████████ apps in Dallas, tx. However, their compensation package
just couldn’t beat the counter offer that my wife’s company came back
with. Their offer was extremely fair, but to make it over the top
companies are going to have to do more when it comes to relocation.
Everything from the amount of money to move, time frame, buying the
existing house the candidate is already in, temporary housing, etc.
Devs like me with a wife, kid, mortgage, schools, insurance, etc. have
to take all of this into consideration when accepting a new position.

I ended up taking a new job last week with VW in Chattanooga, tn.
Their benefits we as good and certainly the talent is like what it is
at ████████████, but the relo was amazing and the cost of living in
Chattanooga is far cheaper.

The guys from ████████████ did tell me that they are having a hard
time as well finding iOS devs on site and I get calls everyday from
recruiters representing companies who are willing to pay top dollar
for devs. Landscape here is great for people like us.  - Cory Wiles

Your Input Please …

What other suggestions would you add?

What would you require from such a company looking to get you interested in working for them? Fame and Fortune? To what lengths do you expect a company to go if they truly want to hire you?

Ah and if you really must know … the company that is near to my heart and that is looking to hire is Scribd.com in San Francisco, quite close to the Moscone Center and with several amazing iOS developers already on staff. Take the virtual go-cart tour of their office. Come on, mail them your CV, you know you deserve it.

Everywhere I travel I generally try to find some local meetup of iOS developers to hook up with. Let me be honest, admittedly, one of the reasons why I like to do this is that often developers would mention in passing that they have heard about my blog or know me from following me on twitter. One word: ego.

But this is not the sole reason for this interest. I am possessed by the idea that if developers in any field – iOS in my case – would organize and socialize more then the resulting network of knowledge and opportunities would generally benefit everybody. I might tend to extremes, here I am working out of my home office for the most part talking about the greatness of a social network.

So far I have found three kinds of formal and informal meetings which different kinds of agendas and structures. One such group that has sort of the same blueprint across the world are the Cocoaheads. I’ve visited several events by the chapter local to Vienna and from this I came to expect certain features that I was disapointed to find lacking in other groups. But don’t get me wrong, certainly there are different way to approach the general idea of getting together like-minded developers. The Cocoaheads approach is to have some topical talk to get started and then transition to something informal from there. This is generally the structure of monthly meetings. A more informal, work-focussed kind of Cocoaheads event is called “coding kitchen”. There you have no structure at all, but instead bring your Mac and something you’re working on and somebody might be present to help you if you got stuck.

The second big group with a global name are the NSCoders aka NSCoderNight. I’ve been to one event of theirs so far and generally it seems to be structured identically to the “coding kitchen” mentioned above. Depending on the weather you might have a couple other developers working on their own apps get together in a small café. What I have been too might not be representative of NSCoders events in general, so take this with a grain of salt.

Generally one problem that all of these groups have in common appears to be some sort of loss of molecular cohesion. You can google all you like, the websites you’ll find in general have not been updated in years. When I asked about this I got two answers, one that groups generally organize via Twitter. The other that groups generally organize via MeetUp, a meeting web site.

Speaking of which, this is how I found one meeting that did not fall under the Cocoheads or NSCoderNight moniker. Via MeetUp I found “The Silicon Valley iOS Developers’ Meetup”. This kind of get-together does not want to belong to an umbrella, but wants to stand on it’s own. There are half a dozen events like this in and around San Francisco, let’s take this one (the biggest) as an example of the third category.

I had an opportunity to sample such an independent meetup at the Skype Headquarters, which was funny in itself, because we had to sign a short NDA with Skype in order to enter their cafeteria where the meeting took place. But hey, anything to be there and check it out. This meeting had by far the largest attendance of all such events that I ever attended. With some positive and many negative side-effects. While it might be interesting for many people to hear about the business pitches of some companies, generally the feeling I get is that our industry is hungry – if not desperate – for fresh blood.

It must have been like 5 companies that took the microphone after the main presentations to quickly mention that they are looking for iOS engineers. Makes me wonder: if it’s hard to find hard good people in Silicon Valley, how much harder must it be everywhere else. Companies in general are interviewing dozens of candiates until they find somebody who has the skills and somebody who is “a good fit”. (Whatever THAT means)

Having a hard time hiring good people also means that there is fertile ground for companies that specialize in re-selling iOS developers, i.e. recruiters. The farther the number of able developers is from the number of companies looking for them, the more you will see companies enter the field of vision that are trying to make the connection and earn money through this. Obviously those are the people that interest me the least, there is little that separates them from used-care salesmen.

If I myself were in the position of looking for getting hired by a company to do what I love, then I would probably want to work for one of the well-known names, not some small startup that might shutdown their business if they run out of seed money. But then again, having the luxury of actually getting paid while you learn might be a good reason to start with any company willing to hire you to do iOS. You can still switch to a more interesting company one year later. While working at old-world telecom  companies the average turnover time was more close to 3 years, but I’m told that the churn rate at US companies is way faster.

My heart aches whenever I hear that a young company finds it hard to staff their iOS team. I would want to help all of them, but I simply can’t. Until human cloning becomes possible I will forever be damned to only be working within my own human limits. This is one of the driving reasons behind me writing this blog. Even if I cannot clone myself, maybe I can clone bits and pieces of my body of knowledge. It is my hope that these bit-sized pieces, when properly digested, can teach some nifty tricks to most developers.

One piece of advice that I myself got a couple of years ago is that you don’t owe the company you work for anything. You work and at the end of the month you get paid restoring equilibrium. If anther company is able to pay better and interest you more, then why shouldn’t you change? This is also proven by the fact that as Apple matures as a company you see more and more Apple-alumni “doing their own thing”. People may find it odd that anybody might ever want to leave the mothership, but it turns out that there is a plethora of reasons why people actually do leave Apple. Or any other big established company for that matter.

But nobody is worthless, he might still have some “social redeeming value”. Another term I recently learned. I think the same is true for any situation where more than 2 developers meet. So if you ware willing to patiently endure the boring parts you are almost guaranteed to make contact with truly interesting people or interesting insights. For example we met an industry veteran who basically invented a method for LEGO to store all building blocks in relational databases. Ok, that has nothing to do with iOS, but still it’s a geeky delight!

I encourage you to take matters into your own hands if you don’t yet have contact with other local iOS developers. I still believe in the idea that it’s more inspiring having a live person in front of you to share experiences with, bounce ideas off each other or simply ask technical questions. Two make a party. Just set a date, decide which of the three mentioned categories you want this to be under and then publish it a sufficiently public fashion as to allow traveling developers to join you. Like me, when I’m the next time in the neck of your woods.

Publishing Powerhouse Pearson is establishing the Voices that Matter iPhone Developers Conferences as an additional “place to be” for us developers.

Last year I had the opportunity (thanks to three sponsors) to attend the issue in Seattle and I loved the casual intermingling with peers, mixed with great networking and – of course – good talks. Being in Seattle is also a great opportunity to visit the Boing plant and see big airplanes being made as an spare time diversion.

From what I’ve seen there the core audience for the VTM events are beginning programmers who are not totally new to the Apple frameworks, but who need a bit of a kick to advance to the next level. VTM returns to Seattle this spring, April 9-10.

Somebody seems to think that my voice matters so they again invited me to come to the conference as an attendee but this year I have set my sights on attending my first WWDC and you know that this is orders of magnitude more expensive to do. So it will require the sum total of all my resources to be able to do that.

But that does not mean YOU shouldn’t go if you are in the area or already on the right continent, that is North America. Seattle was chosen as the ideal place for US west coast and Canadians.

I’ve got this promo code for your that affords you $100 off the ticket price: SEABLOG. If somebody asks: tell them you came from Cocoanetics. Additionally if you buy your ticket no later than February 25th you get a special early admission rate.

On their website you can see that they lined up a great deal of wonderful speakers. Seeing TUAW’s Erica Sadun live (she chairs the conference) alone is worth the cost. Then there’s Aaron Hillegass (Big Nerd Ranch) and many other’s who have written books for Pearson. That’s probably the reason why I will not be invited as a speaker there any time soon, the largest piece I’m able to write is an educational blog post or lengthy apps. But these guys know their stuff.

Leave a comment below if you’ll attend the VTM, it never hurts to network a bit and become friendly with other iOS developing peers.

I was interested to see what goes on in the minds of my peers when it comes to 2011. When you try to emulate the success of other developers it is not just about what they do but you also want to know what goals and wishes their mind revolves around.

I’d like to especially highlight Cory Wiles whose response was the most extensive.

1. Spend more time on my own projects
2. Be invited to give more talks about iOS
3. Finish my password management framework and submit for patent
4. Become much more proficient with CoreGraphics
5. Complete and submit at least two of my own projects to app store
(contract work takes up large part of my time)
6. Go to at least one other conference besides the WWDC

From motivational literature we know that your live moves towards what you predominately think about most of the time. Most of these thoughts would probably not be conscious but my theory is that a “shoot from the hip” response to my question on Twitter should yield a bit of insight.

I’ve categorized the responses into broad areas so that we can see the patterns emerge. Also this is a great opportunity to show off the cool CSS for blockquotes. Add your own resolutions and wishes in the comments.

Dear Apple, …

Apple is the company that provides our livelyhood. If it weren’t for their continued efforts to improve our favorite platform, then we all would not be able to base our business on it. Still there are a couple of things that are left to be wishing for.

Michael Kaye, UK:

I wish apple would rid store of spam/crap apps. Or I will have to drop principles & start writing similar. I need to eat after all.

Steve Streza, USA:

Installing apps without having to go through the iOS App Store.

Pasqualabs, Italy:

Xcode 4 to officially ship!

Stuart Carnie, Australia:

Generic access to bluetooth stack

Dave Stevenson, USA:

I wish Apple would provide analytics into app pages for devs. 2nd, ping for app purchases

Jedrzej Jakubowski, Poland:

Resolution: get Quote Portal v2 featured by Apple in the US. Wish: App Store analytics

Minjie Xu, USA:

My wish is to make my iOS app into top 25 in finance category

Andy Warwick, UK:

Wish: ability to hook up iPhone/iPad to projector for demonstration purposes. Or at least release App that Steve uses.

Obviously there is only one method to tell Apple what we want them to do: file a bug report or feature request. Generally Apple has been known to listen to requests if enough people request them.

Getting featured is a different story. The local iTunes teams are always on the lookout for apps that show excellence and are unique in their features and design. Also during the year they frequently put together lists of apps that match a certain theme. By producing something that is unique, well designed and matches such a theme you greatly increase your changes of getting featured.

Making and Shipping Apps

The second major area in people’s responses revolved around their own apps. Apps that produce a steady monthly income are what keeps our cashflow pumping and bread on the table. So you can see that somebody is a hard core iOS developer and entrepreneur if his first response centers around his products.

Kris Harris, USA:

I’m going to release more than one app in 2011. Hoping to release at least 4.

Layton Duncan of Polar Bear Farm, New Zealand:

Mine is to ship Air Forms!

Dan, Japan:

To finally get my 1984 Apple II game that I’ve been planning to port to iOS for the last 2 years on the App Store.

Augie, USA:

Write and release an app that uses every major iOS framework.

Jason Broyles, USA:

Make a Mac application.

How many apps do you plan to ship? Any new ones? You should also resolve to keep polishing what you already have.

Contract Work

Often the second stream of income for developers is to develop apps under contract. The better you get, the more choice you have in what kinds of clients and projects to accept.

Peter Steinberger, Austria:

To not take shitty projects? [To avoid] toxic clients with meh projects

If you have to do contract work even though you don’t like the nitty and gritty details of dealing with clients than you have two options: either produce more apps of your own and keep building them into a viable business. Or you build a network of local developers who you can share the projects with that you are not personally interested in, for a share in the money.

Skills

Practise makes perfect and so does training. Even seasoned developers recognize the necessity of honing their skills and attending seminars to learn even greater and more elegant solutions to the development problems we keep facing daily.

Sam Jarman, New Zealand:

Develop skills! Produce or work on some great apps

Boris Erceg, Croatia:

One of my new years wishes is attending WWDC11 (same one as last year ),another one is making my own beer for the first time

If you can afford to travel to trade fairs and conferences, then planning to attend at least one such event in 2011 should be on your horizon. Skills you also get from listening to other developers in how they approach certain situations or problems.

Distractions

And in the end we are just geeks who delight in the successes of other developers as we know that we all benefit if the Apple app ecosystem gets stronger. So a wish can also be to poke a fellow developer to finally make use of his skills and build something that you have been lusting for.

Nik Burns, UK:

VLC running on apple tv.

Jonathan Heald, UK:

My wish is myappsales also made for iPad and to include iAds or admob section to see balance, make that come true please

The better connected you are the more of your wishes in this category will be fulfilled.  The feedback we get from app store customers is usually not sufficient to keep your spirits high. But if a pal keeps telling you how great it would be if you finally shipped a certain app or feature then this is the best motivation you can get.

Conclusion

You can see that most of the responses revolved around Apple or apps, the making and selling of products. Which is smart, Apple is our firm foundation and app production is what increases our skills and income. We should do the same: keep Apple on their toes and let them know that we care for them to care. And make some really great apps in 2011 that are worthy of being featured and climb to the Mount Olympus of app store rankings.

As usual, the more brain-power you spend on any topic, the better you get at it. So in any case you would want to have some sort of daily routine that circles around the major topics shown in this article: staying interested in the platform and that Apple makes the improvements that we would like to see. Making apps for yourself and/or contract customers. Look after your skills by following great developers on their twitter and blog and socialize a bit on conferences where you might bump into some of these guys mentioned here.

Finally I encourage you to seek closer contact with your developer peers. If it was only one thing that I learned in 2010, then this: it is orders of magnitude harder to try to be a one-man-shop. Sure, you can do everything yourself. You might also assume that nobody can make the things you have in your head as well as you can. But the kind of motivation you get from a partner is priceless. And better to have an ok app on the app store, than to have a great idea collect dust in your head.

As fate will have it I am sure that we will see quite a few of these goals/resolutions bear rich fruit.

Do you know any facts? Like what you did before getting into iOS development? Or are you possibly looking for facts? Those facts that make blog articles much more interesting?

In this case, let me introduce you to the Cocoapedia. The name should right away invoke two associations: Cocoa, as in Apple’s API we use for developing for Mac and iOS devices. -pedia as in Encyclopedia or Wikipedia. As it should be with any self-respecting Wiki I have written up the history of Cocoapedia on its article on itself.

It’s actually the second time already that we’re launching this, the first time was a complete and utter failure. I had thought that it would smart to make it invitation-only to be able to regulate quality. But this actually prevented any kind of spontaneous growth that makes sites like Wikipedia great. So I’ve abolished these restrictions, everybody can now edit Cocoapedia and they should!

Now, don’t get me wrong, Cocoapedia is not supposed to replace any blog, forum or Q&A site like StackOverflow. Also it should not become a dumb link collection.

Have you ever wondered why some topics are on Wikipedia and why some are not? In May 2008 I wanted to know and added an entry for myself, which promptly got removed again stating that it would not be relevant for addition. From which I learned that relevance is something quite subjective and not even Wikipedia’s set of rules can objectify this dilemma.

We Cocoa developers live in our own universe which has different kinds of rules than mighty Wikipedia. To give a prominent example: Aaron Hillegass is on Wikipedia, while Erica Sadun is not, even though the latter was written dozens of books. Now, unless you are a big fan of Aarons, you probably would agree that this omission is odd. Erica has done much more for us developers but apparently has not hired an experienced Wiki-Writer to add an article for her that would pass under the stern eye of the Wikipedian.

Cocoapedia offers a remedy.

Here the idea is that all facts, events, conferences, apps, components and people connected in the least with Cocoa development have a place to go down in history. Though bear in mind that it is facts that makes a Wiki great. I don’t want to read self-glorfying hymns. I DO want to read a bit of biography and – if any – factual accomplishments, preferably with a footnote that proves them.

Over time Cocoapedia has the chance to grow into a compendium that bloggers would consult to fact-check articles on specific people. There are often disparate bits of “About” spread over developers online sites, blogs, twitter streams and Facebook pages. If you want people to know who YOU are, then you need to provide them with a concise entry.

Making an entry is very easy, I made a tutorial video showing how you can quickly start a new article which you would then fill with some facts about the topic of the article. I randomly chose Gleb Dolgich from my twitter followers who did not mind me creating an entry for him.

Don’t forget that everybody is an editor, so you never truly “own” a page on Cocoapedia. We’ve already had a bit of vandalism, but that’s easy to remove by the undo function. For extreme cases it’s possible to lock pages for a while but experience on Wikipedia has shown that in digital media, where Vandalism can be easily removed, it is generally very short lived. It’s simply less work to revert an article to a good state than it is to vandalize it.

You can look at any page’s source by going to the Edit mode. You most quickly learn Wiki-Editing by copying pieces of such code to your own articles. Consider the article about yourself your first exercise. Then once you have mastered that create references and articles for items related to you. For example if you have a partner for some of your apps, then just enclose his name with double square brackets. This will make it an intra-Wiki link which allows to create a new article if you follow it.

Finally, I request of you that you pass on this information of what need Cocoapedia is trying to fill with the help of an army of contributors. See you inside!

A long time ago, in a galaxy far far away … I think around the beginning of the year actually, Michael Schneider asked me to read this book that he collaborated on with Dave Wooldrige.

At this time and until this date this book remains the biggest and most comprehensive guide on what traps there are in the iPhone app business. It took me some time to read the book from cover to cover and then I also was simply to busy and lazy to do this review. And actually there was another reason, that I din’t want to admit to.

I’m by nature an iPhone app creator, not a business person. I had my first app in the store about 2 months after downloading the SDK back in 2008. Making apps is what I love, but marketing them… yuck! Now if this book really was as good as the table of contents looks then this would mean that I had found – rather by accident on twitter – the ultimate guide to everything that I needed to know about transforming my app workshop into a viable business.

It was long before I read the book that I set out to do iOS development full time. And so I formed my strategy to be running in multiple streams. I did that in part because the income from my apps would only be a fraction of what I needed for living. And here comes the reason: This book is a manifestation of my failure to make apps and market them such that them alone could provide my upkeep.

The reality of the matter is that you don’t just make an app, get it past Apple’s defenses and then the dollars come rolling in. Rather the process begins way before making the app and ends quite a bit after successful submission. These are the chapters in the book, giving you an overview of all the steps that are necessary for success:

1. Seeing the Big Picture in a Crowded App Store Marketplace
2. Doing Your Homework: Analyzing iPhone App Ideas and Performing Competitive Research
3. Protecting Your Intellectual Property
4. Your iPhone App is Your Most Powerful Marketing Tool
5. Money for Nothing: When It Pays To Be Free
6. Exploring New Business Models with In-App Purchase and Affiliate Programs
7. Testing and Usability: Putting Your Best Foot Forward
8. Get the Party Started! Creating a Prerelease Buzz
9. Keys to the Kingdom: The App Store Submission Process
10. Increasing Awareness for Your iPhone App

So you can see that the marketing itself is only a tenth of the whole process from idea to riches. I can safely say that I skipped all but the ninth step. No wonder I’m only making so little money.

The book is not just a good read, it also has an enormous amount of links and places to look at on the Internet. For this feature you would want to also get the eBook version to put on your iBooks. A link in a paper book is hard to be clicked. That’s actually where my first smile came from. There on page 363 in the section on analyzing app store sales statistics, the authors mention My App Sales as “feature packed”.

I think this book is roughly equivalent to making a Bachelor of iPhone App Marketing. The reading itself can be done in maybe two weeks, but there is so much to ponder, so much to actually do, that it will keep you busy for probably a whole semester if not years.

So after having read it through once, you’ll keep it next to your desk for frequent reference. Even though I got my paperback copy for free, I still purchased the eBook version for $10 as reference. To qualify for this 50% off offer you have to state on which page a certain graphic is in the paperback. Much to my unpleasant surprise, APRESS apparently protects eBook PDFs you purchase from them with your e-mail as password! They say that this is their way of dealing with piracy. Oh, well.

Hawk-eyed that I am for “bugs” I immediately found that page 392 of the PDF is corrupt, let’s hope that APRESS fixes that. And I found that you can remove the password by simply re-saving the PDF from Preview, so I CAN put it on my iPad, even if iBooks 1.1 does not open protected PDFs (or does it?).

To give one example of practical stuff in there. For our most recent commercial app WC Betting Pools I used the press release template and instructions to furnish our own professional grade release, the first he had created ever. And I used the list of app review sites provided to get the word out. And I’m happy to say, even though we did not score more than one review, we stirred up sufficient buzz to have our app generate more profit per day than any of our previous apps.

The book makes you a bachelor, to become a master you need to work it for some time. There where a few short sections that I was actually able to skip because I had trained the certificate madness and submission parkour for the past 2 years non stop. But I’d say 90% of the book is was mostly new and inspiring to me as well. And that’s saying something!

What really astounded me was the amount of advice on online-communication that these guys put into their book. It even covers how to communicate best via app website, twitter and facebook. Especially communication I had found to be one of my major problems when getting the word out on apps. Even seasoned app partners I am working with prove daily that they could really use reading this book. Not just will it keep you from making many of the same mistakes I made. It will also enable you to approach iPhone app development as a viable business.

In the least it might show you why you need a partner to take care of the marketing if you want to concentrate on developing yourself. Because if you approach it seriously then you need to invest just as much time before and after the app creation to actually sell it. And if you DO get a partner to do your market communication, then make sure he has read this book before anything else.

Purchase your copy of this book today, APRESS.COM has both versions for sale.

I’ll be OOO during the next two weeks. I’m conducting an iPhone programming course for Vienna based Training company NOW Training.

The first day already occurred last Friday and I so far all participants seem really happy with my style of introducing them into the wild world of OOP with Objective-C.

I’ll be checking my iPhone’s inbox infrequently and in the evenings. But please be patient if I don’t respond right away to emergency code triage requests.

I learned a lesson today regarding happiness and programming. If you are concentrating on a single device and/or a niche of applications then often you feel like you’re the only one you loves the outcome of your never ending pecking at keys. And if you DO get feedback for your apps then often it’s only a rant in the reviews.

I already told you the story how SpeakerClock came to be. I did not write if for the money because frankly I did not think that anybody but myself would be using it. That’s also the reason why I am offering it for FREE initially. I’d rather get a couple of people to use it and send my feedback than have it sit on a virtual shelf collecting dust. Version 1.1 will be the one where I start charging, I decided. Or maybe the basic features now present will stay free, but some upgrades could be a good InAppPurchase.

I’m going to have a look at what we can learn about making great apps from an unexpected reaction I received.

Apple currently has some slides in the iPhone Tech Talk Kickoff presentation of what they think makes a good app. I think I’ll have to make a poster out of this that I can hang on the wall behind my iMac.

• Delightful
• Innovative
• Designed
• Integrated
• Optimized
• Connected
• Localized

Now I’ve heard this several times already, but have I really understood it yet? Well, only partially. One thing that I try to do is have as little distractions as possible. Take SpeakerClock again as an example: through gestures I was able to have all settings be achievable through the main screen. Though I forgot about mentioning that you can start and stop the countdown by simply tapping on it. I’ll have to add this to the already extensive instructions that are on the app’s about page. Another thing that seems to really help users is that they can send me an e-mail with feature requests quite easily.

Starting from the bottom, Localization is something that I saved for future versions due to my self-imposed time constraint of having to finish the app in a single day. Well, for the about part anyway, since the main functionality of the app does not have any text.

I’ve not had any ideas regarding the app being connected. Would you want to auto-twitter where and when you have started your speech? Hm…

Optimization is also only possible for the about table view. I hear that performance on 3G iPhones is not so impressive. I’ve already made some improvements to DTAboutViewController which should pay off in a future update.

Integration with the iPhone’s hardware is currently through the touch interface. There might be more features that could be done using onboard hardware.

Design is something that I care to avoid because I don’t consider myself a good designer. But fortunately for the app there is next to no design necessary. I might increase the size of the traffic light and also the active area of the info button.

I cannot say if you can call SpeakerClock innovative, some happy users seem to think it is. I simply tried to emulate a really existing device, but instead of having buttons and settings to manipulate the time, I opted for touch controls.

But the holy grail of all those items is that your app should be delightful. It should make the user happy to have it and through not getting in the way of his wishes cause feelings of joy. Being the most important of the list it is also the hardest to predict. What do users really want? We can only guess. Possibly to be able to carry out a task in a faster and more intuitive way than they where doing it before having the app on their device.

But after all theory the only way to know if you are on the right track is to engage the user personally and ask for his feedback. I am saying feedback because I mean feedback, NOT reviews. A spontaneous reaction to using your app. What feelings does it produce. Very few people are able to really communicate the level of delight they feel when starting your app. But when forced to think about it they often come up with a list of annoyances that they think you should fix to improve your app. While those are great to continue to improve and polish, they only tell you the facts side of the story. What’s the emotion?

Now we get to what lesson it is that I learned. Yesterday evening I had the spontaneous idea of contacting the TED office and have them try out my app. I had some emotions that would previously have me NOT do that for fear of negative consequences: What if they object to me mentioning the TED clock as inspiration? Am I unknowingly infringing on their copyrights or trademarks? Will they sue me? What if they don’t like it? I would be devastated. I would consider my life a total failure… at least my iPhone programming life …

Or would I?

One thing I learned previously is that at some stage you have to stop with the “what if” questions and just take the leap. A very successful business regimen seems to be: Do first, ask permission later. The worst thing that can happen is that you get a cease and desist letter, like when Ravensburger started to tell developers that they where infringing on Ravensburger’s rights to the trademark “Memory”. Or when Andreas Heck received notice by Winning Moves who told him that he was not legally allowed to use the term “Top Trumps” for his games, so he renamed them. It’s easy to correct if only by removing all instances of a word in your app. Or by reaching a licensing agreement. Any action is better than inaction due to fear of negative consequences. And positive action, that is my lesson, opens the opportunity to result in unforeseeable positive reaction.

Getting back to TED, I did not expect a reaction, or a positive one. But I am not listening to my own teaching at times, I previously DID write about the folly of making predictions. Again, I predicted wrong.

To my own delight I found the following in my inbox not even a day after submitting the TED contact form:

So cool! We’re all playing with your app in the TED office. Here’s
TED’s June Cohen and Chris Anderson.

If you didn’t know, Chris Anderson is the curator of the TED Conference and June Cohen the Executive Producer of TED Media. Having read up on them on Wikipedia makes me smile even broader. These are people that I would love to shake hands and chat with some day to thank them for the great speeches they keep curating and putting on the TED website. Just today they added James Cameron, whom I’ll watch right after publishing this article.

This is the best kind of reaction that one of your apps can elicit in people. “So cool” is code for “Delight”. And “Playing with the app” suggests that the app invites experimentation and exploration with your senses, touch and visual in this case suggesting that if I did not hit the target of Innovative/Optimized, at least I’m in the ballpark. Maybe that’s overanalyzing and reading too much into the TEDsters’ reaction.

In any case their example is a great idea for making a developer happy. Make a photo of yourself using his app and send it to him, be sure to *wink* mention some word that he could infer “Delight” from. You can be certain this e-mail/Photo will end up in his trophy case. Because in all likelihood he will consider his programming a form of art and only secondarily be doing it for the money.

That’s an “idea worth spreading”,  developers have emotions too, you know.

Recently Oliver’s blog post ‘Shuffling an NSArray‘ came across my twitter feed. I’m not sure I followed the link with the intention of being critical, but after reading, I felt the need to make a couple of points. Namely, a fairly staunch opinion that in it’s current form, Oliver’s -(NSArray *)shuffled method is an example of poor naming choice. I realize that the original post was intended to showcase the ability to extend existing classes with categories (a powerful and worthwhile concept to understand). However, take into consideration that many developers new to a language will copy and paste code snippets without fully understanding them, and the importance of using proper convention in code examples becomes very clear.

What’s in a name?

Cocoa is full of naming conventions, a characteristic that has grown to be one of the primary reasons for my love of developing with it. Apple’s own documentation (“Coding Guidelines for Cocoa”) indicates that naming conventions are important for keeping your interfaces consistent and clear. According to Scott Stevenson at CocoaDevCentral, “Naming consistency isn’t extra credit, it’s an essential part of being a great Cocoa programmer”. The ability to develop cocoa applications at an accelerated pace can largely be credited to the fact that understanding method behaviors is almost always completely evident by simply looking at it’s name.

What’s wrong with using “shuffled”, isn’t that what is happening?

My primary complaint about extending NSArray with a method named ‘shuffled’ is that it is quite unclear and somewhat misleading. Without poring over the implementation, it is not immediately obvious what the expected behavior might be, or what objects will be molested and/or returned. Apple indicates that the name of methods representing an action taken by an object should be started with a verb. Shuffled, being a verb, suggest that the receiving object, in this case an NSArray, is going to shuffle. The obvious problem being that, NSArray is immutable – how is it possibly going to be shuffled?

In part two of his article “Cocoa Style for Objective-C” Scott Stevenson touches on naming methods that return objects. As he indicates, there are three basic formats that should be followed .

[object/class thing+condition];
[object/class thing+input:input];
[object/class thing+identifer:input];

or, when wanting to return a variation on a value

[object adjective+thing];
[object adjective+thing+condition];
[object adjective+thing+input:input];

Applying these guidelines, we can see that we are missing one key factor, and that is the THING that we are returning (in this case an NSArray). We should probably be using something closer to -(NSArray *)arrayByShufflingContents or -(NSArray *)shuffledArray. The commonality between the two being that they clearly indicate the thing we will be returning. A very simple change – but one that makes our method much more clear, and lets other developers know we will be returning a new array, not a pointer to the same object we have told to shuffle.

Reviewing the Foundation classes, we can also see that there is an established precedent for naming methods that change the contents of immutable objects.

NSString
stringByAbbreviatingWithTildeInPath
stringByDeletingLastPathComponent:
stringByAppendingString:
stringByTrimmingCharactersInSet:
capitalizedString
 
NSArray
arrayByAddingObject:
arrayByAddingObjectsFromArray:

All of these clearly define the type of object they will return, as well as the condition, input, or adjective describing the variant.

Having read all of that, it might seem like I’m arguing minutia. What difference does adding Array to the end of the method really make? The return type of the method definition is NSArray, and we’re extending NSArray – we can obviously deduce that we’re getting a new object back, right? The major point I’m trying to make is that I should never have to deduce what a method does, and I should rarely have to deduce what a method returns. In the overwhelming majority of cases, it should be almost entirely clear without referencing a minimal amount of documentation.

To continue on the idea of extending NSArray and code cleanliness, I’d like to suggest the form I feel adds the desired functionality, in the clearest possible way. I present, the class method.

+ (NSArray *)arrayByShufflingContentsOfArray:(NSArray *)arrayToShuffle;

I’d venture to guess that every cocoa developer has used class methods, but if you aren’t sure what I’m talking about, this new method would be called similar to the following:

NSArray *originalArray = [NSArray arrayWithObjects: @"item1", @"item2", @"item3", @"item4", nil];
NSArray *shuffledArray = [NSArray arrayByShufflingContentsOfArray:originalArray];

Using this, it is blissfully clear to any developer implementing our category, or reviewing our code, that arrayByShufflingContentsOfArray: is creating a new instance of an NSArray by shuffling the contents of the array that is passed to it.

As a relatively new Cocoa developer myself, I welcome any questions, comments or criticism regarding anything I’ve outlined here – hell, any cocoa related topics for that matter. My cocoa, iphone, and misc ramblings can be heard, 140 characters at a time on twitter. Feel free to get in touch – @jetskier79

Famous Standford University goes the way of the modern educational institution and beginning today makes it’s iPhone Programming Course available in parallel on iTunes U for free while it is being taught live in class by original Apple framework guru Evan Doll. So you don’t get a dusty teacher figure, but the real thing!

I encourage all students of Cocoa Touch to participate in the sessions. Simply subscribe to the video podcast on  iTunes U and watch it comfortably at home or on your iPhone. The course material including downloads and assignments can be found on an accompanying web site. Don’t be fooled by the low price tag: FREE. People usually don’t appreciate what can be had for nothing, but in this case you probably cannot find anything better.

The course starts out with basic syntax and how the frameworks are structured but in the middle of it pupils will even create their very own Twitter Client!

Personally I made myself the promise of spending at least half an hour a day doing something related to Objective-C or Cocoa Touch so that my development muscles continue to develop (pun intendet). Some days you might be too tired to fire up XCode or even to look for easy programming riddles to solve on the iPhone Dev SDK forum. The standford course is the ideal excuse to fill your quota while kicking back a little.

The first one hour lecture is already available and deals with some basic fundamentals. Next week they said that they’ll touch on debugging so I am really looking forward to this.