devsugar posts

Do you believe in miracles? If you clap your hands, will Tinkerbell appear? Are you willing to submit an application developed solely in a simulator and hope that it will work on real hardware? With real customers? In a real App Store? Well, now is your chance to find out.

According to an email just sent out to devs, Apple is now accepting iPad application submissions through iTunes Connect. You can submit your application today and "receive feedback" on its "readiness for the grand opening."

Simulator-only apps developed with the iPhone SDK 3.2 Beta 5 can be submitted as of today for initial review. Upload your apps by 5pm, Saturday, March 27th, and the App review team will e-mail you with submission feedback about the readiness of your application for App Store distribution. You will also receive information about submitting your apps for final review, before the iPad ships and (for most of us) before we even own hardware.

If you're thinking about waiting: don't. Apple states that "[o]nly apps submitted for the initial review will be considered for the grand opening of the iPad App Store." An Apple spokesman further confirmed that "[W]e are looking forward to having an amazing line up of apps available when the iPad ships on April 3." The iPad App Store will launch at the same time as the iPad device.

It's March. It's the month where beer turns green, where the road repair crews start taking over the midwest of the United States, and when Apple usually announces its Worldwide Developers' Conference dates. With the hotly anticipated iPad introduction this year, more devs than ever are looking forward to seeing what WWDC will have on offer.

Will WWDC bring the iPhone OS 4.0 announcement and the hardware refresh that we've speculated about? Or will the iPhone OS family remain in the 3.x generation for the foreseeable future? (The current release for the iPhone and iPod touch are at 3.1.3. The iPad will ship with firmware 3.2.) That's the question that has a lot of devs scratching their head.

In the past two years, March has been the time when new iPhone SDKs were provided to developers, with the actual firmware released a few months later, somewhat in sync with WWDC. This year, with the iPad release due for the first week of April, the iPhone refresh seems to have been pushed out, or even to the side.

Will Apple's WWDC announcement help clarify where we stand in the iPhone lifecycle? That's hard to say. I know a lot of devs are hoping that a new beta SDK will debut sometime in April, once the iPad has been released; with the new version focusing on the iPhone, WWDC sessions would follow up on that build. It would make sense to bring the iPhone up to at least 3.2, so that firmware releases remain in sync across all iPhone OS devices; however, by Jim Dalrymple's estimation we won't see a unified firmware version for both families until the autumn.

What about iPhone OS 4.0? With the WWDC keynote being the only remaining scheduled event keynote in the Apple yearly cycle, it would make sense for Apple to use that platform to announce major a iPhone OS update, or a major Mac OS update for that matter. However, the bottom line is this: Apple keeps its secrets. We'll know when they tell us. That can make third-party planning challenging -- whether you want to schedule flights to California for WWDC, or prepare your applications for major firmware updates. We've emailed Apple for clarification on WWDC timing, and have yet to hear back.

Here's a quick run-down of past TUAW WWDC announcement posts for your reference.

	WWDC '09 Details Posted Spring is in the air, although we're in the midst of a blizzard here in the Denver area. That means one thing -- the Apple Worldwide Developer Conference (WWDC) is coming soon!Eric over at...		Apple announces WWDC 08 dates With the iPhone SDK announcement last week, some of us here at TUAW were expecting a Worldwide Developer Conference date to be announced. Thankfully, the world has been put to rights, as Apple has...
	AppleInsider: WWDC to take place June 11th - 15th Take this with a grain of sodium chloride, but AI is reporting that "people familiar with conference planning" have tipped them off to the dates of this year's World Wide Developers Conference....	Also of interest: Apple's WWDC dates announced Rumor: Moscone schedule + "corporate event" = Verizon iPhone?

Unit testing refers to a software validation methodology that allows programmers to test individual program units for correctness. It's been an ongoing question in the iPhone developer community as to whether the iPhone's view controller class is testable or not.

In response to these discussions, iPhone developer Jonah Williams has written up a view controller unit testing how-to over at the Carbon Five web blog. His write-up offers examples that show how to incorporate some best practices into your code.

Williams points out how broken NIB bindings are a common problem for iPhone OS applications. To address these issues, he regularly adds simple assertions that test that each IB outlet and action are set properly from inside his view controller class implementations. These assertions check that IBOutlet instance variables are not set to nil and that IBAction targets have been assigned, adding a layer of protection against broken bindings.

Another typical view controller issue involves responding to application memory warnings. To respond, he adds tests that ensure that each view-dependent property gets correctly released and re-created as views unload and then later reload. By building these into test methods, he can execute this behavior on demand, and ensure that the sequence will execute flawlessly in real world conditions.

Finally, Williams discusses view controller interdependencies. Often instances are tightly intertwined, with objects acting as clients for each other. For example, a simple table view controller, living within a navigation controller, might present a detail view via yet another view controller when a row is selected. That's three separate controllers to account for, when you really only want to test one at a time. Williams suggests isolating these view controllers away from their interdependencies to test each component separately and provides examples of how you can do so.

What made Williams' approach pop for me is how he carefully exposes and isolates dependencies for testing. These are features that can otherwise be hard to inspect and validate in the normal course of programming. His write-up is well worth reading through, and provides an excellent jumping off point for investigating view controller unit testing.

App Store clutter remains an ongoing issue. In addition to "business card" applications that offer little or no functionality beyond a simple web page^[1], there are lite editions, demo editions, full editions, and even in the case of Tweetie 2, completely new applications providing upgraded functionality.

Each of those applications must be registered with a unique app identifier, each one takes up a separate slot when installed on your iPhone's home screen, each application occupies a separate App Store listing, complete with its own screen shots, marketing material, reviews, and so forth. Each one must be managed by you in iTunes, where you must decide which to sync, which to keep, and so forth.

Add to the mix, the possibility that we're likely to see iPad- and iPhone-specific application releases in the near future in addition to the Universal Application solution that Apple has been heavily promoting. That's because iPad applications offer developers the opportunity to re-imagine their interfaces, adding features without the constraints of the iPhone's small screen and modal interaction limitations. An iPad app that adds significant new functionality may branch off and become yet another related app in a single application family.

After a many-hours outage, the Apple developer site is back -- and the changes are profound, at least on the Mac end of things.

On the iPhone side, users are required to update their profiles, take a rather obnoxious survey and agree to new terms [Developer credentials required for link]. Unfortunately, Apple needs to improve the default survey formatting. iPhone developer John Fricker points out, "If you go to My Profile you can take the iPhone developer 'survey' with better formatting."

But it's on the Mac side where the big news is. Apple has replaced the select and premiere memberships with a single-tiered, low-priced Mac Developer program. They write: We recently introduced a new Mac Developer Program that replaces ADC Premier, Select, and Student Memberships. If you are a current ADC member, you can continue to access your resources and benefits through the end of your membership year.

Universal apps. They're the solution for delivering your iPhone OS application to both the iPhone and the iPad and having it run natively on each without silly make-do's like pixel doubling. It's a way to ensure that your app "fits" each platform, providing art and interfaces that match the target screen. Or, as Apple puts it, "Developers can now start planning for universal applications, allowing them to take full advantage of the technologies found on iPad, iPhone, and iPod touch with a single binary."

Right now, I've got a bug up my sleeve about the whole issue. I'm not convinced that it's the right solution for a lot of apps. Just because you *can* merge an iPhone app with an iPad app, and sell one product, you shouldn't -- unless the functionality is significantly the same for both platforms.

iPhone developer Jonathan "Schwa" Wight offers a great little trick for creating pixel perfect glassy buttons: using the unofficial UIGlassButton class in the simulator to build your art. In his code paste, he shows how to build a button and render it to a PNG, which you can then save to your desktop.

It's a great little trick, and one worth adding to your development arsenal. Be aware that UIGlassButton is a private class, and one that has long since been relegated away from the official SDK development path. Although it continues to work on the Simulator, it's not for use on the iPhone itself or in App Store projects.

Continue reading on to find the code. Don't forget to substitute your own user folder into the code (in my case, "ericasadun") for Jonathan's ("schwa").

Approximately one hour after uploading his new application update to iTunes Connect, Bristol-based iPhone developer Rob Jonson of Hobbyist software got the surprise of his week: an official Apple green light. His latest update to his VLC Remote application had been approved and was ready for sale. VLC Remote allows you to control a Mac- or Windows-based VideoLAN playback client from your iPhone, basically duplicating many of the features you'd get from a standard Apple Remote.

His update wasn't complicated. "It was a simple problem," he told me over the phone this morning. "One of the buttons stopped working because of a stupid error. I missed a break in a case statement." So he uploaded his bugfix at about 11 PM local United Kingdom time.

Just before midnight, he checked his e-mail before heading off to bed. The Apple approval was sitting in his in-box. A recent update, submitted last week, had taken only a day to receive approval. "With 24 hours, I was very impressed. But one hour? I couldn't believe it. Clearly Apple has changed the game."

Update: This picture speaks a thousand words. Courtesy of Tom Harris of InsiderApps. This is a different app from Jonson's

Anyone struggling with the challenge of developing for the iPad, a platform whose hardware has not yet been released, should welcome iSimulate. For just ten bucks, you can test your applications using event inputs from a real device. Yes, you'll be working with the limited geometry of an iPhone -- fewer pixels, not the same device shape -- but you'll gain access to a much wider range of gesture and accelerometer events to help you debug and develop your apps.

Using iSimulate involves little more than compiling in a framework and running an iPhone-based application that you download from the App Store. You'll need to add -ObjC to your linker flags and include the Core Location framework. This latter is needed in order to provide simulated compass and GPS events to your app. Once run in the simulator, iSimulate will automatically find that running app and offer to link to it.

It took me only a few minutes to bring my Xcode project into iSimulate compliance and get it working with the iPhone. In use, I found the entire process of interacting with my phone to generate events on the Simulator far easier and more intuitive than I expected. I suspect I'll keep using iSimulate over the next few weeks until the iPad debuts and can comfortably recommend it to other devs.

TUAW is commonly provided with not-for-resale licenses or promo codes to permit product evaluations and reviews. For more details, see our policy page. Promo code requests are not guarantees of reviews.

TUAW's devsugar series helps introduce developers to tools and tricks that they might not yet be familiar with. Today's tip centers on signing already-compiled and already-signed applications with a new custom signature.

A while back, I posted about a way to sign already-compiled applications with your personal credentials in order to better allow developer-to-developer distribution. By re-signing an application, it allows you to install it on any of the devices you have registered to your account at Apple without having to go through the fuss and bother of normal ad-hoc distribution. In addition, it makes it easier to develop applications on a contractor's machines, to ship them to a client, and then have them signed and shipped to App Store using the client's identity.

A basic command-line solution is as follows. It calls codesign (found in /usr/bin) to sign the application, using the default keychain item that matches "iPhone Developer". It's a handy script, especially for informal beta distributions.

#! /bin/bash

export CODESIGN_ALLOCATE=/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/codesign_allocate

codesign -f -s "iPhone Developer" $1

There are, however, several problems with this approach. First, it assumes you only want to sign with development (typically "Debug build") credentials. That's not going to work if you need to re-sign for distribution. (Solution? Change iPhone Developer to iPhone Distribution). Second, it assumes you only have one developer or distribution profile in your keychain. (Solution? Change iPhone Developer, for example, to iPhone Developer: Company Name to exactly match just one keychain entry.) Third, it assumes the person doing the re-signing knows how to use a command line. For that, the solution is a little more complicated.

Recently, this topic came up on a developer e-mail list that I moderate: how do you make it easier for a non-technical client to re-sign an application, normally for distribution. As a solution, I put forth the proposal that one could embed the above shell script behavior into an AppleScript droplet. After consulting with a few colleagues, and gathering their requirements, I decided to give the project a try. I built an AppleScript application that signs any application dropped onto it.

You can find a working copy of the application at my website. App Signer iterates through any apps dropped onto it, checks to ensure whether each file (or bundle, really) ends with an ".app" extension, and then attempts to sign those files using /usr/bin/codesign.

Users can choose to sign with Developer credentials, Distribution credentials, or select Other to open a prompt and enter text for keychain disambiguation. (See the screen shot at the top of this post for an example of the disambiguation dialog.) The application displays results for each application, one at a time.

Please note the following caveats:

• I make no attempt to guarantee that the app dropped onto this utility is actually an iPhone app (rather than, say a Macintosh application).
• When working with on-device keychains, the identity used to sign the application has to match the application id set forth in the Info.plist file for the application, otherwise keychain access will fail.
• This is a free application. It is offered under the BSD license. Use it at your own risk. Credit always appreciated. The open source github repository for App Signer can be found here.
• To create the application, open the AppleScript source in Script Editor and choose File > Save As > File Format: Application.

Dear Auntie T.,

I have the best idea for an iPhone app, well, modestly speaking, ever! So how do I sell this great idea? Is there a forum for discussing how to get an idea sold? Any help you can offer will be appreciated.

Love and kissies and hugs,

Your nephew,

Mike (who isn't Max)

Read Auntie's answer below!

Are you doing production work and beta work at the same time? Need to install more than one SDK at once? If you've downloaded the 3.1.3 SDK and need to install it on the same system as the 3.2 beta SDK, you'll want to use the Xcode installer's destination chooser.

When given the option of where to install, click on the Developer folder to reveal the pop-up shown here to the right. To create a new folder/location choose "Other..." and use the standard file browser to create and select that location.

I personally use a named folder for all beta installs. My 3.2 beta is located in /Developer32 and I used the standard /Developer path for my 3.1.3 SDK update. Both SDKs coexist in peace with each other, although I did have to assign separate key macros (I'm a Quickeys addict) for normal Xcode and Interface Builder (in /Developer/Applications) and the beta versions of the same (in /Developer32/Applications for me). Having both SDKs available and separate will help you make sure you can test and code in both environments quickly and easily.

In pixel-terms, the iPad offers a much larger workspace to develop on than the iPhone but in terms of the human experience, it's not that very far away from iPhone programming. The two share an underlying operating system and a large overlap in human interaction realities. Here are just three of those overlapping iPhone development realities. Consider taking these ideas into account as you're building your new and updated applications for the iPad.

Human fingers are big. Although the iPhone has a much smaller screen than the iPad, the size and shape of the typical human finger does not change between the two devices. Do not design interaction elements for the iPad smaller than, say 40-by-40 pixels in size.

When in doubt, design larger rather than smaller. The iPad with its larger screen is more likely to be held further away during use than the iPhone, which is often raised fairly close in during use. Build your on-screen objects accordingly. With its 1024x768-pixel screen, the iPad has the room for clean, large interaction elements. Use that space to better compliment the human finger.

Attention spans are short. Like the iPhone, expect your users to approach the iPad in a sporadic netbook-style fashion. Design your applications around short interaction periods and prepare for your application to be cut off as a user stands up to grab his next Orange-Cranberry Frapaccino.

Always save your application state between sessions, as much as you possibly can. A well designed app should relaunch quickly and, upon relaunching, approximate the same task your user was performing the last time the program was run. This can demand diligence on the part of the programmer, but is worth the time investment due to the payoff in user satisfaction.

One more tip after the break!

Thanks Scott Lawrence, |Agent

The new iPad has lots of space. The screen offers 1024x768 pixels. That's way more room to work with than the iPhone gave you. And because of that room, it's time to re-think the way you designed iPhone applications. Things that worked well with the iPhone's limited space -- things that were meant to expand the device's virtual world beyond the screen's tiny reality -- are the things that you need to readdress and confront. Why keep using visual tricks when you can expand into real pixel space?

Take the traditional UINavigationController class for example. Its entire role on the iPhone is to provide the same kind of tree view used in Mac OS X's Finder windows (View > As Columns, Command-3). The animations as you select and push view controllers and the back button are both there because you can't reasonably see an entire tree structure at once, in columns, the way you do on a Mac.

TUAW's devsugar series helps introduce developers to tools and tricks that they might not yet be familiar with. Today's tip centers on table-level badging and how to simply and easily add badged cells to your iPhone Xcode projects.

Badges are a natural partner for table view cells. When working with one-to-many data like mailboxes with letters, or RSS feeds with articles, they indicate how many items (or new items) branch off of each available choice. The standard Apple SDK does not offer badge functionality.

iPhone Developer Tim Grant Davies to the rescue. He has built an open source github repository for his TDBadgedCell project. Distributed under the Creative Commons Public License, this class allows you to add numbers to the right of each table view cell, and choosing a background color for each number.

Each badge is drawn in a custom view using CoreGraphics. This means the class does not rely on extra images stored in memory, and the badges are drawn quickly on demand. You can set color properties for each badge, indicating hues for both the normal and highlighted states.