When you create a Mac app, a lot of code is created for you without you having to do any work. Just creating the app and running it shows you how much functionality has been generated. Part of that includes a default about box, which is 'adequate' but not exactly helpful.
![Not A Blog](assets/images/steve/blog/blog.jpg)
Not a Blog
A place to save useful development notes.
One of the problems with developing something new for a new platform is knowing just what to do. As a long time Windows developer, I know what I want to achieve, but don't know how to achieve it. It's very frustrating.
I started out fixing this with a Mac app template project, which proved very instructional but didn't really reflect a real world application. So I created a second in Mac application, based on a more realistic app. Doing this gave more insight into what it was that I didn't know.
My first app is now at a stage where I have built a working application with the majority of the functionality it needs to operate. Along the way, I had many challenges to overcome. Some relatively simple and some rather complex. This section is intended to document some of these challenges and the solutions I came up with.
Along the way, I may well come up with other stuff that I need to document be it Macos, iOS or anything else. I'll add those in as and when.
Very few applications don’t have some kind of user settings. Little tweaks that make the application more customisable by the user. They are what makes an application more flexible and, by implication, more likely to be adopted by a wider audience. When you create a blank MacOS project, you will see that there is no settings menu item provided by default. While the templates give you a lot, we're on our own when it comes to settings. Not too unreasonable as the template designers couldn't be expected to know what settings you require.
Printing on the Mac from a SwiftUI application seems to be a bit of a black art and the secrets of how to do it seem to be closely guarded by those 'in the know'. You can spend a significant amount of your life searching the web for information and getting little more than snippets.
By default, when you create a Mac application, it is endowed with certain characteristics. One of those is that your application will remain active even when you close all the open windows. The justification is that you may want to create a new window or open an existing data source, so you need a way to do that once all windows have been closed. However, depending on how your application is intended to work, this can equally be frustrating for users who, when closing the last window, may expect the application to close too.
SwiftUI provides us with a lot of functionality and, as a rule, it provides most of what we need. However, there are some things it does not give us access to and, when we need to venture into this territory, it can be useful to be able to access the underlying NSWindow in which our view is running. SwiftUI does not give us a way to do that.
Testimonials
Am I really any good?
Don't take my word for my abilities, take a look at other peoples opinions about me.