Today I released the ninth update to SwiftoDo in about ten weeks. What is driving all these small (but good!) releases? Two main things:
- I want the app to get better
- I want to have fun
I want it to get better
SwiftoDo is a good app, but it is by no means perfect. There are a lot of things that can be improved. My development task list for the app is a mile long. For a long time, the most important items on that list were also the most difficult for me to implement. To be honest, some of those “most important” improvements feel like they are beyond my current capabilities as a developer—but that doesn’t mean that I can’t make improvements somewhere. The app can still get better.
Sometimes, small things can make the app a lot better. Based on many emails with customers, I have learned that, a lot of times, a simple-to-implement feature, rather than a broad reimagining of a portion of the app, will make a big difference to their enjoyment of the app and the productivity they gain from it. That’s why I have been working on “small” features, such as the full file editor, that merely build on what was already there, but end up making the app more powerful and flexible for users. That is also my rationale behind improving application performance, which has become a much higher priority for me this year. Better performance benefits everybody.
I also decided to release features and fixes regularly and frequently. Every week I ask myself, “How can you make the app better for your customers?” And, on another day each week, I ask myself, “Is my latest commit better than what my customers have?” Once I’m sure the new version is better than the last version, I release it.
I figure that adding small features and fixing small bugs eventually accumulates, and my good app can eventually become a great app.
I want to have fun
I’m working on SwiftoDo because it the app is useful to me and because it is fun.
Coding is fun for me, but certainly not every minute of it. Sometimes I have to fight with UIKit’s quirks or work around its bugs, which can take hours of frustrating work. Sometimes I fail to get a feature working without introducing a crash or breaking something else in the app. Sometimes things just don’t work, and it’s really hard to figure out why. Sometimes I’m stuck, and that’s no fun.
I have decided not to remain stuck for more than a day or two anymore. If something isn’t working, I table the work and move onto smaller, solvable problems for a while. This philosophy has led me to work on features that seem simple, useful, and fun to code, but maybe not as important as the larger, more difficult things that have been blocking my progress. That explains why I’ve been pushing forward on improvements to the task text editor, for example, rather than adding new data providers. As a side benefit, working on those smaller things sometimes clears a way, either in the codebase or in my mind, to tackle those larger, more important items.
So, what’s fun? Racking up win after win, week after week, by pushing a better version of my app out to my users. And knowing, every day, that no matter what is not in the app yet, what is in the app keeps getting better.
Version numbers
SwiftoDo’s version number, currently at 2.9.2, is heading into the weird-looking, double-digit-minor-version-number terrority. The next version I release will be 2.10.0.
As Apple suggests, I’m using a 3-number semantic version numbering system, with my own rules for what increments each component. Architectural changes to the app (such as a total rewrite) will bump the first number. Adding new user facing features will bump the second number. Fixing bugs or enhancing existing features, in minor ways, will bump the third number.
Because I am releasing so often now, and batching fewer new user-facing features together, the minor version number has been increasing rapidly. No one should care what the version number is, as long as it goes up. I don’t really care if it is, eventually, version 2.50.0. I does look a little funny to me, though.
What about the Mac version?
I have not been releasing updates to SwiftoDo Desktop recently. The main reason for that is that SwiftoDo Desktop is, basically, feature complete. Unfortunately, because it is coded in Objective C and relies on cell-based table views (mainly for the inline editing to work), it sits at a technological dead end. A total rewrite is in order.
I have prepared for this scenario. My todo.txt-related code is in a framework that can be ported over to the Mac easily. In fact, I have started and stopped a total rewrite of the Mac version a couple times now, but have never gotten that far into it. The things holding me back are:
- I have to update my knowledge of AppKit, which is the Mac’s UI framework.
- The desktop app uses a different filtering system, which is a little harder to use than the iOS version’s filtering system, but it is much more powerful. I don’t really want to kill it off.
- SwiftoDo on iOS could always use more work, and it represents 70% of my user base.
In June, Apple may announce a new framework that would allow me to port my iOS code to the Mac much more easily. If that happens, my ability to provide an updated Mac version would be greatly improved.