The Changelog: Software Development, Open Source - The future of Mac (Interview)

Episode Date: November 20, 2020

We have a BIG show for you today. We're talking about the future of the Mac. Coming off of Apple's "One more thing." event to launch the Apple M1 chip and M1 powered Macs, we have a two part show giving you the perspective of Apple as well as a Mac app developer on _the future of the Mac_. **Part 1 features Tim Triemstra from Apple.** Tim is the Product Marketing Manager for Developer Technologies. He's been at Apple for 15 years and the team he manages is responsible for developer tools and technologies including Xcode, Swift Playgrounds, the Swift language, and UNIX tools. **Part 2 features Ken Case from The Omni Group.** Ken is the Founder and CEO of The Omni Group and they're well known for their Omni Productivity Suite including OmniFocus, OmniPlan, OmniGraffle, and OmniOutliner – all of which are developed for iOS & Mac.

With unified memory architecture, sometimes it's kind of hard to understand what that actually means. And so certainly it means shared memory, and that's what most people think of. But what people don't understand sometimes is that even when you have shared memory on some integrated systems, you still have different formats of how things are represented depending on where they are in memory. So like video or images or things like that, you know, not everything is just a bit blit of moving memory from point A to point B in most systems. In our unified memory architecture, that is all consistent. When you're working on a CPU task and then a GPU task and

moving that around memory, that's all the same file or not file, but memory formats that we architect because we own the whole system. So we can make sure you're not copying. You're always reusing that same memory all the time. So as a developer, stuff that you may have written the same one line of code actually meant the background copy is now actually just handing over a pointer over to a different task. And so you're seeing things that used to feel slow, like boom, all of a sudden that operation happened literally instantly because those things in the background weren't needing

to happen. So it's not just an instruction set. It's not like, hey, you had to write these assembly instructions, now write these assembly instructions. The way your software runs is fundamentally different and it's really exciting. So you're saying we shouldn't be worried about that 16 gigabyte RAM limitation. Yeah, you're not copying, right? So there you go. I see what you're saying. Just forget about it, Jared. Let it go. Let it go. Bamblin for Changelog is provided by Fastly. Learn more at fastly.com. Our feature flags are powered by LaunchDarkly. Check them out at launchdarkly.com. And we're hosted on Linode cloud servers. Get $100 in credit at linly.com. And we're hosted on Linode cloud servers.

Get $100 in credit at linode.com slash changelog. What up, friends? You might not be aware, but we've been partnering with Linode since 2016. That's a long time ago. Way back when we first launched our open source platform that you now see at changelog.com, Linode was there to help us, and we are so grateful. Fast forward several years now, and Linode is still in our corner, behind the scenes helping us to ensure we're running on the very best cloud infrastructure out there.

We trust Linode. They keep it fast, and they keep it simple. Get $100 in free credit at linode.com. Again, $100 in free credit at linode.com. Welcome back, everyone. This is the Change Local podcast featuring the hackers, the leaders, and the innovators in the world of software. I'm Adam Stachowiak, Editor-in-Chief here at ChangeLog. We have a big show for you today. We're talking about the future of the Mac.

Coming off of Apple's One More Thing event to launch the Apple M1 chip and M1-powered Macs, we have a two-part show for you. Part one features Tim Treemstow from Apple. Tim is the Product Marketing Manager for Developer Technologies. He's been at Apple for 15 years, and the team he manages is responsible for developer tools and technologies, including Xcode, Swift Playgrounds, the Swift Language, and Unix tools. Part two features Ken Case, founder and CEO of the Omni Group, who is well known for their Omni productivity suite, including OmniFocus, OmniPlan, OmniGraffle, and OmniOutliner, all of which are developed for iOS and the Mac. Here we go.

All right, we are here to talk about the future of the Mac, fresh off of the One More Thing event in November. This future was teased back at WWDC, and in fact, we've known there's been Apple Silicon based Macs on their way. They were promised to come before the end of the year, and now they are here, and we are here with Tim Treemstra. You've been at Apple for a very long time, Tim, and I'm curious, where does this announcement, this transition rank for you

in kind of the pantheon of big announcements? You had the original PowerPC to Intel transition. You had the iPhone SDK. There's been a lot of big announcements over the years. Where does this one rank? It's kind of funny because you look at it both as like the work you have to do and also as somebody that is just a lover of products. And as a lover of products, this one's at the top of my list. I'm a Mac user. I started my life as a software developer and still like to do that as a hobby. And so having the Mac take this enormous jump is just about the most exciting thing that I've dealt with on here.

And like you said, there's been a lot over the years. From a technical issue, it's quite a bit easier than most of them have been in certain respects. But just from the general excitement, I hear the same thing from our developer community, that they just feel like this enormous uplifting about their love for the Mac being rejuvenated. And so there's a real high level of excitement right now. Just to give a bit more extension to your background, over a decade at Apple, transition to the Intel-based Macs, which is huge. That was the previous gigantic leap forward, as you say, in your announcements. Launched the iPhone SDK, the opportunity to launch the App Store, and then obviously Swift in open source, which has been just tremendous as well. So you've got a lot of history behind you in terms of what developers really care about that

Apple has done. And that's a big deal, what you've done at Apple. Yeah, it's been a really fun ride. And it's something that I think we learn quite a bit from at each step. It was funny is, I think everybody compares this transition to the PowerPC one. and I was lucky enough to be here 59 years ago when we did that. And I think it's apt in that it's the Mac and it was an architecture change and such. But in so many ways, it's a completely different world than when that happened. You know, for one thing, almost no Mac developers at that time had worked with Intel. So for them, it was a fundamentally big shift. They weren't really familiar with it.

There was a lot more technical difficulty. There was NDI-ness to deal with. People had been making the 64-bit move recently with PowerPC. Then the Intel was going to be 32-bit initially, so there were some different things going on then. Bluntly, at the time, most people weren't Xcode users, so it was a big tooling change for a lot of people. The thing that's funny that we're having now

is a comparison. I actually just talked with Ken Case over at Omni the other day, and his comment was like, it's like coming home. Mac developers very often have been sharing code with iOS for years and years and years already. They're using the same tooling. It almost feels like closing the loop. Like, okay, the one last thing that wasn't totally Apple in my ecosystem is now Apple. And they're just really excited about it. It shows a

commitment and also makes it so that they just have one less thing to worry about. It's definitely a big commitment and a huge transition, a huge amount of work and something y'all have been investing in for probably a very long time. Why do this? You said close the loop, get on all of our own stuff. We know that you tout the software hardware integration and the advantages of that, but what was so bad or so problematic with Intel chips

and where you were that it was worth this heavy investment? I think a lot of times you want to look at it, I think there's a phrasing I've seen people use and I use it myself sometimes. It's like, are you running away from something or are you running to something? And I think we always run to something. We saw an opportunity to make amazing products.

Every time we iterated on our CPUs, we saw what we could do. We saw the integration we could make. And then we were able to do that with the Mac was just an opportunity. We thought we could make really, really good Macs. And I think when people get their hands on these Macs, they'll see exactly why we did. From the developer's standpoint, first of all, I think they're going to actually love having these Macs. And then when they do, they're going to want their software to be running at absolutely maximum speed. It was kind of funny.

I knew I was going to talk with you. And a lot of my engineer friends have been telling me about how their experiences with these new Macs are internally. And so I took mine. And just kind of on a lark, I took one of my bigger projects. And I just hit Command-B, clean, Command- command B clean, command B clean, command B clean, like just constantly built on an actually it was a MacBook air and kept it on my lap. And the thing stayed cool like the whole time. And I must've done like a half a hundred builds.

And so just, just simple things like that are going to get developers so excited that they're going to see the opportunity. And I really just think it won't even be requiring and convincing people are just going to be so excited that they're going to see the opportunity. And I really just think it won't even require any convincing. People are just going to be so excited to move to this new platform. Was this example your M1 chip? Just curious. Yeah, that was with an M1 chip. So it was a MacBook Pro or a MacBook Air?

This was actually an Air. And you've seen the statistics on the MacBook Pro, which I think we'll be talking a little bit more about the detail on, but basically it's this enormous C++ project we benchmark. And it was getting almost three times the build performance as far as just the throughput to get the whole build done. But the statistic that Shruti said that I think was almost a little bit missed

when I was watching Twitter that I thought was the bigger one was it's about three times as fast to compile, but then you got four times as many builds on a charge. And you can think a little bit about what that means is that we didn't just throw three times the energy to get three times the performance out. We actually had to throw less energy through the CPU to get that same performance.

So you're actually able to get more work done on that battery charge while still getting your builds faster. So maybe you actually able to get more work done on that battery charge while still getting your builds faster. So maybe you can settle a bet for us, Tim. Just before the show, we were talking about the new lineup and are they really targeted at developers? And I said, well, surely the MacBook Pro

is even though it's a 13 inch, it's not going to be the most powerful laptop, but it's a pro. I said, the MacBook Air, it's really your most consumer level, entry level laptop. Would you actually say developers, you can do your life,

you can do your work on the new MacBook Air? Or would you say, go for the higher performance one with the fans and everything else? Every developer needs to make their own choice, obviously. And the things with the MacBook Pro is that you've got even longer battery life

and it can get even faster in cases. But the MacBook Pro is that you've got even longer battery life and it can get even faster in cases. But like the MacBook Air is an enormous jump versus the previous generation. So I think a lot of times people have to reset what they expect and what they want out of their laptop. There is absolutely no reason you cannot do really serious development on a MacBook Air. I think that's an amazing statement and I think it's absolutely true. But I do think a lot of developers would probably want to go for the MacBook Pro, just because it's a slightly elevated bit that is worth it for a developer. The other major thing that we're hearing from our community and that we're thinking as well, and I think Adam thinks this as well, is we see the new machines.

I don't remember jumping ahead here, but let's just jump ahead and do it. And we get excited and then there's something about the maximum 16 gigabytes of ram on the new machines and it's kind of like you know how many chrome tabs can i really run with only 16 gigabytes of ram we're used to having much more and maybe it doesn't matter because of the system on the chip and unified memory stuff you can speak to some of that, but is this going to be a major holdup, maybe not for regular consumers, but for software developers and video people and the pro customer that you guys serve?

I think that, again, that is something that each individual developer has to make their decision for. We still offer the MacBook Pro outlines that have 32 gig of RAM available on them. My personal belief is that many, many projects would be more than fine to operate in a 16 gig machine. And then the portability and speed that they get in those machines is certainly an awesome product for many, many software developers, especially app developers where apps tend to be a little smaller size. You tend to spend a little bit more of your time doing incremental builds, which are fantastic

about throughput. And the build time is really, really great. So I really think like any product, each individual developer has to make the choice. But my experience is that these are fantastic developer machines. And the fact that you get this great portability and really great performance is going to be an enormous benefit to many developers. So considering that you spent what seems like the majority of your career at Apple

interfacing with engineering and interfacing with developers, what is it that, considering the different announcements you mentioned that you've been through, the different eras of Apple, what is it about this one in particular, the hardware, the software, you know, considering the different announcements you mentioned that you've been through, the different eras of Apple, what is it about this one in particular, the hardware, the software, this integration, this new leap forward, I suppose, for, you know, the future of Mac and the first Apple-made chip, you know, Big Sur, all this that was announced.

What is the thing that you think is the most important for developers to take away from, you know, I suppose the one more thing event, but this time for Apple right now? I think the biggest thing that I really want developers to take away is just the excitement that Apple has for the Mac. I think people have to understand how much we love the product, how much we love using the Mac. And the effort that went into this transition, which you hinted at earlier, is not insignificant. This is an enormous number of engineers working extremely hard for a really long period of time. And yet, I don't think I've ever seen the level of excitement that I'm seeing with this. And so as a result, I think as a developer, you have a built-in Unix, you have

all these types of things with the Mac, and now you have Apple Silicon coming to this product. I think I really want people to perceive the excitement that we have when they use these products. I think when you see the Big Sur redesign, when you see the Instant Wake, all these things, you're just like, wow, this is not what I remember. This is an amazing advancement.

I think Instant Wake is one of those little things that like, it was kind of a fun little gag in the keynote, but it's one of those things the first time you say, I have a laptop and it turns on the same way my iPad does. You're like, wow, that's pretty nice. So the boot up process isn't there anymore. Whenever I turn on my machine, and I know that a few,

a few laptops back, essentially it became whenever you open the lid, it would begin to boot up. So you're saying that there is no boot up process anymore and an instant on, or is that what that meant? Or help me understand better what happens. It works a lot like an iPad does in that you, you, a lot of people have gotten used to the idea of like shallow and deep sleep where, you know, you close the lid and it doesn't really sleep until a little bit of time passes, and then it really goes to sleep, and then it does all this other stuff. That really isn't what's happening anymore. You have this, much like your iPad, where it goes into sleep, and it's saving a huge amount of energy, but it doesn't need to go into a deep sleep that requires it effectively to reboot. It's always in that shallow sleep state. It's always ready when it comes back. It's not

just turning the monitor on. The computer is totally ready to go. Is that taking advantage of specific things in the M1 chip, like the low energy cores or something like that? Yeah, exactly. The chip has been architected specifically for this because this is what people have expected on an iPhone. This is what people have expected on an iPad for forever. And we make both operating systems, right? So we can certainly make it available for the Mac as well.

I'm curious, you have this huge amount of effort we were talking about, right? All hands on board doing this thing many years. And you have these big events and historically they've been at live, thousands of people in the crowd. I know that Apple engineers and employees get to attend the keynotes. And here we have the state of the world we're in right now. Is it somewhat bittersweet because you've been putting all this effort in,

and here you have these announcements, and they're very well done, but they're prerecorded and everybody's watching them from their own machine at home or in the office. We're all isolated. There's probably no high fives like there used to be. There's probably no hugs. I mean, I imagine like, it's like when you win the big game is when the finally your thing that you've been working on gets announced to the world. Is it bittersweet because of the quarantine and whatnot? I wouldn't call it bittersweet, but I definitely get where you're coming at. I mean, sitting in the theater at WWDC when we got to announce it would have been amazing. Being able to do more of that in person now would have been amazing.

And I think we all miss that a little bit. But it's always been about making the product, releasing it into the world, and then knowing people have it, right? And then knowing people are actually enjoying it. And I'll watch Twitter like anybody else and see people excited and such. And I can't wait for them to actually ship next week because we'll have this next wave of people actually experiencing the product. But yeah, I don't think bittersweet is there. There's that element that's missing, but it's also pretty exciting.

Well, like you said, it is ultimately about getting these things out into the world and into people's hands. And as we record this, Big Sur is going to get into our hands tomorrow. But as people listen to this, it's already out there. It can be downloaded, installed, etc. And Big Sur is really kind of a tandem announcement or tandem release to the Apple Silicon chips. And it's built kind of around and for. Tell us about Big Sur and how it integrates into this new product line. Yeah, I think the thing we said is that it's built down to its core for

the new Silicon. And I think the thing to take away is how much code Apple has been able to share for years and years across our platforms. We have these frameworks that are common, so developers have them. iOS was built on a Darwin foundation that we had from iOS. And so the thing that was really neat with Big Sur is a chance to actually have all that work kind of realized back to the Mac. So like I mentioned, the instant wake, you know, that's code obviously we understood and we were able to modify and upgrade it for the Mac. Now you have iPhone and iPad apps able to run on the Mac, which is kind of a fun story where, you know, people have actually seen us develop this in the open and not fully get to see it realized until just now when we did Mac Catalyst three years ago for our own apps, and then we opened it up for third parties so that they could do it,

and then we advanced it even further, and then we used it ourselves for the Messages app and for Maps app. And now, by building those frameworks across the platforms, because you're now in the exact same architecture where you could just do a recompile before for Catalyst and then you'd see what it would look like on a Mac, but you had to do the recompile because it was Intel. It's literally that same framework

now running on Apple Silicon. And the result is that the app can run without you doing anything. And so people start to understand like, oh, I get what you're doing. And then Big Sur just felt like this culmination of all this work and with the Apple Silicon,

where it was, okay, now we have Mac OS 11. We have the next generation of what we think the future of the Mac looks like because of all these technologies coming together and the redesign, you know, it has a lot of these things that we've learned over time as far as space usage and just the general usability we've learned from all these different platforms and makes it feel much more common, like they're all one family now.

So you buy a Mac, you buy an iPad, you buy a phone, iPhone, everything really feels like it was built by the same people with the same ethos about what a computing experience should be, optimized for each individual platform. So what about folks who are not on Apple Silicon, which is everybody at this point, right? Every Apple machine that's shipped in the last 15 years has been Intel-based. So here we are with a bunch of established Intel-based Macs out there. Is there things in Big Sur that just won't be exciting to them,

or do we just miss out on some features? Are there actual explicit features where you're like, this is only for M1 and beyond, and this is for Intel? Well, some of the things that the computers can do, like the Instant Wake and running the iPhone and iPad apps, are contingent on the hardware that's in these new Macs. But one of the things that's really cool is that Apple has pioneered and continued to lead the industry

with this universal concept where we've had universal apps for well over a decade. And so what we do is with the tooling and with universal apps, we're able to make it really easy for developers to support both Apple Silicon and Intel.

So people with Intel Macs will continue to get amazing software, and it's really easy for developers to continue to support them. It's something that I think a lot of people don't really understand is how perfected that is, is that when we had the PowerPC and Intel, that was kind of like the signature time people looked at the universal apps. But over the last 15 years,

we've done the 32 32 to 64-bit transition multiple times. You had iOS moving to 64-bit. In fact, in iOS, we had a V6 instruction set, then we had a V7 instruction set, and there was derivatives of the V7 instruction set. There was a time when we were actually

building three versions of the binary and putting them in the app, and users never noticed because it just worked. And the app store would even thin out the versions of the binary that came to your device so you didn't lose space. So this transition concept is something that we've really had working extremely well for a really, really long time. And Xcode for the developer tools does this for you automatically.

When you open up Xcode 12. developer tools does this for you automatically. When you open up Xcode 12.2 and you open up your Mac project, we'll convert it to a universal. And next thing you know, you're building Intel and Apple Silicon, and you didn't really do anything. And so users are going to reap those benefits for years and years. What about folks who aren't inside Xcode, or maybe they have some legacy stuff? Is there going to be some transitions? I know that we saw Adobe, they'll have Photoshop ready early next year.

So obviously there's some work they have to do there. Are there major lifts for anybody? I know it's easy. It's the happy path. It looks pretty happy, like open Xcode, rebuild, you're good to go. But surely there's some hurdles for some folks. Yeah, I mean, every project is a little different.

What we generally see is that if people completely own their own code, so they have all the source code, they can rebuild it, usually within days they are up and running. I talked with, like I said, some of the developers here recently. Pretty much everybody's told us that's the easiest transition they've had to deal with. And so they're just excited about doing the transition in a few days or a week, and they move on. We do understand that some people pull in third-party code, and if that third-party code is just in binary, they have this dependency tree where they wait for that to get done.

We introduced new things called XC frameworks that makes it easier for people that do vend third-party code to vend it in multiple platforms, just like a universal app. It's essentially a universal framework that you can ship. So it's become a lot easier to do that. And then there are a few edge case things where people were writing to very specific Intel instructions. There's some floating point math or something like that. Very, very uncommon, but there are a couple people that may have a little bit of assembly language that's using that,

and that'll do a little bit of work. But we've worked with big and small developers, and everybody's telling us that this is about the easiest transition they've ever had to deal with. And the fact of the matter is, I think you'll be seeing a lot of software in the App Store that's universal very, very quickly, which will attest to how good it is. I think I saw Visual Studio Code announce that they are already building an Apple Silicon version on their nightlies. They tweeted about that the other day. You saw the Adobe announcement. All the Omni apps will be in the store at launch. Really, it's been an extremely good pickup. What about totally in the open source world? We got a lot of people in our community asking about,

I suppose, the help, the support for open source. One in particular is like Homebrew or other apps like that or projects like that that need sort of support or access as opposed to documentation to be able to run on Big Sur. What does Apple do? I suppose now that you're in Swift and you're more at least in line with open source and have that empathy, what internal things have happened or are available to open source developers to prepare for Big Sur? Well, we did work with a number of open source projects to give them access to the DTK unit. So a lot of people have been working on them for a while. There's many, many homebrew projects that have already been supporting Apple Silicon. You can run homebrew on Apple Silicon. So that is a big hurdle for a lot of people that is already overcome. Obviously, there'll be long tails of projects

that not all of them are there on day one, but we haven't even shipped Macs yet. So I expect it to come pretty fast. We ourselves contributed to dozens of open source projects with patches. We've got everything from machine learning to databases to all the different things that you would imagine in an open source development stack. We know, for instance, the Mac is incredibly popular with web developers.

So the vast majority of the popular web development stacks have already announced or have even produced builds for Apple Silicon. So we think it'll be something that goes pretty quickly. So this is undoubtedly a large change and called out by the fact that you're going to OS 11 now, right? No longer OS 10. So Big Sur is a very big change. And we can see that reason why,

because the underpinnings are like completely different, right? The end user facing features, however, when you look at like the top of the line features that are coming in Big Sur, it looks like a nice operating system update. There's definitely some good stuff in there. It looks more like an evolution than a revolution. Except for one thing,

the change to run native iOS apps on Mac now that could be a revolution that could change the game quite a bit that could change the way the Mac feels over the next couple of years have you run a lot of iOS apps as you've been building this and been looking at builds

how does that feel, what does that look like? it is going to be one of the biggest revolutions through this process is that, you know, the iOS, you know, iPad, iPhone, App Store has the most vibrant app ecosystem in the world. It's hard to argue that point. And so now the Mac gets to tap into that with hundreds of thousands of new apps available as soon as you crack open your new Mac, which is pretty exciting. Personally, the example I always use because it's like something I see all day long is I have a baby monitor camera and I can now run that app and it resizes and does all these great things. And so I have a young child, I can watch her sleeping when she's taking a nap and make sure

she's okay. And the thing about that is that app vendor made an iOS app. Clearly, it makes perfect sense to have it on your phone or an iPad. And that developer, I could totally understand that they didn't have a mindset where they felt that they needed to make a unique Mac app. It's just most people have a phone or an iPad. So I get it. That's their environment. But now as a Mac user with a Mac

that I'm working on, the fact that I can pop that open anytime I want is awesome. It's nothing but a huge win for me. And there's games and there's other apps of that nature. Even simple things like setting up an appliance or something like that that somebody might make an iOS app for. They would probably never make a Mac app for it. But now it's also on your Mac, and how great is it that it's there? So we're really excited about that ecosystem opportunity. We also think with how easy it is to then bring a Mac app over with Catalyst so you can start adding Mac-specific features,

what will happen is developers will see that there's all these Mac users out there. And they'll say, well, they love my app. I can really just check a box in Catalyst and start making a Mac-specific app for those users and make something even better with very Mac-specific features if I want to. And we think a lot of developers that maybe didn't think about it before will have that user base all of a sudden raise their hand and say, I like your app, and they'll make their apps even better for the Mac as time goes on. So the developer doesn't do that. Does it have a strange, uncanny valley feel to it?

Is there no menus? Is there no keyboard shortcuts? Does it feel like it's an iOS app and it just happens to exist here, maybe as you run the simulator kind of a feel? Or does it feel more native than that? Well, first of all, they all do get a menu bar. So you get hide and you get those types of features, you know, built in, you know, all your task switchers and all that kind of stuff work like you would imagine. It's just a window on your Mac screen. And then one of the things that's kind of fun is that, you know, everything about this release feels a little bit like, hey, I've been working on this in secret for a long time now you really understand what we're doing

um you you know you may have seen that uh at wwdc this year we announced uh that there's new side bars for ipad well those side bars look like mac side bars with that same exact physical binary when it opens on a mac um we've been adding multitasking to iPad, which uses this thing called size classes. So you define your user interface, like what if I'm multitasking an iPad and it's like half the screen size or it slides over? Well, that makes it so that the windows are resizable when they're on the Mac. So now you've got a resizable app on the Mac, which makes perfect sense on the Mac, and it feels like it's going to scale properly. You get a new keyboard interface that we had when it came with the Magic Trackpad,

or Magic Keyboard, I'm sorry, for the iPad. That adds some new APIs so that you can make really cool games and things like that with a really precise keyboard API. Well, now you've got even better keyboard API when it runs on the Mac as well. And so you can make really, really rich iPad apps that will also be really rich Mac apps. And so the uncanny valley, a lot of it just depends on did you make an app that is best practices today? Because if it is, it'll look like a really good Mac app too. Now, if you didn't do anything, if you're one of those people that makes an app,

basically I said it's a rectangle and that's all it is and it doesn't resize real well in other ways, well, it'll probably have similar attributes. But I think that's something that's been so exciting about the platform in the recent years is these apps have just been getting more and more and more powerful on iPad and now they're taking the leap up to the Mac.

It seems a lot like that actually. when you took an iPhone or an iOS application and was able to use it on iPad, for example, where when that switch happened, when it became available, similar to that, where you had this whole new opportunity for new users, an extended interface, very similar to a larger screen like a Mac might have. Not exactly a Mac, but very similar. It seems a lot like that era. Like the same things you learned then or the same things the developer went through in that point might be similar or true today, like it is now. Yeah, exactly.

Like when we did size classes a number of years ago, there's a very obvious reason for it is that we came out with larger phones, right? And so by adopting that design pattern in your app, when we came out with a new sized phone, your app looked great, like you didn't do anything, it was using a pattern that allowed your app to scale properly. And so these are the things that we've learned over the years that are now getting applied to more and more of our software stack. And the Mac is reaping huge benefits from that. So how does somebody get their iOS app on the Mac?

Do they just put it in the Mac App Store or just check a box when they're submitting it to the App Store? So there is a place on App Store Connect, which is the place where you manage a storefront for your apps. In an App Store Connect, there's a checkbox so the developer has control whether or not it's available on the Mac or not.

Now, we know there are some apps that maybe use a gyroscope or use really complicated multi-touch gestures where there's not really an equivalent. And so they might want to opt out and say, well, I don't want my app there. But for the most part, we think most people will want their app to be available. The other thing is that this will probably get a lot of people thinking like, wow, I should make an alternate control mechanism. If I add keyboard support instead of just the multi-touch, I could have a pretty cool experience on the Magic Keyboard on an iPad, too. And so we think people will actually start looking at their apps a little differently. But to make it available, it's literally a checkbox.

What in particular does M1 offer in this world, this new native app world that's available? What in particular about M1 should get developers excited? Well, certainly a lot of the benefits they've seen already on iPhone and iPad are now there. So you've got, we've talked about a number of the features, but there's a lot of really low-level stuff too. So for instance, just some of the number of instructions that are necessary to perform very low level commands are less because we've been able to optimize for the actual silicon for years. So an object retain and release, which is like basically reference counting, can be about four or five times faster to perform this very common operation of like instantiating and cleaning up

objects. That's going to be something that you see on an M1, that at the very lowest level, everything is running a little faster. Some of the other things that you'll see is with unified memory architecture, sometimes it's kind of hard to understand what that actually means. And so certainly it means shared memory, and that's what most people think of. But what people don't understand sometimes is that even when you have shared memory on some integrated systems, you still have different formats of how things are represented depending on where they are in memory.

So like video or images or things like that. Not everything is just a bit blit of moving memory from point A to point B in most systems. In our unified memory architecture, that is all consistent. When you're working on a CPU task and then a GPU task and moving that around memory, that's all the same file, or not file, but memory formats that we architect because we own the whole system. So we can make sure you're not copying. You're always reusing that same memory all the time.

So as a developer, stuff that you may have written the same one line of code sure you're not copying you're always reusing that same memory all the time so the developers thought stuff that you may have written the same one line of code actually meant the background copy is now actually just handing over a pointer over to a different task and so you're seeing things that used to feel slow like boom all of a sudden that operation happened literally instantly because those things in the background weren't needing to happen. So it's not just an instruction set. It's not like, hey, you had to write these assembly instructions, now write these assembly instructions. The way your software runs is fundamentally different, and it's really exciting. So you're saying we shouldn't be worried about that 16 gigabyte RAM limitation.

Yeah, you're not copying, right? So there you go. That's what you're saying. Just forget about it, Jared. Let it go. We've all been hypothesizing behind the scenes to like why cap at 16 gigs. And, you know, when you go unified like you're talking about, it seems to make sense because the formats are unified to keep using the word unified. This is cool. But, you know, when you have that, you have less copying. So the assumption from a layman's perspective, I'm not a chip expert by any means, but I have some logic in me at least.

And the logic says, if you're not copying as much, you need less. That's good logic. Yeah. Yeah, I'm not the chip expert enough to say I would predict X amount of memory is different or something. But certainly from a performance standpoint, and certainly when you talk about heap creation

and things like that, other sorts of things that a developer thinks about as far as copies on write and when do we have protection on this and when is the thread safety? All those kind of things get a little bit easier and a little bit less overhead and it really does pay off

in all these different little places through your software stack. So help me understand how Catalyst fits you've mentioned a couple times but we talk about getting the native ios apps onto the mac we talk about the uncanny valley features for mac like does it work with multi gesture etc let's say i i'm your camera operator ios developer and i just have my my iphone app and it works on Big Sur just fine. But let's say I want to adopt some of those more advanced features. Like I want it when you hit command and it opens a new window or whatever it is, maybe that one already works, but you're with me. Do I need to adopt Catalyst to get in on that action? Or do I, I can do all that myself or do I have to start

with Catalyst to have a Catalyst app? I don't really understand how Catalyst fits into the picture for existing apps. I get it for brand new apps. You start a Catalyst to have a Catalyst app? I don't really understand how Catalyst fits into the picture for existing apps. I get it for brand new apps. You start a Catalyst-based app and you go. What about existing apps? Well, if it's an existing app that's only for iOS and iPad, it's not really a Catalyst app. We just call that an iPhone or iPad app.

And then we have all these nice APIs about multitasking and multi-window and such on iPad that you could adopt and that will improve your Mac app. The moment you say, I want to build something that's just for the Mac, at that point, the Mac App Store actually has its own apps, right? So think of it like this, is if you built an iPhone or an iPad app, you check a box and now it's also available to you on the Mac App Store. In fact, there's a nice little tab that we have that separates the Mac-only apps versus the iPhone and iPad apps that are available. But you want to add that Mac-specific feature.

As a developer, you say, okay, I want to turn this code base, which looks like iPhone, iPad code base, and you say, I want to make this a Catalyst app. And what that will do is it will literally produce a different app target for the Mac now every line of code didn't change but now you've got your own Mac target where you can start adding new source

files, new behaviors you say that these new source files and these new behaviors are targeted to just that Mac deliverable and then you can get all these cool new Mac specific features that you put in there and the cool thing about that is that you can then do things like SwiftUI or other API into that Mac app that is specific to that version of the Mac app.

Seems like the video games are going to be the first ones that really take advantage of this. Because why not? I had this awesome game on iPad, and it just checked this box. As long as it's a traditional iOS style game where it's like a single click, right? Like your tap, tap, tap kind of a game and not a gyroscope kind of a game. You could just put it on the Mac and the Mac's going to have thousands more games in Big Sur than it did before. Yeah. We, we, we use the among us game as an example through there,

because it's a really fun game that isn't about incredibly intricate controls it's really about the social aspect of having this game and you can really just kind of tap around the world when you're playing it like go here go here and that control mechanism worked great on the mac and that's a that's absolutely a game that people like i mean the game is going crazy and people are really absolutely loving that game but not putting it on your mac you know that just means that that's it's you know, one less device that you have to say, oh, I'm going to switch over to my iPad to play this game. I can sit here on my Mac and keep playing. I just would love to convey how much, you know, we are all super excited about what this is.

This is a multi-year effort that we're finally getting to reveal to the world. And, you know, I'm just really excited about next week when we start getting all the reviews and everything, when people actually get the hardware in their hands. Because it's funny, when you see hardware announcement, you see this is 20% faster and this is 30% faster. And people get really excited about that. And you don't usually see 20, 30% faster all that often year after year.

And I almost feel like people didn't fully understand that we said 3x, 11x. That's hard to comprehend until you actually use it. And I'm just super duper excited that people will soon be able to actually experience that and see something that is literally three times as fast to compile what that means to their lives. What's up, friends? Have you ever seen a problem and thought to yourself, I bet I could do that better? Our friends at Equinix agree. Equinix is the world's digital infrastructure company, and they've been connecting and powering the digital world for over 20 years now. They just launched a new product called Equinix Metal. It's built from the ground up to empower Thank you. EquinixMetal.com slash changelog. Get $500 in free credit. Equinix Metal. Build freely. So we're here with Ken Case, the CEO of the Omni Group.

And Ken, when I think about Mac apps, and I think about people who make Mac apps, I think about your company. Oh, well, thank you. The indie Mac dev is still alive, still kicking, still creating and making awesome apps. And when I think about someone who's in that space, it's definitely you.

Now, I will admit, I didn't know Ken Case. I knew the know ken case i knew the omni group sure so there's at least that that works tell us about your company what you've been doing and like your desire for the mac platform sure well a little bit about our company we as you've already mentioned we've been on the mac quite a while a long time a long time we actually started on the Mac quite a long time. A long time. We actually started on the Next platform. And maybe I should first mention what we do. We build productivity apps. At least that's what we focus on now over the last 20 years or so. But in the past 30 years ago, our goal was just to try to help this platform succeed.

The Next platform, we were really inspired by all of the technologies that went into it. And we loved programming for it, and we wanted to see it succeed. We were really inspired by all of the technologies that went into it. And we loved programming for it and we wanted to see it succeed. So we did everything we could from consulting contracts to building a web browser to porting games to try to help that platform succeed. And when Next was acquired by Apple, of course, then that passion translated into our passion for the Mac and Mac OS X. Right. That's a long time you've been involved with Apple. And so far back that you have similar roots, the same roots, because you grew together,

basically. Yeah, we know. I mean, I guess we've been involved in a lot of the history from at least one side of the equation. There were all these teams that were on the Apple side of it that we had to meet and learn about. Things like QuickTime back 20 years ago. But yeah, it's been an exciting set of transitions. Yeah, so this is a big one, but it's not the first one you've been through. The big one I mentioned with Tim on the other part of the call was the switch to Intel.

But that wasn't even your first transition. That was your second transition, right? I mean, you've been, you've been doing this a few times, but this is not your second road. It's like your third rodeo when it comes to Mac transitions. Is that fair to say? Yeah, I think that's fair to say. I'm just, I've been thinking back on transitions and 80s, the 80s were full of a bunch of transitions, right? Like it was a crazy time where we had 6502 CPUs on one end with 8-bit processors. And then we had things like I was involved in working with a cyber mainframe on the other end that had like 60 bits, which, you know, we hadn't even standardized on ASCII yet or on how many bits were in a byte or in a word.

Wild, wild west back then. Still trying to figure it out, right? Still trying to figure out what a platform looked like. Yeah. So when we settled down and decided, well, the next platform is what we wanted to do. This is after having explored maybe 20 other platforms from the Apollo to the SGI. All of these crazy different things that were going on in the 80s. And in the 90s, things started settling down quite a bit.

And we saw Windows really start to dominate on the work desktops. And we saw the Mac dominating a lot, I think, on the creative side of things. Right. And you have a whole suite of these productivity tools, probably millions of lines of code at this point. I mean, do you know how many lines of code you are in charge of, roughly? I do not know that. I could start a word count in the background while we this conversation i think it's safe to say millions right i would say maybe roughly more like a million we do try to prune the code from time to time and clean out the old code that uh that can now be written in more efficient ways right right right but yeah maybe i should mention

so the products that we have now are omni more efficient ways. Right, right, right. But yeah, maybe I should mention, so the products that we have now are OmniPlan, which is project management. It's like building a timeline of things. OmniFocus, which is more like executing on that timeline. So it's keeping track of your own tasks and doing something. We have OmniOutliner, which lets you break ideas down into an outline of thoughts and so on.

And then we have OmniGraffle, which I think is one of the apps that we're probably best known for, which is our visual diagramming application. Absolutely. I mean, I can remember back, it's been a bit since I've done one of these, so it's not sort of aging myself to some degree, but I remember the first time I'd like laid out

a workflow for an application. And every time I did it, you know, since then it's been through OmniGraffle laying out how things work, different flows, different workflows. Like if it hadn't been for OmniGraffle, and I suppose even more than that, like the love for developers and the love for the Mac platform, because that's really what it was. It was like, this is a day, I could say this is probably like 10 years ago where the desire was high on that side like the the design function the you know the look the feel of a mac app was clear like building a native or even a company around building mac apps was very much a cool thing and it still is to these days but like this

was like early days was like new you know new cool and had been a huge fan of omni graph one and uh the apps you've guys have created so well thank old school user old school user yeah there was something really distinctive about mac apps in the early 2000s as aqua was introduced and all your windows had pinstripes on them some of those things fell by the wayside over time style change but if you really wanted to be a modern app, you could tell which apps were modern and which ones weren't.

Let's put it that way. There you go. Well, you made this suite of tools and you've been pruning along the way and changing. I'm sure the market has pushed you in certain tool directions and other ones that maybe have gone by the wayside. But you've always had these productivity tools.

They made it through the transition into Intel. And now here we are and they're all running on Intel processors. I was talking to Tim on the other part, and I said, at this point, every Mac out there is now kind of a legacy Intel Mac. All your hardware is still Intel hardware until actually now they've been shipping some stuff out. So starting to change that.

But what does this transition look like for your team? What has Omni had to do to prepare? Because all of your apps are now ready to be native M1 powered, right? Big Sur apps. They're all ready for this transition. So what all went into that? Sure. Well, so you asked earlier, what's different about this transition than earlier? Yeah. Some of those earlier transitions, like from M68K to PowerPC or from PowerPC to Intel, we're really going to a platform that we hadn't been on before. In this case, I feel like we've been preparing for this transition now for a decade, for over a decade, because we've been developing for the iPhone all this time. And it's the same architecture, the same instruction sets.

So a lot of our code, in fact, had already been ported to run on Apple Silicon. Okay, process, right? Do you share a lot of code between your iOS apps and your Mac apps? Or is it just we do? Okay, yeah, all of our model code, we try to share as much as possible. And even some of our drawing code, the drawing code that can be platform independent, like core graphics based, we try to share that code as much as possible. Obviously, we don't share the top level interface code, or at least we hadn't until the advent of SwiftUI, which now we're starting to do that as well.

So yeah, it's been, in many ways, this transition was easier than any of those earlier ones because we already knew what we were building for. We were using the exact same tools. We didn't have to learn a new processor. In fact, we could just take the code, rebuild it, and run it. Start doing some testing. It's just as easy as that. And to that point, your blog post announcing the OmniPredator Suite being available for M1 and macOS Big Sur was out

two days after the announcement. So I'm not sure if that was intended because you have access or if it was just that easy or maybe just both. But definitely right off the announcement two days later announcing the support of M1 and macOS Big Sur. Yeah, well, in fact, we had our apps built and ready to try testing before we had any hardware to test on.

So even the DTK systems that were shipped out to developers this summer, before we had access to a DTK, we had a build that was ready to test on it, and we were just waiting for DTK to arrive. You were moving faster than Apple then. Sometimes we can do that. At least in one narrow area. Right. Well, I think less to their dismay, but more to their credit that they can allow developers on the Mac platform to predict kind of where they're going because of iOS and iPadOS, all those things.

Like because of their work on the different chips, that sort of determined where they're going to go. So you can sort of predict and plan ahead because of that. Yeah. that sort of determine where they're going to go so you can sort of predict and plan ahead because of that. Yeah, sometimes some of the moves that Apple makes are a lot more clear in retrospect than they were when they were happening. Like one of the examples that comes to mind is when Apple announced that they were working on WebKit, you know, they had Safari, and that their priority was to, more than being correct about what rendering a web page, they wanted to make sure that they never regressed in performance at all. And at the time, I was thinking, what, that seems kind of crazy. What if you've left out an important function, like, I don't know, bold or whatever, and introducing bold is going to make the web browser slower, but you need it to be correct, right?

All of that seemed clear to me and crazy until they announced the iPhone. And now it was really clear why they needed something that could not regress in performance, right? It needed to be able to perform well on that device or there was no reason to have it at all. Yeah, really. In retrospect, in this case, though, they showed their cards, right?

Like WWDC, they announced, we're going to, you know, this is a thing, this is gonna be a thing, there's gonna be some they give us tools, which was pretty big, was a big piece of getting ready. We could kind of guess, seeing the writing on the wall, I guess, over the last decade, as we saw the trajectory of how Apple's CPUs were increasing their performance over time compared to what was happening with the Intel CPUs that were in the Macs. Right.

We got some hindsight, too. When we were on the call with Tim, we didn't have much hindsight. So in terms of hindsight, I mean, there's definitely been some delivery of M1 powered Macs in the hands of – Reviewers. You know, enthusiasts, reviewers out there. And one in particular is Rene Ricci. He had done several different benchmarks that were well known to be describing. describing now obviously this is you know paper specs but it definitely like the m1 processor

in these machines was just blowing the whatever's off the water yeah yeah i mean yeah i mean like there's it's just and even you know when you compare uh the mac mini to the macbook air or the macbook pro like they all perform very similar similarly more better than you know intel processors but having been i suppose down this road quite a while you know what is your perspective i suppose on intel power max and m1 power max not so much in terms of like oh they're bad or good but just the fact that like what was the limitations that intel put because one thing i understand with the m1 powered max and this chip is that Apple can design a chip that is specific to their machine rather than an Intel chip which is amazing I'm

sure in many regards but not laser focused on what they're trying to achieve with a Mac mini or a MacBook Air or a MacBook Pro like that's the difference there is is an Intel chip that's sort of like general purpose that anybody could use to make a computer. Whereas M1 is the beginning of a long future of chips Apple will make to make amazing machines that only Apple can make. Yeah, I think you're absolutely right there. And it happens at several different layers in the silicon that happens. Silicon. Right, we have the, well, Apple has built this processor now that handles things like retain and release much more quickly than an Intel processor can. And part of the reason they can do this is because they know what software is being built for their hardware. They can measure it, they can track it, and then they can say, well, let's make that thing, which is taking some percentage of every app's time,

let's just optimize that as much as we can because we know it will benefit every customer and every app. And so they can make that sort of optimization directly there in the hardware they control. And so that's certainly one place where we see a big benefit. And Intel wouldn't necessarily do that because they're not optimizing for Objective-C and Swift. They're optimizing for whatever workloads they're optimizing for,

or maybe not optimizing for a specific workload. Right, they're generalizing, yeah. The general thing. Right. And then, of course, the system on a chip that we have here is not just about the central cores and the instruction sets, but it's also about what the memory management looks like. And having this now the unified memory, which lets you share memory

between different like the video core and the CPU, and so on, means that you save a lot of time that was previously going to copying that memory around into its own sort of local space. And that's another place that because Apple is designing the whole system at top to bottom, they can make some huge performance improvements. A lot of the software you create too is very visual. You know, you got a lot of graphical type software in terms of animations and movement and creating lists and combining lists and unfurling and grappling to to use the part name in my adjectives, I can imagine that there's probably some limitations. What kind of limitations did you particularly hit when building for Intel? Were they noticeable

or is it just sort of hindsight now because you have an M1 powered Mac and you understand the lack of limitations now? Did you physically hit limitations in the Intel world that you're like, man, I just wish we can get past this? Well, to be clear, we were actually pretty excited to move to the Intel world in the first place because Intel at that time had the leading performance. Right, sure. So when we did the transition from PowerPC to Intel, I mean, yes, that system had to coordinate things from a lot more vendors and so on than when Apple was building PowerPC. But even the PowerPC was not just Apple. It was Apple and IBM. And there were compromises along the whole way.

I feel like, yes, in retrospect now, it's easier to see those compromises as the compromises they were. And what we see now is really an incredible system that is designed for the workload that it's trying to do. It's a lot more like, to go back to the 80s again, like the Atari 800, which had a tiny 6502 CPU in it. But you could play some amazing games on it because it also had a sound processor that was dedicated just to spitting out certain types of sounds. And it had a graphics processor and another one that was the raster processor. All of this system was designed to coordinate together to give you something that was very advanced compared to other things that were just using the same processor, that same 6502. And what we see now with Apple Silicon is a similar sort of transition where having these different things working together from the GPU units to the machine learning units, the high efficiency cores and both sets of cores, right, those that perform strongly and those that

use less energy, that you can really build an incredible system that is more than the sum of its parts. When trying to monitor your increasingly complex architecture, you're probably wasting a ton of time jumping between data silos and dashboards. We all know the pain and New Relic wants to change that. New Relic gives you three products in one platform. First, you bring all your data from any source into the telemetry data platform. It's a schemeless time series database, so it runs super fast and it's fully managed, which means you don't have to lift a finger to scale it. You analyze and visualize that data in full stack observability, which has all the capabilities you need for monitoring and troubleshooting.

You can follow an issue from metrics to events to traces to logs in a few clicks. Yep, only one place to go for troubleshooting. Then you can make it even easier with automated detection and incident intelligence. Their applied intelligence product analyzes your data and systems to make those key connections for you. And if there's any anomalies, it makes sure the alert goes to the right person and only the right person. Best of all, they're bucking the industry's love of complicated pricing to keep things

super simple. And that means no more host-based pricing and no constant upsell for more functionality. But don't take their word for it. Go check this out for yourself. You can get one user and 100 gigs per month, totally free forever. Check it out at newrelic.com. Again, newrelic.com.

So take us back to when you had it all ready to go you had the xcode software tooling right you had it rebuilt for arm and for apple silicon and you're waiting for the hardware at that point right you still aren't sure like is this going to be like a evolutionary step improvement right are we going to see like marginal improvements? Are we going to see massive improvements? And then you finally get some hardware and you can actually run all your Omni suite of tools on Apple Silicon. Is it, I mean, in your blog post,

you talk about silky smooth and you can drag things and like, was it noticeably different? Like two machines side by side, maybe like the previous generation MacBook Pro 13 inch and then like this one, is it noticeably different? Or is it just like, I know it's noticeably different, but is it massively different? So I've got to say, when I first got the DTK, you know, one of the instructions that Apple gave developers was not to benchmark the thing. And so I intentionally was trying not to pay very

much attention to what that performance was like. And we get to the end of the process, and Apple contacts me and asks how things are going. And then they asked me, you know, so what do you think of the performance? I'm like, well, you know, I haven't been paying attention to that. And that was really when I started thinking about, well, how is this performance? Maybe now I, you know, is it okay for me to measure? And they're like, sure, sure, try it out. And that's when I started seeing that the time to render graphics to the screen was so much faster than what we were used to on Intel-based Macs. I'd say that first note was like torture, wasn't it? It's like, here, put a kid in a candy store and say, by the way, don't look at any of

the candy and surely don't touch it. It's like, here's some brand new Apple Silicon hardware, but hey, don't see how fast it runs. Because I must have been like, come on, that's what I'm here for. Now, I have to say, I just got my first M1-powered Macs for real, right? Not the DTK stuff over the summer, but the M1 powered Macs arrived yesterday. And so I, of course, set them up, did some timing tests, and entered there, of course, much faster than the DTK was. The DTK was already silky smooth and feeling great. And now we have something that's even better. So what I'm finding, you know, one of our apps takes about 10 minutes to build on an Intel MacBook Pro, the latest one that you could get, maxed out with 32 gigabytes of RAM and so on.

And when I pulled out the M1 Air and I tried doing the same build, it took five minutes and 50 seconds. On the Air, not the Pro. That was on the Air. The Air was almost twice as fast. And the Mini was even faster than that. It was five minutes, 44 seconds. And it was consistently that fast. Then five minutes, 36, five minutes, 34.

I ran each test three times just to see how things were going. And the M1 error actually gets a little bit slower because it gets hot and then it has to slow itself down to stay within its thermal budgets, since it doesn't have any fans in it. But it's amazing to me just how fast these things are. And so this morning I actually told our team, yes, let's get one for each employee. There's never going to be a better time to jump into this. Right. Yeah, I agree. I mean, I've been seeing these benchmarks like that.

It's interesting to hear that the MacBook Air, which and so just to preface this and sort of set the stage, I'm sure almost everyone listening to this has at least heard some of this but the m1 as it's been said is going to be the worst of this new good world so to speak you know and then the macbook air is the most efficient in terms of power consumption not so much in terms of performance but it's still very very capable and so to see it cut that build time in half with no fan and you probably didn't bring your legs or bring your desk you know in the process is is pretty amazing yeah and i've got to tell you uh we then ran the test on a i don't know whether apple wants you to know on a mac pro right the uh oh boy the biggest one that you can get the eight thousand dollar machine right um sorry we don't have the biggest one you can get we have the one that has

16 cores still pretty big it's still pretty big pretty beefy and it was not as fast as the M1 based MacBook Air in terms of finishing building our app well there's two sides of that then Apple can be excited or they can be like

I think they would err on the side of excitement because it's their own. What's the future? You know? Yeah. And, but you know, it might be bad for today's sales,

unfortunately. So we can't help that. It's incredible. I mean, I can't wait to see what the Mac pro looks like with, uh, with the silicon processors in it. Yeah.

Yeah. What's your daily driver? Like what's your, your, your work machine? Is it a pro or you go for a laptop yourself? I use a Mini, actually. Oh, do you?

And so now I'm using the M1 Mini. So you're already upgraded. I was going to ask you, what are you waiting for? The iMac Pro, the Mac Pro, which one are they going to upgrade next? But you're already set. You're on the M1 world. Yeah, I find that the, well, I really have on my desk here, one, two, three, four, five minis.

I don't really have room for five pros. You've got a cluster of minis on your desk. I love it. What's the road been like then, I suppose, to the native world? So some might be using Rosetta 2, some might be stuck in a different world. You're fully native, you're a native universal app, as it said. What's that road been like for you? I know you mentioned in terms of having the you know the tdk and the ease there but more so the fact that you know for the last decade we've had apple silicon just in different platforms ios ipad os etc what's been that that transition like been for you i suppose the road

to that so looking through our code base we don't really do a lot that is architecture specific. I mean, we try to avoid it. One of the things about having moved from one architecture to another over the decades is that we, you know, started to learn things like, oh, well, let's be careful about which order our bytes in. Are they big endian code? Are they little endian code? That kind of stuff. Or if we have something that does need to depend on that, like network communications, then to be sure to use API that will say, okay, well, let's convert this host to network for this particular size or whatever. So a lot of those changes we'd already made going like from PowerPC to Intel. Some of the things that we did have to design for and sort of rebuild on Apple Silicon, and some of this that we actually had to do this summer because we hadn't done it on the iPhone or iPad,

had to do with things like crash catching. Like if we have built a crash catcher into our apps that will report issues when our apps crash, much like what Apple has built in now, but we built it before Apple's existed. So it will catch a crash, offer to send email to us about it, and then the user can enter their details and the email goes to us and we can then categorize the crashes and reply to them directly and so on. And so we wanted to get that system, of course, ported over to running on Apple Silicon as well. And that work took a little bit longer.

I would say that's more like that was about a day or so. So it was not a big deal because, again, we had learned the ARM instruction set by now. Are you mostly Objective-C or is your code base, have you been adopting Swift? Are you mostly, what has it all made of? Because it's been around for so long. I'm sure a lot of it's legacy. A lot of the older code is, of course, Objective-C. And Objective-C

mixed in with just plain C. That's one of the beautiful things about Objective-C is you can have plain C in it or even dive down into assembly when you needed to for performance reasons. But lately, over the last five years, I would say maybe 60 to 70% of our new code has been written in Swift. And we've also taken some of the old Objective-C code and rewritten in Swift, or that makes sense. So on a day-to-day basis, I feel like we're

working with Swift a lot more like we're working with Swift a lot more than we're working with Objective-C. But in terms of our code base, where we have 27 years worth of Objective-C code lying around, it might be still more like 60% Objective-C at a guess. And you mentioned you're adopting some Swift UI. Can you tell us about that? Yeah, so I don't know how much you know about swifty how much

background i should give necessarily swifty ui is designed to be cross-platform it's kind of based around a a function reactive model similar to react in the web programming world okay and rather than you describe what you're trying to do more like you would describe for a web page with HTML would do instead of saying how to do it. So you're saying here's a view and I have some text in it and I want this text to be aligned with this other text or whatever else. So it's kind of a different programming model. It doesn't always work for everything, but for the things that it, where it does work, it gives you a lot of flexibility around, like you can switch between platforms, have the same code run everywhere.

So we've started using that now in our UI code as much as possible. Again, there are some problems that it's not ideal for. And for those, we can still dive back down to the traditional app kit or UI kit models of drawing views to the screen or working with user input. But for things like the widgets that we just released in OmniFocus for iOS 14, all of that code is written in SwiftUI. In fact, it has to be. That's the way widgets are implemented. And once we finished it on iOS, we're like, okay, well, let's see about bringing these widgets to Mac and Big Sur. And we had a beta ready the next day with those new widgets in them. And it turns out we really didn't have to tweak them very much at all as they were ready

to go. So that's been an encouraging sign. And we've been rebuilding things like the outline in OmniFocus, the outline of tasks, using SwiftUI SwiftUI components and looking forward to having much more powerful versions of our apps on the iPad and iPhone as a result. It's very cool stuff. So if you look down the road a bit, where do you think this goes? I mean, you're in the scene, right? You're in the developer scene of Mac software, and you've been doing this a long time, and you see like, okay, M1, so we can all at least project and say there's probably going to be an M2. But what does the future look like in your eyes of this M-powered Macintosh world, the Macs, and how does that play into OmniGroup software and

really the future of your business? I'm sure they're tightly aligned. So it looks bright, but I'm curious what your perspective is on these things. Sure. So in the 90s, we had gotten pretty spoiled by what's referred to as Moore's Law, where every year everything was getting faster. Every two years, speeds were tending to double. It's not the rate that we were going.

And when we looked at our development cycle, a lot of the products that we built, like OmniGraffle, a major version of that might take about two years to build. And so when we were starting that process, we were expecting that the hardware that we would end up shipping on would be twice as fast as you know where we were starting and obviously we have to be careful we want to run on existing shipping hardware as well but there's there are things that you can plan to do that uh that you know are possible on on faster hardware like better animations and so on or adopting some of the the stuff that you mentioned earlier about our look and feel being matching the platform really well, that might not make sense if you thought you were stuck on the same hardware that you had that day. And then, of course, in the 2000s and 2010s, that petered out, we ran into limitations in the hardware. And we started trying to solve that problem by scaling out the processors to more and more cores. We didn't have single cores getting faster, at least not nearly at the same pace,

but we tried to pull things out to different problem sets that could work well with multiple cores. Well, I'm looking forward, I guess, looking ahead to the return of having cores getting faster and faster, individual cores. I'm looking forward to knowing that we can build some things and that maybe today's hardware isn't capable of, but next year's will be. I like that. Bring it, bring,

bring it more as law back, bring it back to us. I mean, I have to think at some point we'll, we'll run into another limit, but it's nice to have those limits relaxed for a bit. And certainly I didn't expect that we would get processors that are as fast as these are right now.

So that's amazing. Yeah. That's, that's actually my next question, but you sort of answered it was your excitement level, you know, having been, you know,

since the next years, forever essentially in terms of Apple's history, how excited you are for the speed at which this CPU is, this system on a chip for the new Mac. I'm blown away by how fast they are. You heard the benchmarks, you heard the mentions during the keynotes, but seeing is believing.

We said that with Tim, even, that seeing is going to be believing in terms of actually having them in our hands, testing them out. I don't actually own one yet, so I haven't tested it, but I'm basing it on people I know and trust in the industry who do this day to day. Right. So, I mean, this has got to be blowing you away in terms of its speed. Oh, absolutely. It's so fast. Yeah. in your way in terms of like its speed it's oh absolutely so fast yeah i've i was skeptical too as i you know as i watched for example i saw the same uh video from renee ritchie that you

mentioned earlier and like okay it works well for those benchmarks that's great i wonder how it doesn't xcode for real like let's get down to it and so that's why i ran those tests last night yeah like what really no okay i've got to try this three times and not just once. Make sure it's not a fluke. And yeah, I'm blown away by how impressive these processors are already. And as you noted,

this is the slowest set of Mac Apple Silicon processors that we're ever going to get. This is the first generation. And so I'm looking forward to seeing what happens with, say, if there's an M1X or an M1Z or M and then of course, M2, M3. What does the next decade look like? Certainly the last decade has had a proven history that's been amazing with the iPad performance and iPhone performance. What do you think you'll do with the time you get back? Well, I have never run out of things'll do with the time you get back? Well, I have never run out of things to do with the time I get back.

Recompile. I look forward to just moving faster on the stuff we're building. Yeah. Well, tell the folks a little bit more about your tools. Maybe even what's coming down on the pipeline for Omni Group, your suite of tools. I'm sure we have listeners out there who are using Omni tools. We have other ones that probably haven't heard of Omni Group or maybe they're Mac users, but they're more casual. They haven't seen the productivity suite. What's out there and what's next for Omni?

Where our focus is right now is the thing I just mentioned, where we're looking at redesigning and rebuilding our apps using the latest technology instead of some of the code that we've written that's currently in OmniGraffle is 20 years old now. And so I'm looking forward to seeing what happens as we rebuild some of this in SwiftUI or just Swift in general. We have new versions of OmniFocus, OmniGraffle that are, well, I don't think I'm ready to pre-announce where we're going with some of this stuff. I couldn't help but try. Just give us a peek over the horizon,

as much as you can, but a peek, whatever the peak might be for you. What I can say, you know, I already mentioned that we're redoing the outline on the iPad. Sure, right, right, right. Being able to edit in place is a feature that'll bring that experience to be much more like what the Mac experience has been like all along. I've also mentioned, I believe, in our roadmaps for several years now that we're working on collaboration as a feature. So making it easier for people to edit things together in a live way well they certainly

have given you a reason to get rid of legacy code which is often a an angst right do you want to get rid of it and delete it well it serves its purpose but if it ages out eventually or new hardware slash new software makes it somewhat obsolete or better you know maybe not obsolete where it doesn't work but more like it'd be better if you did. It'd certainly give you a reason to rewrite legacy stuff. Yeah. Just going through and rebuilding all of the inspectors, for example, that's one of the projects that we're working on right now. And it gives us the opportunity to rethink some of the decisions we made, you know, a decade ago. And based on the experience that we've had since then and the feedback that we've had

from customers, we can think of much better ways to build it this time. So, yeah. Very cool. Ken, is there anything we haven't asked you that you want to make sure we mentioned before we let you go? And then we didn't ask you that you're like, oh man, can they please ask me about that? No, no. I really appreciate you taking the time to talk with me. Yeah. It's a great conversation. We wanted a Mac app developer's perspective on what Apple has done, and we appreciate you sharing that time to do it for us. Thank you. Thank you.

That's it for this episode of The Change Law. Thank you for tuning in. If you haven't heard yet, we have launched Change Law Plus Plus. It is our membership program that lets you get closer to the metal, remove the ads, make them disappear, as we say, and enjoy supporting us. It's the best way to directly support this show and our other podcasts here on changelog.com. And if you've never been to changelog.com, you should go there now. Again, join changelog++ to directly support our work and make the ads disappear.

Check it out at changelog.com slash plus plus. Of course, huge thanks to our partners who get it, Fastly, Linode, and Rollbar. Also, thanks to Breakmaster Cylinder for making all of our beats. And thank you to you for listening. We appreciate you. Bye.