Hey! I’m Yakov 🙋🏼♂️ For the past 6+ years, I’ve been using Swift to build software for iOS and macOS, and on this channel, I’m sharing the things I’ve discovered. Subscribe if you find the videos helpful!
In addition to Swift / Objective-C, I also do some development in TypeScript (Node) and Rust-because I always enjoy learning something new!
Maybe that is his "i am speaking English (not my first language) face" I don't think he looks angry. I think he's just choosing his words while recoding and we can see him editing his thoughts in realtime.
Great insight! Though I’d say it’s more about emotions than thoughts. Most videos are scripted because I don’t want to confuse or mislead viewers with inaccuracies, and by the time every detail is fact-checked and proofread, they hardly evoke any sort of emotion. So when I’m recording, I’m trying to come up with ways to sound more natural and less robotic 😅
"Migrating to this version might take you a while." Not if you are an unemployed neet who uses Swift for personal projects ; ) Plus, I think I have to explore more with the pointer API and hardened concurrency model before I do serious work.
It’s a matter of perspective! Some personal projects would give a hard time to even the most experienced developers 😅 I wonder, are you interested in the pointer APIs for something specific? I can’t remember the last time I actually needed them for my real tasks 🤔
@@SwiftBird Yes, I am making a fantasy console, and I was playing with 5.10 a bit. I sort of am looking at the various pointer types. I would say 80% of my code was mostly just Swift doing that awesome reference counting. But I also did some magic with an enum and the ‘unsafepointers’ until I found out opaque pointer exists and I should be using that lol. Other then that? Not really. I actually would say the other project was a Raylib binding, but I gave up because of the frustrating lack of documentation for specifically the compiler/package manage for binding with C/C++ code. The old Raylib binding for 4.5 is alright….but 5.5 is around the corner so only using it as a soft reference. Another case is with GDExtension with swift, which I would recommend to look at if you ever wanna do game dev. It is complicated, but it is binding to Godot which is C++, so what can you do there? 🤷 Other then the fantasy console, the only other thing I am looking at is a website with Swift. I think SwiftNIO is so much better then equals in Crystal/Go’s ecosystem. (which is not saying much but at least Go makes it painless to do concurrency…) Anyway! yes, definitely a matter of perspective! I also have to do a renderer/rasterizer with Swift, but luckily most of my code was single threaded before I added an actor stub, so I will definitely have to explore that. What I really wish existed as a Linux guy…was a Bevy for Swift.
I’m genuinely impressed! Keep it up 🔥 Swift on the web is my long-time dream. I tried, more than once, to find a sustainable way of using Swift with WASM (so I can deploy Swift backends on Firebase or Cloudflare), but it seems like the Swift / JS bindings infrastructure is still very limited 😵💫
Thank you! ✨ My English accent is far from perfect, no doubt. Not sure it can be improved much (it’s too late probably), but just in case, every video has subtitles 🙌🏻
My problem with Swift and why I won't even try it is because it is basically only for MacOS. Kind of like how C# is only for Windows. Sure, you could run it on other platforms, but it isn't going to be as smooth most of the time.
Hard to argue with that. While there’s a number of GUI frameworks plus fairly simple integration with C-which make Swift pretty similar to something like Rust-the lack of proper support in IDEs makes working with it far from smooth. Basically your best option is VS Code, but the Swift plugin is very rudimentary.
@@oglothenerd constructive criticism is good, swift needs to get up to par with other modern languages in terms of cross compatibility and dx. however, three things i want to add: 1. it's ironic to complain about dx on non-native platforms when you blatantly refuse to use the tools that currently offers the best dx, and not to say the swift extension for vscode is officially developed and maintained by SSWG (Apple). 2. c# is in no way "only for windows" and haven't been for years, it's not even remotely close to swift in that regard. 3. sourcekit-lsp is open source and available for neovim if you really want to.
@@oglothenerd idk what part of that point made you think this is about operating systems, if you read the last sentence the "vscode" should be a clue that i'm commenting on your "I ain't touchin' VSCode with a 10 ft pole" comment. you're a dev and if the work you do requires you to use a tool whether you hate or love it you use it.
Thank you! Perhaps my main advice is to try different formats (textbooks, RU-vid 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.
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.
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.
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.
I have watched a couple videos from your channel now. You have excellent content and the refinement of the video editing is really good for RU-vid. Just an amazing channel. Thank you!
0:59 "Lets talk about whats wrong with bash" ....*held my breath with antici-*.... "To be fair to it, nothings really wrong" ...*-pation**dramatic exhale*....
For anyone who does find they are required to use (or debug) scripts written in 'bash' or plain 'sh', then look up a util called "Shellcheck". It can be very helpful.
Excellent video, bro! I just have a question: With macros, is it possible to attach additional event handler to a button? For instance, can you add an extra tapGesture() for each button in the view? I'm considering adding analytics code automatically to every button in a SwiftUI view.
Thanks! What you want isn’t gonna be very easy because of two things. First, macros can’t change the existing code, so it’s not like you can swap the button’s action closure for the original action _plus your analytics code._ I thought of suggesting the good old property wrappers (which _can_ replace the original expressions), but then the second thing comes into play: SwiftUI buttons don’t expose their action closures. If this was a real task, not just an engineering exercise, I’d consider the least invasive approach: extending SwiftUI’s Button with an initializer which returns a normal Button, only with its handler updated to send the event. With something like init(_:event:action:), all you have to do is literally stick the event name in between the title and action.
Thanks! 🙌🏻 Actually, I often use the very same Medium posts for my research, adding just a couple things on top. I do some extra fact-checking (and even after that I don’t expect anyone to just trust my word, hence the links in the description). I try to present the data in a more visual format (although I still don’t have enough time to implement _all_ of my ideas). And then, I wrap everything in a cohesive narrative. The last part is probably the most important ingredient because (for me, at least) seeing the connections and big picture makes understanding stuff much easier (e.g. weak refs have certain properties for which the side table is needed, and the way the side table works calls for certain object-lifecycle steps). Like, everything affects everything, and I’m trying to untangle those connections 😄
We have had tons of build system crashes on Xcode 15.3. We had to downgrade back to 15.2. Also strict concurrency checking has yielded hundreds of errors and thousands of warnings. Not even sure how we’re going to do the swift 6 migration in our codebase. Apple seems to have blindly slapped @MainActor on every single UIkit construct. Regardless if it’s a simple struct that should be sendable, or a class with mutable state.
Crashes of the build system itself? 🤔 Personally, one (big) issue I noticed after all the releases (and the video) is, Apple seems to have tweaked some checks on the App Store back end. I used to build my app with beta and RC versions of Xcode for the past few months, and they worked just fine in TestFlight. But a couple weeks ago, when I uploaded a fresh build created in the same environment, with very few changes in the project, that build was “processing” in ASC for, like, 12 hours-and then failed to deploy. Apple even reached out to me and showed some errors I’d never seen before: apparently, at least one Firebase component was “not a proper framework bundle.” I wouldn’t be surprised if that was the first time they saw this themselves. The funny thing is, I tried rebuilding and redeploying a commit that succeeded before, and got the same problem with infinite processing. Speaking of concurrency, I also noticed quite a few changes in the strict mode, but that project was small enough for me to fix them (except now I can’t go back to 15.2). So yeah, Xcode 15.3 does have its fair share of problems, after all 😵💫
@swiftbird so would you recommend downgrading to 15.2 then going back to 15.3 once they have addressed the bugs. Even when I start a new project the default “Hello World!” View will not preview or simulate
I think it could be something different in your case 🤔 Most of the issues I had were caused by third-party frameworks (e.g. Firebase) or App Store checks-neither are part of Xcode itself. Missing previews in SwiftUI happen from time to time, except they’re not really missing-it’s just the preview pane (“canvas”) decided to not show for some reason (but it can be re-enabled in editor options).
I guess KMM’s come a long way in the couple years I didn’t touch it! What do you think of debugging when it comes to the Swift / Kotlin joint? Back in 2021 everything felt very fragile, which only added to the confusion 😵💫
- Smaller: Yes, because everyone downloads Xcode mostly to develop for macOS, so just remove the iOS SDK from Xcode and advertise it as an improvement. - New super fast linker: Wonderful. With the new linker you can now use "-Wl -ld_classic" flags to build using the old linker because not every C/C++ library out there is supported by the new one. - Because every developer has an internet connection, Apple now disables the option to debug via cable without the internet. The new linker is blazing fast, so the new over-wifi debugger will make your experience more balanced, by making it terribly slow. - Swift & Swift UI: Really? You care for this fucking ugly language that changes in every release and forces developers to modify their huge codebase in order to build? Apple, if you're reading this you're treating your developers like shit.
Thank you! 🥹 I guess I’ll add a C++ interop section in an episode on using Swift outside Apple platforms. TBH, I’m hesitant to do a separate video about C++ because I wouldn’t call myself an expert here.
Why does an object still remain in memory when in deinited state? From my understanding ARC proxies all the access operations and the only thing it has to deal with to raise exceptions (unowned) or return nil (weak) is a side table.
Hi! While the side table keeps track of the all three counts, it acts as a proxy _only_ for weak references. Unowned refs point directly to the object, not the side table. So as long as you have unowned references, you also need to have _something_ at their memory address.
The background does make sense! It turns out being relaxing :) The only question that popped up in my mind is that some parts of implementation details of ARC remain uncovered. How does ARC runtime actually operate? What is the moment when it finally decides to free up the memory (when release turns counter into 0 or when a special moment comes out)? Likely, it's covered somehow in advanced video but I can't recall you mention it here whereas it's a useful chunk of info for tech interviews. I got asked about it many times throughout my career. All in all, a video is must. Reminds me Sean Allen workings in a good way. Thanks!
Thank you! You raised a good point! Though very rarely, I certainly did receive questions about this “when _exactly_ is memory deallocated (immediately, on the next run-loop iteration, etc.)” thing. But TBH, I hate those nitpicky questions designed to trip you, because job interviews are not theory exams. While I can answer many questions like this, in response I normally ask when was the last time this info helped with a real task. And then I’m shamelessly relishing the look on their face and dead silence 🥲 On this channel, I’m trying to paint the coherent picture one can easily wrap their head around, not make a cheat sheet one has to simply remember 🙌🏻 Your point doesn’t become any less valid, though. I decided to omit this aspect from the _memory-management_ episodes because for something needed as rarely, I didn’t want to introduce the whole concept of the run loop. But I’ll definitely cover this aspect in the run-loop episode!
