App Store Bit Rot

With Xcode 4.5 reportedly dropping support for armv6 binaries (iPhone Classic and iPhone 3G) and therefore deployment targets below iOS 4.3, actually continuing to use these devices gets increasingly harder.

Apple has half-baked measures in place that could alleviate this issue, but it appears to be broken.

Let’s say I’m using my iPhone Classic on iOS 3, and GreatApp 1.0 supports this hardware.

The developer decides to support iOS 6 and iPhone 5 using Xcode 4.5 and therefore has to drop armv6 support with GreatApp 2.0.

The device will not install the update because it’s incompatible. But iTunes on Mac/PC will download the update and replace the 1.0 .ipa on disk.

Now the device needs a restore from a backup. iTunes lost the 1.0 ipa. And the device is unable to get the older version from the App Store, because only the latest version is listed.

In iTunes Connect, there is an option to “indicate a legal issue with this version“. According to the wording on the page, this should make this version unavailable to redownload. This would also imply there was some way to access those old versions. But there is none.

Even when accessing the old purchase directly (viewSoftwareRedownload URL), the store seems to present only the latest version to the user, even if it’s incompatible.

With an ever-increasing number of older devices floating around, Apple should make sure customers have a way of restoring those devices to a somewhat usable state even when apps get their unevitable updates and drop explicit support for old devices.

The App Store should enable old devices to actually download the last compatible version of an app through the iTunes in the Cloud / iCloud mechanism, a.k.a. App Store / Updates / Purchased.

Developers should have a clear way of indicating which old versions should stay available. The “legal issue” indication is there already, but worded confusingly and apparently quite useless.

About APNs tokens and duplicate UDIDs

David Schuetz found the source of the leaked UDIDs by tracking the duplicate UDIDs in the file. Great find!

While the result was confirmed by BlueToad, his intermediary assumption about the APNs tokens is not correct.

Interesting. Just noticed there are UDID duplicates in that data dump, with multiple APNS tokens. Different app providers, or multiple regs?

UDID duplicates do not come from multiple app providers or multiple apps. Any production app on a single device will get the same token. E.g. Facebook and WhatsApp will get the same token on the same device at the same time.

Tokens change when

  • the user switches devices, regardless of restored backups
  • the user restores a device to factory settings and does not restore his old backup
  • (possibly some Apple certificate expires, maybe once every year or two, maybe at major iOS updates)

Tokens appear to be derived from some device specific data (maybe the UDID), a key applied at device activation, and possibly Apple’s certificate.

So the duplicates likely stem from development devices being restored to new OS versions, as is apparent from some of the device names as well. “iPad 4.2” vs “iPad 4.3.1” on the same UDID.

Another way of one device having multiple tokens at the same time is production vs sandbox environment. But at any one time, a device will not have more than those two tokens (in the App Store context, MDM may be another story).

Another interesting data point are identical APNs tokens on differing UDIDs in the data set. By all accounts, this should be impossible, as confirmed by Apple (iOS Dev Membership required).

iPad mini?

Q: Do we need to sand down our fingers to a quarter of their size to operate a 7″ or 8″ iPad, as Steve Jobs suggested in an Earnings Call in 2010?

The iOS Human Interace Guidelines say that some things do not change across all iOS devices, e.g.

The comfortable minimum size of tappable UI elements is 44 x 44 points.

There are two screen sizes on iOS: 480×320 and 1024×768 and they need to stay like that if Apple doesn’t want to break all three bazillion Apps.

Look up the physical display dimensions on the technical drawings on Apple’s site. They change by a millimeter or two across device generations, but they give you a good idea of how big the displays are.

On the iPhone/iPod touch, this translates to a minimum physical tappable size of:

(Display width / Horizontal point dimension) x minimum tappable size
(50mm / 320pt) x 44pt = 6,875mm

On the existing 9.7″ iPad:
(149mm / 768pt) x 44pt = 8,536mm

If one was to shrink the 1024×768 display from 9.7″ to let’s say 7″, the screen would have a portrait width of around 107mm.
(107mm / 768pt) x 44pt = 6,13mm

This would be 11% smaller than on the iPhone, on a device you usually hold at a far greater distance.

And at 8″:
(123mm / 768pt) x 44pt = 7,05mm
The 8″ display would come in at 160ppi, very close to the original iPhone at 163ppi.
This would actually match the physical size on the iPhone, and most apps adhering to the 44x44pt finger would still be operable without any changes.

A: No need to sand down your fingers.

Newsstand is for Written Content

German version here / Deutsche Version hier

NewsstandI tried submitting an app that plays back an audio podcast as a Newsstand app to benefit from the Newsstand-only features, true background downloading and dynamic covers. A long shot, I know, but someone had to try.

After two very long rounds of reviews and a App Review Board appeal, the app was rejected after 5 weeks for “not being primarily written content”.

This requirement could be implied by the way Newsstand looks and feels, of course. But nowhere in the semi-public review guide or in the dev agreements do they actually say it. When following the documentation’s requirements literally is not enough, Apple has to work on their public review guide. Developers need clarity up front about what is acceptable and what is not.

I have a feeling that there are a lot of obscure new guidelines in place at App Review and the documentation available to developers is very incomplete.

Another guideline that I was made aware of: “Don’t use wooden shelves for your Newsstand app.” Wooden shelves are for the Newsstand folder only. Oh, and iBooks. But you really don’t want to use shelves in your app. For magazines. Silly you.

Meanwhile, one-star rip-off apps claiming to provide services that are impossible under iOS (custom lock screens etc.) are on top of the sales charts.

Apps are the new channels, but meanwhile podcasting is getting shoved further back every year in the iTunes Store. Getting a little worried about Apple’s intentions there.

Right now, the podcast directory still is maintained, but I see this going the way of the dodo. If you don’t have your own app to distribute your content, sooner or later, you may be out of luck. (Need one? Ask us.)


NewsstandIch habe gestern Abend einen Anruf aus App Review bekommen: Der Content der Bits und so App erfülle nicht die nötigen Voraussetzungen für Newsstand. Newsstand sei für Magazine mit überwiegendem Textinhalt gedacht.

Die Frage, wieviel Prozent Text sein muss, und ob eine gewisse Menge Großbuchstaben nötig sei, habe ich mir dann doch verkniffen.

Meine zum Ausdruck gebrachte Kritik werde weitergereicht, sagte mir die Mitarbeiterin.

Warum überhaupt Newsstand?

Die Idee war: Bits und so kann im Hintergrund auf Wifi-Verbindungen geladen werden und ist schon in dem Moment bereit zur Wiedergabe, in der die Benachrichtigung zur neuen Folge angezeigt wird.

dictionaryNach der wortwörtlichen Interpretation der Review-Regeln ist Newsstand zu 100% für eine Publikation wie Bits und so geeignet. Bemüht man das Apple Dictionary zu Begriffen wie “periodical” und “magazine”, finden sich Definitionen, die auf Bits und so zutreffen.

Die Sendung erscheint regelmäßig, sie folgt dem Format einer Radio-Talkshow, sie enthält verschiedene aktuelle, redaktionell zusammengestellte Inhalte.

Was Apple nicht in die Regeln schreibt, allerdings stillschweigend durch die Review vollstreckt, ist der Zwang, nur text-zentrischen Inhalt zu vertreiben. Magazine, wie man sie an einem traditionellen Zeitungskiosk finden könnte. Dass das rückwärtsgewandt und irrsinnig ist, gerade für die Firma, die gerade die Zukunft der Verlagsbranche gestalten will, kann ich nicht verstehen. Auch bei Apple sitzen wohl Freunde des toten Baumes.

Diese Anforderung nicht in die Regeln zu schreiben, ist allerdings sehr zweifelhaft.

Auf den holprigen Start und die verqueren Anforderungen angesprochen, sagte mir ein Apple-Mitarbeiter: “I wouldn’t disagree.”

Für viele Feinheiten scheint es interne Richtlinien bei App Review zu geben, die nicht in den semi-veröffentlichten Regelwerken oder in den der Geheimhaltung unterliegenden Verträgen mit den Entwicklern stehen. Eine weitere Richtlinie und damit weiterer Ablehnungsgrund für Newsstand ist zum Beispiel: “Don’t use wooden shelves.” Kein Scherz.

Und selbst wenn Apple den Newsstand tatsächlich nur mit toten Bäumen füllen will, ist das noch kein Grund, Hintergrund-Downloads auf diese Kategorie zu beschränken. Es gibt genug Apps, die davon profitieren würden, selbst mit den gleichen Einschränkungen: Nur auf Wifi, nur einmal pro 24h. Technisch gibt es keine Einschränkung. Nur App Review setzt diese Bindung an die App Store-Meta-Kategorie Newsstand um.

Ich werde jetzt den Newsstand-Code aus der Bits und so App entfernen und so schnell wie möglich in den Store submitten, um endlich die seit Monaten fertiggestellten iOS5-Features an die Hörer zu bringen. Denn solange die Entscheidung bezüglich Newsstand nicht gefallen war, konnte ich kein Update in den Store bringen, ohne den Entscheidungsprozess abzubrechen.

Exporting from After Effects to H.264 using x264

When exporting an 8 bit After Effects composition to a lossy format, you may end up with gradients that show visible banding, and the lower the bit rate, the worse the banding.

You may get better results by upping the bit depth on the composition to 16 bits, but you still will be depending on the downsampling algorithm within the AE Render Queue, or Adobe Media Encoder. And you’re also stuck with the codecs exposed through those pieces of software.

If you want to use x264 to have finer control over your encode, especially at very low bit rates, and stay compatible with specific target devices, such as the iPhone or iPad, you will most likely face the problems of feeding 16 bit image sequences to x264 via mplayer, or use some unholy avisynth script, as x264 will not accept ProRes or any other higher bit rate format natively.

One possible solution for this problem is using the QuickTime x264Encoder component. It will work within After Effects’ own Render Queue, QuickTime Pro, or Compressor and will accept any input QuickTime accepts. So simply export your AE 16 bit sequence directly to H.264 using the x264Encoder component, or export it first to ProRes 4444, and feed it to x264 via the component, with a lot of x264’s options exposed.

Update: Surprisingly, the component also works reasonably well within Qmaster distributed encoding. You may want to experiment with multithreading within the component’s settings vs. multithreading in Qmaster, or both. Provided you have enough storage and RAM and a fast network, this works true wonders when encoding hours of video at a time.

Philipp und Philipp unterhalten sich

Philipp und Philipp unterhalten sich… mit Timo. Wertvolle TV-Unterhaltung mit Club Mate, Döner-Pizza und dem unvergleichlichen Videokassetten-Domino-Tag*

Philipp und Philipp unterhalten sich mit Timo

Gespannt auf die neue Sendung mit Timo Hetzel und Philipp Seidel? In den Newsletter eintragen und informiert werden, wenn die App erscheint.

* Ähnlichkeiten mit tatsächlich existierenden Domino-Tag-Fernsehformaten sind rein zufällig.

Server-side Auto Renewable Subscription Receipt Verification

Update 10/2011: Watch the WWDC 2011 video on in-app purchases. This clarifies some of the points in this post and introduces a handful of useful fields in the receipt.

I think Apple’s documentation on checking receipts for auto-renewable in-app subscriptions is a little sparse. I overlooked this paragraph when first reading the documentation and wasn’t aware of its ramifications.

In App Purchase Programming Guide:

The response also includes an additional latest-receipt field; if the user’s subscription is active and was renewed in a transaction that took place after the transaction you provided to the App Store, the latest-receipt field includes a new base-64 encoded receipt for the latest renewal for this subscription. Your server can use this new receipt to maintain a record of the most recent renewal.

Here’s a sample response where receipt and latest_receipt are identical, we’re inside the first subscription period.

Screen shot 2011-04-01 at 12.48.50

When your app is launched regularly, everything is just about the same as with good old-fashioned non-consumable subscriptions. The app receives restored transactions to verify via your server.

When the app isn’t launched, you may still want to be able to stay in sync with the user’s subscription, even when he is not running the app. You can have a scheduled task on your server that can periodically replay the last known receipt to Apple, and if the latest_receipt differs from the receipt you just sent, you can send it right back to Apple to get the latest renewal date.

latest_receipt_info is not documented, so it might be a safer bet to actually use latest_receipt’s contents.

Use the purchase_date within the latest_receipt to calculate the current subscription period. The length of time for every period is not contained within the receipt date, so you need to calculate it from your product_id or item_id.

By doing this, you can maintain accurate subscriber stats on the server or grant paying users web access to content originally purchased in the app.