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?
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.
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.
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.
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?
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.
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.
> 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.
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.
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.
"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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.)
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.
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.
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 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.
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.
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.
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.
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.
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?
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.
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?
"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.)
> 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.
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.
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.
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.
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.
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 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.
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.
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).
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.
> 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!")
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.
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.
> 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.
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.
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.
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.
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.
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).
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.
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.
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.
>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?
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.)
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.
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.
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/
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).
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.
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 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.
268 comments
[ 2.6 ms ] story [ 263 ms ] threadYou 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?
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.
Apple is the back-to-back champ of these platform transitions.
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...
https://en.wikipedia.org/wiki/.NET_Compact_Framework
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?
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.
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.
And it goes the other way. The iPad Pro will probably benefit by gaining support for pointer input.
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'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.
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.
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".
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.
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.
A bank is a tool, I don't care how pretty it is, I care how functional it is.
If companies are consistently punished by consumers for these unfriendly changes, maybe they'll stop doing them. At least I can hope, right?
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
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.
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.
Heh, you think that's bad, I remember MPW and MacApp... thank God for CodeWarrior!
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.
MS has failed miserably. Windows phone is dead and Windows 8 was just a disaster. Windows 10 is just an attempt to salvage things.
The UI transition is tricky for developers to adopt. There will be legacy apps for decades to come as it will not be updated.
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.
This is about making development easier for enterprise developers.
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.
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.
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
Recently got a Pro 10.5, and it's a fantastic device — seriously considering a keyboard for office work.
Missing is the ability to use a mouse to supplement touch, which I could do on my Android tablet before it died.
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.)
(Actually, I'm a web developer, so what I really would need is full dev tools on iOS Safari.)
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...
https://static.highsnobiety.com/wp-content/uploads/2012/10/t...
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?
And ARM ain’t coming to MacOS anytime soon. The costs are far higher than benefits.
Maybe it'll also keep people from using other frameworks and lock them in on Apple platforms more.
Touch interfaces take up too much space on lap/desktops, and desktop interfaces are inconvenient to the point of not working with touch.
Still using the same platform. The idea is to use responsive design rather than different UI frameworks.
Disclosure: I work at Microsoft.
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.
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?
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.
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.)
... 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.
Convoluted currently, but not impossible.
• 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.
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 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.
Alternatively imagine if all new Macs were created with touch screens and pen input like all new Microsoft machines are.
It will be Apples less successful version of Electron.
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.
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).
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.
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.
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!")
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 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.
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.
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.
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.
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.
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.)
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.
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'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.
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.
You can do this already via iCloud Drive app folders.
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?
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.
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.
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.
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
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)
> 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.
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.
As a user I personally prefer more powerful software and a more financially motivated developer; even when it makes buying more bespoke.
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.
Assembling from disparate sources will have more of an upfront cost but cost less per purchase. So it depends entirely on your sales volume.
Regarding your second point, interesting, seems like MAS is good to get started until the app reaches a certain volume.
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.
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.