All those companies are panicking, not because they are being left behind technologically, but they are being left behind in the buzzword war.
The simple fact of moving to 64-bit does little. It makes for slightly faster computations in some cases, somewhat higher memory usage for most programs, and makes certain programming techniques more viable. Overall, it's not hugely significant.
The ARM architecture changed a bunch of other things in its transition to 64-bit. An increased number of registers and a revised, streamlined instruction set make for a nice performance gain over 32-bit ARM.
Apple took advantage of the transition to make some changes of their own. The biggest change is an inline retain count, which eliminates the need to perform a costly hash table lookup for retain and release operations in the common case. Since those operations are so common in most Objective-C code, this is a big win. Per-object resource cleanup flags make object deallocation quite a bit faster in certain cases. All in all, the cost of creating and destroying an object is roughly cut in half. Tagged pointers also make for a nice performance win as well as reduced memory use."
[1] https://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-an...
The transition could have happen later, maybe, with not too much repercussion, but why not make the jump now, especially when you have a whole new OS engineered to take advantage of it?
"Adding it all together, it’s a pretty big win. My casual benchmarking indicates that basic object creation and destruction takes about 380ns on a 5S running in 32-bit mode, while it’s only about 200ns when running in 64-bit mode. If any instance of the class has ever had a weak reference and an associated object set, the 32-bit time rises to about 480ns, while the 64-bit time remains around 200ns for any instances that were not themselves the target.
In short, the improvements to Apple’s runtime make it so that object allocation in 64-bit mode costs only 40-50% of what it does in 32-bit mode. If your app creates and destroys a lot of objects, that’s a big deal."
https://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-an...
Processor word width has absolutely nothing to do with memory size. e.g. 8-bit processors regularly interface with 16-bit-wide memory buses, and 64-bit processors often allow use of 32-bit-wide pointers.
What the word width does affect is how much data can be processed by each instruction. Certain algorithms benefit immensely from this (you can easily double throughput), but the code needs to be written to take advantage of this (or at least, not to squander the advantage), and needs to be compiled to use 64-bit-wide registers.
Huh? How would you address high positions on your 8Gb memory with a 32 bits pointer that will overflow after 4Gb?
If the processor does have special pointer registers (e.g. 6502, 6809, 8086, AVR, etc.), you use those.
That's what happened on the desktop. I think Apple only shipped one generation of 32-bit Intel processors. Apple was shipping 64-bit CPUs for years when many Wintel computers were still on 32. So when it came time to say 'We're going 64-bit only' with Mavericks Apple left almost no-one behind. On the other hand Microsoft still supports 32-bit Windows 8.
Apple is preparing to make their lives easier in the future. For today's user, it's usefulness may not be too much higher than the level of a buzzword.
1. Think about designs like e.g. the Varnish cache versus squid where the latter team has poured an enormous amount of effort into features which allowed them to manage storage manually, work which is increasingly counterproductive when you can simply mmap() 4GB and let the kernel perform that complex, error-prone task for you while you focus on more interesting features.
We're less than one iteration of Moore's Law away from the 32-bit address space not being enough, even if you're just concerned about memory sizes of mobile devices. Getting this done doesn't seem particularly premature.