Transcript

00:00:00 - Speaker 1: So I do think it’s a really tough sell for classic native apps into the enterprise. Now there is another market which you might call independent creative professionals, and these buyers value different things and say what they want is powerful tools that are shaped to their needs and workflow that they can deploy on their platform of choice, and that give them a lot of abilities and that are kind of unique to them as a creator.

00:00:26 - Speaker 2: Hello and welcome to Meta Muse. Muse is a tool for thought on iPad and Mac, but this podcast isn’t about Muse the product, it’s about Muse the company and the small team behind it. I’m here today with my colleagues Mark McGranaghan. Hey Adam, and Leonard S Saberski. Hello. And I don’t know if you fellows noticed, but we changed the intro a little bit. I did. So this is a bit more aspirational than actual, but exciting news, Muse 2 is coming early next year, that will be in early 2022. I’ll link to our roadmap memo talking about that, and one of the top features there is a MacA.

00:01:07 - Speaker 1: Very exciting, the pieces are coming together.

00:01:09 - Speaker 2: Yeah, and certainly this has been part of our vision from the beginning, tying together all the devices where creative people do work.

Clearly, the iPad, while we think it was sort of like an underserved device and has a lot of potential for creative uses, particularly this thinking work that Muse is all about, but having, I think, pretty well explored that, we also need to fill in these other pieces of the puzzle.

And so, desktop is obviously the next step there. And of course, one answer on desktop is you make a web app, either something runs in a browser or something that runs in a, what’s called an electron app, which is basically just kind of a wrapper for a browser or a web technology app.

But we’re opting to do something that is what I would call a native app, and I thought that would be a great opportunity to explore the topic of native apps generally and what those even are and and what they mean for users of the software.

So maybe we can talk a bit about the technical side of that because it is fundamentally a technical thing, but then the design user experience, you know, what does it mean to design a native app and what’s the benefit to users or how should things look or feel different for them.

And I’d also like to speak a little to the business side at the end because we’ve seen a big growth in a lot of interesting productivity tools, both kind of business team, enterprisey stuff, but also personal tools and see how the native app question fits in there. So Mark, you’re the most technical of this group, I think by a fair shot. So maybe you could briefly define for us what is a native app or what’s even the alternative to that and how do they differ.

00:02:48 - Speaker 1: Well, there are a lot of different axes here, but let me give you the classic native app and then the contrast with say the web app.

So classically, a native app is something that you download as a binary artifact like a DMG versus a web app where you would go to a URL. It’s implemented in the native language and stack of the platform. So for an Apple products that would be Objective C or Swift. And it integrates closely with the platform features and libraries for things like UI systems access, input and output, and so forth.

Contrast with web, it’s going to be implemented in the language of the web, you know, HTML and you might have more or less access to the underlying platform features you might not be able to read it and write the disk, for example. And then I think importantly, traditionally native apps store things locally. On the local disk and web app store things in the cloud.

Now, as we’re going to discuss, I’m sure you can mix and match different axis here, but that’s the classic native app as I see it.

00:03:45 - Speaker 2: Right, so I think of the classic native productivity tools would be something like the Microsoft Office Suite. So if you were on a Windows computer in the 90s or early 2000s and you would download or even install it from a CD probably, so you’ve got the, as you said, the binary program, you copy that software onto your computer, you run it there, and then when you want to save something, a XLS. or a doc that goes onto your hard drive somewhere and you can transmit that to someone else, you can email it, put it on a floppy disk or a thumb drive, but everything is very on the local device and the software is there and downloaded and runs right there on your computer.

And nowadays, both with things like Google Docs, actually, I think Microsoft has even transitioned to cloud kind of web apps with their stuff as well. That’s something where you’re really connecting to someone else’s computer or cluster of computers, AKA the cloud through your web browser and everything stored. Basically, most of the sort of software itself is run on their computer and sort of the results just transmitted to you and the data itself is also stored there.

00:04:52 - Speaker 1: Yeah, and just to give an example of mixing and matching these different aspects, you have electron apps which are distributed as binaries like DMGs on Mac, but under the hood they wrap what is basically a web browser, so you have a web implementation and then the resulting feel and storage characteristics is often in between that of a native app and web app. It feels kind of webby, but also kind of native, depends on the individual developer, but that’s an example of how you can mix and match some of these axes.

00:05:22 - Speaker 2: Electron has become incredibly pervasive. Slack’s desktop app is Electron, so it’s the Spotify app, so there’s the Notion app, so there’s the FIMA app, so this sort of, yeah, wraps up, would otherwise be a web app.

Another piece on the technical side, I think is it’s not just this kind of web and cloud versus local program and local storage duality, but it’s also how you implement that interface.

So there’s typically APIs that are customed to a platform, so Windows. has a set of APIs, Mac has a set of APIs, iOS has a set of APIs, there’s often widget toolkits that go with that, you know, on Linux, you have something like GTK, often there are different widget toolkits, and so the degree to which you use or don’t use those can make it feel native. Now, Leonard, maybe you can give us the user experience or the design side. What does native mean kind of within your discipline?

00:06:18 - Speaker 3: Yeah, I think there are a few different ways of looking at it. So one is to just take the technical definition and look at, OK, we have a native app. What does that mean for the design of the interface? And we have a non-native app, what does that mean for the design? And there are sort of implications on both sides that can make the user experience better or worse. But what I actually find more interesting is thinking about what makes an app feel native and look native, even completely separate from the technical implementation of it. So I think there are a lot of different factors to untangle that just from the user experience, make an app feel native.

00:06:55 - Speaker 1: Yeah, and we can enumerate a few aspects of this. So one that you’ve mentioned already is the look and feel based on the UI toolkit and how the controls look.

Another, I think is how the app interacts with the underlying platform. So for example, different platforms expect applications to write user data in different locations on the disk, you know, like Unix has like the slash user or whatever, and Mac has the till the application support or whatever it is on Mac, right? And sometimes you get these apps that are multi-platform, they start writing data in really random places and it confuses you.

And maybe a third example, the most subtle would be the mental models and metaphors that an application uses. So on Mac kind of uniquely there’s this idea of app that’s separate from Windows, like physical instantiations of the app, and so you can have an app open with no Windows. Or you can have an app open with multiple windows, and that’s quite different from how it works on Windows, where if you click the X, like the application exits, because the window is the app and vice versa.

00:07:50 - Speaker 2: Linux window managers typically work the same ways, and also that you can run the program twice, right? So that was something I has a Linux on the desktop user for many, many years, and I actually really liked that if I ran my Text editor, for example, a second time with my command pallet or from the command line or just by clicking the icon, I would get a second window, a second instance of that, and with Mac, when you click on it in the dock or you all tab to it, it brings whatever was already there to the front. So basically whether the program is running or not gives you different behavior when you go to launch it.

00:08:24 - Speaker 1: And maybe one more thing we could throw in there in terms of platform access is just the power of the features that you have access to. So a lot of audio and video things, for example, are hard to get at if you’re not a more native app on the iPad, for example, you can only get 120 hertz if you can’t do that as a web app and so forth.

00:08:40 - Speaker 3: And I think a lot of that is not just because you don’t have technical access to those features, but even just because these apps are designed for so many different platforms and so many different devices that basically every feature that isn’t available on all of these platforms just isn’t that important and isn’t that easy to build.

00:09:00 - Speaker 1: Yes, and this brings us to what you might call the implied aspects or dimensions of native versus non-native apps. So you mentioned one which is if you’re building a non-native app, it’s often because you’re building for multiple platforms and then you tend to get this least common denominator effect where you only use the features that are available on all platforms. Another one that we found is quite important is performance, where sometimes but not always, if you implement the app in a way that’s less native, you can suffer worse performance or perhaps have a lower performance ceiling.

00:09:30 - Speaker 2: One thing we learned working with web technologies and styluses was, for example, that the data you could get from the APIs was just less.

Yes, you can get input, maybe you can even tell it’s a stylus, but you couldn’t get, for example, the asimuth of the pencil.

And maybe that doesn’t matter for your particular application, but for example, for Muse where we wanted to do weird stuff with you hold the stylus in a different grip, and then you get a different tool, and we thought this would be a cool and interesting and powerful way to take advantage of that unique form factor, but it just wasn’t on the web at the time. And I think the web tends to catch up eventually, but that stuff always comes first to the native platform APIs.

00:10:08 - Speaker 1: Yeah, it’s a good point that there’s a time dimension here where, as you said, often web or multi-platform umbrellas will catch up over time, but you’re less able to change as the underlying platform makes changes, you need to basically wait for the change to propagate up through the various abstraction layers that you’re using, whereas if you’re native, as soon as the underlying API changes, you can adopt it.

00:10:32 - Speaker 2: Now another slice maybe of the kind of native versus not, again on the technical side here is the web I think of as being the sort of universal runtime that won the wars of the early 2000s, so for those graybeards like me who are around to experience that.

Java and the JBM was a very big push in the industry to create this concept of right once run anywhere, that you have different computing platforms or different kinds of computers, different operating systems, different manufacturers, but in a way they were kind of especially pre-mobile, they were basically all pretty similar in terms of they have screens and keyboards and some kind of pointing device and seems silly that you have to rewrite your app to run it in.

Different places and the JVM had this concept that it could make this universal run time, make it run anywhere and Flash had a version of that as well, but they both were basically pretty terrible experiences for anyone that ever remembered running Java Servlet applications or Flash had its uses, but in the end also it felt like this this very confined box that was just constrained.

From interacting with your computer in all these useful ways, and I think the web eventually won that war where essentially everyone now has a web runtime environment.

It’s called the browser. It’s become extremely powerful. It often can tap a lot of the operating system APIs for hard audio and video access and things like that. And of course we do love the web for a lot of reasons and that has unlocked a lot of things, but in the end it is this essentially kind of translation layer.

Another type of translation layer that isn’t requiring the user to install a runtime, that is a browser or a JVM is something like React Native, or something like Cordova. It’s the right ones run anywhere concept, but rather than trying to give that sort of general bundle to someone on Windows and someone on Mac downloads the same program, the Java jar or the web HTML plus related assets bundle. Instead, you actually compile it, trans. You might even say to each of these platforms.

So React Native, for example, is a mobile application platform. You write your app for a phone, but then it can compile to iOS and it can compile to Android, and these are true native apps in the sense that then you compile them and build them with the normal iOS and Android tool chain, they become a binary artifact that is probably hard to tell from casual inspection. That it wasn’t built kind of directly using Xcode or the Android equivalent workspace.

And yet of course it has the downside that now as you said, lowest common denominator there is this translation layer, but it just kind of happens at a different time. It happens on sort of the developer’s computer when they do the build and through this toolchain rather than the end user’s computer. And so that probably gives you some performance benefits, but there is this thing where you’re kind of homogenizing between the platforms.

00:13:36 - Speaker 1: Yeah, and with React Native in particular, you seem to get the now you have N +1 problems issue, which we have to some extent with browsers, sort of famously web developers deal with browser quirks and every browser is a little bit different, although that seems to be less of an issue these days with auto updating browser. But with React Native, it seems to be a huge deal. Probably because of the surface area and complexity and dynamism of the underlying APIs, just trying to write something that compiles reasonably and runs reasonably on these two platforms which are very different and have very particular APIs just has proven to be quite hard, but we can talk more about how that’s played out.

00:14:07 - Speaker 2: But where I thought the technical side interleaves pretty well with the designer user experience side is I feel like this. I don’t know if it’s a siren song, or at least it is an appealing idea to developers and to certainly to businesses that don’t want to have to maintain code bases and multiple platforms that you write kind of one single code base and then you can deliver it to different platforms through some kind of minor effort, minor translation layer. And I feel like it’s so compelling to the creators of the software, but then as a user of the software, then there’s this thing where, yeah, it just seems like it’s never as good. It’s gone through this translation layer, it’s lowest common denominator, either it feels like the other platform. So, one example there might be something like, I sometimes use the Audacity audio editor, which I originally used on Linux back when I was in that world, it’s built using the GTK toolkit, so it was native to that environment. And they build what you would call native versions for Windows and Mac, but it looks like Linux, because it uses the GTK toolkit, it does not integrate at all well, and that matters a lot for audio stuff, so it’s a good example there with Audacity, it’s hard to switch between your audio sources, it basically gets really confused, it just doesn’t use the Mac audio APIs very well, so it ends up feeling very, very clunky and feeling like it’s been transplanted from this other place, even though it’s been compiled in this way.

00:15:34 - Speaker 1: Yeah, and this is an engineering problem. You’re not fated one way or another to have either a great uniform app or a terrible app that looks bad on all the different platforms. Another example would be Flutter. Flutter. Yeah, so they did the same thing. It’s right once run anywhere for I think primarily targeting mobile platforms, but they did the thing where they reimplemented all the iOS controls, Pixel for Pixel, and it basically looks pretty good, even though you’re not using the AS controls at all, so it can be done, just big engineering problem.

00:16:01 - Speaker 2: So Leonard, what for you is some examples of great native apps that showcase, it’s not necessarily about the technology, but it’s about being designed specifically for a particular form factor, or a particular platform.

00:16:14 - Speaker 3: Yeah, I think the most obvious example to look at is just the Apple apps, you know, that’s the sort of gold standard, of course, in terms of native apps that are adapted to each platform. There has been, at least in recent times, like some exceptions to that, where they are also trying to bring the iPhone or the iPad app to the Mac. And that can result in something similar to just bringing a web app to the Mac, where it’s not really optimized for the platform and it doesn’t quite feel right. But yeah, there are some great examples and I think especially for the pro apps, you know, Final Cut or something. This is a very native app that feels great in its design exactly for the platform. I think there are still a few third party apps that do a great job, like Things app. Which is a task manager.

00:17:01 - Speaker 2: Things was gonna come to mind for me, yeah.

00:17:03 - Speaker 3: Yeah, and things are surprisingly, I don’t think they actually use that many completely native UI elements like a lot of the UI is sort of custom, but all of it feels very native and it is still a native app and they just customize elements to sort of bring in their own brand and do things a little bit differently to fit their needs.

00:17:25 - Speaker 2: Yeah, for me, the feeling native thing is not about using system controls. I think it’s good when kind of principle at least surprise or you’re familiar with these controls, and so therefore, you know, if your share sheet just uses that standard share action icon and you tap on it and you get a pop up, whereas I think it’s quite common. I know a couple of apps do this quite annoyingly where you tap that share icon and you get something that is not the iOS default share thing, maybe Twitter does that.

00:17:55 - Speaker 3: Yeah, I think YouTube does that and basically all the Google apps, like they first show a share sheet that highlights all the different Google ways to share and then like at the very bottom of the very right corner, you have to scroll to there’s like a tiny more button and then you get the actual share sheet.

00:18:09 - Speaker 2: Yeah, exactly, there’s some more thing and that takes you to the system one.

For me, it’s not necessarily about using the system widgets everywhere, it is about performance, it is about using the form factor to its best extent, and I think things is an example I like because they have apps for Mac, for iPad, for the phone, and they’re all very similar visually and they have a lot of the same controls, but they use the different screen size.

And they use the different options that are available in each place. So, for example, they’ve got great keyboard shortcuts, which you can use on the iPad and you can use on the Mac, they’re not relevant on the phone for obvious reasons, and so, making use of what exists in each place, even if it’s just different screen sizes and orientations, is part of what it’s about, that it’s been thought about, how do we make this work well on this. Device and I think that’s where often either the translation layers or back to some of our very first episodes of the podcast, Mark and I spoke quite a bit about what he usually calls the transliteration of apps, rather you take a desktop app and you try to bring it to the iPad, or you bring an iPhone app and you bring it to the iPad, and either way, if you haven’t really thought about iPad’s unique capabilities, unique form factor, it just feels like a port, like a weird port. And sometimes I’ve even seen versions of these where people take iPhone apps and make it available on iPad, but it doesn’t even work in landscape mode. It’s got this weird letterboxing. I almost think, why does this even exist? It is so out of place on this platform that you might as well just not even have it.

00:19:50 - Speaker 3: Yeah, I think there’s another reason here why many larger companies prefer a non-native design for the apps.

And I think often it basically comes down to their brand identity and they don’t want to give up their brand for feeling native. So in the end, it becomes a decision between being native to the system and native to the brand that you’ve established and the sort of visual system around that.

And so for example, apps like Spotify, they basically look the same on every platform, on every device and they also behave and feel similar, right? And I think for them, that’s a very conscious decision not only because they don’t want to develop a native app for every single platform, but also because their brand is so important to them.

And I think that’s especially true for industries like music streaming or even like car sharing food ordering where it’s very commoditized and you basically have to rely on your brand for people to use your service. And so if they all switch to like a generally more bland, less branded native experience where they can’t control every single aspect of the app, I think that’s just not worth it to them.

00:20:59 - Speaker 2: I think you also see the war between the tech giant empires play out there a little bit, right? Google wants to bring their material design stuff. It’s actually an interesting thing recently where maybe it’s the Google Maps team or one of the teams that takes some of the Google products and brings them to iOS, and they retired a bunch of their custom widgets, some really interesting Twitter thread there. I’ll see if I can find and link it, but They do have a kind of consistent, I mean, material design is great and it’s consistent across these different platforms they’re on, it’s tied to their brand, but there is also this element of Google and Apple are kind of warring empires in a way, and you probably get a similar thing with Microsoft as well.

And so it’s weird to say that you know Microsoft Office doesn’t feel that native on Mac because they want to like. Use their unique brand identity when Microsoft’s office is pretty bland and vanilla, but there is this element of it’s their, they’re trying to bring some of their empire into this other company’s empire, and so sometimes you see these wars play out, maybe like the YouTube share sheet is an example of that. What you’re seeing is not kind of user-centric design, what you’re seeing is the warring tech giants trying to encroach on each other’s territory.

00:22:12 - Speaker 3: Yeah, and I think if you take it to the extreme, there can be cases where basically a third party creates a platform on top of your system that’s just completely takes over the design. Like a lot of people just spend a ton of time on Facebook and use Facebook apps and Facebook services and everything that’s created there will just look like Facebook and not support anything system related. And I think there’s a similar thing in many countries where you know in China you have WeChat and that is like the platform that everything runs on and it doesn’t matter at all if it’s running on an iPhone or an Android. It just becomes the system essentially.

00:22:47 - Speaker 2: Yeah, that’s a good example, and I’ll tell you another good example, almost the most impressive one of all time, which was in the 1990s, Microsoft had an absolute lock on the desktop operating system.

To the point that they were, you know, being hauled in front of federal courts for essentially having a monopoly, and the thing that eventually broke that was not legal action, I don’t think, but was the web and the appearance of the web browser was essentially this insertion of a whole other platform, or other almost operating system. That you could run inside this existing platform, and I think ultimately the web was what broke the Microsoft monoculture and Microsoft computing monopoly a little bit. And so rightly so, I think companies are afraid of that.

Apple probably works hard to defend against that, for example, not allowing other browser engines on iOS or letting you do anything that runs code or anything that looks vaguely platform like and for good or for ill, but you can see why from a business perspective and defending your empire perspective, that’s a wise decision.

So Leonard, you’ve been spending a lot of time on the design of Muse for Mac recently, and without giving too much away there, I’d be curious to know how you went into approaching that or if you have this idea in your mind that it’s good to design something to feel native, it’s less about the technology and more about how it feels and what the end user experiences, what principles did you bring to bear, or how are you approaching the design of use for Mac with that in mind?

00:24:23 - Speaker 3: Yeah, it’s interesting because Muse is basically a native app both on the iPad and on the Mac, but it does still feel like a bit of a foreign entity when you use it since we are not using that many system components by default and we are doing things a lot differently than many other iOS apps.

00:24:42 - Speaker 2: One of the things I found really interesting reading some of your just internal memos as you were gearing up for this project was pointing out that basically Muse for Mac will use a lot more system widgets and a lot more common conventions around things like menus and shortcuts and Right, click context menus and things, and that’s basically because Mac is the world’s best, it’s just my personal opinion, but I think a lot of people share it, it is the world’s best platform for creativity and productivity. So on iPad, we came into it saying we think this device has huge potential for creative tools, but that potential is not being exercised, and that’s lack of the right kind of software and it’s also lack of the right kind of support from the operating system or the right kind of widgets or the right kind of system APIs.

And so we kind of invented a lot of our own, and we started with a literal blank canvas and brought in a lot of our own controls and interactions and so on, taking advantage of a lot of the things that make iOS very powerful, including the high performance and the programming frameworks and so on, but really the system level widgets were of less use to us.

But it seems like on Mac, that will be less the case because in fact there is a multi-decade history. In fact, I would argue that Mac traces its lineage back to Xerox PARC when Steve Jobs went in there and saw the future of computers in the form of the Alto and brought that to Lisa and then the original Macintosh. And so it’s steadily accumulating all our best practices about how to be productive on computers in that time.

00:26:19 - Speaker 3: Yeah, I think iOS and iPads have something very special and unique there where every app really feels like its own world and it sort of lives on its own.

And I think as a result of that, we have seen many native IOS apps looking very different from each other. And that’s not really as much the case on the Mac.

Like the native apps on the Mac all look quite similar and feel quite similar. Like there are some that, you know, maybe trying things differently and either succeeding or failing, but in the end, like they are all trying to follow the same visual language.

And that’s not really the case on iOS and I think that provides an interesting opportunity at least for designers to try new things. And I think you have to be a bit more careful with that on the Mac since yeah, there’s such a long tradition on the Mac and be right next to all kinds of other apps and people kind of have a different expectation of how an app fits into the system. And so I think a general rule for us, even though it doesn’t seem like it at first, is actually we deviate from sort of the native default design for a future, then like that has to be a very deliberate decision and like we have to have a reason for it. We have to understand why the system component or the system design pattern works differently and then we can sort of do our own thing with it. And I think that’s even more true on the Mac and there will also be less reasons basically to do our own thing.

00:27:41 - Speaker 2: Yeah, to name one example that comes to mind as a pretty core design idea from Muse dating back to our research prototype days is that you should never have to wait for anything, no controls, no gestures, have some kind of built.

In delay.

So the standard drag and drop on iOS, and that includes iPad OS, is that you hold your finger down for some period of time. It’s usually about half a second and then the item kind of lifts up and then you can carry it someplace else. And the problem with that is if you want to move a bunch of items quickly while you’re constantly waiting. And we wanted to make something where you could not only never have to wait, but in fact, with the larger screen of the iPad, there’s this really neat effect where you can start moving your hand in the direction of where you want to move the card, bring the finger down and sort of catch it just like it’s an index card sliding across your desk, move it to where it’s gonna go and let go. So there’s no delay there, but that, you know, is our own custom gesture system because that’s quite an unusual way to do things as far as I know. I don’t know that I’ve seen any other app on iOS do that, whereas on Mac, yeah, guess what, when you click on an item and start dragging it, it goes right away. That’s, that’s how it works. That’s how basically all programs work. And so, great, so there we just do the standard thing that everyone else does.

00:29:03 - Speaker 3: Yeah, I think you can really achieve a lot if you try to play to each system’s strength and not just, you know, try to adapt one element and like make it work.

But really think about the different kinds of inputs and systems surrounding your app.

Like at the very basic level on the iPad, of course, we have touch input and, you know, that feels great. You have like a very direct way to manipulate things, can your gestures and we use that a lot from use on the iPad.

But then on the Mac, like if we just take all of that stuff and let you do the same stuff with the mouse, yeah, theoretically that would work, but it’s just not going to feel great.

And so instead, the mouse has its own benefits, right? Like it’s much more precise. It can be used in tandem with the keyboard that’s also always there. And so I think there will be a lot of opportunities like that where if we really think about what the strength of each platform is, then we can do something that web apps which have to serve the lowest common denominator, can’t even do at all.

00:30:01 - Speaker 2: And I think it’s not just the capabilities of the platform, but the use cases you are going to use them for and even how you were sitting.

So Mark, I think this was part of your kind of original vision for the multi-device use experience.

I’ll see if I can paraphrase here, which is, you know, when you’re at the computer, you’re in this focus posture, you’re probably sitting upright, you’ve got the bigger screen, you’ve got the keyboard and mouse. You’re probably doing something like deep research on the web or maybe production work, like writing a long paper or designing an interface or something, whereas the tablet, maybe you’re sitting in a reading chair, you’re at a cafe, maybe you’re outside somewhere. You’re in this much more relaxed, or you have a lot more variety of positions you can have flat on the desk, sitting in your lap, that sort of thing. You might be holding it in different angles and you’re using it more for this thinking, arranging, pondering, you’re scratching your chin and sipping your coffee and maybe getting up and pacing around the room. You know, that’s more of the setting that you’re in. And so, of course, you have different capabilities on each device, but in many cases you actually have different uses, and so we should be as much as we can designing for those uses, I think, without also being too restrictive about we obviously don’t want to stop you from doing any one particular thing in any one particular environment, but knowing roughly what sort of environment and what sort of use you’re having seems like a thing to take into account with the design work.

00:31:24 - Speaker 1: Yeah, exactly, and then by the way, the phone is going to be, you’re on the go, you have one hand and a few taps, and that’s it to either save something or look something up quickly.

00:31:32 - Speaker 2: Yeah, a good example on the phone is I think it’s considered best practice, and I think I probably agree with this to try to make everything doable essentially with one finger, basically one thumb, and also a thumb that you can reach, you know, maybe in the bottom half of the screen.

So most of what you want to do when you’re hailing a ride. You’re messaging with a friend, you’re quickly looking something up on the map. You got to imagine that you’re juggling the phone in one hand, maybe you got a coffee or a baby or a dog’s leash or a bag in the other hand, it’s a noisy environment, maybe you’re outside.

And so what the design should prepare for is I’m at my office, it’s quiet. I’m looking at a big screen, I’ve got my hands on a full-sized keyboard, and I can take my time and I have much more precision, and I want more control and power, but it’s also OK if the essentially things are a lot fussier. There’s more on screen at the time, and if I click on the wrong place, it’s OK, I’ll undo that sort of thing.

00:32:29 - Speaker 1: OK, so we’ve been talking a little bit abstractly here about use cases and postures and number of hands available and so forth. Leonard, to kind of bring it back to the concrete visuals, how do you see that being different across these different platforms and native versus non-native?

00:32:43 - Speaker 3: Yeah, I feel like there’s always a very interesting conflict between native and non-native apps where native apps always seem like sort of the dull ones and the ones that aren’t going to be visually unique or interesting. Like we talked about this earlier with the brand design and presumably if you do a native app, you know, your brand is not really going to shine through. And so I think the instinct is very often to just not follow the native design so that you can sort of do something unique and do something interesting and then your app will actually stand out from the crowd.

00:33:14 - Speaker 1: This is like moral hazard, visual designer edition. It reminds me in the world of engineering where sometimes companies make it a requirement to get promoted, they do something complicated, and then so engineers introduce a whole bunch of unnecessary complicated stuff into production because they want to get promoted. As a similar vibe to me.

00:33:30 - Speaker 3: Yeah, I think there’s actually a management part to that where as a designer, if you, if you strictly try to follow the system components, like those are basically constraints, and if someone tells you and says, you know, we want to do a specific thing this way, then you might have to say that’s not compatible with the system way of doing it and we can’t do that since we are following the system guidelines.

And so it’s very appealing in that way to just do your own thing and then you can always say, OK, yeah, let’s do what we want basically.

I do think we kind of have a bit of a lost art idea of being able to get the most out of the native components and being able to bring your own design language into them. Like if you look a few decades back to something like Windows 95. Like there when you download like a media player from the internet, you would actually have skins that you can also download and then the app just looks completely different and completely wacky and basically by now modern interface standards usable, but it introduced a ton of personalization and sort of uniqueness to the whole platform, right? And I think it’s somewhat making a comeback that like some apps have options for themes or skins you can click through and those can still be native apps and they just sort of transform how things look a bit and introduce some personalization to it.

00:34:46 - Speaker 2: One interesting point there, I think we talked about with Weiweiu in our episode about expressive tools is there’s the designer or the company getting to express their unique brand, like you mentioned Spotify, and then there’s the individual getting to customize so that they can express their unique personality through their computing environment.

So I think the Winna skins were great. Yeah, a lot of them were maybe not super usable, but maybe for a media player, that’s pretty simple anyways, it’s just like play pause, volume, jump track, you as a user are choosing, I want this wacky, brightly colored one, because I like what that expresses about myself and brings some customization to my computing environment.

Which something about that feels more wholesome or maybe just comes back to this user-centric thing again compared to my company has a prerogative to use our brand styling system everywhere possible in order to maximize shareholder value or a designer wants to get promoted because they did something cool and unique that stood out to their team or to their boss. I don’t want to be too negative on that. I think there are a lot of good places for bringing unique style and character to an application that reflects your team or your product, but I think those are two really different categories.

00:36:05 - Speaker 3: Yeah, I guess what I would like to see more is just people trying to merge the two and trying to use native components and still infuse them with their own brand.

Like one great example of that is a Wikipedia reading app called V for Wikipedia. And that basically uses like 90% system components, but if you just look at it, like it still exudes sort of its own style just by type of. colors, iconography, animations, good image views, and that sort of requires, I think, a pretty high craftsmanship to be able to really merge the two and you have to really know what each component is doing and what you’re trying to do with it.

But yeah, I think if we could see more of that, that would elevate native apps to a level where non-native apps don’t have as much as an advantage at these foreign brands anymore.

00:36:56 - Speaker 2: Another example that comes to mind for me on that when you’re talking about typography is Twitter. I think they do pretty well with something that to me feels like a pretty fundamental app on the iPhone, browsing social media sort of like, for better or for worse, what our pocket communicators have largely become for.

They have a new typeface that I think they had custom designed, but for the most part, they really give over the space to user content. You have avatars, you have the handles, you have the tweet. And you have, you know, an image or video, and you can scroll through that in a feed, and it mostly feels pretty kind of integrated to the operating system, and I think it works pretty well with the share actions and things like that, although they may have their own share button problems. But in general, it feels like there’s a Twitter brand, but it also doesn’t feel too overbearing or feeling like they’re forcing it on you, or either that that’s taking away from sort of the personal brands, you could say a person communicates through their Twitter bio or whatever, or that it feels out of place on the iPhone. I think it feels very good and natural on the phone. Multimemedia kind of audio and video stuff.

There’s also another interesting one coming back to the WA thing, and you also mentioned Final Cut, uh, program I use, which is maybe in between those two is called Screen Flow, which is a really nice kind of classic screen recording software for Mac and been using it for many years, and it’s sort of not nearly as complex or sophisticated asinal Cut. But it does allow you to do quite a lot that’s very specific to screen recordings related to use and other software that I work with, and it feels very native, it’s certainly fast, it uses system widgets and that sort of thing, but it also does bring some of its own style to how the timeline is shown, how you interact with, you kind of slice and slice the video clips, and what happens, you know, they do a little icon of a rabbit when you are doing a sped up clip and a little icon of a turtle and it’s slowed down. So I think that’s kind of a nice example from an indie shop.

00:38:57 - Speaker 3: Yeah, I think that’s a good way to do it in general, to sort of infuse the uniqueness and branding into the components that make your app special anyway, like yeah, for a video editor, that’s like the timeline and specific settings for it, but then try to use system components whenever you have more standard options.

00:39:15 - Speaker 2: So two interesting apps I’d love to reflect on here are Sketch and Nova.

So both of them have essentially worked native in the concept of being a native app into their marketing, which is unusual because I think that’s typically seen as more of a technology term or a kind of an insider jargon.

That sketch, for example, has this beautiful article titled Part of Your World, Why We’re proud to have Built a truly native Mac app, and then Nova right on their homepage, they talk about a native Mac code editor and why that’s better, and basically all of their value proposition is around why being native is a better experience for the end user. I think your users of both of those pieces of software, Leonard, I’d be curious your take on those specifically and sort of presenting it as a user benefit in their marketing.

00:40:06 - Speaker 3: Yeah, I feel like for sketch, it’s certainly a unique selling point, especially since they are an app for designers, and I think a lot of designers still do care about that craftsmanship that is in the native app and like prefer using native apps. And so I feel like they specifically sort of have to lean on that.

But then on the other end you have FIMA, which is not native and it’s still doing great, right? Like it’s a very fast app. The first time I heard of it was because Sketch was actually really slow and like crashing a lot with large files while on Figma, the same sort of designed files were just completely smooth. So they still managed to, in terms of performance be similar.

In terms of the design of the interface, they are very similar to sketch, like you don’t have to adapt too much. And at least over the last few years, it feels like Figma just has gotten a lot better than Sketch at developing new features and basically making a better app faster than Sketch can make an app that supports collaboration and the web, basically.

00:41:08 - Speaker 2: Yeah, I think that brings us nicely into the business side of this, which is kind of the last piece I wanted to talk about which.

Maybe the sketch figma thing is something we’re seeing play out throughout the industry, which is FIA can start with something that is maybe worse in some perspectives because it’s not native, but they’re able to reach a wider audience, they’re able to offer these sharing and collaboration features that in turn, and those things are both valuable enough, they can essentially earn more money or attract more investment dollars. They can use that to hire an unbelievably good engineering team that have done.

Just really remarkable things with using the web platform through web assembly and other quite impressive tricks, and therefore more or less keep up with and maybe even in some cases beat sketch on some elements like performance, obviously things like integration the system APIs will just never be possible.

But maybe those aren’t quite valuable enough to users, at least not in comparison to being available on every platform by default and the kind of sharing and collaboration features and so then that naturally creates a flywheel where they can earn more, they can get more investment and then they can make the product that much better.

So to me, it comes to a tough question for us, the software makers and all software creators have to consider the same thing, which is we can sit here and say we love the crafts personship and the design work and the performance of native applications, but then if we look at the industry, I wonder, is that kind of a bad bet? Are we sort of picking the losing side?

00:42:38 - Speaker 1: OK, a few thoughts here. I do think that the center of gravity of how software is implemented in terms of the language, the platform, the deployment is going to be determined by the economics and right now the best economics in the industry are an enterprise software. There’s also a consumer software which we can talk about, but let.

Focus on enterprise.

One of the things that enterprise buyers care about, it’s uniformity and ease of distribution, control, security, ability to facilitate collaboration, which is almost a definition of an enterprise, right? And these are things that the web really excels at.

So to my mind, Sigma was better than Sketch for enterprises because the things that enterprises value were just more aligned with how the web works, you know, that Sketch might have had better native API integration. It’s almost like not even wrong. It’s just not what the enterprises, I think we’re looking at when they were looking to buy software to support collaborative design, right? So I do think it’s a really tough sell for classic native apps into the enterprise.

Now there is another market which you might call independent creative professionals, and these buyers value different things. They don’t necessarily care about uniformity of distribution and control by someone else in anti-fe and say what they want is. Powerful tools that are shaped to their needs and workflow that they can deploy on their platform of choice, and that give them a lot of abilities and that are kind of unique to them as a creator.

And so I do think you see these tools succeed with this platform choice with things like sublime text or even something like Final Cut Pro. But there’s this asterisk of success is different because the market is much smaller.

That’s just the way the market is right now. The ability to price these things is significantly lower than enterprise software, so that is what it is. So I think it’s not so much that one is better than the other is that they’re aligned with different markets and the markets are of different size, and I mentioned consumer briefly. Now consumer, I would actually say is better for natives, in particular, it’s better for iOS, which is the main platform in terms of money. And their consumers actually really value performance and integration with their phone with things like contacts and so forth, and so there you do see native apps winning.

One other thing that I’ll say here is I do think that sounds maybe a little bit bleak for native apps. There is the consumer positive and of course there’s this independent creative professional positive that we’re targeting with Muse. I do think that there are a lot of sensibilities from native apps that you can pull into apps that are distributed over the web, because I mentioned that these axes are somewhat independent. So one of my favorite examples and sorry notion, I’m gonna pick on you again, we do it because we love you. Notion search is really slow. You type a sync, which is something that we’re working on now, and it takes like 5 seconds to show you a result. And that’s not because of native versus web, like whether it’s written in JavaScript or objective C. It’s slow because it’s going to a remote server and like scanning notions entire database for stuff.

My sync, where if instead it worked like a local app where just loaded all the data in memory and scanned everything I’ve ever written, they could do that in 10 milliseconds, right? That’s an example where you could have something distributed over the web with something like an electron app, but they had more of this native slash local first sensibility and gave you some of those benefits. So it’s not all bleak.

00:45:38 - Speaker 2: Yeah, well, as you said, that comes back to the data question and so it’s less about, you could have a native app that was mostly doing things through APIs to cloud backend, and yeah, every time you need to do a quick search, it has to go, you know, round trip to the cloud.

But you would also have a web technologies app that has much more local stuff. I think it was something like Kevin Lynasiner is one good example where he wrote the thing in Rust. He had the goal of 60 frames per second. It’s a nice blog post about that, I’ll link, and it’s really all about looking stuff up on your local system, and he used web technologies because that’s what he’s good at using, and you can make them fast if you want to, but it really is about the data locality more than how the software is built, let’s say.

I think another important question on the business side is the platform creator and what their incentives are.

So, we’ve definitely seen this and talked about it a little bit with being a prosumer iPad app, means that you’ve got the App Store with the heavy-handed review. And the pretty limited things that you can do inside the application, and a lot of things you inherit from App Store economics, which are really all about consumer, but makes it harder to do a subscription prosumer piece of software, for example, and probably Apple’s incentives are such that that’s not super likely to change because the iPhone is their big product and the App Store is made to serve that, basically. And then similarly, you might have something like Google, which has platforms like Android or Chrome OS, but you know, when you look at their business empire, those are not primarily moneymakers for them, they’re primarily channels to get you into the places they actually make money, which is, for example, having you do searches and serving you ads.

And even Microsoft famously in many ways the most successful platform maker of all time, as we talked about that 90s computing platform Monopoly, they, as of a few years back, basically deemphasized Windows that when Satya came on as CEO, basically said, look, Windows is Microsoft’s past, it’s still a piece of our business, we need to create it and make it good, but it’s not their big focus and it’s not their big moneymaker.

So then the Individual platforms in terms of what they want to incentivize with developers, in terms of how they, how you distribute apps, how they allow or enable you to make money or not make money through the apps.

Certainly things like app stores, what APIs are provided, all of that plays into dynamics about what kind of software can get created, and it really does feel to me like the web. Ends up being the best, not just for enterprise for the reasons you said, Mark, but even this more prosumer world of things, you know, I think we see this kind of tools for thought, space, you know, that includes the notions and figmas of the world, but also something like Rome or obsidian, for example. Yeah, it’s just the web is I don’t know, superhuman or linear. These apps by being on the web, they get maximum control, they get ease of distribution, and they get to charge money without an intermediary, and that’s just a very powerful thing for business.

00:48:46 - Speaker 1: Yeah, yet another important idea in this political economy of software that we’ve been talking about a few times on this podcast. I think that’s an important like.

00:48:55 - Speaker 3: And I think even if we assume naively that the goal of every company is just to create the best app possible, even then native apps become less and less a good choice, the more devices you want to support.

And so as Mark said, enterprise companies just need to support many devices.

And so if you try to do native apps for all of these, like that’s not gonna be possible. You won’t be able to really create a good experience across like 10 different platforms and device factors, right? And so I think that’s why we often see native apps more with smaller companies that may be focused on, yeah, either a single user environment where you don’t need to support many different platforms and ideally even an environment like Apple’s platforms where you have the Mac, the iPad, and the iPhone, or even the Apple Watch, all kinds. sharing some APIs and the code base and some design language so that a few people can reasonably keep it all in the head and sort of design and build a good product for all of these platforms, and that sort of approach doesn’t really work anymore for larger enterprise companies where you need to have apps on many different devices.

00:50:04 - Speaker 1: And now that we’re talking about this, I got another riff, so we talked about how perhaps enterprises tend to choose web because there’s all this collaboration amongst the members of the enterprise, which in fact is almost the definition of an enterprise, but increasingly you could say we’re all part of the enterprise of like the software community, and this is a little bit of a joke, but here’s what I mean.

It used to be that you would like go to the software store and you would buy a box with Excel and you would install it and you would try to learn it yourself, and that was kind of that.

But now we’re in a much more networked community.

So for example, If you are doing design, you might want access to a plug-in that was authored by someone else on the internet and to be able to install it.

Well, by the way, it’s a lot easier if you’re using FIMA, or it just might be that you want to look at a YouTube tutorial of how to do something.

I said several times in this podcast that YouTube is very important, and if your product is available on essentially all devices, there’s more likely to be good YouTube content, so there’s this big positive externality that feeds back in.

So this is kind of me partially trying to understand why it is that what Adam just said was true about the web also seems appealing for what looked like in one sense to be individuals, but even there there’s an element of community and participation.

00:51:10 - Speaker 2: One item might be remiss to leave out in the business discussion was there was a bit of a kerfuffle, I might say in the iOS slash Apple developer community when OnePassword, which is one of the more successful password managers, announced that they were switching from their native built password manager on the Mac to one built on what’s basically web technologies, it’s like Rust and Electron, I think.

00:51:34 - Speaker 1: I was going to give them as an example of a good native app earlier.

00:51:37 - Speaker 2: Exactly, so the Twitter discussions that followed were essentially, OK, you got this shining example of an indie software company that has created a lovingly crafted and well designed native app for many years, you know, there’s many password managers, but one password is successful largely on the strength of the look and feel and performance that feels very native and feels very integrated, particularly with Apple stuff.

And then they essentially raised a big round of venture capital and immediately thereafter switched their previously native app to these web technologies and people felt betrayed, or that it was some kind of a harbinger for the future of native apps generally and maybe Mac specifically. And they ended up doing a follow-up blog post that I’ll link in the show notes that was interesting about essentially the engineering management and business decisions they made that led up to that, and some of them are just some specific things related to exactly where the platform APIs are in the moment.

But maybe it does come back to that question of when you’re trying to serve the widest possible audience, and you’ve got an engineering team and it’s just a good business decision, even when you’ve got a pretty big engineering team, you think, can’t you afford folks to build native apps on all these platforms and actually just makes more sense to have this unified code base and less to support. So we’ve talked about the technology side and the cost of building the apps, we’ve talked about the design and user experience, we talked about the business. Are there any other aspects of native versus non-native that are notable to touch on here?

00:53:06 - Speaker 3: Yeah, I feel like one of overlooked aspect is accessibility. That’s kind of a big victim of non-native apps where accessibility really depends on system features, right? Like you wanna be able to set in the system settings what you need and rely on these features that providers like Apple built across the system and not, you can’t fine tune these settings for every single app and you can’t.

Rely on every single developer building like a complete suite of accessibility features. That’s just not going to happen. And so for that system to work, you kind of need native apps that can support these native APIs and build with accessibility in mind and non-native apps just can’t really do that. And there isn’t usually time to build custom implementations for non-native apps for accessibility.

00:53:55 - Speaker 1: That is an interesting one. I’ve been thinking about this in the back of my mind because the type of non-native technology that I’m most excited about is the setup where you have a high performance language that you compile down to a very narrow runtime, like the rust slashwam style, for example, where you write the app in a high performance language, it compiles down to what is basically like a web native binary, and then you can run that wherever you want.

But there’s only a very thin API between what becomes the application and the platform, in contrast to the usual thing where there’s like a whole windowing system and tool kit and widgets and everything that the platform provides. And yeah, in that world in particular, you implement your very high performance text editor, but then what people can’t, you know, highlight the text so they can’t have it spoken to them or whatever. It’s tough.

One thing I wonder though is, can you separate a little bit the platform hooks for accessibility from the implementation.

So to take the example of text size, one way to do that is there is a platform standard text implementation, which I’m sure there is on Mac and iOS, and if you use that, it automatically scales the text up and down according to whatever. The user has set in the universal text size settings, but it could also be that there’s a thing you can call which is like get current text size, and then in your own implementation of text you could scale the text accordingly and yes, it’s gonna be harder and less likely people do it, but it’s still potentially possible, especially if there are various other libraries and other library options for UI widgeting. So yeah, it’s tough.

One other question I have is what do games do because games are typically implemented in this way where you have basically the game takes over the whole screen and does whatever it wants, including different ways of rendering texts and so forth. So I kind of wonder what they do. It’s probably a lot of just don’t support accessibility, but maybe there’s a fire right there.

00:55:40 - Speaker 2: Yeah, I think it just ends up being a custom implementation per game, so whether it’s color blind mode, or changing the text size or different kind of input controls, there’s a good game maker’s tool kit video, I’ll link to that.

But yeah, essentially it’s all up to the developer, which often means that smaller indie games just can’t or don’t have the resources to support that, but of course the AAA games have these massive budgets and massive teams, is both possible and really in their business interests, because once you’re going to a wide enough audience, then even a small percentage of people that have a particular type of color blindness to pick one example of an accessibility area, that actually represents a pretty good number of customers for you.

Well, maybe as a closing point, we’ve talked all about the pros and cons. I think it sounds like we come down personally pretty strongly in favor of native, but we also see where business wise that might be a more questionable thing as the world evolves. So I’d love to hear from each of you and maybe I have my own answer. Why are we making news for Mac and why not use for the web?

00:56:48 - Speaker 1: Yeah, well, I actually don’t have a very dogmatic answer to that.

It’s that we had a few key desiderata for the Muse, let’s call it desktop app, you know, the thing that you’re going to run on your Mac, and the two main options for implementing that would be a maybe the three options would be a classic native app, an electron app, and a web app.

And there’s things like performance, but a huge thing for us was access to the file system to be able to do a local first work, which basically eliminates the web option, really you’re left with electron and classic native and I do think the performance is quite a bit better for a classic native, and also we have this potential to share a lot of code between the iOS app and the desktop app, so there was a clear path to implementing it. So that’s why I would have thought about it.

00:57:31 - Speaker 2: Yeah, for me, the answer is also all about performance and that also connects to the local first or local data storage. Again, you can do that with electronic web technologies, but I feel like it’s more of a reach. The electron app that uses local storage. It’s a translation layer, that’s kind of all there is to it, and so trying to make the performance good and use local storage effectively, not to mention integration with things like drag and drop, which is really important for me is getting stuff in and out. It’s just hard for me to picture providing a really great experience there.

00:58:02 - Speaker 1: I’m not an expert on it by any means, but my sense is that local first data storage and the web in particular is quite hostile. Like someday someone in Mountain View might have a bad day and just kick you out of the Chrome cache because whatever you’re using too much space and then you’re out of luck. I don’t know if that’s exactly what happens, but my sense is that you cannot count on the data in a stored in web browser.

00:58:19 - Speaker 2: Yeah, so for me it’s all about fast, and it’s about local, and you get those things with native, so therefore, probably make different arguments about the business case, but for what we want to express in bringing news to the desktop, use for Mac is the only thing that makes sense. And by the way, answering my own question there, it’s not that we’re not making use for web. I feel very strongly we should do that, and that’s for the sharing and collaboration case because that is where the web excels, but sequencing that later feels like the right decision to me.

00:58:51 - Speaker 3: Yeah, I feel like that’s the important thing coming back to playing on the strength of each platform. And for the Mac, that’s just the native app ecosystem and the connection we already have with the iPad app. And we’ll be foolish not to use that strength of the Mac, basically. And then in the future, if we want to build something more web-oriented, then we’ll surely also play to the strength of the web.

00:59:15 - Speaker 2: Well, let’s wrap it there. Thanks everyone for listening. If you have feedback, write us on Twitter at NewAppHQ or via email, hello at museApp.com, and you can help us out by leaving a review on Apple Podcasts. We still early with the muse for Mac beta, but I’m really enjoying this question of how we bring what makes Muse special and interesting and unique from this other platform onto the Mac, which is a platform beloved by me and many other creative people, and watching your work on that, Leonard, as well as our engineers working on what exactly will be the same and what will be different has been really interesting. So looking forward to continuing to watch that evolve.

00:59:57 - Speaker 3: Yeah, me too. I think it’s something we’ve been kind of working towards for a long time, so it’s been sort of in the back of our minds, so you might look on the Mac, but yeah, it’s an entirely different beast to actually like get into the weeds and really figure out the design details of the Mac app.