SwiftUI:
SwiftUI is an innovative, exceptionally simple way to build user interfaces across all Apple platforms with the power of Swift. Build user interfaces for any Apple device using just one set of tools and APIs. With a declarative Swift syntax that’s easy to read and natural to write, SwiftUI works seamlessly with new Xcode design tools to keep your code and design perfectly in sync. Automatic support for Dynamic Type, Dark Mode, localization, and accessibility means your first line of SwiftUI code is already the most powerful UI code you’ve ever written.
I guess this is project Amber. I don’t know the details well enough to say much yet. But I think building UIs in code with a functional/declarative style is fundamentally the right approach. The code snippets look similar to (but better than) the newer UI code I’ve been writing using my own layer on top of AppKit.
As you work in the design canvas, everything you edit is completely in sync with the code in the adjoining editor. Code is instantly visible as a preview as you type, and any change you make to that preview immediately appears in your code. Xcode recompiles your changes instantly and inserts them into a running version of your app, visible and editable at all times.
The Swift compiler and runtime are fully embedded throughout Xcode, so your app is constantly being built and run. The design canvas you see isn’t just an approximation of your user interface — it’s your live app. And Xcode can swap edited code directly in your live app with “dynamic replacement”, a new feature in Swift.
At first I thought SwiftUI was a wrapper layer on top of AppKit and UIKit.
Robert Clegg:
It really isn’t. It’s built from the ground up and is all Swift code.
If so, this is really interesting as it introduces a separate UI stack and really makes Objective-C a second-class citizen. But it is also a chance to have a unified framework that can apparently coexist with legacy views in the same window.
Nate Cook:
SwiftUI works great with UIKit, AppKit, and more! This tutorial shows how you can host SwiftUI views inside view controllers, and then embed those view controllers in SwiftUI
Jack Lawrence:
Remember all those awesome UX #WWDC talks about interruptible animations, and how they make your app feel far more responsive? Getting it right used to be incredibly hard. #SwiftUI does it all for you with One. Line. Of. Code.
Combine:
The Combine framework provides a declarative Swift API for processing values over time. These values can represent user interface events, network responses, scheduled events, and many other kinds of asynchronous data. Combine declares publishers to expose values that can change over time, and subscribers to receive those values from the publishers.
This is Apple’s reactive framework (finally) and the successor to Cocoa Bindings and KVO.
Previously:
Update (2019-06-04): Joe Groff:
Some things wrap UI/NS views, but whether they do, and what view type they wrap, is subject to change. Best to think about it as a distinct thing
Joe Groff:
SwiftUI controls have layers that are managed directly by the framework; there are APIs for embedding an NS/UIView in SwiftUI and vice versa. Performance was a top priority, it’s good
Joe Groff:
Any transform that can change visibility or structure gets represented by a generic wrapper in Swift, so it’s known that opacity/scale/rotation/etc. can change, when content can have variable numbers of nodes, etc. Only the variable cases need “ids” for diffing
Kyle Howells:
You don’t build an entirely brand new UI framework from scratch if you intend the other to be around long term.
Best case you reimplement everything twice in both frameworks forever, or they diverge and you get diff behaviours in each over time (like adding swipe to delete).
Olivier Halligon:
Sooo... This is what’s likely behind that strange SwiftUI! 🕵️♂️
(you know, with no commas and still an if statement inside that StackV)
There’s now a forum thread.
David Smith:
Let’s see, names this project has had…
Pipelines
Dataflows
KVO2
PubSub
Combine
am I forgetting any? 😂
JP Simard:
I’m assuming the SwiftUI @State keywords are @dgregor79’s Property Wrappers currently being pitched in the Swift Forums.
Daniel Jalkut:
If you were lost when Apple used $ in $variableNames during coding demos, it comes from this addition to Swift.
Jordan Rose:
Yeah, it has too many system components to backwards-deploy, sorry. But it supports all the usual weak-linking / availability stuff, so if you want to mix-and-match for new views in existing apps you do have that option.
Jeff Nadeau:
Localized by default. In fact, if you want to display un-localized text from model data or internet sources, you use the Text(verbatim:) initializer instead.
Kyle Howells:
I’m actually incredibly disappointed that SwiftUI seems to be a new UI framework, not written on top of UIKit.
Declarative UI frameworks are great for simple straight forward UIs that fully their preconceptions. But if you want to violate those they are a massive pain!
If it was built on top of a normal imperative UI framework you could drop down to the real power of a normal framework instead of dancing through hundreds of hoops to make it work.
I’m fearful this will regress iOS UI into more bland plain simple UIs even further than iOS7.
Corbin Dunn:
I also worry about customizability.
Jeff Nadeau:
Most things are customizable (or will be when API lands). The controls do some indirection through a Style type that lets you implement whatever appearance and behaviors you want.
It’s just a matter of getting to everything since there are so many widgets on the Mac
Patrick Balestra:
Creating a brand new project in Xcode 11 doesn’t create a Main.storyboard anymore, everything is defined in code.
Joe Groff:
One place Swift really helps with performance compared to other Reactish frameworks is the type system. The static subset of the view graph is encoded in the type system, so the runtime knows it can’t change and only has to diff the dynamic parts. 120hz update was a P0 goal
Daniel Jalkut:
It’s still sinking in for me that Apple effectively deprecated ALL of their UI frameworks yesterday. Mac, iOS, tvOS, and watchOS developers are equally displaced.
See also: Hacker News.
Kyle Howells:
Two things Swift (and looks like SwiftUI now too) fall down on is lack of understandability/predictability and reasoning about perfo; and being seemingly simple but having a very steep difficulty curve when you get into the details.
Zhuowei Zhang:
Apple: Swift is a system programming language that can replace C++
Also Apple: writes new #SwiftUI library in C++
In fairness, most of SwiftUI is written in Swift! It’s just the scenegraph that is in C++. I wonder why they did that. Is there an older library that they reused?
Jeff Nadeau:
SwiftUI does not require Catalyst (it interfaces with AppKit directly on macOS), but it does work in Catalyst apps if that’s what you’re building.
Russell Ivanovic:
iOS Devs: “ha ha only 10% of Android devices are on the latest OS”
Also iOS Devs: “I can’t touch SwiftUI for another 2 years because I have to support older iOS versions”
Android Devs: “Oh Google shipped a new framework? I’ll update my AndroidX package and start using it today”
Update (2019-06-20): Jeff Nadeau:
A feature of this screen I took from today’s Introducing SwiftUI talk, and something I think will be very typical.
Look at the shape of the code: state, var body, and functions. The body is all nouns, and then all of the verbs follow in separate functions.
Personally I think this separation is wonderful. It keeps the event-reactive code out of the DSL and very cleanly demarcates “deciding what to show” vs “deciding what to do”.
Rob Mayoff:
Order of modifiers in SwiftUI view impacts view appearance
[…]
It is better not to think of the modifiers as modifying the MapView. Instead, think of MapView().edgesIgnoringSafeArea(.top) as returning a SafeAreaIgnoringView whose body is the MapView, and which lays out its body differently depending on whether its own top edge is at the top edge of the safe area. You should think of it that way because that is what it actually does.
Jonathan Wight:
Quick example.
This is NSOutlineView uses a SwiftUI HStack (or rather many…) for each row.
The (unoptimised, in need of a refactor) method for outlineView(viewFor:item:) is shown.
I think this code plays to both Cocoa’s and SwiftUI’s strengths
Majid:
I will try to show you real-world app example written entirely in SwiftUI. Let’s build an app searching for Github repos. We need a screen with a text field for typing a query and a list of repos which comes from the search query.
John Sundell:
Declarative UI programming patterns have become incredibly popular over the last few years. On the web with frameworks like React and Vue.js, in cross-platform development environments like React Native and Flutter, and through native tools like RxSwift and RxCocoa — declarative UIs and the reactive principles behind them have truly taken many development communities by storm.
It’s therefore especially exciting to see Apple step into this scene, with their own, completely native declarative UI framework — called SwiftUI. While there’s a ton of functionality to be discovered and experimented with in this new UI framework for all of Apple’s platforms — let’s start by taking a first look at some of the fundamentals of SwiftUI, and how it lets us drastically reduce the amount of code needed to produce common forms of UIs and interactions.
Rui Peres:
First, how I feel as a developer and as a person that has dedicated a tremendous amount of time to FRP* (both as a dev, contributor and evangelist). The release of Combine is the realization that the investment I have been making all these years made sense and it's also the confirmation that the industry is moving on this particular direction.
Adam Sharp:
Combine has very different thread safety guarantees than I’m used to coming from ReactiveSwift, which goes to heroic effort to ensure that events are always delivered serially, and never recursively.
John Sundell:
While it’s quite easy to initially look at SwiftUI as just a declarative API written right on top of UIKit (and in some ways it is), it’s so much bigger than that. While it’s true that, at the end of the day, any SwiftUI view hierarchy will get resolved into some form of UIKit/AppKit/CoreAnimation representation — there’s not a simple 1-to-1 mapping going on here.
Dave Abrahams:
SwiftUI layout isn’t a constraint system—or you could say we just have one-way constraints between parents and children. Most of the time, that’s enough, but if you need generalized constraints you can bridge views to UIKit and use autolayout.
Joe Groff:
The eventual goal is to allow all your UI code to be done in SwiftUI. Whether and how things map to UIViews is subject to change
Daniel Jalkut:
I’m going to throw some more worms into this compost bin. Another huge “mind blown” realization I had (with help) today: SwiftUI means “views” are essentially free. Zero overhead. Declarative UI is as cheap as any other struct. Huge shift from UIView, even more from NSView.
Shai Mishali:
Myself, and Gett, are heavy users of RxSwift — so as part of my learning process, I’m trying to make a map of things that correlate directly between RxSwift and Combine.
Casey Liss:
In order to discuss a Combine, one has to discuss the main differences between it and RxSwift. To my eyes: there are three.
Matt Gallagher:
Apple’s Combine talk at WWDC didn’t mention “reactive programming” or any background to the field. When presenting functions with the same interface as standard reactive transforms they said “we’ve designed”. It was the most blinkered, isolationist talk I’ve seen.
Bruno Rocha:
The new Swift features that are spawning out it are also game changing, and I for one am ready for the addition of new compiler black magics into Swift.
Chris Eidhof:
SwiftUI still seems to be full of bugs, making it hard to learn. You don’t know if it’s you making a mistake, or the implementation. Here’s another one[…]
Eric Lewis:
There is so many gotchas in SwiftUI. Especially around lists.
Wil Shipley:
The other (real) complaint is there’s no good reason this was secret. It’s not like Apple just invented reactive programming. This could have been done with community input.
Apple’s making this common mistake where they’re like, “Oh boy, we created something amazing with help from a huge community working together — now we should add our own private surprise stuff because surely we know better than everyone else in the whole world combined.”
Brent Simmons:
The future of app-making looks more and more like web development. Declarative. Semantic. Dynamic — adapting to context (interaction styles, accessibility settings, screen size, etc.). Runtime-editable.
Andrew Pontious:
I’ve never seen an abstraction layer high enough up to make cross-platform apps work well enough to be something I’d like to use for native apps.
Everyone keeps trying to reinvent the web, but for native, this time.
But the web exists for a reason. It was supposed to give us cross platform functionality without being native. And it works!
[…]
Apple fought cross-platform layers for so many years! And we cheered along with them!
And now, suddenly, due to their own strategic moves, they have too many platforms to develop for individually.
Same problem they brushed aside when it was only our problem!
Paulo Andrade:
While I’m very excited about SwiftUI, this type of stuff is what scares me most about letting the framework “do the right thing”. Sometimes you might want a slightly different behavior than what the framework does and you’re down the rabbit hole trying to make that happen.
Craig Hockenberry:
This is exactly why I think Apple has a HUGE advantage over other systems. Their solution must adapt for interaction sizes as small as a watch face and as large as a TV screen. That requirement means it must be control independent, thereby allowing a native platform feel.
Brent Simmons:
I have not watched WWDC videos so avidly, and with so much glee, in a decade.
Brent Simmons:
I’m surely not the only person to think, all week long, that this WWDC marks the end of Apple’s NeXT era and the beginning of the Swift era.
Matt Gallagher (tweet):
This article will look at how SwiftUI’s approach to declarative views compares to CwlViews, why the two approaches differ and what Apple changed to make this possible.
[…]
Long term, SwiftUI will be good but it’s going to be years of transition before most projects have a minimum deployment target of iOS 13 or macOS 10.15. As with the first year or two of Swift development, I expect a lot of hastily started, poorly implemented and quickly forgotten projects. The SwiftUI implementation, its API and associated tooling are likely to change rapidly as serious bugs and gaping holes are patched.
Colin Cornaby:
SwiftUI is amazing because it doesn’t feel like there are any losers. It makes the Mac better. It makes the iPad better. It makes the iPhone better. Heck, it even makes the Apple Watch and Apple TV better. I’m thinking about ways to ship apps for the TV and Watch, and I never would have considered that before. I even have Mac apps I might bring to iPad. I didn’t want to give up the power of AppKit on the Mac, and I didn’t want to maintain two separate code bases. Now I don’t have to choose.
Craig Hockenberry:
Something I haven’t seen discussed: how size classes will be handled in SwiftUI.
I realize it’s still early days, but this is a pretty important aspect of devices like the iPad, where screen real estate varies widely.
“Just add some conditional logic” hurts the abstraction.
Steve Troughton-Smith:
SwiftUI is really great for AppKit developers because it does give them a path forward that is cross-platform and isn’t ‘port to UIKit’. But I don’t see SwiftUI currently capable of replacing complex AppKit-specific Mac UI any more than UIKit; that could be some years out
Erica Sadun:
In fact, as a developer, I’m not happy about not having direct control over the tightness of either layout or an obvious way to relate ZStack siblings. If there’s a way to describe how much content hugging I want in a ZStack layout and how to prioritize which item in that layout should guide the others, I haven’t discovered it. If you have, please let me know!
Craig Hockenberry:
But I think there’s something important to add to his note: the SwiftUI DSL describes the most capable environment. It’s the maximum interaction surface: platforms will render and react to a subset of what’s declared.
Colin Cornaby:
Are master/detail editable views a problem in SwiftUI right now? If you have an array of structs, and a detail view that edits one of the structs, there’s no way to commit the edit to the master array it seems like.
Joe Heck:
Color, Layout, and graphics design are all clearly customizable with SwiftUI. I also expect that some of the crazier innovations (such as the now common “pull to refresh” gesture) will become significantly harder to enable from declarative structures. By its very nature, the declarative structure will make the common, well established UI elements easy and accessible, so much so that I wouldn’t be surprised to see a lot of early SwiftUI apps to “all look alike”. I expect the impact of “all looking alike” to drive a number of IOS dev teams a bit nuts.
The “escape hatches” to do crazy things clearly do exist – and while I haven’t reached that level of learning with SwiftUI, it does seem to follow the “make easy things simple, and hard things possible” concept of progressive disclosure.
It will be interesting to see what happens this fall when the first SwiftUI apps become available as experiments and where that takes consistency and usability on the Apple platforms.
Tanner Bennett:
It seems every single WWDC session on SwiftUI and Combine I’ve watched have managed to avoid talk of graceful error handling.
If someone could please point me to some resources on this, I would be very greatful. For example, displaying an alert when refreshing a feed failed.
Drew McCormack:
One thing I won’t miss is autolayout. Feels like the layout system in SwiftUI is an admission that autolayout was a dead end. It can live out its days with Garbage Collection and Java Cocoa. (Or perhaps it will remain, but only as an implementation detail.)
Kuba Suder:
Prepare to feel like you’ve just started learning Mac/iOS programming… This is a completely new thing which works in a completely new way, and it’s hard to switch your brain to a new mode. You will be thinking “How the hell do I do X” every step of the way.
[…]
Long term, I imagine the way it’s going to work is that SwiftUI (and possibly some related new frameworks) will gradually take over more and more parts of the underlying platform UI frameworks, to the point where they eventually just disappear. We’ll be writing a single codebase with SwiftUI and it will render differently on each platform, with some customizations required for each platform, but it’s possible that we’ll need less and less of those going forward, as the framework will get smarter.
Jaanus Kase:
In the old UIKit/AppKit world, view controllers were a central building block, and did a lot of manual shuffling between view and model. In the SwiftUI world, the view binds directly to the model, the glue is gone, and I have yet to figure out if there is any “logic” left which previously lived in ViewControllers and would still need to exist, or can I just forget about the whole ViewController concept.
Guilherme Rambo:
So apparently the way Apple found to hide SwiftUI (Amber) from the eyes of curious engineers was to implement it in a framework called “TimerSupport” lol
Drew McCormack:
Rather than hacking a DSL into the Swift language for SwiftUI, I think I would have preferred they add a data format based on Swift syntax. Like JSON is to JS.
Joe Groff:
We’d considered this. The problem with that for UI, and historically with nibs, is that if you outgrow what the data language can do, then you’re stuck rewriting a programmatic UI. By using code, the DSL, mix regular and DSL code, and also DSL and Kit components
About-SwiftUI:
The goal of this repository is to gather all this information having an unique place where looking for info about SwiftUI.
Update (2019-06-24): Mike:
Hmmm, looks like CareKit uses Combine and CoreData as a local database…
And this project is open-source so you can get a glimpse how to use Combine in the wild!
Jeff Nadeau:
The SwiftUI Environment is extensible, if you want to propagate your own custom values hierarchically. Once you define a property on EnvironmentValues, you can push new values using the .environment modifier and a KeyPath to your property.
Update (2019-10-13): David Smith:
Well, the final version [of Combine] that actually shipped isn’t my work, but the original concept is simple enough: make KVO composable, then strip it down to just the most core concept (data streaming) by replacing all the options and parameters with composition.
My first prototype was an alternative to NSFileHandle of all things, but some friends on another team were like “you know if you replace all those NSData*s with ids it looks a surprising amount like something we were prototyping, let’s join forces”.
Auto Layout Catalyst (Marzipan) Cocoa Cocoa Bindings Combine framework iOS iOS 13 Key-Value Observing (KVO) Localization Mac macOS 10.15 Catalina Programming ReactiveCocoa Swift Programming Language SwiftUI tvOS watchOS Xcode
Apple:
Power to change everything. Say hello to a Mac that is extreme in every way. With the greatest performance, expansion, and configurability yet, it is a system created to let a wide range of professionals push the limits of what is possible.
Function defines form. Every aspect of Mac Pro is designed in pursuit of performance. Built around a stainless steel space frame, an aluminum housing lifts off, allowing 360-degree access to every component and vast configuration. From there anything is possible.
I thought Apple wouldn’t listen and would find a way to screw this up. But it looks really great. Besides the core features like lots of processor cores and PCI slots, there are so many nice touches, from a couple USB-A ports to the rounded handles and the rotating, height-adjustable stand for the 6K matte display.
Joe Rossignol:
The new Mac Pro will start at $5,999 with an eight-core Intel Xeon processor, 32GB of ECC RAM, AMD WX 7100 graphics, and 256GB of SSD storage.
However, it’s way more machine—and price—than developers need. (And only 256 GB of storage for the $6K base model—when the base iMac Pro has 1 TB?) Similarly, the Pro Display XDR looks amazing, but I would like to have a more affordable 5K one to put next to my iMac.
I’m also not exactly sure what the situation is for internal storage. It looks like there are two slots, but I don’t know whether they are proprietary or can be upgraded after purchase.
Previously:
Update (2019-06-03): Drunken Dogcow:
The PowerMac G5 base price was $1,999 (or around $2,700 adjusted for inflation). $6,000 is incredibly insane.
Update (2019-06-04): Rory Prior:
Of course on the PC side you can buy a workstation for dramatically less money to suit your budget. With Apple you’re either all in or you’re stuck with either a ‘throw away’ iMac Pro at the high end or pay through the nose for a weakly specced mini.
Timothy Wood:
I love the annual Apple hate day. Today’s favorite is the complaining about the $1000 discount you get if you go with the VESA mount option and get your own damn monitor stand for your deep color super bright 6K display that’ll last you 15+ years (my current Apple display is 17!)
Jack Brewster:
Saw a comment about “don’t complain about Mac Pro pricing Apple didn’t build it for you” which feels like the wrong take.
It could have been for me, too. But Apple chose not to make it that way. It’s a flexible, tower computer. It could have been many things to many customers.
Scott Anguish:
Apple could have released a monitor targeted to 10x more users that matched the iMac/iMac Pro 27” and 5k and we’d have been ecstatic.
David Owens II:
The blower-style exhaust fan looks pretty cool... I wonder how dust is handled though. I didn’t see any dust filters.
paulc:
There sure is a LOT to say/question about this new machine, but my central one is how in the blazes can they call this a REAL pro machine if it’s not capable of running CUDA? Far as I know, CUDA is a very essential part of a LOT of actual professionals…
Mark Gurman:
I need help deciding between an iPhone XS and the stand that’s required to hold up the new $5000 Apple monitor.
Greg Titus:
“Detach. Move. Attach.”
Wait. So the display MAGNETS to the stand? People are going to get two $1000 stands and carry their 32" display in between them?!?!
There is going to be that one guy who gets their local coffee shop to install a stand for them at a table, isn’t there?
Wojtek Pietrusiewicz:
Dear @Apple @pschiller @tim_cook — this but with a Core i9, industry standard M.2 NVMe SSDs, and support for “regular” GPUs. And a normal price tag.
Ryan Jones:
Apple 100% DID abandon Pros!
“Everyone” was right.
And “everyone” saying it is 100% the main reason for today.
The community voicing and explaining concern saved Pro. 100%
Colin Cornaby:
The first third party MPX module was already quietly announced by Apple
Felix Schwarz:
Internal #MacPro SATA port mystery solved! Promise will make an enclosure that attaches to them: the Pegasus J2i with two 3.5" SATA drives. Promise will also make an MPX module, the Pegasus R4i with four 3.5" SATA drives. In total, that'd enable up to 10 internal HDDs.
Marco Arment:
Here (at 6:53) you can just barely hear what Jony was explaining to Tim about the new Mac Pro as I awkwardly stood behind them
Michael Pusateri:
Finally, I can tweet knowledgeably on a topic, the new Mac Pro & display. I help oversee 175+ Macs used for professional video editing, audio mixing, and graphics creation. Here’s a ‘hot take’ on the new Mac Pros.
Eric Young:
The new Mac Pro is the exotic flagship model. It’s the best computer money can buy. It’s the super car of computers
It’s not about need. It’s about want
I don’t need a McLaren or a Ferrari. I want a McLaren or a Ferrari!
Felix Schwarz:
According to specs, the new #MacPro ships with PCIe 3.0. Meanwhile, AMD ships Ryzen CPUs with PCIe 4.0 this year, doubling transfer speeds. Intel is rumored to start adopting PCIe 4.0 in late 2020. At these prices… may be worth waiting for it.
Ole Begemann:
The new Apple monitor doesn’t seem to have speakers or a camera built in.
Steve Troughton-Smith:
We entered WWDC without Apple offering a modular desktop that meets our needs, and we’re leaving WWDC without Apple offering a modular desktop that meets our needs. They clearly don’t have enough developers in their focus group, so the Mac Pro is a major failure in that respect.
See also: Accidental Tech Podcast.
Rick Gigger:
I know I’m not their target customer. I want to be. I want them to make a monitor they fits the needs of normal professionals, not just people doing high end video work.
See also: Hacker News (3), Rene Ritchie, Jason Snell, Joe Rossignol, Tim Hardwick.
Update (2019-06-06): Stephen Kampff:
Unfortunately, reference monitors aren’t all the same, and newer standards like HDR10 and Dolby Vision can only be achieved with a certain class of display. That wouldn’t be a problem if these things were cheap, but an industry standard Flanders Scientific monitor will seriously set you back, and you'll want it to last years. A Flanders that’s comparable to Apple’s Pro Display XDR would cost $35,000 and would be 4K instead of 6K.
A side note here that I prefer a true 16x9 4K reference monitor so there’s no upscaling from a 4K signal. Still, 6K is impressive and will be amazing for photographers.
Mac Power Users (MacRumors):
Stephen and David have boots on the ground in San Jose for WWDC 2019. In this episode, they interview Doug Brooks, the Apple Product Manager for the new Mac Pro.
Marques Brownlee:
Pretty sure this whole “Apple Pro stand costs $1000” rampant headline would’ve been avoided if on stage they just said
“Apple Pro display XDR costs $5999”
And then when the config site goes live in fall they have an option that says “ship without stand” and it drops to $4999
Colin Cornaby:
It's a Xeon workstation. What did you think it would cost? Apple was absolutely right that its price competitive. Things have changed since 2012.
Sam Deane:
The confusion comes from different definitions of “pro”.
For me it means a machine designed for people who want to replace components. Something I can put a new graphics card into and upgrade the memory and drives later.
Powerful, but not ridiculously so. Just flexible.
Nick Heer:
These prices and the ridiculous capabilities of these products are exclusive in the truest definition of that word. They exclude huge numbers of customers who either cannot afford to spend over $12,000 on a new computer and display, or do not need such high-end capabilities. I think that’s okay. The iMac Pro remains a very capable machine for all but the most demanding users.
Greg Koenig:
That’s the thing- the intro price is eye watering for a poor spec machine. I’ll bet not a single demo Apple touted can be done on a Mac Pro costing less than $12k (sans crazy display).
This is a great machine- but the low end needs $1500 off, and a 30" 5k display option.
scott:
Apple held an unprecedented roundtable with podcasters and bloggers to tell them how much they care about developers. […] Announcing that product at WWDC was a monumental insult to every single Apple developer.
Scott:
What does this have to do with the new Mac Pro? It shows me Apple isn’t thinking on all cylinders. The Mac community has been asking for a IIci since before the 2013 Mac Pro “Trashcan”. The new mini just doesn’t cut it. And the new Mac Pro doesn’t either.
Mike Zornek:
I truly believe they should have revealed this MacPro and monitor at a proper video / media conference. Revealing it in front of developers who can’t afford it nor whom the product is marketed at just feel very out of context. We were begging them to built us a tower and display, but they built them for someone else, and it’s kind of depressing.
[…]
I wanted a $5000 tower where I could update the graphics cards a few years in. I don’t need 8 PCI slots, maybe 4 or 2 would work. I wanted to have easy access to RAM to add more in the future (I don’t need 12 slots I’m sure 4-6 would be fine). I want multiple SSD slots on the board (2 is fine). I want to be able to open it up and clean out the dust every few months (this is why an iMac will never work for me).
I wanted a $1000 self-contained version of the 5K iMac display. Maybe an ultrawide version? I like Apple monitors historically. They work great out of the box and have great color. Surely there is room in the market for a sub-$6000 Apple monitor for the “rest of us”?
Jon Alper:
The power of the Mac Pro 2019 summarized perfectly:
“With the head of software engineering right here at our disposal for an hour, I can’t think of anything better to talk about than…hardware” - @gruber
See also: Hacker News.
Update (2019-06-17): Paul Haddad:
We are now living in the time of the < $100 1TB high performance SSD!
If you don’t buy from Apple.
Jeff Johnson:
Interesting theory from @tytus_s is that the new Mac Pro was never for developers at all, and Apple only started to work on it when they started to get into the movie and TV making business and got pushback about it from showbiz people.
This makes sense, although it raises the question of why Apple specifically made the point at the 2017 media event that developers were their largest pro audience. That—and the history of sub-$2,000 Mac towers—is why developers expected the new Mac Pro to be “for them.” Apple even continued this in the 2019 Mac Pro’s announcement (to a room full of developers), presenting the Pro Display XDR as great for writing code.
The display is actually the main problem for developers. The Mac Pro costs a little more than people expected—given the iMac Pro. But the display does a lot more and costs a lot more than the type of display developers need. And, with LG exiting the market, there isn’t really a suitable non-Apple display available that’s 5K and the right Retina resolution for iOS/Mac development.
Colin Cornaby:
Just for fun I spec’d out a Dell workstation comparatively to a base 2019 Mac Pro. The Dell still has slower storage and less PCIe slots.
Rory Prior:
It’s just a shame they don’t make a box with an i9, at least 1x 16x PCIe for a GPU of your choice, upgradable RAM and storage. That would be the perfect system for 99% of pro users, power users and developers who don’t need workstation level components.
Bryan Pietrzak:
Apple has iPad mini, iPad, iPad Pro. MacBook Mini (Air), MacBook, MacBook Pro, iMac and iMac Pro, and Mac mini and Mac Pro. Seems like a mid range "Mac" computer in the same case, but i9 cpus, ddr ram, fewer PCIe slots, smaller power supply price point around $3-$4K could work
And they have Pro Display XDR, let's see an Apple Display 5K that takes the 5K iMac panel, 27" (or maybe 32"?) with stand and typical ports (including power delivery) for $1599 would selll very well
Helge Heß:
People who say that the new MacPro is not for developers are ObjC dinosaurs and never worked on a large Swift project (or a C++ one, like CLang).
Bob Burrough:
If a solution is inaccessible to you, it doesn't matter whether the reason is technical (e.g. poor thermal management) or financial (e.g. exorbitantly overpriced). Your problems remain unsolved.
Jean-Louis Gassée (Hacker News):
The gods who render mad those they want to destroy have struck again. They’ve caused a marketing exec — we hope not the same one who bragged about innovation in 2013 — to price the new XDR monitor stand at a baffling $999. Listen to the guffaws in the audience at 1hr 40 mins into the keynote video. Why not $399 instead and increase the MacPro base price by a barely visible $600?
A friend points out two factors. One, Mac Pro configurations will probably be used with multiple XDR monitors mounted in a bay arrangement using relatively inexpensive ($199) VESA mounts. Two, businesses and production companies are less price sensitive than the developers in the WWDC audience.
These are reasonable points, but good marketing deals with emotions and impressions, not mere reason. The $999 stand was widely mocked in the media, Apple was labeled as greedy and tone-deaf — the latter definitely deserved.
kingtbird:
Heya @atpfm @marcoarment @siracusa @gruber maybe your ear w/ Apple can find out why the $6K Mac Pro has slower read SSDs than 2017 iMac Pro & 2019 MacBook Pro:
3.3w/2.8r iMac Pro
2.2w/3.2r MacBook Pro
2.7w/2.6r Mac Pro
AFAIK slightly faster than 2017 & 2019 iMac 5K 2.5r/2w
Marco Arment:
iMac Pro uses two SSD modules in parallel for all sizes. Mac Pro uses just one in the 256GB config, two in the higher ones.
Also maybe relevant: I don’t think iMac Pro uses a PCIe switch to offer more total lanes than its CPU, but Mac Pro does. Maybe SSD bandwidth is reduced.
Ed Cormany:
When Apple announced the new Mac Pro last week, one of the things that got the most attention was its price tag: the base configuration will cost $5,999. The question is whether it’s an outlandish price for what is far and away the most powerful Mac ever sold. The fact is that Apple has definitely charged that much in the past for its hardware.
The graph above shows the base prices for 60 different Apple hardware lines, and how those values compare over time accounting for inflation.
Tom Nelson:
Will additional MPX modules be available in the near future? And will they only be available from Apple, or will other peripheral manufacturers be able to make use of the MPX system?
MacRumors:
IKEA has joined in poking fun at the new Mac Pro… 🧀
John Kheit:
The entirety of the Mac press’ post-WWDC rationalization distortion field is: “the computer for the rest of us”, “it’s not for you.” After receiving Apple’s PR fluffjob, these pundits make straw-man arguments that people think the Mac Pro is bad because it’s too pro, too powerful, or not cheap enough. They ignore what enthusiasts are saying: “Apple please add a lower entry level slot upgradable model that enthusiasts can also afford.”
Accidental Tech Podcast discusses how the Mac Pro effectively does have internal drive bays.
Update (2019-06-25): Marco Arment:
These are the CPUs used by the Mac Pro. Note Intel’s pricing.
The “M” variants (which cost twice as much) are needed to support >1 TB RAM configs.
Bole:
There is zero chance that the Afterburner card is “$1K …$1.5K”, as Marco guessed.
To give you context, similar accelerator card produced by Red is almost $7K…
And programmable ASIC that are comparable are in the $9K-15K range.
Update (2019-07-05): Lloyd Chambers:
Kudos to Apple for what looks to be an extraordinarily robust and quiet ultra-high end pro-grade workstation.
[…]
Looking at the specifications, it’s not clear that the 2019 Mac Pro will be faster [for photographers] than 2019 iMac 5K—the Mac Pro might be slower, particularly with the entry-level 8-core CPU. That’s because for most tasks in Photoshop and Lightroom, only a few CPU cores are used and so what matters is clock speed for the cores actually used—and the Xeon processors run about a gigahertz slower.
My prediction is that it will be a mixed bag with the 2019 Mac Pro much faster for a few tasks (and only if configured-up on CPU/GPU), and slightly slower for many tasks.
Update (2019-07-19): Andreas Storm:
Apple updated the Mac Pro icon.
Update (2019-09-27): See also: Hacker News.
Display Icons Mac Mac Pro macOS 10.15 Catalina Pro Display XDR Thermal VESA
Neil Sardesai:
“AppKit is our primary native framework and it takes full advantage of all the Mac has to offer. And in no way are we de-emphasizing that.” —WWDC 2018, Platforms State of the Union
Craig Hockenberry:
Cross-platform frameworks have a long history of sucking. If you ever used a Java app during the early days of Mac OS X, you know immediately what I’m talking about: the interactions were from a different universe. The design of the system was a “least common denominator” where only a limited set of capabilities was exposed. It just felt wrong.
[…]
Apple’s been down this road before and I don’t see them making the journey again. Instead, I see them taking a new and forward thinking direction. A bold and pragmatic change that Apple is famous for: they’d be setting themselves up for the next decade of user interaction.
[…]
I’m not going to predict how this would be accomplished. Yes, it could draw inspiration from React or other similar technologies. The only thing I’m confident of at this point is that Apple knows it has a problem and is working actively to solve it in a platform-independent fashion.
Marzipan is our first step. And what I’ve described above is Amber, the next step.
Brent Simmons:
I’m kind of unsure that leadership at Apple understands what’s great and important about Macs that we should not lose.
Evolve, change, yes — but not become a supercomputer with its arms tied behinds its back. That’s what I worry about it.
Riccardo Mori:
Also, as a consequence, I fear that the Mac App Store is going to become more like iOS’s App Store in every way — with thousands of crappy apps, and terrible pricing trends. Where by ‘terrible pricing trends’ I mean the race to the bottom on the one hand, and on the other hand an increase in subscriptions as the only payment method even for simple utilities and single‐purpose apps. (I hope more people realise how subscriptions aren’t sustainable on a large scale for customers).
I fear that iOS is going to become the new model that dictates how the Mac user interface has to behave. That Macs are going to be considered just as ‘big iPads’, and that paradigms and behaviours that are tailored for iOS and belong to iOS come to replace those paradigms, principles, and behaviours that made the Mac’s user interface great.
[…]
I’m all for change if it brings unequivocal progress. But I’m afraid that Mac OS is getting repurposed and repackaged more to fit inside an agenda than to keep thriving as a platform with its history, characteristics, and unique features.
I’ve experienced firsthand all the transitions the Mac platform has gone through, and this is the one that’s leaving me the most apprehensive. Because all past transitions brought clear advantages to the Mac, either from a hardware or software standpoint. The signals were of progress for the Mac platform; or, at the very least, of having to take a step sideways to then take two steps forward. This time it feels that things have to change simply to benefit the advancement of another platform.
Dieter Bohn:
The apps are not good. I think Apple should make more of them.
In fact, I think Apple should do more than double down on these iPad-style apps on the Mac. I think Apple should go all in and make nearly all of its consumer Mac apps with the new UIKit / Marzipan frameworks, including Mail, Notes, Messages, FaceTime, Photos, Reminders, and Calendar. Apple should just go for it, sooner rather than later, and ideally right now.
My reasoning is pretty simple: whether you think these apps should be the future of macOS development, they’re absolutely coming either way, and Apple should want to ensure that they’re great.
[…]
I worry that Apple could find itself facing an analogous (though not parallel) quandary to what Microsoft has faced with its own next-generation Windows app framework. Called the “Universal Windows Platform,” it has been fraught with changes in direction and complaints that it was too limiting. It took the company nearly half a decade just to decide what to call them. Worst of all, UWP saw very little adoption as developers stuck with the old way of making apps. Now, even Microsoft might not be very committed to them anymore. The best way to avoid that kind of confusion is to be clear and decisive from the start.
I’m also hopeful (perhaps naively so) that this new Mac framework will be powerful and flexible enough for many different kinds of apps.
Jason Snell:
Sort of like jumping into a cold swimming pool. I’m not sure Apple’s really that kind of company, but I hope that behind the scenes, Apple is ceasing development on the Mac-only versions of all of its consumer apps and instead pushing all future development to be done with Marzipan in mind. We might not get a Marzipan version of Mail or iMovie or Pages this year, but those need to be in the works.
Like it or not, Marzipan apps are the future of macOS—and they need to be good, or macOS won’t be.
If that’s in fact the future, it’s only because of Apple’s choosing. I simply don’t see the situation without Marzipan as dire. Mac are selling well. And what problems there are could be fixed in other ways—they’re not that the apps aren’t iOSy enough, more the opposite. Part of my pessimism is with the general idea of write-once-run-anywhere. But also, at the present time, I have low confidence in Apple’s ability to implement good rewrites of Mac software. What in theory may seem like an OK unification strategy, is actually quite risky because if they don’t do it well we’ll end up much worse off than if they’d just kept the Mac in maintenance mode for a while.
Damien Petrilli:
I see some tweets about electron Apps and marzipan.
But Apple is mainly responsible for it:
- driving quality of App down (and leading the way since iOS 7)
- making the app market unsustainable
- bad dev tools / documentation making it costly to do native dev
Marzipan is seen as one way to tackle this, but unless all the points above are addressed today, this isn’t going to change and could even get worst.
Steve Troughton-Smith (tweet):
I have been very vocal about why I think UIKit coming to the Mac is something to be excited about. There is so much potential in unifying the software ecosystem across Apple’s platforms, but to do it right you can’t stay on the fence like Microsoft did. For this to work, you need to own it, and you need to make it so good that it’s hard to imagine wanting to use or write any other kind of software. That is how iOS makes me feel, and that is how the Mac should make iOS users feel.
[…]
I really don’t think there will be a viable future for the Mac if Marzipan falls flat on its face. Apple’s dominant ecosystem is iOS — that ship has sailed. No new UI framework or declarative layer on top is going to change the arithmetic; any new app framework for the Mac will by definition have to be shared across iOS and Mac, or we’ll be right back where we started. By the time we’ve got to that point, there may not be any native desktop apps left, and iOS will still be accelerating into the future with new form-factors, augmented reality or whatever comes next. Even native app development titans like Adobe have a version of Photoshop in development for WebAssembly, and it’s hard to not see the appeal for developers. The web is amazing; WebGL and WebAssembly will enable all kinds of powerful new platforms.
Tanner Bennett:
Geez, I don’t know what planet Steve TS lives on, but just because one platform is more “dominant” than another (iOS vs macOS) doesn’t mean one is or should be totally left behind.
That’s like saying cars are the dominant form of transportation and we should just abandon boats.
Rob Griffiths:
I honestly wish Apple were bringing the Mac and iPad closer together by bringing more of the Mac to the iPad than by bringing more of the iPad to the Mac.
Jesper:
Apple is supposed to complete the curveball it threw all of us for in last year’s WWDC, when it started to say that iOS apps are not coming to Mac, and following it up by saying that instead, UIKit is coming to the Mac, presenting four new apps that looked like straight-up ports from their new iOS incarnations that had in fact not even been ports.
[…]
The reason I’m not wild about Marzipan is because wanting to use a Mac in the first place has always been about liking the way things are subtly different and subtly better. The Marzipan apps so far have been completely bled of this quality. They make the same mistake “Universal” Windows applications did, which is to believe that taking a touch interface and sprinkling keyboard-and-mouse adaptiveness on top of it is “enough”. It is “enough” for a dropdown menu to be one of those scrollable list pickers - the ones designed for a finger to swipe through on a constrained display, with haptic feedback guiding you. (This was UI that Apple actually shipped in an app that wasn’t just a major feature of an OS update but a flagship app of a new framework.) At least the UWP applications can more readily expect the screen on a laptop to respond to touch.
The thought of Marzipan being capable of delivering something Mac users will recognize and praise as Mac-like is laughable; the thought of it subsuming Cocoa to become the recommended default is offensive. Cocoa eclipsed Carbon because it was better at providing a Mac-like experience. For all the recent iOSsification of macOS, I still don’t see this being the case without extensive surgery. If anything, the way forward should have been a “Cocoa X”, designed from scratch with the learnings of both UIKit and AppKit/Cocoa in mind.
See also: The Talk Show.
Colin Cornaby:
Ok, final pre-Keynote Marzipan hot take: I find it funny when it’s put in terms of some emotional fight over legacy vs modern and looking down on people. I just want a tool that’s able to get the work done I need it to get done. Mac, iPad, whatever.
When there is a possibility or an actuality of the platform preventing you from getting your work done, or making it a lot more difficult, that’s a problem.
People who use their Macs to get a job done that they couldn’t do with another tool don’t care about opinions about legacy or whatever. A hammer is a legacy tool but people get important things done with them every day.
Previously:
Catalyst (Marzipan) Mac macOS 10.15 Catalina Programming
