[Xcode] IPA Generation Broken, Again

It happened before and shall happen again: xcrun PackageApplication doesn’t work anymore.

The whole process isn’t meant for contractors

Let’s face it, Xcode is getting better at the coding part, but the signature / IPA generation is “streamlined” for the App Store, which in turn is under a lot of assumptions that I’ve mentioned here in the past. Since the last time, the heavy push for storyboards (oh, the tasty git conflicts), and the weird quirks of swift haven’t really improved things. Dev tools should be as flexible as possible, because they are meant for devs.

Anyways, 8.3 broke the “easy” IPA generation that everyone was using. It was especially important for Hudson/Jenkins continuous integration and beta deliveries. No, relying on the Organizer’s UI doesn’t work, because more often than not, you want automation, and Xcode is less and less automatable.

PackageApplication is gone

It worked for a while, then you had to remove a part of the entitlement checking, but now it’s not there anymore. So… no more Hudson builds?

Fret not! The one-liner may be gone, but we have a heavily convoluted multi-step export process in place that does the same!
(Imaginary tech support person)

The idea is to replicate the UI process:

  • generate an archive
  • click export an IPA
  • select a bunch of signature and type options
  • rename all the things it exported (you usually want the build number/version right)

Believe it or not, some of these are actual xcodebuild commands. But the argument list is… errrrr, weird, if you’re used to Linux and server stuff. So, no, in the following, it’s not a mistake that there’s only one dash. You have been warned.

Gimme!

There are two pieces to the export thing : a plist containing what you would type/click in the UI options at the end of the process, and a script that chains all the necessary actions together. I tried to piece together various sources into a coherent whole, but it’s a dev tool and your mileage may vary. Also, because it’s intended as a Hudson build script, it takes the version number as argument and outputs what I would upload to the beta server in Outfiles. Again, adapt it to your workflows.

The plist:

< !DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>method</key>
    <string>development</string>
    <key>teamID</key>
    <string>TEAM_ID</string>
    <key>uploadBitcode</key>
    <true></true>
    <key>uploadSymbols</key>
    <true></true>
  </dict>
</plist>

Remember to use the correct TEAM_ID in there.

The script (takes the version as first argument, may break if none is provided):

#!/bin/bash
 
APP_NAME="Insert app name here"
SCHEME_NAME="Insert scheme name here"
CONFIGURATION="Insert configuration name here"
 
ARCHIVE_DIRECTORY=Archives
OUT_PATH=Outfiles
 
#change as needed
SDK=iphoneos10.3
 
echo "Cleaning previous build"
 
#clean
xcodebuild -sdk "$SDK" \
-scheme "$SCHEME_NAME" \
-configuration "$CONFIGURATION" clean
 
echo "Creating Archive"
 
#archive
xcodebuild -sdk "$SDK" \
-scheme "$SCHEME_NAME" \
-configuration "$CONFIGURATION" \
-archivePath "$ARCHIVE_DIRECTORY/$APP_NAME-$1.xcarchive" \
archive
 
echo "Creating IPA"
 
#export ipa
xcodebuild -exportArchive \
-archivePath "$ARCHIVE_DIRECTORY/$APP_NAME-$1.xcarchive" \
-exportPath "$OUT_PATH/" \
-exportOptionsPlist exportIPA.plist
 
#name files and dSYMs
mv "$OUT_PATH/$APP_NAME.ipa" "$OUT_PATH/$APP_NAME-$1.ipa" 
cp -rf "$ARCHIVE_DIRECTORY/$APP_NAME-$1.xcarchive/dSYMs/$APP_NAME.app.dSYM" "$OUT_PATH/$APP_NAME-$1.dSYM"
cd "$OUT_PATH"
zip -r "$APP_NAME-$1.dSYM.zip" "$APP_NAME-$1.dSYM"
rm -rf "$APP_NAME-$1.dSYM"
cd ..
 
#optionally
# rm -rf Archives

As usual, use with wisdom ;)

Final Thoughts

It’s not that the system is bad, per se. It actually makes a lot of sense to have commands that mirror the GUI. But the issue is, for a long long long long time, automation hasn’t been about simulating clicks. Since you don’t have the UI, it makes even more sense to have shortcuts in addition the GUI counterparts

  

[Ouch] The Joy Of Migration

So, out of the blue, and to escape from a dickish choke hold on my public facing infrastructure, I decided to switch back to administrating my own installation on a VPS…

First off, you think you are good at system administration when you have a lil server at home that has been running since forever and that you maintain, right? Wrong. Installing a production server from scratch is a totally different thing. You do not have the luxury of your comfortable habits and scripts that work just so on your tiny little environment. Everything has to be re-thought, as well as re-configured.

Private-facing daemons have to be secured (less than 4h after the original installation, I already had 3 script kiddies trying to brute-force my root password… seriously), everything has to be hooked up to talk to each other, some wanting to talk to localhost, others to the public facing IP address…

And then, you start setting apache up. Yes, I use apache rather than nginx. Sorry. I happen to know my way around apache (kind of), and nginx baffles me. Anyway… Let’s say that vhost management in apache is full of silent and deadly pitfalls. It took me 4h to realize that www.krugazor.eu and krugazor.eu didn’t actually point to the same thing. I will skip talking about LetsEncrypt for now, as I have many things to say about it, mostly positive, but the initialization process was painful, to say the least, although not all of their making. So, instead of ranting now because I haven’t slept much, I’ll save it for later.

I may go into specific details later, but suffice it to say that those were 24h full of “fun”. Yes, even though it prevented me from having a good night sleep, even though I have lost some hair, it is quite an intellectual challenge, and while the whole voodoo-vs-science tinkering reminds me a lot of programming, it feels good to “mentally masturbate” (as some of my friends call it) about a different topic.

I especially wanted to highlight the overwhelmingly positive factor that is Hover, which is just plain awesome. Their interface is clean and clear. Their rates are a steal. And the support I got for helping me with the DNS migration was just jaw dropping fantastic. A fella named Marty picked up the phone at 8:15 his time (.eu domains are ‘tricky’ to transfer), and while he was a thorough professional, the conversation felt no different than with any other of my geek friends, exchanging local news and anecdotes. 12h later that ‘tricky’ process was done and dusted, with a 20 minutes enjoyable phone call, and 4 emails. If that’s not a fantastic customer service, I don’t know what is.

As a conclusion, I will just say that if you find that some services and/or pages are broken, drop me a line!

  
Mood : tired

[Xcode] Broken IPA Generation

As of Xcode 6.0.1, you can only generate an IPA with a certificate/provisionning profile pair that matches a team you are part of (it offers only choices present in your Accounts preference pane).

Before ranting about why this this is stupid as hell, here’s a workaround:

xcrun -sdk iphoneos PackageApplication [path to the .app] -v -o [path to the ipa] --embed ~/Library/MobileDevice/Provisioning\ Profiles/[profile to use] --sign "[matching developer NAME*]"

NAME is the name that appears in the popup menu in your xcode build settings, not its ID

After a somewhat lively discussion on Twitter about that, two things:

  • I know Apple would prefer that developers are organized in teams managed on their servers. It’s just not practical for a lot of them, and there’s even a few good reasons not to go that way
  • It’s stupid to have that drastic a change, when 3 weeks ago, the official way of having a third-party developer generate IPAs for your company was to give him a p12 and a .mobileprovision and let him do his thing, and to not warn people about the change

For those of you who don’t know how development of a mobile application works, yet, here’s a quick run down.

A customer contacts me for a development. We agree on a timeframe and a price. I write the code, provide them from time to time with testable betas. When we agree it’s finished, I give them the final IPA for putting on the store and we call it a day.

Providing betas and giving an IPA for the App Store work exactly the same: a binary is produced, which is put in an IPA (kind of installer package for iOS), then that IPA is signed, and transmitted. On the other end of the wire (be it the customer or the App Store), the IPA is decompressed, the signature checked for validity (by app ID, device, and status of the apple account), and the app can be run or put on sale.

In that scenario, if I use my certificate, I have to enter the device IDs the customer will test the app on, of which my developer account allows for 100, in total. So if I have 10 customers with 10 devices a year, I can’t work anymore. So, most of the time, the customer has to provide the relevant information for me to give access to the betas, and of course, since they’re releasing it under their own name, the relevant information to produce the final version, which is a different pair of keys.

So far, so good, all they had to do up until now was give me a couple of p12 (key archives) and the corresponding profiles, and manage themselves the test devices, the release, etc.
It allows whoever’s in charge to retain access and knowledge about what the company is doing. Does that person want me to see they are also working on a concurrent product to something I’m doing for somebody else? Of course not. And there’s no reason to give me that kind of access. Oh and if the customer wants to prevent me from using that certificate again, all they have to do is revoke it.

The new way of doing things is to have the customer invite the developer in the team (in the Apple sense of the term), which gives the developer access to every piece of information under the sun (even when we can’t use it directly).

This is part of an ongoing cycle of making life difficult for contractors. We always have to find workarounds. The idea that almost every ios/mac developer out there is writing code for the structure they belong to, who will then release it in their own name for the general public is ludicrous. It hinges on something that has been gnawing at me for years: the idea that code and binary are the same thing, and is what I’m selling.

That idea is false. When you get Unity3D for your game development, you DO NOT GET THE CODE. For Pete’s sake, we don’t get the code of the OS we are developing on! The idea that when a developer is hired, the customer automatically owns the code is one of the many fallacies I have to deal with on a monthly basis. You hire a developer for his/her expertise first, and foremost. It might be then applied to internal code, which the dev won’t own in the end anyways, or to a newly minted piece of code which might or might not be given with the ability to use said code as part of something that has value. It is a separate item on the negotiation list.

I might delve into the pros and the cons of giving out your source code with the binary in a later post, but let’s get back on topic.

If, like me, you don’t always give the code with the binary to the customer, you’re screwed. Of course they won’t give you access to their company’s secrets by adding you on the team, if they don’t want to. And, obviously, you can’t release the binary under your own name for a customer who wants an app.

Please give me back a way to sign IPAs for customers, directly from my IDE.

Thank you, and sorry for ranting.

  

Rule Of Thumb

Principles, rules and laws are essentially the same thing. I won’t bother you with a paraphrasing of my recent reading list, which includes Plato, Kepler and Douglas Adams, but for a freelancer, it’s important to differentiate what is what, especially for the Other Guy.

A principle is a lighthouse on the horizon, and it’s OK to veer left and right, or even ignore it altogether. That’s one end of the spectrum. At the other end of the spectrum, you have the Law, which, to quote Morpheus, will break you if you try to break them (and get caught, obviously).

There are varying degrees of rules in between, from the rule of thumb to the house rule. Which apparently is akin to law. Or so I’m told.

Moving on…

Developing a program is kind of a ninja split between the two: some rules are unbreakable, because of maths, and contracts and stuff, and some people try to impose on us rules that can (and sometimes should) be gladly ignored. Just look at some interface designs blatantly ignoring the rule that someone somewhere edicted, and look just plain awesome. Right?

I took a roundabout way to make that point but programmers tend to consider rules with a clear downshift on the “have to” slider.

But, as computers are very attached to their governing rules, humans go a long way to actually enforce them. Case in point: you’re asked to make a mockup app that will illustrate some concept or something. It’s about as easy as making a working prototype, sometimes, so we bend the Prime Beancounter Directive: we go beyond what’s asked. But it’s not what was covered in the Contract. So we don’t get paid. Or at least it’s very hard.

So the appreciation of this particular rule was apparently wrong.

The problem is twofold: the question of the rigidness in the expression of the rule, and whether the Other Person tends to respect the spirit of the rule rather than the letter of it.

For the second part, it’s a lot easier to hide behind wording and you-have-to-s than to imagine what the intent of the rule is. That’s how we get “warning hot” on coffee cups (wait, what? I specifically ordered a lukewarm boiled cup of coffee, not that seemingly delicious cup of joe!), or “do not dry your pet in it” on microwaves (I won’t even bother). As weird as it sound, stupidity is foolproof. Adhering completely to blatantly stupid explicit rules is what makes the world tick smoothly it seems. For more on that, see the Miss Susan vs Jason, in Thief of Time.

You soon learned that ‘No one is to open the door of the Stationery Cupboard’ was a prohibition that a seven year-old simply would not understand. You had to think, and rephrase it in more immediate terms, like, ‘No one, Jason, no matter what, no, not even if they thought they heard someone shouting for help, no one – are you paying attention, Jason? – is to open the door of the Stationery Cupboard, or accidentally fall on the door handle so that it opens, or threaten to steal Richenda’s teddy bear unless she opens the door of the Stationery Cupboard, or be standing nearby when a mysterious wind comes out of nowhere and blows the door open all by itself, honestly, it really did, or in any way open, cause to open, ask anyone else to open, jump up and down on the loose floorboard to open or in any other way seek to obtain entry to the Stationery Cupboard, Jason!’

Loophole. The Dreaded Word by the Rulemakers. The Golden Sesame for the Rulebreakers.

But the power of a loophole relies solely on the fact that the rule is rigid to the point of absurdity. Of course, there should be an unbreakable rule that states that it’s not allowed to come to my home and take my hard-won computer for themselves. Of course there should be one for being able to tell a power hungry person that they overstep said power.

I guess the whole point is finding out where the rule protects a group of people from others and also from themselves. But when we’re talking about breaking a rule, in order to make something better for everyone, it’s an epitome of everything that’s wrong with our reasoning abilities.

And yet… I hear some of you think along the lines of “yea but if some rules should be put aside, how can that not be an argument for that there should be no rule, at least with some people?”. Strictly respecting all the rules makes it easier to have others respect all the rules as well, right?

Wrong.

Again, I think it’s a matter of harm. If by breaking a rule you harm no one (including yourself) in any way (except maybe their ego, but that has nothing to do with anything), then the rule is stupid. And should be ignored. Like, say, going beyond expectations. Actually, breaking a stupid rule should be grounds for an award, a compensation, something stating “wow, that rule was stupid. This awesome programmer deserves a raise. And he’s so cute too… <fawns>“.

Ahem. Anyways…

So then, I hear you think from here on my spaceship, how do you know you’re doing no harm? to anyone?

Dude, the daily personal and professional interactions we have are rarely a matter of life and death for entire nations. Business laws are supposed to protect me from getting screwed over by customers with no scruple. Not to prevent me from doing my job better than I’m supposed to. Fact is, most of the time, to enforce a “common sense” rule (getting paid for a job), I have to go through stupid rules first. And since the Other Guy is usually better equipped than I am to handle these first stupid hurdles, they win the race. So it spirals down: stupidity being the most efficient way, it becomes the norm. And we have to edict new rules to kind of balance the most stupid of our actions, or to close the loophole. Oh wait, another set of stupid rules to follow!

Stupidity is recursive. Thinking is hard.

The end doesn’t justify the means. Life shouldn’t be a permanent chess game either.

  

Popularity Contest

A lot’s happened recently, triggering a lot of discussions as to who we are perceived to be.

As I was thinking about social networks, I also took some time to upgrade this website’s log analyzer. I have switched to Piwik, for various reasons:

  • it’s not too heavy on resources
  • it’s capable of loading statistics offline (I don’t want to have something that loads yet another resource)
  • it supports DoNotTrack, which means that I’ll see users only if their DoNotTrack flag is off

Of course, that last feature kind of removes some of the information, but to be honest, I don’t really care about who the visitors are personally, I just want to detect trends, and see if anything stands out.

Thing is, I started wondering about why I was looking at these things only after it was working properly. It’s not like I have a lot of visits anyway, and my work doesn’t really depend on that number. So why are these stats interesting?

Ego Trip

When you write something that gets published, there’s an obvious satisfaction at seeing it being read. And an even bigger satisfaction for me at seeing it re-read over the following months.

A few weeks ago, I read about the whole “echo” business (generating hits/visits just by having linklist-type blogs, which feed off each other). Can’t say I’m surprised that it’s common practice, and will continue to do so as long as advertisement revenue is indexed by the number of hits/visits the page gets. However you look at it, that’s one of the few statistical analysis that’s objective, and therefore can be automated. Besides, what ad-selers want is to bee seen as often as possible, and page hits give you that exact metric.

It’s a flawed way of looking at a readership, but unfortunately the only one that’s available.

Another ego factor is seeing what websites send their readers to you. Apart from generating some traffic, some of the referer’s reputation transfers back to you (if it’s a positive link, of course, not if it’s a this guy is a moron kind of link… and even then, it potentially is interesting if your point is thought to be good, even if he original link disagrees).

Feedback

This blog is about various things… This post is a more general kind of reflection, whereas there are more math or computer oriented contents. Seeing which posts or pages are generating the most traffic gives me some data points on what I’m potentially good at, or what I do that might interest people.

I’ll stop the wondering that this statement might incur by saying that the more general kind of post generates about 1/4 of what the tech/code ones do. And on the rest of the site, the vast majority is taken by customer-specific sections of the site.

Most people who come and read this know where to go, they don’t really find me by accident. And most of them come back for the same reasons.

Conclusions

So why should I care about statistics, if I pretty much know already who comes and reads what is written here? Popularity has never been my priority, and is beyond my reach anyhow, although I do prepare my coffee in a fussy way, and have a clicky keyboard ( look it up, some people said it works ;) )

It may be as simple as “I like crunching numbers“, or that I have a lot of fun seeing which search strings led to this site.

It may be because I want to keep track of which pages or posts are more popular, in order to update them as they become obsolete.

But in the end, I think it’s just a geeky thing to do: making sure I know how the things I do are acquired/read, in order to try and deduce the way they are used.

Anyways…

Anyway, to anyone who happens to be reading this (either on a regular basis or not), thank you! The ultimate goal of publishing something is to have it be read. And that’s all there is to it.

  

[ZinoAward] Best misapplied technology: the remanence clock

I’m pretty damn sure the people who invented that clock didn’t think of it as the most efficient bug-swatting device out there.

First thing first: What Is It?

This clock is based on the same principle as movies: your eyes retain any image image for a few micro-seconds, so any frequency above a certain threshold appears as movement, even though it’s a collection of stills. In theaters, the frequency is 24 images per second, and on TV, depending on where you live, it ranges from 25 to 30-ish.

This clock is made of something that resembles a windshield wiper, and with the same type of motion, only it makes roughly 20 round trips per second. At the top of the wiper, a line of lights is set. To write a message seemingly on nothing, the lights turn on when they reach a certain position, corresponding to the columns in a matrix (see diagram). Since it takes less than 1/20th of a second to make a swipe, the message seems to be written in thin air.

By now, most geeks out there are like “yea ok, cool thing, but it’s nothing new”. True. Where it becomes a genuinely interesting item is in the behavior of bugs at night: they are drawn to bright lights. And it is a LED white ramp, which means it’s very bright indeed… and when the bug reaches the place where the light should be there’s nothing except a wiper that moves really fast. Blam!

So far, my clock has swatted a bunch of mosquitos (I haven’t been bitten in a month), flies, and even a wasp.

It smells nothing, doesn’t get hot or cold, is completely silent, and deadly efficient.

So this wonderful invention gets the ZinoAward of the best misapplied technology hands down!