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.

This year, we spoke to:

• Vidit Bhargava, the creator of the dictionary app LookUp
• Steve Troughton-Smith, the creator of Broadcasts, Pastel, Grace and other apps
• Malin Sundberg, the creator of time tracking app Orbit
• Ish ShaBazz, the creator of notebook and habit tracking app Capsicum
• Sawyer Blatz, the creator of budgeting app Nudget
• Majid Jabrayilov, the creator of CardioBot
• John Sundell, the creator of Swift by Sundell and co-host of the Stacktrace podcast

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.

Impactful APIs: What new or significantly updated API do you expect will have the greatest impact on third-party apps?

Every WWDC is a mixture of frameworks and APIs for new, headline features, as well as changes to existing APIs that users usually don’t see. These latter ‘quality-of-life’ updates may not be visible to users, but they free developers up to work on the fun, new cutting-edge aspects of their apps. WWDC 2021 didn’t include a feature like widgets that nearly all developers can take advantage of, but it did introduce a long list of updates that will make many developers’ lives easier, allowing them to concentrate on the most innovative aspects of their apps.

For example, Ish ShaBazz said:

I think the winner this year might be Foundation. The new formatters, improved localization support, attributed text, and native support for Markdown are all game-changing.

Steve Troughton-Smith ticked off several UIKit and SwiftUI improvements that will help a wide range of developers:

There are many highlights in UIKit this year, like proper keyboard focus and tabbing behavior, button styles, and half-height sheets, and some incredible no-brainer additions like being able to easily resize an image without having to go find an appropriate snippet on StackOverflow. Realistically, with the massive SwiftUI adoption over the past year, the improvements to SwiftUI will have the greatest reach across the app ecosystem.

In addition to specific features introduced this year, Malin Sundberg pointed out something that I’ve been thinking about a lot lately: the idea of Apple Platform Development, which lays the foundation for developers to build apps for all of the company’s platforms more easily instead of specializing in one or two:

In terms of bigger features, I think we will see apps adopting support for SharePlay, Quick Notes, and Shortcuts. These APIs can be useful for apps in a lot of categories. I’d also expect to see almost all third-party watchOS apps adding support for the always-on screen. It’s something that will be added by default when developers build their apps with the watchOS 8 SDK and allow for some tweaking to make it even better.

There were also non-API-related changes that I think we’ll see impacting third-party developers. Lately, we’ve seen Apple advocating for the concept of Apple Platform Development. The state of the different platforms and the direction of the frameworks naturally paves the way for developers to, rather than being iOS developers, macOS developers, or watchOS developers, embrace developing for all of Apple’s Platforms. Frameworks such as SwiftUI and Catalyst, the ability to add support for features like Shortcuts and Widgets for different platforms, and newly introduced tooling like TestFlight for Mac give developers a great opportunity to provide awesome app experiences on more than just one platform.

The Power of Shortcuts Everywhere: What effect do you think the addition of Shortcuts to the Mac will have on all of Apple’s platforms?

There was a lot of speculation about Shortcuts coming to the Mac in the months leading up to WWDC, but few people expected how deeply integrated the automation app would be with existing Mac technologies or how direct Apple would be in declaring it the future of automation on the desktop. The reaction to the big announcement was universally positive.

Alluding to Shortcuts’ origins as an indie app from a small team of developers, ShaBazz celebrated the improved ability to share shortcuts:

Shortcuts on Mac makes the greatest indie story of all time complete. I love it. With Shortcuts now available on the Mac, we have multiple shareable formats. Automations are a bit of a niche power user thing, but occasionally things catch on that are wildly useful. I think the increased shareable nature of shortcuts will increase their adoption across all platforms.

Vidit Bhargava expects the expansion of Shortcuts to lead to greater developer adoption and more powerful actions on other platforms:

Shortcuts coming to the Mac and being announced as the future of automation on the platform is a big move. The powerful actions that Shortcuts brings for the Mac will also end up being useful for platforms like iPadOS.

But more than that, it invites so many more developers to take advantage of Shortcuts, and given the flexibility of the Intents Framework, it’s not hard to imagine the automation workflows growing on all platforms. So when something like the ML Super Resolution comes to Shortcuts on the Mac, one can hope to take advantage of that on iPadOS too.

Overall, it’s a move that benefits all platforms, and as an automation user, I am really excited for the future of Shortcuts. As a developer, I find the Intents framework that powers Shortcuts on both iOS and macOS to be flexible enough to have powerful actions come on all platforms for my apps.

Sawyer Blatz thinks Shortcuts for Mac should also make it easier for users to build complex shortcuts:

The biggest impact I think this will have is the ease of creation. Creating complex shortcuts on iOS can be a bit cumbersome, and I think being able to sit down in front of a machine with a keyboard and mouse will make this a lot easier.

As Steve Troughton-Smith notes, though, Shortcuts has big shoes to fill if it is eventually going to replace existing scripting technologies:

Apple didn’t hedge its bets with Shortcuts — it made it very clear that it is the ‘future of automation’ across Apple’s platforms. On the one hand, that means Shortcuts has to grow dramatically in capability to fill the shoes of the desktop tools it is replacing, and iPad and iPhone should inherit some of that work. On the other hand, it points to an increased deemphasis on tried and tested open scripting technologies on the Mac.

Building Apps on the iPad: What impact do you think being able to publish apps from Swift Playgrounds will have?

This fall will mark the first time someone will be able to build an app for the iPad and publish it all from the device itself, using the Swift Playgrounds app. Swift Playgrounds has been used by everyone from beginners learning to code to veteran developers who use the app to prototype apps and test ideas. Even though Swift Playgrounds is no match for Xcode running on a Mac, the ability to make apps on the device that will run them is a big milestone for the iPad.

Majid Jabrayilov expects to see Swift Playgrounds drive a fresh crop of apps on the App Store:

It was great to see the first version of Xcode on iPad. It doesn’t have all the features of the desktop version of Xcode but still allows you to do many things. I believe that it will bring us many new apps from the people who start learning Swift and SwiftUI.

Bhargava expects camera apps and utilities to emerge as natural fits for Swift Playgrounds-based development:

Swift Playgrounds gaining support for developing and publishing Swift UI apps is an important first step in an iPad-first development environment.

I can see it becoming a useful tool for side-projects, interaction design experiments, and for people getting started into app development. The focused environment that the iPad provides is powerful enough for developers to quickly try building smaller parts of their apps and then move to the Xcode.

One area where the iPad is a natural development environment is camera first apps, i.e., apps that involve augmented reality or machine learning-based frameworks like Vision. The iPad’s built-in camera enables a much faster way to test and prototype the apps. With AR gaining more and more traction, future iterations of Swift Playgrounds would enable app development in a way that Xcode wouldn’t be a great fit for.

In terms of an immediate impact, I can see a lot smaller utilities coming to the App Store, given how Playgrounds removes a fair amount of friction in publishing apps.

I share Blatz and ShaBazz’s expectation that publishing from Swift Playgrounds will have a big impact on education and making development accessible to more people:

Blatz:

I think being able to publish apps directly from Playgrounds will be huge for educational purposes. Demonstrating to someone that they can build something and put it right on the App Store right from their iPad really lowers the barrier to entry to app development. I think it’s unlikely we’ll see huge multi-year, complicated apps published this way because it’s still a lot more limited than Xcode, but it certainly has its place and will be great for smaller projects or those learning to write code.

ShaBazz:

Being able to publish apps from Swift Playgrounds opens up a world of possibilities for folks who don’t have or aren’t able to afford a MacBook. That’s a whole lot of people. I do a lot of mentoring of folks who are just starting to learn to code. Many of them have an iPad, but a MacBook is more of an investment than they can reasonably afford. Having the ability to create apps and publish them can be life-changing in some of these cases.

SharePlay: What impact do you think SharePlay will have for third-party developers?

SharePlay is a new framework that Apple has built into FaceTime that allows for shared, synchronized group activities like watching a movie or TV show, listening to an album, or sharing their device’s screen. Two areas I expect to see third-party developers extend SharePlay is educational and gaming apps. Both feel like natural fits for small group sessions. The possibilities are exciting, but there are potential obstacles too.

Sundberg and Blatz see many of the same opportunities that immediately sprung to my mind when I saw Apple demo SharePlay:

Sundberg:

I think SharePlay can add a much more personal experience and a very collaborative environment to apps. It naturally fits into a lot of different app categories, like productivity and collaborative work tools, entertainment apps, games, and educational apps. Normally, adding this kind of feature would require a lot of work from developers having to build it all from scratch, so it’s great that there’s now an API for this. I’m super excited to see what everyone will build with it. I have some fun ideas myself.

Blatz:

I’m honestly really excited for this one. I can imagine collaboration in apps getting a lot more intimate because of this. Imagine being able to drop into a friend’s gaming session or working on an art project with them—the possibilities feel a bit endless! I can’t wait to see what people do in this space.

However, as John Sundell points out, SharePlay may have discoverability issues reminiscent of iMessage apps and there are limits to what developers can do with it:

This is an interesting one because I think, as a technology, SharePlay is super interesting. The API seems powerful and well-designed, and there seem to be quite a few limitations as to what kind of FaceTime-integrated experience that you can build using it. However, just like with iMessage apps, I think discoverability could become an issue. How will people discover that they can use a particular app within a FaceTime call? But, in general, I applaud all of Apple’s efforts that involve giving us an opportunity to tightly integrate our apps with the system, so I’m curious to see to what extent both developers and end-users will end up using SharePlay.

Asynchronicity:¹Why is Swift concurrency a big deal?

If you were following developer reactions during WWDC, you probably saw excitement around concurrency coming to the Swift programming language. With only a loose understanding of what asynchronous programming is, I wanted to know why so many people think Swift concurrency is a big deal.

As John Sundell and others explained, a big part of the hubbub is that asynchronous code will be simpler to implement, less prone to errors, and ultimately mean fewer bugs for users to deal with:

Up until this point, Swift hasn’t really had any built-in way to write asynchronous code. Sure, we’ve had technologies like Grand Central Dispatch, OperationQueue, Combine, and more, but neither of those technologies is really integrated into the language itself. Since asynchronous and concurrent programming is becoming increasingly more common, as apps need to perform more tasks in parallel, having first-class support for those patterns within the language itself will likely make writing such code much simpler and less error-prone.

As Blatz notes, the change should make it easier for new developers and reduce reliance on third-party libraries:

Concurrency can often be really confusing and complicated. Keeping track of which thread you’re supposed to be on, dealing with tangled and messy syntax, avoiding race conditions, yuck! Many developers use third-party libraries like PromiseKit to address these problems today, so having a native solution built right into Swift will make it easier to hit the ground running for new devs or new projects. Languages like Kotlin have had async for a while, so it’s super cool to see Swift catching up in this respect. Unfortunately, this syntax currently only works with iOS 15+, which means we likely won’t see it in many production apps for several years, but it’s a start at least!

Troughton-Smith advises approaching asynchronous code with caution but sees potential for the feature to allow more developers to leverage Apple’s multicore chips:

It isn’t [a big deal]! Swift concurrency is a long-awaited feature that brings Swift programming closer to the concurrency model of other languages and makes it more clear which parts of the system APIs are safe to use on a background thread. Since Apple introduced Grand Central Dispatch in 2009, its previous concurrency model, we have learned a lot about where and how concurrency (doing multiple tasks at the same time) makes things faster in our apps; realistically, concurrency is something that should be used very sparingly for most tasks. Thus, lowering the barrier to entry, as Swift concurrency will do for newer programmers, is something that needs further education and illustration on Apple’s part to have the best effect. If applied correctly, it will really let apps take advantage of any massively multicore Apple Silicon processors in the pipeline.

Are We There Yet?: Is SwiftUI a viable alternative for most projects?

Apple has continued to push SwiftUI forward rapidly.

As Jabrayilov explains, it’s now an excellent option for indie developers:

WWDC21 brought another release of SwiftUI, which now has many new APIs that allow us to build better apps that leverage all the power of the platform. All the new SwiftUI features require iOS15, but I think that SwiftUI is the best way to build an app for independent developers. With the current iteration of SwiftUI, we finally have the features we missed, like focus management and search component, and many other minor additions.

The benefits of SwiftUI to small teams are echoed by Sundberg, who says the usefulness of the framework:

still depends a lot on the project. You need to consider things like: Which version of iOS/iPadOS/macOS do you want to support? Do you already have an existing codebase? Are you adding a lot of new features and functionality to an existing app? Do you have the time, and are you comfortable learning a framework that’s still changing a lot from year to year? In general, the earlier version of iOS/iPadOS/macOS you wish to support, the more you probably will have to fall back to using UIKit and AppKit with your SwiftUI code.

I’ve personally used SwiftUI a lot for new projects since it was released. My partner and I shipped our app that’s primarily built using SwiftUI for macOS, iOS, iPadOS, and watchOS. I don’t think we would have been able to do this within a year as a team of two if we would have used AppKit and UIKit. My overall experience using SwiftUI has been great, and I’d use it for any new app I’m building, but I certainly did run into some of its limitations and some pain points along the way.

Apple put a lot of focus on SwiftUI in their sessions this year and added many new, welcoming features to the framework. I think there are so many benefits to using SwiftUI and the sooner you start to learn it, the better, even if it’s just to use it for a new feature. Once you’re comfortable with it and know how to work with some of its limitations, it’s a lot faster to build and iterate on the app’s design and user interface.

Troughton-Smith views SwiftUI as a good place to start, but difficult for using to build an entire app:

As an entry-level experience, SwiftUI is amazing; it’s really fun to prototype with, and you can get a working app very quickly. I use it for all my prototypes today. It gives both iOS and Mac developers a path to the future that they can start to take at their own leisure, but fleshing it out is going to take most of the coming decade.

SwiftUI excels for a couple of tasks currently: making Apple Watch apps and replacing Interface Builder by building straightforward layouts that you can incorporate into your non-SwiftUI app as views, panels, or modal popups. Right now, SwiftUI is a situational tool, and that’s OK! I’ve adopted it in all of my apps, and I look forward to being able to adopt more of it as it evolves.

It’s very difficult to build an incredible SwiftUI app right now, no matter your skill level, because so many things still aren’t there, and many of those that are just don’t work right. You have to become an expert at integrating SwiftUI with UIKit (or AppKit, for that matter), hacking around and patching out all the little issues and behaviors that just can’t be otherwise coerced into doing what you need. And even if you get past all that, you can easily squander all of the performance benefits of SwiftUI when dealing with the kinds of large data sets (lists, grids) that are common and necessary in apps today. It’s also pretty tough that when Apple does add improvements to SwiftUI, they are tied to the latest OS and can’t be back-deployed — even when the new features are merely exposing things that have been available to UIKit and AppKit apps for years.

Sundell takes a similar approach:

Yes, absolutely. While very few apps will likely be built entirely in SwiftUI right now, I think most apps can make great use of it in one way or another. I personally write the majority of my production UI code using SwiftUI these days, but I’m also happy to fall back to either UIKit (on iOS) or AppKit (on macOS) when needed. The fact that the interoperability story between SwiftUI and those previous UI frameworks is so strong gives me a lot of confidence in using it as my default UI technology unless the app I’m working on needs to support iOS 12 or earlier. SwiftUI is still far from perfect, and there are still rough edges that you need to work around, but it is definitely a “net win” in my opinion.

Building in the Clouds: Who is Xcode Cloud for, and what problem does it solve?

Apple announced Xcode Cloud at WWDC, a service coming later this year that will support the development process by offloading building, testing, and deployment to the cloud. ShaBazz explains the advantages that the service will provide:

Xcode Cloud is for anyone who would benefit from automating their building, testing, and deployment workflow. It solves the problem of having to do lots of repetitive manual work but also allows developers to test on beta versions of Xcode and operating systems without having to install beta software on their machines and devices.

Bhargava sees advantages to Xcode Cloud’s integration with App Store Connect and TestFlight too:

Xcode Cloud is Apple’s offering of a Continuous Integration and continuous deployment tool. CI/CD tools automate the workflow of building, testing, and deploying code changes. It’s something that development teams can use to speed up the development process and ship more reliable code, as CI/CD tools can offload these time-consuming tasks to the cloud.

Xcode Cloud’s promise is that it offers the features of a CI/CD tool (automated workflows for building, testing, and deploying changes) and seamlessly integrating with App Store Connect and TestFlight, in a secure and private system.

I can see this becoming a useful CI/CD tool for small development teams who don’t already have a system in place for CI/CD practices and don’t want to spend a lot of time or money in setting up one. Apple’s integration with App Store Connect and TestFlight is also bound to make Apple platform developers consider this over others.

Wish List: What everyday annoyance and big-ticket item do you want to see Apple tackle for developers next?

WWDC unloaded a lot of goodies on developers, but everyone’s got something they hoped for and didn’t get and would like to see Apple tackle next.

Jabrayhilov would like to see more from Swift UI:

I love the roadmap that Apple has. One thing I would like to see is more frequent updates to SwiftUI. We don’t want to wait a year to have bug fixes or new features in SwiftUI.

ShaBazz would like to see a Dark Sky-based weather API and a server-free CloudKit solution, both of which I agree would be great additions, especially for indie developers:

A weather API would be great. With Apple’s acquisition of Dark Sky, many developers are in need of a new weather provider. This year Apple announced lots of changes to the Weather app, and I am hoping an API will be available next year. I would also like server-less CloudKit that would allow developers to do things like schedule automated push notifications from CloudKit. This would give developers an alternative to managing their own servers for small tasks.

Blatz wants the interactive widgets I was convinced were coming this year but didn’t:

I would still love to see widgets that allow user interaction. I’m also still itching for true custom watch faces that developers could take advantage of! Both of these were touched on a bit last year, and I was hoping for more this year, but unfortunately, we didn’t get any news for either of these areas.

No code (or text) editor is ever perfect, so I can relate to Sundell’s hope for refocused efforts on Xcode’s core code editing functionality:

Honestly, I’d love for Apple to just keep iterating on and improving the core Xcode code editing experience. Writing Swift code in Xcode is still, seven years later, often a frustrating experience — with autocomplete that stops working, documentation that doesn’t appear, very fragile syntax highlighting, and so on. While they keep adding new IDE-style integrations and features (such as the new auto-importing of modules, for example, which is fantastic), I wish they’d instead focus on making the actual code writing experience completely rock-solid. Maybe next year.

That’s it for this year’s developer debrief. Thanks again to the participants. For the complete, unabridged version of each of the seven interviews, don’t miss MacStories Weekly, our Club MacStories newsletter, this Friday and next. If you’re not a member of Club MacStories yet, you can join here.

Stay tuned for more from our 2021 Summer OS Preview Series soon. We’ll dig more deeply into the features of the OS betas once they are available publicly for our readers to try, and we’ll also have a few more interviews on AppStories, covering the most interesting features coming this fall. To ensure you don’t miss anything, you can also follow our 2021 Summer OS Preview Series through our dedicated hub, or subscribe to its RSS feed.