Swift Developments is a hand-curated newsletter containing a weekly selection of the best links, videos, tools and tutorials for people interested in designing and developing their own apps using Swift.
This week saw Apple announcing the dates for this years WWDC! It’s a pretty early announcement compared to last year, and brings the news that WWDC will be leaving San Francisco, it’s city of choice for the past few years, and will instead be returning to the McEnery Convention Centre in San Jose, historically a regular WWDC venue up until 2002. This years event is scheduled between 5th and 9th June and as last year, tickets will be distributed via random lottery. If you’re planning on attending, tickets will go on sale on Monday 27th March so get your credit card ready!
Putting the specifics of app design aside for one moment there are a range of good design principles that are applicable to all products that we design. This is the topic of this article from @badashov which provides an interesting look into some of the higher-level design principles employed by brands such as Apple, Facebook and Medium.
The use of swipe gestures has become a common theme for app designers wishing to fit more functionality into a limited mobile screen size. However if not used with care, there are some major draw-backs to adopting this design paradigm that might not be so obvious. @angielitv takes a look and provides some recommendations for how to use swipe gestures within your app designs.
For some reason I forgot to include this in last weeks issue despite it being on my list. Anyway, if you haven’t seen it already @JordanMorgan10 has put together an epic article listing every single keyword in the Swift 3.0.1 language along with examples of how to use each of them. It’s a great reference.
An interesting article from @kharrison look at Swift’s
Hashable protocol. The protocol
Hashable protocol itself is the simple part, it’s the approach to hashing complex data types in order to avoid hash collisions that provides the challenge.
Memory ownership is a common topic on the Swift Evolution mailing lists and many of the core members including @clattner_llvm have previously hinted at a change, or at least enhancements to, Swift’s memory model some time in the future. This week has seen the first steps down this path with John McCall posting a new Memory Ownership Manifesto outlining the plans for memory ownership in Swift. There’s also a TLDR; courtesy of gankro if you just want the highlights.
Swift 4 Release Process
It’s actually been a pretty busy week on the Swift Evolution front. In an announcement on the Swift Evolution mailing list @tkremenek has outlined the plan for Swift 4 including goals, release process and timescales. The big news here is the official deferring of ABI stability, something that for the most part won’t effect you unless your shipping pre-built binaries.
The primary focus for Swift 4 will pivot around source stability for Swift 3, with the stated aim that most Swift 3.1 will code continue to compile. However for those living on the bleeding edge, there will be a number of compiler additions to support the transition to Swift 4. My only hope is the transition is going to be a little smoother than the transition from Swift 2.2 to 3.
The balance of progress vs stability in a rapidly developing language is a difficult one. Don’t get me wrong – I love working with Swift but I also recognise that the constant flux that we experience as the language grows can, and does, lead to significant amounts of rework, a steep learning curve for those new to the language and a serious amount of frustration. This is a sentiment echoed by @chockenberry.
I obviously mention Swift a lot on this newsletter but with Swift growing in popularity and many of Apple’s libraries still written in Objective-C, is moving forwards with two languages a sustainable strategy for Apple in the long-term? In this article, @lapcatsoftware peers into his crystal ball and muses over what the future may bring.
In this article @fmo_91 provides some advice on better ways to structure your Swift networking code, breaking apart each element of the request, dispatch, response pipeline into different components to facilitate testing. It’s an interesting read.
With the introduction of
UIViewPropertyAnimator in iOS 10, a new range of animation possibilities were opened up. Dance from @sdrzn builds on these capabilities providing powerful and straightforward animation framework whilst remaining simple and easy to use.
Still not convinced about unit testing? @jaimzuber provides a practical, down-to earth talk about why you should unit test, how to get your apps covered by tests as well as answering some common questions such as how to test your view controllers, how to test your storyboard code and how to test Swift code in general without the support of mocking libraries and mocks that we were used to from Objective-C.
There’s a bit of testing theme to the videos this week with this video from @paulstringer in which he looks at acceptance testing and the FitNess framework, an acceptance testing framework that can be used to automate your acceptance tests without creating automated UI tests.
If you’re looking to get up the RxSwift learning curve, this talk from @icanzilb at dotSwift 2017 might be the one for you. In this talk Marin provides a gentle introduction to RxSwift starting out with some basics examples before moving on to some more hardcore topics.
Developing iOS 10 Apps with Swift
If you’re just starting out with iOS development this is a resource you should probably know about. Every year @Stanford publish their iOS app development course, lecture videos and course material and all. It’s all free and available on iTunes U. This year is no exception with the new iOS 10 development course now in session.
Whether it’s the transition from Objective-C to Swift or just a particularly gnarly piece of code that needs some love, refactoring is a part of daily life as a developer. However when it comes to refactoring there is always the question of when to do it, how to do it and when should you just throw it all out and start again. @cocoaphony provides some interesting thoughts.
Wanting to contribute to open source or start an open source project of your own? GitHub have published a number of guides to help you setup, run and maintain your open source project. A useful resource.