Apple Plans Combined iPhone, iPad and Mac Apps to Create One User Experience
bloomberg.com
bloomberg.com
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.
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.
The success of the iPad in the "pro" market is more of an accident and took a long time to come around.
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…
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.
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.
That just doesn't work because of business decisions on google's end.
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.
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.
This seems like the perfect, long-term, planned-out setup.
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...)
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.
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.
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.)
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...
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.
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.
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.
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.
UIKit is so much better in so many ways, it's time NSView and its friends are all put out to pasture.
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 ended up using a web view and did a lot of front-end work via HTML to save time!
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).
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.
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.
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.
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.
“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.
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?
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...
To which I completely agree, mind you.
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.
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.
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.)
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.
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.
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?
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?
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.
I'd be curious to hear from experienced Mac devs on what they think of this plan (if true) and the biggest hurdles?
people failed so many times before... let's see what they can bring to the table now.
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?
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.
Seems like real innovation is a thing of the past.