Besides fused multiply-add, what is the point of ARMv7s?

This post is part of a series on why an iOS developer would want to add a new architecture target to his iOS app project. The posts in this series so far cover ARMv7, ARMv7s (this one), ARM64 (soon!).

You probably remember the kerfuffle when, at the same time the iPhone 5 was announced (it was not even shipping yet), Apple added ARMv7s as a default architecture in Xcode without warning. But just what is it that ARMv7s brings, and why would you want to take advantage of it?

One thing that ARMv7s definitely brings is support for the VFPv4 and VFPv3 half-precision extensions, which consists of the following: fused floating-point multiply-add, and half-precision floating-point values (only for converting to and from single precision, no other operation supports the half-precision format), as well as the vector versions of these operations. Both of these have potential applications, even if they are not universally useful, and therefore it was indispensable for Apple to define an ARM architecture version so that apps could make use of them in practice if they desired: had Apple not defined ARMv7s, even if the iPhone 5 hardware would have been able to run these instructions, no one could have used them in practice as there would have been no way to safely include them in an iOS app (that is, in a way that does not cause the app to crash when run on earlier devices).

So we have determined that it was necessary for Apple to define ARMv7s, or this new functionality of the iPhone 5 processor would have been added for nothing, got it. But what if you are not taking advantage of these new floating-point instructions? It is important to realize that you are not taking advantage of these new floating-point instructions unless you full well know you do: indeed, the compiler will never generate these instructions, so the only way to benefit from this functionality is if your project includes algorithms that were specifically developed to take advantage of these instructions. And if it is not actually the case, then as far as I can tell using ARMv7s… is simply pointless. That is, there is no tangible benefit.

First, let us remember that adding an ARMv7s slice will almost double the executable binary size compared to shipping a binary with only ARMv7, which may or may not be a significant cost depending on whether other data (art assets, outer resources) already dominates the executable binary size, but remains something to pay attention to. So already the decision to include an ARMv7s slice starts in the red.

Go forth and divide

So let us see what other benefits we can find. The other major improvement of ARMv7s is integer division in hardware. So let us try and see how much it improves things.

int ZPDivisions(void* context)
    uint32_t i, accum = 0;
    uint32_t iterations = *((uint32_t*)context);
    for (i = 0; i < 4*iterations; i+=1)
        accum += (4*iterations)/(i+1);
    return accum;

OK, let us measure how much time it takes to execute (iterations equals 1000000, running on an iPhone 5S, averaged over three runs):

ARMv7 ARMv7s
divisions 24.951 ms 25.028 ms

…No difference. That can’t be?! The ARMv7 version includes this call to __udivsi3, which should be slower, let us see in the debugger what happens when this is called:

0x3b767740:  tst    r1, r1
0x3b767744:  beq    0x3b767750                ; __udivsi3 + 16
0x3b767748:  udiv   r0, r0, r1
0x3b76774c:  bx     lr
0x3b767750:  mov    r0, #0
0x3b767754:  bx     lr

D’oh! When run on an ARMv7s device, this runtime function simply uses the hardware instruction to perform the division. Indeed, on other platforms such a function may be provided in a library statically linked to your app, whose code is then frozen. But that is not how Apple rolls. On iOS, even such a seemingly trivial functionality is actually provided by the OS, and the call to __udivsi3 is a dynamic library call which is actually resolved at runtime, and uses the most efficient implementation for the hardware, even if your binary only has ARMv7. In other words, on devices which would run your ARMv7s slice, you already benefit from the hardware integer division even without providing an ARMv7s slice.

Take 2

But wait, surely this dynamic library function call has some overhead compared to directly using the instruction, could we not reveal this by improving the test? We need to go deeper. Let’s find out, by performing four divisions during each loop, which will reduce the looping overhead:

int ZPUnrolledDivisions(void* context)
    uint32_t i, accum = 0;
    uint32_t iterations = *((uint32_t*)context);
    for (i = 0; i < 4*iterations; i+=4)
        accum += (4*iterations)/(i+1) + (4*iterations)/(i+2) + (4*iterations)/(i+3) + (4*iterations)/(i+4);
    return accum;

And the results are… drum roll… (iterations equals 1000000, running on an iPhone 5S, averaged over three runs):

ARMv7 ARMv7s
unrolled divisions 24.832 ms 24.930 ms

“Come on now, you’re messing with me here, right?” Nope. There is actually a simple explanation for this: even in hardware, integer division is very expensive. A good rule of thumb for the respective costs of execution for the elementary mathematical operations on integers is this:

operation (on 32-bit integers) + - × ÷
cost in cycles 1 1 3 or 4 20+

This approximation remains valid across many different processors. And the amortized cost of a dynamic library function call is pretty low (only slightly more than a regular function call), so it is dwarfed by the execution time of the division instruction itself.

Take 3

I had one last idea of where we could actually look for to observe a penalty when function calls are involved. We need to go even deeper: having these calls to __udivsi3 forces the compiler to put the input variables into the same hardware registers before each division, so the processor is not going to be able run the divisions in parallel, so let us modify the code so that, in ARMv7s, the divisions could actually run in parallel:

int ZPParallelDivisions(void* context)
    uint32_t i, accum1 = 0, accum2 = 0, accum3 = 0, accum4 = 0;
    uint32_t iterations = *((uint32_t*)context);
    for (i = 0; i < 4*iterations; i+=4)
        accum1 += (4*iterations)/(i+1);
        accum2 += (4*iterations)/(i+2);
        accum3 += (4*iterations)/(i+3);
        accum4 += (4*iterations)/(i+4);
    return accum1 + accum2 + accum3 + accum4;

(iterations equals 1000000, running on an iPhone 5S, averaged over three runs):

ARMv7 ARMv7s
parallel divisions 25.353 ms 24.977 ms

…I give up (the difference has no statistical significance).

There might be other benefits to avoiding a function call for each integer division, such as the compiler not needing to consider the values stored in caller-saved registers as being lost across the call, but honestly I do not see these effects as having any measurable impact on real-world code.

If you want to reproduce my results, you can get the source for these tests on Bitbucket.

What else?

We have already looked pretty far in trying to find benefits in directly using the new integer division instruction, what if we set that aside for now and try and see what else ARMv7s brings? Technically, nothing else: ARMv7s brings VFPv4 and VFPv3-HP, their vector counterparts, integer division in hardware, and that’s it for unprivileged instructions as far as anyone can tell.

However, when compiling an ARMv7s slice, Clang will apparently take advantage of this to optimize the code specifically for the Swift core (according these patches, via Stack Overflow). These optimizations are of the tuning variety, so do not expect that much from them, but the main limitation with those is that not that many iOS devices run on Swift, in the grand scheme of things. If you check the awesome iOS Support Matrix (ARMv7s column), you will see for instance that no iPod Touch model runs it, and that the iPad mini skipped it entirely (going directly from ARMv7 to ARM64). So is it worth optimizing specifically for the 4th generation iPad, the iPhone 5, and the iPhone 5C? Maybe not.

What compiling for ARMv7s won’t bring you

And now it’s time for our regular segment, “let us dispel some misconceptions about what a new ARM architecture version really brings”. Adding an ARMv7s slice will not:

  • make your code run more efficiently on ARMv7 devices, since those will still be running the ARMv7 compiled code; this means it could potentially improve your code only on devices where your app already runs faster.
  • improve performance of the Apple frameworks and libraries: those are already optimized for the device they are running on, even if your code is compiled only for ARMv7 (we saw this effect earlier with __udivsi3).
  • There are a few cases where ARMv7s devices run code less efficiently than ARMv7 ones; this will happen on these devices even if you only compile for ARMv7, so adding (or replacing by) an ARMv7s slice will not help or hurt this in any way.
  • If you have third-party dependencies with libraries that provide only an ARMv7 slice (you can check with otool -vf <library name>), the code of this dependency won’t become more efficient if you compile for ARMv7s (if they do provide an ARMv7s slice, compiling for ARMv7s will allow you to use it, maybe making it more efficient).

I need you

Seems clear-cut, right? Not so fast. Sure, we explored some places where we thought direct use of hardware integer division could have improved things, but maybe there are actual improvements in places I did not explore, places with a more complex mix between integer division and other operations. Maybe tuning for Swift does improve things for Cyclone too (which is represented by the ARM64 column devices in iOS Support Matrix), and maybe it could be worth it. Maybe I am wrong and Clang can take advantage of fused multiply-add without you needing to do a thing about it. Maybe I completely missed some other instructions that ARMv7s brings.

And most of all, I have not actually run any real benchmark here, for one good reason: I have little idea of the kind of algorithms iOS apps spend significant CPU time on (outside of the frameworks), so I do not know what kind of benchmark to run in the first place (as for Geekbench, I do not think it really represents tasks commonly done in iOS apps, and in addition I am wary of CPU benchmarks I cannot see the source code of). A good benchmark would avoid us missing the forest for the trees, in case that is what is happening here.

So I need you. I need you to run your app with, and without, an ARMv7s slice on a Swift device (as well as a Cyclone device, if you are so inclined), and report the outcome (such as increased performance or decreased processor usage, the latter is important for battery life). Failing that, I need you to tell me the improvements you remember seeing on Swift devices when you added an ARMv7s slice, or what were the conclusions of the evaluation to add an ARMv7s slice, what you can share of it at least. I need you to tell me if I missed something.

And that is why I am exceptionally going to allow comments on this post. In fact, they should appear immediately without having to go through moderation, in order to facilitate the conversation. But first, be wary of Akismet: if your comment is flagged as spam, try and rework it a bit and post again. Second, comments with nothing to do with the matter at hand will be subject to instant vaporization.

So have at it:

What benefits does the iPhone 5S get from being 64-bit?

Every fall, a new iPhone. The schedule of Apple’s mobile hardware releases has become pretty predictable by now, but they more than make up for this timing predictability by the sheer unpredictability of what they introduce each year, and this fall they outdid themselves. Between TouchID and the M7 coprocessor, the iPhone 5S had plenty of surprises, but what most intrigued and excited many people in the development community was its new, 64-bit processor. But many have openly wondered what the point of this feature was, exactly; including some of the same people excited by it, there is no contradiction in that. So I set out to collect answers, and here is what I found.

Before we begin, I strongly recommend you read Friday Q&A 2013-09-27: ARM64 and You, then get the The ARMv8-A Reference Manual (don’t worry about the “registered ARM customers” part, you only need to create an account and agree to a license in order to download the PDF): have it on hand to refer to it whenever I will mention an instruction or architectural feature.

Some Context

iOS devices have always been based on ARM architecture processors. So far, ARM processors have been strictly 32 bit machines: 32-bit general registers, addresses, most calculations, etc.; but in 2011, ARM Holdings announced ARMv8, the first version of the ARM architecture to allow ARM native 64-bit processing and in particular 64-bit addresses in programs. It was clearly, and by their own admission, done quite ahead of the time where it would actually be needed, so that the whole ecosystem would have time to adopt it (board vendors, debug tools, ISVs, open-source projects, etc.), and in fact ARM did not announce at the time any of their own processor implementations of the new architecture (which they also do ahead of time), leaving in fact some of their partners, server processor ones in particular, the honor of releasing the first ARMv8 processor implementations. I’m not sure any device using an ARMv8 processor design from ARM Holdings has even shipped yet.

All that to say that while many people knew about 64-bit ARM for some time, almost no one expected Apple to release an ARMv8-based consumer device so ahead of when everyone thought such a thing would be actually needed; Apple was not merely first to market with an ARMv8 handheld, but lapped every other handset maker and their processor suppliers in that regard. But that naturally raises the question of what exactly Apple gets from having a 64-bit ARM processor in the iPhone 5S, since after all none of its competitors or the suppliers of these saw what benefit would justify rushing to ARMv8 as Apple did. And this is a legitimate question, so let us see what benefits we can identify.

First Candidate: a Larger Address Space

Let us start by the obvious: the ability for a single program to address more than 4 GB of address space. Or rather, let us start by killing the notion that this is only about devices with more than 4 GB of physical RAM. You do not, absolutely not, need a 64-bit processor to build a device with more than 4GB or RAM; for instance, the Cortex A15, which implements ARMv7-A with a few extensions, is able of using up to 1 TB of physical RAM, even though it is a decidedly 32-bit processor. What is true is that, with a 32-bit processor, no single program is able of using more than 4 GB of that RAM at once, so while such an arrangement is very useful for server or desktop multitasking scenarios, its benefits are more limited on a mobile device, where you don’t typically expect background programs to keep using a lot of memory. So handsets and tablets will likely need to go with a 64-bit processor when they will start packing more than 4 GB of RAM, so that the frontmost program can actually make use of that RAM.

However, that does not mean the benefits of large virtual address space are limited to that situation. Indeed, using virtual memory an iOS program can very well use large datasets that do not actually fit in RAM, using mmap(2) to map the files containing this data into virtual memory, and leaving the virtual memory subsystem handle the RAM as a cache. Currently, it is problematic on iOS to map files more than a few hundred megabytes in size, because the program address space is limited to 4GB (and what is left is not necessarily in a big continuous chunk you can map a single file in).

That being said, in my opinion the usefulness of being able to map gigabyte-scale files on 64-bit iOS devices will currently be limited to a few niche applications, if only because, while these files won’t necessarily have to fit in RAM, they will have to fit on the device Flash storage in the first place, and the largest capacity you can get on an iOS device at the time of this writing being 128 GB, with most people settling for less, you’d better not have too many such applications installed at once. That said, for those applications which need it, likely in vertical markets mostly, the sole feature of a larger address space means 64-bit ARM is a godsend for them.

One sometimes heard benefit of Apple already pushing ordinary applications (those which don’t map big files) to adopt 64-bit ARM is that, the day Apple releases a device featuring more than 4 GB of RAM, these applications will benefit without them needing to be updated. However, I don’t buy it. It is in the best interest of iOS applications to not spontaneously occupy too much memory, for instance so that they do not get killed first when they are in the background, so in order to take advantage of an iOS device with more RAM than you can shake a stick at, they would have change behavior and be updated anyway, so…

Verdict: inconclusive for most apps, a godsend for some niche apps.

Second Candidate: the ARMv8 AArch64 A64 ARM64 Instruction Set

The ability of doing 64-bit processing on ARM comes as part of a new instruction set, called…

  • Well it’s not called ARMv8: not only does ARMv8 also bring improvements to the ARM and Thumb instruction sets (more on that later), which for the occasion have been renamed to A32 and T32, respectively; but also ARMv9 whenever it will come out will also feature 64-bit processing, so we can’t refer to 64-bit ARM as ARMv8.
  • AArch64 is the name of the execution mode of the processor where you can perform 64-bit processing, and it’s a mouthful so I won’t be using the term.
  • A64 is the name ARM Holdings gives to the new instructions set, a peer to A32 and T32; but this term does not make it clear we’re talking about ARM so I won’t be using it.
  • Apple in Xcode uses ARM64 to designate the new instruction set, so that’s the name we will be using

The instruction set is quite a change from ARM/A32; for one, the instruction encodings are completely different, and a number of features, most notably pervasive conditional execution, have been dropped. On the other hand, you get access to 31 general purpose registers that are of course 64-bit wide (as opposed to the 14 general purpose registers which you get from ARM/A32, once you remove the PC and SP), some instructions can do more, you get access to much more 64-bit math, and what does remain supported has the same semantics as in ARM/A32 (for instance the classic NZCV flags are still here and behave the exact same way), so it’s not completely unfamiliar territory.

ARM64 could be the subject of an entire blog post, so let us stick to some highlights:


Ah, let’s get that one out of the way first. You might have noticed this little guy in the ARMv8-A Reference Manual (page 449). Bad news, folks: support for this instruction is optional, and the iPhone 5S processor does not in fact support it (trust me, I tried). Maybe next time.

More Registers

ARM64 features 31 general purpose registers, as opposed to 14, which helps the compiler avoid running out of registers and having to “spill” variables to memory, which can be a costly operation in the middle of a loop. If you remember, the expansion of 8 to 16 registers for the x86 64-bit transition on the Mac back in the day measurably improved performance; however here the impact will be less, as 14 was already enough for most tasks, and ARM already had a register-based parameter passing convention in 32-bit mode. Your mileage will vary.

64-bit Math

While you could do some 64-bit operations in previous versions of the ARM architecture, this was limited and slow; in ARM64, 64-bit math is natively and efficiently supported, so programs using 64-bit math will definitely benefit from ARM64. But which programs are those? After all, most of the amounts a program ever needs to track do not go over a billion, and therefore fit in a 32-bit integer.

Besides some specialized tasks, two notable example of tasks that do make use of 64-bit math are MP3 processing and most cryptography calculations. So those tasks will benefit from ARM64 on the iPhone 5S.

But on the other hand, all iPhones have always had dedicated MP3 processing hardware (which is relatively straightforward to use with Audio Queues and CoreAudio), which in particular is more power efficient to use than the main processor for this task, and ARMv8 also introduces dedicated AES and SHA accelerator instructions, which are theoretically available from ARM/A32 mode, so ARM64 was not necessary to improve those either.

But on the other other hand, there are other tasks that use 64-bit math and do not have dedicated accelerators. Moreover, standards evolve. Some will be phased out and others appear, and a perfect example is the recently announced SHA-3 standard, based on Keccak. Such new standards generally take time to make their way as dedicated accelerators, and obviously such accelerators cannot be introduced to devices released before the standardization. But software has no such limitations, and it just so happens that Keccak benefits from a 64-bit processor, for instance. 64-bit math matters for emerging and future standards which could benefit from it, even if they are specialized enough to warrant their own dedicated hardware, as software will always be necessary to deploy them after the fact.

NEON Improvements

ARMv8 also brings improvements to NEON, and while some of the new instructions are also theoretically available in 32-bit mode, such as VRINT, surprisingly some improvements are exclusive to ARM64, for instance the ability to operate on double-precision floating point data, and interesting new instructions to accumulate unsigned values to an accumulator which will saturate as a signed amount, and conversely (contrast with x86, where all vector extensions so far, including future ones like AVX-512, are equally available in 32-bit and 64-bit mode even though for 32-bit mode this requires incredible contortions, given how saturated the 32-bit x86 instruction encoding map is). Moreover, in ARM64 the number of 128-bit vector registers increases from 16 to 32, which is much more useful than the similar increase of number of general-purpose registers as SIMD calculations typically involve many vectors. I will talk about this some more in a future update to my NEON post

Pointer size doubling

It has to be mentioned: a tradeoff of ARM64 is that pointers are twice as large, taking more space in memory and the caches. Still, iOS programs are more media-heavy than pointer-heavy, so it shouldn’t be too bad (just make sure to monitor the effect when you will start building for ARM64).

Verdict: a nice win on NEON, native 64-bit math is a plus for some specialized tasks and the future, other factors are inconclusive: in my limited testing I have not observed performance changes from just switching (non-NEON, non-64 bit math) code from ARMv7 compilation to ARM64 compilation and running them on the same hardware (iPhone 5S).

Non-Candidate: Unrelated Processor Implementation Improvements

Speaking of which. Among the many dubious “evaluations” on the web of the iPhone 5S 64-bit feature, I saw some try to isolate the effect of ARM64 by comparing the run of an iOS App Store benchmark app (that had been updated to have an ARM64 slice) on an iPhone 5S to a run of that same app… on an iPhone 5. Facepalm. As if the processor and SoC designers at Apple had not been able to work on anything else than implementing ARMv8 in the past year. As a result, what was reported as being ARM64 improvements were in fact mostly the effect of unrelated improvement such as better caches, faster memory, improved microarchitecture, etc. Honestly, I’ve been running micro benchmarks of my devising on my iPhone 5S, and as far as I can tell the “Cyclone” processor core of the A7 is smoking hot (so to speak), including when running 32-bit ARMv7 code, so completely independently of ARMv8 and ARM64. The Swift core of the A6 was already impressive for a first public release, but here Cyclone knocks my socks off, my hat is off to the Apple semiconductor architecture guys.

Third Candidate: Opportunistic Apple Changes

Mike Ash talked about those, and I have not attempted to measure their effect, so I will defer to him. I will just comment that to an extent, these improvements can also be seen as Apple being stuck with inefficiencies they cannot get rid of for application compatibility reasons on ARM/A32, and they found a solution to not have these inefficiencies in the first place, but only for ARM64 (and therefore, ARM64 is better ;). I mean, we in the Apple development community are quick to point and laugh at Windows being saddled with a huge number of application compatibility hacks and a culture of fear of breaking anything that caused this OS to become prematurely fossilized (and I mean, I’m guilty as charged too), and I think it’s only fair we don’t blindly give Apple a pass on these things.

So, remember the non-fragile Objective-C ABI? The iPhone has always had it (though we did not necessarily realize as the Simulator did not have it at first), so why can’t Apple use it to add an inline retain count to NSObject in 32-bit ARM? I’m willing to bet that for such a fundamental Cocoa object, non-direct effects start playing a role whenever attempting to make even such an ostensibly simple change; I’m sure for instance that some shipping iOS apps allocate an enormous amount of small objects, and would therefore run out of memory if Apple added 4 bytes of inline retain count to each NSObject, and therefore to each such object. Mind you, the non-fragile ABI has likely been useful elsewhere on derivable Apple classes that are under less app compatibility pressure, but it was not enough to solve the inline retain count problem by itself.

Verdict: certainly a win, but should we give credit to ARM64 itself?

Fourth Candidate: the Floating-Point ABI

This one is a fun one. It could also be considered an inefficiency Apple is stuck with on 32-bit ARM, but since ARM touts that a hard float ABI is a feature of ARM64, I’m willing to cut Apple some slack here.

When the iPhone SDK was released, all iOS devices had an ARM11 processor which supported floating-point in hardware; however, Apple allowed and even set by default Thumb to be used for iOS apps, and Thumb on the ARM11 could not access the floating-point hardware, not even to put a floating-point value in a floating-point register. And in order to allow Thumb code to call the APIs, the APIs had to take their floating-point parameters from the general-purpose registers, and return their floating-point result to a general-purpose register, and in fact all function calls, including between ARM functions, had to behave that way, because they could always potentially be called by Thumb code: this is called the soft-float ABI. And when with the iPhone 3GS Thumb gained the ability to use floating-point hardware, it had to remain compatible with existing code, and therefore had to forward floating-point parameters in general-purpose registers. Today on 32-bit ARM parameters are still passed that way for compatibility with the original usages.

This can represent a performance penalty, as typically transferring from the floating-point register file to the general-purpose register file is often expensive (and sometimes the converse too). It is often small in comparison to the time needed for the called function to execute, but not always. ARM64 does not allow such a soft-float ABI, and I wanted to see if I could make the overhead visible, and then if switching to ARM64 would eliminate the overhead.

I created a small function that adds successively 1.0f, 2.0f, 3.0f, etc. up to (1<<20)*1.0f to a single-precision floating-point accumulator that starts at 0.0, and another function which does the same thing except it calls another function to perform the addition, through a function pointer to decrease the risk of it being inlined. Then I compiled the code to ARMv7, ran it on the iPhone 5S, and measured and compared the time taken by each function; then the same process, except the code was also compiled for ARM64. Here are the results:

Inlined addition 6.103 ms 5.885 ms
Addition by function call 12.999 ms 6.920 ms

Yup, we have managed to make the effect observable and evaluate the penalty, and when trying on ARM64 the penalty is decimated; there is some overhead left, probably the overhead of the function call itself, which would be negligible in a real situation.

Of course, this was a contrived example designed to isolate the effect, where the least possible work is done for each forced function call, so the effect won’t be so obvious in real code, but it’s worth trying to build for ARM64 and see if improvements can be seen in code that passes around floating-point values.

Verdict: A win, possibly a nice win, in the right situations.

Non-Candidate: Apple-Enforced Limitations

Ah, yes, I have to mention that before I go. Remember when I mentioned that some ARMv8 features were theoretically available in 32-bit mode? That’s because Apple won’t let you use them in practice: you cannot create a program slice for 32-bit ARM that will only run on Cyclone and later (with the other devices using another slice). It is simply impossible (and I have even tried dirty tricks to do so, to no avail). If you want to take advantage of ARMv8 features like the AES and SHA accelerator instructions, you have to port your code to ARM64. Period. So Sayeth Apple.

That means, for instance, that Anand’s comparison on the same hardware of two versions of Geekbench: the one just before and the one just after addition of ARM64 support, while clever and the best he could do, is not really a fair comparison of ARM64v8 and ARM32v8, but in fact a comparison between ARM64v8 and ARMv7. When you remove the impressive AES and SHA1 advantages from the comparison table, you end up with something that may be fair, though it’s still hard to know for sure.

So these Apple-enforced limitations end up making us conflate the difference between ARM32v8 to ARM64v8 with the jump from ARMv7 to ARM64v8. Now mind you, Apple (and ARM, to an extent) gets full credit for both of them, but it is important to realize what we are talking about.

Plus, just a few paragraphs earlier I was chastising Apple for their constraining legacy, and what they did here, by not only shipping a full 64-bit ARMv8 processor, but also immediately a full 64-bit OS, is say: No. Stop trying to split hairs and try and use these new processor features while staying in 32-bit. Go ARM64, or bust. You have no excuse, the 64-bit environment was available as the same time as the new processor. And that way, it’s one less “ARM32v8” slice type in the wild, so one less legacy, to worry about.


Well… No. I’m not going to conclude one way or the other: neither that the 64-bit aspect of the iPhone 5S is a marketing gimmick, or that it is everything Apple implied it would be. I won’t enter this game. Because what I do see here is the result of awesome work from both the processor side, the OS side, and the toolchain side at Apple to seamlessly get us a full 64-bit ARM environment (with 32-bit compatibility) all at once, without us having to double-guess the next increment. The shorter the transition, the better we’ll all be, and Apple couldn’t do shorter than that. For comparison, on the Mac the first 64-bit machine, the Power Mac G5, shipped in 2003; and while Leopard ostensibly added support for 64-bit graphical applications, iTunes actually ended up requiring Lion, released in 2011, to run as a 64-bit process. So overall on the Mac the same transition took 8 years. ARM64 is the future, and the iPhone 5S + iOS 7 is a clear investment in that future. Plus, with the iPhone 5S I was able to tinker on ARMv8 way ahead of when I thought I would be able to do so, so I must thank Apple for that.

Let me put something while you’re waiting…

A short note to let you know that I am currently working on a copiously researched post about the big new thing of the iPhone 5S processor: 64-bit ARM, as well as related updates to keep “Introduction to NEON on iPhone” and of course “A few things iOS developers ought to know about the ARM architecture” up-to-date. I already have a lot of interesting info about that aspect of the iPhone 5S, either from experimenting on it or found online, and while searching I happened to stumble upon this post, which is so true and exactly what I’ve been practicing for so long that I wish I would have thought of posting this myself, so I’m sharing it with you here.

In fact, rather than compile then disassemble as in that post, I go one step further and compile to assembly (either use clang -S, or use the view assembly feature of Xcode:)

screenshot of part of the Xcode window, with the menu item for the view assembler feature highlighted

Indeed, sometimes I don’t merely need to figure out the instructions for a particular task, but also the assembler directives for it, for instance in order to generate the proper relocation when referencing a global variable, or sometimes simply to know what my ARM64 assembly files need to start with in order to work…

A highly recommended technique. Don’t leave home without it:

ARM Processors: How do I do <x> in assembler?

How Nintendo could release iOS games

So there have been a few exchanges lately in the Apple pundit sphere about whether Nintendo is in trouble with the 3DS and whether it had better start releasing games for the iPhone and iPad. I feel I would be out of my depth analyzing Nintendo’s woes (or lack thereof), but on specific points I feel like I can contribute.

First of all, my personal experience, for what it’s worth, mostly matches Lukas’: when my little sister got a Game Boy Color in 1998 or so, we all used it at home (including her), with only a few exceptions like road trips (where we would take a lot of things with us anyway). On the other hand, these days I use my Nintendo DS Lite during my daily commute, and it seems from various online and offline interactions that I am not alone; it is hard for me to tell whether Nintendo portable consoles are being displaced in that market: I do see a lot of people playing on their iPhones and Android devices in the commuter train, but would have (even part of) these people been playing on portable consoles instead were it not for smartphones? I have no idea. I would carry my briefcase during my commute anyway, but it is possible that others did take advantage of their smartphone to forego the portable console, and the briefcase/backpack/attaché-case along with it, for their commute, and therefore that for some the smartphone did in effect displace the portable console.

Now, on the matter of what Nintendo could do, I think that if they followed John’s recommendation and started releasing games for the iOS platform, success of such a strategy would have the odds stacked against it, at least if what they do is just release iOS games for the sake of releasing iOS games. Others went into some of the reasons why, but one factor I would like to add it that it would not sit well internally at Nintendo. Nintendo is a proud company. For starters, they have buried all of their predecessors and 80’s contemporaries, and by bury I mean that Nintendo (at least) drove them off the hardware business: Atari, Amstrad, Commodore, SNK (Neo Geo), and of course Sega, and this is but an incomplete list. And for those which did manage to keep releasing games, the results have been… I think I’ll go with “sub-par”. Now I think Nintendo would do better than these guys as a pure game developer, but it is easy to see why Nintendo employees would internally consider releasing games for iOS, even “a couple of $9.99 iPhone/iPad games to test the water”, to be losing face. Even if they were to present it to the outside as “giving a glass of ice water to someone in hell”.

As a result, if Nintendo were to work on releasing games for iOS, it would not have its best employees working on them, and it could even cause some of these to leave the company. Teams working on games for iOS would be considered turncoats by other parts of the company, with the possibility of turf wars and withheld cooperation from these other parts. What’s more, both technical and non-technical Nintendo employees working on these games would have to deal with Apple’s technical and policy rules of the iOS App Store, which are already frustrating to most iOS developers, so I let you imagine how much more they would be to people used to making the rules. Apple certainly is not going to bend the rules for Nintendo, regardless (or possibly because) of the “ice water” Nintendo would bring. In the end, that would cause some of these employees to question why they should be dealing with this stuff, and drive them to quit.

The comparison with iTunes for Windows is not apt at all. For one, by that point Windows was an incumbent; but more importantly, in general-purpose computing other network effects exist besides “more users attract more applications, and more applications attract more users”, so it was possible for Apple to convince its own people that it was worth it to stomach Windows development because it would help the iPod and even indirectly the Mac as well, and in the end it did. By contrast, with video gaming platforms there is very little of such secondary network effects, so for Nintendo employees to be working on games for iOS would be seen as playing for the other team. So I think it is too early for Nintendo to be seen releasing iOS games.

However, if Nintendo were to try releasing iOS games at this time anyway, one way they could do it which would dampen this factor (and maybe others) is by taking advantage of the iPhone to do things they could not do anyway with the 3DS. In particular, back in the day of the Game Boy and Game Boy Advance, Nintendo would sometimes release games featuring additional hardware in the cart, like Kirby Tilt’n’Tumble or Pokemon Pinball. But nowadays it is no longer possible, as the cartridge slot in the Nintendo DS and 3DS just does not reasonably allow anything to stick out like that. Lately I have been playing WarioWare Twisted, which packs a gyroscope and rumble (I mean, just look at that cart) and only ever uses the A button besides that, and thought it would be ideal for the iPhone, which features both. Now it turns out that the 3DS does have an internal gyroscope among other things, but as far as I can tell it does not have any rumble feature. So Nintendo could get a start on the iOS platform by releasing back catalog portable games that for one reason or another relied on a feature not present in the 3DS.

But releasing back catalog games does not a strategy make. So Nintendo could use this as a starting point to make new original games for iOS which they could not do on the 3DS. But probably not by relying on things like rumble or multitouch for these new games, as Nintendo might want to put them in their next handheld, and reserve games relying on these features to that console; instead, these games for iOS would rely on features less usual for games to use like the magnetometer and location services (to make augmented reality games for instance), as these features are not traditional gaming hardware features, and Nintendo could use them while keeping face and with less fear of squandering an opportunity of keeping such mechanisms exclusively for its next handheld.

And the (fictional) banner under which the team at Nintendo would do so, kind of like the Macintosh’s team pirate flag, could be WarioWare, Inc., the fictional company founded by the greedy character Wario and supposed to be behind the microgames in the WarioWare series of games. For a start because Nintendo has already played with Wario giving out a mock press conference or mock press release and fundraiser, then because the first back catalog game they would release this way would be WarioWare Twisted. But also because WarioWare games have always been quite… experimental, and this would merely be one more way to experiment, the new frontier for Nintendo. I am not even the first one to suggest the association.

And, well, okay, let’s admit it, it is also because I love the WarioWare microgames that remix old Nintendo games, and would love even more to see old Mac and Apple II games get the same treatment in a WarioWare for iOS: Oregon Trail (“cross!”), Zork (“get lamp!”), Ultima (“find the exit!”), Mystery House (“type!”), Alice (“capture!”), Lode Runner (“dig!”), Shufflepuck Café (“block!”), Beyond Dark Castle (“throw!”), Realmz (“cast!”), Ambrosia games and Escape Velocity in particular (“land!”), Glider (“escape!”), Marathon (“shoot!”), Factory (“dispatch!”), Jetpack (“dodge!”), or, heck, Visicalc (“calculate!”) or Hypercard (“flip!”)…

More on Mac OS X being the new Classic

In Mac OS X is the new Classic, I made some bold predictions about Apple’s operating system future, but forgot to attach some sort of deadline to these predictions. Allow me to repair this omission here by adding this: I believe Apple will announce to developers the operating system transition described in that blog post within the next five years, at WWDC 2018 at the latest. So if WWDC 2018 comes and goes and no such thing has been announced, you are free to point and laugh at me.

On the same subject, I omitted that not only I believe that Apple will allow Developer ID apps on desktop iOS, but I believe Apple will in fact allow distributions of desktop iOS apps without requiring developers to pay Apple for that privilege (either through a free certificate or no certificate needed at all), though, like with Mac OS X Mountain Lion currently, the default setting will likely not allow running such apps. This is in consistency with what I already expressed in my blog post about Developer ID.

Lastly, for those of you wondering, I finally remembered an example of behavior that apps ported to Mac OS X could technically get away with, but ended up “sticking out” among native apps including to the user base: drawing directly to the screen outside of full-screen mode. At the start of Mac OS X some games would do so, even in windowed mode, but it ended up being noticed, as it resulted in ugly interactions with the transparent on-screen volume and brightness change overlays, and then very bad interactions with Exposé; so as a result developers were pressured not to do so and by the time of Mac OS X 10.4 Tiger pretty much no newly released app was drawing directly to the screen. So the same way, Apple would not even need to mandate all aspects of what a good iOS desktop app would be, they can allow some things that are not completely iOS-like to allow developers to more easily port their apps, knowing that over time the community will ostracize such exceptions.

How can we know whether we can effect change from the outside?

Marco Arment thinks we can have some influence, however measured, over Apple through our writing (or podcasts or YouTube channels or other media, as the case may be); and I do think so too, but I have to wonder to which extent it is true, and as a consequence whether it is even worth keeping in mind.

The first issue is that we don’t know whether a decision was influenced by externally produced elements or not. As Marco wrote, Apple is not a waterfall dictatorship. But it is also a peculiar company, which has consistently eschewed “common wisdom” thrown at them (by the tech press in particular) for quite some time now, instead doing what they feel is best for them and for the user, and the least we can say it that it seems to have worked okay for them (so far). So by necessity Apple employees have, consciously or not, filters with which they dismiss many of these external opinions. Of course, we Apple developers are quite attuned to these filters, but on the other hand we are both users with slight delusions as to the representativity of our needs in the customer base at large, and also a party in relationship with Apple and as such are likely coming off as biased, especially on the subject of relation between Apple and third-party developers (iOS App Store policies come to mind, in particular). Paul Graham made me realize this when he wrote in Apple’s mistake:

Actually I suppose Apple has a third misconception: that all the complaints about App Store approvals are not a serious problem. They must hear developers complaining. But partners and suppliers are always complaining. It would be a bad sign if they weren’t; it would mean you were being too easy on them.

How do I convince an Apple employee, who I cannot hear, that my criticism of something does not (just) come from the inconvenience this something causes me as a developer, but comes from my belief this something causes subtle but important inconveniences for the user? I do not know. I mean, we still do not have trials on the iOS App Store after 5 years, for instance, so there has got to be some reason some of our pleas do not work.

Of course, I don’t expect an Apple representative to just go on the record telling that external opinions influenced this and that decision. Duh. But there are a variety of officious channels through which this could be hinted at. For instance, in the particular domain of Radar (Apple’s bug reporting tool) Matt Drance, formerly of DTS, gave a talk at C4 (scroll down to “Drance – How to be a Good Developer”) about your relation as a developer with Apple, in particular about Radar, giving information that I believe is not available anywhere else, and my thanks go to him for doing this talk, and to Philippe Casgrain for transcribing it and publishing his notes. As far as I know, no one who works or used to work at Apple ever talked publicly about the influence of external opinions the way Matt Drance talked about how radars are seen from the inside.

The second issue is that the tech community in general seems to be pretty quick at decreeing every Apple reaction as being the result of press coverage/public outcry/radar duplicates/etc., without any evidence (other than circumstantial) supporting that affirmation. The prime example being, of course, Apple’s eventual decision to release a SDK for the iPhone, which many developers will tell was because it had however many duplicates in Radar, while things couldn’t possibly have been that simple (personally I believe conversations over private channels between Apple and important software vendors, game developers in particular, played the main role in convincing the relevant Apple executives). Even for the example Marco gives, the replacement of Helvetica Neue Light by Helvetica Neue in current iOS 7 betas, I remain unconvinced: this could just as easily be explained by usual iteration of the design. The only instances where we can say with some credibility that Apple reacted to external influences are when they reversed their position on some app rejections (the Mark Fiore incident in particular comes to mind), and (along with some help from the FTC) when Apple renounced to their additions to Section 3.3.1. As a result it is hard to have a conversation in the tech community about what works when it comes to publishing opinions Apple employees see as valid; and since we are not going to have this conversation with Apple either, this leaves most everyone in the dark.

So as a result, I am going to keep writing my opinions here for my audience, but I am not going to pay attention to whether anyone at Apple actually could take them into account, as I do not want to worry over something of which I cannot know the outcome.

Mac OS X is the new Classic

Doing predictions about Apple is risky business. Heck, predicting anything in the tech industry is risky business, and people who did would generally like you to forget they did so at some point: as we know, being a pundit means never having to say you’re sorry.

I’m willing to risk some skin on one matter, however, which is that of Apple’s operating system future. In short: Mac OS X is the new Classic, and iOS will move over to non-touchscreen interfaces, the desktop, and x86, while taking on more Mac-like features. This might be unexpected on my part, critical as I have been here of many aspects of the new computing iOS in particular embodies (but also the Mac App Store, Gatekeeper, etc.). But while I am critical of these aspects, I am also lucid enough to realize, starting in particular when the iPad shipped, that iOS is a revolution, and that all computers will one day work that way.

The iPad revolution

I used to think that our “old world” user interfaces, while not perfect, could eventually be learned by a majority of the population; I did not believe that only stupid people refused to work with computers (I very well understand unwillingness or inability, which sometimes aren’t completely distinct, to deal with the necessary complexities of today’s computers), but I also believed that our current state in computing was as good as it could be given the constraints, and that eventually computer usage would become part of the basic skills, like literacy and mathematics. In fact, I still believe this could have happened with current computers given enough time.

But Apple has shown a much better way. The Mac and Windows PC of 2010 are pre-alpabetic writing systems; nice pre-alphabetic systems, mind you, that anyone could learn in theory, but in practice only a minority of scribes were literate. By contrast, iOS is the first alphabetic system.

During the iPad introduction, for the roots of the iPad Steve strangely chose to go back to the beginnings of Apple with the Apple II (including a rare reference to Woz), and the first PowerBook; strangely because what the introduction of the iPad corresponds the best to is the original Macintosh. Both are compact computers with completely different graphical interfaces first seen elsewhere (the Lisa/the iPhone), but which suddenly took a much broader significance, and were as a result derided for being for play and not real work. While it was not necessarily the Mac itself which succeeded afterwards, we all know where the ideas pioneered in the marketplace by the original Macintosh went.

What about the incumbents?

But does this mean that current operating systems will change to become more like iOS? I don’t think so, or, rather, for those which try and do so, I don’t believe it will work. As we have seen with Mac OS X, operating system transitions are as much about transitioning user expectations as they are about the technology itself. A change of this magnitude will require new operating environments that people can see with a new eye, rather than by modifying an existing OS where any change is perceived as grating, or may not really work unless most applications are on board.

For instance, in Mac OS X Lion Apple changed built-in apps to automatically save documents being edited, as well as adopt a number of new behaviors (for instance, when a document is set to be an attachment of an email, the application editing the document, if any, is asked to save its work to disk so that the document state the user sees in the editing application is actually taken as the attachment), and encouraged third-party applications to do the same. This is undeniably progress, think of all the aggregate amount of work that is no longer being lost because of a power failure or application crash, across all Mac users running Lion or later.

But many people (including noteworthy people) complained about a part of this change, which is the loss of the “Save As…” command. The very notion of that command, which is that you are currently engaged in modifications to a file that you intend to not apply to that file but instead write elsewhere, is deeply rooted in the assumption that the system does not write file modifications until you explicitly tell it to; and so “Save as…” is foreign, at best, in an autosave world, but at the same time people have gotten used to it, so are they wrong to be missing it? After some adjustment attempts, Apple eventually relented and added back full “Save As…” functionality, but I don’t know if they should have; in particular, I have not checked to see how it interacts with the “attach to an email causes a save” feature.

Speaking of this feature, what do you think happens when someone uses it with, say, TextEdit documents currently being edited and it works as expected, and then uses it on an unsaved Word document (assuming Word has not been updated with that feature)? The last saved version gets attached instead of what the user expects, and he only knows about it when his correspondent replies with an inflammatory email telling that there is nothing new in the document, what have you been doing all this time? As a result, the feature will be poisoned in the mind of the user, who will adopt paranoid and near-superstitious steps to ensure the latest version always gets used in attachments. A feature that works unreliably is worse than no feature at all.

Another such problematic change is auto-quitting applications that are not topmost and have no document open. What is the issue here? After all the application has no visible UI in this case, and when recalled it would behave the same way (typically, by showing a new untitled document) whether it was auto-quit or not. Except this is not actually transparent at all: the application as a result disappears from the command-tab interface, most notably, so when the user wants to switch back to it using command-tab, he can’t.

What about the feature of saving the list of applications running upon shutdown, and reopening them upon restart (which in turn causes them to restore their open windows and state if they support it)? But there is a problem with that: applications can still veto a shutdown, so if half the applications have quit, but one prevents the shutdown at this point, once you have cleared the situation with the reluctant app when you shut down again only the list of applications still running at this point is saved and will get restored. So, oops, the feature only partially and inconsistently works, which I argue is worse than not having the feature at all.

Etc, etc. The list goes on. Now as John Siracusa ponders in his Lion review, users are expected to look down on applications (or mechanisms, like command-tab) that ruin the experience for everyone else, but it is not necessarily easy for the average user to make the correct connection, especially when the failure (wrong attachment, incomplete list of applications launched after the reboot) is removed from the cause. But even these cases are still easier to trace than what is coming next.

Copland 2010: Avoided

In Avoiding Copland 2010, John boldly (given, again, the risk inherent in doing so) tried to predict Apple’s operating system future, and referred to the situation of the Mac prior to Mac OS X, Copland being the failed attempt by Apple to provide the Mac a modern operating system. As he explained, what the “classic” MacOS lacked compared to Mac OS X was:

  1. systemic features: memory protection and preemptive multitasking,
  2. a modern programming framework: Cocoa with its object-oriented programming model, for the form present in Mac OS X,

the combination of the two being more than the sum of these parts. He then went on to try and find out the parallels which could be made between the Mac OS X of 2005 and the traditional MacOS of 1995, to figure out what Mac OS X would need in the future in order to stay competitive; but he focused on the second category on improvements, namely what kinds of programming paradigms Apple may need to adopt (such as functional programming, garbage collection, dynamic languages, etc.). I remember reading his article and being skeptical: after all with memory protection and preemptive multitasking in Mac OS X, applications were now isolated from each other, so from now on whatever the need for new operating system functionalities needed to stay relevant (be it systemic features or a better programing framework), applications could adopt them individually without having to have the others on board, so no clean break similar to Mac OS X would ever be needed in the future.

Of course, I was wrong. But not because a better programming framework turned out to be necessary (I don’t feel there is much competitive pressure on Apple on this front); rather, I forgot the one big globally shared entity through which applications can still interfere with each other: the file system. So a new clean break is likely needed to provide sandboxing, the systemic feature to solve the situation. With sandboxing, applications… well, I hesitate to say that they would be properly isolated, because I now know better than to proclaim that, but they certainly would be better isolated by an order of magnitude.

And on the sandboxing front, Apple is certainly among the most competitive, if not in front (at least as far as client software is concerned)… thanks to the iPhone, which was sandboxed from day one. Thanks to a hardware opportunity a few years prior, Apple already has in house the production-quality, shipping operating system with a third-party software ecosystem, ready for the challenges of the 10s; compare to when they had to buy such a system from NeXT in the 90s. This time Apple is ready.

Playing in the sandbox

I have not yet shown why sandboxing is so necessary; it certainly is less obvious than for memory protection and preemptive multitasking. Doing so would take an entire post, but I should mention here two advantages: the mysterious file system, and privacy. For the first, it may be hard for us nerds to realize how mysterious the file system, or at least some aspects of it, is to the average user, what with it mixing the operating system, applications, user files, downloads, and the like. Why did this folder for a game (containing, as it turns out, game saves) suddenly appear in the Documents folder? And so forth, and I am sure many such interactions that I don’t even think twice about and no longer realize any more, are instead frustrating mysteries for many users. Sandboxing would put an end to that.

As for privacy, you may say that you trust the software installed on your machine. But that’s the thing: you need to trust something entirely before you install it as a Mac app, there is no way to benefit from an application that is useful yet in which you do not have entire trust. Contrast that with the web, which is the platform actually challenging Apple the most in this area: with its same-origin restrictions, the web already has a strong sandboxing model which allows people to use Facebook and a myriad of other services, easily adopting a new one with low commitment and low friction, confident that the service only knows what the user entered in it (granted, the myriad of “like” buttons on the Internet mean that Facebook is aware of far more than what users explicitly tell it, but that’s between Facebook and the sites integrating the “like” button; sites can choose not to do so). Apple needs sandboxing in order to stay competitive with the web.

Of course, you have probably noticed Apple actually tried to retrofit sandboxing on Mac OS X. When I heard that Lion would feature application sandboxing, I tried to imagine how such a feat could be possible while keeping the Mac file usage model, and thought that they would have to turn the open and save panels into a privileged external application, which upon selection from the user would grant the sandboxed app the right to operate on the file, while keeping API compatibility, no small feat. Which is exactly what they did. Impressive as it may be, I feel this effort to maintain the “all files mixed together” file system while adopting a sandboxed underlying infrastructure will eventually go to waste, as Apple will need to build a new user model eventually anyway to go with the sandboxed infrastructure (for instance, users could rightly wonder why a file “just next” to one they selected is not automatically picked up, say the subtitles file next to a movie file), a new user model where documents of each app are together by default, and “all files mixed together” is for specific scenarios for which there could be a better UI.

And on a software development standpoint, the retrofitting of sandboxing on Mac OS X has been less that stellar, with deadlines pushed multiple times, Apple needing to implement scenarios they had not foreseen but turned out to be so important for users that apps would not ship without it, like security-scoped bookmarks, notable app developers publicly giving up on sandboxing, other apps having to become clunkier or losing features in order to adopt sandboxing… All for little benefit since, as far as I can tell, an unsandboxed app can still read the data stored by sandboxed apps.

The Mac OS X transition model

In theory, Apple could have introduced Mac OS X in a less disruptive fashion. Instead of pushing it to consumers when they did, they would have kept Mac OS X 10.1 and 10.2 to developers only, while encouraging them to ship carbonized applications. Then for 10.3 with a sufficient number of Mac OS X-optimized apps around, they would have introduced it to consumers as simply the evolution of MacOS 9 and minimal cosmetic changes, with carbonized apps and new Cocoa apps running natively, and other apps running in a completely transparent Classic environment, and the users would have benefited from a more stable operating system without any visible transition.

But in practice, that would have of course never worked. There are numerous reasons why, but foremost is the fact third-party application developers are not perfectly cooperative. They are ready to listen and adopt Apple initiatives, but there had better be some sort of immediate payout, because otherwise they are spending time, and thus money, changing their code while adding exactly zero feature. So developers would have waited for Apple to ship Mac OS X in order to carbonize their app, otherwise what’s the benefit in a MacOS 9 environment, and Apple would have waited for a critical mass of carbonized apps before shipping Mac OS X to consumers. Uh oh.

Instead, by shipping Mac OS X 10.0-10.1 to early adopters, then progressively to less early adopters, Apple provided right from the start an incentive for developers to ship carbonized apps, first some specialized developers would have enough of their audience using Mac OS X for them to be worth it, then more and more developers would find it worthwhile to port, etc. More importantly, early adopters and early applications would actually set up expectations, instead of incumbents setting them in the case of a “progressive” transition, so that if an app got ported technically, but not in spirit (say, it would use a lot of resources), it would stick among the ported apps and it would be pressured to fit to the new standards. And playing just as important a role, the Classic ghetto clearly marked which apps would all together go down whenever one of them would crash, making sure to mark the boundaries of the negative network effects/broken windows (where a minority of apps could ruin it for everyone else). The Aqua interface was an essential part of this strategy, being no mere eye-candy, but eye-candy that coincided with a major OS environment change and helped mark it for average users.

Drawing directly to the screen, as I added in a clarification, is a good example of behavior that characterized a Mac OS X app that was not ported in spirit, and that these apps were pressured to drop. — September 3, 2013

By contrast, what Apple is currently doing with the “iOS-ification” of Mac OS X is merely add superficial enhancements from iOS to a system whose behavior is still fundamentally defined by existing users and existing applications, a system which has to stay compatible with existing installs, existing peripherals, existing workflows, existing mechanisms, etc. Mark my words: history will look back at the recent “iOS-ification” of Mac OS X as as quaint and superficial and meaningless as the Mac-like interface of the Apple IIgs.

Mac OS X as the Classic of iOS

I expect that Apple will soon realize that trying to drive Mac OS X toward having all iOS features is a dead-end. And some setback or other, leading to cost-saving measures, or just their obsession with efficiency, will make them suddenly question why the heck they are spending effort maintaining two operating systems in parallel. I do not think Mac OS X and iOS will merge either; this kind of thing only happens in tech journalists wet dreams. There will be no Mac OS XI, instead my prediction is that the Mac will have a new OS, and Mac OS X will run in a Classic mode inside that OS. But Apple already has a new OS, it’s called iOS, hence that new OS would be a “port” of iOS to the desktop, called… “iOS”.

So in practice, this would allow Apple to provide an incentive to applications adopting modern features like sandboxing and a more modern interface (larger click/touch targets, etc.), by having them run outside the Mac OS X ghetto and inside iOS instead, and thus for instance making their data impossible to read from a an app running inside that ghetto; and I am sure other such immediate incentives are possible, given the benefits of sandboxing to users. Currently Apple can get some applications to adopt sandboxing thanks to their clout, embodied in the Mac App Store, but application developers resent it, there has to be more positive ways of encouragement. Also, the “iOS-native” area would be, again, defined by the early adopters (here, in fact, the existing mobile iOS apps, see later), so applications not having, for instance, autosaving would quickly stick out and be pressured to adopt it, if it wouldn’t be mandatory in the first place in order to run outside the ghetto.

Meanwhile, the new Classic environment, with Mac OS X running inside, would allow users to keep using “legacy” Mac OS X apps during the transition, exactly the same way the Classic environment of Mac OS X eased the transition from MacOS 9. The current Mac OS X interface (which only has a passing resemblance to Aqua at this point) would be the new Platinum, a ghetto inside the world of the native iOS interface, which would play the role of the new Aqua.

Now given all the speculation about Apple potentially adopting ARM chips for future MacBooks, or Apple potentially using Intel chips in future mobile devices, I think it is important to clarify what I am talking about here. I expect Apple to keep using the most appropriate chip for each device class, which for each existing Apple product line is still ARM chips for tablets and smaller, and Intel chips for the MacBook Air and up, and I don’t expect it to change in the short run (Intel and ARM chips are just now starting to meet in the performance/power point in the no-man’s land between the two device classes).

So I expect iOS, for the purpose of running on laptop and desktop class devices, would be ported to x86. This is not much of a stretch, extremely little of one in fact because first, iOS already runs on x86 (at the very least, the whole library stack and some built-in apps), and second most iOS App Store apps do already run on x86, both thanks to the iOS Simulator. This unassuming piece of iOS app development, including the iOS runtime environment, indeed runs natively on the host Mac, without any processor emulation involved, and iOS apps need to be compiled as x86 to run on it. As many iOS app development processes rely on running the app on the iOS Simulator for convenience when debugging, better debugging tools, easier and faster design iteration, most iOS apps are routinely compiled and work on x86, and would easily run on the x86 iOS port; and Apple, having most of iOS running on x86 already, would have little trouble porting the remainder of iOS, it could even once ported be installed on Macs shipping today and not require new machines.

What would the interface for iOS on the desktop be? I can’t remember in which Apple product introduction this was mentioned, but the host mentioned that touching a vertical desktop screen did not work in practice, and neither would it be practical to read and view a horizontal desktop screen — and that they had tried. So while some are clamoring for iOS to come to the laptop (and desktop) form factor so that we can finally have large touchscreen devices, they are misguided: if it was technically possible, then Apple would already have done it on the Mac, with Mac OS X. Maybe this will happen some day, but this would happen independently of iOS running on desktop class devices.

Instead, as using a touch interface with a mouse is at least tolerable (as opposed to using an interface meant to be used with a mouse on a touchscreen device), iOS on the desktop could be used, at least its basic functions, with a mouse, but in fact a Magic Trackpad would be recommended (and bundled with all desktops from that point on), as providing something of the best of both words: multitouch, and the ability to browse a screen much larger than typical finger movements using the typical mechanisms of acceleration, lifting and landing elsewhere, etc. Of course, since it would be a touch interface separate from the screen instead of a touchscreen, there would need to be a visible pointer of some sort; likely not the arrow shape we’ve all known and loved since 1984, as this arrow is meant to be able to click with pixel accuracy, which is antithetical with the iOS interface paradigm. Maybe something as simple as a circle could do the trick.

Now remains the most important and thorny question of how these laptops and desktops now meant to run iOS would be called; would we still call them Macs? I have no idea.

iOS would have to change, too

But just like Mac OS X was not Rhapsody, iOS, in order to run on the desktop and be an attractive target for current desktop apps and users, would have to adopt some Mac features. For one, the model of designing iOS apps specifically for each screen size clearly wouldn’t scale, there would have to be ways to have apps reliably extend their user interface; most of the infrastructure is there mind you, even with springs and struts a lot can be done, but there would have to be new mechanisms to better take advantage of space when available; think CSS media queries and responsive design for native apps.

But having apps themselves scale with the screen is only part of the challenge, with all that screen space we certainly would not use it to run one app at a time, so ways to have multiple iOS apps on screen a the same time would have to be devised. That would be an awful amount of work to define and implement this new on-screen multitasking model for the 21st century, no doubt about it.

Then iOS would have to adopt some sort of document filing system, of course, as well as Developer ID, because having all apps having to come from either the iOS App Store or Mac App Store would be untenable for a desktop machine with many uses, corporate ones in particular.

I believe Apple will in fact even allow unsigned apps, or something functionally equivalent, on desktop iOS, though maybe they will not be allowed to run in the default setting. — September 3, 2013

Then it would need the ability to specify different default apps for, say, browser or email, as well as more comprehensive systems for apps to communicate with each other, with services for instance, better URL handlers (with UI to specify the default in case more than one app claim support). iCloud that doesn’t suck, but that’s a necessity for iOS on mobile anyway.

Most significantly, iOS for desktop would need to support some Mac OS X APIs, possibly with some restrictions and dropped methods/objects (kind of like Carbon was to the Mac Toolbox), most notably AppKit, but not only it, though it is safe to say Carbon wouldn’t make the jump.

And Apple would need to add (meaningful) removable media support, external drive support, backup support on such a drive, support for burning disks, wired networking, multiple monitors, a Terminal app, a development environment, some solution to the problem of communal computing/multiple users, etc, etc.

It’s time

So, easy, right? Just a little bit of work. In all seriousness, that would be a big endeavor, bigger maybe than Mac OS X, and, like Mac OS X, iOS on desktop would probably require a few iterations to get right. And that’s why Apple, whatever they actually intend to do (because they will not keep maintaining two operating systems forever), should start the process by telling developers as early as possible; for instance Mac OS X was introduced for the first time in May 1998 (how time flies…), and wasn’t really ready to replace MacOS 9 until 2002 or so.

I initially forgot to put some sort of deadline with my prediction, this has been repaired: I think it will have been announced by WWDC 2018, in five years, at the latest. — September 3, 2013

So what do you think will happen? Even if I am completely off-base here, at least I hope I provided for some interesting reflection for you to think on the matter.

Parody week

Well, I hoped you enjoyed parody week last week on this blog. After the parody of the Old New Thing I posted Monday as an April’s fool, I admit I got a little carried away and posted a parody of Hypercritical Tuesday, a parody of Coding Horror Wednesday, and concluded with a fake parody of Fake Steve Thursday.

So of course these posts last week were not entirely serious. But… Let’s see, for instance, Did Apple just cargo cult the iPhone platform?; clearly, I would not use a cargo cult metaphor for the iOS platform, even with precautions, outside of a parodic context: “cargo cult” is a very specific and grave accusation that just does not apply to the iOS platform. But just because this was a not-really-serious, parodic post, does not mean it was only for laughs and entertainment: if you are not coming away from that post thinking there was a deeper message to it, then I have not done my job properly (hey, what’s this bold text doing here? Oh God Jeff is contaminating me). I think that good satire makes you laugh, then makes you think, and I hope I was up to that standard.

As always, thank you for reading Wandering Coder.

Good riddance, Google. Don’t let the door hit you on the ass on the way out.

This post is, in fact, not quite like the others. It is a parody of Fake Steve I wrote for parody week, so take it with a big grain of salt…

See here. Basically, the rockets scientists at Google have decided, after having used our WebKit for years in Chrome, that they, uh, suddenly did not need us any more and forked WebKit like the true leeches they are. Dude, we are the ones who found KHTML and made WebKit what it is, if it weren’t for us KHTML would only be known to three frigtards in west Elbonia and you would have had no engine to put in your hotrodded race car of a browser, so I guess, thanks for nothing, bastards.

Truth is, good riddance. Those know-it-alls at Google have been a pain in our ass ever since Chrome debuted. Where do I start? Like with V8. Oh God V8… I… uh…

Okay, I can’t do this. I can’t parody Fake Steve. I’ve got nothing on Dear Leader. He was pitch perfect, like, you would get the feeling the real Steve Jobs would be writing just for you in his secret diary, all the while being satiric and outrageous enough so that at some level you knew it was fake but at the same time the persona was so well maintained that you easily suspended disbelief and you could not help thinking Steve could have shared these opinions. And he was insightful, oh of course he was, like in the middle of some ludicrous story you would feel like you would be enlightened about the way the tech industry or the press or tech buyers worked, didn’t matter if it was made up because it was a way to thought-provoke us and make us think about how the sausage factory really worked inside. He was the perfect ying-yang of the old-school professional who has seen it all and who knows how it works behind the hype, and of the new media guy who can drop a bunch of paragraphs without a word limit on a whim on a subject he want to tackle, and is not afraid to try new things and new ways of storytelling. Favorites? Ah! Apple, the Old Borg, the New Borg, the Linux frigtards, the old dying press, these upstart bloggers, the consumers standing in line, PR flacks, software developers, no one was safe.

I can see him now, looking above me from wherever his is now, laughing at my pathetic attempt at reviving him, even for a minute. I know he is at peace there, meditating, waiting for his reincarnation, because oh yes, he will be reincarnated some day, in a different form: Fake Steve is buddhist too, he most certainly did not meet St Peter at the pearly gates, and he has unfinished business in this world, he was not done restoring a sense of childlike sarcastic wonder in our lives. I’m waiting, waiting for the day I will see a blog or webcomic or column, because Fake Steve has a sense of humor and may throw us all for a loop by reincarnating in the old press, or Twitter feed or animation (but not a Flash animation, there are limits), and I will see the telltale signs, the snark, the character play, the insightfulness, and I will think: “Yes, Fake Steve has been reincarnated.”

Meanwhile, Fake Steve, I know you are now in a better place and cannot come back as such, but if you could hear my prayer: Dan… has not been good lately, to put it mildly. So… could you try and inspire him a bit while he will be away from the echo chamber? Not for him to write as you, no, just so that when he eventually returns to us after having spent some time away from it all, he will write good things, no matter what they are. Because we can’t stand looking at him like this.

The Joy of Tech comic number 995: Yes, Virgil, there is a Fake Steve Jobs

Did Apple just cargo cult the iPhone platform?

This post is, in fact, not quite like the others. It is a parody of Coding Horror I wrote for parody week, so take it with a big grain of salt…

In The iPhone Software Revolution, I proclaimed that the iPhone was the product Apple was born to make:

But a cell phone? It’s a closed ecosystem, by definition, running on a proprietary network. By a status quo of incompetent megacorporations who wouldn’t know user friendliness or good design if it ran up behind them and bit them in the rear end of their expensive, tailored suits. All those things that bugged me about Apple’s computers are utter non-issues in the phone market. Proprietary handset? So is every other handset. Locked in to a single vendor? Everyone signs a multi-year contract. One company controlling your entire experience? That’s how it’s always been done. Nokia, Sony/Ericsson, Microsoft, RIM — these guys clearly had no idea what they were in for when Apple set their sights on the cell phone market — a market that is a nearly perfect match to Apple’s strengths.

Apple was born to make a kick-ass phone. And with the lead they have, I predict they will dominate the market for years to come.

But never mind the fact a similar reasoning could have been made of the Macintosh when it came out. What bothers me today is the realization Apple might have handled the opening of the iPhone platform like a cargo cult:

The term “cargo cult” has been used metaphorically to describe an attempt to recreate successful outcomes by replicating circumstances associated with those outcomes, although those circumstances are either unrelated to the causes of outcomes or insufficient to produce them by themselves. In the former case, this is an instance of the post hoc ergo propter hoc fallacy.

cargo cult phone

cargo cult phone by dret, on Flickr; used under the terms of the Creative Commons CC BY-SA 2.0 license

By which I mean that Apple decided they needed to open the iPhone as a development platform, but I wonder to which extent they then did so by giving it the trappings of a platform more than the reality of a platform: third parties can sell their apps for running on it, right? So it must be a platform, right? Well… And I don’t mean the APIs are the problem either, it’s more like… everything else:

  • Apple has a very restrictive idea of what kind of use cases third parties are allowed to provide solutions to: everything that does not fit their idea of an app is rejected, or is impossible. For instance, installing third-party keyboards is not possible on iPhone:

    But sometimes, an Apple product’s feature lands at the wrong side of the line that divides “simple” from “stripped down.” The iPhone keyboard is stripped-down.

    If you don’t like how Android’s stock keyboard behaves, you can dig into Settings and change it. If you still don’t like it, you can install a third-party alternative. And if you think it’s fine as-is, then you won’t be distracted by the options. The customization panel is inside Settings, and the alternatives are over in the Google Play store.

    This? It’s from Andy Ihnatko, in an article in which he explains why he switched from iPhone to Android. Andy. Ihnatko. When Mac users of 25 years start switching away from the iPhone, I’d be very worried if I were in Cupertino.

  • Even for these use cases third-parties are allowed to provide solutions to, they are quite restricted: when Apple added support for multitasking, in iOS 4, they more or less proclaimed they had covered for every desirable multitasking scenario, and have not added any since. This feels a tad preposterous to me that there would have been no need for even a single new multitasking scenario in the two years since.

  • Even when third parties can sell their wares, they do so at the pleasure of the king. Apple seems to consider iPhone developers to be contractors/authors developing solely for Apple purposes. And paid by commission. Without any advance. And without any assurance when they begin developing that their app will be accepted in the end.

  • Apple apps do not play by the same rules other apps do. They are not sandboxed, or not as much. They use private APIs off-limits to other apps. They get a pass on many iOS App Store restrictions. In short, Apple eats People Food, and gives its developers Dog Food:

    Microsoft has known about the Dogfood rule for at least twenty years. It’s been part of their culture for a whole generation now. You don’t eat People Food and give your developers Dog Food. Doing that is simply robbing your long-term platform value for short-term successes. Platforms are all about long-term thinking.

  • In the same spirit, Apple introduced iCloud, gave users the perception Apple did the hard work and that apps would merely have to opt in, sold it to developers as the best thing since sliced bread, then promptly went and not used it themselves in combination with er, the technology they have consistently recommended be used for persistent storage (while ostensibly supporting this combination), without giving the ability to audit synchronization issues either. And now it turns out, and people come to the realization, that iCloud Core Data syncing does not work. Shocker.

  • Apple even tried at some point to prohibit non-C programming languages for iPhone development, with a clear aim to ban a number of alternative development environments, not just Flash. But just like Apple cannot provide all the software to fulfill iPhone user needs, Apple cannot provide all the software to fulfill iPhone developer needs either. A platform is characterized not just an by ecosystem of apps, but also by an ecosystem of developer tooling and libraries behind the scenes. They ended up relenting on this, but if I were an iPhone developer, I would not be very reassured.

But wait, surely, that can’t be. Apple knows all about platforms and the value of platforms, right? VisiCalc, right? But that encouraged Apple to provide something that looks like a platform, rather than a platform. As for the iPhone not being Apple’s first platform, there is a school of thought that says Steve Jobs did not build platforms, except by accident; so according to this line of thought, the Apple II and the Mac became honest-to-God platforms not because of Apple, but in spite of Apple. And now for the first time we would get to see the kind of platform Apple creates when it actually calls the shots. It looks like a platform, sounds like a platform, has the taste of a platform, smells like a platform, walks like a duck platform… but the jury is still out on whether it is actually a platform.

There is a case to be made for reducing your dependencies. Apple clearly is not going to let anyone hold it back; but as incredibly skilled as the people working at Apple are, is “not being held back” going to be enough to keep up when Android, propelled by being a more complete and inclusive platform, will threaten to move past Apple?

Apple can still turn this around. Indeed, the issue lies not so much in these restrictions being present at first, than in so few of them having been lifted since then. The key, of course, will be in figuring out which ones they need to lift, and how to do so. And this will require Apple to reconsider the motions it does to bring cargo, regardless of the cargo these actions have brought, and instead focus on improving their limited understanding of what it is that actually makes a platform. In order to really bring in the cargo.