7 ms·

Anyone unfamiliar with how things currently work: macOS and iOS use 2 different UI frameworks (CocoaTouch and UIKit, respectively). And this causes problems wh

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).

jawngee 9y ago
It's just Cocoa on macOS. Cocoa Touch is iOS (and tvOS and watchOS) and encompasses UIKit.
- allwein 9y ago
  Correct. And the UIKit equivalent on macOS is called AppKit
Duckton 9y 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.
- jobu 9y ago
  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.
  - deleted 9y ago
    [deleted]
  - gumby 9y ago
    > 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!")
  - coredog64 9y ago
    Did a bunch of people let go from the Windows Phone 10 effort land at Apple?
  - wlesieutre 9y ago
    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.
    - TheOtherHobbes 9y ago
      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.
- kartickv 9y ago
  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.
mojuba 9y ago
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.
sjtgraham 9y ago
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.
- thought_alarm 9y ago
  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.)
  - saagarjha 9y ago
    > 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.
potatolicious 9y ago
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).
- _jn 9y ago
  I think we'll also see an influx of great Mac apps as lots of engineering talent is currently trained to use UIKit (iOS).
  - potatolicious 9y ago
    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.
    - saagarjha 9y ago
      > 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.
      - mantas 9y ago
        Spotify on iOS isn't native either, isn't it?
glhaynes 9y ago
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.
makecheck 9y ago
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.
Eric_WVGG 9y ago
“Apple Plans Combined iPhone, iPad and Mac SDKs to Create One Developer Experience” would have been a more accurate title.
blueprint 9y ago
I believe you mean AppKit and UIKit.
logicallee 9y ago
>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?

jawngee 9y ago

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

allwein 9y ago
Correct. And the UIKit equivalent on macOS is called AppKit

Duckton 9y 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.

jobu 9y ago
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.
- deleted 9y ago
  [deleted]
- gumby 9y ago
  > 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!")
- coredog64 9y ago
  Did a bunch of people let go from the Windows Phone 10 effort land at Apple?
- wlesieutre 9y ago
  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.
  - TheOtherHobbes 9y ago
    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.
kartickv 9y ago
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.

mojuba 9y ago

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.

sjtgraham 9y ago

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.

thought_alarm 9y ago
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.)
- saagarjha 9y ago
  > 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.

potatolicious 9y ago

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).

_jn 9y ago
I think we'll also see an influx of great Mac apps as lots of engineering talent is currently trained to use UIKit (iOS).
- potatolicious 9y ago
  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.
  - saagarjha 9y ago
    > 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.
    - mantas 9y ago
      Spotify on iOS isn't native either, isn't it?

glhaynes 9y ago

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.

makecheck 9y ago

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.

Eric_WVGG 9y ago

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

blueprint 9y ago

I believe you mean AppKit and UIKit.

logicallee 9y ago

>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?