Long Live the King

Jeff Atwood of Coding Horror has an interesting post today about being a developer for Apple's ecosystem. We'll leave aside for now the fact that Jeff isn't and has never been an Apple developer and is, in fact, a strong proponent of Microsoft's developer stack. Despite that flaw, I usually enjoy reading Coding Horror. I think Jeff's a smart guy with a lot to offer the world in terms of insight about software development.

But…

Jeff's premise today is that third party Apple developers "serve at the pleasure of the king", which is absolutely true. But, he finishes his post by saying he would never develop for Apple's app stores because of the chance of "being thrown under a bus" by Apple. Fair enough, we all have different tolerance levels for things, and his assumption here is essentially correct. Apple developers run a risk of having Apple compete directly with us if our product is successful enough. It happens, perhaps, to .01% of us, but it does happen.

I want to run with Jeff's metaphor a bit, but first, I need to address a couple of points in his article.

The first point I want to talk about is his claim that if Microsoft were to ever do something as audacious as release a product with the same features as one of their third party developers

…developers would be screaming bloody murder and rioting in the, er, blogs and web forums.

Wait… what? Excuse me? What the hell kind of fantasy world does one have to live in to think that Microsoft doesn't, wouldn't, and hasn't competed with their own third-party developers. Microsoft practically made a sport of it in the nineties, and has continued to do it since then, albeit less obnoxiously. I mean, have we forgotten that Microsoft was convicted by both the US and the EU of abusing their monopoly power to compete unfairly. Microsoft used to routinely use their market power to put smaller software companies out of business in order to gain control of a particular niche of the software industry.

And what were the third party Microsoft developers doing back then? Screaming bloody murder?

Nope.

They were defending Microsoft, and understandably so. The hand that feeds and all that. Those developers knew that being assimilated by Microsoft, or being unfairly competed against by Microsoft, were risks of doing business in that particular market and they deemed it worth the risk, much the way that iOS developers do today with Apple.

The second point that I think needs to be made is Atwood's implied assumption that because Marco Arment isn't up in arms over Safari's Reading List feature (which duplicates many of Instapaper's features), and isn't ranting to anybody who will listen, that it means he's "a loyal subject of the king". The implication being that Marco will put up with any treatment that Apple chooses to dish out, no matter how unfair, because he's a good whipping boy.

Which is a completely inaccurate characterization.

I don't know Marco personally, but he's one of the very few people I follow on the Internet who has consistently come across like a grown-up. Marco knew that getting sherlocked was a risk he faced by participating in Apple's ecosystem and decided that it was worth the risk. When that risk turned into reality, he accepted the consequences like a grown up. Anyone who could condemn a man for acting maturely should be called out for it, and that's exactly what Jeff is doing here. Marco's response to the Reading List feature was nothing less than admirable.

Virtual Geography

Now, back to Jeff's original metaphor of App ecosystems as countries. Let's talk a little bit about the Apple Kingdom and also about the neighboring countries where, as a merchant, you might choose to peddle your wares if the King's terms aren't acceptable to you.

The Apple Kingdom

As Atwood noted, the Apple Kingdom is a monarchy, ruled by a King. By Jeff's own admission, this king is a benign king, making decisions that he feels are best for his citizenry (consumers). He's not perfect, but generally his decisions have served the populace well, and they are happy and prosperous. The Apple Kingdom has beautiful paved roads and a great system of railways, and state-run stores within walking distance of every single citizen in the country. The king has invited even the smallest merchants to use this infrastructure to sell goods in exchange for a small percentage of their income and so long as those merchants follow some guidelines that the King has set (and, admittedly, may periodically change) in order to make sure his citizens have a good experience in his stores.

The Apple Kingdom is large, and its citizens are fairly affluent. They regularly shop at the King's stores and enjoy buying things there. Even tiny merchants are finding ways to make a comfortable living by being able to reach all the citizens of the country. Sure, not all merchants are succeeding. Even the best roads and stores aren't going to make a poorly run business profitable or get people to buy spoiled produce, but the opportunity is there for any one who wishes to sell goods to do so with minimal overhead and startup costs.

The King, however, is also something of a merchant himself, and sometimes he will sell at his own stores. He doesn't sell much, but when he does, sometimes he's selling the same types of products as some of the merchants in his kingdom. The King, of course, doesn't have to pay a percentage of his income to use the trains, roads, or stores, though. In even rarer cases, he'll find a product in the stores he likes so much that he wants to provide it to all of his citizens for free, which basically makes it impossible for the original merchant to sell that product any longer.

Now, the Apple Kingdom is not the only country in the world, and the King doesn't prevent anybody from emigrating or, in fact, even from exporting products to other countries. When deciding whether to pack up and go to another country, you need to make sure that your destination is going to be better than where you are now, so let's look at these other countries.

Androidistan

The largest neighboring country is an enormous country called Androidistan. Androidistan doesn't have a king, but instead has dozens of local and municipal governments of varying types and quality. Their national system of government is probably best described as anarchy. Androidistan's infrastructure varies greatly from province to province, with some roads and trains being free for anybody to use, and others requiring payment. Many provinces have their own stores where anybody can sell, but it's hard to find what you want and the quality of the goods is generally kind of poor, though there are exceptional products if you're willing to look for them. Unfortunately, there are also dangerous products sitting on the shelves as well. Poisoned produce and other deadly items disguised as legitimate goods.

Although there's a lot of people in Androidistan, most of them don't really like to buy goods at the government stores. They like to go in and make a meal of the free samples, but most don't really like to actually buy anything and shoplifting is rampant in these stores. In fact, it's often considerably easier to steal a product than to buy it legitimately because many of the stores aren't very well run.

Most merchants have found they can't make enough money selling their goods in Androidistan's markets, so they've tried placing stickers on their goods advertising other products. Some merchants are making a really good living doing this, but many more aren't even covering their costs.

Windowsland

On the other side of the Apple Kingdom is the relatively large country of Windowsland. Windowsland was once prosperous and has a huge amount of industry, but the country has been stagnating somewhat during the recent move toward smaller merchants. The government has recently started updating their infrastructure and building stores modeled after the ones in the Apple Kingdom. Windowsland has started a heavy advertising campaign trying to get merchants to sell their goods there.

Despite a great infrastructure and clean, brightly-lit stores, Windowsland has been having limited success in moving to the modern age of small merchants. Their large industry is still going strong, though, and in the long run, likely their stores will start to do a good business. Someday.

Oh, did we mention that Windowsland is also run by a King? He charges the same percent of income to use his railways, roads, and stores, but has placed fewer restrictions on his merchants in an attempt to lure them to sell in his country. Windowsland is a pleasant enough place, but there's just not all that many people going into their stores yet.

The Democratic Republic of WebOS

This small country had huge potential, but recent mismanagement and ineptitude have basically shut the government down. There are a few citizens roaming the streets still in a bit of a daze, but most have left for better-run countries.

The Blackberry Oligarchy

The Blackberry Oligarchy, which actually has two kings, has gone in one generation from prosperous world power to third world country due to its inability to change its ways. Citizens have been leaving this country at an alarming rate and the remaining citizens have little faith that their pair of kings will be able to fix the problems given the frequent power outages and decaying infrastructure.

There are several other small outlying countries in MobileWorld, but these five pretty much cover the major markets that merchants would want to sell into.

Epilogue

Metaphors are easy to stretch to a point that they become meaningless, and I probably crossed the line a few paragraphs back, but the point is this: all ecosystems have their benefits and their downsides. In the old days of boxed software, instead of a single benign king, you had to deal with a dozen tyrants (software chains) to get your goods on the shelf, and they took more than half the sale price in exchange. If you didn't want to deal with them, you could instead choose to work through a distributor who took another large chunk of your gross income in exchange for dealing with the tyrants on your behalf.

In every market at every time the risk of competition from a bigger, richer competitor has existed.

Part of Atwood's argument is that even good Monarchies can go bad. Sure they can. So can good democracies. Let's take what Apple might be someday off the table. We can't fault people for not staging a revolution before there's an actual reason to revolt.

Whether you do it explicitly or not, going into business means you're accepting certain risks in order to obtain certain rewards. When bad things happen in business — when risks (anticipated or otherwise) turn into actual problems — acting like a twelve year-old and whining to the Internets doesn't make things better. You buck up, find a way to fix it, or move on to something else.

So, yeah. We Apple developers serve at the pleasure of our King, and we know it. In exchange, we get access to millions of citizens who want to buy our products. A tiny percentage of us will end up competing directly with our king at times, but overall, life is pretty good in the Apple Kingdom for us merchants.

And, while we'd be glad to have you among our ranks, Jeff, you're more than welcome to pack up your gear and move to a neighboring country if you think life would be better for you there.

Read more »

Posted in: Other blogs,Rant

Respect & Shame

It's been fascinating seeing how many people have responded to the death of Steve Jobs exactly the way I did. It's truly amazing how many people who never met the man feel not just that the world has lost somebody significant but that they themselves have lost a friend.

Hearing others express exactly what I'm feeling? It helps. And, for the most part, the media has been right there with us, responding to Steve's death by focusing on his impact and the good he has done.

I really hope seeing how many peoples' lives he has touched is helping Steve's family and friends get through this.

But not all of the media has chosen to focus on the good. I won't link to any of the actual articles, but Gawker and the New York Times top a short list of media outlets that have chosen to focus on Steve's flaws and to stand up and shout out to anybody who will listen that Steve was… well… human. Imperfect. Flawed.

There's a custom in modern society that's often called "respect for the dead". It has nothing whatsoever to do with the dead. The dead don't care what you say about them. It's about the living who cared about the dead, and they do. It's because they care that mourning is such a difficult process. Painful. Sad. It's not a time when you want reminders of the flaws of the person whose absence you are trying to come to terms with.

No human with with a shred of empathy or decency chooses to publicly criticize the recently departed, famous or otherwise, regardless of how they felt about them. Doing so is an act of cruelty. It's hurtful. Little. It's kicking people hard when they are already as low as they can be.

For those, like me, who care, but didn't know Steve Jobs personally, people like this are an annoyance. They're just another crass, classless obnoxious Internet loudmouth that we have to make an effort to ignore.

But for Steve's family, friends, and coworkers… the people who really knew him, it's a hell of a lot more than that. It breaks my heart to think that they might read those articles.

Shame on you, New York Times. You're better than that. Shame on you, Gawker. You should be better than that.

Read more »

Posted in: Apple,Rant,Steve Jobs

Sad Mac

I haven't had much time for blogging lately. I have about a half-dozen unfinished blog posts in my queue, but have been too busy to finish any of them.

One of the things keeping me busy right now is work for Apple through MartianCraft. This work, in many ways, is a dream come true for me, as I wanted to work for Apple for years and never managed it.

I started programming on an Apple ][+ in 1980 and Apple has been a part of my life ever since then. I don't need to look much further than the desk I'm sitting at to realize just how much my life has been impacted by this company called Apple started in a garage by two guys named Steve. I make a living using Apple's products and developing for Apple's products, but more importantly, my life is better because of their products.

I took a few hours away from my desk this evening and returned to the news of Steve Jobs' death. I came back to news that quite literally felt like a kick in the stomach. And I mean literally. My stomach hurts.

It seems odd to feel this way about a man I never met. I've only once been closer to Steve Jobs than the front section of Moscone West or North, and that was when I accidentally knocked into him on the show floor at MacWorld one year. But I feel like an old friend has died. I'm fighting back tears, and maybe I should be ashamed of that.

But I'm not.

Steve died far too young. I think a few tears are in order.

Read more »

Posted in: Apple,Rant,Steve Jobs

On Being Excellent to Each Other

Marcus Zarra has a somewhat depressing post today on the excellent Cocoa is My Girlfriend blog. It's about the release of The Daily. Because of all the secrecy around The Daily prior to its official launch, I think not a lot of people knew Marcus was not just involved with it, but was actually leading much of the development effort.

I knew.

I wasn't on the main development team for The Daily, but I did most of implementation work on a single component (the 360° panorama). I wasn't in NYC every day the way Marcus was, but I went down there enough to know the conditions under which the application was written. I saw the endless late nights (actually, it was usually early mornings) and the stress and difficulties under which the app was written.

A personal stake always makes it harder to watch negative publicity. The Daily's launch was especially hard because I was in a position where I couldn't really come to Marcus' team's defense, since my involvement with the project wasn't yet public knowledge. If it had been, I would have been written off as biased.

So, I had to just sit back and watch it the way you'd watch a trainwreck. It was painful watching the snark. It was painful watching Loren Brichter, a well-respected member of our community put together a carousel demo in a complete vacuum and post a video of it as if it proved something about performance in an incredibly large and complex application. It was even more painful seeing John Gruber link to that video, spreading a false impression to a far wider audience.

They both enough about software development that they should have known better. There's almost no part of The Daily that can't be re-implemented in a few hours as a standalone application using static data and with great performance.

Doing the same thing as part of a large development application developed by a large team, working with a larger management team and a huge content and production teams under an unreasonable deadline and constant pressure? That takes more than being a competent developer. A lot more. It takes patience and diplomacy and a very high tolerance for frustration. I don't think I would've survived in Marcus' shoes all those months. I would've walked out or been escorted out long before the launch ever happened. It was honestly that tough.

I'm not sure that our community is getting quite as bad as it appears to Marcus at the moment, but there is no doubt that we are capable of producing our share of snark. And let's be honest… I am capable of producing more than my individual share. I don't think we think about being mean when we fire off a smug comment. I think it's usually just a side effect of expressing a myopic, partially informed opinion. I'm sure Loren honestly believes he could have done better with the carousel had he been working on The Daily. But he's wrong. He just doesn't know enough about the situation to realize it.

But it's not my intention to point fingers here. I'm been just as guilty at times. Last year, during the WWDC keynote, I was extraordinarily snarky about the Farmville demo, completely forgetting that I know people who worked on it. I wasn't intending to shit on their work, but I did, and I'm sincerely sorry about it. There have been other examples. I hope there won't be more in the future, but only time will tell.

I think Marcus' post should be read and taken to heart by all of us. I think it should serve as a reminder that real people — very often our friends and colleagues — are behind the software and hardware that we express opinions on. We should keep in mind that a lot of work went into it. We should also keep in mind that in most cases, we have no idea the circumstances under which the application was written.

Being critical is not only fine, but a necessary part of driving each other to be better developers. But we should try and avoid being a dick about it. It can be done respectfully, and should be.

I promise to try if you will.

Read more »

Posted in: Other blogs,Rant

On WWDC Now Being "Broken"

Over at TUAW, fellow author Erica Sadun opines that WWDC is broken because it sold out fast. And she's right. It's so horribly broken that more people want to attend than they've got room for. Th… wait, what? Where I come from, that's called "success", and it usually indicates that you're doing something right. It's not usually a big red flag that you need to make a complete about face in your approach.

But that's exactly what Erica is suggesting Apple do.

I used to work in the Enterprise software world and know all about these large conferences that Erica is referencing. I was a developer at PeopleSoft (now part of Oracle), and I've been to (and have even spoken at) mega Enterprise conferences like the old PeopleSoft conferences (20k attendees at its peak) and OracleWorld (which is now, I guess, called Oracle OpenWorld because Oracle is so… open).

Making WWDC more like these giant, soulless, "enterprise" conferences is not the answer. Scaling WWDC to 10k, 20k or 40k is fixing the problem by shooting the golden goose. Trying to scale up WWDC like that would utterly destroy everything that is wonderful about it.

WWDC is community. WWDC is actually being able to talk with the engineers who wrote the software you're having problems using. WWDC is a chance to get on a first name basis with people in our community, including (if you're lucky) some of the awesome people who make the APIs we use to make our living. It's a time for learning, absolutely, but it's also for making friendships, making business connections, and looking for future employees/employers/subcontractors. The current size of WWDC is part of what makes it great and is part of why so many people want to attend. In fact, the past few years, it's bordered on being too big, with lab slots becoming harder to get and many sessions having long lines and being standing room only.

What WWDC is, is not what giant corporate conferences like OracleWorld are. If anything, they're the polar opposite. Which is not to knock what those big conferences are - they serve a particular market, and they serve it well, but we are not their market and our needs cannot be met by adopting their model. Conferences like Oracle World are places where groups of people from the same large company or government entity go together, hang out together, and then leave together. They're places that people go because their employer is paying for them to go and has instructed them to go. They're places where people wander through large convention halls picking up swag they don't really want while being sold on the merits of various products their employers don't really need. They're vendor fair as much as a place to learn. In fact, they're usually more like one big fucking advertisement that your company pays for you to attend.

They are not events (by and large) that people save up and do without in order to attend. They're not events that people make sacrifices in order to find a way to go.

But that's exactly what WWDC is. WWDC is a conference that people want to go to even if they have to pay money out of their own pocket. It's something people look forward to attending and talk about having attended for months afterwards. It's a conference where a great many people pay their own way to attend and are thrilled to do so.

Monstrous mega-conferences don't develop community. That's simply not what they're there for. Forty thousand people isn't a community: It's a city. Forty thousand people is so far beyond anybody's monkeysphere as to make the concept of "community" meaningless. Wandering around conferences like OpenWorld no more engenders a sense of community than does walking through Times Square.

I don't want WWDC to become that. You don't want WWDC to become that. I honestly don't even think Erica really wants WWDC to become that. I think what she wants is a perfectly egalitarian world where everybody gets what they want. But that only exists in fiction. In real life, everything involves tradeoffs, and the tradeoffs with her suggested solution would be disastrous for our community.

Scarcity always increases value. Apple could have chosen to jack up the WWDC ticket price until they stopped selling out, but they didn't do that. In fact, the price hasn't increased in years. Yes, they did get rid of the early-bird pricing and group rates, but the base ticket price for WWDC has remained unchanged for quite some time (8 years maybe? Anyone know?). Apple could gouge us and many of us would pay the inflated price happily. But they don't do that. In fact, they charge us less than the early bird prices at big mega-conferences like Oracle OpenWorld, Tech Ed, and PDC, despite the fact that WWDC has no sponsors or advertisers and no vendor floor.

The simple fact of the matter is that any mechanism that Apple might implement to "level the playing field" for tickets would result in somebody feeling like they didn't get a fair chance to purchase. The more complex the scheme and the more advance notice Apple were to give, the more opportunities there would be for people to game the system and create true inequity in the process.

What Apple did do was put WWDC tickets on sale without advance notice and sold them on a first come, first served basis. That's not perfect, but it is about as close to a level playing field as you can get. Yes, some people were on planes, and some people were sleeping (including people in Silicon Valley, it should be noted), and some just weren't paying attention to the Internet when the tickets went on sale. But those tickets were available for over ten hours and everybody should have known they were going to sell out quickly. Yes, people got left out, and it sucks. That's the nature of scarcity.

This is not an artificial scarcity, however. WWDC tickets are like money, you can't just solve the scarcity by printing more tickets. Every additional ticket reduces the value of the conference to the rest of the attendees. Letting everybody have what they want means nobody gets what they really want, or need.

I'll take scarcity and a once-a-year scramble to buy tickets before they sell out over a soulless commodity conference like OpenWorld any day, thank you.

Read more »

Posted in: conferences,Rant,WWDC

The iPad 2 Rant

MartianCraft has a fair amount of Android work right now. Personally, I try to focus on the iOS work whenever possible, but we're a small company, so nobody gets to play the primadonna. As a result, I spend a good chunk of my time on Android projects and have to stay abreast of both the Android and iOS worlds from both a hardware and a software perspective.

Last week, I found myself grudgingly admitting to myself that the Motorola Xoom is not a bad tablet. It feels incomplete in many ways. It has rough edges, some definite hardware and software CBBs¹, and a general dearth of good, native-resolution apps. But, it had potential and I definitely saw how certain demographics might be attracted to it over the iPad. I saw a tablet that normal people could use with some frustration, but not an insurmountable amount… much like Windows, post Windows-95.

The thing that I haven't seen in any of the Android tablets, however, is a compelling reason to buy them instead of the iPad. The only people I know who've bought Android tablets also own iPads. Other than a strong aversion to Apple's products or Apple as a company, what would compel somebody to pay $800 for a Xoom or Tab rather than going out and getting an iPad? Maybe there's a reason, but I can't see it. While both the Xoom and Tab had some specs that were better than the original iPad, neither offered a comparable experience let alone a better one, and neither could do anything that the iPad can't², despite higher price tags.

Then came yesterday.

Two days ago, the Xoom looked like a decent, almost finished and slightly overpriced tablet. Two days ago, it had a couple of quantifiable advantages, including native CDMA support and a better GPU. Two days ago, you could make the Xoom look better than the iPad on paper. Though marketing based on tech specs hasn't proven to be a very effective strategy in mobile computing space, at least they did have that for them. They had grounds for claiming you should buy the Xoom instead of an iPad. The arguments were thin, but two days ago they existed.

Today, simply put: The Xoom is fucked. So, I suspect, is the unreleased Samsung Tab 10.1 and the RIM Playbook. I can only imagine the discussions that are going on inside those companies today.

Only the staunchest Apple haters and self-deluded "openness" ideologues are going to pony up that kind of dough for a tablet that can't offer a comparable experience and doesn't have better tech specs. The Xoom doesn't even have the advantage of working with a carrier that Apple's tablet doesn't. In seven days, there will be both native CDMA and GSM models of the iPad 2.

Think about this: yesterday when I checked, the Android Marketplace had sixteen Honeycomb tablet-resolution apps. Sixteen. And you know what's not included in that sixteen? That space game that they show the guy playing in the Xoom commercials. In other words, they had to put a fake game in the commercial. Would they have done that if they had even one compelling application that could make the Xoom look better than the iPad?

As a tablet platform, Android has two big challenges.

First, it has a chicken-and-egg problem with software. Developers are waiting for people to buy Android tablets in sufficient quantity to support the platform, and many consumers are waiting for good apps to buy Android. In the phone world, Android seems to be past that hump. While the app situation is nowhere near as good as on iOS yet, there are apps — including some good ones — for the platform.

But, even if the Xoom were every bit as amazing of a piece of hardware as the iPad 2, it would still have the problem that it does less cool things. There's nothing comparable to Garage Band or iMovies, or any of the hundreds of jaw-dropping iPad apps that have been created in the last year like Infinity Blade, The Elements, or Alice. There's just no "wow" app you can put on your Xoom and show people that's going to make them want to run out and buy one. There's nothing you can do and confidently say "your iPad can't do that shit right there, bitch".

The second, and much larger problem is simply one of price. I see people constantly comparing the Android/iOS situation to the Windows/Mac situation of the eighties and nineties. I usually see this claim by people laughably arguing that Apple's failure is imminent.

In the nineties, Apple kept insane profit margins on their products while dozens of manufacturers created inexpensive commodity PCs running Windows. There was a margin war on the PC side, and PCs became noticeably cheaper (despite paying hefty licensing fees to Microsoft), and that price difference, combined with Microsoft closing some of the usability gap with the Mac, is what lead to the dominance of Wintel machines. In the nineties, Macs simply cost more. You could argue that Macs were cheaper based on TOC or employee efficiency, but in the quantifiable terms that bean counters understand, the Mac was a lot more expensive and didn't do noticeably more, especially once Adobe jumped ship and become cross-platform.

That's not where things are now, however. For typical consumers - people who don't have a dog in the technology race, so to speak, are going to buy based largely on price, Apple's mobile "post-PC devices" aren't just better than their competitors, they're cheaper than comparable competitors.

We don't have a situation where commodity resellers can easily assemble components into a working, desirable mobile device. Mobile devices are all about form factor, design, and ease of use. They don't sit on a desk, they go where you go. They need to be well engineered, light, get good battery life, and be easy to use. They can't require IT support staff, an instruction manual, or training. A large beige box on a desk is one thing, but in your pocket it's another thing altogether.

Why is this the case, though? Why can't these companies compete with Apple on price in the tablet space?

The prices Apple can offer is a result of two things. First, is plain and simple buying power. Apple sells a lot of devices, so they buy a lot of screens, flash memory, etc. As a result, they can get quantity discounts. Apple got to the 10 inch form factor first and cornered the market, driving up the price for 10" screen components for any competitors coming after them.

The second, however, is that they have gobs of cash on hand. A lot of market watchers say Apple is foolhardy to keep so much cash on hand. On the contrary! Apple understands psychology, and not just consumer psychology. When they go to a vendor or hardware partner and ask for exclusive arrangements, priority fulfillment, or better prices, do you know what bargaining chip they have that few other companies have?

The corporate equivalent of a suitcase full of cash.

When a vendor needs to retool for a new manufacturing process Apple has developed or needs to increase their output capacity, Apple shows up with a wad of cash in hand. They don't have to liquidate any assets or get a loan or seek permission of shareholders. They just play Daddy Warbucks and pull out a wad of million dollar bills. Apple's partners, in addition to getting large-volume contracts, can get working capital as part of their arrangment with Apple without taking out loans. A definite part of the reason you were able to buy an iPad for only $499 is because Apple didn't follow conventional wisdom about cash on hand.

Arguing that Apple would be doing better by doing what everybody else is doing isn't usually very convincing to me.

Motorola and Samsung… they're both large companies with a lot of buying power and strong brand recognition. The problem is, they don't understand the game that Apple's playing in the mobile space, so they're playing it wrong. They're so caught up in catching up that they're not even trying to innovate in this space. Maybe HP or Rim will figure it out, but I'm not going to hold my breath.

Which is unfortunate. If Apple's doing this kind of amazing stuff without any viable competition, can you imagine what they'd be doing with strong, viable competitors nipping at their heels?

---

1 "Could Be Betters"
2 From a consumer perspective, not from the perspective of a geek who likes to take things apart and put them back together. The Xoom, with its more powerful processor and GPU had the potential to do things the original iPad couldn't, but didn't ship with any application that proved it. Consumers believe what they see, not what the tech specs say.

Read more »

Posted in: iOS,iPad,Rant

On Seven Inches

Tim Bray has a year-end blog post up that's worth a read. In case you don't know, Tim Bray is Google's Android Evangelist. As you might expect from someone who would take that job, he's as enthusiastic about the Android platform as I am about iOS. Although his perspective colors his view (as does mine), his analysis is usually pretty good.

He's got one assertion in this most recent post, however, that doesn't seem to ring true to my ear.

Apple will totally do a 7" device. Anyone who’s spent quality time reading books or playing games on the Galaxy Tab knows; there’s a great big hole in the ecosystem that needs something bigger than a handset but that still fits in one hand and you can use for four hours in a row sitting up. This argument is over.

John Gruber seems similarly skeptical, opining yesterday that:

The problem is that it’s nice, for certain tasks, to be able to hold a tablet in one hand, but you can’t do that with the current iPad. I think Bray’s mistake is assuming that using a 7-inch display is the only way to solve that problem.

The argument is far from over, and it's silly to even make the assertion. I have, within arm's reach, the very 7" tablet Tim refers to - a Samsung Galaxy Tab. I have spent quality time with the Tab, and think I definitely count as part of the set known as "anyone", yet I don't see this glaring hole that Tim thinks is so obvious. Personally, I found the Tab awkward for text reading, though part of that is due to Android's abysmal text rendering engine. The only way the Tab is better than the iPad for reading is that it's lighter and more portable. As for games, I'll admit that the Tab's form factor is pretty much ideal for driving games. All other types of games I've tried, it's either no better or worse than the iPad and, of course, there's no comparison in the selection of available games yet.

The Tab is a 16:9 tablet running Android 2.2. For watching 16:9 video content like movies and HD television shows, the end result is that you get roughly the same size image video as you do on the iPad in a package that's lighter and easier to hold, which sounds like a winner, right? There are downsides, however. The smaller form factor means less room for batteries and thus shorter battery life. The energy requirements for a 7" tablet are not considerably less than those of a 10" device, but there's a lot less room for batteries. As a result, while battery life is almost never an issue on my iPad, it's often one on the Tab. If you've seen the inside of an iPad, you know that most of the heft of the iPad comes from batteries. Apple made the design decision that they'd rather have a slightly heavier device that could run all day long on a single charge with normal usage. Based on sales and reviews, I think it's safe to say that was a good decision.

Batteries are getting more efficient every year, as are processors, so at some point, a 7" device with iPad-like battery life is completely feasible, however when that happens, a 10" device will have even better battery life. But battery life is far from the only downside to this form factor.

With the exception of video, some types of games (e.g. car driving games), and likely a handful of other tasks, the smaller form factor is simply not as good as the iPad for most things you'd want to do. It sits in an uncomfortable middle ground between phone-size devices and 10" tablets like the iPad and the… well, like the iPad. The Tab does nothing considerably better than either an iPhone or an iPad. It's "as good" at a handful of tasks.

What it boils down to is that the main advantage of the 7" form factor is that it's easier to carry around with you and is lighter to hold. I'm just unconvinced that's enough of a reason to make a 7" iPad inevitable.

Personally, If I were going to buy something to fit between my iPhone 4 and my iPad, I'd buy a Kindle, and recent sales numbers seem to indicate that many people are making that choice. The Kindle does less than the Tab, but it's even lighter and it does do something better than the iPad, iPhone, and Tab: it's a better ebook reader. It gets great battery life, it's easy on your eyes, has nice text, it's easy to carry, can be held comfortably in one hand, and it's much, much cheaper.

When Apple introduced the iPad, it looked like it was going to compete, and probably kill, the burgeoning ebook reader market. Instead, it pushed those special-purpose devices into a lower price bracket where they no longer compete directly with the iPad. Looking at how the sales numbers have jumped recently, the iPad may just be the best thing that ever happened to the Kindle. The Kindle and Nook are almost down into the "impulse buy" category, and as a result, they're selling like hotcakes, often to people who already own iPads.

But where does a seven inch tablet fit into the market? What would compel someone who owns an iPad to buy one, or would compel someone to buy one instead of an iPad? There isn't really a huge unmet demand for this product to fill. There's no pressing, burning need that would cause people to buy yet another device. A seven inch tablet has to compete with products that are already on the market and that are well-established. It can't compete with the Kindle on price, size, weight, or as an ebook reader. It's not noticeably cheaper than the iPad, yet has shorter batter life. It doesn't do anything that the iPad or iPhone can't. It's only compelling advantages are that it's lighter and smaller. Well, for a small segment of the market, it has another advantage: it's not from Apple.

The Galaxy Tab has been selling pretty well, but it's got novelty working for it, and it's really the only viable non-Apple tablet on the market right now. That will not be the case for long, however. The way the iPad has sold, you can expect every computer hardware manufacturer to try to claim a piece of the tablet market. Microsoft has already announced that, for them, CES would be about "slates" yet again this year (oh, boy!).

For seven inch tablets to gain traction in the long run, they will have to provide a compelling advantage over the iPad, the iPhone, and the Kindle. If they're not going to compete on price, maybe there's some feature or ability where seven inch tablets can distinguish themselves and establish a long-term foothold, but I haven't thought of it yet, and apparently neither have the current tablet manufacturers like Samsung.

The only way Apple will release a 7" tablet is if they think of some compelling reason for such a product to exist. It's possible that the reason would be price - making a more affordable and smaller iPad available to people who can't afford a $500+ device but want something bigger than an iPod touch. That's not impossible given Apple's drive for competitive pricing in their consumer products the last few years, but it's far from a foregone conclusion.

Read more »

Posted in: Android,Apple,Rant

Non-Deterministic Problems aka Finding Talent

As programmers, we usually deal with deterministic systems. To state it simplistically, deterministic systems are systems where the same inputs always results in the same output. Unless we intentionally introduce randomness¹ or have a relatively rare kind of bug in our code, the same inputs to our programs will always yield the same output. It could very well be the wrong result if our algorithm is bad, but it should be the same wrong result every time, which is a trait we rely on heavily.

In the real world, most things we encounter are non-deterministic. There are always factors we can't control or measure, and most systems have a human element. We are at the mercy of whim and emotion, and that's hard for a lot of programmers to deal with. Our fellow humans's decisions are decidedly non-deterministic and hard to predict, as are ours (though we usually don't notice this trait quite as much in ourselves).

You may have noticed that I haven't had much time to write lately. I've been exceedingly busy of late, even by my own standards. Although a lot of my time is being spent writing and debugging software, I've also been involved with some very non-deterministic problems as a result of my involvement with some large, complex development projects.

Probably the biggest non-programming problem that I've had to deal with lately, which most of my industry peers and nearly all of our clients are dealing with also, is finding good, experienced, reliable developers to staff projects. In short, there aren't enough experienced mobile software developers to go around. There simply aren't as many developers with multiple successful projects under their belt as there are companies who need the services of such people. I know of one large company that currently has ten open requisitions for mobile developers - five iOS and five Android - and no viable prospects at the moment. I helped one client recently bring aboard a good iOS developer, which took several months, and then I very quickly regretted it, because MartianCraft could really use that developer's services now.

Yet, on the other hand, whenever I blog about just how much work there is right now, I inevitably get several e-mails or comments from developers wanting to know how to find all this work. I make it sound like it's raining work, and they're not getting wet.

Given that, I thought it worth a few minutes to write about both sides of the equation: how to find developers, and how to find work as a developer. This isn't an exhaustive treatment, just a summary of recent observations.

For Developers: Finding Work

Unfortunately, I've got no silver bullet for aspiring developers. Overnight success is often indistinguishable from years of hard work. There are countless issues around getting that are not mobile development-specific that I'm not going to touch, such as a willingness to relocate ("go where the work is").

As with any industry, a large part of finding work is establishing a reputation and getting to know as many people in the industry as you can. Though it's expensive, you really need to go to WWDC, and probably a couple other conferences as well. About half, maybe even more, of MartianCraft work has come directly or indirectly as a result of one of us attending a conference. Conferences are where we meet our peers and where we develop and maintain our relationships with them. You should also attend CocoaHeads and/or NSCoder Night if you have one near you. This is where you can meet and get to know local iOS and Mac developers. On the Android side, there are similar meet-ups that you can attend.

When going to hire or subcontract a developer, most people I know will automatically prefer someone they've met, talked with, and maybe shared a drink with over a stranger, no matter how good the stranger's resume looks. Confidence in someone's ability to get a job done comes more rapidly from personal interaction. Resumes are sterile, but sitting down and working through a tough bug with somebody gives you a real feel for the other person's character and technical chops in a way you can never get from a resume.

At conferences, don't worry about going to every session. Everybody tries to at their first DubDub, but don't. Really. Pace yourself so you can socialize in the evenings. That may sound like bad, or even frivolous advice - as if I'm telling you to play hooky, but the information in the sessions can be found again. Most conferences videotape their sessions, and usually some of the attendees do joint note-taking using SubEthaEdit and make those notes available. But socializing with industry peers is vital if you want to do this full time, especially as an Indie. These are the people who can give you work (and accept work when you're too busy to take on new work yourself), and they are the people who can help you when you're stuck on a gnarly technical problem. These are the people who can give you a different perspective on something you've been staring at for far too long and are the people who can help you become a smarter, better developer.

Though not perfect, the iOS and Mac developer community is incredibly giving and helpful. It's not uncommon for direct competitors to help each other out and consider each other friends. Most of us realize that it's not a zero-sum game, and helping out others in our community usually comes back with interest. Scratch that. Not usually. Always.

Getting ongoing work requires more than being liked by other developers, however. You have to give people a reason to have confidence in your abilities. Creating or contributing to open source projects can show huge (if not immediate) returns. In the early days of iOS, before Core Data was available, my SQLitePersistentObjects project brought me nearly as much recognition as having my name on the cover of iPhone programming books.

Regular blogging is also a huge opportunity. Not only does it give people an idea of the depth of your knowledge, it gives you a chance to learn and improve. I don't think I've posted more than a couple technical blog posts where there wasn't either a correction or improvement sent to me by a reader, and often there were many. Just remember not to get defensive or depressed when it happens. You don't stop making mistakes until you stop living, but if you keep learning, you can avoid making the same mistake too many times. Readers who care enough to point out your mistakes are valuable beyond belief. Tame your ego and cherish them. Nobody's going to think less of you as a developer for occasional mistakes or less-than-perfect code.

But, no matter how much of the above you do, there is one absolute prerequisite to getting work on an ongoing basis: you have to have the technical chops. This is probably the hardest thing to figure out. I've met many great developers who lacked confidence in their abilities and I've met some who've had far too much confidence in them. It's really hard to gauge your own ability and it's almost always sobering to revisit older code you've written. No matter how good you get, there's always room to get better and if you're doing it right, you will. As developers, we're paid as much for our ability to quickly assimilate new knowledge as we are for the things we already know.

Don't worry too much about your whether you have a specific degree, or a college degree at all. You don't have to have a computer science or computer engineering degree to be a good programmer. There are many, many great programmers (including inside Apple) without those degrees and, in fact, without degrees at all. College is one way to get the information and some of the experience you need to be a good programmer, but it's not the only way, and it's possible (though probably not common) to get through school with a CS or CE degree and completely suck. Some of the worst iOS programmers I've encountered have both degrees and programming experience. Objective-C is a bit of a weird beast, and overconfidence is a big problem for experienced developers coming from C++, Java, and C# background. They look at Objective-C, see familiar aspects, and think they know what they're doing, sometimes completely oblivious to the differences between a static, strongly-typed language and a dynamic, weakly-typed one or the differences between a garbage-collected language and a reference-counted one.

In a perfect world, nobody would ever be able to offer their services as an iOS developer without perfectly understanding the rules around memory management. I'm not suggesting you should, but everything else, you could learn on the job, but you have to really grok the way retain counting and memory management work to be a professional iOS developer. You can really fuck up a code base trying to fix EXC_BAD_ACCESS bugs if you don't know what you're doing and can create an awful lot of work for somebody else in the process. You can also get away with an awful lot of leaks if you're developing on the simulator that will cause significant problems later. The stakes get much higher when you're working on the same code at the same time other developers are.

One thing to seriously consider, even if you have a few apps under your belt, is to take a class or workshop. There are some excellent ones out there, including (but certainly not limited to) the Big Nerd Ranch and the Pragmatic Studio. A few thousand dollars may seem like a lot of money, but it's a hell of an investment given the work opportunities available right now. A good workshop will beat into your head the important stuff. They'll strap a firehose of information onto your face and open the spout. They will make your brain hurt, but you will come out knowing memory management and the fundamentals, and that will put you in the running.

Another key skill is debugging. Being able to fix your bugs and those you find in other people's code is vital. Plus, the more bugs you encounter, the more things you know not to do in the future. Want to test yourself? Try downloading this. It's an Xcode project — a modified version of one of the Beginning iPhone 3 Development projects — that has a number of common bugs introduced into it. You should be able to get this to compile clean (no errors or warnings), then be able to navigate into every view in the application without it crashing and with something being displayed on every view. Once you've done that, you should then be able to fix any leaks in the app using Instruments. How long it takes is going to depend on a lot of factors, but I'd say that a typical, experienced, professional iOS developer should be able to fix this in between a half hour and an hour and a half. Regardless of how long it takes, if you can fix them all without help, you've gone a long way down the path to becoming a great developer.

Don't worry if you can't find them all that quickly. The first time you encounter a particular class of bug, it takes more time. Persistence is as important as speed, and debugging this project is a good exercise. Once you see a type of bug once, it's much easier to find and fix it when you encounter it again.

If I find time over the holiday, I might do a screencast showing how to find and fix all the bugs in the project. I can't promise I'll find the time to do that given my current workload, but if I can, I will.

Lastly, if you're looking for full-time iOS or Android employment, or for contract development work, send me your resume. MartianCraft isn't hiring full-time employees at the moment, but we do often need subs, and I know of many, many open requisitions for full-time jobs and I'm always happy to pass resumes along to hiring managers.

For Companies: Finding Mobile Developers

The other side of the equation is, how do you staff a mobile development project right now? Many experienced mobile developers were attracted to the space because it offered them the ability to make a living creating what they want to create. Mobile, and especially iOS development offer opportunities for small teams without a lot of funding to make a decent living. Many of those indie developers are doing exactly what they want to be doing and it's going to be hard, if not impossible, to attract them away from that life, if they're good at what they do.

Hell, many contract developers have app ideas they'd love to be working on themselves. A friend of mine who owns a development shop stated the problem fairly succinctly recently by saying: "We've got several app ideas we'd like to build, but clients keep throwing money at us."

I don't know exactly how many contract iOS developers there are with Objective-C experience that pre-dates the release of the iPhone SDK and/or who have several successful projects under their belt, but it's less than are needed. Big businesses are finally catching on to the importance of mobile and that's making a shallow talent pool even shallower. The situation for Android is similar. Though there are more people who already know the underlying language (Java), the platform has only relatively recently hit critical mass, so there aren't a lot of people who have been involved with successful Android software projects yet compared to the work available, and even less who have successfully shipped multiple Android projects.

In all reality, you're either going to need to offer crazy rates to lure the cream of the crop to your project (and that is no guarantee you're going to get the cream) or you're going to need to invest time and money into developing internal talent. I would advise at least having one really good, experienced tech lead on any decent size project, though. As many App Store success stories can attest, it is absolutely possible to ship good software using only inexperienced developers. But, doing so increases your risk substantially. Having at least one mentor who can guide and help and solve the really icky problems is gold.

In most places, you can train developers more cheaply and more quickly than you can find existing ones, at least if you're looking for full-time employees. It's not a perfect plan - your newly trained people will be learning on the job and making mistakes and may, at times, hit problems that are beyond their ken. But, with the proper training and support, they can handle the bulk of the work, and over time, will gain the experience to handle anything. Of course, you'll have to take steps to keep them from leaving. Arming an employee with a highly marketable skill always incurs a risk of losing that employee.

You can deal with that using contract terms requiring payback of training expenses or other similar ideas, but it's far more effective (albeit harder) to create an environment where people want to work. Job satisfaction is a bigger motivator for many developers than the size of their paycheck, assuming they're making enough to be comfortable and to feel valued. We're one of the few growth industries in this economy, and there's always another paycheck somewhere if you have these skills, so if you're create a hostile environment, no amount of money is going to keep the good people around long term.

There's another option you might be considering: offshoring. Go ahead. I mean, anything I say against the practice is going to seem biased given what I do for a living, and it's true that you can get considerably lower rates by doing it. I've seen shops in other countries offering iOS development services for about what you can make working at Burger King here in the states. And there are actually success stories from offshoring to cheap development body shops. Unfortunately, there are even more horror stories. In the few cases where I've been brought in to fix² projects of this nature, it's always been a waste of time and we ended up just throwing out the old code and starting over. Let me tell you, "start over" is a suggestion that strikes fear into the hearts of project managers.

To put it as fairly as possible: Offshoring increases risk. If you're comfortable with more risk, then it might be a good choice for you. There's a chance you'll come in way under budget and be a hero. Just recognize that there's a larger chance you'll end up six months down the line starting over completely. Any way you cut it, you're likely to have language barriers, cultural differences, and a hard time enforcing accountability. The simple fact of the matter is, even in countries with considerably lower cost of living, opportunities for good mobile developers are legion, so the only way those shops can maintain those excessively low rates is with a constant stream of new, inexperienced bodies. Call me crazy, but it seems to me, that if you're going to have inexperienced bodies working on your project, you'd be better off with ones closer to home that you can train and guide and have some idea of what they're doing.

I'll be blunt. If you're looking to build a team of iOS or Android developers in-house, you've got a tough road ahead of you at the moment. At some point, we'll hit equilibrium and it will get easier, but right now, it's hard. Just as I suggested to aspiring developers, I'd encourage you to get involved with the community. Send somebody, preferably somebody with some authority to hire developers and whose day-to-day job is working with the technology, to conferences, CocoaHeads meetings, and NSCoder Nights, or the Android equivalents (Meetup.com is a good place to find both iOS and Android groups in your area).

I'm always happy to hear from companies that need iOS or Android development resources. I'm thrilled to refer potential employees your way if you're looking for in-house talent, and MartianCraft is always open to talking with with you about your development needs, whether it's for a little strategic consulting and guidance, or to fully staff a development project. And if MartianCraft isn't a good fit for your situation or doesn't have the resources available to do a great job, there's a pretty good chance we know somebody who is and does. If we do, we'll connect you with them.

---

1 Technically speaking, without external input of some sort, computers are not capable of true randomness, and using a pseudorandom function doesn't make a computer non-deterministic. Pseudorandomness does make the computer pretend to be non-deterministic, though, and you will appear to get different output from the same input on successive runs of the program.
2 The term that we professionals in the industry use to refer to this process is "unfucking". Surprisingly, most dictionaries have not picked up this term yet.

Read more »

Posted in: Contracting,Developers,Rant

Lifting the Skirt

MartianCraft has received a surge of requests for quotes and proposals in the several weeks. A disturbing trend that I've been noticing in some of these proposals is that more and more of the people who contact us are wanting us to sign NDAs before they'll lift their skirts even a little. Often, we can't get the most basic information about a project, not even things like ballpark budget, timeline, or type of application until we've signed an NDA, often a pro-forma NDA that was downloaded from the web.

The last thing any reputable iOS dev shop is interested in doing is stealing your idea. First of all, it would destroy our business if we did that. NDA or not, it would be unethical. This is what we do for a living. If we were to steal an idea and publish it as our own, word would get out and people wouldn't trust us. Our business would die even without ever being sued.

More than that, though: Ideas, with only rare exceptions, have little value without the ability to execute on the idea and execute on it well. I guarantee you that no matter how great you think your idea is, we have several of our own that we'd rather be spending our time on. But we don't even have time to work on our own cool side projects right now, never mind steal yours.

It's absolutely understandable, of course, to reserve certain strategically important details until after a contract is signed, but you have to give us enough information for us to decide whether we're a good fit for your project.

Every NDA or contract we sign costs us money, and not an inconsiderable amount of money. Every single one goes to our lawyer before we'll sign it, and most of them have to be modified and negotiated. It's a costly process. Even the simplest NDAs cost MartianCraft hundreds of dollars by the time we've signed it. We're not going to spend that if we don't have some notion that it's a good project for us and that we have the resources to do it well. We'd quite honestly go bankrupt if we were to forward every NDA request we got to our attorney.

If we know a little about your timeline and budget and a brief synopsis of the app you want to build, we're far more likely to submit a proposal. If you're not willing to give us even the most basic information, then we're going to politely decline your NDA and pass on the project unless you're a Fortune 500 company… maybe.

Here's the important thing for you to realize if you're looking for any mobile developer, but especially an iOS developer: there are nowhere near enough competent, experienced mobile developers right now to meet the demand. By now, all the large companies have realized that mobile is the strategic battleground for the next several years. As a result, experienced mobile developers rarely have to look for work. MartianCraft has existed for less than a year. In that time, the only advertising we've done is to put a banner ad here on my blog, and yet we already have had to turn down at least as much work as we've accepted. I say that not to brag, but to show what the current state of the market is. It's not unusual for us to receive a half-dozen requests for proposals in a single day when you combine requests to MartianCraft and those that come to us individually. When we don't submit a bid on one of those proposals, it's not out of hubris, but rather out of practical necessity.

We are far from alone in this. All of us have friends in other longer-established mobile dev shops, and it's the same story all around. There's a lot of work — a lot of interesting work — and simply no way to accept every interesting project that comes along.

If you insist on an NDA before you give any information at all, you are potentially limiting your pool to the developers who are desperate for work, and given just how much mobile dev work there is out there right now, I'm really not sure that you want to limit your talent pool to just the ones who are desperate for work.

Read more »

Posted in: Contracting,iOS Development,MartianCraft,Rant

Outlets, Cocoa vs. Cocoa Touch

I almost always follow Apple's lead on Cocoa and Cocoa Touch conventions. I figure that by the time outside developers like me see something for the first time, Apple engineers have been living with that thing for many months, so they've likely got a much better idea than I do about the best way to use that new thing.

But, after spending time with their stuff, sometimes — not often, but sometimes — I disagree with what appears to be Apple's recommended "best practice" for doing something. I think I've come to the decision that the IBOutlet behavior in iOS is one of these areas.

If you look at Apple's documentation snippets and sample code, you find that they almost always retain IBOutlet properties, like:

#import <UIKit/UIKit.h>


@interface FooView : UIView 
{

}
@synthesize (nonatomic, retain) IBOutlet UIButton button;
@synthesize (nonatomic, retain) IBOutlet UITextField textField;
@synthesize (nonatomic, retain) IBOutlet UIImageView imageView;
@end

There's a good reason for this. In iOS, the documentation explicitly states that you need to retain all outlets because the bundle loader for iOS autoreleases all objects created as a result of loading a nib.

Objects in the nib file are created with a retain count of 1 and then autoreleased. As it rebuilds the object hierarchy, however, UIKit reestablishes connections between the objects using the setValue:forKey: method, which uses the available setter method or retains the object by default if no setter method is available. If you define outlets for nib-file objects, you should always define a setter method (or declared property) for accessing that outlet. Setter methods for outlets should retain their values, and setter methods for outlets containing top-level objects must retain their values to prevent them from being deallocated. If you do not store the top-level objects in outlets, you must retain either the array returned by the loadNibNamed:owner:options: method or the objects inside the array to prevent those objects from being released prematurely.

This is different from Cocoa on the Mac, where it wasn't necessary to retain outlets and people rarely did. In fact, we didn't usually bother with accessor or mutator methods for outlets (it was just unnecessary extra typing in most cases), we just put the IBOutlet keyword in front of the instance variable and the nib loader was happy to attach our outlets like that, retaining the objects that needed retaining.

The behavior under Cocoa/Mac is not actually to retain everything in the nib, but rather, to retain any object that doesn't have a parent object to retain it. So, in other words, if an object in a nib will be retained by something else, like a superview, the nib loader doesn't bother to retain it again. But, if it doesn't, the bundle loader retains it so that it doesn't get deallocated.

This is a logical approach and, in fact, was necessary back in the pre-Objective-C 2.0 days because outlets back then were just iVars and there was no easy way for the controller class to retain objects that needed to be retained.

I have to wonder why they would change the fundamental behavior of a foundation object like NSBundle between Mac OS and iOS? NSBundle is not part of Cocoa or Cocoa Touch, it's part of Foundation, and the whole point of Foundation is to have common objects between the different operating systems.

I wrote a small project to test if the Bundle Loader really did behave differently, as documented, by using an instance of UIView in the nib with no superview. Sure enough, when I didn't retain the outlet, I either got an EXC_BAD_ACCESS or a different object altogether when I printed the outlet to NSLog(). The difference is real. The bundle loader on the Mac will retain outlets for you if they need to be retained, which allows you to continue using instance variables, or properties with the assign keyword. This means you don't have to release your outlets in dealloc and you don't have to mess around with anything like viewDidUnload on iOS.

The bundle loader on the iOS, on the other hand, does not retain anything for you, so if an object does not have a parent object to retain it, you have to retain it in your controller class or you will end up with an invalid outlet.

I really don't see the value in changing this behavior. I'm guessing the decision was made for the sake of memory efficiency in the early days of the iPhone. The idea being that you might load a nib with object instances that you aren't actually using, and with the old behavior, those would take up memory as long as the nib was loaded. That doesn't necessarily sound like a good idea on an embedded device with no virtual memory and 128 megs of RAM, which is what the original iPhone and iPhone 3G had.

Despite that, I think the cure here is worse than the disease. If you don't remember to release your outlets in viewDidUnload (which, if I remember right, we couldn't even do in the 2.0 version of the SDK), your outlets will continue to use up memory after the nib is unloaded, obviating any advantage of the lazy loading. Essentially, it's more fragile, because it depends on the programmer doing the right thing and there are few if any situations where a programmer would need to not do the right thing.

By virtue of the bundle loader not retaining outlets, it also requires more rote, boilerplate code to be written in every controller class in every iOS application, yet it runs just as much of a risk of unnecessary memory use, arguably a greater risk. In other words, the cure is no better than the disease.

iPhones are getting more robust and less memory constrained with every new device that comes out. I would argue that it's already time (or, at very least, soon will be time), to bring the behavior of the two bundle loaders together. If they are brought together, they should be brought together using the old Cocoa behavior not the new iOS behavior. When you think of the number of people coding for the iOS now, those extra required dealloc and viewDidUnload lines in every single controller class in every single iOS application are really adding up to a lot of engineering hours lost on boilerplate.

A few weeks ago, I started experimenting with using assign instead of retain for IBOutlets except in cases where the outlet's object didn't have a superview or another object retaining it. If an outlet's not a view or control, then I also use retain. In essence, I'm mimicking the old behavior of the nib in designing my controller classes.

This has led to a lot less typing and less code to maintain because 95% or more of the outlets I create are connected to objects retained by their superview during the entire existence of the controller class.

Now, I'm not necessarily saying you should do what I'm doing. It can be tricky, at times, remembering which objects need to be retained and they can be hard to debug if you get it wrong. Apple has made a recommendation with good reason and I don't think you should disregard that recommendation lightly. That being said, if you're comfortable enough with Objective-C memory management and the bundle loader to be able to distinguish when a nib object will be automatically retained by something else, you could save yourself a fair bit of typing over time.

I normally try to embrace changes Apple makes, but in this case, I just can't convince myself that this was a good change. The old nib behavior of retaining only things that need retaining has been in use for over 20 years, dating back to when desktop computers were less powerful than our iPhones are, and there doesn't appear to be any practical advantage to the change. On the other hand, we'd all benefit from going back to the old Mac OS bundle behavior because we'd have less make-work to do when setting up a controller class. There's also little danger in changing this behavior because code that follows Apple's current recommendations would continue to work correctly.

Read more »

Posted in: Cocoa,Cocoa Touch,Objective-C,Rant

Experts == Idiots?

It's sad, really, the state of technology journalism. But you knew that, already. I should know to enough ignore link-baiting crappy journalism, especially those that do little more than republish some company's press release. Most days, I do.

Not today, though.

Computerworld posted an article with this headline today: Devs bet big on Android over Apple's iOS.

Wow, really? That seems surprising. What could possibly justify such a claim? Some proof that developers are leaving iOS in droves? Some new data about the Android Marketplace is actually making decent money for a substantial portion of Android developers? No, though it is encouraging to see that the Marketplace opened up to 13 new countries today. Still another 60 or so to go, but it's a step in the right direction. But that fact's not even mentioned in this article.

So what justifies such a grandiose claim? A survey of Appcelerator Titanium developers commissioned by Appcelerator. Now, if you don't know, Appcelerator Titanium is a cross-platform framework that allows you to develop an app once and generate applications for multiple paltforms: iOS, Android, Linux, Mac OS, and Windows.

Leaving aside my personal opinions about cross-platform tools, the article has already strayed from the headline. Devs? Well, sure, they're devs, but they're not representative of devs in general as the headline would imply. They're developers who have specifically chosen one option, and it's an option that doesn't tie them to a platform at all. We're talking about a group of people that have already shown their willingness to hedge their bets and who aren't about to take the risk of hitching their wagon to a single platform.

It's an inherently skewed sample. If you ran that same survey past 15,000 dedicated iOS developers, or dedicated Android or Blackberry or .Net developers, you'd get drastically different results.

In other words, this survey has no value whatsoever except to Accelerator. To them, it's perhaps useful for helping them decide where to devote their resources in the future to keep their clients happy.

But for the world at large? Worthless.

Oh, and what constitutes "betting big" in the context of the article? Well, it's not actually addressed, but their idea of "betting big" doesn't seem to match mine. There's nothing about investments, or exclusive agreements, or anything else that involves any sort of risk whatsoever. Developers were just asked things like "how interested are you in a platform X". The "betting" didn't involve monetary investments, or time investments. These developers did nothing more than state an opinion. An anonymous opinion. Oh… those crazy rebels.

Well, I'm "betting big" that the author of this post is a hack and his soi-disant "expert" is fucking clueless.

Let's face it, nobody knows for sure where the mobile market is headed, and being a Titanium Dev doesn't make your opinion any more informed or valuable than anyone else's. Personally, I suspect Android will continue to grow in market share unless Windows Phone 7 is better than great or else Microsoft manages to one-up Google's relationship with Verizon. But, any way you cut it, this is not a replay of the PC battles. There are too many companies still in the game and who have the potential to grow market share, profit share, or whatever other metric by which you want to judge.

Despite what you may read, there is no clear market leader. Nokia is still in the lead based on total handsets, Blackberry is still in the lead based on smartphone handsets sold, Apple is kicking ass in the profits department, and Android is doing gangbusters in new sales unit, if you lump all the 100+ models of Android phones together and count free phones as sales. Plus, the market is still growing. Apple, for example, didn't increase their market share at all year over year, but they increased their units sold considerably.

Understandably, many people are counting Microsoft out of the mobile game, but I'm not. Though I'm no fan of their technology stack or their approach to business, I think the sheer size of Microsoft's advertising budget, their Enterprise-savvy sales force, and the enormous pool of existing .Net developer talent they can draw on gives them an opportunity for huge inroads. They may not capitalize on it, but it's certainly there and counting Microsoft out of the wireless market would be as foolish as counting Apple out of the game 12 years ago was. And over at HP, lots of money and time is being invested into the Pre platform, which has not been a huge commercial success, but got pretty good grades with many developers who worked with it.

The game's afoot. It's going to be fun to watch, but if you are truly a betting person, this is what you might call a high-risk scenario.

Read more »

Posted in: Android,iOS,iPHone,mobile,Rant

More on dealloc

I really didn't expect to kick off such a shitstorm yesterday with my dealloc post. A few people accused me of proselytizing the practice of nil'ing ivars, at least for release code. Possibly I did, but my real intention was to share the reasons why you might choose one approach over the other, not to say "you should do it this way." I mostly wrote the blog post to make sure I had my head fully wrapped around the debate because it had come up during the revising of Beginning iPhone Development.

Daniel Jalkut responded with a very lucid write-up that represents one of the common points of view on this matter. That view might best be summed up as "crash, baby, crash". If you want to find bugs, the best thing you can do is crash when they happen, that way you know there's a problem and know to look for it. This is not a new idea. I seem to remember a system extension back in the old Mac System 6 or System 7 days that would actually cause your system to crash if your app did a certain bad thing, even if that bad thing didn't cause any noticeable problems in your app. I don't honestly remember the specifics, but it was something to do with the trapping mechanism, I think (anybody know what I'm talking about??). Of course, Apple didn't ship that extension to non-developers.

What makes this a difficult argument is that Daniel is absolutely right… sometimes. There are scenarios where crashing is much better than, say, data loss or data integrity loss. General rules are always problematic, but though I see his point, I'm sticking with "not crashing on customers" being a good rule generally… except when it's not.

In interest of full disclosure, there's actually a third dealloc pattern, albeit a distant third in popularity, but it has definitely become more popular than when I first head of it. In this approach, you assign your instance variable to a stack local variable, then nil the instance variable before releasing it, like so:

- (void)dealloc
{
    id fooTemp = foo;
    foo = nil;
    [fooTemp release];
}

In the release-then-nil approach, after you release, there's a tiny window between the release and the assignment of nil where, in multithreaded code, the invalid pointer could still be theoretically be used. This approach prevents that problem by nil'ing first. This point of view represents the opposite end of the spectrum from the one Daniel stated. In this approach, your goal is to code defensively and never let your app crash if you can help it, even in development. If you're a cautious programmer and believe in the Tao of Defensive Programming, then there you go - that's your approach to dealloc.

For me, personally (warning - I'm about to state an opinion) I can't justify the extra code and time of the defensive approach. It's preemptive treatment of a problem so rare that it's almost silly that this discussion is even happening. I've been writing Objective-C since 1999 and I've only once seen a scenario where the dealloc approach would've made a difference in the actual behavior of the application, and that was a scenario created for a debugging exercise in a workshop, so we're really splitting hairs here.

So, here's my final word on dealloc:

1. If you already have a strong opinion on which one to use for the type of coding you do, use that one. If not…
2. If you prefer that bugs always crash your app so you know about them, use the traditional release-only approach
3. If you prefer not to crash if you can help it and prefer to find your bugs using other means, use the newer approach
4. If you want your app to crash for you, but not your customers, use the MCRelease() macro or use #if debug pre-processor directives

What's important is that you understand the benefits and problems of the different approaches, not that you use the same one that I do (or Daniel does, or anybody else does).

After all, you're the one who has to live with the consequences of your decision.

Read more »

Posted in: Memory Management,Objective-C,Rant

Complaining About Success

If you want to see how little sympathy you can get from those around you, try complaining about being successful. It just doesn't tend to be a problem over which people shed tears on your behalf. But I'm actually not here to complain. I'm really thrilled that MartianCraft is growing steadily and, more importantly, that we're getting interesting work.

I did think it was worth popping in here to explain my absence of late, however. I've got several partially written posts sitting in MarsEdit, including a couple for my recently-started and just-as-lonely personal blog. But time has become a scarce commodity for me, and will likely remain that way for at least the next month or two, possibly even longer. Even my OpenGL ES book for prags has suffered lately as I've been basically working double-time trying to catch up on my workload. Even the move to Florida is being affected, as we probably won't get our house on the market now until the new year.

The fact that I've been doing so much coding does mean that I've got some great ideas for blog posts, so hopefully once the dust settles, I'll have some goodies for you, but bear with me in the meantime.

Oh, and a somewhat related note. A client of MartianCraft is looking for a really mobile developer to work in New York City. They'll be happy with any mobile experience, with preference for iPhone or Android experience. Having both is ideal. This client is a very large media company and you'd basically be responsible for leading one division's mobile efforts, starting with maintaining their existing apps, but eventually eventually extending them and building new ones. It's a great opportunity for the right person. If you're in New York or willing to relocate there and have some good mobile chops, drop me an e-mail with your resume (my main e-mail is my twitter name at mac dot com or you can send them to jeff at martiancraft dot com) and I'll put it in front of the hiring manager.

Read more »

Posted in: Rant,Update

Microsof't Funeral

There's really not much fun in bashing Microsoft any more. Although they're still firmly entrenched in the desktop space and profitable as a company, their attempts to make inroads into emerging markets have been less than stellar and in what's arguably the most important emerging market – mobile – they've gone from being a moderately strong player to an almost non-existent fringe player in just a few short years.

You may not believe this, but I'm actually rooting for Windows 7 Phone (though I still hate the name). I really want it to be good, and it has the potential to be good, and even the potential to be better than Android out of the gate. Microsoft's problem has never been lack of good engineers; their problems are almost exclusively management making it impossible for the engineers to deliver something awesome. A lot of Microsoft products have had the potential to be good, but weren't.

But, maybe this is the product that will turn the tide. And if Windows 7 Phone can get some traction, there are a lot of developers out there familiar with C#, .Net, and Visual Studio who will jump aboard their market. I've actually been hearing a lot of good things about the Windows 7 Phone SDK and tools from people. I'm not sure I'd like them - I've never really liked the high-level approach that .NET takes - but a lot of people do, so there's a large pool of potential developers if they can get the platform off the ground.

I'd really love to see the mobile space avoid the quasi-monoculture problems that the desktop space has had thanks to the dominance of Windows. Real competition is good.

So, yeah… I'm kinda rooting for Windows 7 Phone even though I know there's at pretty good chance that Microsoft Management Idiocy™ has ruined another potentially good product. I'm cautiously optimistic based on what I've been hearing from people with access to the tools.

Given that, then, I found yesterday's news of Microsoft's RTM "parade" for Windows 7 Phone very sad. Who throws a victory party before the race has even started? Hell, who even throws themselves a parade?? In the words of Wil Shipley, it's just gauche.

I think the funeral was really for Microsoft's last shred of dignity.

Read more »

Posted in: Microsoft,Rant,Windows 7 Phone

Mea Culpa

The original version of my Briefs.app blog post contained a snarky comment about the Director of the App Review team and a link to a Wired article about his past. A friend of mine, who happens to work at One Infinite Loop, privately took me to task for including that link in my post.

It took me about two seconds, now that I'm a little further away from it and not as angry, to realize that he's 100% right. It was a dick move on my part and I'm sorry for it. I have removed the link and offer my apologies to Phillip Shoemaker. The fact is, I have no visibility into what's going on and don't know where the holdup is on Briefs.app. For all I know, Mr. Shoemaker could be valiantly fighting for Briefs.app against higher up forces in the company, so casting an ad hominem attack like that was juvenile and uncool.

My basic feelings about the matter are unchanged, however. It was uncool when Apple left Google Voice in limbo, but that was one small product from one very large company. In this case, it's the sweat equity from one individual developer who worked very, very hard, sacrificing sleep, family time, and entertainment to create something very cool. The impact is much greater and much more personal and it's hard for me not to get angry about it.

Read more »

Posted in: App Review,Apple,Rant

Briefs.app

My co-worker and all-around good guy, Rob Rhyne has officially open sourced Briefs.app as of today. After three months of being dicked around by Apple's review team, he's finally given up on getting Briefs.app onto the App Store.

Throughout the ordeal, Rob has taken the whole thing with tremendous grace and has only good things to say about the people involved in the entire process. I hope he'll forgive me for not being quite so gracious.

I'm pissed on his behalf, since he won't be. Make no mistake: This sucks. This is no way to treat anybody, but especially him. Rob has bent over backwards throughout the process to be nice and work within the system and to avoid saying anything negative about the problems he's faced. Rob has kept the discourse on a level I think few of us could manage. He didn't go out and raise a stink the way many developers have when they felt slighted by the App Review team. Rob just calmly and patiently worked within the system trying to make his case and get a product he worked on for months onto the app store… while working a full time job, starting a new business, and being a parent to a toddler. Oh, and his wife works too. Rob's one of the few developers I know who spends more time sitting at a computer than me.

If Apple's review team had just come out and rejected the app, it would have sucked, and it would have been the wrong decision, but it would have been an acceptable situation. The app review team's job is to make tough decisions. Sometimes they're going to make bad decisions, and sometimes they're going to make decisions that we developers are going to disagree with.

But since making decisions is, in fact, their job and they've never actually made a decision about this particular app, it's not an acceptable nor a forgivable situation. Three fucking months Briefs.app has sat in the review queue, and in that time, the app review team has allowed other prototyping applications onto the app store: applications that do the same basic tasks that Briefs.app was created to do. Interface was approved several weeks after Briefs.app was submitted to the App Store. LiveView and Dapp were both updated just yesterday. iMockups was approved about a week ago.

But Briefs still sits in the queue and nobody can be bothered to even say what the exact holdup is or what needs to happen before a decision will get made.

I don't know what reason they could have for dragging it on like this and not making a decision, but it's not right. Apple owes Rob, and all the people who want to use Briefs, an apology.

Read more »

Posted in: Apple,Briefs,Rant,Review Process

App Licensing

For all those people telling me that Google's App Licensing would put a definitive stop to piracy on Android and that Apple should implement something similar, all I can say is: I told you you were wrong and here's proof, and it didn't take even as long as I said it would.

I understand Google has to address piracy because it's a bit of a black eye for the platform. They need third party developers, and a lot of third party developers are gun-shy about developing for a platform with a reputation for rampant piracy. Although the iPhone has its own problems with piracy, it's on a completely different scale. The closed nature of the platform is actually an advantage for third party developers, much the way gaming consoles are. Sure, Apple's protection scheme has been compromised and any App posted to the app store can be pirated easily. But, because only people who Jailbreak their phones can actually install the hacked software, and Jailbreaking a phone can cause problems with future updates from Apple, there's built-in damage control.

It also helps that you can buy App Store apps in every country where you can legally buy an iPhone. On Android, you can only buy apps in 13 countries, meaning people in other countries either have to do without paid apps, or have to pirate. There's built-in incentive in that system for people who might be perfectly willing to pay for an app to go pirate it. Google would get more for their piracy-battling dollar by expanding the paid markets than by implementing more hare-brained licensing schemes that won't ever make a dent in piracy.

I don't envy Tim Bray's task of having to try and reassure Android developers that this crack isn't a problem. Of course it's a problem. It's a problem the media industries have been fighting with since the dawn of digital content. The RIAA, MPAA, and media companies have invested millions, maybe even billions of dollars into various schemes that have failed to make much of a dent in piracy.

For those who think this App Licensing can ever work, you (much like the media industry) fail to grasp the inherent technical flaw with any kind of DRM. With DRM, you have to provide the legal purchaser with the content and with the key to unlock that content. No matter how sophisticated the stuff in-between, no matter how complex the lock, a sufficiently technically knowledgeable person who has the content and the key to unlocking it can find a way to free the content from its protection. On Android, once you've freed the content from its DRM, you can distribute it to anybody because of the ability to sideload applications. So on most Android phones right now, once a single copy of a program has been hacked, it's just as easy to pirate as it was without App Licensing.

With software, finding the balance between making it inconvenient to pirate (because you can't make it impossible) without overly inconveniencing your customers is hard. It's easier on a closed platform. That's not to say there aren't downsides to a closed platform — of course there are — but this is one of the clear advantages for third party developers. Truth be told, you simply can not stop the dedicated pirate, but a closed platform does deter the bulk of the pirates who can be diverted into paying customers by making it inconvenient. Best of all, it does it without affecting the legal purchasers, unlike most DRM.

When it comes down to it, the most effective way to stop piracy is to make it easy and convenient for as many people to buy content legally as is possible and to price it fairly. This is something Google clearly doesn't get, or else you'd be able to buy paid apps everywhere you can buy an Android phone.

Read more »

Posted in: Android,Google,Rant