Re-signing iOS apps

I am occasionally presented with a packaged iOS .ipa archive by a third-party developer, which is intended for in-house distribution (using an Apple Developer Enterprise certificate), or for App Store distribution using a different developer account.

Re-signing is a quick and simple way of delivering an app when a developer won’t provide you with their Xcode project source from which to spin your own build.

I previously used the iReSign utility to accomplish this, but found that this wouldn’t work in all cases, in particular when the app includes linked frameworks or libraries (which results in errors such as “DYLD, Library not loaded“).

To solve this I wrote the shell script below. It takes an existing .ipa archive, embeds your own developer provisioning profile, replaces any existing code signatures and packages it again for distribution.

Please use with my compliments and leave a comment if this helps you out.

(Note: This script has a dependency on command line tools such as PlistBuddy and codesign, so you will likely need to install Apple’s Xcode developer tools)

Replace DEVCERT with the Common Name of your own Apple developer certificate.

#!/bin/bash
# Re-sign an IPA with specified developer certificate (present in keychain)

DEVCERT="iPhone Distribution: Your Developer Cert Name"
TMPDIR="tmpwork"
SOURCEIPA="$1"
MOBILEPROV="$2"
BUNDLEID="$3"

if [ $# -eq 0 ]

then
  echo "Usage: $0 [app.ipa] [provprofile] [bundleid]"
else
  if [ ! -e "$SOURCEIPA" ]
  then
    echo "Error: $SOURCEIPA not found"
    exit
  fi

  if [ ! -e "$MOBILEPROV" ]
  then
    echo "Error: $MOBILEPROV not found"
    exit
  fi

  SIGNEDAPP=`echo $SOURCEIPA | awk -F".ipa" '{ printf ("%s-signed.ipa", $1) }'`
  unzip -qo "$SOURCEIPA" -d $TMPDIR
  APP=$(ls ${TMPDIR}/Payload/)

  if [ ! -z "$BUNDLEID" ]
  then
     echo "Changing Bundle ID to ${BUNDLEID}";
     /usr/libexec/PlistBuddy -c "Set:CFBundleIdentifier $BUNDLEID" "${TMPDIR}/Payload/${APP}/Info.plist"
  fi

  cp "$MOBILEPROV" "${TMPDIR}/Payload/${APP}/embedded.mobileprovision"
  security cms -D -i "${TMPDIR}/Payload/${APP}/embedded.mobileprovision" > Entitlements_full.plist
  /usr/libexec/PlistBuddy -x -c 'Print:Entitlements' Entitlements_full.plist > Entitlements.plist
  echo "Re-signing with certificate: $DEVCERT"

  for folder in `find -d ${TMPDIR} \( -name "*.app" -or -name "*.appex" -or -name "*.framework" -or -name "*.dylib" \)`; do
    /usr/bin/codesign --continue -f -s "$DEVCERT" --entitlements "Entitlements.plist" "$folder"
  done

  echo "Package the signed IPA"
  cd $TMPDIR
  zip -qry ../${SIGNEDAPP} *
  cd ..
  rm -rf $TMPDIR
  rm Entitlements_full.plist

fi

iPhone 5

An industry insider told me that sales of Samsung’s Galaxy S III sky-rocketed the day after Apple’s big reveal of the iPhone 5. Evidently potential customers were holding off their upgrades until they had seen the new product, but what they saw disappointed.

I probably shouldn’t be admitting this, but I have already used the iPhone 5 and I was underwhelmed too. iPhone has become the safe (even boring?) option, something you would confidently give to your Mum and Dad. Apple’s runaway success has become the de facto smartphone, but the commercial imperative not to alienate their mainstream customer base has stifled innovation.

The original popularity of iOS (then iPhone OS) was due to its perfect blend of technology, form and function. Often it wasn’t possible to customise something to your liking, but that was by design and the intention was to keep things deliberately simple.

I look at iOS 6 and wonder where Steve Jobs’ painstaking obsession with simplicity has gone. I never expected CEO Tim Cook to share the same ethos, but since Jobs had apparently described Sir Jonathan Ive as being his “spiritual partner” there was a hope that he would carry forward Jobs’ legacy. It’s likely however that Ive’s control only extends as far as the hardware design, not the operating system, which is the responsibility of Scott Forstall.

Watching the official iPhone 5 promo video, it’s hard not to be impressed by Apple’s manufacturing techniques and the obvious attention that has gone into the hardware design (like crystalline diamond-cut chamfers!), but it doesn’t detract from the hard truth that to the average customer the new iPhone just doesn’t seem all that different.

With each new iPhone Apple usually succeeds in generating enough excitement and desire to persuade existing customers to follow the natural upgrade path, but they also lose some customers to Android – and they rarely return. I don’t know anyone (including myself) who has switched to Android and then gone back to an iPhone. Once you’ve broken away from the closed iPhone ecosystem it feels quite liberating to have the freedom of open services and a wide range of devices.

Conversely with each evolution of the Android platform the gap has been closing and arguably the Android 4.1 ‘Jellybean’ release has leapfrogged iOS by delivering a simple intuitive user interface and powerful features – much like the original iOS.

Samsung are seizing the opportunity to capitalise on the apathy surrounding iPhone 5 with a marketing campaign directly comparing their two flagship products:

Apple fanbois have responded with their own parody advert, but when the best they have to brag about is ‘fits all pockets’ and ‘elastic bounce back’ (the subject of Apple’s recent patent dispute with Samsung), it doesn’t bode well.

It’s certainly not all doom and gloom for Apple. They will of course sell iPhone 5 by the millions, but the shine is starting to fade.

I do have an answer to their predicament. Apple needs another product with which to dazzle and showcase their technical excellence and suppressed innovation.

Dear Tim, how about you add a new model to the iPhone range? Call it the ‘iPhone X’, pack it with enough fancy gizmos and new technology to satisfy the Android crowd and demonstrate what the biggest company in the world can really do.

Dealing with App Store rejection

In the course of my work I’ve been submitting iOS (originally iPhone OS) apps since 2008, so I have quite some experience in this area.

Although Apple have always been diligent in manually inspecting app submissions and successful in weeding out the chaff, I get the impression that the demands of quality over quantity have gained greater emphasis in recent months.

The App Store Review Guidelines (a living document) have been tightened-up and certainly from my experience the App Review Team have been policing them with increased vigilance.

I’ve read about developers complaining that their app has been unfairly rejected, but in most cases I can sympathise with Apple’s stance. They have the expectations of a enormous customer base to fulfil and a squeaky-clean brand image to protect. If your gut instinct is that your app might be contentious, then Apple will probably think likewise.

Don’t for a minute imagine you are going to reverse their decision by engaging the App Review Board in a battle of wits. It’s Apple’s game and you must play by their rules. If they don’t like your app then they won’t publish it and no amount of picking holes in the App Store Review Guidelines is going to help your case.

Apple doesn’t respond well to legal threats or external publicity. Let’s face it, they haven’t grown to be the largest company in the world by being agreeable with everyone. They retain the best lawyers, designers and technical experts in the world and there is no benefit to be gained by arguing with them.

So enough of the ‘do nots’ and on to my advice.

Do thoroughly read Apple’s developer documentation before embarking on a new development project. The App Store Review Guidelines are actually written in an engaging and almost humorous style, so take the time to digest them fully.

If you feel that your app has been unjustly rejected or perhaps misunderstood then respond using Resolution Center. Ask for further clarifications if required and politely ask for their assistance in identifying precisely what it would take to overcome their objections. Make your responses courteous with a sprinkling of humility and you might be in with a chance.

Some developers might feel powerless going up against the 800 lb gorilla, but I have been successful in reversing some app rejection decisions by using diplomacy and a collaborative approach.

If all else fails, my expert consultancy is available – for a modest fee 😉

Xcode freezing when opening a project?

A possible solution to Xcode 4 freezing after you open a project:

If your Xcode project source path contains a space then rename it and try opening the project again. This is the most likely cause.

If it still freezes after renaming then do the following:

1. (Force) Close Xcode
2. Delete these cache files:

rm ~/Library/Caches/com.apple.dt.Xcode
rm ~/Library/Preferences/com.apple.Xcode.plist

3. Restart Xcode & keep your fingers crossed!