Cracking the code behind Apple’s App Store promo card design | Hacker News Reader

Cracking the code behind Apple’s App Store promo card design

blog.equinux.com

249 pointsreklawnos57 comments

That mysterious font actually is an adaptation of one of the oldest typefaces around specifically designed for optical character recognition. OCR-B (1968), by Adrian Frutiger. It’s used everywhere still, on credit cards, wire transfer forms, license plates, etc. etc. It’s even an industry standard (ISO 1073-2:1976).

https://en.wikipedia.org/wiki/OCR-B

So, it’s as ‘custom’ as Apple’s (pre San Francisco) systemfont Myriad, compared to Frutiger’s Frutiger, who said of the adaptation: “not badly done” while feeling that the similarities had gone “a little too far”… — https://en.wikipedia.org/wiki/Myriad_(typeface)

It's likely that they use custom font not as a deterrence measure, but merely because it's specifically designed to simplify their recognition code.

Exactly. Also the box and placing was no 'security measure', just the way it worked. It is very interesting to see how the view of the person trying to 'break the cipher' is different to the mindset of the team that had to get it to work. They were probably security paranoid about the hackability of their work but in a totally different direction to that 'seen' by someone 'breaking the cipher'.

While I imagine it's not a security measure, I don't think it's "just the way it worked" either. It sounds like a conscious decision to limit false positives.

To elaborate what the parent was talking about when they said "the way it worked" (it might also be what you're talking about). My guess is that the box is useful to straighten, unskew, and scale the image before applying the OCR.

You could /try/ to do it looking at the baseline and cap heights of the text itself, but you wouldn't know the scale in either direction. I imagine those font identifiers would have been a lot better if they could have known those things.

At first I thought this was going to be some kind of sketchy "keygen" thing, but I was glad to see they've just deciphered the way to make your own iTunes-scannable promo code printouts! Very cool. :)

I feel like I've seen that font before, on non-Apple electronic products, where it was used for similar serialisation and part numbering purposes. It actually looks like a monospace version of http://www.identifont.com/find?font=code&q=Go

I wonder if Apple actually designed this font, or just asked for permission and extracted it from the built-in font of some industrial printing machine.

That font is extremely different from the one Apple is using. Compare the Q and K for the biggest differences that wouldn't be effected by 'monspacifying' it.

Wow this is really cool! So how do you get the promo codes at all? Do you buy those through an API?

Are you considered Apple will shut you down somehow?

You can generate promo codes on iTunes Connect. They're fairly limited: you can only get 100 promo codes per app version, and you're not allowed to use them for commercial purposes.

As long as you're not selling these cards, I don't think Apple would have a problem with them.

Interesting.

I have no idea if this is within the rules, but another option could be to use the "Gift This App" function to generate paid, non-expiring promo codes instead (send it to yourself). You'd incur the 30% App Store revenue cut this way in addition to any sales tax.

That's an interesting idea. I wonder what Apple would think. On one hand, they still get their cut. On the other hand, they like having full control over the experience. On the gripping hand, how could they even stop it?

... by kicking you off the store?

Possibly. But unlike standard promo codes, you could easily do this from a separate account that's not in any way linked to your developer account.

Because if there's one thing we've learned, it's that developers doing things they're not supposed to do on the App Store always do a great job of keeping their "black hat" account separate and distinct from their "real" account.

Since apps are ranked in the App Store by revenue and number of apps sold, buying copies yourself could also be seen as ranking fraud, so I'd assume Apple wouldn't like it.

Starbucks used to have cards that would let you download individual apps that worked like this.

I think I remember that. Were they paid apps Starbucks had a deal with, or free ones?

I never saw it for apps, only music.

Lots of paid apps, games and even e-books, I have several cards for Monument Valley.

If you have an extra one and don't mind sharing, I've been waiting to get into stardew valley... If you could email it to me (in my profile page) I'd be so happy :)

Psst... He said monument valley, not stardew valley. :)

Bit of both. I downloaded some free apps via the cards but mostly they were paid app redemption codes (in-app purchases excluded, of course).

The program moved to the Starbucks app a year or so ago but seems to have stopped.

An old episode of Build and Analyze discussed participation in the Starbucks promotion: http://5by5.tv/buildanalyze/80

> Surrounding box, w/ proportions of the box (ratio 3 width : 1 height)

I don't understand this part. The aspect ratio of the box seems much more extreme than 3:1.

It is. I downloaded their image and it's like 540x128 or so. If it were 512x128 it would be 4:1, but it's slightly larger, like 4.2:1 (er... 21:5?). I was highly confused by that as well.

Any technical reason not to use a QR code?

Probably so it’s human readable.

Yep, since you can also manually enter the code.

Am I right in assuming that we could use this in our apps to do different things other than a promo?

I don't think so - it's only used when you trigger the Redeem Code action and you scan the code via camera ...

I can't catch that before it triggers a "call" to Apple to very the code and do something else? I'm thinking of rerouting to a feature inside my app that's special to users of that code.

Users redeem codes from inside the App Store app on their phone.

You can generate codes to give you app away for free, or to grant a free in-app purchase, but that is all. There's no callbacks from the app store to your app to intercept.

Possibly you could do what you want with QR codes and launch URLs, or by doing camera+OCR stuff yourself inside your app.

It's also likely a copyright violation to use that font file without permission.

Typefaces have never been copyrightable in the US, but digital fonts implementing a typeface have been since the early 90s.

This all sounds like it was done without duplicating the font itself (aside from installing it, which does make a copy in one of the Library/Fonts folders, but afaik that isn't been considered duplication for copyright purposes). And it could be done easily enough without even making that copy (a symlink would likely do it).

RedLaser had an barcode and QR code OCR framework you could license a while ago. Don't know if it still exists.

Can you build your rerouting function as part of an in-app purchase and then use the code to activate it?

> Or you could use Mail Designer Pro to share your promo codes, e.g. to send a nice promo code email to a journalist. It adds a bit of magic to the experience if your email is scannable

Yeah, sounds very convenient... How exactly would that work?

It's one step removed. You would use your phone to scan the email displayed on your computer.

Can someone explain what these promo codes are for? If they are just scanned by iTunes wouldn't you need to register them somehow in order for them to be useful?

A developer can generate these promo codes for their app, so a potential customer or reviewer can get a free copy of the app.

But surely if you just printed off a random code it wouldn't let you download the app for free?

It would, but only once.

I've never used one of these cards, but the one in the photo has a barcode on it. Why doesn't the software just read that instead?

That'll be the GTIN - what the store scans on their till when you buy it. It's the same on all cards of that type.

Is this the same font used by the (scannable) homekit activation keys, which are usually printed on the box/device?

Very cool stuff.

So does this mean that the iPhone camera is always awake and scanning for said box with code?!

No, see the image http://blog.equinux.com/wp-content/uploads/2017/07/scan-card...

No, it's only activated when you go to redeem a card in the iTunes/App Stores.

if you are worried about any of the sensors on your phone always being on, remember that Apple and Google need their relative OSes to make battery charges last as long as possible. So always on stuff is problematic. For a good user experience Bluetooth and wifi usually need to be on, but GPS, camera and microphone usually don't.

How is always-on useful for Bluetooth? In fact, it's a huge vulnerability if that's the case. On Android I simply turn it on to connect to something and off to disconnect.

You can do that on iOS too -- and discoverability is, as usual, a transient state that you invoke manually. So most people probably leave BT on, but not discoverable, most of the time.

GPS is basically always on - on iOS if you have a background location app, you're being located every 5 minutes at least.

For iOS the GPS chip itself is only turned on when 1) a foreground application is using location 2) a navigation app is using location and you task switch (that blue bar you get at the top) 3) for background location, when the device reassociates to a new cell tower

This isn't true, an app has to explicitly turn GPS hardware on. Almost all the time apps, foreground or background, get locations passively, which is done by triangulating cell tower positions, i.e. the location the phone already knows.

Reply on news.ycombinator.com