Phone and Laptop Prep

Earlier this week, I changed my phone from syncing with my desktop to syncing with the laptop. Last year I had an older laptop without much room on it for my music, so the iPhone was pretty much read-only during that time. Now I’ll be able to update any new podcasts as well as clear out those I’ve managed to listen to.

As long as I was losing all my application data by linking to a new library (I really wish there were a better transition available for that) I decided to finally bite the bullet and install the 3.0 OS. Beta 5 combined with a 1st Gen iPhone caused me quite a bit of grief to install, but I finally got it going and have been using it since.

I’ve trimmed my music playlist on the phone to make room for more videos to watch while traveling without having to pull out the laptop. My paper book for the week will be Cordwainer Smith’s “When the People Fell” which I’m already partway into, and I have Marcus Zarra’s “Core Data” epub in Stanza on my phone.

I’m somewhat paranoid of losing my phone in general, and the idea of leaving it behind in a swarm of almost identical phones at the conference only amplifies that fear. My normal desktop photo is my wife and daughter, but in a room of people who have just met me–and have never met my family–that won’t help. To improve chances of recovery, I have changed my desktop to my business card. It doesn’t fit perfectly, and I haven’t had the time to rearrange the graphics, but my name and email address are legible for anyone who might find my phone.

External Hard Drive

I installed the latest Snow Leopard developer release onto a portable drive, a Maxtor OneTouch Mini I’d bought a while ago. I haven’t been actively developing against Snow Leopard, so if/when we receive a new dev release at the conference, I will feel free to install over it.

Tip: If you are going to bring an external drive to run dev releases, reformat the drive in advance to use GUID Partition Table or it won’t boot your Intel Mac. That’s a really annoying thing to discover after you’ve gone through the OS install process.

Power

Hotel room outlets are a crap shoot. When you actually find outlets you can reach, they’re usually mostly occupied by appliances already. I always bring along my Monster Outlets-to-Go mini power strip. This thing is just one of those brilliant simple ideas, executed well.

During sessions, I don’t know that I’ll need much power. I’ve found that when it comes to note-taking, I’m more of a paper person than a laptop person. I’m not to the point of buying Moleskine notebooks, but I find writing easier and quicker to edit and annotate than a keyboard, and I focus more on the presentation itself. A paper notebook is also much less awkward to carry around and balance on your lap.

I am planning to carry a power adapter for my phone, though. Like Brent’s suggestion to stay hydrated, phone battery tends to be something you don’t think about until you’re critically low. Carrying a charger should allow me to grab a charge as needed.

Keep In Touch

I found Twitter to be invaluable last year for finding out about both sessions and social events. For those I follow in my closer social circle, I have their updates text message me; everyone else I can check as I wish. I just need to remember to disable the text messaging before I go to bed, then re-enable in the morning.

During the day next week, my Twitter stream will become somewhat cryptic: I tweet the session number and room I’m in (e.g. “101 Presidio”) when in a session; if you’re in the same session hall, you can then choose to look for (or avoid) me.

Feel free to follow me, but don’t be offended if I don’t follow you back. To limit the flow from Twitter, I have a general rule of trying to restrict myself to following people I have met in real life. Feel free to say “hi” and I’ll almost definitely follow you back.

I look forward to meeting as many fellow developers as possible this week, and wish you all a successful WWDC, however you define “successful.”

Joe has a very solid grip on the topic, and a seemingly boundless desire to both share what he’s learned and learn from others. Writing for the iPhone can be a bit disorienting at first, especially if you’re not already familiar with Cocoa; Joe is an ideal sounding board for questions you may worry might mark you as a “rookie.”

We got a preview of the course at last month’s Xcoders meeting, and I highly recommend it for anyone wanting to get up to speed on iPhone development. (Especially if you can get the discount he mentions in his post.)

Warning: If you are not an iPhone developer and don’t plan to be, you should consider skipping this post. It’s minutia you will never use, and I don’t offer a refund for your time or brain cells spent reading this.

Profile Fun

The session started off with the client stating that he couldn’t get the code running with his Developer and Ad Hoc profile on his phone (I had been giving him milestone releases signed with my Ad Hoc profile which (mostly) worked just fine). I’m still not convinced that the combination of both Developer and Ad Hoc is desirable, let alone valid, but that’s beside the point–in the absence of being able to convince myself it was invalid such that I could convince him it was, I would do my best to make it happen.

I got it working with the Developer profile pretty easily, but Ad Hoc was elusive. I installed clean copies of the mobileprovision files a few times, with and without restarting Xcode to “be sure,” but still no joy.

The real problem? The profile was for App Store Distribution, not Ad Hoc. Both kinds of profile say “iPhone Distribution” in Xcode, so no information gained there. I found it suspicious that his profile didn’t list any devices, but didn’t feel I could assume that just because he hadn’t added a device to the provision implied that it was for the App Store. As it turns out, that assumption is correct: App Store profiles can’t have devices specified, and the Program Portal won’t let you create an Ad Hoc profile without at least one device specified.

At this point, some of you may be rolling your eyes at my client–please stop. I don’t know anyone who has felt that this process and the Dev-vs-AdHoc-vs-AppStore distinction were clear when they first encountered it. Working with profiles isn’t an everyday thing; once you get it working you tend to just use it the way it is and as a result that knowledge doesn’t necessarily stay in long-term memory. Creating your own profiles also allows you to name the profile descriptively, whereas trying to determine whether someone else did it “right” is not immediately obvious. This was an interesting challenge for me, but I don’t fault him at all.

Submitting the App to iTunes Connect

So, we’ve determined that we’re working with an App Store profile not Ad Hoc, and at this point have decided to skip attempting the Ad Hoc and move on to submitting for review. The first task is to find iTunes Connect; the Program Portal User Guide says you “will find a link to iTunes Connect in the ‘Distribution’ section of the Program Portal”…but it’s a bit more hidden than that.

Fill out the overview form. Liberally click the circled question marks for descriptive help.

When I uploaded the application zip, I would be told that the application was invalid, so I clicked the “Check here to upload your binary later” checkbox to allow me to upload all the (corrected) images and continue setting information about the application. Most of that was self-explanatory, or at least answerable by my client (”How much do you want to charge?”). That checkbox is pretty magical–you can fill out everything about your app but the app itself and leave that to the last step. I plan on making that my modus operandi for every future app.

Fix the App Signing

There were still two more layers of the app submission onion I needed to peel away. The first was to figure out why my app archive was “invalid.” Once again, I did numerous clean-and-build cycles to check that the Build Output window looked like it was signing correctly and generating the files as expected. I downloaded “fresh” copies of the mobileprovision files and reinstalled them in Xcode in case all the twiddling I’d done earlier had corrupted something.

Then I finally slapped my forehead when I realized that the signing had continued to use “iPhone Developer” not “iPhone Distribution”. In the mass of build output text, I’d mentally reduced to “iPhone D” and called it a match. I went to the target’s build settings in Xcode, changed the Code Signing Entity to the “iPhone Distribution” entry, cleaned all targets, rebuilt and…it was still signing with “Developer”. No matter how many times I toggled the build setting, it refused to use a different profile.

Searching the web, I mostly found suggestions to delete lines in the pbxproj file where PROVISIONING_PROFILE and CODE_SIGN_IDENTITY were defined. After making a backup of the file, I went for the nuclear option and stripped the lines. I started Xcode back up and reconfigured the now-empty Code Signing Entity setting, cleaned targets, rebuilt and…it signed with “Distribution” finally!

As I said, I consider this a nuclear option. Future releases and projects will probably follow Craig Hockenberry’s advice for sharing projects once I get my brain wrapped around it better. Until then, “grep -v PROVISIONING_PROFILE MyApp.pbxproj | grev -v CODE_SIGN_IDENTITY > MyAppStripped.pbxproj” will help me out.

Zip the application, camelCase the zip file, upload to iTunes Connect…and the app is valid! But one more hurdle: I am told that the bundle identifier contains disallowed characters. This is relatively easy to troubleshoot: The project template of “com.yourcompany.${PRODUCT_NAME:identifier}” translates spaces in multi-word product names to an underscore (”My App” becomes “My_App”) which is not allowed. Simple troubleshoot, simple fix: As much as I would like to figure a correct way of using the variable substitution (this app changed names a few times during development), at this point I’m willing to just hardcode that last piece of the identifier to a camelCased version of the product name.

Cleaned targets, rebuilt, zipped the application, camelCased the zip file, uploaded to iTunes Connect…

SUCCESS!

So there the app sits, with a little yellow “In Review” globe in the status field. I plan to do a post discussing what I learned during the development of the app, but will wait until it’s actually approved by Apple since numerous changes and learning opportunities may still be in store.

My wife and I have registered with the State of Washington as “Goracke Consulting, LLC” (the word “Corporation” is not allowed in an LLC name–who knew?) doing business under the name “Corporation Unknown.” It’s been an interesting process; not difficult, but filled with worry about not “doing it correctly” at each step. We made the final step of opening the business bank account on the last day of the year, and are ready to officially enter our first full year of business.

Since last year’s simple goals worked out pretty well, I think I’ll state my business goals for this year. In no particular order:

• WWDC
• C4
• Ship It!
• ?
• Profit!

(Hoo-boy, that joke never gets old.)

I have a couple dev-related posts I’ve been meaning to get out of my head which should be appearing soon. One of them will (if all goes as planned) include shared code I hope people will find useful.

Happy New Year!

But the latest post by Glen Aspeslagh describes Ecamm Network’s usage of a project which seems to deserve increased exposure: Cocotron, “an open source project which aims to implement a cross-platform Objective-C API similar to that described by Apple Inc.’s Cocoa documentation.” Or, as glibly summarized by the Ecammeratus: “Wrote a Cocoa app? Just add a new Xcode target, hit compile and out shoots a Windows version.”

Sure, it doesn’t work perfectly, but Glen’s warts-and-all description sounds promising. If you have a product that could benefit from a Windows equivalent please give Cocotron a look and contribute code–so it will be easier for me to use when I come up with a product that could benefit from it.

I can’t imagine anyone will be hearing that news from this blog first, but I do want to acknowledge and take advantage of it. My last post felt a bit vague, even to me, about my definition of “iPhone black” and that was partly due to dancing around the NDA. While it was really tempting to be provocative, I felt it would be irresponsible for my current contract work to risk getting smacked with an NDA violation (even though I have yet to hear of an instance) and have the client’s product suffer as a result. I considered screenshots, but felt they were either singling out someone else’s application, or a simplistic straw man if I just used an Interface Builder mockup.

The definition I had in mind of “iPhone black UI” is not simply “any view whose background is black”; it is a UINavigationController whose UINavigationBar's barStyle is UIBarStyleBlackOpaque (instead of UIBarStyleDefault) and is controlling a UITableViewController whose controlled UITableView's rows have either a white or black background. If a UIToolbar is present, its barStyle is also UIBarStyleBlackOpaque. I think most people understood that, but I still prefer to be explicit.

Wow, that feels great to type all those UI* prefixes in public–I encourage everyone to do so!

Brushed Metal

When Apple introduced brushed metal, I was fine with it. I was fine with it for the QuickTime Player (partly because I rarely use it on its own); I was fine with it for iTunes and Calculator.

When other apps started using brushed metal (it was as simple as a checked setting in Interface Builder) and didn’t follow the guideline of “re-creat[ing] a familiar physical device,” I would actually try to find another app. I think many of these developers tried to use brushed metal to make their app stand out, but I agreed with Apple’s HIG that it made many apps look “too heavy” and, while I can’t recall specific examples, I remember it just not behaving as well for visual cues of backgrounded windows.

When brushed metal bled into Safari and iChat, I started hacking their nibs to disable the brushed metal; when it infected the Finder I discovered UNO and disabled it across the board (UNO also had the advantage of enabling the then-nascent “unified toolbar” interface look, which I really liked).

I rather like the idea of a “look” or “mode” which adds contextual information about the app itself, but when people use it with abandon, it loses its contextual purpose. In interior design, there is the concept of an accent wall: A wall (usually) painted a bolder color than the other walls to draw attention and break up the uniformity of the room without domination of the bold color. More than one accent wall in a room, and the room is split-color; all of the walls the accent color, and it’s no longer the accent color–it is the room color. This is what I feel happened with brushed metal.

iPhone Black

If you can remember back that far, think about a stock iPhone devoid of App Store purchases. Phone, Mail, Text, Calendar, Maps, Safari, Settings, and half the tabs in Clock–gray status bar, blue navigation and toolbars. Black is used in the tab bars, and indicates that the icons here behave differently from a toolbar (again, modes). Yes, there are a few “variants”–the Stopwatch and Timer tabs of Clock, Photos, and iPod while playing. These are all fullscreen uses, with the apparent intent to blend the controls into an unobtrusive background.

But notice how even the iPod application uses blue navigation bars when in table/list mode. I don’t believe there is a single Apple application with a black navigation or toolbar displaying a table view. Yet, that is exactly what many third-party applications are doing.

I must confess that when the App Store finally opened, I hadn’t really dived into the SDK very deeply. When I saw the first “black UI” app, I was amused at the work the developer must have done to override the standard color just to make it “sexy black.” Obviously, I didn’t know at the time that black was just another option in Interface Builder. Now I know, and it’s apparent by the large number of applications with the black UI.

WWAD?

As an iPhone user, I appreciate the consistency of interface among the applications. Gratuitous use of a black UI only serves to distance an application from this smooth interface flow–maybe not as bad as a yellow, green or pale blue background, or an application that doesn’t even use standard navigation, tool and tab bars–but distanced nonetheless. Ironically, as more applications use the black UI, any one app using it is no longer differentiated–it’s now just noticeably “not Apple.”

Maybe I’m just not good enough about developing bleeding edge user interface; I consider myself to be more in line with “WWAD?” than “WWPD?” I’m not going to call out any specific apps as looking bad because of this, but I will give one positive comment: I think Twitterrific is one app that has a really good all-black look although I appreciate and prefer the “light background” preference (which I’d still like to see go all the way to standard colors).

I certainly wish Apple’s HIG had more guidance on this topic, but until then whenever I see a black UI app that doesn’t exhibit a need to take the user into a different mental mode, I consider it just as gratuitous as brushed metal.

Goal #1 (The Personal One): Return to our honeymoon place for our anniversary. For the first 5 years of our marriage, we did an anniversary trip to Sooke Harbour House, the same place on Vancouver Island we honeymooned. It was an awesome indulgence and great way to recharge. Then baby came along, and logistics haven’t worked out. My goal was to get that tradition back on track–it didn’t happen. We (actually, Marya) did find a really nice weekend hideaway closer to home and more affordable, and that’s where we celebrated this year; we also technically still have time to visit Sooke this year, so I’m counting this goal as “half accomplished” and it’s already reappearing on next year’s list of goals.

Goal #2: Attend WWDC. I wanted to take the next step toward creating Mac software, which has long been a hobby/pasttime/fascination. This isn’t really a goal that can give half credit, and I didn’t actually think this was going to happen until (again, with not only my wife’s blessing but encouragement) it was decided at the last minute of early registration to go for it. I haven’t regretted it since, and need to make this another annual tradition.

And now the biggie:

Goal #3: Make some money writing Mac software. This could have been the easiest one, and certainly the most affordable. The size of the check wouldn’t matter–it could have been $5 under the table for all I cared, and it would have been a step forward. I have exceeded that goal.

I now hold in my hand a check for a side contract I accepted to write an iPhone application. I had not really been interested in iPhone apps when I went to WWDC, but I had just thought of an app that would scratch a personal itch and started writing that app when I was approached about this contract so I felt confident enough to accept it. It’s been hectic fitting this development into my schedule, it’s been frustrating to figure out not only how to do things on the phone, but how best to do them. But it’s also been incredibly rewarding even beyond the financial end.

This check was for the prototype of an application. It may never make it to the App Store, and you may never see it. I hope you do, and if it gets that far (and I’m allowed) I’ll make sure people know about it here. I’m proud of what I’ve done on it so far, but if it never goes any further, it will still be the application that accomplished one of my goals.

That’s just software created by attendees. It’s an impressive Who’s Who of companies and applications, all sitting down together in a conference room for the weekend.

Now, C4[2] opened registration and sold out while I was off on a weekend getaway. I hadn’t attended the previous two years, but was hoping to make it happen this year. There’s not much I can do about that except say “bummer” and look on the bright side: I had been very close to booking a flight and room when the dates were first announced, and I haven’t had to spend the day canceling reservations now.

What is the next Mac dev conference this year, and where should I set up my tent for the line?