tag:blog.human-friendly.com,2013:/posts Human Friendly 2017-02-19T17:48:56Z Human Friendly tag:blog.human-friendly.com,2013:Post/935900 2015-11-19T02:38:35Z 2015-11-19T02:38:35Z Generating Core Data Swift

The Xcode generated NSManagedObject subclasses are annoying me. While they generate as a pair of files where you can add things to the main class and the @NSManaged variables are generated in an extension in a separate file so that they can be be overwritten and replaced as the model is updated without affecting the file where you make your changes unfortunately there is a big deficiency from my point of view in that the model type information does not get fully carried through to the Swift objects.

Insufficiently Typed

There are two generation options, with "Use scalar properties for primitive data types" you get usefully typed integers, floats, doubles and bools but lose the expression to express optionals/nil values. This is presumably due to the limitations of the Objective-C based API. It also expresses date types as NSTimeIntervals (Doubles) rather than NSDates.  The other option will generate with objects so you will get NSDates but for number values and Booleans you will get NSNumbers which lose information about whether it is a floating point type, integer or boolean.

Other Issues

tag:blog.human-friendly.com,2013:Post/905183 2015-09-15T01:10:36Z 2016-04-13T02:08:18Z Swift 2 (Xcode 7 GM at least) Generic support for @objc protocols

Just had a response to a radar (thanks Apple Swift team) that you can now implement Objective C protocols with generic Swift classes. This means that you can make typesafe and composable classes to do much of the work for many UI objects without ugly wrapping code and indirection.

This example shows a really basic example and should work in a playground.

In production code I would not initialise the table view cells in the closure but would make the closure but would probably take either the table view as an argument and directly dequeue cells from it or would take the cell as the argument and only configure it in the closure. Still this approach allows much of the boiler plate and common code to be abstracted. The next level may use a similar approach to make each section and an array of such structures could be used to make the whole table (or collection) view.

There is still work for the Swift team to do as I don't think that you can implement the Objective C protocol in an extension to a generic yet. I can't think of a reason why it wouldn't be possible and I'm confident it is coming.

Update: It should work in a protocol. I'm not sure if I'm currently doing something wrong or if it is Swift compiler bug yet:

tag:blog.human-friendly.com,2013:Post/903161 2015-09-09T22:15:11Z 2015-09-10T00:21:09Z Swift Performance - iOSDevUK

I presented today at iOSDevUK in Aberystwyth with some more material on Swift Performance and how to profile Swift. Also on wrapping classes in value types. Unfortunately much of the presentation was a demo and there is no video but I'm posting the materials here and will try to make a follow up post covering some more of the details in the next week or two (no promises).

Slides (note that slides a terrible communication mechanism and caveats and subtleties in the talk may be lost):

tag:blog.human-friendly.com,2013:Post/881253 2015-07-15T00:48:02Z 2015-07-16T12:19:41Z Unexpected Assertion Behaviour - Radar 21826180

Apologies for the lack of posts, full time work and family time among other things have been keeping me from finishing off Swift performance stuff. The new Swift 2.0 features look really good but again I haven't got stuck in yet. This is a quick post about an issue concerning me since I noticed it when reading Erica Sadun's post about assertions. I actually thought it couldn't be correct when I first read it so unexpected was it but when I checked the documentation it matched exactly what Erica said.

Assertions and Unchecked Builds

I use assertions for things that shouldn't happen but sometimes might. For example corrupt or unprocessable network data where I write code to safely handle the case but I also want to know instantly and start debugging the issue (whether it is in the app or the server). If you do the same and have assertions which could happen then you must not build in -Ounchecked (or in Swift 2.0 with Disable Safety Checks enabled) otherwise in the event of assertions not being true you will be in undefined behaviour.

tag:blog.human-friendly.com,2013:Post/828549 2015-03-23T01:49:11Z 2016-05-15T22:48:37Z How Swift is Swift?

Slides, video and links related to my Swift Summit talk on Swift performance. Video should be available later is now available and it might be worth watching Airspeed's talk that preceded mine before watching it when it is available I'm also expecting a blog post from him shortly on his static vs. compile time talk which is also highly relevant to optimisation.

The key point in Swift is that as the compiler gets better there is no need to choose between nice code and fast code. With a little thought and knowledge it is usually possible to get close to the speed of lowish level C code with nice abstractions. Some may say that C++ is there already but I enjoy writing Swift code much more and C++ is hampered by it's C legacy and choices made many years ago (for good reasons) from becoming a truly nice language in my view (non-Nullable by default would be hard to retrofit for example).

There were also many other excellent talks at Swift Summit, and all were at least good. I'm looking forward to watching several again.

tag:blog.human-friendly.com,2013:Post/817093 2015-03-01T20:55:49Z 2015-03-30T12:02:30Z Simple Library Free JSON Parsing in Swift

Parsing JSON in Swift without adding libraries could be tricky and annoying at least until nil coalescing was added and optional chaining was upgraded late in the original betas but that really isn't the case at least since Swift 1.0 was final. There are clearly a wide range of JSON libraries for Swift ranging from SwiftyJSON which just tidies up extractions from deep in nested structures to Argo which will feel comfortable for those coming from Haskell and look clever but be hard to read for those not familiar with the syntax.

I want to show people that there is really nothing very tricky or ugly about parsing JSON data in Swift even without libraries to help.

This post was trigger by seeing Jameson Quave's new lightweight Luma library and the syntax in the project readme (at the time of writing) would work without a added library on the result of parsing with Cocoa's included NSJSONSerialization class. Please note that there is nothing wrong with the Luma library or anything I have seen written about it but I wanted to make clear how lightweight it is and how easy these things are to do without using a library at all.

I confirmed that the syntax was available in the Playground without using the library and there is no problem just using exactly the same syntax on the dictionary you get back from NSJSONSerialization as in the Luma example. The only difference in the presentation of printing the parsed structures.

tag:blog.human-friendly.com,2013:Post/814635 2015-02-24T03:38:49Z 2015-04-02T05:24:34Z Swift 1.2 Update (Xcode 6.3 beta 2) - Performance

Apple have shipped another major update (release notes - registered devs only) only two weeks after shipping the beta 1. There are major updates to Swift Playgrounds, additional syntax support for more flexible `if let`, added a zip function, various other tweaks and fixed a tonne of bugs. This is all on top of the major changes in 1.2 beta 1 that I discussed at Swift London.

Erica Sadun has already blogged about the Playgrounds and `if let` changes and I'm sure that there will be plenty more over the next week. I don't intend to go over that ground but instead discuss the performance changes in Swift 1.2 versions. [Update: I should also have mentioned Jamesson Quave's post that covers the new zip function.]

The performance jumps are very significant in Swift 1.2 and certainly in Beta 2 the steps necessary to optimise your code are significantly changed. This post will cover some information on the improvements and how to get the best out of the Swift compiler. In most cases I have encountered the performance is now very close to C/C++ code and may be faster at times.

Swift 1.2 beta 2 Big Performance News

High performance can be achieved in Xcode 6.3 beta 2 without making code changes to achieve the result that were required to get close previously. Specifically the performance gains of these changes seem to have been largely eliminated:

  1. `final` methods/properties which used to be massive (although I still recommend it where possible for design/safety reasons).
  2. unsafeMutableBuffer instead of array (at least in -Ounchecked builds)
  3. moving code into the same file to allow the compiler to inline (with -whole-module-optimizations build option new in Xcode 6.3 beta 2).

There also seems to have been a slight general performance gain (about 5% above beta 1 from my initial tests).

Is Swift Fast Yet?

Yes. I've always believed that the language had potential to be as fast or faster than C because of strict compile time type checking, immutability and a lack of pointer aliasing concerns. With the Xcode 6.3 betas that promise is being delivered on. I'm sure the work is continuing and there is more to come but it is already fast in most cases. My thanks to the Apple team for making a fast platform but you have just taken away my ability to look impressive by speeding up code significantly with a few simple changes - you bastards.

tag:blog.human-friendly.com,2013:Post/812783 2015-02-18T00:13:14Z 2015-02-18T14:33:33Z Swift 1.2 Presentation and Notes (Swift London 17th Feb)

This isn't a proper blog post but I wanted to share the slides and notes from my talk on Swift 1.2 tonight. I'll post a link when the video goes up.  The video is now available here.

One thing that I forgot to mention in the talk is late initialization of let variables. The example Swift 1.2 code does show it though.

Comments, questions and suggestions all welcome.

Slide Text and Notes

tag:blog.human-friendly.com,2013:Post/805490 2015-02-01T04:49:22Z 2015-08-22T01:53:27Z Overcoming Swift Resistance Explored

This post is a response to David Owens' Swift Resistance Explored post.

First I want to acknowledge that Swift Debug builds are hideously slow. This isn't news to me or anyone who has seen my talk on Swift optimisation. To be clear this is a problem which Apple have said that they are working on but I still don't think it is an absolute block on any real development because there are fairly simple workarounds.

If you want to see the code under discussion it is all in my repository here with a log of my development. The first commit is the Zipfile that David made available in his blog post, the rest is my testing and development of the Swift version.

These are my performance figures (for 100 runs so it isn't directly comparable to David's):




0.077 (1.8)

0.042 (1)


0.38 (9.1)

13.7939 (327)

tag:blog.human-friendly.com,2013:Post/805294 2015-01-31T01:32:42Z 2017-02-19T17:48:56Z The Importance of Being `final`

[UPDATE - Swift 1.2 from Xcode 6.3 Beta 2 brings performance benefits to non-final properties and methods making final unnecessary for performance from that time - see my initial reaction to Beta 2. I still recommend final where possible as it avoids need to consider effects of an object being subclassed and methods overwritten that change the behaviour.]

This post is intended to quantify, explain and show the performance hit that you take from not adding the word final to your classes (or their properties and methods). The post was triggered by a blog post complaining about Swift performance and showing some performance figures where Swift was significantly slower than Objective-C. In the optimised builds that gap could be closed just by adding a single final keyword. I'm grateful to David Owens for showing the code he was having trouble and giving me a base to demonstrate the difference final can make without it being me cherry picking any code of my choosing.

As with most performance issues this doesn't matter most of the time. Most code is waiting on user input, network responses or other slow things and it really doesn't matter that much if the code is being accessed a few times a second. However when you have got performance critical code and in particular that inner loop that is being executed hundreds of thousands of times a second it can make a huge difference.

What does final do

tag:blog.human-friendly.com,2013:Post/801559 2015-01-23T19:01:14Z 2015-02-03T03:07:00Z Beyond if let

I've given my Beyond if let talk based on my How I Handle Optionals blog post about handling optionals in Swift twice this week. I was probably a more dynamic speaker in the NSLondon talk but the content is pretty similar. I may have been a bit slower and more methodical at the Swift London one though. Let me know if anything isn't clear in either of them or if you have any tips or suggestions (speaking  or Swift).

Vimeo of talk at NSLondon. Questions from 13:30. [Updated to replace Livestream feed with this.]

tag:blog.human-friendly.com,2013:Post/790486 2015-01-02T23:53:46Z 2015-01-03T17:15:40Z You Really Don't Need Protected Members

When Swift's access controls were introduced I wrote about how they worked like C's with good use of internal and external headers. I've recently been asked about how to do access private properties when subclassing and thought it would be worth sharing the conversation.

If you are new to Swift's access controls I suggest you look at the previous post (same link as above) first as this is the refinement and conclusion (in my mind) of an issue that I an open question when I wrote that. If you are new to programming then this post is probably one to skip as it is more about comparing how things can be done in Swift that people are used to doing a certain way in Java than something meant as an introduction to the concepts.

I’ve a question in context of open/closed principle (Software entitles should be open for extension but closed for modification.), coming from Java, AS3 background highly influenced by the Design Patterns book by the Gang of Four, the way I see protected is so that work can be extended by other people. 

How can I fully extend a class in it’s entirety without access to it’s private members, surely I can override methods but that won’t be enough.

The only way I could think is to approach this by declaring everything public or have a getter setter for each but then I’m violating “Encapsulation” principle
The short version is I would design the system in such a way to avoid requiring any inheritance apart from the specifically designed to inherit from system classes (NSObject, UIView, UIViewController etc.).
tag:blog.human-friendly.com,2013:Post/785983 2014-12-20T18:34:51Z 2015-01-26T19:04:49Z How I Handle Optionals In Swift Updated to add using map over optionals section - 7th January 2015

Update (26th January 2015) See Beyond `if let` for video of me presentating of much of this content.

Dealing with optionals is unavoidable in any Swift program that interfaces with the Cocoa or CocoaTouch libraries. Realistically that is all of them with a very few limited exceptions. Handling them is often annoying a although I am very glad of the rigour that they enforce on me. In fact I like the rigour so much that I never use implicitly unwrapped optionals (variable declared with !) and I use force unwrapping only in very limited circumstances.

In almost all cases I use combinations of optional chaining and nil coalescing operators with `if let` used where they don't do the job. In this post I'm going to explain how and where I use the different options and give some examples.

Note that this is very much a "How I do it" post and not a "How you should do it" post. It is also what I do this week which may evolve further in future. I take a somewhat radical approach and others may prefer approaches that fail earlier rather keep running in error conditions to the choices I take which are intended to keep running in most circumstances. Do note that there are definitely cases where it is better to stop than continue in an error condition especially where there is risk of corrupting data, losing money or even more serious consequences. Please choose a domain appropriate response. My recent domain has been a consumer app handling network data and not complicated and corruptible user documents or financial or safety critical and the choices you make about operating in unexpected state are different in each one.
tag:blog.human-friendly.com,2013:Post/778479 2014-12-04T03:23:09Z 2015-01-20T22:26:30Z theAnswer = maybeAnswer !! "Or a good alternative"

AssertingNilCoalescing Operator !!

I believe that Swift needs one more operator to deal with optionals, in this post I present my concept to make dealing with them better and safer. It isn't a beginners introduction to optionals or Swift. There are plenty of good ones out there already.

infix operator !! { associativity right precedence 110 }
public func !!<A>(lhs:A?, rhs:@autoclosure()->A)->A {
    assert(lhs != nil)
    return lhs ?? rhs()

How this code works will be explained near the end of this post so don't feel you need to understand it now. It adds an additional operator !! to a Swift project for dealing with optionals. It is designed to retain the benefits of strong typing proving the validity of some aspects of the code while documenting the expectation that the left hand argument will not be nil and exposing (in debug builds only) if that belief about the code is wrong.

Unlike other operators it behaves differently in a debug build than a release build. In release builds it is exactly the same as the built in ?? nil coalescing operator return the argument on the left unless it is nil in which case the right hand argument will be returned.

tag:blog.human-friendly.com,2013:Post/759396 2014-10-23T22:58:27Z 2014-10-29T22:34:19Z 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).


tag:blog.human-friendly.com,2013:Post/756612 2014-10-21T19:12:57Z 2014-10-23T13:19:57Z 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.

tag:blog.human-friendly.com,2013:Post/756391 2014-10-16T21:34:20Z 2014-10-23T13:20:24Z 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:

tag:blog.human-friendly.com,2013:Post/748846 2014-09-30T13:10:35Z 2014-09-30T13:21:55Z 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.

tag:blog.human-friendly.com,2013:Post/744997 2014-09-22T10:59:02Z 2014-10-10T09:18:58Z eHow advise to use Base64 to "encrypt" credit card data ]]> tag:blog.human-friendly.com,2013:Post/742135 2014-09-15T22:47:56Z 2014-09-19T01:42:25Z London Swift Presentation - Swifter Swift

This is the Swifter Swift presentation I gave at the London Swift Meetup in Clapham today (15th September 2014). Apologies for the stock photos/standard template, I focussed on the content.

I also showed the optimisation levels as described in this blog post.

Things I Forgot To Mention

Use constants - declare with let unless avoidable, allows extra optimisation. Test before changing to mutable state within a function for performance reasons.

Currently the optimiser can do better within a particular file although this will be fixed at some point.

Github Repos

https://github.com/josephlord/GrayScott - Optimised version of Simon Gladwell's Cellular Automata project.

Async.legacy - My iOS7 / OS X 10.9 compatible fork.

Async - Original by Tobias Duemunk

tag:blog.human-friendly.com,2013:Post/735491 2014-09-02T17:09:10Z 2014-09-02T21:31:41Z Swift Optimisation - (#iOSDevUK Swift 300)

My demo completely failed (Mac locked up when connecting to the projector) so I couldn't show what I wanted. If you want to try the demos yourself these are the Github branches I was going show. All these are 70 pixel square calculations for consistent comparison the main master branch increases in later versions.

tag:blog.human-friendly.com,2013:Post/733568 2014-08-29T20:26:42Z 2014-08-29T22:17:51Z Async.legacy - Swift wrapper for Grand Central Dispatch (iOS7 and OS X 10.9 compatible)

While GCD is a fairly simple API enabling blocks to be dispatched asynchronously on different threads or on particular queues that doesn't mean that the API can't be cleaned up a little to make it really nice to use with Swift.

Tobias Due Monk released the Async library that does just that. I saw the announcement probably on iOSDevWeekly and I liked what I saw except there was one fatal issue for me in that the library required iOS 8 or OS X 10.10 and I haven't updated my devices yet let alone moved my target up to that version yet. I actually just left it and ignored it but having done the optimisation of the GrayScott code presented at the last Swift London meetup I felt comfortable enough with GCD that I could implement most of the fuctionality to work with iOS 7 (and OS X 10.9 Mavericks but just take that as read every time I mention iOS 7 in this article). The result was Async.Legacy

How to Use Async (or Async.legacy)

All you need to do is to drop in the Async.swift (or AsyncLegacy.swift if you are using iOS7) into your project and then you can call the methods. There is full API documentation in the Readme files and that are easily viewable on the Github pages but essentially what Async allows you to do is chain a series of Asyncronous calls rather than to nest them. The result looks like:

Instead of having to nest the calls like this:

tag:blog.human-friendly.com,2013:Post/733569 2014-08-29T16:43:06Z 2014-12-09T12:09:22Z From 41 frames per second to 1560 - Full app 38x speedup

Having spent a couple of evenings back porting Async to iOS 7 and OS X Mavericks (10.9) and releasing it as Async.legacy I've gone back to trying to squeeze some more performance out of the GrayScott Cellular Automata app that Simon Gladman presented at the last London Swift Meetup.

For me this was an interesting case to see how fast something that is almost entirely CPU and memory bound can be made and it gave me a chance to play. Not many things need optimising if well strutured but this was a case where it could clearly be relevant.

Simon's original code calculates about 10fps in debug mode and displays many of them. Built with optimisations it increases to about 41fps calculated but it very rarely updates the screen due to the timing mechanism he used rather than calling back to the main thread. All this was done on a 70 pixel square calculation.

Running the latest code on a 70 pixel square calculation it calculates between 1550 and 1600 frames most seconds for a speedup of about 40 times and it is displaying far more frames to the screen too (well assigning the images to the image property of the imageView, the screen framerate is far lower).

This post focusses on making the main solving work multi-threaded for performance and in the optimisation of the inner loop. At this point we are moving beyond the point where we are optimising by improving the style, purity and immutability of the code. Some of the changes (inlining simple functions) go directly against good style and should only be done in inner loops. The parallelisation of the main solver is also something which makes the code less clean and tidy as is the incorporation of the pixelData generation into the main loop.

tag:blog.human-friendly.com,2013:Post/730428 2014-08-21T12:44:11Z 2016-12-17T02:24:52Z Drawing Images From Pixel Data - In Swift

This can either be read as a follow up to my last post about improving a Cellular Automata demo created by Simon Gladman (aka FlexMonkey) and speeding it up or as a standalone post with simple example code for creating images (UIImage or CGImage) from raw pixel values.


I had reached the point where the rendering code was the bottleneck in the Gray Scott Cellular Automata app that I was optimising. The existing code was drawing a set of one point rectangles into a UIGraphicsImageContext

I could see in the profiler that the execution time was being dominated by the drawRect calls which didn't surprise me and I knew that there must be a better way to draw pixel data.

Solution - CGDataProvider and CGImageCreate

This is the core generally applicable function that anyone can use to create images quickly from pixel data.

tag:blog.human-friendly.com,2013:Post/729574 2014-08-20T00:37:34Z 2015-04-15T12:26:20Z 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.

tag:blog.human-friendly.com,2013:Post/727686 2014-08-15T02:42:14Z 2014-08-15T07:26:40Z Being Explicit about Types in Swift

I've just read Andrew Bancroft's post about being explicit about types in Swift which I largely agree with and is worth reading before the rest of this post which adds an extra reason to follow his advice.

Summary of Andrew's Post

Where the type of a declared variable is not immediately visible from the surrounding code such as when it is declared to equal the result of a function, possibly a function defined in another file, you should explicitly declare the type for human readability and understandability purposes even the the compiler is happy inferring the variable's type. I agree with this.

The Other Big Benefit

That post however misses an entire other benefit of the practice which is that you get the compiler to check for you that the type that will be assigned is he one that you expect. If the function you are calling gets changed you will get an error at the call site not where you first use the object of inferred type (if you are lucky - you may get no error at all if the object is used in locations where type is liberal such as string interpolation).

Consider Defining Your Variable as a Superclass or Protocol 

Now it may be possible to declare your variable to a superclass or protocol of the expected object's type and if so that should be done to give some flexibility while ensuring expectations are met. This also documents the flexibility of the type that you can accept. 

Drawback of Explicit Typing

The disadvantage of explicitly typing your object is that if you change what the function that sets it returns and it is still compatible you have to manually change the type (possibly in many places if it is a heavily used function). I think that is a price worth paying to encourage at least a cursory check of the use of the values and to ensure it is not just well typed (which the compiler can do) but also correct. 

tag:blog.human-friendly.com,2013:Post/726413 2014-08-12T17:39:24Z 2016-04-18T19:50:41Z 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.

tag:blog.human-friendly.com,2013:Post/717202 2014-07-22T21:19:25Z 2015-07-28T14:18:45Z Swift Access Controls are like C's (and that isn't necessarily a bad thing)

Apple introduced access controls to Swift with the release of Xcode 6 Beta 4 and accompanying documentation (revision history).. The approach they have taken contrasts strongly with that taken by languages like C++, C# and Java in that the controls do not limit access based on the class hierarchy but instead limit based on the file and module.

Even variables declared private can be accessed from other classes and functions that reside within the same file. This allows properties and functions to be declared private but still accessible to free functions and operators defined particularly to operate with that class. It avoids some of the complexity that has C++ having "friend" classes and functions.

tag:blog.human-friendly.com,2013:Post/714978 2014-07-17T11:03:52Z 2015-01-14T16:13:39Z 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.

    tag:blog.human-friendly.com,2013:Post/705554 2014-06-19T19:31:47Z 2014-07-17T11:28:48Z 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).