Version | Date | Notes |
---|---|---|
1.0.0 | 3/24/02 |
Initial release |
1.0.4 | 4/1/02 |
Added capabilities |
2.0.0 | 1/3/15 |
Yosemite compatibility |
2.0.1 | 1/4/15 |
Minor bug fix, improvements to Help |
3.0.0 | 1/9/16 |
Major rewrite. The app is now coded in Swift. “The Challenge” and “The Solution” are now presented in separate windows rather than tabs within a single window. |
3.0.1 | 1/26/16 |
Fixed a minor bug which affected window positioning. The intent is to remember where the user positioned windows on the screen and reopen them in the same place. The bug caused the windows open slightly downward and to the right of the previous location. |
3.1.0 | 8/6/16 |
Fixed a bug which crashed the app on launch when running on older versions of MacOS. This was not a problem on 10.10 (El Capitan) or newer. |
3.2.0 | 11/27/19 |
Added support for the improved security in Mac OS 10.15 Catalina. The app has been submitted for checking by Apple’s “Notarization” service, which scans the app for any malicious code and issues a notarization certificate which is then attached to the app and also stored on Apple servers. Catalina’s “Gatekeeper” looks for this notarization certificate when installing and running the app, compares it against the stored certificate, and only approves the app for execution if everything checks out satisfactorily. This provides strong protection against malware problems. Fixed a Catalina specific issue when running the solution animation at maximum speed. Catalina is much more aggressive in optimizing drawing operations, which would normally be a significant advantage, but in this case the goal is to show all of the steps in the search for a solution, even though they proceed at blurring speed. I had to restructure the code to make sure drawing is completed for each step before proceeding to the next. I do not want the drawing for those intermediate steps to be optimized away. |
3.3.1 | 9/4/20 |
Prepares for the upcoming release of MacOS 11.0 Big Sur. Mostly this has been a matter of adjusting the layout of on-screen elements to accomodate the visual changes Big Sur is introducing. No issues of any great significance Also begins preparation for the upcoming Macs with Apple Silicon. I have started building the app as a “universal binary” — that is, including native code for both Intel and Apple Silicon. However, compatibility can not be confirmed until those new machines start shipping near the end of 2020. The app now checks periodically in the background for new releases. If a new version is available, it will display an alert window to inform you. Click the “Visit App Website” button in this window to open your web browser and go directly to the page where you can learn more about the new release and download it when you’re ready. If you prefer to wait, click the “Remind Me...” button instead. You can also perform the check manually by choosing the “Check for App Update” command in the application menu. When you do this, the app will tell you explicitly whether the version you’re running is up to date, a new version is available, or perhaps that you’re running a pre-release copy. Also in the application menu is a “Visit App Website” command. Choose this to visit the app website at any time. |
3.3.2 | 9/18/20 |
Minor layout adjustment for Big Sur, which uses a larger knob in slider controls. As a result, the speed slider in the Solution window did not fit in the rectangle allocated for it. |
3.3.3 |
11/19/20 |
The app has been rebuilt with the final release of Apple’s developer tools for Big Sur. The transition to Apple Silicon has gone incredibly smoothly. All of my apps are “Universal” — built to run natively on both Intel and Apple Silicon Macs. |
3.3.4 |
11/20/20 |
A small improvement to the Visit App Website command to better handle any changes to the URL for the target page. |
3.3.5 | 12/26/20 |
Fixed an bug in the check for app updates. In the case where this check failed because there was no internet connection, a re-try was being attempted a few seconds later rather than waiting 10 minutes as intended. This error had no visible effect, but caused the computer to perform unnecessary work in the background. |
3.3.6 | 11/29/21 |
Proactively applies changes to avoid a potential crash on Quit problem that has been seen in various apps from time to time. The problem is that quitting an app causes closing of all windows and teardown of all data structures, but this process requires multiple steps and can result in consequences such as notifications that are executed in an undefined (i.e. unpredictable) order. That has the potential to trigger updates to views in the middle of the process — using data that has already been partially torn down. The solution is to mark every view with a boolean value "isClosing" before starting the Quit operation, and then to suppress any updates if the view is so marked. Many views already had this protective logic, but I have made the effort now to make sure it is implemented in all views in all windows. |
3.3.7 | 4/5/23 |
Apple recently released a new version of Xcode with two changes that impact nearly all of my apps. The changes I'm making in response are not immediately essential, but I prefer to keep up with the latest from Apple. It pays off in the long run. 1. The original method for creating keyed archive files has been replaced with an approach that is more secure. The old method is now deprecated. I have in recent years replaced most of my keyed archive files with binary files of my own design. All of my document storage is now binary, but there are still a few keyed archive files remaining — mostly for things like saving user preferences and settings. I am systematically going through all of the apps and converting these keyed archives to property lists. This is an alternative way to store data structured as "dictionaries". Making this switch avoids the issues with keyed archives, but is also simpler and more compact, so it's a worthwhile improvement. 2. When running under the debugger, Apple now generates warning messages to the console regarding windows that are opened while the application is not active. I typically open one or more windows when the system tells my application that it has completed launching, but this occurs just before the app is first activated. So I am now moving my code to open the initial window(s) to this later point in the sequence. |
3.3.8 | 8/1/23 |
This version was built with Xcode 15.0 (beta) and the SDK for macOS 14.0 Sonoma. Building for and testing with Sonoma betas will help flush out any compatibility issues before that release goes out in the fall. I've already encountered and fixed some issues. |