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.


Core Location - Significant Location Updates Requires Background Permissions

If you've watched the WWDC video you will already know this but if you just look at the class references it isn't obvious that . iOS 8 introduced the possibility to request permission to access location only while the App is in the foreground which should encourage users to grant permission without fear of being tracked inappropriately however the foreground only mode only works with some of the modes. This slide from the talk (WWDC 2014 What's New In Core Location - Session 706) is the key one:

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.