Nov 11

Happy 11-cubed day!

Everybody has been reviewing and posting excerpts from the Steve Jobs biography recently. So I’m going to talk about a different book.

If you’re already a fan of Neal Stephenson, you can stop reading now and just go and get the book. You won’t be disappointed.

Stephenson has written several classic Sci-Fi/Cyper-Punk/computer-related novels. Snow Crash and Cryptonomicon are two of my favorites. He made a detour, in my opinion, with the Baroque Cycle which I never managed to get through.

With Reamde he’s back in a contemporary setting and the story revolves around a fictional MMO called T’Rain. If you’re into playing World of Warcraft, then you’ll find the similarities and story plots very interesting.

Throw in a gang of international terrorists, rouge Russian mobsters, and a group of Chinese hackers, and you get a very intense and fast-paced thriller that moves between the virtual and real world.

This was the longest book I’ve read with iBooks (print length 1056 pages). With such an engrossing story, the chrome of the app and the iPad itself disappear. As I suspected the very realistic page turn animation in iBooks doesn’t matter when you’re actually reading a long book. However, one iBooks feature I found myself using frequently, and one that’s sorely missing in the Kindle app, is the number of pages remaining in the chapter. With Stephenson’s prolific writing don’t be surprised to see that you have 384 pages remaining in the current chapter…

written by Nick \\ tags: ,

Nov 04

A long standing “problem” with Cocoa has been Apple’s insistence that HTTP header field names are case-insensitive. This is clearly described in the documentation and also in the relevant RFC.

However not all server systems follow these standards so strictly and often require HTTP header field names to have a specific case. For example if the server expects the name “MyHeaderField” and your app sends “Myheaderfield” then the server may not read the value sent in the header field at all.

Your code may look something like this:

NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"http://www.server.com"]];
[request setValue:@"value" forHTTPHeaderField:@"MyHeaderField"];

The problem was that when the HTTP request is sent to the server, the case of the name of the header field was “helpfully” changed for you, without giving you any control over the exact change or any way to override it. In the example above the name would become “Myheaderfield” instead of “MyHeaderField”, which is what you specified in the code.

If you have control over the server API you could just ask the server team to look for “Myheaderfield” instead and all would be well. But if the server API was a third party serving multiple clients, you would have a problem.

With iOS 5 this behavior has changed. Now the header field names are not changed at all. Whatever you specify in your code is what is sent to the server. Nice!

If your code looks like the snippet above, and you made a deal with the server team to look for the modified case string, then you may have issues when your app is running on iOS 5. Of course in the perfect world where servers followed the RFC to the letter, there would not be an issue (in iOS 5 or earlier) because the server would not care about the capitalization and treat “MyHeaderField” and “Myheaderfield” as the same.

http://0xced.blogspot.com/2010/06/fixing-nsmutableurlrequest.html

http://www.cocoabuilder.com/archive/cocoa/142670-http-extensions-to-nsmutableurlrequest-erroneously-modify-headers.html

http://stackoverflow.com/questions/2543396/how-to-add-lowercase-field-to-nsurlrequest-header-field

written by Nick \\ tags:

Oct 28

Apple has made several subtle changes related to case (as in upper/lower/mixed-case) in the URL and HTTP communication classes for iOS 5. Here’s the first one, and more blog posts to follow.

With a UIWebView I often implement the shouldStartLoadWithRequest method in the UIWebViewDelegate to look at the link the user tapped and take specific action for certain types of links. Here’s a simple example that handles mailto links:

- (BOOL)webView:(UIWebView *)theWebView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType {
	BOOL shouldStartLoadWithRequest = YES;

	NSString *scheme = [[request URL] scheme];
	if ([scheme isEqualToString:@"mailto"]) {
		[[UIApplication sharedApplication] openURL:[request URL]];
		shouldStartLoadWithRequest = NO;
	}

	return shouldStartLoadWithRequest;
}

Another common use is to handle application specific links like “MyApp://goto?id=42″. If you just replaced @”mailto” with @”MyApp” in the example code above, it turns out that this breaks in iOS 5. The reason is that iOS 5 returns “myapp” (all lowercase) for the scheme, whereas iOS 4 and earlier returned the actual string from the HTML link unaltered.

The solution is simple. Just make your string comparison case insensitive. For example:

if ([scheme compare:@"MyApp" options:NSCaseInsensitiveSearch] == NSOrderedSame) {

written by Nick \\ tags: , ,

Oct 21

One of the better known apps we at Pervasent have developed is the Zinio magazine reader app. For a while it’s been in the top 5 of the Top Grossing iPad Apps on the App Store. Duking it out with Apple’s Pages app, Angry Birds and Smurfs’ Village for the top spots.

Recently the Zinio app was awarded the “Best Global App” by the Internet Marketing Association at an award ceremony in Las Vegas. The event was opened by the Mayor of Las Vegas and streamed live to 11k people (out of IMA’s 350k members). So sounds like a pretty big deal. I’m not sure what the selection criteria was, or who the competitors were. But it doesn’t get much better than being the best global app. Nice!

written by Nick

Oct 14

Marco wrote a great post explaining the issues with local file storage in iOS 5. Please read it now and then come back.

There are also many threads on the Apple Developer Forums about this (developer login required):

Confusion

There is considerable confusion around this subject because there are many different issues discussed and lumped together:

  • The semantics of cache and tmp directories
  • Changes/gaps in Apple’s documentation
  • App review rejections
  • What is being backed up by iTunes and iCloud
  • Changes in behavior in iOS 5

Let’s discuss each issue separately:

The semantics of cache and tmp directories

If you have an OS X or Unix background, it’s easy to understand Apple’s position that such directories have no guarantee as to how long the data in them will persist.

The fact that the tmp directory in the app’s sandbox is not the same as the root /tmp directory, should not make a difference in how you think about this directory.

If you have never observed files being removed from these directories in the past, that is not a guarantee that it will not change in the future. Especially when the change is in accordance with documentation. This is a general rule.

Changes/gaps in Apple’s documentation

As late as June 29, 2011 Apple’s documentation regarding <Application_Home>/Documents said:

Use this directory to store user documents and application data files.

This is pretty clear. No wonder developers are unhappy that the rules for the Documents directory have changed in iOS 5 without any suitable alternative.

And regarding <Application_Home>/Library/Caches

Use this directory to write any application-specific support files that you want to persist between launches of the application or during application updates. Your application is generally responsible for adding and removing these files. It should also be able to re-create these files as needed because iTunes removes them during a full restoration of the device.

The phrasing in this section is definitely vague. The general impression that I get from reading this is that Apple has made a fundamental change with iOS 5 that contradicts this paragraph. But if you instead focus on the words "generally" and "able to re-create" you could argue that Apple has warned you what might happen to your files.

The iOS Data Storage Guidelines state:

To ensure that backups are as efficient as possible, be sure to store your app’s data according to the following guidelines:

1. Only documents and other data that is user-generated, or that cannot otherwise be recreated by your application, should be stored in the <Application_Home>/Documents directory and will be automatically backed up by iCloud.

2. Data that can be downloaded again or regenerated should be stored in the <Application_Home>/Library/Caches directory. Examples of files you should put in the Caches directory include database cache files and downloadable content, such as that used by magazine, newspaper, and map applications.

3. Data that is used only temporarily should be stored in the <Application_Home>/tmp directory. Although these files are not backed up to iCloud, remember to delete those files when you are done with them so that they do not continue to consume space on the user’s device.

If we for the moment disregard the fact that sole purpose of many magazine, newspaper and map apps is to display content offline, these guidelines are clear and make sense.

App review rejections

Developers are reporting that apps that store any/some/much data in the Documents directory are being rejected by App Review.

It’s unlikely that the App Review team has detailed knowledge of which files are being stored in which directory and which of those are user generated vs. data that can be downloaded again or regenerated. Some developers have reported success in responding to the App Review team with an explanation of how their app is storing data and how that is in accordance with the rules.

What is being backed up by iTunes and iCloud

Everything in the app’s home directory is backed up, with the exception of:

  • The app bundle itself (.app)
  • <Application_Home>/tmp directory
  • <Application_Home>/Library/Caches directory

This is clear from the iOS Data Storage Guidelines and Michael Jurewitz comment.

Other documentation clearly states that the Application Support directory is also backed up by iTunes (and presumably iCloud). In the discussions some developers have suggested that Application Support directory would be safer (= more permanent) alternative to Caches. To me it seems that App Review would crack down on large amounts of data stored in Application Support with the same fervor as for the Documents directory, since it’s all about iCloud storage.

Changes in behavior in iOS 5

As of iOS 5, <Application_Home>/Library/Caches may be purged while your app is not running if the device experiences a low disk space warning.

What’s missing?

There is no longer a directory where your app can store files that are:

  • Not backed up to iTunes/iCloud
  • Not at risk of being purged

It’s obviously too late to implement this for iOS 5.0. But if enough developers make a case that this is really needed for their apps, then it might happen in a future version. Hint: file a bug report.

What’s a developer to do?

If you are currently storing files in the Documents directory

Your app will continue to work in iOS 5 without any issues. Your customers might complain about too much data being backed up to iCloud. (See below.)

However, when you update your app, it’s likely that it will be rejected for storing too much data in the Documents directory.

If you are currently, or are considering, storing files in the Caches directory

Make sure that your app can gracefully handle the situation when any of the files you stored in the Caches directory disappears. One way to handle this is to keep a list of all the files you store in Caches along with their source URLs. (And obviously store this file in a different, more permanent location.) Then at app start go through the list and verify that the files are still there.

If any files are missing you can show a dialog to the customer apologizing, explaining the situation, and asking if the files should be downloaded again. If the device is offline, you apologize and explain that the customer is screwed.

There are many more complicated situations than these two, e.g. where partial data is available. You need to decide what and how much data you can display.

I love the use case pointed out by one of the developers in the Apple forums: His app is used by pilots to display maps. If he was to store the downloaded maps in Caches and they were suddenly deleted by iOS 5 and this was discovered while the plane is in the air, that could have some dire consequences. A dialog asking the pilot to download the maps data again would add insult to injury. Literally.

Migrating existing data

If you update your app to be compliant with the new iOS 5/iCloud rules and now store files in the Caches directory, then you should probably move any existing files from Documents to Caches. I’m sure that the app review team will not test this because they will not have an old version of your app with data saved. But it seems like the right thing to do.

Remember to not start a big job of moving files on the main thread during app startup. This will get your app killed by the startup timer watchdog.

Early warning

When the app is running, you can warn the customer if the device is running low on disk space. This will not prevent files from being removed, but at least it will raise some awareness about the issues.

I don’t know how low the available disk space needs to go before the iOS 5 cleaning process kicks in, and I doubt that Apple will ever specify this. Please add a comment to this post if you have any results from your own experiments.

Let Apple know that this is a big problem

File a bug report.

What’s a customer to do?

Until now, apps that store a lot of data in directories that are backed up have been a problem because the iTunes backup process took a very long time. This was especially true if a large number of files needed to be backed up.

With iCloud backup, customers may not want to use their precious 5 GB data allotment (or pay for additional storage) to backup what they consider to be non-essential data. It is possible to turn off iCloud backup for individual apps. Just go to this easy to find location in the Settings app: iCloud > Storage & Backup > Manage Storage > Backups. In the Backup Options list on this screen, backup can be turned on/off for each app. Since it’s unlikely that your customers will stumble across this setting, you may want to prepare a support email with these instructions.

It is my understanding, although I have not tested this yet, that turning off iCloud backup will not affect iTunes backups. But for customers who have cut the cord and are no longer syncing with their computer, they will be without any backup of their app data if it’s turned off as described above.

written by Nick \\ tags:

Oct 12

If you installed a beta version of iTunes along with the beta releases of the iOS 5 SDK, you may encounter a problem when trying to update to the public release version.

When I tried to update my non-development iOS device to iOS 5 with a beta version of iTunes 10.5 I was informed that I needed iTunes 10.5 to do this. Fine. Since I knew that 10.5 had been released to the public, I selected Check for Updates to download it. But the Software Update application said that there was no update available for me.

Solution: Download the iTunes disk image file here and install it.

written by Nick \\ tags: ,

Oct 07

Apple announced the iPhone 4S and as usual many pundits are proclaiming their bitter disappointment. Let’s take a rational look at what Apple announced.

Hardware

The iPhone 4S has the following new or improved hardware:

  • Significantly faster processor.
  • A much improved camera.
  • 1080p HD video recording.
  • A new image signal processor.
  • AirPlay audio and video streaming and screen mirroring.
  • GSM and CDMA combined in one phone.
  • A redesigned system for managing the antennas.
  • Data download rates approaching 4G speeds over 3G networks.
  • Despite more and faster hardware, maintains industry leading battery life.

Wow, those hardware engineer slackers at Apple. What have they been doing for the past 15 months?

Why did they not give us:

  • A larger screen. Never mind that it would either lower the pixel density of the retina screen, or change the number of pixels and thus breaking most apps.
  • A 3D screen. Those devices are cool, but their sales numbers are not exactly approaching iPhone 4 levels.
  • A 3D camera. Ditto.
  • NFC. Consumers and merchants are not lining up for a new way to pay with a phone. The biggest cheerleader for NFC is Google, who wants to "manage" your purchase history data.
  • Solar powered. When there’s a quantum leap in solar cell efficiency, I doubt that cell phones will be the first application.
  • A new case design.
  • An "iPhone 5" label.

Since Apple only recently managed to fully meet demand for the iPhone 4, does it not make sense to continue to use as much as possible of the existing case and assembly materials and processes for the new phone? Which would in turn make it possible to roll out the iPhone 4S more quickly to more countries?

In the future you might as well get used to the incremental hardware improvements for the iPhone. Which is just what Apple has done for the past four iPhone generations.

Software

Software does not suffer from the same pesky physical laws and limitations that hardware has to abide by. As long as we continue to see incrementally faster processors and more memory, there’s really no limit to software innovations.

So what did we get along with the iPhone 4S:

  • iOS 5 – Many significant improvements over the current OS.
  • iCloud – A new way to manage your data across multiple devices and computers.
  • iMessage – A clever end-run around the phone carriers. I bet they didn’t see this coming as a software update to millions of their current customers.
  • Siri – A very sophisticated personal assistant with AI-like qualities.

Of course many of these software innovations require and depend on the incrementally better hardware. This is what Apple does so well: integrating hardware and software.

In the future the new smarts in Smartphones will continue to come from the software. The pundits can shed tears over the lack of fantasy hardware. In the meantime, we developers are more than happy to welcome the next 100 million iPhone 4S owners as our customers.

written by Nick \\ tags:

Oct 05

I am honored to be with you today at your commencement from one of the finest universities in the world. I never graduated from college. Truth be told, this is the closest I’ve ever gotten to a college graduation. Today I want to tell you three stories from my life. That’s it. No big deal. Just three stories.

The first story is about connecting the dots.

I dropped out of Reed College after the first six months, but then stayed around as a drop-in for another 18 months or so before I really quit. So why did I drop out?

It started before I was born. My biological mother was a young, unwed college graduate student, and she decided to put me up for adoption. She felt very strongly that I should be adopted by college graduates, so everything was all set for me to be adopted at birth by a lawyer and his wife. Except that when I popped out they decided at the last minute that they really wanted a girl. So my parents, who were on a waiting list, got a call in the middle of the night asking: “We have an unexpected baby boy; do you want him?” They said: “Of course.” My biological mother later found out that my mother had never graduated from college and that my father had never graduated from high school. She refused to sign the final adoption papers. She only relented a few months later when my parents promised that I would someday go to college.

And 17 years later I did go to college. But I naively chose a college that was almost as expensive as Stanford, and all of my working-class parents’ savings were being spent on my college tuition. After six months, I couldn’t see the value in it. I had no idea what I wanted to do with my life and no idea how college was going to help me figure it out. And here I was spending all of the money my parents had saved their entire life. So I decided to drop out and trust that it would all work out okay. It was pretty scary at the time, but looking back it was one of the best decisions I ever made. The minute I dropped out I could stop taking the required classes that didn’t interest me, and begin dropping in on the ones that looked interesting.

It wasn’t all romantic. I didn’t have a dorm room, so I slept on the floor in friends’ rooms, I returned Coke bottles for the 5-cent deposits to buy food with, and I would walk the seven miles across town every Sunday night to get one good meal a week at the Hare Krishna temple. I loved it. And much of what I stumbled into by following my curiosity and intuition turned out to be priceless later on. Let me give you one example:

Reed College at that time offered perhaps the best calligraphy instruction in the country. Throughout the campus every poster, every label on every drawer, was beautifully hand calligraphed. Because I had dropped out and didn’t have to take the normal classes, I decided to take a calligraphy class to learn how to do this. I learned about serif and san serif typefaces, about varying the amount of space between different letter combinations, about what makes great typography great. It was beautiful, historical, artistically subtle in a way that science can’t capture, and I found it fascinating.

None of this had even a hope of any practical application in my life. But 10 years later, when we were designing the first Macintosh computer, it all came back to me. And we designed it all into the Mac. It was the first computer with beautiful typography. If I had never dropped in on that single course in college, the Mac would have never had multiple typefaces or proportionally spaced fonts. And since Windows just copied the Mac, its likely that no personal computer would have them. If I had never dropped out, I would have never dropped in on this calligraphy class, and personal computers might not have the wonderful typography that they do. Of course it was impossible to connect the dots looking forward when I was in college. But it was very, very clear looking backwards 10 years later.

Again, you can’t connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something–your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life.

My second story is about love and loss.

I was lucky–I found what I loved to do early in life. Woz and I started Apple in my parents garage when I was 20. We worked hard, and in 10 years Apple had grown from just the two of us in a garage into a $2 billion company with over 4000 employees. We had just released our finest creation–the Macintosh–a year earlier, and I had just turned 30. And then I got fired. How can you get fired from a company you started? Well, as Apple grew we hired someone who I thought was very talented to run the company with me, and for the first year or so things went well. But then our visions of the future began to diverge and eventually we had a falling out. When we did, our Board of Directors sided with him. So at 30, I was out. And very publicly out. What had been the focus of my entire adult life was gone, and it was devastating.

I really didn’t know what to do for a few months. I felt that I had let the previous generation of entrepreneurs down–that I had dropped the baton as it was being passed to me. I met with David Packard and Bob Noyce and tried to apologize for screwing up so badly. I was a very public failure, and I even thought about running away from the Valley. But something slowly began to dawn on me–I still loved what I did. The turn of events at Apple had not changed that one bit. I had been rejected, but I was still in love. And so I decided to start over.

I didn’t see it then, but it turned out that getting fired from Apple was the best thing that could have ever happened to me. The heaviness of being successful was replaced by the lightness of being a beginner again, less sure about everything. It freed me to enter one of the most creative periods of my life.

During the next five years, I started a company named NeXT, another company named Pixar, and fell in love with an amazing woman who would become my wife. Pixar went on to create the worlds first computer animated feature film, “Toy Story,” and is now the most successful animation studio in the world. In a remarkable turn of events, Apple bought NeXT, I returned to Apple, and the technology we developed at NeXT is at the heart of Apple’s current renaissance. And Laurene and I have a wonderful family together.

I’m pretty sure none of this would have happened if I hadn’t been fired from Apple. It was awful tasting medicine, but I guess the patient needed it. Sometimes life hits you in the head with a brick. Don’t lose faith. I’m convinced that the only thing that kept me going was that I loved what I did. You’ve got to find what you love. And that is as true for your work as it is for your lovers. Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven’t found it yet, keep looking. Don’t settle. As with all matters of the heart, you’ll know when you find it. And, like any great relationship, it just gets better and better as the years roll on. So keep looking until you find it. Don’t settle.

My third story is about death.

When I was 17, I read a quote that went something like: “If you live each day as if it was your last, someday you’ll most certainly be right.” It made an impression on me, and since then, for the past 33 years, I have looked in the mirror every morning and asked myself: “If today were the last day of my life, would I want to do what I am about to do today?” And whenever the answer has been “No” for too many days in a row, I know I need to change something.

Remembering that I’ll be dead soon is the most important tool I’ve ever encountered to help me make the big choices in life. Because almost everything–all external expectations, all pride, all fear of embarrassment or failure–these things just fall away in the face of death, leaving only what is truly important. Remembering that you are going to die is the best way I know to avoid the trap of thinking you have something to lose. You are already naked. There is no reason not to follow your heart.

About a year ago I was diagnosed with cancer. I had a scan at 7:30 in the morning, and it clearly showed a tumor on my pancreas. I didn’t even know what a pancreas was. The doctors told me this was almost certainly a type of cancer that is incurable, and that I should expect to live no longer than three to six months. My doctor advised me to go home and get my affairs in order, which is doctor’s code for prepare to die. It means to try to tell your kids everything you thought you’d have the next 10 years to tell them in just a few months. It means to make sure everything is buttoned up, so that it will be as easy as possible for your family. It means to say your goodbyes.

I lived with that diagnosis all day. Later that evening I had a biopsy, where they stuck an endoscope down my throat, through my stomach and into my intestines, put a needle into my pancreas and got a few cells from the tumor. I was sedated, but my wife, who was there, told me that when they viewed the cells under a microscope the doctors started crying, because it turned out to be a very rare form of pancreatic cancer that is curable with surgery. I had the surgery and I’m fine now.

This was the closest I’ve been to facing death, and I hope its the closest I get for a few more decades. Having lived through it, I can now say this to you with a bit more certainty than when death was a useful but purely intellectual concept:

No one wants to die. Even people who want to go to heaven don’t want to die to get there. And yet death is the destination we all share. No one has ever escaped it. And that is as it should be, because death is very likely the single best invention of Life. It is life’s change agent. It clears out the old to make way for the new. Right now the new is you, but someday not too long from now, you will gradually become the old and be cleared away. Sorry to be so dramatic, but it is quite true.

Your time is limited, so don’t waste it living someone else’s life. Don’t be trapped by dogma–which is living with the results of other people’s thinking. Don’t let the noise of others’ opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition. They somehow already know what you truly want to become. Everything else is secondary.

When I was young, there was an amazing publication called “The Whole Earth Catalog,” which was one of the bibles of my generation. It was created by a fellow named Stewart Brand not far from here in Menlo Park, and he brought it to life with his poetic touch. This was in the late 1960’s, before personal computers and desktop publishing, so it was all made with typewriters, scissors, and polaroid cameras. It was sort of like Google in paperback form, 35 years before Google came along: It was idealistic, and overflowing with neat tools and great notions.

Stewart and his team put out several issues of “The Whole Earth Catalog,” and then when it had run its course, they put out a final issue. It was the mid-1970s, and I was your age. On the back cover of their final issue was a photograph of an early morning country road, the kind you might find yourself hitchhiking on if you were so adventurous. Beneath it were the words: “Stay Hungry. Stay Foolish.” It was their farewell message as they signed off. Stay Hungry. Stay Foolish. And I have always wished that for myself. And now, as you graduate to begin anew, I wish that for you.

Stay Hungry. Stay Foolish.

Thank you all very much.

Watch the video here. Try to ignore the impolite, bored looking Stanford graduates. They may not understand what a truly extraordinary man Steve Jobs was.

Steve – Thank you for creating and leading our tribe.

written by Nick

Aug 18

We need to submit our app to the store before it closes for the weekend—what time does the app store close on Friday nights?

I found that quote on the very funny site ClientsFromHell.net. Reportedly it’s an actual quote from a real client.

Of course the App Store is not shut down for customers during weekends. But we have recently found out that the app review team no longer works on weekends. Back in the days when it seemed like the app reviewers were constantly having trouble keeping up with the ever increasing flood of app submissions, you would see apps get approved at all hours of the day and on weekends. No longer.

In a previous life when I was building large scale web sites and server systems we learned to never deploy new code on a Friday, unless you wanted to work on weekends to fix bugs or deal with launch jitters.

The same thing applies to iOS apps now. Don’t set the release date of an app to fall on a Friday. Should there be a problem with the new version of the app and you want to push through an emergency update, then nobody will act on your request until the following Monday.

But, you don’t have control over when an app will be approved, you say. That is true, but you can set the date when the app will be released. And you should always, always use this feature.

Look at the current App Store Review Status and add some margin to allow for delays. For example, today the status says that 99% of all new app submissions and 99% of all app updates are reviewed within 7 days. I would set the release date to around 2 weeks for an app update. Make sure that the date is not a Friday, and that it’s a day when you’re available and ready to handle new customer support issues.

For a new app submission I would set the release date even further into the future to allow your marketing campaign to ramp up and steam forward towards a known date. But that’s a different topic.

written by Nick \\ tags: ,

Aug 16

Less than two weeks ago Google’s Chief Legal Officer David Drummond wrote a blog post criticizing what he calls bogus patents. “Patents were meant to encourage innovation, but lately they are being used as a weapon to stop it.”

Yesterday Google announced that they are acquiring Motorola Mobility in order to “supercharge” Android. In the conference call with analysts they repeatedly emphasized the access to Motorola’s 17,000 patents. I’m assuming that these particular patents do not fall under the “bogus” category, and that their primary use will be to encourage innovation, and will not be used as weapons…

This transaction raises the software patent debacle to a whole new level of absurdity. Google is spending 12.5 billion dollars on something that will not create any new innovations. Not a single one. But what’s $12.5B for a rich company like Google? It’s actually the entire profit generated by Google over the past two years…

Some analysts say that Google had to do this to shore up their lagging “bogus” patent portfolio. But let’s leave the legal games to the lawyers and think about how $12.5B could be used to really supercharge innovation.

One criticism of the Android platform is that it lacks killer apps. So imagine if Google spent a billion or so on recreating the top 1,000 iPhone and iPad apps for Android. That might not make Android developers happy. So we’ll assume that they make all the code open source so that any developer can build upon the code and submit to the Android market. That will allow us to throw in the “open” buzzword into the mix too. Bonus!

But wait, copying existing iOS apps probably does not qualify as being innovative. Back to the drawing board…

Android tables are widely seen as lagging far behind the iPad in sales. So let’s seed the market with some subsidized Android tablets. That might “supercharge” the Android ecosystem. Say that a generic Android tablet costs $300 to manufacture and a consumer price of $99 will make them fly off the shelves. Spending $12.5B in subsidies would flood the market with 62,831,853 tablets. This move in itself is not very innovative, but it should definitely spur some activity and innovation among Android tablet developers.

Industrial design of Android devices and UI design of the Android OS could also use some refinement. How about hiring away some superstar talent? Jonathan Ive will probably not sell his soul for $12.5B, but how about one of the designers of the original iPhone UI? I bet that Facebook picked them up for a lot less. Create a separate company, just like Motorola Mobility is supposed to be run. Seed it with superstars and a few billion and see what innovations come out into the “open”.

So how will Googrola affect us iOS developers? My bet is: not at all. I can’t see how acquiring one of the larger, existing and money-losing Android licensees, will suddenly spur innovation, superchargers and wonderful user experiences. Besides, they are going to be very busy selling ads to pay for this acquisition.

written by Nick \\ tags: ,