terminaleleven.

Building & Archiving in Xcode 4.0

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Helvetica} p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Helvetica; min-height: 16.0px} span.s1 {text-decoration: underline ; color: #0f3a8a}

With the recent release of Xcode 4.0, with its much improved user interface (finally a single window for everything!) and other nice new features such as Git integration we made the jump and switched over completely.  All these nice features, however, did come at a price when we finally tried to push version 1.2 of <a href="http://www.terminaleleven.com">SkyView</a> up to the market.

The way our project is setup we have several static libraries we link in, including one 3rd party library that is quite large.  When following the Xcode Archive & Distribution guide on the Developer page, it indicates you should set the "Skip Install" setting for your target and each static library built in your project to "Yes" for distribution:

This tells Xcode that for the Distribution build configuration it should produce a single contained executable -- this is required for submitting the archive to the App Store.  Here is where the problems begin.  Apparently there is currently a bug in Xcode 4.0 that prevents a proper archive from being created when this setting is set to "Yes" for <i>any</i> of your static libraries and targets.

In addition to the above bug in Xcode, we also were forced to go through our project and remove any static libraries we were building and include the source directly into our project (except for the 3rd party library).  After doing this, and setting each of the Skip Install lines to "No" for our single remaining static library and target, things archived properly and we were able to submit.

Another note, if you are trying to run Product > Archive and nothing shows up in Organizer after it succeeds this is most likely because you are linking in some static libraries and it is still building their source.  We had to <b>uncheck</b> "Find Implicit Dependencies" in your active Scheme's "Build" section.  With this enabled Xcode automatically tries to discover and build other dependencies automatically, and in our case, incorrectly.

SkyView in Education Top 5

Thanks to everyone who has downloaded our augmented reality stargazing app, SkyView, as it has been in the Top 5 in Education for several weeks now. We've recently released a free version of SkyView to the App Store and it's been climbing the free charts in Education quite rapidly, currently also in the Top 5. If you haven't had a chance to check either of these out, head over to the app store and see what you've been missing!

http://itunes.apple.com/us/app/skyview-explore-the-universe/id404990064?mt=8

SkyView Free 1.0 Has Been Submitted

Permanent SVN to Git Transition

A little while back we decided we wanted to make the jump to Git from SVN.  There were a few reasons but the main 2 were the fact that we are a distributed team and our current SVN server, privately hosted, is quite slow.  We chose GitHub as our hosting option because of its low cost and great collaboration tools.

After creating our new repository on GitHub, I started looking at options for importing our largest SVN repository.  The first option, svn2git, was used previously on smaller repositories so I gave that a shot at first.  When running the usual command:

svn2git https://xxx.xxx.xxx.xxx/repo --authors ../authors.txt

We ran into the following error:

RA layer request failed: REPORT of '/repo/!svn/vcc/default': SSL negotiation failed: SSL error: parse tlsext (https://xx.xx.xx.xxx) at /usr/local/git/libexec/git-core/git-svn line 5091

We would get this after svn2git ran for a while on the repository.  Because of this we turned to using git-svn for the import and used svnsync to pull the remote repository down locally.

1.  Create Local SVN repository

First things first, you need to create a fresh new local SVN repository:

svnadmin create /pathto/newrepo

2.  Add a “pre-revprop-change” hook to the local repository

Following the guidance here, step 2, you have to add a "pre-revprop-change" hook to your new SVN repository.  This allows for successful modification of revision properties in your repository outside of a normal commit.

If you're on a Mac, as we are:

echo '#!/bin/sh' > /pathto/newrepo/hooks/pre-revprop-change
chmod +x /pathto/newrepo/hooks/pre-revprop-change

3.  Synchronize new local repo with remote one

In our case, because our SVN repository is a remote one with access via https we cannot simply do a dump of the repository.  Therefore, we have to use 'svnsync' to synchronize the remote repository with a local one.

svnsync init file:///pathto/newrep https://xxx.xxx.xxx.xxx/repo


svnsync sync file:///pathto/newrepo


 

Get some coffee, this might take a while.

4.  Setup "authors.txt" file

Create a file that maps your SVN names to email addresses on GitHub, such as:

billyb = Billy Billyson <email@email.com>


sams = Sam Samson <email2@email.com>

5.  Import local SVN repo into a new Git repo

git svn clone -s file:///pathto/newrepo /pathto/new_gitrepo --no-metadata -A ./authors.txt

The '-s' indicates this SVN repos is in "standard" layout, meaning there is a "branches", "tags", and "trunk" directory.  If you have a different layout you might want to look at the dogs for git-svn for more information.  Additionally, the --no-metadata tells git-svn to leave behind SVN stuff you shouldn't need.

6.  Cleanup Git repo

Now change directories to your new Git repository.

In our case, we didn't have any branches or tags so this made things much simpler after importing.  If you need more details on how to move these over, see here.

In  our case, we only had a single branch created by git-svn on the migration, and this branch was called "git-svn".  We removed this unneeded branch (there will also be a "master" branch, which is needed):

git branch -d git-svn

Now we can remove all the SVN stuff we no longer care about:

git config --remove-section svn-remote.svn


rm -Rf .git/svn/

7.  Push new Git repo to GitHub

Make sure you first have your new repository created at GitHub and then from your new local Git repository directory (/pathto/new_gitrepo, to follow previous steps) do:

git remote add origin git@github.com:yourgithubname/newrepo


git push

This will now push up your newly converted SVN repository.  Now you can enjoy Git-awesomeness from here on out.

UIView Animations Using Blocks (Closures)

Just a quick tip for someone looking to easily convert their simple pre-iOS 4.0 UIView location animation code to use the new block mechanism.

Our previous animation code:

Now becomes the much cleaner & more simple:

Blocks (or closures) have been around for quite a long time, and go by many different names, and I'm pretty excited to start using them with the iPhone SDK.

LED Flashlight HD

After a number of setbacks, and nearly a month of "review" time, our app LED Flashlight HD is finally up on the App Store.  We are completely shocked at how long this took to finally reach the store shelves after submitting it for review all the way back on June 17th.

A few lessons:

Below is the Apple review history.  As you can see we submitted it June 17th, only to be rejected June 23rd because of an "incomplete iAd implementation".  The issue here was that we were constantly displaying an iAd banner even if an ad was not being served from Apple's ad servers.

Lesson #1: Only display iAd banner when an ad has been served to your application.

After we fixed this and promptly resubmitted to Apple, we waited all the way until last night (nearly one week, mind you) until we finally sent Apple an email regarding the status of the application.  Upon sending the customer service email we received a reply immediately stating that our marketing screenshots displayed iAd in an "invalid state".  In other words, we were displaying an empty iAd banner in the screenshots. 

Lesson #2: Leave out iAd banners in screenshots.

Well after nearly a month, it's finally on the App Store.  I firmly believe we were one of the first ones to submit an LED flash application for the store but due to a few technical issues and delays on Apple's end, now we have fallen in the pack.  Regardless, if you need a FREE simple flashlight app for your iPhone 4, pick it up on the App Store today.

LED Flashlight HD [iTunes]

New & Noteworthy

Our application, Real Mirror HD, recently posted on the Apple app
store is now in New and Noteworthy under Utility. Thanks for the
selection Apple!

Real Mirror HD: On the App Store

Finally after a week+ of working with App Store submission woes our mirror application is on the App Store.  Real Mirror HD is a dead simple application for the iPhone 4 that simply uses the front-facing camera to produce a mirror.  We've included a few other things to set us apart:

• Super-fast startup time, even faster than starting the Camera app and switching to front-facing
• iPhone 4 high-resolution graphics: the frames look pretty darn sweet on the new high-res screen of the iPhone 4
• Blemish Checker: 2X zoom for the mirror, giving you a closeup look

Check out a few of the screenshots:

(download)

Click here to download:

real-mirror-hd-on-the-app-store-cBigIFEilbbxuIzwirCC.zip (3.74 MB)

If you'd like to pick up this app, check it out in iTunes, it's only $0.99!

http://ax.itunes.apple.com/us/app/real-mirror-hd/id378238414?mt=8

In the meantime we are still waiting for our LED flashlight app to be approved/rejected... Apple?

iAd Mix Up

Last week when pushing up our new application LED Flashlight HD to the Apple review process for the Market, we encountered the new "Enable iAds" button on the iTunes Connect page.  We had full intention to make this a free application from the get-go, and decided we'd try out the new iAd infrastructure by including this in this flashlight application (who wouldn't want to use a free flashlight application on their phone?  Especially one that actually uses the phone's LED instead of the cheesy screen backlight...).  What we found out, the painful way, was that if you are using your wildcard distribution profile for your applications when you push them to the market, they will not be able to be used in conjunction with iAd.  When clicking the "Enable iAds" button in iTunes Connect, it will indicate that there is not a valid bundle to work with iAd - but it still lets you continue!

What you need to do to avoid this is simply create a new provisioning profile from the Provisioning Portal that will be used for the distribution for your application and select that provisioning profile instead of the default wildcard profile.  Simple.

Our mistake basically has set the approval process for LED Flashlight HD back one week, doh.

Icons by Developers

One of the most challenging things we've come across when starting to write our own applications for Android and iPhone: proper icon design.  I think for the most part many people take icons for granted.  They are expected to not only be razor sharp, but they are expected to be razor sharp at any resolution.  When first starting out it might not be obvious to many that you can't simply scale the icons down to the sizes required, say, by the iPhone.  Thinking you can make a single 512x512 icon and then do a Free Transform down to 57x57 is definitely a big mistake.

Check out a snapshot from Photoshop of the current icon-in-progress for our application, Real Mirror HD, for the Apple App Store:

• 512x512 (iTunes)
• 114x114 (iPhone 4)
• 72x72 (iPad)
• 57x57 (iPhone 3G/S)
• 29x29 (Spotlight results)

More details can be found on Apples doc for Application Icons, but this gives you an idea of the sheer number of icons that need to be created for each application.  For the most part a large number of the layers in the above icon can be scaled down without loss, but some of the shapes just have to be re-created with less detail at the lower resolutions.

The lesson here: I'll never again take for granted good icon creation now that I know the sheer amount of work required to get them out the door and looking good.