iApps Development Blog

iPhone/iPad DevCon

Sun, 11 Jul 2010 13:27:05 -0700

I’ll be presenting two courses at iPhone/iPad DevCon, a new developer conference for the iOS platform being held in San Diego from September 27-29, 2010:

• An all-day workshop titled From JavaScript to iPhone SDK Programming. This course will guide current Web app developers to make the transition to iPhone SDK programming in Objective-C with Xcode. I made the switch myself, so I’ll show you how to do it, too.
• A 75-minute class titled Dynamic App Data Updates via NSURLConnection. I’ll show you a technique I use to ship periodic data updates to my apps in a bandwidth-efficient manner. This includes special tips for integrating this feature into iOS 4 Fast App Switching.

Register before July 30, 2010 to qualify for early registration discounts. Save an extra $100 on a full conference pass when you use the GOODMAN discount code.

The conference catalog has an impressive lineup of workshops and classes. I’m looking forward to giving my courses and sitting in on lots of other sessions, including a keynote talk by Aaron Hillegass. Click the image at the right to visit the iPhone/iPad DevCon web site for the full conference schedule and additional details.

See you in San Diego!

iPhone 4 Screenshots

Fri, 25 Jun 2010 09:14:01 -0700

Here are some quick numbers on the emailed image sizes of iPhone 4 screenshots:

Full size: 640 x 960
Medium size: 426 x 640
Small size: 213 x 320

Just as we developers see in the iPhone 4 simulator at full size, full-size screenshots really reveal the comparative low quality of app icons and other images that have not been optimally-sized for the retina display. It doesn’t take long to spot the non-optimized app icons in the display itself with the naked eye — they really look fuzzy.

The Double-Edged Sword of Control

Fri, 9 Apr 2010 11:49:43 -0700

Many iPhone OS developers have long complained about the high level of control that Apple exerts over so many aspects of their development lives. Being limited to public APIs (when so many goodies sit behind closed doors), having to wade through a less-than-transparent app approval process, NDAs, and having only one Apple-controlled distribution point for revenue-generating apps — all of these issues have filled many a blog rant since the first iPhone SDK became available.

Individual experiences of some developers get lots of publicity from time to time. Some of the complaints were justified, IMHO, while some seemed to me to be little more than petulance, railing against The Fruit.

Apple’s control issues became too much for a real friend of the iPhone developer, Dan Grigsby. He has been an iPhone programming trainer, podcaster, and insightful blogger devoted to the iPhone OS developer community. But today he announced in his Mobile Orchard blog (in a posting whose permalink is ominously named “goodbye”) that he is heading for the hills, leaving behind his entire iPhone professional life.

Dan’s main issue involves what for him is an intolerable level of control that Apple imposes on a developer. He states that he has a 100% record of running “afoul of Apple’s policies” when he submitted apps for the App Store. That’s gotta hurt time after time after time. Apparently the final straw came with the beta release of the iPhone OS 4.0 SDK yesterday. New prohibitions on using development systems that bridge non-Objective-C sources for use in Xcode compilation drove him over the edge. Dan’s final plea: Apple should “provide unrestricted, frictionless, off-store distribution a la Android.”

From another corner of the Internet on the same day, I learned that scads of Windows Mobile users have had their phones infected with malware that dials a few international telephone numbers without the user’s permission (or knowledge unless they happen to hear it happening). It took a few days to track down how this happened, but the common denominator among affected users was that they had downloaded a free pirated version of an otherwise paid game application. The pirated version had been modified so that even just the installation of the app (without even launching it once) caused the auto-dialing menace to be installed deeply within the phone’s file system and run (waiting a few days after installation to try to distance itself from the app download). More details are available here.

That, unfortunately, is what can happen when there is no app distribution gatekeeper for a smart phone. Something similar has already happened to the jailbroken iPhone community.

So, that’s the balancing act the iPhone developer and user communities have to perform. Is the service that Apple provides to protect users (especially the hoards of unsuspecting users out there) from Bad Guys worth ceding so much development control?

My own belief is that the iPhone OS platform benefits overall from this level of control. If the controls were too onerous, would we have 185,000 apps in the store? Wouldn’t developers have gotten on the first shuttle outta here? It’s not just a case of developers “selling out” to the power of Apple — the vast majority of paid apps don’t really pay for the time and effort that went into their development. Aside from the occasional loud chest thumping from a denied developer, how many really have significant problems getting their apps approved? From my own experience having published three apps in the App Store, the closest I ever came to running afoul of Apple was with a sentence in one of my app descriptions that referenced jailbroken phones. I knew I was poking the bear through the bars when I added the sentence in the first place, and it actually stayed in my App Store description for a couple of months before Apple called me (yes, on the phone) to remove the line before it would approve the latest app update.

Some hard-core programmers out there may look upon me as a patsy or drinker of the Kool-Aid. Perhaps my present attitude has been imprinted through years of scripting in fairly restrictive environments, where I did the best I could within the limits. Whatever. In the meantime, I get to work these days on apps and ideas for devices whose designs are nothing short of transformative.

iPad and App Design

Tue, 30 Mar 2010 09:25:55 -0700

As my iPad wings its way to me, I’ve been watching various iPad app previews floating around the web. Many of the apps look artistically gorgeous. And that leads me back to a combined sigh and rant about Apple’s tradition of rich graphics environments and the bearing on independent developers. Developers who are better at writing code than drawing art can find themselves overwhelmed by the tons of eye-sizzling applications that justifiably raise users’ expectations of what an app on that platform should look like. This is something with which I (someone who can’t draw a straight line with the Shift key down) have wrestled since the HyperCard days. That’s 1987 for you young ’uns.

If you are an independent developer without innate artistic talent, about the only way you’ll get a graphically stunning app is to: a) contract out your art via your deep pockets; or b) be sleeping with a designer (no prejudgements here about gender roles or orientations).

I was lucky back in the HyperCard days that my commercial releases (anyone remember Focal Point and Business Class?) were published by a major software publisher. There were enough funds that I could hire a real designer to create professional-looking user interface elements (well, for the day, and in a bit-mapped monochrome world).

Years later, when I wrote a book on authoring Dashboard widgets (Mac), the design thing hit me squarely in the face. There was no budget for sample widget graphics, yet the widgets that Apple provided were really good looking. Anything I could produce would look terrible by comparison. And they did.

Things aren’t quite so bad on the iPhone/iPod touch small screens. For certain types of apps, the iPhone SDK provides enough of a head start for things like tables and transitions to allow an app to be at least “good enough” to look professional. Many of Apple’s own built-in apps used the simple native UI pieces without much original art embellishment. It was possible to generate an app that looked at least as good as an Apple app without having earned an MFA degree. Certainly, third-party apps that went the extra mile or two to create eye-popping original art and UI elements were frequently rewarded with high marks and sales.

The iPad, however, presents an entirely different canvas — one that is so large that it screams to be filled with high-quality art, even if only around the edges. Apple is doing its best to raise the standard with its built-in apps. It’s also attracting developers — such as major magazine publishers — who have enormous graphics resources at their disposal, and who will exploit those resources to make their apps so beautiful that they’ll find their way into iPad TV ads.

All that high-quality design will be great for the platform and for users. I can’t wait. But for artistically-challenged, short-pocketed, non-designer-bed-mated developers, the bar is now raised pretty high.

iPad Development in the Blind

Fri, 29 Jan 2010 10:56:32 -0800

So now we (as in iPhone developers) have all downloaded the Beta SDK, pored over the documentation, and even tried some things in the iPad Simulator. We’re gonna huff and puff, lose sleep, and code our fingers to the bone to be the first on the block with our iPad apps when that part of the App Store opens. But as a developer whose products tend to rely on Cocoa Touch user interface elements (as opposed to full-screen games), a big part of my developer’s brain suffers what might be a near-fatal gap: I haven’t had an iPad in my hands to experience even the basic apps and their user interfaces.

I can watch video of Steve tapping and pinching and twisting an iPad from the comfy stage leather chair, but he’s the only one getting the true experience of this new style of semi-recumbent computing. I can read about the 10 minutes or so that some of the media folks got to spend with the device at the unveiling, but I’m not really getting the true sense of how users will get to know standard UI element behaviors from their exposure to the built-in apps. And, as we iPhone developers are well aware, user experience on a simulator (and its skimpy selection of built-in apps) is a far cry from the real thing in your hands.

There’s something about actually using a device that connects user interface neurons in an app developer’s mind. Perhaps it comes from years of trying to get into my readers’ minds while writing an article or book, but I like to do the same when I develop software. Users will have certain expectations from their exposure to the built-in apps. I’d really, really like to know what those expectations are by twirling one of those gadgets in my hot little hands. We developers can imagine all we want — and some of us may accidentally go a good job of it — but there is no substitute for executing and fine-tuning an app on an actual device.