So I gambled…

I hoped Apple would do the right thing by developers who paid for access to the Developer Transition Kit (DTK) to get the first Apple Silicon Macs, but I was wrong and I lost.

UPDATE - 6 Feb 2020: Apple has responded to feedback from me and other disgruntled developers and so I didn’t lose as much as I thought. Apple is now giving US $500 credit, which is what developers in the US paid for the DTK, and they are extending the time limit to the end of the year. I am quite certain they will release a desktop M1 Mac before then, so I will get credit for most of the cost of the DTK (after exchange rate losses) and I will be able to use the credit towards a Mac that I want.

Thanks Apple for listening and reacting.

With the option to create apps using the SwiftUI App life cycle, we get a new way to set up menus in Mac apps. This post will explore some of the ways to do this as well as look at the default menu groups that Apple gives us.

SwiftUI gives us a completely new way to lay out out user interfaces, in a declarative and responsive way. Your data dictates what is displayed. But this leads to a new problem - how should the data models be constructed and how can they be passed around between the various views that make up your app?

In this post, I intend to discuss the possibilities with examples.

Update - January 2021: I think the information in this post is still all valid except for one change. When you are initializing an ObservableObject, you should use @StateObject instead of @ObservedObject. Your views can receive objects that are owned by other views as @ObservedObject or @EnvironmentObject but the owner of the data should always create the data object with @StateObject.

I have just released Crossfix and Crossfix Lite for iPhone. They are both the same anagram assistant solver for crosswords, particularly cryptic crosswords. The Lite version is free but limits you to three solves per day. The full version is unlimited with no ads, no recurring subscriptions and works with family sharing.

In December 2019, I wrote a series of articles about using SwiftUI to build a Mac app . At WWDC 2020, Apple announced macOS 11 Big Sur along with Xcode 12 and a heap of new features for SwiftUI, so I decided to try creating my test app again and seeing how much had changed.

Snapshot testing is a technique that has been very popular in the web development world and it seems like a great way to test SwiftUI user interfaces. I read about snapshot tests in a recent blog post and was intrigued, but I had some difficulty getting it to work, so when I finally succeeded, I decided to share my experiences in the hope that others will find them useful.

My current work in progress is an iPhone app designed to make it easier to solve crossword anagrams by emulating and improving upon an ability that was there when we used to do crosswords on paper, but is missing for digital crosswords.

But I cannot think of a clever name for the app, so please read the story and contact me with your name suggestions or if you would like to test the pre-release version of this app.

As developers, we are used to thinking of color as a numeric way to specify a particular tint. But in SwiftUI, Color - like almost everything else - is actually a View in its own right. This leads us to two very interesting questions: how do we use a view to specify a color and how can we use the fact that Color is View?

As a rule, I prefer to use fonts that come pre-installed with the system. That means that your interface is already familiar to users, you get dynamic font sizing and if Apple updates the fonts, you get the updates without doing anything.

But sometimes, you really need to use a different font in your apps, and as the process of getting a custom font to display in your app can be confusing and tedious, I thought I would go through the steps for both iOS and macOS apps.

I probably should have published this on a different day, but it is not a joke…. really.

Last year, I wrote a 3 part series of articles on using SwiftUI to build a Mac app. I would like to thank everyone who contacted me about this series. It was received very well and revealed that there is still a large amount of interest in programming for the Mac.

Some of the responses I got were pointing out different or better ways to do things, so I am going to list them here, adding to this post as I get new information. The relevant sections in the original posts will have links to the fixes suggested here, but I decided it was easier to list the changes in a separate post, rather than asking people to re-read the whole series looking for modifications.