Apologies for the lack of code syntax highlighting. I have plans to migrate my whole blog at some point in the future but I needed to get this out of my head before that. 

I woke up this morning with several questions in my head and I couldn't find an existing blog post that answered one. If one does exist let me know I'd love to compare notes.

1. How does the SwiftUI Environment work?
2. Can it be used outside SwiftUI for more general dependency injection?
3. If not how similar can I make something to do the job?
4. Why do people keep telling me the Environment is unsafe and will crash if the object requested hasn't been added?

By early evening I think I had the answers. By night the blog was written and by the early hours the Swift Package was published.

[Update 17th Feb 2021 - Follow up post now available with information about the Swift Package status.]

[Update 20th Feb 2021 - Package 1.0.0 released.]

Spoiler 1 - I Know Property Wrappers

I now have enough understanding of property wrappers to understand much but not all of what the SwiftUI environment is doing.

I didn't know Property Wrappers before this morning, beyond the concept and use of existing ones. I'm now much more familiar with them including the future extension from the Evolution proposal that seems to be live in Swift and it seems is the basis for the @Environment and @Published property wrappers.

Spoiler 2 - No it can't be used for DI but...

Read more

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

Read more

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.

@jl_hfl You should be able to use an extension. What problem do you hit if you try?

— Joe Groff (@jckarter) September 15, 2015

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):

Read more

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.

Read more