Web Roulette 1.0.1 is on the App Store
Apple approved the 1.0.1 update to Web Roulette earlier this week. It fixes a potential crash when submitting links back to us and addresses a UI glitch on the “about” screen.
One interesting statistic from the first couple weeks of sales is that iPad users are the large majority of daily users. It’s hard (impossible?) to say if this is because there is less competition in the iPad part of the App Store or if people prefer to use a web-centric app like Web Roulette on an iPad.
Automatic Subversion Revision Stamping for iPhone Projects
Early during development of a new iPhone OS application, I discovered that App Store submissions must use a strict format for the CFBundleVersion key in the Info.plist file. It can only be numbers and dots. This left me a little frustrated with how to version pre-1.0 releases to testers. I didn’t want to use an open-source style “0.9″ and yet it wasn’t 1.0. What I really wanted was “1.0 b1″ or similar.
I stumbled on Daniel Jalkut’s post about automatically stamping the Subversion revision into Info.plist and thought that might be a good way to go. I also created a new key in Info.plist, LYSApplicationDisplayVersion, that I use as a human-friendly version string, which is where I get my preferred “1.0 b1″ form. CFBundleVersion now takes the form of major.minor.revision, where major and minor are the important parts of the human-friendly version (“1.0″) and revision is the Subversion revision number that produced the binary.
I like this method because it solves one problem raised by commenters on Daniel’s post. Because the Subversion revision is the third component, it doesn’t matter than r3999 is a mature 1.2 point release and r4000 is a risky pre-2.0 alpha for testers. Those versions end up 1.2.3999 and 2.0.4000 and it’s clear that they are from two different branches of development. For iPhone Ad Hoc distribution, iTunes also parses the version properly and knows that 1.0.100 is newer than 1.0.95.
Here is the script to paste into your custom script build phase:
# Xcode auto-versioning script for Subversion # by Axel Andersson, modified by Daniel Jalkut to add # "--revision HEAD" to the svn info line, which allows # the latest revision to always be used. use strict; die "$0: Must be run from Xcode" unless $ENV{"BUILT_PRODUCTS_DIR"}; # Get the current subversion revision number and use it to set the CFBundleVersion value my $REV = `/usr/bin/svnversion -n ./`; my $INFO = "$ENV{BUILT_PRODUCTS_DIR}/$ENV{WRAPPER_NAME}/Info.plist"; my $version = $REV; # (Match the last group of digits and optional letter M/S/P): # ugly yet functional (barely) regex by Daniel Jalkut: #$version =~ s/([\d]*:)(\d+[M|S]*).*/$2/; # better yet still functional regex via Kevin "Regex Nerd" Ballard ($version =~ m/(\d+)([MSP]*)$/) && ($version = $1); die "$0: No Subversion revision found" unless $version; die "$0: Modified, switched or partial working copy, you sure about that?" if $2 && ($ENV{"BUILD_STYLE"} eq "Ad Hoc" || $ENV{"BUILD_STYLE"} eq "App Store"); open(FH, "plutil -convert xml1 \"$INFO\" -o - |") or die "$0: $INFO: $!"; my $info = join("", <FH>); close(FH); $info =~ s/([\t ]+<key>CFBundleVersion<\/key>\n[\t ]+<string>\d+\.\d+).*?(<\/string>)/$1.$version$2/; open(FH, "| plutil -convert binary1 - -o \"$INFO\"") or die "$0: $INFO: $!"; print FH $info; close(FH);
There are a couple of other changes to this script for Subversion 1.5 and later, and for iPhone OS targets.
The first is that the regular expression allows for a trailing P in the Subversion revision. This signals a working copy from a sparse checkout, which I never use and therefore may be a problem. I have the script fail if any letter is appended to the revision when the BUILD_STYLE is “Ad Hoc” or “App Store”, which are two new configurations, cloned from Release, that I use for Ad Hoc and App Store distribution, respectively. Especially for modified working copies: I never want to accidentally hand out a build made from a modified working copy. Should the day come that I really do, I can comment this line out, make the build, and uncomment it again.
The second is that iPhone projects convert Info.plist to the binary plist format in the application bundle. In order to extract the existing CFBundleVersion key, it must be converted back to XML. When writing the plist back out, it is again converted to binary. Both of these steps use plutil, which is part of the Developer Tools.
Remember HTTP Password in Mobile Safari
In iPhone OS 3.0, Apple allowed Mobile Safari to save usernames and passwords in web forms. Unfortunately, Safari does not offer to do the same thing for HTTP Basic and Digest authentication. I’ve become fond of using HTTP authentication because it is very easy to set up, either in your Apache virtual host configuration or within a Rails application. There are many times that a full-fledged user database is unnecessary for a simple administration back-end.
There is a work-around, though it does mean storing your user and password in plaintext in your device’s bookmarks. HTTP allows you to supply authentication credentials as part of the URL, in the form http://username:password@example.com/.
In the last few days, I’ve considered building a form-based login for one of my sites, just so I can do basic management from my iPad. I’m comfortable that since the device rarely leaves the house, and the data on this site is not sensitive, that leaving the password in plaintext in the bookmark is an acceptable trade-off.
Code the Phone
I’ve started a new blog, Code the Phone, with a friend of mine. The purpose of it is all things related to application development and the business of selling apps on smartphones. Not surprisingly, we aren’t talking about anything other than the iPhone at the moment.
Announcing In Season 1.0
I am pleased to announce the immediate availability of In Season 1.0 for the iPhone and iPod touch. In Season is a produce shopping guide, inspired by a couple of recent books that address the problem of missing flavor in most produce found in American markets.
Here in America, we’ve become rather used to the idea that fresh fruits and vegetables are available whenever we want them. What we don’t always realize is that this convenience comes at the cost of flavor and price. Plants grow according to a schedule, and while we can force things somewhat (hothouse tomatoes, for example), if you want peaches in the dead of winter, they aren’t coming from the northern hemisphere.
Shipping produce from South America is a long trip to an American market, though, so food has to be bred to survive the journey and someone (the consumer) has to cover the costs of that travel.
There are even disadvantages to strawberries grown and sold in season. Strawberries are so fragile, growers have had to breed them exclusively for shipment, resulting in a berry that has only a pale shadow of true strawberry flavor left.
I created In Season to help my own family, and hopefully others, with this problem. Food tastes better when it’s grown according to its natural schedule, and even more so if you can find a local farmer supplying produce to your market. It will take less effort to grow it and supply will be higher, so you will pay less. Locally-grown produce also means less fuel is burned bringing that food to market, further bringing prices down and reducing your carbon footprint at the same time.
The economics of the App Store being what they are, version 1.0 is a toe in the water. If it is well received and I can justify further development, I have some great ideas to make it an extremely useful and educational app.
If you are interested in those books I mention above, they are terrific reads: How to Pick a Peach: The Search for Flavor from Farm to Table, by Russ Parsons and Animal, Vegetable, Miracle: A Year of Food Life, by Barbara Kingsolver.
Apple Sanctioned Developer Forums
Hallelujah: Apple is now offering official developer forums for the members of the iPhone Developer Program. It’s tied to your Apple ID, so they know who’s in and who’s not, and part of the usage agreement implies that they may provide forums for the discussion of pre-release software.
I hope they extend this to Mac development, too. The Apple mailing lists are great, but up until Leopard was released, the moderators on cocoa-dev were constantly fighting the tide of questions about Leopard-only APIs.
(Seen on Daring Fireball.)
Announcing Pat Counter for iPhone
This evening I finally received an email from Apple informing me that our first application for the iPhone and iPod touch is ready for sale. I’m pleased to announce Pat Counter, a simple way to keep track of a running count without having to hold something in your hand or look at a screen to tap a button.
It’s a simple application, but it was an interesting experience in developing and shipping an application for a new platform. Rands was right about 1.0: it’s amazing how much work and time it takes to take care of all the little details, even in something as simple as Pat Counter. Valley start-ups really do go out of business because it can be so hard. (Aside: Rands’s book Managing Humans is quite good.)
I wasn’t able to find any data points out there about lead times, but for me it was five days between submission of the binary to Apple and approval for sale. That includes a weekend, but it seems like apps are still approved then, just at a slower rate.
Finally, a word of advice: make sure your binary is right the first time. I goofed my initial build and it took seven days before Apple told me about it, by which time I’d already noticed it myself. Replacing the binary was effectively the same as the initial submission; I went to the back of the line. Read the instructions for a distribution build closely and follow them exactly.
Update: It’s now available on the App Store with a direct link, but isn’t in the search results.
Update 2 (Sep. 15): It now shows up in search results, a mere five days after approval.
Contact us: info (at) lightyearsoftware.com | Press
Copyright © 2007-2010 Light Year Software, LLC. All rights reserved.