Hacker News new | ask | show | jobs
by 0x0 4024 days ago
Wow, that's quite a change! Is this some kind of intermediate LLVM language? Sounds very Java/.NET-like. I can see how it's nice for future proofing (i bet you can even change from ARM to x86 then!), but you're handing a lot of control and probably something much closer to the original source code over to Apple.

Is there a fundamental change of architecture planned for future iOS devices?

3 comments

http://llvm.org/docs/BitCodeFormat.html. Way closer to assembly than Java/.NET byte codes. Also potentially processor specific.

My guess is that it is future-proofing towards running iOS apps on Mac OS and/or running (parts of) iOS apps on the Apple Watch. It also might mean that Apple plans to make their own ARM extensions (for example, I suspect having the CPU know about tagged pointers, so that an 'add' instruction can do an indirection, if needed, might be an overall win)

Update: the release notes for the Xcode 7 Beta say:

"• Bitcode. Archive for upload to the App Store in an intermediate LLVM binary representation that the store can then optimize into the 64 or 32-bit executable to be delivered to customers."

This falls under a feature they call 'App Thinning'. It makes the App Store optimize an app for the device it gets installed on, CPU-wise and asset-wise, and also allows your app to download some resources on demand.

> also allows your app to download some resources on demand.

Oh boy; if this is the start of apps lazy-loading resources and code, I'm really excited. It's the largest barrier to signing in your account from any device.

There's new higher level stuff for downloading assets on the fly from the App Store, check out the new NSBundleResourceRequest class.
Oh ok. So would you need two sets of bitcodes to target ios32 and ios64? A lot of fundamental types like CGFloat have different sizes...
Would iOS32 be supported at all?
They say iOS9 will support iPhone4s so it must be?
Along those lines, John S. just tweeted "<whisper>ARM Macs…</whisper>" [1], which is interesting, as he also got the Open Sourcing of Swift right a couple of days ago.

[1] https://twitter.com/siracusa/status/608029277963972608

Interesting, although the open sourcing of swift feels more obvious than arm macs. Bitcode and app thinning are currently ios+watchos only. I think it sounds more likely for ios and especially the watch changing architectures in the future rather than a non-x86/64 osx. But I'm probably wrong.

What would be the selling points for an ARM MAC? Access to the iOS app store software library? (unlikely) Better battery usage? (maybe) Super cheap devices? (un-apple-like)

Changing archs has been done before but I don't see a rosetta for intel apps running smoothly on arm. Virtualizing windows and linux is another killer app for intel macs that would be missed for some.

You're giving up a lot of performance for that battery life, however, and I think it's probably premature to even think about ARM Macintosh for three years at the least, if ever.
You control the whole tech stack thus a good selling point would be a longer lasting battery.

Perhaps it's also a shot in front of Intel's bow.