- A Little Thing About Release Notes
- Principles of Mobile App Design
- Bridges of Siracusa County
- Using Swift Extensions the Wrong Way
- Compiling and interpolating C using the Swift Package Manager
- Using Xcode Schemes To Run a Subset of Your Tests
- Meeting People is Easy, But Hard
- Understand Monads with this One Weird Trick
- Practical Cross-Platform Swift
I was a little surprised when I saw this article during the week. According to @TheNextWeb it looks like Google are looking at potentially using Swift on Android as a solution to their on-going licensing battle with Oracle. I suspect that any migration will be some way off (due to the sheer volume of work involved) but it’ll be interesting to see how this plays out in the coming months. If it does happen though, it would be great news for many iOS developers as it would open up a whole new market for many iOS developers.
One of the major news events this week in the Mac development world has been the decision by Smile Software to switch their monetisation approach to away from a simple paid-up-front model toward a subscription model. As most of us know, software development takes time and effort and generally ain’t cheap, so as a developer, I can understand their desire to explore new avenues for revenue generation. For many though including me, the associated price hike may be too in the long-term, especially given the range of potential alternatives in the marketplace. @mjtsai has a good round up of exactly what’s been going on.
Written by @jennylg , Google’s UX Research lead, this series of articles work through 25 different principles of app design that together can contribute to a great mobile user experience. Topics include navigation, search, registration and form entry to name a few. Oh, and don’t worry – the principles she covers are as applicable to iOS development as they are to Android so it’s still worth reading.
In this article, @xenadu02 discusses his recent proposal for exposing Swift classes to be able to expose Objective-C friendly interfaces without the need to compromise the design of your Swift code (such as defining models as classes rather than structs). Above and beyond the proposal itself, the article itself also contains some great notices on developing the proposal itself. Worth reading if you’re thinking of contributing.
I really liked this article from @natashatherobot . It’s a reminder about just how useful Swift extensions are for improving the organisation and readability of your code by both hiding and grouping related sets of functionality.
As you’re app grows, so will the number of tests and so will the time it takes to run them. (You are writing unit tests aren’t you?) Anyway, this useful tip from @orta , shows you how to temporarily partition your test suite so that you can run just the tests in the area that you are working on.
After a long spell of hiding behind closed doors, recent months have seen me getting more involved with the Swift and iOS development community, (partly through this newsletter and partly through the articles I’ve been writing for the website). As a result, I’ve also been debating about whether to attend my first iOS conference this year (by going to iOSDevUK ). As with many engineers though, I personally edge toward the introverted end of the spectrum rather than the extrovert so the prospect of attending my first conference on my own is a little daunting. With this in mind then, this article from @yonomitt really resonated with me this week and provides some great tips that I’ll be keeping in mind should I attend.
I’ll be honest, my background is object-oriented development and so sometimes many of the concepts of functional programming can be a bit mind-bending. This video from @jqsilver helped though and has allowed me to solidify and reinforce some of my mental models.