Hacker News Reader

Comment by baldajan | Hacker News Reader

Anyone unfamiliar with how things currently work:

macOS and iOS use 2 different UI frameworks (CocoaTouch and UIKit, respectively). And this causes problems when trying to compile the source code between the two platforms. Ex: things like font and color are defined specifically in each framework (NSFont and NSColor versus UIFont and UIColor). If they combine these frameworks, it makes the design and maintenance of cross platform software a lot easier (it'll still be difficult), and the at the very least, you wouldn't have to stub out a bunch of class names and files.

BUT - the most important work is still on the developer to ensure that their app runs great on iPhone, iPad and Mac and has a cohesive UI that scales and takes advantages of the different technologies. It's no different from Responsive Web Design or the shift from iPhone to iPad (and vice versa).

View on HN

There is a private framework called UXKit that's been shipping with macOS for at least 2 years now. It's a UIKit API compatibility layer that sits on top of AppKit. Photos is built on it.

Photos is still very much an AppKit app.

UXKit is just a simple compatibility shim on top of AppKit. There are many like it, and there's nothing particularly interesting about UXKit except that it is used by the team that developed the Photos app.

If Apple intends to fully support universal Mac/iOS apps then they're going to need a whole lot more than an AppKit compatibility shim. Those apps will be UIKit top to bottom, which means a lot of new features will need to be added to UIKit (resizable windows, menu bar and menu commands, mouse handling, etc.)

> UXKit is just a simple compatibility shim on top of AppKit. There are many like it, and there's nothing particularly interesting about UXKit except that it is used by the team that developed the Photos app.

Yes, it is, but I think you're underestimating the value of a "compatibility shim". Sure, right now it's all backed by AppKit, but once developers are writing for this abstracted API it makes it possible for Apple to pull out the underlying AppKit implementation details and use a UIKit adaptation instead.

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.

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.

It's just Cocoa on macOS. Cocoa Touch is iOS (and tvOS and watchOS) and encompasses UIKit.

Correct. And the UIKit equivalent on macOS is called AppKit

There's also the aspect of the separate stores. If a developer wants to, they can today offer a single purchase that gives you an app that works on iPhones, iPads, Apple Watches, and Apple TV — but not Macs.

This. There's a thriving open source ecosystem around iOS that is largely unavailable to macOS developers because of fairly arbitrary and unnecessary API differences in frameworks.

Unifying the API will open a lot of doors for macOS devs to use iOS libraries and provide a boost to macOS development.

I think those thinking about UI convergence are missing the point, and it's doubtful that this is what Apple has in mind. Having unified APIs makes dev life easier, and having official linkages between desktop and mobile apps makes it easier to do things like document sharing between mobile and desktop versions, or sharing of purchases (so you don't have to buy the desktop/mobile version twice).

I think we'll also see an influx of great Mac apps as lots of engineering talent is currently trained to use UIKit (iOS).

Agreed, and also encourage development of desktop counterparts to popular mobile apps - if you can keep the vast majority of your business logic and middle-layers (and largely just have to implement new UI), that's a huge load off of dev teams.

I'm thinking things like a FB Messenger desktop app - certainly a lot easier to implement.

And hopefully even move some players away from the ever-popular not-quite-native desktop apps (looking at you, Slack and Spotify) towards more actually-native UIs.

> And hopefully even move some players away from the ever-popular not-quite-native desktop apps (looking at you, Slack and Spotify) towards more actually-native UIs.

That’s the dream, but I’m not optimistic. More than likely they’ll just add another target to their Electron/React app and call it a day.

Spotify on iOS isn't native either, isn't it?

Off topic, but there is a native app for FB Messenger available: https://fbmacmessenger.rsms.me/ . It’s great!

""Native""

True, I didn't realize it was a fancy wrapper.

> having official linkages between desktop and mobile apps makes it easier to do things like document sharing between mobile and desktop versions

You can do this already via iCloud Drive app folders.

“Apple Plans Combined iPhone, iPad and Mac SDKs to Create One Developer Experience” would have been a more accurate title.

I've built my own compatibility layer once that could hide the differences across Cocoa and UIKit. It was easier than I thought actually, though I made it only for the things that I needed and not more than that. It came down to mapping UIKit symbols on the Mac and also implementing the missing methods. You build and debug the app on iOS and then it compiles and runs on the Mac, that's all.

Apple’s Sprite Kit “sort of” does this with SKColor, etc. While you can still stumble across a surprising number of platform-specific variants even with those, it is definitely useful to have some simple common elements.

I believe you mean AppKit and UIKit.

>If they combine these frameworks, it makes the design and maintenance of cross platform software a lot easier (it'll still be difficult)

You seem to say this with some confidence. Could you list the things you know for sure will still be difficult? At a basic level isn't the only fundamental, guaranteed cross-platform difference taps vs mouse clicks? What else is "guaranteed" to be difficult, no matter what they do?

Reply on news.ycombinator.com