Hacker News new | ask | show | jobs
by Duckton 3102 days ago
Precisely. People thinking this is to create one UI for both platforms are missing the point.

Just like you can have an app for iPhone, iPad and Apple Watch, all with their own UI to a more or less degree, you will now be able toinclude a macOS build as well.

2 comments

Shared Text and UI controls and libraries could be useful, but we need to consider the "one UI" given the title of the article "Apple Plans Combined iPhone, iPad & Mac Apps to Create One User Experience". That just screams Marketing Department Overreach to me, and I've arguments about this exact issue with sales and marketing people before.

The "one user experience" idea is a fallacy because the physical interfaces are so much different. There are definitely overlaps with typical phones, computers or TVs, but developers should embrace and accentuate the the differences, not try to force everything to the lowest common denominator.

For example, an iPhone has limited text input because of a small screen where the keyboard takes up almost half the space. However, it does have a great camera and a shit ton of useful sensors that no computer or TV ever will.

It's not like how apps get made is part of Apple's product marketing, if anything it's their developer outreach.

My money is on this being a developer focused update to fix the CocoaTouch/AppKit dichotomy, which will make it easier to develop a Mac version of your software alongside the iOS, watchOS, and tvOS versions. Spinning it as "combined iPhone and Mac apps" sounds like a misunderstanding on the reporter's part.

iOS has gotten a really large developer following with a ton of great apps. Not a lot of that has spilled back to the Mac side of things, but if the basic toolkit were compatible it would be easier for iOS devs to make the jump.

I think it's more likely iOS apps will run in a sandboxed emulator on the Mac. Xcode already does this, and it would trivial to build and bundle an emulated app for MacOS with the standard iOS build.

I can't see real unification happening. The platforms are just too different - not just physically, in terms of interface modality and available hardware, but in terms of design culture. For the most part, iOS apps have very little in common with Mac apps - and that will continue to be true even if Apple releases a series of Tablet Macs as the next evolution of the iPad Pro.

Going the other way makes even less sense. All the big content creation apps are monsters with hundreds of menu options and settings. There is zero chance of being able to port a functionally equivalent version to a device with a touch UI, a much smaller screen, and limited performance.

I hope this isn't based on a fantasy of being able to make everything look and work like Photos or Apple's office clone - because that will mean dumbed down apps on the Mac, and a total loss of faith in the Mac among professionals and power users.

> I think it's more likely iOS apps will run in a sandboxed emulator on the Mac. Xcode already does this, and it would trivial to build and bundle an emulated app for MacOS with the standard iOS build.

I would bet a large pile of money against that happening. Apple has been pretty adamant that iOS is for the touch interface and macOS is for the mouse/trackpad. They know an iOS UI doesn’t work well on a Mac.

If they wanted to do Microsoft style “universal apps” they would have done it years ago.

Xcode doesn't use an emulator. When you build for the simulator it's building an x86_64 binary that runs natively.

Also, to your other point (UI integration), my assumption is that you'll need to make a different UI for macOS than you do for iPhones (you have to do the same for iPads, IIRC, even if you're just creating a larger version of the existing iPhone UI).

So if you have a simple way of handling it, you end up with all of your core logic being shared between all versions, and multiple versions of the UI that you just hook up to your existing controllers.

But there's minimal non-trivial shared core logic, because the apps live in a different user space and do different things with different end goals.

You can port a Mac DAW to iOS - e.g. Cubase to Cubasis - but it's no longer the same product. Most of the features that make the desktop version so useful in a professional context are lost in translation, because iOS doesn't have the resources to support them.

So what do you gain by trying to merge development, except extra work and possibly extra confusion.

> That just screams Marketing Department Overreach to me,

Yeah, and doesn't sound like how Apple has done things in the past. More likely this is Reporter Doesn't Understand Technical Decision Overreach to me....and it worked ("made you look!")

Did a bunch of people let go from the Windows Phone 10 effort land at Apple?
It's not "one UI" as much as not reimplementing parts of the UI that don't change between macOS and iPad. Simplenote, for example, has a two-pane view, with a list of notes on the left and the selected note on the right, with a toolbar above the note. Don't reimplement the entire UI, implement only the diffs.

Like responsive web design, where you implement only the diffs between the phone and PC layouts of your site, while reusing things that don't change.