So we got a pretty big surprise this week which I hadn’t seen coming.
In email to the Swift.org mailing list, @clattner_llvm announced that he will be handing over the “Project Lead” role for the Swift open source project to @tkremenek and will leaving Apple for pastures new later this month. In a second self-effacing follow-up email to the list, Chris explains some of his reasoning for the move whilst also explaining that he will remain involved in the Swift Evolution process going forwards but also reinforces what a great hands he has left the Swift project in – a sentiment I agree with.
As it turns out it appears that pastures new for Chris will be a role at Tesla where he will fill the position of Vice President of Autopilot Software – a role that no doubt will throw up it’s own unique and interesting challenges.
My personal view is that Chris has done a great job with Swift, both in it’s initial development and in it’s subsequent evolution and would like to take a moment to publicly thank him for both his hard work and for a great language that I love working with. I also want to wish him the best of luck in his new position. It’ll be really interesting to see what he can achieve!
If you’ve ever been wondering about striking out on your own, maybe making that leap from employee to an indie, you’ll no doubt realise that it is a big jump and one that is extremely difficult to make on your own. An easier approach can be to team up with someone else and in this article, @pietrorea walks through the different options for this approach and provides a bit of inspiration for you if you’re considering this move at some point in your own future.
As you know, keeping your app updated can be a major factor in both retaining your existing users and in attracting new ones. One approach to these updates is ‘little and often’ approach where you incrementally fix issues and add new features. However, even with this approach there will still come time where a major updated is needed. @kenyarmosh provides some hints and tips to help you identify exactly when that time should be.
Getting new users for your app can be a difficult task and ensuring that those users are quickly drawn into using your app is critical for their long-term retention. In this article, @101babich provides some best practices for this onboarding process that you should seriously consider incorporating into your own app designs.
Sticking with the theme of user engagement that this issue seems to be acquiring (I’d like to say that was planned but it wasn’t), we have this article from @samjarman. In it, Sam lays out some of the best strategies and practices for using push notifications within your apps and how you can use them to target that sweet spot between annoying your users and keeping them engaged.
Most of the time, the strong typing build into the core of Swift language can have major benefits, helping to catch mistakes and typos early in your development process. However, there are occasions when you may want to relax some of Swift’s type safety rules in order to gain some additional flexibility. In Swift, the concept of Type Erasure can help with this. @rc_edwards walks us through some examples.
It’s a common frustration with Swift enumerations – the inability to get a array containing all the cases of an enumeration. In this article, @tiborbodecs explores a couple of possible solutions to this problem before coming up with a more generic and supportable solution of his own.
“If you don’t abstract away different the styles of views you used in your application (font, background color, corner radius etc.), changing them can be a huge pain in the ass”.
When working with data from a server and displaying it in a UITableView, it’s relatively common to have to deal with the fact that no data may be returned. Above and beyond simply adding a fixed view to the UITableViewControllers view property, @azamsharp explains a nice little trick using view controller containment to add some flexibility to your code.
If you’re anything like me, at one time or other you’ll have managed to accidentally make UI changes on a thread other than the main one. It’s actually a relatively easy mistake with multi-threaded code if you’re not paying attention. This is where ODUIThreadGuard from @lingshenglyu comes in. By adding a single Swift file to your project you’ll get an assertion being thrown if you accidentally make UI updates in a thread other than the main one as well as a nice thread stack to help debug the issue. No more random crashes head scratching whilst trying to work out what’s wrong.
If you’ve reached the point where you’re optimising the performance of your application and you’re trying to assess the impact of certain parts of your application on frame-rate and CPU, GDPerformanceView from Daniil Gavrilov might be worth a look. GDPerformanceView can be added above the status bar and displays the current frame rate and CPU usage as well as the iOS and app versions directly within the app. Not recommended for production but a useful addition to help with the optimisation process.
I’m a big fan of SwiftLint and it is one of the first things I tend to add when setting up a new Xcode project. In this video, @simjp walks you through the steps along with how to tailor SwiftLint to give you the semantics that you need. I’d recommend watching it if you want to add some consistency and cleanliness to your Swift code.