For iOS developers, WWDC is always something of a New Year. We are presented with so many new products, and sometimes you can get lost in them. Most of my colleagues are trying to be in touch by watching “Platform State of Union” and all “What’s new” sessions. The event basically provides an opportunity to developers a glimpse of the features to expect from the software part. When Apple has a conference like this one, they want to make sure they have enough time to get everything done. In order to do this, they need to be able to work at their own pace and not worry about how long it will take them to get something done.
This means that if you have a small project, it may not be that important but once you move into larger projects with more people involved, every second saved can be worth several dollars in terms of money saved or profit made by the company. The platform tightly integrates programming languages, frameworks, and tools. Everyone gains when these three complement one another. Customers receive a consistent experience, such as scrolling that feels right every time. And developers may devote more time and attention to what distinguishes the app.
And it’s fine, you don’t need to spend so much time for this other unpopular stuff. However, in these, not-so-popular videos as couple of them may be called as “hidden gems” because of the content or a beautiful presentation/structure. Let me show couple of them!
Meet WeatherKit
https://developer.apple.com/videos/play/wwdc2022/10003/
I think it’s always interesting to work with frame forces that people can use. This year Apple has added another one of these. Now your weather apps can be even better, more accurate, and faster. Technically, WeatherKit supports async/await, allowing it to be used in conjunction with SwiftUI. There’s a small price tag, but it seems to be cheaper than other competitors so far. The interface itself looks comfortable too.
As for the session itself, I liked the narrator. Everything is very dynamic, with jokes and some easter eggs.
Apple Weather kit delivers current weather, 10-day hourly forecasts, daily predictions, and historical weather using high-resolution meteorological models integrated with machine learning and prediction algorithms. While the new iOS 16/iPadOS/macOS Ventura is powered by the Apple Weather Service, developers on those platforms may now access Apple's weather data in their own apps using WeatherKit. Adding the data to an app using Swift appears to be very simple, with API calls based on location—the data is also accessible via a REST API for other languages or use cases. Apple has always been about innovation, and that's never been more apparent than when it comes to their iOS platform.
They've always been able to make the most of their resources—and now, with the release of WeatherKit, they've made it easier than ever for developers to take advantage of all of the data available through Apple's servers.Now, developers don't have to worry about building their own weather API or paying for access to another platform's API—they can simply use WeatherKit and get all of the functionality that comes along with it. The possibilities are endless! Developers will be able to build apps with built-in weather features right out of the gate when Apple's software updates ship in the fall. There's big news is that WeatherKit can also be used in web apps and android apps thanks to REST APIs, so you can use its API to provide weather information in your web app — helping you keep your users on the platform longer and making sure they aren't getting bounced around between browsers.
What’s new in HealthKit
https://developer.apple.com/videos/play/wwdc2022/10005/
I have already reported on this framework and was amazed at its full functionality. You can see my review here, but it’s in Russian. This year, Apple added even more features. Sounds cool to me! I will tell you why
Firstly, the support for triathlon trainings is fantastic, with breaks between activities. It seems that Apple itself, in the development, involved people themselves engaged in this crazy sport. And secondly, a vital feature has emerged for many people with glasses. I asked around my friends who have vision problems. And they shared that it’s very convenient to have it all on the phone. Thirdly, this hallmark gives a clear and current overview of health status. It consolidates health data from iPhone, Apple Watch, and third-party apps that are already in use, thus allowing anyone to track the health process. It recommends other helpful apps to round out their collection and makes it easy to learn about health matters.
As it was indicated, it is easy to put data at your fingertips, so you can see your trends over time and spot potential issues early. Equally, it allows users to manage their own health data, as well as family members' data. Surprisingly, with the new Health Records feature, medical data from multiple providers is consolidated in one place. It is important to note that it is designed to work with the new HealthKit framework. The powerful API can be intimidating at first but depending on any complex undertaking of a developer, the framework is pretty helpful. I believe apple has emphasized on optimization and am happy that the company is taking developer feedback seriously.
The data sharing feature is a great feature for securely storing fitness data as HealthKit Repo offers a centralized data store. A standardized and unified store for fitness data is offered by HealthKit. It will make it easier to create applications and gadgets that can exchange fitness-related data. Despite being slightly more complicated than Apple's other native applications, HealthKit allows users to compare all of their data on a single page, which is useful if they want to see how various aspects interact.
The session itself is exciting and easy, and I recommend watching it. Cheers!
The SwiftUI cookbook for navigation
https://developer.apple.com/videos/play/wwdc2022/10054/
Disclaimer: don’t watch this session hungry!
Preparing to navigate has always been difficult. But with the new updates in SwiftUI, they’ve tried to show us how to do it properly, clearly, neatly, and simply. I’m afraid I have to disagree with the approach, but the session allows us to sort out the problems and find the right solution. This makes it an ideal candidate to watch. The API makes it simple to describe the navigation style that best suits the demands of the app. You may simply save and restore selections, as well as alter the whole contents of a navigation stack, with strong programmatic control over the presentation of app’s views.
This is extremely handy for dealing with critical activities such as configuring your app's start state, managing transitions across size classes, and responding to deep links. Apps are all about translating concepts, code, and APIs into user experiences. And the best applications are those that can meet users right where they are. Since the new version of Async-Await has been released in Swift 5.5, it has become possible to make network calls without freezing the UI thread. When I first heard about this feature, I was inspired by the creativity in how the Navigation API can lead to valuable extensions in app development. I’m excited about this new API, but it has required more than just an update to our developer tools.
We’re going to build a UI that works on both iOS and Android, which means we will have to modify not only our app but also the way users navigate. Since all of this is done at runtime, it can take time and effort to catch everything up before releasing a polished experience that’s ready for adoption. When working with NavigationLink, it can be tempting to convert an optional-containing binding to a boolean rather than an optional one. The reason is simple and obvious: a navigation action that contains an optional component on its payload will pop the component upon completing a transition in which the component is present in the navigation link. While this is not necessarily a bad thing, forcing such behaviour can cause unintended side effects.
Demystify parallelization in Xcode builds
https://developer.apple.com/videos/play/wwdc2022/110364/
I like that recently they have started adding sessions with the prefix “demystify.” There was some cool about SwiftUIs last year. All the details of the technical implementation are captured and focused on. Sometimes when I watch other sessions, I miss this hardcore, under the hood. The session itself lets you understand the critical development mechanism — the process of building your app.
While you have a small project, it may not be that important, but once you move to a large company, every second you save can be worth several dollars to the business. So, it is crucial to understand and understand the parallelization process. And of course, the new tool, Build Timeline, is worth mentioning. Everything is excellent and convenient, as always. Xcode 14 adds parallelization of the build process for even faster build times for multi-core Macs. Apple has been putting up a lot of signs lately about the new xbuild tool. It's a great way to keep your code clean and organized, and that means faster build times for your products. Xcode 14 includes a number of improvements, but one that's definitely worth noting is the parallelization of some parts of the build process.
Xcode starts the compilation of a target as soon as the build and runs scripts are complete. This means that the next target to be built will start a little bit early compared to Xcode 13, since linking other operations can now be done in parallel. Xcode's build timeline shows you the steps that make up your build process, from when you change code to when the app is ready for distribution. It's a great way to see how your code changes affect the whole process. Xcode's visualizer also allows you to see how builds are parallelized (assistant editor).
Different colours indicate how much time is spent on each target, and empty space shows blocked tasks. Sandboxed shell scripts define their inputs/outputs and help in building system management dependencies. Eager linking happens when you use a pure Swift target, which means that those targets can be built without waiting for other parts of your project to be built before running through Xcode's interface.
