Published by
Every year at Apple’s WorldWide Developer’s Conference (WWDC), developers are provided new functionality in the operating systems. These exciting new features are the thing most often focused on in various recap discussions. However, that’s definitely not the only thing worth noting during the announcements from DubDub.
N-1 and Delaying Implementations
One reason why the latest technology released isn’t necessarily the most important thing to many developers is that a significant portion of the developer community waits until those features are more widely available to bring them to our user experiences. At BottleRocket, we try to focus on releasing for iOS version N-1; that is to say, we try to release for one version earlier than the most recent. This ensures that our client’s projects provide a reasonably up-to-date experience, as well as ensuring that we don’t build functionality that users that lag a little bit in updating can’t access.
When iOS 16 is released in September (anticipated), we’ll be able to safely target features found in iOS 15.
The most important of these to our iOS development team is the viability of SwiftUI for larger projects. Just like with Swift as a whole, the early versions of SwiftUI were generally not robust enough to build larger projects with. However, iOS 15’s updates to SwiftUI definitely raised the bar, and now we’ll be more comfortable using this declarative language to build our user interfaces.
As a side note, the improvements we’ll be seeing when we target iOS 16 are astounding. We can hardly wait to be able to go all-in with SwiftUI once these come online.
What We Can Use Immediately
It wouldn’t be all that exciting to just discuss what we might do next year. You might wonder what we get to use right away, and rightfully so.
Improvements to Regex
Sometimes improvements are so good they get backported to earlier versions of iOS shortly after the launch of the new version; for example, we saw this with the implementation of Async/Await during 2021’s WWDC. This feature was ultimately implemented back to iOS 13. This is understandable because fundamentally it was a change to the programming language and not the operating system, and so we were able to use it widely right away.
We’re hopeful that the updates to Regular Expressions (regexes) also become available to earlier versions of iOS. These improvements include two major components; compile-time validation of regular expressions, and a new Domain-Specific Language for the same.
There is an aphorism that is stated as such: “You have a problem, and you decide that regular expressions are the solution. Now you have TWO problems.” Regexes are notoriously difficult to get right. With the new version of Xcode, they are now validated as correct (or in need of fixing) during development time, instead of waiting until the app is run — by then, it’s far too late to fix things.
let baseString = "An anchor or an anchorman, take your pick"
let regex = try Regex("a(.*) ")
let match = baseString.firstMatch(of: regex)
print(match?.0)
The best part is that even if we don’t get official support for earlier versions of iOS, the way that regular expressions are written is universal across languages. This means we can use the Swift tools to verify that our regex is correct, and then bring that verified regex into our project targeting an earlier version of iOS.
<script src="https://gist.github.com/rmirabelli/567f1eeeee245cd252c37085a9523a8f.js"></script>
The second of these, a Domain-Specific Language for Regexes, makes them even easier to write. Instead of the complex syntax of a typical regex (example one and even example two), we get a much more readable solution (as in example three, below).
<script src="https://gist.github.com/rmirabelli/6c0e24d3e92f290cb733fef638967aac.js"></script>
Example three: using the new Swift regex DSL
Improvements to SwiftUI Previews
An even more exciting update is the new SwiftUI preview pane. There are three significant changes here, which together will not only increase the speed with which we build for SwiftUI, but also improve the quality of what we build.
The first is that by default, SwiftUI previews are now interactive as default. This is in contrast to earlier versions of Xcode, where these previews were static by default. This points to an overall improvement in the performance of these previews more than anything else. We would generally choose static previews just to speed up development time and responsiveness of our development computers.
The second is the ability to quickly toggle between different appearance styles, such as light mode vs dark mode or landscape vs portrait. This can be used with the same interactivity as mentioned above. Being able to quickly see the results of user changes is a great improvement.
The third is probably the most important of them all; we can choose to view multiple variations at the same time (though not interactively). While this is nice for orientation or color scheme changes, this feature really becomes meaningful as we support Dynamic Type (variable font sizes) within our apps. Having an app that properly handles the user’s preferences for font size is often complicated, and checking a wide range of options is time-consuming. This new feature will have immediate gains in our development speed and developing good-looking layouts no matter what the user’s needs for typeface settings are.
For all of these changes, we will be able to see these benefits in any project using SwiftUI, no matter what version of iOS we are supporting. This makes the feature’s footprint even larger than it might otherwise seem.
Why Quality of Life Changes Matter
Ultimately, all developers have the goal of providing software that meets the needs of the customer, whatever those might be. When our tools become more capable, we can deliver better software faster.
