Swift Arrays are not Threadsafe

Swift arrays are not necessarily contiguous blocks of memory (although they may be in some cases so some code may work in some cases but not in others). Some operations may trigger them to be converted to a contiguous block of memory and I believe that is what can particularly cause issues when there is access from multiple threads.

[Update - This post is more popular than I expected (thanks Reddit). I've added some additional notes at the bottom. Also the previous post about optimisation is probably more interesting and valuable.]

Even the code as described here may not work (and I haven't tested at all) when there are multiple reads or writes that access the same elements of the array. All the code I used was either reading from a constant array (safe from multiple threads/queues) or writing into non-overlapping ranges with no reads occurring (only seems safe with the technique described here).

.withUnsafeMutableBufferPointer

Swift Optimisation Again - Slides from Swift London 21st October 2014

Update (23rd October 2014) - Now with video link HERE.

Swift optimisation presentation refined and developed further.

Please contact me if you want the source version and please let me know if you make use of it or find it useful.

Description of the demo from a previous event. Note that for Xcode 6.1 you will need to use the 0x, 1x, 2x and fullSpeedXC61 branches instead of the 0, 1, 2 and fullSpeed branches respectively. Likewise master currently has an Xcode 6.1 version although I will probably merge that to the real master shortly.


Bluetooth Low Energy in the Background - iOS8 Followup

I posted about the results of some experiments I had done using the iOS background modes for Bluetooth. At the time I hadn't updated any devices to iOS8 (and they would have been betas anyway). This is a quick update to confirm that there are no changes in these areas that I can see in iOS8.

If you do know of any iOS8 changes or workarounds to the issues described please let me know

Basic Findings (repeated from earlier article)

  1. Apps on BLE capable iOS devices can be woken from the background when a device with the correct UUID is detected even when they have been completely removed from memory due to other apps needing the memory.
  2. This background listening/advertising state is stopped if the app is deliberately closed by the user swiping it up from the task switcher.
  3. The background listening/advertising state is stopped if the device is switched off or runs out of battery. It isn't restarted until the App is run again. (I haven't actually retested running out of battery but am guessing it is the same as manually powering off I will try to test again when the battery on something is getting low)


Please see the previous article for discussion of the impact on on app design and some potential workarounds.

Optimising Swift With Functional Style - 50x Speed boost from changing 1 Keyword

At yesterday's Swift London Meetup Simon Gladman (aka @FlexMonkey) presented the Gray Scott cellular automata application he had been developing to explore threading in iOS using NSOperation. During the presentation there were a couple of things that were apparent and looked possible to improve on. Firstly Simon had used a timer to work around a difficulty that he had in calling back onto the main thread and secondly he found that he got better performance using an NSMutableArray than using Swift Arrays. When I got home I forked the repo and got to work. This post describes the changes I made. The bulk were made together in parallel before I even ran the code but I will break down the changes.

This post describes the significant changes that resulted in needing less code, being clearer (at least in my view) and actually speeding up some sections by about 18 times. This speedup is in particular array processing code and largely the result of changing from NSMutableArray to a Swift array of structs which should be accessed with much less indirection. This improvement wasn't a direct path and if you browse the branches in my fork of the Repo you can see some dead ends and some of the steps along the way. The changes I'm discussing in this post can be seen in the pull request.

iOS - Bluetooth Low Energy in the Background

The Apple documentation is I believe correct although in places it isn't as explicit as I would prefer. This short article aims to explain what you can and cannot do in the background and the behaviour you will see. This information is relevant for iOS 7. [Update: If iOS 8 is different I will try to revise this post at a later date.  iOS 8 behaviour appears the same in my initial testing and I couldn't find any significant changes documented and there was no CoreBluetooth talk at WWDC 14.] If you think anything is inaccurate please let me know I don't want to mislead anyone and my testing hasn't been extensive.

Not Quite Enough for Peer to Peer Applications

My summary of the situation is that you can't do quite enough to support peer to peer in a viable way unless you have an app that you expect to be run on a regular basis anyway because the background modes (except for iBeacon detection) do not persist through a reboot of the phone or a flat battery. This means that the user will fall off your peer to peer application framework.

iBeacons can awake apps that have not been running since a reboot but iOS devices can only themselves perform as iBeacons in the foreground.

Swift Arrays - Beta 3 (Hooray!)

I should probably have written this sooner as it has been 10 days since Beta 3 was released, but I've only just noticed that there is a bit of traffic still coming in about Swift Arrays from my earlier posts about the array semantics in the first Swift betas. The short version is that I'm very happy with the new Swift Arrays in Beta 3 which have full value semantics (optimised with copy on write under the hood). The syntax for declaring arrays has also changed which is fine although I didn't have a particular problem with the old syntax. Be sure to update the Swift iBooks (delete and download again) as there are some significant changes.

The copy() and unshare() functions are gone because unshare has essentially become the default behaviour (although contents changes not just length changes now trigger the copy so copy is not needed either).

Semantic Changes

  1. Arrays are no longer reference types. You can treat every assignment, argument pass and function return as if it were a copy.
  2. Changing the contents of an array is no longer permitted when the array is declared constant with let.

In this example you can see the copy-on-write (CoW) behaviour using the identity operator (=== which I wouldn't recommend you doing in real code to affect behaviour on the CoW status but it enables us to observe the CoW). In the example it doesn't make any difference if a is declared with let or var but b must be declared as var otherwise you will get a compile time error because the contents change.

    Swift Arrays - Will be fixed in future betas - Reference semantics like dictionaries

    Just seen the announcement on the developer forum from Chris Lattner (link for registered developers and another).

    If you want to know about the array issues in Beta 1 see the threads above or my last two posts.

    I don't know and I don't really care if it was always the plan or is a result of feedback. I think this is very good news.

    I think that this means that it will be copy on write behaviour so that if you aren't changing the array you get pass by reference performance and only pay the call by value price when a mutation will occur. It may even be smart enough to know when the caller isn't going to access the array again and allow it to pass and mutate the original. We'll see in beta 3 (or maybe later).

    Swift Arrays - The Bugs, the Bad and the Ugly (and a best practice suggestion)

    UPDATE 2: I've added a new post about the changes in Beta 3 (I like them)

    UPDATE: Apple have indicated that the array behaviour in Swift is going to change - see this post

    My previous post suggests an explanation for why the behaviour of Swift Arrays is as it currently (in the very first Swift release) is as it is. In this post I intend to explain the behaviours, show the problems and give examples. Many examples are based on those found in this thread on the Apple Developer forums. Feel free to add comments if I've missed any categories and I'll incorporate them if they form a different case.

    The relevant part of the documentation covers most of the behaviour and apart from the issues specifically mentioned in the Bugs section at the bottom these are descriptions of the specification not just the implementation.

    Is it Value? Is it Reference? No its Confused!

    Hacking Constraints in Storyboard Files

    When Interface Builder doesn't do what you want Hack the Storyboard XML

    I like Autolayout and the concepts behind it. I also like using Interface Builder to see the relationships I'm creating but there isn't quite the right degree of flexibility and control (at least as of Xcode 5.1.1).  This post shows how you can convince Interface builder to do your will when it doesn't want to let you create quite the layout that you want you can directly edit the Storyboard XML to enable the effect that you want (and subsequently view it and tweak it in Interface Builder).