HTML-код
- Опубликовано: 25 июн 2024
- WWDC 2024 is here, and it brings a lot of updates to both consumers and-most importantly-developers. In this video, I highlight WWDC24’s key announcements, including Swift 6, Xcode 16, Swift Testing, Apple Intelligence (predictive code completion and Swift Assist), and much more.
You can support the Swift Bird by…
• …becoming a sponsor: / swiftbird
• …buying me a coffee: www.buymeacoffee.com/SwiftBird
Links:
• My Swift wish list for 2024: • What I Want to See in ...
• Platforms State of the Union: • WWDC24: Platforms Stat...
• Swift 6: • WWDC24: What’s new in ...
• Xcode 16: • WWDC24: What’s new in ...
• Swift Testing: • WWDC24: Meet Swift Tes...
• Swift on Server: • WWDC24: Explore the Sw...
• Embedded Swift: • WWDC24: Go small with ...
• All WWDC24 videos: developer.apple.com/videos/ww...
Chapters:
• 0:00 Intro
• 0:50 Key Highlights
• 1:57 Swift 6
• 4:32 Apple Intelligence
• 7:06 Xcode 16 with AI Tools
• 8:48 Swift Testing
• 11:27 Updates in Other Frameworks
• 13:19 Swift on Server & Embedded Swift
• 14:39 Summary
• 15:45 Outro
The Swift Bird, a Yakov Manshin production 🎞️
Music:
• Beauty Flow by Kevin MacLeod (CC-BY 4.0)
#WWDC #Swift #softwareengineering 
Наука
Thanks for being so concise, I love it!
Glad it was helpful!
I was waiting for your review! Keep the good analysis and thank you!
Will do!
awesome vid...btw 5:50 was there a new air released a few months ago that i missed?
Thank you!
Yep, the refreshed Air came out back in March: www.theverge.com/2024/3/4/24089999/apple-macbook-air-m3-announced-13-15-inch
I mostly took a break from Swift to pick up D because I wanted to get over my fear of C/C++ languages. Regular {} and ; were kind of hard for me to get used too.
But now I am back and I am super excited for Swift 6! I have been using since 5.9 and it is my go to 'feel good' language next to perhaps Nim or Crystal. I too and looking forward to the new testing framework.
My favorite new feature is the do catch error handling. I am working on a fantasy console, partly to build my own platform, partly to learn emulators and boot environments and partly because I love games. I think I can use that in managing console errors and validating contracts. I personally prefer to write code with explicit errors, so this is kind of my dream feature. I always liked how safe swift, it is almost like a less hair pully rust or a opinionated nim imho.
Wow, seems like you’ve got a lot of experience to compare Swift to! Good luck with your console project!
Just found your channel it’s great! Any tips for someone trying to learn swift who’s new to programming?
Thank you!
Perhaps my main advice is to try different formats (textbooks, RUclips videos, etc.) before committing to a 500-page book or an expensive online course. For instance, I choose hands-on projects because I can take different routes and experiment beyond the given task, keeping myself focused and entertained. On the other hand, practical projects don’t always go smoothly (you have to investigate and solve unforeseen problems by yourself), which can demotivate those who prefer comprehensive guidance. So try a few things first and then see what works best for you. I don’t believe you need a “special talent” to learn programming-but wrong tools can make this experience miserable.
A new UI Framework and new programming language every year? Why should this be necessary or desirable? Can you elaborate? SwiftUI took years to become anything close to a production-ready framework. And why should Apple introduce a new programming language?
Sure, I’ll clarify. The purpose of this video is to highlight the updates you might’ve missed after the consumer stuff had stolen all the spotlight at the keynote. A new programming language and UI framework serve only as an illustration: Had Apple introduced something like that, it would’ve been _all_ people talk about (I witnessed the lines for SwiftUI sessions at WWDC19). The point I’m making in the video is, you shouldn’t overlook the other (exciting) updates simply because they’re not as groundbreaking as a new UI framework.
Is it just me or these new testing examples and its way to write feels like more of a proxy of the code that is being tested?
I mean if we are testing a multiply for 2... the code is probably in the app main code not on the test itself since its the main code we are testing...
Not sure if I explain well what I mean. I'm sure I'll understand it better when I tried it later and find different examples to make sense of it.
But if the @test states a sequence of expected events/results... isn't that all what we expect from tests? the whole test? so why have the body of the test?
I wouldn’t say we’re _proxying_ the production code in tests; more like defining the constraints it has to fit into, without recreating (or even knowing about) the implementation. In Swift Testing, it’s no different from the usual way we write tests.
Typically, the body of a single test consists of four parts:
1. Define an input (which we control);
2. Define the expected result (which we know is correct);
3. Call the production code (which we’re not sure works correctly) on our input and get the actual result;
4. Make sure the actual result matches our expectations.
We often need to check the same production code on different inputs, for which there’s a number of techniques: duplicating test methods (which is error-prone and tedious to update but gives you good visibility of which scenarios fail), using a for-in loop to iterate over different inputs within a single test (which requires less duplication but makes finding errors more difficult), etc. Parameterized testing solves this specific problem, without reinventing the fundamental approach to testing. It’s basically syntactic sugar to duplicate tests without you copying and pasting them manually.
Test arguments move the inputs and expectations out of the test body, but you _still_ have two more tasks to do: call the production code and compare the results. That’s what the test body is for. In the demo, I don’t multiply anything _in the test code:_ The test knows _what_ the production code has to return, but doesn’t care _how_ it does it, so the production implementation doesn’t leak into tests.
Not sure I 100% understood what you meant, so please correct me if I didn’t.
Я также проверил эту связку и не могу не подтвердить её эффективность.
Отлично, спасибо!