Hacker News new | comments | show | ask | jobs | submit login
Apple Plans Combined iPhone, iPad and Mac Apps to Create One User Experience (bloomberg.com)
350 points by uptown 5 months ago | hide | past | web | favorite | 262 comments



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


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?


Well, I hope they can learn from Microsoft's total failure to do this.

To be honest, I don't see a persuasive argument. In order for this to be worth the extra development time the company needs to have a big marketshare on both platforms - MS failed because they had zero footprint on mobile, and I think Apple will fail because they have a relatively small footprint on desktop. As a third party developer, is it really worth your time to make a native macOS app when the web is already very capable? In some cases I'm sure it will, but in the vast majority of cases you're going to need to make a web version anyway (for the huge number of Windows desktops out there), so a native macOS app just wouldn't be worth it.


Unifying the ui itself is less important than unifying the frameworks to build the ui.

Assuming that the effort is focused on making frameworks that simplify macOS development for folks trained as iOS developers, then this will have a large impact on native Mac development.


Microsoft failed because they had few developers for either the desktop or mobile version of the framework. The countless Windows apps did not become buildable on mobile. If Apple makes it easy to add OSX support to existing iOS apps, they will have a lot of success.


That, and the fact the new XAML UX framework can only be used by AppX apps that run in the sandbox. “Normal”, otherwise unconstrained Win32 programs can’t use it.


This decrease in capability seems to be a weakness with Mac App Store as well, that and the ramp up from 0% to 30% of purchase price.

As a user I personally prefer more powerful software and a more financially motivated developer; even when it makes buying more bespoke.


What are some alternatives to Mac App Store that give the developer the same services, like handling payment, including subscriptions, downloads, some DRM to prevent casual copying and updates, for less than 30%?

Last I checked, I had to assemble the above from disparate services, investigating each, integrating them, and paying for each, which doesn't seem like a productive use of my time or money.


That's not an answerable question in any universal way. 30% of what?

Assembling from disparate sources will have more of an upfront cost but cost less per purchase. So it depends entirely on your sales volume.


30% of the sale price, obviously.

Regarding your second point, interesting, seems like MAS is good to get started until the app reaches a certain volume.


The "buy once update forever" business model of the Mac App Store is the real financial burden, not the ~30% tariff. Dev houses need some residual income, esp in the relatively small Mac market.


My guess is this could be driving the divide between semantic and vanity versions. If a developer has a big new update that's fully backward compatible they'll still be tempted to bump the major version of it means they can justify selling it separately. (Assuming stores allow names with a numeric bump.)


Counter argument: there are many app store apps that I would use on my laptop if I could - Unit converters, resistor code calculators, etc. I use them on mobile, and I google those things, but I would probably buy certain iOS apps to only use them on desktop if they were available.


Man, you could almost see that in the old OS X Dashboard. In fact, the early Apple iOS apps looked like they took cues directly from some in-house dashboard apps. I thought for sure that one of these days one would be able to put iOS apps on the Dashboard. Dashboard’s gone, but this still might work out in some fashion.


The Dashboard isn't gone! You can still enable it in Mission control and can decide whether it is a separate space or an overlay. I still depend on it for about 10 different international clocks all the time. I too hope to see iOS apps there one day.


I love the Dashboard and even updated an app that displays weather radar for my city. The idea of the Dashboard being an iOS app workspace makes perfect sense and I can't see how I missed the connection before.


The naive approach to allowing people to develop applications that work both on mobile and on the desktop always fails because in the end the user gets a bad experience on the desktop, on mobile or on both. There is no UI that works on both mobile and the desktop.

Apple could unify UIKit and AppKit so you could more easily share parts of widgets and the backend code, but you'd still have to design the general user interface separately.


> MS failed because they had zero footprint on mobile, and I think Apple will fail because they have a relatively small footprint on desktop.

Two possilities here:

They dust off NextStep’s YellowBook support (Cocoa for Windows) and update it to support UIKit.

-or-

What if the parameters of Marzipan is not a compatibility API, but an effort to package the iOS Simulator and your x86 simulator builds transparently for the end user. Then port the iOS Simulator to Windows.

Halo Effect 2.0


To your "YellowBook" point, yes, looks like possibility.

And several Apple software like Safari 5 for Windows and iTunes already ship with macOS UI libraries ported to Windows. So in near future iOS apps may run on macOS and Windows - quasi true universal apps (not the UWP-crap)


You had been flagged for whatever reason…not sure why.

> several Apple software like Safari 5 for Windows and iTunes already ship with macOS UI libraries ported to Windows.

Actually, the situation is kind of the opposite: Safari and iTunes eschew the use of macOS's UI libraries. Safari, in particular, is actually just WebKit (which has no "UI") wrapped up in a Windows-style chrome to appear native. iTunes itself, even on macOS, is some sort of weird C++ hybrid abstracted API that's not Cocoa (which is why it looks so "off" on macOS). This, along with a version of Foundation/CoreFoundation, allows it to work on both platforms–though not very well, I'll admit.


Yes true. What I meant:

Safari 5.1 (Win32 version, discontinued) comes with several MacOSX user mode libraries ported to Win32 DLLs.

Older iTunes and QuickTime (like 5 years ago) came with MaxOSX libraries ported to Windows too - at least from what I recall.


Someone keeps flagging you…


I feel like the Ubuntu phone might have succeeded had they not focused on trying to do it this too. So sad.


It feels like a "X is the year of the Linux desktop!" comment to make, but I'm more and more convinced that the web is will be a very viable mobile app platform soon. Progressive Web App APIs are solving a lot of the homescreen/notification/other native functionalities, and performance is always getting better.

One day there might be an opportunity for a web-focused phone OS (what Firefox OS was trying to be, essentially), but... not quite yet.


Are you talking about everything being an Electron app?


Well, I'm talking about mobile, so the Electron model isn't quite applicable. But sort of, yes. Except without the overhead of each app bundling it's own entire browser runtime.


Progressive web apps actually run in the browser (any modern browser), whereas Electron runs its own copy of Chromium and Node.js, which is why you see the bloat.


It's all about trade-offs though, right?

Compared to a native app web apps are bloated, slow, have foreign UIs, and are power hungry. On a desktop machine, it probably doesn't matter, but for anything battery powered it does. I'll choose a native app any day of the week over a web app.


When I see the word Electron, I just don't install the "app." I am convinced that the 3MB winamp does just a good of a job being a media player as the stupid "electron" "app" that takes 20x as much RAM.


20? try 200


Looking forward the combination of webassembly (as a full virtual machine) and adaptive web apps, for a single app across every device and OS...


Would users want this? That seems like a huge step back for performance.


Why would it? Webassembly is meant to be close to native code performance. An HTML UI has no reason to be significantly slower than a native UI.


The lure of convergence again... that really didn't go so well for Microsoft.

I think that's something that really set Apple's iphone apart and that was really smart.

The problem is the iPad. The iPad should be a mac, in my view, like the Surface is a PC. Making the iPad a giant iPhone was a big mistake. Now people make pro applications for the iPad Pro and they're thinking "shit I really wish this could run on a mac" and now Apple is forced into some kind of compatibility that goes from the iPhone 5s with touch screen to a iMac 4K with touchpad.


> Making the iPad a giant iPhone was a big mistake.

I disagree. iPad is fundamentally a touch device, and trying to shoehorn macOS into this paradigm would have probably doomed iPad–remember, that's what the competition was doing back before iPad, and you know how the sales of those devices were…


I agree with the post you responded to. I have a 13-inch iPad "Pro" that I'm unhappy with since it doesn't do what it's promised to do. Can I build an iOS app? An Android app? Upload 100GB of data to Google Drive? Play movies stored on my external hard disc? Download Youtube videos for local playback, as some Mac apps can do? And so on.

As far as I'm concerned the "big iPhone" idea is a failure. I don't want a tablet that doesn't have the full power of a PC OS like macOS or Windows. That doesn't preclude touch. The OS and apps could and should be updated to support touch. And Apple has the market power to pull that off.

I want an OS with the full power of a PC OS + touch. You can get there by taking a mobile OS and making it more powerful, or by taking a PC OS and adding touch to the OS and apps. Yes, both options require a lot of work, but Microsoft is further ahead in having shipped it for years rather than denying the problem, as Apple does.


> [Can I] Upload 100GB of data to Google Drive?

Yes…is there something preventing you from doing so?

> Play movies stored on my external hard disc?

Well, you could if your hard disc supported a format that iOS could understand, such as a lightning cable, Bluetooth, or Wi-Fi.

> Download Youtube videos for local playback, as some Mac apps can do?

There are apps that let you do this.

> Can I build an iOS app? An Android app?

No, unfortunately you can't do this yet. This is one of the things that iPad cannot do yet and I'm sure Apple is working on.

> The OS and apps could and should be updated to support touch.

This is an awful lot of work for developers…especially on Apple's platforms, where bolt-on solutions are rare and most apps try to make full use of the medium they have.

> I want an OS with the full power of a PC OS + touch. You can get there by taking a mobile OS and making it more powerful, or by taking a PC OS and adding touch to the OS and apps.

Yes, we all do–and Apple is doing this from the "taking a mobile OS and making it more powerful" rather than "taking a PC OS and adding touch to the OS and apps" as Microsoft is doing. My argument is that this is the better way to do things, and the market seems to largely agree.


> Yes…is there something preventing you from doing so?

Full multitasking, which is required for the hours or days it takes for such a long upload, and ability to connect an external hard disc.

> if your hard disc supported a format that iOS could understand, such as a lightning cable, Bluetooth, or Wi-Fi.

Which is to say, hardly any of them.

> There are apps that let you do this.

Show me some that still work. I looked but couldn't find.


For the hard drive, I think you can use the USB dongle to connect a hard drive. But you are right in that the multitasking probably doesn’t allow for multi day upload. Haven’t tried it yet though.


> Download Youtube videos for local playback, as some Mac apps can do?

That just doesn't work because of business decisions on google's end.


Well, it's not an iOS limitation at that point.


If a device can't do what users want, they won't buy it, no matter whom you consider to be at fault.


Happy owner of an iPad Pro here. I don't know who promised you that you could build an Android app on an iPad but I'm pretty sure it wasn't Apple and they're the ones who should know. As for building an iOS app, you can write most of the code for one and then transfer it to a MacBook or iMac for the final build and packaging (go check out the Swift Playgrounds app for details).


It's not a question of "who promised" but that the device isn't capable enough for my needs.

If I have to transfer the code to a Mac, I'd rather develop on the Mac. I don't need an iPad. Besides, Playgrounds is not a substitute for the full Xcode.


I think you are exactly right. If I wanted a small macOS device, I could buy one (I didn't). What I wanted is a large iOS device and that's why I have a 10.5" iPad Pro. It's my favorite computer.


Making the iPad a giant phone was what made is successful compared to every other attempt (even Microsoft's) at making tablets.

The success of the iPad in the "pro" market is more of an accident and took a long time to come around.


I don't think it's a lure. Multiple platforms and languages is a massive and expensive pain point. It's just that you need everyone (Apple+Microsoft+Google) to play nicely and even now that doesn't seem to be the case. It doesn't look like Apple has any appetite for non Apple portability.


But isn't that exactly what'll drive this shift? Anyone that's using an iPad Pro to do this work will immediately flock to the Mac versions of these apps, especially when they're all in one binary, and the UI will reflect the device they're on, regardless of where it was first purchased. I would love to have those tools on a Mac while still retaining the ability to open/use them on an iPad when I'm on the go and need to make some quick last-minute changes that don't require a full computer.

This seems like the perfect, long-term, planned-out setup.


> Making the iPad a giant iPhone was a big mistake.

Making the iPad a giant iPhone gave it amazing standby battery life, and access to a wide range of games and apps, many of them kid friendly.

Compare that to a Windows tablet, which I cannot leave sitting next to my couch for a week, come back, push a button, and have it respond immediately. (Though on occasion Windows' standby modes do work...)


I definitely feel this is more about getting devs who make pro apps on the Mac to start shipping iPad (Pro) versions.

Tim Cook still believes iPads are the future of computing, literally "Post-PC" to quote their recent advert. Yet very few people are making serious productivity apps for the iPad Pro.


> Yet very few people are making serious productivity apps for the iPad Pro.

Text entry is still an unpleasant process on iOS. Even with an external keyboard, not having a good way to move the cursor around the screen without touching the screen (and even then, fingers aren't precise enough to do this quickly) makes typing long documents on it painful. I love my 12.9" iPad Pro, but until they solve this problem, it's not going to be a good productivity device.


I’m waiting for Bluetooth mouse support. It’ll be a game changer. Fingers aren’t precise enough for pro tasks and touch isn’t ergonomical for long duration tasks. The mouse as an option will allow the iPad to blossom into a real capable post-pc workhorse that I could use professionally.


Depends on the degree of convergence. As has been mentioned having both UIColor and NSColor serves no purpose.


> Developers currently must design two different apps -- one for iOS, the operating system of Apple’s mobile devices, and one for macOS, the system that runs Macs. That’s a lot more work.

One set of devices have ONLY a touchscreen as an interface. The other set of devices have ONLY a keyboard and mouse.

So how will this create less work? I think it will mean that each app either (a) bundles two essentially-different programs into one "application", or (b) gives up on desktop usability. Sadly I expect (b) and I feel that Apple does too, and doesn't mind.


Apple Watch has a crown and a touch screen. iPad Pros have keyboards, pens, and a touch screen. Apple TV has directional and trackpad input. All support voice input. All work fine with basically the same UI toolkit.


Interesting point. I am mainly biased toward caring about desktops and laptops, I don't use any of those devices.


It’s just the UI. Most of the underlying logic code and magic sauce can stay the same I bet.


Given that Apple seems to be following more and more industry trends, maybe touchscreen Macs are coming?


Also, they officially support a keyboard for iPad Pro. With recent multitasking updates for iPad and considering positive reviews for the keyboard, the Pro seems to be a serious contender for laptop replacement.

Recently got a Pro 10.5, and it's a fantastic device — seriously considering a keyboard for office work.


Does any one see the prospect of Xcode on iPad pro?


This is my metric. Can I develop iOS apps using iOS? Until then, I'm sticking to Mac.

(Actually, I'm a web developer, so what I really would need is full dev tools on iOS Safari.)


iOS has supported keyboards for a very long time. right back to when they first sold their 30-pin to USB "camera" adapter. You could definitely plug in a keyboard and use it.


Not just that, the first iPad had an official "keyboard dock" accessory - a desktop-style keyboard with a built-in iPad stand and 30-pin connector:

https://www.cnet.com/products/apple-ipad-keyboard-dock-serie...

(For the record, this was in 2010, the same year the camera adapter you mentioned was released, as well as OS support for Bluetooth keyboards.)


E.g. - this comment, via a Bluetooth keyboard on my iPad mini 2 :-)

Missing is the ability to use a mouse to supplement touch, which I could do on my Android tablet before it died.


Yep, and pairing a Bluetooth keyboard would work as well! I knew many people who carried around an iPad and a Magic Keyboard to use together.


Unlikely. Apple likely hasn’t solved the problem that the form factor for touchscreen desktops suck.

This is about making development easier for enterprise developers.


Why do touchscreen desktops suck? I'd be happy to touch the reply button below this input form instead of using the touchpad to move the cursor to there and click.

In other cases I'd use the touchpad (the cursor is more fine grained than my finger) but some touchscreen / some touchpad seems fine to me.

Fingerprints on a matte screen? Maybe that's a problem.


The people that have responded to you seem to be focusing on using touchscreen in a desktop-only/work-only environment, but as an owner of a Surface Book I think that's wrong. When I use my Surface Book for work I very rarely touch the touchscreen because, like @fauigerzigerk said, shoulder pain would become a real problem. Instead, when work is over I detach the keyboard, turn the device into a tablet, and switch myself over to "consumer mode". That's when I use the touchscreen; that's when I break out the pen and start drawing; that's when I switch over to using Windows Store apps because they're built for touchscreen; that's when I switch open Edge because it supports touch gestures; etc.

Of course that would assume Apple builds a device that can detach its keyboard or operate as a 2-in-1 where the screen folds over. I agree that as it's designed right now, a Macbook with a touchscreen would be a bad user experience.

This is just an anecdote, but when my last Windows laptop died in October I looked really hard at buying a Macbook and eventually decided I couldn't live without the touchscreen. Pardon the pun, but being able to touch anything on my screen like I can do on a phone just feels right.

(However, I will say that my default work setup [0] is to flip the screen over, place it on my laptop stand and use it as a second monitor - a decent configuration for annotating documents or taking notes with the pen.)

[0] https://i.imgur.com/sDNYoDF.jpg


Fingerprints is a problem, but a more minor one. Pulling your hand off the more accurate touchpad is another one. Screen weight/balance is another one, you want a really stiff screen for touching, but not so stiff you can't easily move it.

I'd say one of my biggest peeves is tap area sizes. Your fingers need much bigger areas to tap in accurately, so an efficient touch UI needs way more space for tap areas. But that space is wasted when you are using a mouse/touchpad cursor.

I think Apples stance that the additional costs and impediments aren't worth the minor gains has been reasonable. But it's probably close. I wouldn't be shocked if they changed their minds on their next round of laptops.


Shoulder pain will be an issue for people using it all day long. I know I can't lift my hand up to the screen hundereds of times per day.



On the other hand, Windows Store apps have "required"(loosely) that all interface works with both mice+keyboard and touchscreen. So it's not impossible, just yeah, a lot of work.


My laptop has a touchscreen. I didn't even realize until I needed to clean it. Maybe they'll require all new macOS screens to be touchscreens?


I think Apple has explicitly eschewed touchscreens on any screen that is always held vertically (i.e., laptop and desktops). They said usability studies consistently found people's arms get tired.


Well, it’s been so useful to you....


Yeah but my nieces and nephews are practically touchscreen only users, so maybe for them. I'm personally holding out for decent voice controlled UI - should be any year now.


This highlights something incredibly important. There's a very stark age line in people using touch screens by default. I TA an intro CS course, and I've noticed the line creep. It's somewhere between those born in 1998 and 2002. They just all like touch screens better because that's what they are used to.

I haven't even graduated and am feeling like a greybeard when it comes to this area. I have to wonder if it's simply that we were trained to be mouse by default...


It's difficult to argue that touchscreen isn't more natural in some sense. I've seen a 2 year old competently use an iPad to access media and play simple games. Programming seems to require a more sophisticated UI though, so I worry that touchscreen people will be even less inclined than usual to hack on internals, etc.


I guess this also helps explain why the new Mac Pros are becoming giant iPads, away from the old openable cheese grater design.


iMac Pro. We don't know the form factor for the new Mac Pro yet, but all signs are encouraging that it'll be expandable.


Unlike older iMacs?



This is a complete 180 from the approach in the early iPhone, iPad days. Everything was encouraged and often required to be made device-specific, because the UX is subtly different. Apple followed this too, back in the heady days of Skeumorphism. Even the shade of grey on the keyboard was different between iPhone and iPad[1].

This is yet another indicator that Apple has changed drastically since the Jobs days, and is moving more into alignment with other tech giants in their approach to products.

[1]: https://ux.stackexchange.com/q/16369


Microsoft has been failing at unifying desktop apps with mobile apps for many years with metro, UWP and whatever. Will be interesting if Apple can pull it off.


Throwing another data point — the recent transition to APFS was quite successful. There surely were problem cases, but the transition happened quickly and was transparent to end users.

The UI transition is tricky for developers to adopt. There will be legacy apps for decades to come as it will not be updated.


Apple has already proved they can do major software transitions gracefully with their adjustment from PowerPC to Intel.


For developers this transition was quite seamless, since most of the high-level API functionality was still there. This isn't the case when you're ripping out the current UI framework that every app uses.


I am not saying that's easy but unifying development for desktop and mobile seems harder. I think a lot of people have concluded that it's pretty much impossible because the needs are too different.


That was over ten years ago. The Apple of 2017 is a totally different company, and I don't think they're capable of pulling this off.


Perhaps after seeing the somewhat success of Microsoft in this arena, they are going to a "switchable" UI that will change depending on the device type. Instead of writing an app for iPhone, iPad, macOS, the developer just has to write one switchable app. That would be helpful for the developer, and if implemented right, the user wouldn't be able to tell the difference.

This functionality already exists to a degree in iOS. You can render different views based on the device / resolution. This would just be extending it to touch vs. keyboard and mouse.

I wouldn't think of it as a single UI that (doesn't) work for all devices, but rather a UI that knows what device it's on and can morph accordingly.


Apple's never been about the Developers (Developers! Developers!...) though, it's been about the users. It's a while since I've worked on Apple platforms, but it wasn't exactly a pleasant experience. Apple — back then at least — had the user experience at the forefront of what they were doing. You endured the pain of writing your app in Objective C, in XCode, submitting it to the app store, paying the subscription fees, dealing with the terrible portals and jumping through many hoops because Apple's platforms were where the users were.

Microsoft's approach was always, "We're where the developers are, which is where the app(lication)s are, which is where the users will be forced to go".

It's hard to remember quite how much easier to use Apple's devices were in those early days compared to the status quo.


>but it wasn't exactly a pleasant experience. Apple — back then at least — had the user experience at the forefront of what they were doing. You endured the pain of writing your app in Objective C, in XCode, submitting it to the app store, paying the subscription fees, dealing with the terrible portals and jumping through many hoops because Apple's platforms were where the users were.

Yes, I did those same things and found them as frustrating as you did. While I don't do iOS dev anymore, it has gotten a lot easier. Swift is an attempt to make a more modern, friendly language. Submitting to the App Store is mostly built into Xcode now, as is managing certificates. Their API/SDKs are top notch for the most part. Subscription fees were extended to include all Apple development (not just iOS). The portals still exist and haven't gotten any better.

The point I'm trying to make is Apple isn't as good to developers as Microsoft is, but they are definitely taking actions to move in that direction. Visual Studio is my favorite IDE by far, but Xcode is definitely taking cues from it.


You endured the pain of writing your app in Objective C, in XCode

Heh, you think that's bad, I remember MPW and MacApp... thank God for CodeWarrior!


"somewhat success of Microsoft in this arena"

MS has failed miserably. Windows phone is dead and Windows 8 was just a disaster. Windows 10 is just an attempt to salvage things.


Rhapsody, Yellow Box, Blue Box, Carbon, nothing has changed at Apple.



Speaking as a user, many developers are, pardon my French, shit, and will take every mile for any inch given to them.

Look at the iOS App Store after Apple introduced subscriptions: Even the most inane apps are now asking for monthly and yearly subscriptions.

Like, what is even the point of, say, a text editor having a monthly subscription? “To justify development costs”, they write elaborate blogs about. Even though they used to be perfectly fine with a pay-once model for years before. Even though everyone was perfectly happy with buying an incrementally-numbered “Text Editor N” every year, IF they needed to.

Some (like Day One I think) try to justify it by charging for features that Apple can provide for free, like iCloud Sync, and reinventing that wheel with their own paid solutions for that.

As a user I was happier with the weekly blog whining about Apple’s draconian walled garden, compared to this subscription-infested market now.


People expect updates once they've purchased an app for a few bucks. They tend not to pay more, and developers who release v2 and v3 as completely separate apps are often criticised. Not to mention, export/importing data can be a new issue across apps.

An upgrade could be released as an IAP, but asking for more once you've released a paid app is risky also.

I tend to avoid subscription software too, but I can fully understand why developers lean towards it as a way of getting a strong return and justifying further development, taking on staff for support, etc.

If the app isn't up to it, then consumers can find an alternative that can scrape by with a single price, right?


> People expect updates once they've purchased an app for a few bucks.

... and the App Store model does not allow a developer to e.g. maintain three different branches of a product (oldstable, stable, beta), with purchases tied to the branch. This makes a "classic" release flow like 1.0 is released, then 1.1 is released, then 1.2, then 2.0 (with new features, whatever), and then a patch 1.3, impossible.

Unfortunately, this "only ever have a single released/maintained version" approach (that was famously pioneered by Apple in iOS itself!) has caught the entire industry - there is no way to avoid e.g. a major update because it brings a royally fucked up UI, lost/rearranged features or whatever without risking security issues.

This is really really bad for enterprise customers where things like "UI overhauls" can lead to a massive, expensive training for all the users or at the very least an increased amount of helpdesk tickets.


Actually, many developers do exactly that by releasing each major version ("branch") as a separate app.


That's a hack though. Also, how do you do stuff like giving out "upgrade discounts" or discount vouchers? That's not possible at all.


Releasing major versions as separate apps is actually desirable for a number of reasons:

• The users decide if and when they want to upgrade.

• If a trial for a newer version is available, users can try it out before upgrading.

• Users can keep older versions if they prefer the older UI etc. They’re not forced to like all and any major changes just to keep using the app. There’ve been plenty of [in]famous cases where people complained about new versions of popular apps and websites.

• Generally a predictable timeframe for yearly updates.

• Users don’t have to pay every month even when an app is getting no updates.

• Developers are not under any pressure to release updates for the sake of updating to justify a monthly subscription.

Subscription-based software generally loses some or all of these advantages. Subscription-based apps seem to favor developers more than users. Greedy developers, in my unsugarcoated opinion.


I believe some apps have done that by requiring some sort of proof of purchase for an older version, and maybe paying the developers directly at a discount, who then prove the user with a code to redeem on the App Store.

Convoluted currently, but not impossible.


Pay-once apps compete with each other for my wallet only once. I can purchase them all over a given period of time.

Subscription-based apps constantly compete with EVERYTHING else that I have to pay for every month.

If I’m already subscribing to many apps, it reduces the chances of me subscribing to your app, even if it does not directly compete with those apps in the same category. i.e. photo-editing apps start competing with text-editing apps and games and music apps, perpetually, if they all switch to a subscription model. How is that sane?

If my monthly budget needs some breathing room and I [temporarily] cancel a subscription, I lose features or even access to my existing data. It doesn’t matter how long I had been paying for, not even if I had been a subscriber for years before cancelling.

If developers demand a subscription model then users should demand a “loyalty” perk, where you get to retain access to an app for N weeks after cancelling if you had previously subscribed for X months.

Also, you’d think that with the total number of computing users increasing for all platforms across the world, the overall sales of apps, or at least the potential buyers to market to, must be increasing as well, compared to when we didn’t even have subscriptions in the App Store.


"Also, you’d think that with the total number of computing users increasing for all platforms across the world..."

A certain percentage of those computing users are developers creating new apps. It's hyper-competitive.

If you can get a subscription product off the ground, you can double down on the product and support and get some advantages over small-time developers struggling along still servicing a userbase that paid a couple of bucks, one time, years ago.

(For the record, none of our apps are subscription based. I'm just saying I can completely understand the appeal from the developers' side.)


Oh, ok. So, if your health insurance expires, you're still going to go ask for coverage, because your insurance only expired two weeks back and you were on it for the last 5 years?


Try your best to step back and appreciate the differences between healthcare coverage and apps.


There are 2 parts of the apps. There's model layer and view layer. The model layer is a pain to bring over because certain model objects (UIColor) are only on one platform. So if they make changes to ease that then making a mac app will become way easier.

The other problem is that AppKit is not as nice or as easy to use as UIKit in my experience. If they can bring these two frameworks together under shared functionality that would be great. For example, template Master-Detail from iPhone to iPad is great (and you can always customize). So having that extend to macOS would make mac development easier. I imagine this is what they are planning.

The third idea is they are thinking of something greater yet separate that is not meant for existing apps. Like a new UI Framework that works on both. This seems hard to believe as they have the iOS app base and the goal is to bring that over to mac not start a new app base altogether.


As someone (apparently the only one in this thread) that writes macOS and iOS apps, I can't wait for NSView and it's stupid lower-left cartesian coordinate system to die.

UIKit is so much better in so many ways, it's time NSView and its friends are all put out to pasture.


Unifying the APIs that exist in slightly different versions on both platforms makes sense. But it's dangerous to talk like that frees you from having to design and implement separate user interfaces for handheld touchscreens and for desktops with keyboard+mouse.

I like the idea of getting a compiler error when you try to deploy a touchscreen UI to my MacBook Pro. I paid good money for that Retina display because I want to have a lot of information on screen. I don't want it wasted by 200px buttons.


I've had many years of experience with iOS and then started working on a macOS app a year or so ago. Everything seemed overly complicated compared to iOS development.

I ended up using a web view and did a lot of front-end work via HTML to save time!


UIKit is much more limited than AppKit because it was meant to run on devices with limited resources. In fact, people used to complain about all the things you couldn't do on iOS devices that you could on the Mac.


I end up just using a subclass with isFlipped returning true 90% of the time. I've found that I rarely need to deal with the lower-left issue after that... what's your biggest pain point after that?

I look forward to this from Apple, because then I could scrap so much of my own stuff that's aliasing the two platforms. I think people who haven't built for these platforms don't understand that it's not about Apple letting you provide the same UI on two different platforms, but about getting rid of the lower-level differences between the two that don't need to exist in the first place. It's strange to see so many people both here and over on Reddit take issue with Apple doing this - you can't sit there and complain about Electron taking over and then decry a company literally giving you a better option. I'd gladly run a Slack client on my desktop if I could get the iOS build, and I'd really enjoy having RobinHood or Tinder or any number of apps on my desktop so I don't need to pull out my phone (or open a browser) for them.

As it stands right now, cross-building your app for desktop from iOS is a rabbit hole that most people are right to shy away from as there's a lot of odd knowledge that's historically been needed to make it work.

For example, NSTableView in 10.13 finally supports AutoLayout without needing to hack around it with a caching view, making it much closer to UITableView. That alone makes certain views much easier. Collection Views also only recently got closer to their UIKit counterparts, and it's made that much more usable as a result. Before these things, there was _so much_ glue code to reuse the same stuff. Sharing layout code before was possible, but an extreme exercise in frustration for a lot of people - now it's getting closer to a 1:1.

Using any of the littered unmaintained frameworks for "UIKit in AppKit" is also usually not that great, since it's another API to learn that's most unofficial and they've almost all been abandoned over the years.

Also, as one last personal comment, Apple needs to port UINavigationController - I ended up rolling my own (with the whole header view/etc), which is horrendously annoying to do. While I totally understand that mobile != desktop, it's 2017 and people have gotten slightly used to some mobile interfaces working on desktop. At the end of the day it's a simple stacked navigator that'd make code reuse a lot easier. Hell, port the API and have it display differently for all I care.

Ninja Edit: if you're an Electron fan, and Apple had frameworks that worked the same on Mac/iOS, you could avoid Electron on iOS if you had a React Native app that could now cross compile (not using the odd third party framework that exists and is never really feature-parity with actual React Native).


Convergence is overestimated.

As a users, I actually do not want an identical use experience of apps on desktop and mobile devices because inherently these are different use cases and it does not make sense to mix them. It's not even the same applications that would be used on iPad as on macOS.

I doubt technology is an issue here. Universal binaries for macOS worked well and that was a decade ago. It's the fundamental use cases for these devices that differ and no development framework can bridge that, probably even shouldn't.


It sounds to me like you're actually saying your experience with convergence has been overrated vis-à-vis initial claims.


By extension they could be saying that convergence is likely to incentivize creation of those mediocre experiences.


Assuming they can pull this off in a very good way (a big assumption), I think this is a smart move. This isn't just for tech illiterates, this is for pros.

Imagine if all new software created was immediately available on iPad - that'd be huge. People have been talking about the lack of pro-grade video editors, vector art painters, and programming environments on iOS for a while now. This could be really interesting.


I like that most may content creation software has a high level of access to the operating environment.

I also like that all my iPhone and iPad apps are sandboxed off from each other.

I use the devices for different purposes, and want them to behave differently. That's how I felt when Unity flopped, that's how I felt when Windows 8/10 flopped, and that's how I expect I'll feel this time, too.


Serious applications will always be native.


> Imagine if all new software created was immediately available on iPad

Alternatively imagine if all new Macs were created with touch screens and pen input like all new Microsoft machines are.


I sure wouldn't hold my breath for any Adobe products to get on board with this, they've put all of one app (Photoshop Elements) on the Mac App Store so far.


I wouldn't be so sure. Adobe has a rather large presence on the iOS App Store, and they're frequently featured as early adopters of whatever new technology Apple rolls out during their onstage presentations. Apple would probably try hard to get Adobe to follow along here, since it's an important app that people want to use.


Here's a relevant 2014 WWDC presentation on how Apple redesigned iWork to work on both iOS and Mac using most of the same codebase, and the technical problems which needed to be solved: https://developer.apple.com/videos/play/wwdc2014/233/


Outright shared apps sounds like a terrible experience. I can definitely understand the argument from a developer perspective wrt shared code bases between platforms, i don't know if the user part of me is excited, though.

Maybe it'll also keep people from using other frameworks and lock them in on Apple platforms more.


Like everything, it greatly depends on the execution rather than the concept.


The concept was tried with Windows 8; they had to go back to offering both desktop and touchscreen options. Based on my experiences using an iPad, iPhone, and a variety of mac laptops, I don't see how this could be practically different.

Touch interfaces take up too much space on lap/desktops, and desktop interfaces are inconvenient to the point of not working with touch.


> The concept was tried with Windows 8; they had to go back to offering both desktop and touchscreen options.

Still using the same platform. The idea is to use responsive design rather than different UI frameworks.

Disclosure: I work at Microsoft.


Please, don't Apple. A Mac is a different device with a very very very different user interface - in the sense of how users are interfacing with it. I don't need ANY of the UIKit interface elements on my Mac.

It's like Write Once Run Anywhere all over again. Instead, go back and focus on what made OS X so great. Because High Sierra ain't it.

It's bad enough that a viewer of hypertext documents is now the common 'app' platform, I don't need or want a unified UI kit.


It would be interesting to compare this to https://github.com/BigZaphod/Chameleon which came out of the Iconfactory in 2011:

“Chameleon requires OS X 10.6 or higher. Apps built with it have been proven to be acceptable to Apple for the Mac App Store. Chameleon was first built by The Iconfactory to unify the codebase of Twitterrific for both Mac and iOS.”

Frameworks with iOS/macOS targets have long existed and it is proven possible to have events routed in UIKit style. I however fear that the merging of user experiences will come at the detriment of the Mac experience.

SJ said long ago that Macs are trucks and only some people need it. This converging step makes no sense when Apple is already trying to push the iPad as the “computer” for the masses.


Having lived through windows 8 and the .net frameworks, I really hope Apple can do better.


> .net frameworks

I believe you mean Metro/Modern/Universal Application Platform, the .Net Framework dates back to 2002[0] and was likely created to compete with Java after the 2001 Visual J++ court case[1].

.Net wasn't an attempt to combine mobile/tablet/PC applications together, in particular as it predates smartphones and modern day tablets. Metro/Modern/UAP was however designed to accomplish that goal in Windows 8.

[0] https://en.wikipedia.org/wiki/.NET_Framework_version_history...

[1] https://en.wikipedia.org/wiki/Visual_J%2B%2B#Sun's_litigatio...


.Net Framework Compact Edition has been around since 2002.

https://en.wikipedia.org/wiki/.NET_Compact_Framework


I don't think it is possible. Different hardware means different user experience.

You can pretend it is the same application, make one sale and provide different software for each device. But this is more of a marketing gimmick than anything.


We can't even make unified websites which work well on a desktop and mobile. There's always something missing from the mobile website which makes the customer revert back to desktop version on mobile, which is a horrendous experience(like functionality which is there on desktop version but disappears as soon as you shrink the screen past a certain point). Very very very few companies get it right.


It's not even the hardware, it's the user interface. Touch interfaces are too large for desktops apps well, and desktops interfaces are too fiddly to be used with touch.


Agreed, but if anyone understands that UI platforms are different with different needs, it's Apple.


Spoiler: It won't.

You need UX that is tailored for the device type and form factor. It's like gravity - you can't escape this. Both Google and Microsoft learned this the hard way.

Even Apple had to basically encourage developers to write tailor-made tablet apps. If iPhone and iPad apps can't be "universal" what hope is there to unify them across an even larger range of form factors?


The difference will be that instead of complaining, Apple devs will find explanations why it makes sense and adopt it.


Spoiler: they will.

Apple is the back-to-back champ of these platform transitions.


Ugh. Not looking forward to this at all. Instead of making things perfectly fit each device they will try one-fits-all approach which will most likely be sub-optimal at best and horrible at worst (Windows8).


Windows is a different beast–many of it's laptop/desktop computers have touchscreens, and Microsoft overreached and basically made the experience better for them at the expense of mouse/keyboard devices. Apple can't do this, of course, since Macs don't have touch screens.


The cynic in me sees your last statement as an indication of the next must have feature - the official Apple Touch Screen Monitor for your desktop Mac.


But Steve did the research, he even said himself: "Laptop users do not want a touch screen!".

To which I completely agree, mind you.


Except they have a curated app store, so they can reject apps which do not have a good UI for both cases.


Seems like such a bad idea from a UX perspective that it's hard to imagine iOS apps on macOS being anything more than reimagined Dashboard widgets.


I think the burden is going to fall squarely on iOS developers to make their apps usable with mouse and keyboard on the mac. Mac developers are probably not going to bother porting their UI to work on iOS though. Apps like Sketch App come to mind.


No one's mentioned this but could this be a precursor to weaning themselves off of Intel for MacOS devices?


Why would it be? macOS's APIs are architecture-independent and have been since day one, which is what enabled the smooth transition from PowerPC to x86.


I'm surprised by all the negative comments about this. It's hard for me to understand why this is a bad thing. Linking the phone to the computer in deeper ways without having to write separate apps seems _super_ valuable.


Yes. The obvious universal API that targets big screens and small, touch or mouse is Qt. It started as a desktop framework, was made touch-aware to be used Nokia and BB10 for phones, powers KDE 5 and I'm hopeful Ollie Paranoid will provide an update in a few weeks re: Plasma on postmarketOS.

Now a company with Apple's resources should surely be able to reintegrate the Cocoa Touch hard-fork back into a common modernised Cocoa, which by now has a 30 year legacy from NeXTSTEP.

Naturally you'll still need to customize a UI for Mac or iPhone but a unified toolkit is entirely possible.


So basically they’re going to allow a 3rd set of storyboards and components for the Mac (theres already differences for iPad and iPhone), and then somehow merge the frameworks so it’s coherent from a programming perspective?


This convinces me my suspicions are correct. They want to replace desktops with iPhones.

Apple has been drastically increasing the power of the processors in iPhones. Now they’re unifying the iOS and macOS experience.

They’re going to create a desktop mode within iOS. It’ll use bluetooth peripherals and an HDMI Airplay stick that plugs into a monitor.

The iPhone will become a PC we carry around in our pockets containing all our data making it unnecessary to have a different computer in every place we go to. And it will justify spending more on our phones because we’ll be saving not buying desktops.


I've suspected that iOS-only had been the plan for a while and I am pretty sad about it to be honest. I'm sure the user experience will be great but I'm a professional and I want a relatively unrestricted OS with a decent UI and good hardware. I suspect I'll have to compromise on at least one of those eventually. It makes sense for Apple but it will be the end of an era.


Please just fix iTunes for God's sake. Why are they wasting all this effort when their core apps like iTunes are among the worst apps in existence but are forced upon us?


Maybe they'll rewrite iTunes to use this framework, instead of the C++ Windows/macOS hybrid monster it is today?


If they write it in Swift, all the problems will magically go away. Just like how stable rest of macOS has become in the last few years.


You're joking, right?


What do you think?


They are inching ever closer and closer to that toaster-fridge they despise.


This are two different eco systems. What works for touchscreen does not work for Desktop and vice versa. I don't want even one app from the phone/tablet on my Desktop. This only gets messed up. The good thing about macOS is that Apple stick to it and does not mess it up like Microsoft with their confusion about touch and non touch apps.


This is probably going to be focused on lower performance apps but for those talking about video editors it may be important to point out that though the iPad is insanely powerful, it's not as strong at doing long term high performance tasks. Not like a laptop anyways.


It’s insanely powerful only for its size and energy usage. There are so many cut corners and micro-lies when it comes to mobile that make all the specs sound good but at the end of the day they are far, far more crippled devices than any desktop or laptop computer. They tout things like processor specs but the entire computer matters, and turns out when you optimize for power efficiency and battery life a whooooole lot of computing power is simply not there for you to use.


Really looking forward to my complex professional software and content creation and data management desktop tools being dumbed down to the UI complexity of an iPhone just like desktop web apps have been since the advent of responsive design.

Maybe the upside of this will be all the developer types fleeing to Linux and Linux finally gaining a comparable user-facing software ecosystem.

(Yes, I know a lot of software exists for Linux, but the quantity, variety, and ease of installation of end-user applications on Mac is in a different league; and a lot of mainstream Mac+Windows apps still don't have Linux versions. It's the main thing Apple gained by making OSX developer-friendly in the first place.)


This will probably be what gets me (and most power users) to leave Apple's walled garden for good. Once iOS infects MacOS heavily enough that it interferes with the way I prefer to use my computer, it's all going away.


Going to be very interesting to see how they go about implementing this. So much is different about the UI of Mac Os and iOS, that I'm guessing at the very least you'll need different views for each platform.


This is amazing news. As a developer the idea of writing once and running on many platforms is weight off our shoulders.

However, I can also see how a lot of developers might not like this. For example, Cultured Code charges $13.99 for Things on iOS but $49.99 on Mac. Why the difference? It is mostly because users expect apps to be cheap on mobile even though developing for both platforms is comparable. However now, developers are going to be expected by users to support both iOS and Mac apps for the same price.

Also, I feel like this news might imply ARM based macOS?


No, it won’t imply ARM macOS. It’s obviously a distinct possibility, and I wouldn’t be surprised if they went that way one day. In fact, given release builds uploaded to Apple are basically just an intermediate llvm bitstream, Apple could theoretically release to any architecture.


llvm bitcode is a compiler IR and nothing else, it's not architecture-independent. There have been independent bytecodes based on it like PNaCL and SPIR-V, but they're not nearly good enough to run any old app on.


No developer will be forced to use this, it will be for enterprise developers and low volume specialists. Pricing will stay the same.

And ARM ain’t coming to MacOS anytime soon. The costs are far higher than benefits.


The reason MAS is a ghost town I have always assumed was because of the MAS limitations and that unlike iOS devs aren’t required to use the store.

iOS and macOS are totally different so you’d still have to develop custom ui’s though Apple could certainly help to make it easier to develop for both platforms at once. But even then MAS would remain mostly a desert until they even change limitations or require all apps to be from MAS which would be nearly impossible, especially for business customers.


Would be interesting to see how Apple tackles the problem; since other giants have failed badly on this. Microsoft is perfect example of over-promising and not getting traction.


I've realised a while ago that the fact that OSX is Unix-based and fairly open - and therefore used by many developers for non-Apple development -- happened purely by accident, because Apple needed a better replacement for the old MacOS 9 and NExTSTEP was readily available. When developing iOS they made it more controlled and closed, and they're now following that strategy to the desktop.


I just don't see anyone winning other than trash app sellers.

far too many using iOS expect apps to be free or so cheap as to be free. how will that outlook crossover into the Mac world? Let alone how will all the apps with in app purchases play out in the Mac world?

finally, how much functionality must mac apps give up to be compatible with both systems? the mac ecosystem is much more open than iOS, is that going to change?


I guess this is possible given that their frameworks support many different screens at this point, and some variation in tap target size. But it's not totally clear to me that supporting both touch and mouse in one app will do both input mechanisms justice.

Unless they're imagining that there would be a completely different set of UI resources for Mac apps vs iOS ones?

Any thoughts on this from Windows users?


I'm hoping "unified user experience" is meant in a big way -- the promise of a device that can go from touch UI when in my pocket to desktop experience when a keyboard and display are connected is a huge one.

The makings of such support are already there in the hooks iOS has to support different size classes -- currently used to handle device rotation mainly.


This makes more sense for games than apps (for apps could have a much more wildly different experience and design on the desktop than on mobile), and it makes even more sense for VR games (where both input and output will be identical regardless of the execution ecosystem).


That sounds like a terrible idea. You need an Apple device to seriously build iOS apps, so does that mean that Apple users will have trouble using software that is created by people who write their software on other operating systems?


I take it that next year we will see a totally different macOS user interface, in order to make the one ux experience alignment. macOS has not had major UI changes for a few years, so maybe macOS app with no menu bar?


Not enough info here to determine anything useful from the developer perspective. If I had to make an arbitrary assumption, I'd guess that this boils down to a UIKit implementation on the Mac.


people seem to forget but Apple makes some of the most powerful iOS apps currently. iMovie, Keynote, Photos, Garagaband etc. And the experience between iOS and MacOS is extremely similar between them. Just more “expanded” on desktop. I wouldn’t be surprised if they share a lot of code between the different platforms too. If this helps more developers accomplish the same thing that Apple is doing with their own apps then I’m all for it!


Wish Apple would hurry up and eat their words so that they can add touchscreens to their laptops. I'm using a mac at work and I so miss my Windows touchscreen.


Windows 10. I hope Apple treads this path very carefully.


Windows 10 is fine, Windows 8 was the failure. Window 10 actually suffers a bit from not being enough like Windows 8 in some touch screen facets.


Windows 10 became fine after taking windows phone out of the equation. You no longer need to optimize for both big and small screen.


I know Beeware[0] is doing something similar. Disclaimer: Contributor.

[0] https://beeware.org


It doesn't make sense for all apps but I felt like I need it since I started using Margin Note app in my ipad and macbook.


The user experience I want includes USB ports, an SD card slot, replaceable batteries, and the escape key.


This is exactly what Progressive Web Apps are going to achieve! Reinventing the wheel once again...


This sounds to me like providing the ability to run iOS apps in a window in Mac OS


Hopefully this means the iPad Pro will gain support for trackpads and mouse input.


I would seriously doubt this. More than likely it'll be a unification of some AppKit and UIKit API, with the developer being expected to tailor the experience to the input devices available.


To provide some historical perspective: Apple's done major transitions like this in the past: The move from Mac OS 9 to Mac OS 10 and the move to Intel come to mind.

I'd be curious to hear from experienced Mac devs on what they think of this plan (if true) and the biggest hurdles?


Along with an ARM-based 12” MacBook named iBook. #speculation


Friendly reminder that a 12" laptop named "iBook" already exists: https://en.wikipedia.org/wiki/IBook


I was alluding to that indeed: reviving the beloved brand. Makes perfect sense.


To me this speaks to the power of Progressive Web Apps.


Yea, that is the first thing I thought of when I saw this. PWAs could be made for this and I think could be awesome


One step closer to killing off Mac OS.


Apple's got the Microsoft bug.


there we go again...

people failed so many times before... let's see what they can bring to the table now.


I wonder if this is a hint that apple might finally be bringing a touch screen interface to the Mac?


AKA UWP for Apple OS


I wish people would stop designing "one user experience" between mobile and desktop.

Capital One just switched me from a nice classic UI to one clearly designed for a small touch screen, and I'm thinking of switching banks because it annoys me so much.

I generally hate when websites redesign to "look nicer" based on the aesthetic du jour and in doing so throws away a significant portion of the functionality.


Despite the title of the article, I do not think this is about designing "one user experience" between mobile and desktop.

I think it's about consolidating the UIKIt and Cocoa frameworks, making it easier for developers to share code between platforms, but not necessarily creating a UI that's the same for both.


> I generally hate when websites redesign to "look nicer" based on the aesthetic du jour and in doing so throws away a significant portion of the functionality.

I'm right there with you. On the other hand, some of my accounts are still using half-broken UI that hasn't been touched in a decade (A&M plans still don't include UI apparently), even the minimum viable refresh would be an improvement.


They will probably refresh everything except this part.


That's an orthogonal problem. Why should the Apple platform arbitrarily require you to use different toolkits for different form factors or input modalities? They already support phones, tablets, TV's, and watches with the iOS toolkits. Adding desktops and laptops to that mix seems obvious.

And it goes the other way. The iPad Pro will probably benefit by gaining support for pointer input.


Ally made that idiot choice awhile back (mobile first, f-the rest) UI and they've been gradually dialing it back for better experience on desktop. It was like using iphone app on ipad in simulation mode; everything huge, functionally crippled.


Couldn't you just zoom out?


I've yet to find a browser where zooming out reduces the gratuitous padding around UI elements without shrinking the text beyond readability.


The banks had extremely functional websites after years of iteration.

Some of those sites had been more or less unchanged since at least the early 2000's.

A shining example of if it ain't broke, don't fix it.

I'm 99% certain people weren't leaving any bank because of an old website design.

The new ones have so much padding and empty space, and hide everything behind "clever" menus. I'm a PM and avoid this clever bullshit like the plague.


Tons of people leave banks because of old website designs. Old websites typically don't support newer technologies on the backend because they're entirely outdated. Just because something worked when it was developed doesn't it mean it stands the test of time and, if customers can't access new features, they won't use that bank.


I would leave a bank because it lacked features, not because it's design looked old.

A bank is a tool, I don't care how pretty it is, I care how functional it is.


That was kind of my point. The new designs don't incorporate any new functionality.

The designs don't necessarily look outdated, they look out dated to us because we live and breathe that stuff.

I'm not speaking in absolutes here though - some bank sites do need to be completely reimagined. Chase specifically comes to mind for example, but Wells Fargo's site was perfectly usable and did not feel dated.

To go even further, I'm not entirely arguing against redesigns, I'm arguing that if you do go that route it should at least be simple and straight forward, it's a bank site not the next social media behemoth.

It's always a really tough problem to keep old users happy who've been using the old sites for possibly years while treating new users to something more modern. This is one of the toughest problems I've encountered working in this field and haven't yet found an elegant solution.


Totally. The google map desktop is hard to use, because it's copying features from mobile.


"Mobile-first design" often produces really bad results. I could name a lot of sites that do it and their websites are often terrible on a laptop, which is how I use the Internet.


No, bad design produced by committee and other bureaucratic bs produces bad results. You're doing it wrong if you're stripping features only on small view ports.


> You're doing it wrong if you're stripping features only on small view ports.

I'm not sure how that statement addresses the point made by GP, who said, "...their websites are often terrible on a laptop, which is how I use the Internet."

If not the de facto guidance of mobile-first design, the de jure guidance steers designers toward reduced functionality. The overwhelmingly common outcome of a mobile-first redesign of an application is dramatic reduction of functionality, often spun as a simplification. I would prefer if mobile-first redesigns retained existing functionality but I acknowledge functionality may be reached in new ways that better fit the capability of the device.

The problem is not that mobile-first design strips features only on small view ports; the problem is that mobile-first design strips features full-stop.


Unfortunately, I agree that it certainly is a tendency to do that. But, again, I'd say that's just bad design. A good design with a mobile first strategy should not end with such an outcome. I'd also like to clarify that my tone was directed towards the people who mess it up, not the parent. If you start with a semi truck trailer full of stuff from your suburban mcmansion and try to cram it into a studio apartment, you're going to have a bad time. But you have to. What you don't have to do is say "We have all these widgets and need them on mobile so let's figure that out". Those aren't features. The feature is being able to get the information you need or do your task on any device. If you can't design an interface that accomplishes what you need in a small viewport, that doesn't mean cut it, it means maybe think a bit more. It's not a situation of fitting every god damn thing on the same screen and then giving up on anything that doesn't fit. When you have more screen real estate use it if you can effectively.

Again, your feature is what you can accomplish with whatever it is you're designing. If it's a database of information with tons of categories then it's an IA problem from the tightest box first and then using more space as it becomes available. If a user can't get to the same information on any device then the design ain't working. If its a piece of accounting software you'll have a bunch of crud operations happening and need to focus on designing great forms. I think most large companies basically decide to cram their mega menu into a side are menu, then expose the search bar and put their app in read only mode. Very much like slapping agile on your team to solve your efficiency problems, it won't work.


> If a user can't get to the same information on any device then the design ain't working.

Another explanation: sometimes the device really is too small for the information. Mobile devices are terrible for a lot of things. People with laptop or desktop computers shouldn't pay a price for that. "Mobile first" is okay in some cases as long as it isn't "mobile on every device".


I'll certainly concede that there may be different challenges associated with design for things like watches. Maybe. Haven't used or designed for them though.


Oh man the capital one redesign infuriates me so much. The "Account Summary" page which you land on after logging in has barely any info or links on it. You actually can't manage your account from that landing page, you have to click on the View More link inside the Recent Transactions box to get to a page that has any account services. You also need to click on their back buttons on the webpage to navigate backwards instead of using the browsers back button.


I did switch banks due to their redesign. I settled on Radius, primarily for their interest rates since their UX isn't totally there either. All the functionality I need is there (unlike the redesigned Capital One), just not intuitive to find.

If companies are consistently punished by consumers for these unfriendly changes, maybe they'll stop doing them. At least I can hope, right?


Tangerine did the same a few weeks back. Hate it.


Hope they ban the shitty cross platform frameworks at the same time.


Unity probably accounts for 90% of the iOS games.


I would imagine games would be an exception. Plus Unity started on OSX.


Better hope the Javascript Mafia doesn't read that!


This will be one of those Apple APIs that someone in Apple thinks is a good idea, gets a half hearted release, then dies on the vine as the vast majority of developers say “F no”.

It will be Apples less successful version of Electron.


That really comes down to whether or not Apple uses it themselves. If they port their various iOS apps to this new thing and have them replace their current macOS counterparts, then this thing is safe to use.


That's not the point. I have no doubt it will be "safe" to use. But if it's going to be used for dumbing down apps, it's only going to be beneficial for enterprise and cross platform developers willing to make usability trade-offs to slash development costs.

As a Mac/iOS developer, I'd only use it if I'm able use the merged classes to cross-develop on both platforms, while still implementing my UI natively on each. If it's just for making iOS widget apps run on MacOS, that's fine for others but it's not going to fly for many commercial applications.

The problem is, as an iOS developer, I spent the majority of my time writing UI code to make our apps work as well as possible for users. Which means large tap areas, eschewing menus, minimizing scrolling areas, etc. Basically the opposite of good desktop design.


Apple just can't let go of copying Microsoft, first with flat UI, now with one-size-runs-all :D

Seems like real innovation is a thing of the past.


I thought it was more Google providing Android compatibility within Chrome OS driving the push to bring apps to macOS.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: