The App Business Blog

Developing apps for the iPad using the simulator is great. Assuming you have a decent Mac development environment the simulator is super fast and has seemingly unlimited amounts of memory. What more could you ask for?

Actually it would be much better if the simulator environment was closer to the device when it comes to speed and memory limitations. Especially memory.

Apple has never published how much RAM memory there is in any of the iPhone or iPod Touch devices in the past. And of course no such details are available for the iPad. You might assume that for a larger device there would be more memory available. Guess again.

The gorgeous 768 x 1024 display is begging to be filled with full screen images. Keep in mind that an image of that size will take up approximately 3 MB of precious memory. Keep 10-15 of them around in memory and you’re half-way to getting your app terminated because of memory usage.

Today is the last day to submit iPad apps for consideration for the new iPad App Store. I predict that we’ll see quite a few apps crashing on opening day because developers have not been able to test their app’s memory usage on an actual device with real world memory limitations.

written by Nick \\ tags: iPad

If your iPhone app needs to store or access a lot of data locally you should take a look at Core Data. It’s not a panacea, but I find that it’s particularly useful when you need to search a lot of data that may result in a very long list to present in a table view. For this use case the NSFetchedResultsController is your friend. It handles many of the nasty issues of memory management, ensuring that you have enough data in memory to populate the visible portion of the table view instead of loading the entire result set into memory at once.

Your code to perform a fetch using NSFetchedResultsController may look something like this:

NSPredicate *predicate =[NSPredicate predicateWithFormat:@"name contains[c] %@", searchText];
[self.fetchedResultsController.fetchRequest setPredicate:predicate];
NSError *error = nil;
[self.fetchedResultsController performFetch:&error];

If you’re using a UISearchDisplayController you may be tempted to call this code each time the user enters a new character in the search field. There may be obvious performance reasons why you cannot want to do this. If it takes a few seconds to perform each fetch after each character then it will make for very slow data entry that will frustrate the user.

But there’s a more subtle reason why this is a bad idea, which I recently ran into.

NSFetchedResultsController optionally caches results and the cache content may get out of sync if you just change the NSPredicate like the code above does. One way to get around this is to delete the cache before you set the new predicate:

[NSFetchedResultsController deleteCacheWithName:nil];
[self.fetchedResultsController.fetchRequest setPredicate:predicate];

I’ve seen the first code section in many Core Data code examples, but I’ve never seen anyone mention the need to delete the cache before you perform another fetch with a different predicate. Now it turns out that you don’t have to do this in the current iPhone SDK, because it “just happens to work” anyway. But this behavior may, or may not, change in an upcoming NDA-covered SDK release. Consider this an advance warning.

written by Nick \\ tags: Core Data, NSFetchedResultsController, NSPredicate, UISearchDisplayController

As consultants and developers for hire we often don’t get to put our name in a product we work on. Sometimes we are not even allowed to reference the client or even mention that we were even part of the development effort. That’s part of the job description, and I’m ok with that.

What’s not ok is when people try to take credit for work they didn’t do.

Recently I’ve been contacted by several companies trying to sell their iPhone development services to me. I’m not interested in outsourcing the core of my business to another company, but I sometimes play along just to hear their pitch. One of the first things I ask for is references. What apps, available on the App Store, have you developed?

Here’s how the conversation went with the Business Development Manager at a company called Backfire Solutions:

– In the document with references that Alexa Shame sent me, you list an app called Curious George. Can you tell me what your company’s role was on this project?
– Full lifecycle development.
– Very interesting. What would you say if I told you that a colleague of mine developed this app?
– That is very strange because we developed that app.
– I’m looking at the source code for the app on my computer screen right now and I see my colleague’s name in the headers, but not yours.
– Uhmm. Please hold a minute, let me talk to my project manager. [Typing furiously, presumably in an IM window.] Actually, we just did some image work for that app.
– So not really any full lifecycle development?
– No. And actually we’re not really allowed to reference this client. Please do not talk to them about this. Is it ok if we sign an NDA now?
– Let me get this straight: You claim to have developed apps that you didn’t, you provide client references that are not really references, and you share client confidential information when soliciting new business. Did I miss anything?
– Uhmm.
– Good bye.

As a developer I get really upset when people claim that they have written code that they clearly had nothing to do with. But I’m not a spiteful person so I was going to let this go. That was until Backfire Solutions called us a second time! This time it was a colleague of mine that took the call, and they launched into a similar sales pitch. This is how you end up on the iPhone Developer Wall of Shame.

The next story comes courtesy of Rutabaga Makeincident at As*h**e Designs. He claims his 11 programmers are “are sort of expert in IPhone”. When asked for references he sent over a list of iPhone apps that included Twitterific.

– Twitterific? Really?!
– No reply.

Repeated attempts to clarify their role in the development of Twitterific were met with silence. I assume that they realized that their bluff had been called and they were busy working their next lead — one that hopefully would not question their references.

How do these companies think they can get away with such blatant lies? My guess is that they don’t realize how small and tight the iPhone development community in the U.S. is. I’m probably not more than two or three degrees of separation away from any professional iPhone developer based in this country. So if I don’t directly know the developer of an app, chances are that I know somebody who does. Within a great community like this, it’s very easy to verify who actually developed an app.

I know I’m not alone in getting these solicitations. Please share your stories in the comments.

• Developers stealing from developers: an App Store tale
• iPhone Appmakers Caught Taking Credit For Apps They Didn’t Build
• Some iPhone Coders Padding Resumés With Lies

Update 11/22/2010: Mr. Rutabaga Makeincident has contacted me with a “Concern” about what I wrote about him and his company in this blog post. This of course made me concerned too, and I offered to immediately correct anything that was factually incorrect in what I have written. After further conversation it turns out that there wasn’t really anything wrong with what I wrote, he just wanted his name removed from this web page.

Mr. Rutabaga furthermore said that his prior fraudulent claims about his company’s credentials was a mistake, and he profusely apologized. I think we can all agree that lying to potential customers is a big mistake, and I offered to publish his apology. From there the conversation degenerated into threats, culminating with “YOU HAVE TO PAY US FOR THIS 1000 USD FOR SPOIL REPUTATION”. It wasn’t sent with letters cut out from a newspaper, but I guess this is as close as you can get to a ransom note via email.

To be clear: I have no experience with, or knowledge of the quality of the work performed by the companies mentioned here, and I make no such claims. (In fact there are comments below from apparent clients who have had success in working with with them.) I have merely reported the sales tactics these companies use with potential new clients, based on actual conversations that these companies initiated with me and my company.

Update 11/23/2010: I have been advised that giving in to extortionists demands is actually a good thing. My point with this post was to expose shady business practices in our industry, not necessarily hanging out the bad guys to rot. Therefore the names above have been altered to protect the not so innocent.

written by Nick

Even though we just received a foot of fresh powder snow, conference season is already here. Are there any conferences you should/must attend as an iPhone developer? The answer will of course depend on your personal situation. I don’t like to travel much, but I really enjoy meeting fellow developers and to put faces to blog signatures and Twitter handles. So here are some upcoming conferences where you might meet me.

Mobile World Congress

This conference took place in Barcelona February 15-18. We had one of our developers speaking there, and at least one of our clients was there too. This is mainly a business conference and the focus is not on the iPhone. Apple is not one of the exhibitors. Microsoft was there in big force showing off an early build of Windows Phone 7 Series (nice name!). Global telecom companies announced a planned Super App Store where the unstated goal is to take away some of the power from Apple. (Good luck with that.)

NSConference

Traditionally a Mac developer’s conference with some of the world’s best Mac developers as speakers. This year they added a day devoted to iPhone programming. The 2010 conference has already taken place and Jeff LaMarche has a nice write-up.

CTIA Wireless – March 23-25, 2010 – Las Vegas, NV

This is the U.S. counterpart to Mobile World Congress. It takes place in Las Vegas every year. Like MWC it’s primarily a business conference, but with more focus on the U.S. market.

Don’t expect to learn any new Cocoa Touch skills here. But if you need a tax deductible reason to go to Vegas, this might fit the bill. Or if you just want to speak your mind to the AT&T executives Ralph de la Vega and Randall Stephenson, they’ll be there.

360|iDev – April 11-14, 2010 – San Jose, CA

I was a speaker at 360|iDev in Denver last summer and I really enjoyed the conference. It’s a small and intimate conference where you really get a chance to interact with both speakers and attendees. Both attendees and speakers were top-notch, and I learned a lot as well as made valuable connections.

The early bird pricing is already sold out. But the regular cost for three jam-packed days of sessions is still very reasonable.

Unfortunately I will probably not be able to attend this conference. I’ve got a few iPad projects that need to be wrapped up right around that time.

Voices That Matter – iPhone Developer’s Conference – April 24-25 – Seattle, WA

I have not been to this conference before, but the speaker lineup looks really good. The first day has a whole track devoted to UI design. This is something that I’ve been deeply involved in recently when porting iPhone apps to the iPad. (“Porting” is probably the wrong word here. “Redesigning the user experience from scratch” is more accurate.) On the second day there are several sessions that I plan to attend: Cocoa Design Patterns, Memory Management, Performance Tuning and Effective Networking. You can’t learn enough about these topics, and the opportunity to learn from some of the best in the business can’t be passed up.

Early bird pricing is available through March 12. And if you use the discount code “PHBLOGS” you’ll save an additional $100.

Full disclosure: I’ve been offered a complimentary ticket to the conference. If my schedule does not allow me to go, I will give the ticket away to a lucky reader here on the blog.

written by Nick \\ tags: conference

In a previous post I presented a framework for creating a data entry screen. That code focused mainly on UITextFields and allowed the user to move to the next field by tapping the Return key on the keyboard.

What if you have one or more UITextViews on your data entry screen because you want the user to be able to enter multiple lines of text? Well the UITextView handles the Return key internally and adds a new line to the text being entered, just like you would expect when you’re writing text in a text editor. And there is no equivalent of textFieldShouldReturn for UITextView.

If you don’t care about newlines in the entered text and you just want to exit the field when the Return key is tapped, then add the following method to the UITextViewDelegate:

- (BOOL)textView:(UITextView *)textView shouldChangeTextInRange:(NSRange)range replacementText:(NSString *)text {
  BOOL shouldChangeText = YES;
	
  if ([text isEqualToString:@"\n"]) {
    // Find the next entry field  
    BOOL isLastField = YES;
    for (UIView *view in [self entryFields]) {  
      if (view.tag == (textView.tag + 1)) {  
        [view becomeFirstResponder];  
        isLastField = NO;
        break;  
      }  
    }  
    if (isLastField) {
      [textView resignFirstResponder];
    }
	
    shouldChangeText = NO;
  }
	
  return shouldChangeText;
} 

The shouldChangeTextInRange method is called after each keystroke is received by the UITextView, but before it’s shown on screen. If the text is a “\n” character (the Return key) then we either set first responder to the next field, or hide the keyboard in the case that this is the last field. (The entryFields method is explained in the previous post.) Return NO if a return character was detected since we don’t want the new line to show up in the UITextView, otherwise return YES and the text will be processed and shown in the UITextView as normal.

written by Nick \\ tags: UITextField, UITextView

It is a good practice to set a variable to nil after you release it:

[myVariable release], myVariable = nil;

If you don’t do this then you may experience bugs that are difficult to track down. Say that you inadvertently refer to myVariable after it has been released. Sometimes the memory pointed to by myVariable still has the old content of your object, and your app will run fine. Sometimes that memory location has been overwritten with something else, and you’ll get an unpredictable result.

One nice characteristic of Objective-C is that you can send messages to nil objects without error. (Unlike Java, for example, where NullPointerException is probably the most common exception thrown.) So if you have set myVaraible to nil and you then try to send a message to it with [myVariable something] then it will not fail. Nothing will happen of course, but at lest nothing will happen every time, which is much easier to track down than indeterministic behavior.

One might argue that sending a message to a nil object is the result of faulty code. Your code should know if an object is valid or nil. But here’s a simple counter-example:
If your class has properties with a retain declaration, then you should release those properties in the dealloc method. In many cases setting the value of a property to nil is perfectly valid. And thus sending release to that nil property in dealloc should be ok.

Keep in mind that the above conventions apply to Objective-C. If you’re calling Core Foundation functions you need to be more careful when dealing with nil.

For example, if you call the following function with a nil parameter, it will fail:

CFRelease(contactFirstName);

Before calling CFRelease you need to check the parameter value like this:

if (contactFirstName) CFRelease(contactFirstName);

written by Nick \\ tags: CFRelease, release, retain

Today the Zinio app rocketed up to the #1 slot in the News category for free apps. It is ranked ahead of NYTimes, Yahoo!, NPR and USA Today. Pretty cool.

The app allows you to read magazines on your iPhone. The magazine pages are rendered just like they appear in the dead tree version of the magazine, or you can select a text mode where you lose the overall layout of the page, but the text fills the screen and is much easier to read.

If you live outside the United States then physical magazine subscriptions from the U.S. are typically very expensive due to the postage. (You used to be able to select surface mail, which was much cheaper. But then it took three months for the magazine to arrive. I always wondered what kind of surface vessel took 3 months to cross the Atlantic to Europe. I guess those ships have been retired because surface mail is no longer an option.) With a digital subscription from Zino you get the bits immediately and for a much more reasonable price. And you can read the magazines on your iPhone, another mobile device, or on your computer.

It’s a really nice app. Check it out.

written by Nick

After watching the highly anticipated presentation of Apple’s latest creation, here are my initial impressions from a developer’s point of view. Apologies in advance for the very long post and the somewhat random order of information. My mind is in hyperdrive thinking about all the new possibilities.

The iPad and the iPhone are very different

The iPad is not portable in the same way that the iPhone and iPod Touch is. You will not pull out the iPad from your back pocket and interact with a 2-minute app while you’re waiting in line at Starbucks. When thinking about apps for the iPad you have to think about how this device will be used.

The iPad is the new home computer. I see it being shared among members of a family to surf the web, consume media or look up information while watching a show. Or even interacting with the show in real-time. You don’t walk to another room to “use the computer”; it’s always laying around in your house, ready to be picked up and used where you are. Of course much of this applies to the iPhone as well. But one big difference is that the iPhone is very personal in that the screen is too small to share. The iPad screen seems big enough that you can have shared experiences around it. How about sitting around an iPad and playing a board game, where the computer takes care of the boring parts like keeping score and enforcing the rules?

I can also see a big role for the iPad in schools and educational settings. Schools that today have a computer in the classroom often have it shoved off in a corner or a special computer area, where students go to do “computer tasks”. An iPad can be integrated into the classroom and with the teacher-student interactions in a much more natural way. Given Apple’s long history in the educational market, I’m a bit surprised there was no mention of this. Maybe they’ll do a special school related event later with iTextbook and some other features targeted directly at the educational market.

As an app developer you need to realize that the iPad is not an iPhone. The same apps, user scenarios and UI designs that make sense on the iPhone, probably don’t translate well to the iPad. While there is sure to be an initial flood of iPhone apps “adapted” for the iPad, I think that in the long run the really successful iPad apps will be those that really take advantage of the unique characteristics of this device.

App development

Apple is really encouraging developers to create universal binaries that will run on all devices and that adapt to the current run-time environment. This has some interesting consequences. On the positive side for developers is that you only have to maintain one build. For customers this approach is also a good thing because they don’t have to manage different versions of the same app for their array of devices. (You know people will want an iPad in addition to their iPhone.) The economic drawback of this for us developers is that customers who have already purchased your iPhone app will get the iPad upgrade for free.

The bar for apps is going to be much higher on the iPad than the iPhone/iPod Touch. A silly app that just does one simple thing might be a fun gag on a device that you can pull out of your pocket and show your friends. But it’s going to fall flat on the larger capabilities of the iPad. I think people will expect more. However that doesn’t mean that app developers won’t try.

Relying on pixel doubling is not going to cut it. You need to adapt your apps to make use of the larger screen and the new SDK features. This may lead to a natural segregation of apps in the App Store: those apps where the developers actively invest in upgrades, and those that are more or less abandoned. Personally I think that would be a good thing.

Also, the bar for app developers is going to be much higher on the iPad. The learning curve for getting into iPhone development is not that steep. And if you don’t want to learn Objective-C and Cocoa Touch, then you can outsource development for a reasonable cost. Creating an app that works well on both the iPad and the iPhone is a whole new level. This requires that you have given separation of concerns some serious thought, you have a solid model-view-controller design, etc. Of course you can ignore this advice and forge ahead anyway. But given the conditional coding required to adapt to the two device classes, you are very likely to end up with a big pile of spaghetti code.

The new SDK 3.2 comes with a new NDA, so I can’t talk about any new features. But at a first glance there is a lot of new stuff to learn. It’s going to be an intense 60 days to master this new SDK.

Hardware

The iPad screen resolution is 1024 x 768. This is a 4:3 aspect ratio, instead of the 3:2 ratio of the iPhone and 16:9 for HDTV sets. So when you play HD content in landscape mode you’ll get black bars above and below the video. This is something to keep in mind when you create full screen video content for the iPad. The new SDK seems to support video playback that does not take over the entire screen, (finally!), so another option could be to play videos in portrait mode at 768 x 432 (=16:9) and leave the bottom half of the screen for other content. I’m guessing that the reason for the iPad screen size is that a more elongated device would feel awkward in your hands.

The lack of a camera is disappointing. The focus of the iPad seems to be on media consumption. And there’s plenty of new territory to explore here to keep us busy for quite some time. I wouldn’t be surprised if Apple included a camera in a future model. That would make the iPad a real communication and collaboration device. But then again, maybe they’re reserving that for the iPhone. Remember the fuss around the “missing” camera in the latest generation iPod Touch.

The Apple A4 processor is a big deal. Reports from people who got to test the iPad after the presentation say that the iPad is blazing fast. How could you even consider writing a suite of productivity apps for the device if it didn’t have the necessary horsepower. This bodes really well for app developers. How many times have you been hamstrung by the lack of CPU power in the iPhone? Now whole new horizons open up. And for the 4th generation iPhone coming later in the year, would you be surprised if it was powered by the A4 processor (or a close sibling)?

And since Apple designed the A4, they own it. How many other mobile device manufacturers have their own chip design company in-house? How are they going to compete? The iPhone showed that it’s all about the software. After almost 3 years competitors have yet to achieve the same usability and supreme user experience as the iPhone. Now add in a super-blazing-fast CPU (that nobody else can get their hands on) and the type of applications you can create on Apple’s devices just took another huge leap forward.

Content

By not including Flash on the iPad (no surprise in that) Apple has put another nail in the coffin of proprietary web technologies. If the iPad is the new home entertainment complement that sits on a kitchen or coffee table, people will avoid web sites that rely on Flash when they search the web for entertainment or information related to the show they’re watching. Before, you could maybe get away with a web site that did not support mobile devices. But with iPad media consumption devices that number in the millions that is no longer an option.

I’ve spent a lot of time building ebook and comic book readers for clients. So I can speak with some authority when I say that Apple has spent a lot of time and money building iBook. It is by far the best presentation of traditional books on an electronic device that I’ve seen. Kindle and Nook look very pale (literally) in comparison. I consider this to be state of the art for Book 1.5. The next step is to take books to another level: Book 2.0. Now that we have the hardware device, it is time to really innovate.

There was no mention of DRM for ebooks, but I assume that Apple will add an additional layer of Fairplay in the EPUB files that you purchase from the iBookstore (as allowed by the EPUB specification). DRM is a huge concern for people who buy a lot of books. Traditional books are compatible with almost all readers (=humans). But when you buy DRM locked ebooks for your Kindle, Nook or Sony device, you are tied to that vendor forever for reading your ebooks. Apple actually has a leg up in this race because there is a Kindle app for the iPhone. So if you have purchased Kindle ebooks in the past you can read them on your iPad. It will be interesting to see if Amazon will create an iPad version of their reader. My guess is that they will. In the long run it has to be more attractive for Amazon to deliver digital content vs. being in the hardware business competing with Apple and Sony.

I’m a little bit surprised that Apple just focused on traditional books. No mention of magazines, newspapers or textbooks. If the NY Times demo was any indication, then Apple will leave this area to individual publishers. That’s good for us developers since we get to build apps for each one.

The new gold rush

The work Apple has done with creating iWork for the iPad is nothing short of amazing. It’s hard to tell how useful productivity apps will be on a tablet until you get your hands on a device for a longer period of time. But I’m disappointed in the price level and the expectations Apple sets by “giving away” the iWork apps for $9.99 each. That means we remain stuck in dollar-app mode. (I’m convinced that Apple really likes dollar-app pricing. More on that in a future blog post.)

At $499 this is a mass market device. Apple will sell a lot of these devices. Dedicated ebook readers like the Kindle and the Nook will have a tough time to justify their existence. Kindle recently announced a SDK for their device, and Nook is built on Android so there’s a theoretical possibility that they’ll come out with and SDK too. Meanwhile Apple has over 100k developers with current skills and who are just itching to dig in and build new apps for this device.

I fully agree with Scott Forstall: This is going to be another app developer gold rush. It’s going to be fun!

written by Nick \\ tags: iPad

We all know about the feature to register a custom URL scheme in Info.plist so that when Safari tries to open myapp://some?parameters, your app will be launched. This is very useful, but has it’s clear limitations.

Today I downloaded Apple’s new MobileMe Gallery app. At one point the app asked me if I wanted to always open MobileMe galleries in the app, instead of showing the web version. When I said “sure”, the app launched Safari which greeted me with a page that exclaimed: “Safari is now configured to use the MobileMe Gallery app.”

The result of this magic trick is that now when I go to a URL like this: http://gallery.me.com/something/000000, Safari launches the MobileMe Gallery app.

This is different from the custom URL scheme registration we all know and love:

• A new URL scheme was not registered, it uses http:
• Not all URLs starting with http: were taken over, just those associated with MobileMe galleries.
• The registration was done dynamically.
• I had a say in if I wanted this to happen or not.
• It seems to rely on some undocumented feature in Mobile Safari.

Why would this be useful in your own apps?

• On a web page you can create a link that will launch your app on the device if it has been installed. If the app is not installed you can display a web page that entices the user to purchase the app from the App Store.
• Say you have a news reader app and you share a link to a news story with a friend via email. If your friend also has the app installed then the news story can display nicely in the app. If not, then Safari will be launched and your friend will see the web version of the news story.

With custom URL schemes both of the above scenarios would require two different links and force the user to select the right one based on their situation. Tap the wrong link and you’ll get an error message. Not pretty.

Apple, can you please document and expose this functionality to us mere mortals?
Update: Turns out that this feature does not rely on any private API:s. Read Brian’s comment below to learn how it’s done.

written by Nick \\ tags: Safari

All so called analysts should be required to follow up on their predictions and show to the world how accurate they were. Since I don’t make a living as an analyst, I’m happy to give you my scorecard for my 2009 predictions.

Push API

The Push API was indeed introduced in 2009. This was an easy prediction.

MobileMe API

I still think it would make sense for Apple to lock in users closer to the iPhone/Apple/MobileMe world by providing a MobileMe API for the iPhone. But nothing close to this was revealed in 2009. A clearly missed prediction.

More APIs

We definitely saw new APIs for the iPhone in 2009, including video recording and iTunes music access. We would all have liked to see more, specifically more access to the phone part of the iPhone, but I’m still going to claim this as a win.

No Major Hardware Releases

The new iPhone and iPod Touch releases were exactly as I described them: incremental improvements.

Better App Store

Apple did introduce keywords for the App Store as well as one new top list that isn’t “completely tilted towards $0.99 apps”. But I wouldn’t call the organization of the App Store “vastly improved”. I’ll claim half a point for this one.

More App Store Commerce

“Apple will introduce more commerce options for the App Store, e.g. subscriptions and separate billing for content.” I think I hit the bulls-eye on this one! Keep in mind that I made this prediction before In App Purchase was announced even to developers under NDA.

No Trials

Time limited trials were not introduced in 2009. With In App Purchase for free apps I think we got a bit closer to trials, but that also came with other headaches. I think most developers would agree that we don’t yet have a good system for creating trials for iPhone apps.

Summary

A total score of 5.5 out of 7. Not too bad. Maybe I should make a living as an analyst. 🙂
Stay tuned for my 2010 predictions coming next week. In the meantime, have a safe and Happy New Year!

written by Nick \\ tags: predictions