Bitcode. I just don’t buy it.

At WWDC 2015 Apple introduced the concept of Bitcode, which essentially means we will in future compile our code to an intermediary binary represetation (IR) and uploaded to this iTunes Connect in this device-agnostic form.

This has been sparsely publicized as an optimisation strategy for iOS and watchOS apps, allowing Apple to apply hardware-specific micro optimisations after your app has been released to the store.

Perhaps they will use it for this, but I call disinformation on the whole thing.

If you stop to think for a moment about what the introduction of Bitcode involves, you quickly see this makes no sense for micro optimisations that might shave a few nanoseconds off operations here and there on newer chips.

Off the top of my head, here are just some of the costs and risks of introducing Bitcode:

  • Deploying code the developers have not tested and verified themselves. Both a PR risk with customers and a risk in developer relations. A bad deploy could destroy a company’s reputation for quality.
  • Developing Bitcode itself and integration with developer tools will not have been trivial and is ongoing, increasing complexity.
  • Infrastructure costs of hosting and cross-compiling Bitcode to N platforms for every release version of an app – including old versions if a user has not updated for some reason (unless they force update to latest apps on device restore)
  • Infrastructure and development costs of changes to iTunes Connect to handle the batch processing of queued cross-compile jobs and most likely verifying cross-compiled builds still work and pass App Review (N+1 reviews per release?)

In short this must be a big and relatively expensive project, and yet it is apparently just to service small optimisations on future hardware — something that makes Apple no new money at all. The new device is already sold and likely already faster than the previous device the user had.

More substantial explanations could include devices coming with a new family of chips that run the IR or a single derivative of it directly. No cross-compile, Apple ships the same code the dev provided. Deploy the same code to every new device.

That in itself would not generate more revenue for Apple in any direct way, although there will be CDN cost savings from smaller binaries, which are not insignificant at Apple’s scale.

What about sharing of code between devices? You can imagine a gaming scenario where Tom has a game and friend Sarah and Pete want to play it together but do not have it. Tom starts the game and Sarah and Pete get a prompt “Tom wants to play game MEGAWHATEVER with you? Do you want to install it now?”. They answer YES and the game is transferred in seconds over wi-fi between the devices directly. Without having to get or buy the game (even if it is free) in the App Store. Couple that with Apple TV showing the actual game play and the devices acting as controllers with displays, and you have a pretty compelling iOS sociable gaming experience.

Far-fetched? Possibly. I’m not sure about it either. But I am sure this is not just about theoretical optimisations.

The Microsoft years – don’t be mad John

On episode 125 of ATP, John Siracusa was goaded into spelling out his hatred of Microsoft, where as a young Mac enthusiast he felt Microsoft unjustly “won” the personal computing market.

This was very interesting for me to hear as I had never really given it much thought. At that time in the mid 90s I was a Windows user because, pre-OS X, only crazy musicians or designers used Macs. Until Windows 95 came out, MacOS was arguably aesthetically better than Windows but was soon technically and visually crushed by Win95.
Read more →

Interview – “Revealed: Soundproof”

Our music practice app Soundproof has some cool custom user interface elements that we spent a lot of time getting right. The good people at Itty Bitty Apps interviewed me about this and how we use the excellent Reveal app to debug and design these elements.

You can find the interview here

You may find it interesting to find out a bit about how we work, and how Reveal is worth every penny if you’re an iOS developer. Buy it now if you haven’t already. It does stuff Xcode can only dream of.

Going deep with Accessibility in Soundproof

When we first released Soundproof we had to make the difficult decision to delay polishing our VoiceOver experience for accessibility users.

We had done some work on this already, but due to the nature of our custom UI elements such as the time scrubber and Count-In screen, the work was too much to complete first time around.

In hindsight, I really would like to have done this for the first release. It seems to be common that developers don’t bother with this until later, if at all, but it is extremely useful as it tells you things about your visual UI that you wouldn’t have considered. In short, it is a great test of your visual design.

Read more →

Logging in Swift without overhead in production

I recently wanted to start covering start writing all my new app code in Swift, but hit a big problem: I use CocoaLumberjack everywhere and its not ready for Swift yet. They are working on this right now for a 2.0 release.

I checked around github and it seems some good work is being done on this. However the missing piece was very important: because Swift lacks conditional defines and a macro preprocessor, all arguments and strings you pass to the log functions would be evaluated every time — even if you had the logging level set to exclude it, or totally disabled.

Read more →