After the Life and Death of Twitter for Mac episode, the recorders kept rolling and all the big brains — John Gruber of Daring Fireball, Loren Brichter of Tweetie, Paul Haddad of Tweetbot, Craig Hockenberry of Twitterrific, Ben Sandofsky of Halide, and Greg Pierce of Drafts — shared their thoughts on the rumored "Marzipan" iOS and macOS cross-development platform. Christina Warren of Microsoft joins to add context to everyone's hopes, dreams... and fears.
Rene Ritchie: ...do you have any feelings about Apple going more cross-platform, making UIKit work on the Mac, or replacing UIKit and AppKit with something that is more unified?
Loren Brichter: It's stupid not to. It doesn't mean that UIs have to be the same. The building blocks that are the same should be the same. The classes could be the same. You can refactor to a point. It doesn't have to be identical, but don't make it this hard. AppKit is old. It's NeXT old. I'm not saying it's bad, but it did its time.
Rene: Christina Warren, formerly of Mashable and Gizmodo, currently at Microsoft. Can I make a real-talk confession?
Christina Warren: Of course.
Rene: On the last episode with "The Life and Death of Twitter," I had all those big Twitter brains on the show. I asked them to stick around. I asked them about the idea of cross-platform iOS and Mac development.
Christina: Awesome.
Marzipan
John Gruber: It's one of those things. It's one of those rumors that's really intriguing to me, because it could mean anything. It's difficult to say. It stems from a Mark Gurman report sometime in the last month. There's just not a lot of detail in this report. Come WWDC in June, we can look back and say, "Yes, everything Gurman reported about this back in January was true."
We don't know if it's good news or bad news. Bad news would be literally just like being able to run the equivalent of what you see in the iOS simulator. Just have a little rectangle shape of an iPhone or an iPad that runs in a window. Every click is like a simulated touch, and that's it.
Anybody who's ever tried running an app, like an iPhone app, in the Xcode simulator, it's a great feature for debugging, but it's horrible for using. It's because it just doesn't mesh with the mouse-and-keyboard paradigm of the Mac. It never feels right to do that.
That would be the bad news. Just a lazy click of button in Xcode, and out comes an app that technically runs on a Mac, but doesn't look or feel or act like a Mac app at all. The good way would be if Apple...This is like the culmination of a years-long strategy within Apple of, "Hey, AppKit has evolved from 1988 and its origins at NeXT, through today, in 2018." Literally, 30 years. It's like the 30-year anniversary of AppKit.
It's evolved. Obviously, the big jump in the '90s, where it went from NeXTSTEP to OS X. They folded in and had to run alongside Carbon APIs. It wasn't necessarily continuous, but there's a lot of similarities there. I've talked to some developers who remember the NeXT era. I've said to them, "If you think you could point back to your old self and showed yourself modern AppKit code, would you be able to follow along?"
They were like, "Yeah, I'd be impressed by some of their stuff. Maybe I'd have a few questions, but for the most part, I'd get it." The reason a lot of people like AppKit more than UIKit, like Paul Haddad and others, is that when they created UIKit, they didn't just port AppKit over to run on a phone.
They, more or less, in 2006, took a, "OK. We've got 20 years of lessons from AppKit. What would we do differently today if we had it to do all over again? Because effectively, we have a chance here to do it all over again."
What I'm hoping they're doing for the Mac is drawing the same lessons of, "Here, we have another 10 years under our belt, 10 years of iOS development. What can we do for the Mac to modernize these frameworks for the next 10, 20 years, that would really make lives, the work of engineers as much easier today as they thought UIKit was than AppKit 10 years ago?"
Rene: My understanding, and it's one degree of separation, is that it's like Swift. It's like APFS, where Apple knows they need to do something. They have several candidate projects.
I believe the one Mark was talking about was Marzipan. That may not be the one they go ahead with. Just because they did do this rework, and they are doing the code bases, and now we have messages on iOS, it doesn't have feature parity with messages on the Mac.
This is a way to solve for that, so that their teams -- obviously, it will be good for some developers -- can be much more efficient, in terms of keeping things in sync and being consistent in what they put up.
Solving for Apple
Christina: I would agree with that. I think that you're right. You actually hit the nail on the head, which is that Apple is running into this problem themselves, which is that they have...Look, as much as Apple says publicly how much they care about the Mac -- and I don't doubt that, I never doubted that -- anyone who says they care as much about the Mac as they do about iOS is kidding themselves.
Rene: The way I look at it, and I understand completely that Apple has...and people never understand this. Every company has limited resources, because you're limited to the amount of engineers that are willing to work for the amount of money that you pay, and live in the area where you require them to live.
That's in the face of being able to work in places you prefer or getting start-up money with IPO potential. There's just always a limit on resources. I look at it like, it's almost like you have one kid, who is a grad student, he's away at college, and he's pretty self-sufficient, and another kid who's Taylor Swift.
[laughter]
Rene: You're making millions and billions of dollars. You've got to micromanage them every minute. If you have to choose, "Yes, I really want to be there to watch you sit at college, but we're on world tour in Patagonia right now." [laughs]
Christina: It's hard. You're exactly right. You don't have all the resources to do these things. That's why people oftentimes, I'm not going to say "have shortcuts" because that's not the right term, people will criticize something as, "Why don't you maintain native apps for all these different platforms?" and "Why aren't you making everything unique?"
The reason why frameworks like Electron are popular isn't because coders are lazy. It's because they don't have the resources to dedicate teams to maintaining these things.
Rene: One of the big examples to me is the Mac App Store. You know it, whenever an engineer is hired onto that team, it's like, "Aah!" In Philip Schiller's heart, he wants you to work on the Mac App Store. Practically speaking, every engineer possible on that team had to work on that big Apple App Store relaunch.
Maybe they'll go and work on the Mac App Store, which hasn't been updated in what? I don't know, five years. It's also possible that if a system like Marzipan or whatever the cross-platform framework that advances or replaces AppKit and UIKit, that would help everybody.
Haddad, Hockenberry, and Sandofsky
Paul Haddad: We already share all the low-level networking code, all the code that talks to Twitter. It would be nice to just be able to share more of the view side of things, more of not having to do the entire timeline over again on Mac, just because they're totally different frameworks. I'm not sure UIKit over on the Mac is the right solution or not.
Craig Hockenberry: Where I see it being really, really helpful is with people who are developing cross-platform apps. Right now, if you got a color in your app, on iOS, you have to deal with this thing called "UIColor." On the Mac, it's NSColor. They're slightly different. It's a pain in the butt to have to think about, "OK. I want red. Which kind of red do I want to make?"
You don't want to have to think about that. Same thing with simple things like table views, collection views and all the ways that data get presented. There's a lot of similarity between those two. Apple could save everybody a lot of time and effort if they focused on the view aspect to it.
Basically, every app is broken down into three major components -- the model, the view, and the controller. Every developer understands what those are. The model basically is your data. The controller is telling how things are supposed to work. The view is just the presentation of the data.
Right now, the [inaudible 8:02] for Twitterrific is our Mac and an iOS client. They share the model. The data that we get on the Mac and the data that we get on the iOS is identical. How we display it is different. The controllers are also a little bit different, because you're dealing with different kinds of ways of presenting the information.
If you could have a common view on Mac and on iOS that knew how to display a tweet, for example, that would save us...because we've got different codes for displaying a tweet on iOS and a different code on Mac for doing the same thing. If that code could be the same, we would have saved ourselves a lot of time and effort, just like we did with the model.
Having a model on both platforms was a huge, huge thing for us. We're already seeing that fixing a bug in the model is like fixing a bug in two apps. It's awesome. [laughs] It's like Sean -- my development partner, Sean Heber -- he fixes something there. He fixes something on the Mac, and he fixes something on the iOS at the same time. It's awesome.
The controller, that's the thing where people are just saying, "Oh, that will just magically work." Well, drag-and-drop works differently. Yes, they could probably make some of the drag-and-drop stuff work on iOS and the Mac better, more similarly. You have different types of information you can drag, being able to handle the menu bars and things like that. There's no menu bar, for example, in iOS.
Marzipan or whatever that code name for it, I can see that helping a lot for people building cross-platform stuff. I don't think it's necessarily going to be just compiling your apps for ARM32 versus ARM64 that will basically flip a switch and, "Hey, it works." It's not going to be like that.
Ben Sandofsky: Every year, I cross my fingers, hoping this WWDC is when they announce that they're actually unifying that layer. At the end, having that layer wouldn't have guaranteed that Twitter for Mac would still be around. By not having the layer to share more code guaranteed that it was always going to be drifting away, in terms of consistency. It would just be insurmountable.
The greater discussion, and I see people talking about it like, "Well, there's nothing wrong with the Mac as a platform." AppKit is fine. It's great. Sure, it's got some legacy stuff. At the end of the day, there are just so many inconsistent-enough things for no good reason, just like the coordinate system is flipped upside down. OK.
When I was maintaining the Mac app for a while, I wanted to get in localization for Japanese and Chinese. There was an obscure bug in AppKit that was, after talking to Apple engineers, like, "Oh, that has to do with the Carbon background." I'm like, "Oh, OK."
It's just like all these little death by a thousand cuts, when there's no reason -- for the core logic, the basic tweet rendering -- you shouldn't be able to just say, "OK. Now drag and drop this into a Mac project. You get all the, at least, visual design."
They can still stop short, similar to tvOS. tvOS, it's not based around a touch interface. It needs you to use the focus engine. If you're building a Facebook app or an Instagram client, you can reuse all the rendering code. You can reuse all the lower-level stuff.
You have to bring yourself that last mile to figure out what's the best way to interact with it, using a remote control. As long as Apple stops short of true cross-compilation, it's going to be outstanding.
Desktop apps in a mobile world
Rene: Some of the feedback or some of the reaction to Twitter exiting Mac was that, "What does it mean for Mac as platform?" It was a little doom-and-gloom-ish. I looked. Twitter pretty hard-exited the Windows platform as well.
Christina: They did. In fact, they exited the Windows platform earlier. The metro-style Twitter app is still in the Microsoft Store. You can have it work on your start menu or whatever. TweetDeck for Windows, which was a separate Windows app, stopped being bundled over or packaged separately quite some time ago. I think it was a couple of years ago.
You can obviously still use it in Chrome or whatever browser you choose, but it stopped being distributed directly. There's an app called TweetIn, which is basically TweetDeck. They've added a couple of native things, notifications and whatnot. It is in the Microsoft Store.
By and large, other than the very rudimentary Twitter for Windows app, which was never as robust as Twitter for Mac, they've already started exiting desktop, even before it left the Mac app store.
Rene: I was thinking, this is less a, "What does this mean about the Mac and the future of Mac apps?" question -- to me, at least -- and, "What does this mean for desktop and the future of desktop app?"
Christina: I would agree with that 100 percent. It's much less a Mac-specific focus, doom-and-gloom mode, or "The Mac is a dead platform." That being said, I do think that it becomes a very fair question, which is to say, "What is the current situation for desktop apps, in general?" If I'm being totally honest, I feel like the heyday of a lot of native apps on desktop is over, sadly.
Rene: Let's stop to think about it. I talked to John Gruber about this, too. When I stop to think about it, all of the big apps, the apps that I would consider world-changing on small or bigger scales recently, they've been mobile first, or at least web first and mobile first -- things like Instagram, things like Uber and Lyft.
Even the wonderful updates we've had on desktop software, things like Final Cut Pro, Pixelmator and Microsoft Office, those have been updates to old apps, not new apps, that are revolutionizing things on the desktop today.
Gruber: To draw a rough analogy, it's like sports. You need your kids to be playing a sport for the sport to maintain popularity. If all of your favorite players in a certain sport all are in their late 30s, and there's the 22-year-olds coming up on a dare because they're playing other sports that have become more popular, it's a problem.
Christina: Exactly. A great example of that is something like Slack, or to put in a plug, Microsoft teams, which is our Slack competitor. Atlassian has another one, Stride. Those are web first. Obviously, people packaged them using Electron, which is the most common framework. We could use anything. There are a lot of it here.
Google has led the effort. A lot of other companies are supporting it with progressive apps for offline access, cache, and things like that. You're right. When you really look at what have been the biggest services, platforms, apps, experiences over the last five-or-so years, the vast majority have been either mobile first or web first.
Rene: It's super interesting to me, because when you look at Microsoft and Apple, both of them have legacy desktop operating systems. Currently, they have almost opposite problems. Microsoft was never as successful in mobile as they were in desktop. They've worked on universal apps that would let them bring Windows over to mobile.
Apple was far more successful on mobile than they ever were on desktop. Now, there's rumors that they're looking at ways to help bring iOS apps to the Mac.
Christina: I don't have a lot of experience with it, to be honest, but I talk to a lot of developers. They think that on the universal, Windows App Store is pretty complex. It started as a way to bring Windows desktop apps to mobile. It shifted to saying, "OK. If you have more of a traditional x86 app, you can put it in a wrap. You can use this bridge."
You can bring it to the Microsoft Store, so that it can run on other devices, including things that run Windows S, potentially even other mobile platforms, and potentially, down the line, Windows on ARM and things like that.
Now, it's opening up even further, where a couple of weeks ago, the Microsoft Edge team announced support for progressive web apps, as well as the fact that in the next version of Windows 10, progressive web apps will be available in the Microsoft Store.
That's a pretty big deal, because that means that people who are building progressive web apps for Chrome, or whatever the case may be, can now actually have these packaged, delivered and live on the desktop. You can interact with them like they were a desktop app.
Some people are saying, "No. Progressive web apps mean that UWP is dead." It's like, "No. They can work hand in hand." It just depends on what tool and what situations are better for what users. It's been interesting to see that approach.
When it comes to Apple, the challenge will be, frankly, that for all the good and bad things you can say about having touch available on Windows, the fact remains is that, for going on five years now, Windows -- starting with Windows 8 and now through Windows 10 -- has supported touch inputs. There are good and bad things about that dual approach.
Apple is always taking a very separated approach. Whereas on the desktop, it does a mouse cursor. On mobile, it is a finger. If Marzipan or whatever it's called happens, it will be interesting to see what tools they put in place, how emulators and things work so that those touch points and those different user experiences are able to translate across platforms.
You don't have the experience you had, I would say, when you first saw Android apps appearing on Chrome, which was that they weren't quite designed for the mouse cursor at all. They didn't align with the screen well.
The bigger challenge is less so much sharing the code, and more about thinking about, "What's a good end user experience on these devices?" and, "Is it going to feel native, or is it going to feel like the robot that almost looks human, but there's just a little bit of an uncanny value that you can just tell that it's not real?"
Forward to the Mac
Rene: There are two sides. Maybe Twitter would never come back to the Mac, because they're fine with the web. If the Twitter app that they built for iOS could much more easily be ported back to the Mac, maybe it's only half an engineer. Maybe that's more portable, or maybe some other developers like that.
The opposite example to this is tvOS. tvOS is based on iOS. You can share a great amount of the code. We still get horrible Amazon Prime with YouTube apps. Maybe I don't know anything, Christina.
Christina: I don't know. Part of that is there are some certain limitations with tvOS. You're right. You saw horrible JavaScript-laden apps. I would argue that the case of the Prime in the YouTube app is that their primary concern is to make things look the same across a million different platforms. Apple TV has a really small user base compared to the Rokus and the Chromecasts of the world. Again, you prioritize resources.
Rene: The rumor I heard is that some engineers, of course, care desperately about the quality of their app. The product managers really favor portability. Them taking their own...
Christina: Absolutely.
[crosstalk]
Rene: ...code from whatever player, it's taking on an Apple TV. They cared about fast and cheap, not good. They just want...
[crosstalk]
Christina: Right, which I would 100 percent believe. Again, I can't fault, because if you're looking at, "OK. I need to get a product out. It works well enough," the people who are really going to nitpick over the experience are going to be a very small subset of the users.
Most users are just going to use the app. If it has a bad interface, it has a bad interface. We're willing to forego perfection just to get the product out, especially if we only have X and web users, and we're trying to cross-maintain a million different platforms.
This is why, even though it's impossible -- [inaudible 20:08] everywhere is impossible -- it is why people are moving more to trying to use shared frameworks, whether it's in the web, mobile or whatever.
Rene: The thing that I'm hoping for is that, yeah, there'll be a ton of inertia with them. I'm thinking similarly like Greg Pierce, who makes Drafts for iPhone, iPad and Apple Watch, and currently doesn't have a Mac app might be...
Christina: He didn't have one.
[crosstalk]
Rene: ...to say, "Now, there's no reasons for me not to have a Mac app."
Greg Pierce
Greg Pierce: Absolutely. There's no reason I wouldn't want to be on the Mac. Other than that, I haven't had the resources. The effort required has been prohibitive. I've been taking steps to get there. Over the years, they've improved a lot of the underpinnings. There's a lot of things that can be shared. The UI is so different.
The resources required to build an entirely separate UI has slowed down that process. I'd love to see something like that come from Apple.
Christina: Exactly. Overcast, we could finally have an Overcast Mac client. The web app is great, but we'd have a native one. For companies like Omni, who's been basically doing this on their own for five years, maintaining the same code base and just having different UI stuff would maybe lessen their load. That would be great.
I would love to see the good Greg Pierce be able to do drafts for Mac, because I would kill for that. On the inverse side, in a perfect world, I'd also like to be able to say, "Maybe you have some really good Mac apps that have never come to mobile, that might be able to come to iOS in better ways."
WWDC 2018 dreams
Rene: Bottom line for me, my dream is that Craig Federighi would show up on stage at WWDC, 2018 or 2019. He would say, "We've had 20 years of AppKit. We've had 10 years of UIKit. Today, Apple takes the next step forward. Today, we announce a framework that lets you share your resources between iPhone, iPad and Mac much more easily, much more effectively. We call it XKit or we call it AppleKit."
Christina: I would love that idea. That would be great. For developers who are really already invested in both platforms, and would want to do the heavy-lifting work of migrating their stuff over, that would be great. Definitely, for new apps going forward, that would be great.
My only fear with this XKit thing is that, in my mind, I'm always afraid that that means they're going to take away some of the special things that make a Mac app more powerful than an iOS app.
Unfortunately, my gut tells me that if that's the case, then you would see some of the scripting things and some of the more advanced system access things disappear if you were to do that, which would be OK for most apps if they didn't already have a Mac version. Still, it makes my Mac app heart hurts.
Rene: We see that. They took the engine from iOS. They brought it to the Mac. It was super painful.
Christina: It was.
Rene: [laughs] We lost everything at first. Even Final Cut Pro, anytime there's a restart, it's months or years in pain. Eventually, it gets better. That's my only hope. That's my hold on to hope, Christina, is that it would eventually get better.
Christina: I know. I'm certainly not trying to say that it would never get better. You're right. There will be pain points. That's just me only having realistic glasses on face. I'm with you. That would be great. It would be good for the Mac UI system and maybe help provide some life into it, so that if someone is building an iOS app, it's that much easier for them to say, "OK. Do I want to invest these many hours into also making a Mac version?
When I update things, Xcode can be written in such a way that it will update things across both of them, deploy them to both stores, and do testing on both types of devices. I don't have to do a lot of the heavy work that exists now in trying to maintain an iOS version and a Mac OS version."
Rene: Christina Warren, I thank you so much for your time. If people want to find you, it's @film_girl?
Christina: That is correct. You can also listen to my podcast we do every week on Relay FM called "Rocket."
Rene: Awesome. You're still hosting the Channel 9?
Christina: I am still hosting this week on Channel 9. I also host a show called "GALs." We do some other things.
Rene: Thank you so much, Christina. I really appreciate your time.
Christina: Thank you, Rene.
Loren Brichter: I was convinced that they were going to go that direction in 2008, 2009. The fact that it took this long, I'm assuming that they're doing it. The fact that it took this long is mind-boggling. I don't understand why anybody there either resisted, or it just...Yeah, I don't get it.
