I look forward to this. However I hope that doesn’t mean that they start dumbing down mac apps.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple Plans to Let Developers Release Universal Apps That Work Across iPhone, iPad, and Mac
- Thread starter MacRumors
- Start date
- Sort by reaction score
in a way, we are all ready doing universal apps, my current app runs on all platforms and one code for all, but if they are merging the APIs to be one then that will make things easer, as today we have the likes of NSColor v UIColor, they is SKColor that works on both but if all NS became UI then that would be great, no more NextStep
Autodesk Graphic is pretty good, and Affinity Designer is coming out for the iPad.
Now THIS is fantastic. As an iOS/Mac developer, I’ve always thought it was ridiculous how different Apple’s frameworks for iOS vs. macOS are.
For example, building on something like a table view (a list) is completely different in macOS and iOS, the frameworks are unnecessarily different. It makes it very time consuming to port iOS software to the Mac because you end up having to completely rewrite so much UI code.
Apple has tried to bridge the gap and make Cocoa (Mac) and Cocoa Touch (iOS) more similar, but it doesn’t save you much time when you still have to rewrite so much functionality that should be the same. There are some differences in how a user interacts with a Mac application (file menu, keyboard shortcuts, right click, etc) but fundamentally a Mac & iOS application should mostly be able to share the same UI code.
[doublepost=1514171696][/doublepost]
Not only will this not mean Mac apps will get dumbed down, it actually means they’ll get even better because devs won’t have to waste a ton of time reinventing the wheel for UI code they already wrote for iOS (or visa versa).
For example, building on something like a table view (a list) is completely different in macOS and iOS, the frameworks are unnecessarily different. It makes it very time consuming to port iOS software to the Mac because you end up having to completely rewrite so much UI code.
Apple has tried to bridge the gap and make Cocoa (Mac) and Cocoa Touch (iOS) more similar, but it doesn’t save you much time when you still have to rewrite so much functionality that should be the same. There are some differences in how a user interacts with a Mac application (file menu, keyboard shortcuts, right click, etc) but fundamentally a Mac & iOS application should mostly be able to share the same UI code.
[doublepost=1514171696][/doublepost]
No, it doesn’t. It simply means that developers can focus on important stuff (polish) rather than having to reinvent nearly all of the code that should be very similar.
Not only will this not mean Mac apps will get dumbed down, it actually means they’ll get even better because devs won’t have to waste a ton of time reinventing the wheel for UI code they already wrote for iOS (or visa versa).
Last edited:
What are you trying to say? The fact that macOS used to run on powerppc (a risc architecture) doesn’t have anything to do with whether it will be ported to ARM in the future. Two RISC architectures can be as dissimilar as a RISC architecture is from a CISC architecture.
I’ve designed x86, sparc, PowerPC, and F-RISC chips, and they are all quite different from each other.
[doublepost=1514400541][/doublepost]
That would surprise me.
When apple goes arm (it will) it will go all in. And they will start with a replacement for the 12” MacBook and work their way up the line toward the pro machines over time.
[doublepost=1514400598][/doublepost]
Or vice versa
Do you know of the existence of an ARM emulator that is fast enough. All the ones I've heard about are far too slow.
Makes more sense to me that they take the intermediate llvm bytecodes (which they have since they control the App Store and the compiler) and simply compile them to x86 instructions.
But even more likely is they just go full in on arm.
There's a developer option for Xcode to upload bitcode during app submissions to the App store. So they may be doing that (recompiling from bitcode) already for armv7 versus arm64 app downloads, and perhaps even doing custom optimizations for their different arm64 processor microarchitectures. For all we know they've already been testing our iOS and Mac apps in the lab on x86-64 iOS test devices and arm64 MacBooks.
That being said Apple has the experience to do so. You designing the chips themselves may not have a direct cosality for the OS that operates on those chips as a pure 1:1 does it? Or is there the same sort of disparity you're claiming here?
The only x86 RISC architecture I know of was Opteron CPUs. Was there any others?
All I'm saying is that Apple has RISC OS architecture as experience so we should see a rapid transition, faster than what we say with PowerPC to Intel architecture.
I was a lead designer on opteron. It wasn’t risc.
And my point is that regardless of apple’s experience with powerppc, porting an OS from cisc to risc (or vice versa) is no harder than cisc to cisc or risc to risc. Far more important are whether both designs have the same endianness, similar memory addressing modes, similar security models, etc.
They don’t have that. Bitcode is not architecture-agnostic. It’s suitable for microarchitecture-level optimizations only.
[doublepost=1514426705][/doublepost]
They did not. iAd as an ad platform within apps is actually dead.
Bitcode encodes the LLVM IR. It’s intended for targetting to arbitrary architectures.
Interesting. I did forget about Endian part of the equation.
Little Endian vs Big Endian:
http://teaching.idallen.com/cst8281/10w/notes/110_byte_order_endian.html
PowerPC Instruction Set:
http://titancity.com/articles/ppc.html
The PowerPC: (this is why I surmise Apple has experience with ability to switch to an ARM based CPU.
- RISC based
- Can switch between big-endian and little-endian at runtime
- Fused multiply-add intruction (a ← a + b * c)
also seems that Arm based CPUs architecture support both little/big endian byte code ... and up to the manufacturer to set which or both when created (if I understand the literature correctly)?
https://www.quora.com/Is-ARM-big-endian-or-little-endian
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0432c/DDI0432C_cortex_m0_r0p0_trm.pdf
Article 5.1 in the PDF directly above states ...
Arm Architecture ...
https://en.wikipedia.org/wiki/ARM_architecture
64/32-bit architecture seems that Bi-Endianness is supported but with little endian as default.
So I'm very curious what would stop Apple from very quickly migrating macOS (ahem OSX) to a RISC based processor, being set as Big Endian (if thats what OSX is)?
EDIT Got my answer:
On the Macintosh platform, PowerPC-based Macintosh computers use big endian addressing, while Intel-based Macs use little-endian addressing.
Source: https://developer.apple.com/library.../WritingPCIDrivers/endianness/endianness.html
So ... yeah Apple having experience with RISC based PowerPC chips, although Big Endian in their day, can transition to Little Endian RISC based Arm chips fairly quickly. Jobs once said that one of OSX's mission statements was to be processor agnostic ... not sure if that was maintained since the "just in case" Intel transition ... but they have major experience in this field. If Microsoft can do it in less than 2yrs for Windows 10 then I'm sure Apple can as well.
Still a few years away.
Last edited:
No, it isn't intended for that.
https://news.ycombinator.com/item?id=10190571
Unless something changed between the introduction of Apple's use of Bitcode three years ago and now, Bitcode is a poor fit for architecture-agnostic code.
And that's ignoring the many native dependencies your code will directly or indirectly have.
This quote is a bit misleading. The IR can contain raw assembly but it need not. The ABI issue is real, but that’s an OS issue. The ABI can be (and presumably would be) identical on two cpu architectures if the same party is supplying the same OS for both. In other words the quote is conflating cpu architecture with OS architecture. I can’t take bitcode targeting iOS and expect it to run on Windows because the callng conventions, etc are completely different.
[doublepost=1514476971][/doublepost]
I’m not saying that Apple can’t do arm. They will. I’m just saying that the original post which said “they did risc before and therefore arm is easy” mis-states the problem because just saying that two chips are risc doesn’t mean they have any more in common that a random cisc chip and a random risc chip. ARM is more similar in a lot of ways to x86-64 than it is to, say, Sparc (e.g. sparc register windows), for example. PowerPC numbers the bits backwards from everything else. Writing an OS for one risc chip doesn’t give you a leg up on porting it to another (vs porting it to any other chip) unless the instruction set, memory addressing modes, etc. also happen to be similar.
Of course, having previously ported architectures you have a leg up because your code is probably now organized in a way that keeps code that needs to differ based on CPU in discrete locations. But that’s the case regardless of whether it was risc or cisc.
I ageee we need two different UI’s, but I think many people forget iOS is based off OS X. If you remember Steve Jobs said, “We start with a strong foundation. iPhone runs OS X.” This was before they named it.
So it really shouldn’t be hard to create one application and just add tweaks for touch screen.
[doublepost=1516286701][/doublepost]
I think it’s likely we’ll see an ARM MacBook and MacBook Pro and no more Intel in Laptops. Desktops will keep Intel for now.
[doublepost=1516286820][/doublepost]
They technically have one OS, just different UI. I doubt very much that is going to change.
Apple isn’t Microsoft, they’ll get this right.
[doublepost=1516286977][/doublepost]
I haven’t actually used Office on iPad, but is it not the full version?
[doublepost=1516287179][/doublepost]
You’re thinking Negative. There isn’t one app in the App Store that you wont, but this will allow Adobe to bring their software to the iPad Pro. Final Cut Pro X on the iPad Pro. Any app on the Mac could be brought to a platform that is easy to take with you on the go.
[doublepost=1516287389][/doublepost]
A universal app doesn’t mean a universal UI. Developers can make the same code in the background running things and have a different UI that scales for the device your on. Like Android is the same even though the Launchers are the different. It’s not like Samsung made a different Android then Google.
AppKit (the macOS UI framework) and UIKit (that of iOS, watchOS, tvOS) differ for two reasons. One is that AppKit is really quite old now (it comes from late-80s’ era NeXT days), and they had an opportunity in iOS to modernize without legacy concerns. This remains interesting — AppKit is now yet another decade older, and still substantially different in some needless ways.
The other, however, is by design. Keyboard and mouse is simply a different paradigm than touch. You can try to accommodate both, but it’s not that easy. Look at Windows 8 to see how Microsoft has been struggling. As of today, they still haven’t managed to move their big apps like Word to their modern shared framework (UWP).
Not by a long shot.
I can't add a ToC, edit styles, insert an image that's not from my Photos library, and hard link an external document for starters.
Microsoft way is one design for all. I’m willing to bet Apple’s way will be different.
[doublepost=1516498347][/doublepost]
That’s interesting. Office sucks on Mac anyway. Pages was my favorite writing app. Still is, mostly.
A few days ago it was announced that Office for Windows and Mac will be built using the same codebase. Not that that guarantees feature parity, but they should be a lot closer than previously.
My problem is how much it always lagged on my iMac(s). I can’t stand it. Taking a while to load is okay but once I start writing I should be able to do that without worrying about the computer not able to keep up with me. I could chalk it up to my older 2006 iMac but I had the same problem with my 2011 iMac, too.
So I always just used what wasn’t slow. Plus Pages it’s really easy to make beautiful documents.
It only means dumbing down Mac apps if developers choose to dumb down their Mac apps.