Yesterday, Apple released Swift Playgrounds 4.0, the first version of the app from which you can build an app and publish it on the App Store. That’s a big step forward for the app that started as a limited sandbox for learning to code. The app is not as capable as Xcode. Still, with support for Swift 5.5, live previewing of the app you’re building as you code, multiwindowing, access to SwiftUI, UIKit, the ability to move projects between Swift Playgrounds and Xcode, and more, the app has an enormous amount of potential waiting to be tapped.
Apple’s coding course selection has grown steadily since 2016.
Swift Playgrounds has steadily improved since its introduction in 2016 on the iPad and launch on the Mac last year. Early versions of the app were firmly grounded in learning to code. That’s still the case. The app includes an extensive catalog of lessons on how to code and build apps. There’s also a new ‘Get Started with Apps’ lesson and an App Gallery section that includes several sample apps to help teach coding basics.
We kicked off the MacStories Summer OS Preview Series on AppStories a couple of weeks ago with interviews of four 2021 Apple Design Award winners. We’ll also publish a series of in-depth first-looks at what users can expect this fall from iOS and iPadOS 15, macOS Monterey, and watchOS 8. We’ll also be interviewing developers on AppStories, exploring the technical details that we expect will have the biggest impact on upcoming app updates and releases. You can follow along with the series through our dedicated hub or subscribe to its RSS feed.
Today, we wanted to continue the conversations that began with the AppStories ADA interviews by talking to seven more developers about a wide range of topics. Now that the initial excitement has passed and the dust settled from WWDC, we wanted to hear more from the developers who will be using Apple’s latest technologies to bring readers new apps and innovative updates to readers this fall.
The following is a collection of the responses from each of the developers I interviewed on a wide range of topics from new frameworks and APIs to Shortcuts on the Mac, the ability to publish apps built on the iPad, SharePlay, SwiftUI, Swift concurrency, and more. Thanks so much to everyone for sharing their insights on these topics with MacStories readers. We greatly appreciate everyone taking time out of their busy post-WWDC schedules to participate.
I received fantastic, thoughtful responses from all of the developers I interviewed, which resulted in more material than I could use for this story. However, we’ll be featuring unabridged versions of the interviews in the next two issues of MacStories Weekly. It’s an excellent way to get an even deeper sense of the ramifications of this year’s WWDC announcements. If you’re not already a member, you can learn more at club.macstories.net or sign up below.
It’s time for Apple Watch apps to grow up, and Chirp for Twitter is leading the charge.
Chirp 2.0 debuted today, offering a full-featured Twitter experience on the Apple Watch. Chirp was already the prime Twitter client on watchOS, but with version 2 the app becomes something truly special: an iPhone-quality app on the Watch. Thanks to SwiftUI and other new developer tools Apple has built for watchOS, Chirp can do all the things you would expect from a full-featured iOS app, such as load your whole timeline, with liking and retweeting functionality, display videos and open links embedded in tweets, offer tweet composition, full user profiles, DMs, and much, much more.
Watch developer Will Bishop has been shipping impressiveapps for a while, but Chirp 2.0 undoubtedly represents his best work yet.
Ironically, Apple chose to name this year’s update to macOS after an island. Since the iPhone and iOS took off, macOS has sometimes felt like an island isolated from the rest of the company’s OSes, but the goal articulated by the company at WWDC this year was quite the opposite. Apple clearly telegraphed that change is coming to the Mac and it’s designed to bridge the user experiences between each of its platforms.
To developers, that message came in the form of Catalyst and SwiftUI. Catalyst, which was previewed as an unnamed ‘Sneak Peek’ in 2018, is meant to make it easier for iPadOS developers to bring their apps to the Mac. SwiftUI has a similar longer-term goal of unifying and streamlining how developers build the interfaces for their apps across a range of devices, for everything from the Apple Watch to the Mac.
The efforts to draw macOS in closer with Apple’s other operating systems run deeper than just developer tools though. macOS may have been the foundation on which iOS was built, but in the years that followed iOS’s introduction, the two OSes grew apart. Identically-named apps were developed on different schedules, which meant they rarely included the same features. Also, system-level functionality like System Preferences, which serves the same purpose as iOS’s Settings app, was unfamiliar, making Mac adoption unnecessarily hard for newcomers. Catalina is an attempt to address those kinds of inconsistent user experiences.
With Catalina, Apple has taken clear, though not always successful, steps to bridge the divide between the Mac and iOS. App functionality has been realigned, System Preferences has been rearranged, and new features have been added to make it easier to move from one platform to the other.
As with other transitional periods in the Mac’s history, this one isn’t going to be easy. However, because the change is driven by a fundamental change in computing, it’s also necessary. We live in a new climate where computing is now dominated by mobile devices. For many people, a smartphone is all the computing power they need day-to-day. That doesn’t mean there’s no longer a place for the Mac, but it’s clearly what’s driving the changes in Catalina.
Apple could have chosen to ignore the shift of the ground beneath its feet and merely maintained macOS, making the kind of small incremental changes we’ve become accustomed to in recent years. However, not adapting is as deliberate a choice as change is, and it carries just as much or more uncertainty for the Mac as a platform because it risks irrelevance.
The Mac isn’t in crisis, but it isn’t healthy either. Waiting until the Mac is on life support isn’t viable. Instead, Apple has opted to reimagine the Mac in the context of today’s computing landscape before its survival is threatened. The solution is to tie macOS more closely to iOS and iPadOS, making it an integrated point on the continuum of Apple’s devices that respects the hardware differences of the platform but isn’t different simply for the sake of difference.
Transitions are inherently messy, and so is Catalina in places. It’s a work in process that represents the first steps down a new path, not the destination itself. The destination isn’t clear yet, but Catalina’s purpose is: it’s a bridge, not an island.
At WWDC 2018, Craig Federighi provided a sneak peek at what everyone was calling Marzipan: an as-yet-unnamed way for iPad app developers to bring their apps to the Mac. So, it came as no surprise when Federighi retook the stage in 2019 and revealed more details about the project and its official name: Catalyst.
What caught a lot of developers off guard though was SwiftUI, a declarative approach to building user interfaces that was also announced at WWDC this year. SwiftUI, known before the conference as Amber, its rumored project name, was on developers’ radar almost as long as Catalyst, but it’s fair to say that few anticipated the scope of the project. The purpose of SwiftUI is to allow developers to build native user interfaces across all of Apple’s hardware platforms – from the Apple Watch to the Mac – using highly-readable, declarative syntax and a single set of tools and APIs. If that weren’t enough to get developers’ attention, using SwiftUI carries the added advantage of providing features like dark mode, dynamic type, and localization automatically.
The message from WWDC was clear: SwiftUI is the future, a unified approach to UI development designed to simplify the process of targeting multiple hardware platforms. It’s a bold, sprawling goal that will take years to refine, even if it’s eagerly adopted by developers.
However, SwiftUI also raises an interesting question: what does it mean for Catalyst? If SwiftUI is the future and spans every hardware platform, why bother bringing iPad apps to the Mac with Catalyst in the first place? It’s a fair question, but the answer is readily apparent from the very different goals of the two technologies.
SwiftUI serves the long-term goal of bringing UI development for all of Apple’s platforms under one roof and streamlining it. It won’t take over immediately though. There’s still work to be done on the framework itself, which Apple will surely expand in capability over time.
By contrast, Catalyst is a shorter-term initiative designed to address two soft spots in Apple’s lineup: the stagnation of the Mac app ecosystem, and the slow growth of pro iPad apps. The unstated assumption underlying the realignment seems to be that the two app platforms are stronger tied together than they are apart, which ultimately will protect the viability of their hardware too.
The impact of Catalyst on the Mac and iPad remains murky. It’s still too early in the process to understand what the long-term effect will be on either platform. There’s substantial execution risk that could harm the Mac or iPad, but despite some troubling signs, which I’ll get to in due course, I’m convinced that Catalyst has the potential for meaningful improvements to both platforms, especially the Mac. Let’s take a closer look at what those could be.
