The App Business Blog

From Apple Developer News:

Beginning January 9, app screenshots will be locked in iTunes Connect once your app has been approved. New screenshots may be uploaded when you submit a binary for an update to an existing app or a new app.

This is in response to the tactic employed by some scam apps whereby they switched the screenshots after the app had been approved to look like a popular app with the hope of tricking customers into downloading the wrong app. See this blog post from Panic for an example.

Sigh.

written by Nick

This blog was started in March 2008, back in the days when all iPhone development information was covered by Apple’s draconian NDA. I take great pride in having helped many developers get started with iPhone and iPad development, and answering their questions here on the blog.

Today the landscape for information for iOS developers is very different. For pure programming questions is impossible to beat the sheer breadth of StackOverflow. That is one reason why you have seen a lot fewer programming related blog posts here lately; there’s no point in writing up something that is already well covered on another web site.

If you miss the pure programming topics, here are a few blogs and resources for iOS developers that I highly recommend:

• RayWenderlich.com has awesome in-depth tutorials on many iOS topics. With each new iOS release they also publish a tome of a book packed with tutorials and sample code. A great resource to quickly get up to speed on new iOS API:s.
• ManiacDev.com regularly publishes short notes on new open source components and projects for iOS developers. Keeping an eye on this can save you a lot of time in your app development.

So what does the future hold for this blog?

I want to continue helping app developers on their journey to make great apps and to be able to make a living doing so.

Today I’m happy to announce that I’m relaunching this blog as The App Business Blog.

It is increasingly clear to me that pure development skills are not enough to survive and thrive in today’s very competitive App Store marketplace. So going forward you will be seeing a lot fewer programming topics covered here, and a lot more information about marketing your apps. You can also expect more reviews of books, services and information products relevant to app entrepreneurs. (If you have a product or a service that you think is relevant to the readers of this blog, please contact me here.)

Comments are now enabled again, so please let me know what you would like to see here in the future.

written by Nick

If you are not already a regular reader of Mike Ash’s Friday Q&A blog, then you should immediately subscribe to his RSS feed.

Mike typically takes a very narrow topic and explores it to the ultimate depth. This week’s topic is about something seemingly as simple as what happens in the CPU when it loads a byte of memory. It’s not something that you worry about every day as you’re writing Objective C code. Although there is a good explanation of what causes the dreaded EXC_BAD_ACCESS crashes. For me it was a fun trip down memory lane from the days when I was designing hardware and software at this low level.

Even if this week’s particular topic is not of great interest to you, I’m sure you will learn a lot from Mike’s weekly column. I certainly do. If you want to catch up on his past column in a convenient ebook format, and at the same time support his writing, you can buy his book from the iBookstore as well as Amazon.

written by Nick

Ready Player One is a fun novel by Ernest Cline that I purchased mostly on a whim to have something to listen to while we were wrapping Christmas presents and preparing for tomorrow’s festivities. The reviews for this book on Audible.com were glowing, and there was more than one comparison to Douglas Adams. Since DNA is my all-time favorite author, I figured I couldn’t go wrong with Ready Player One.

The main characters of the book spend all their time immersed in an online game called OASIS. Even schools are virtual and online in the OASIS world. A very interesting idea. The players start out competing in an online competition to find an Easter Egg hidden by the game’s eccentric creator. The first person to find the Easter Egg will inherit his vast fortune, including control over OASIS. The online easter egg hunt quickly starts having real world implications and the young protagonists find themselves fighting an epic battle of good vs. evil.

If you have ever played World of Warcraft, Order & Chaos, Celtic Heroes, or some other MMO game then you will feel right at home in this book. Both because you will recognize the environment, and you’ll understand the addictive qualities these games have.

But you don’t have to be a World of Warcraft player to enjoy this book. But being a geek certainly helps. The books is filled with references to early video games and 1980’s pop culture. If you, like me, grew up in this era and had some exposure to computers and video games, then I think you will love this book. My son, who missed this era by about three decades,  also thoroughly enjoyed this book.

Highly recommended. Especially the audio book version read by Wil Wheaton.

written by Nick

I have commented about developers who do not take the time to display a proper name under the app icon before on this blog.

Recently I experienced a variation on this issue. An app that I was working on was a universal app (both iPhone and iPad). The name of the app fit perfectly under the app icon on the iPad, but on the iPhone (where the icon is smaller) the name got truncated with the ugly … in the middle of the name.

As you may recall, the best way to control the name that is displayed under the app icon is to create an entry in the InfoPlist.strings file like this:

"CFBundleDisplayName" = "YourAppName";

Instead of resorting to abbreviating the name on the iPad just so that it would fit on the iPhone, I wondered if there was a way to have different strings for each platform. After some experimentation it turns out that there is. And it’s quite logical too. Just add the usual ~iphone and ~ipad suffixes after the key, and it just works.

"CFBundleDisplayName~iphone" = "iPhoneName";
"CFBundleDisplayName~ipad" = "iPadNameLong";

written by Nick \\ tags: CFBundleDisplayName

The Dilbert widget for embedding the comic strip uses Flash, so you’ll have to tap on the link the old fashioned way to see today’s comic:

http://dilbert.com/strips/comic/2012-04-02/

written by Nick \\ tags: humor

Consumer Reports have been known in the United States as the premier, independent testing lab for consumer products. To iPhone owners they are probably best known for their role in stoking the flames of reported issues with the antenna design of the then newly launched iPhone 4.

Last week it was time for another attack on Apple’s latest product: The new iPad gets up to 13 degrees hotter than the iPad 2 when playing a game

This report had many experts scratching their heads, and it even prompted an official response from Apple.

Now it seems it may just be part of an elaborate launch promotion for their latest app: iGRill.

Inspired by earlier apps that exercised the iPhone CPU to the point where it could be used as a hand warmer, and this video showing how the iPad can be used as a great kitchen appliance, it was obvious that the latest advances in thermal engineering of the new iPad called for an app like iGRill.

Here’s how it works: Place your new iPad on a flat surface in your kitchen. Make sure that the surface is not flammable and that it can withstand prolonged exposure to the immense temperature of 116 degrees Fahrenheit. Now launch the iGRill app and turn up the dials to maximum heat. Wait a few minutes until the awesome heat animation indicates that the surface of the iPad is now exactly “13 degrees hotter”.

Bring out your raw meat, raw chicken and other foods that are dangerous to consume if they’re not thoroughly cooked. Place the food on the screen of the iPad in the indicated areas. Be careful not to layer the food items. Note that there is no need to add any cooking oil, since the oil from your fingers stored in the oleophobic coating of the screen is sufficient.

If your new iPad and your iPhone are both on the same iCloud account, then you will receive an iMessage as soon as the food is done. This way you don’t have to hang out in the kitchen for months while the food slowly turns into charqui.

Another exciting feature, which can be unlocked with a modest in-app purchase, makes use of the front facing camera. The camera will capture an image of each food item as it’s placed on the screen. The app then matches the captured image with GR’s extensive food database and provides you with instant nutritional information.

The iGRill app is not yet available in the App Store, but we understand there have been heated discussions between the developers and Apple. So look for it to appear in the What’s Hot section soon.

written by Nick \\ tags: humor

The New York Times had a great article yesterday about the outsourcing to China of all consumer electronics manufacturing in general and the specifically manufacturing of iPhones.

Woven into the article is the fascinating story of how the plastic screen of the first iPhone was replaced with the Gorilla Glass that we know and love, in just six weeks before the iPhone went on sale. No other company besides Apple would even consider pulling off such a feat. And there’s no other place in the world besides Shenzhen China where it would be possible.

written by Nick

Yesterday Apple introduced iBooks Author at an education event in New York City. Almost immediately people were up in arms: How dare Apple introduce an application for free that does not meet all of their own personal needs? And the audacity of insisting on a EULA that favors Apple’s own devices and markets. Not to mention the fact that iBooks Author only runs on Macs. Of course I would also prefer a tool that solves more of my issues related to publishing, along with unicorns and free beer. But, since I’m not footing the bill for the development of iBooks Author, my opinions on this don’t carry much weight. So let’s move on and look at what iBooks Author really is.

iBooks Author is intended to solve a very narrowly defined problem: How to easily create and publish great looking interactive eBooks for the iBookstore to be read on iPads. From what I’ve seen, it solves this problem very well.

iBooks Author is not intended to be a general purpose ePub authoring tool. This is of course disappointing. Most people don’t know that Apple already has one of the very few commercial, easy to use tools for creating ePub files in the iWork Pages application for the Mac. It’s not all that great, but Pages solves the problem of writing a book containing mostly text, adding some images and saving it as an ePub. A disappointing consequence of the introduction of iBooks Author is probably that Pages will not see many future improvements to it’s ePub capabilities.

.ibooks vs. ePub

The output from iBooks Author is like ePub but not quite. If you open up the .ibooks file (it’s a zip archive just like ePub files are) you will see the same structure as an ePub. Each page has it’s own xhtml file, and there are a couple of XML files that describe the structure of the book.

Creating an ePub reader for iOS is not terribly difficult since the individual pages or chapters are pretty standard HTML files which can be displayed in a UIWebView. I believe that iBooks v1.x in essence was built around a UIWebView. But that has changed significantly with iBooks 2.

Examining xhtml files generated by iBooks Author in more detail and you’ll find a lot of non-standard CSS: -ibooks-layout-hint:, -ibooks-list-text-indent:, -ibooks-strikethru-type:, etc. I know there are several WebKit specific CSS extensions with the prefix -webkit, but I don’t know what WebKit, and much less a UIWebView would do with these new -ibooks extensions.

But it gets worse.

When you use one of the built-in widgets you will get code like this:
<object type=”application/x-ibooks+anchored” data-anchor-ref=”danchor-gallery-0″> This code must trigger something in the iBooks 2 binary that renders the widget. It would have been nicer if iBooks Author generated standard JavaScript+CSS here instead. The native approach was probably done for performance reasons, as anyone who has tried to develop complex, interactive animations with JavaScript and CSS can attest to.

A consequence of these design decisions is that it’s no longer possible to load the xhtml files into a UIWebView and see a fully rendered page. This begs the question of how did they implement these new features in iBooks 2? I don’t see any way to just use the public APIs of a UIWebView to accomplish this. But given the debacle when iBooks was caught using a private API for adjusting the screen brightness, it seems unwise to go down that path again. Maybe they started from scratch using the WebKit open source code? They would certainly have the talent at Apple to pull that off.

So why did Apple choose proprietary extensions to ePub instead of fully conforming to the standard? We can only speculate.

• They want to lock in publishers to the iBookstore to boost the lagging number of titles.
• They want to ensure only iPads sales benefit from this free tool.
• They want full control over the format themselves.
• Time and budget constraints forced them to take the easier path.
• The current ePub standard does not provide all the functions and features they wanted to include.

I think there is some truth in all of the above, but I would put my money on the last one. See also John Gruber’s insightful analysis.

Given that the output format is closed, it would be possible for Apple to switch to a fully ePub compliant format as soon as the standards catch up. I don’t think this is very likely. But keep in mind that this is just the first version of iBooks Author.

Lack of iPhone compatibility

Curiously iBooks Author only generates ebooks for the iPad. I don’t think there are any technical reasons for excluding the iPhone and iPod touch. It’s more likely to be a content production issue. Creating the page layouts for these enhanced ebooks for the iPad is expensive enough. Forcing publishers to do the work twice to also target the iPhone, would probably be too much to ask.

For the educational market, the iPad is probably the right target. But if you are contemplating using iBooks Author to create ebooks for a wider audience, then the lack of support for iPhone and iPod touch is definitely a factor to consider.

Newsstand

One seemingly obvious application for iBooks Author is to create magazines to be distributed via Newsstand. Jason Snell of MacWorld wishes for this. The current EULA forbids content created with iBooks Author to be distributed via Newsstand (unless you give it away for free), but that is something it shouldn’t be too difficult to get an exception from Apple for, or conceivably see Apple change the EULA to include Newsstand in addition to iBookstore.

But given the architecture of iBooks 2 and the files generated by iBooks Author, it will be a challenge for third party developers to create magazine reader apps to display content generated by iBooks Author.

So should Apple create a generic magazine reader app, e.g. iNewsstand, that has similar features as iBooks, but also handles subscriptions and delivering content using the Newsstand infrastructure? That would be a bit odd to introduce now, as it would become a newsstand within the Newsstand folder. (Apple has actively discouraged third party magazine aggregators from making their apps Newsstand enabled.)

How about a sample project that magazine publishers can download and expand for their own use? This also seems unlikely as that would diminish some of the benefits Apple is achieving (deliberately or as a side effect) from the new proprietary file format.

IBooksPageViewController

An elegant solution to the problem of giving third party developers the ability to display content generated by iBooks Author would be to provide a new view controller that can read and display .ibooks files. It would be like a UIWebView on steroids. We can debate wether it should be a view or a view controller. Given the fixed page layout nature of ebooks created in iBooks Author, I think a view controller would be more appropriate.

Imagine the cool apps that can be created by developers if the creativity unleashed by the free iBooks Author tool could be harnessed in iOS apps. If Apple’s true intention is to keep the file formats proprietary and the technologies exclusive to the iOS platform, that is still achieved and further promoted with this solution.

I like this idea. I think I’ll go right now and submit a Radar for it.

written by Nick \\ tags: iBooks, iBookstore, UIWebView

This post is on a very narrow issue, but one that I spent several hours tracking down and finding a fix for. Hopefully this will save some grey hairs for a few of my loyal readers and Google searchers.

An app that we’re working on connects to an IIS server and authenticates using NTLM. For security reasons (for this particular app) NTLM is the only acceptable authentication mechanism.

Therefore, in the didReceiveAuthenticationChallenge callback method we specifically check to ensure that the authentication method is the one we’re accepting.

- (void)connection:(NSURLConnection*)connection
didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge*)challenge {
	
  if (([[[challenge protectionSpace] authenticationMethod] isEqual:authenticationMethod]) &&
    ([challenge previousFailureCount] <= kAllowedLoginFailures)) {
		
    [[challenge sender]  useCredential:[NSURLCredential 
                    credentialWithUser:user.username
                              password:user.password
                           persistence:NSURLCredentialPersistenceNone] 
            forAuthenticationChallenge:challenge];
  } else {
    [[challenge sender] cancelAuthenticationChallenge:challenge];
  }
}

This worked great until the app connected to a server over SSL. Then we experience a very strange behavior. Communication with the server worked fine the first time the app was launched. But after quitting the app and launching it a second time, all server communications failed.

After a bit of debugging and a liberal sprinkling of log statements we discovered that the server sometimes sent the authentication method NSURLAuthenticationMethodServerTrust instead of the expected NSURLAuthenticationMethodNTLM.

We spent some time digging deep into the settings for IIS. The idea of forcing IIS to only use NTLM authentication seemed promising. But in the end we were unable to find the right switch in IIS to get the behavior we desired.

So back to Xcode for a closer look at how authentication is handled. We soon came to the canAuthenticateAgainstProtectionSpace callback method. Which had this naïve implementation:

- (BOOL)connection:(NSURLConnection*)conn
canAuthenticateAgainstProtectionSpace:(NSURLProtectionSpace*)protectionSpace {
  return YES;
}

After fixing this and rejecting authentication methods we can't or don't want to handle, the method now looks like this:

- (BOOL)connection:(NSURLConnection*)conn
canAuthenticateAgainstProtectionSpace:(NSURLProtectionSpace*)protectionSpace {
  DLog(@"protectionSpace: %@", [protectionSpace authenticationMethod]);
	
  // We only know how to handle NTLM authentication.
  if([[protectionSpace authenticationMethod] isEqualToString:NSURLAuthenticationMethodNTLM])
    return YES;
	
  // Explicitly reject ServerTrust. This is occasionally sent by IIS.
  if([[protectionSpace authenticationMethod] isEqualToString:NSURLAuthenticationMethodServerTrust])
    return NO;
	
  return NO;
}

The IIS server still sends NSURLAuthenticationMethodServerTrust occasionally but when the iOS app rejects it, IIS immediately follows with a request for NSURLAuthenticationMethodNTLM. The didReceiveAuthenticationChallenge method is then called with an authentication method that it can handle. All is well again.

written by Nick \\ tags: canAuthenticateAgainstProtectionSpace, didReceiveAuthenticationChallenge, NSURLAuthenticationMethodNTLM, NSURLAuthenticationMethodServerTrust