Category Archives: Coding

SwiftoDo Development Notes, April 2018

Weekly updates to SwiftoDo came to an end in early April, but work on SwiftoDo has continued apace.

What’s next?

I am working on an update, version 2.12.0, that includes a couple minor, but long-requested features: (1) a setting to preserve priority on completed tasks and (2) a default priority setting for new tasks. Implementing these features required lots of behind-the-scenes effort. Consequently, neither could be completed in less than a week.

I am currently working on improving the Dropbox code that (1) checks whether SwiftoDo is authorized to access Dropbox, and (2) reports this to the user in a clear and actionable way. This is necessary because Dropbox can de-authorize SwiftoDo for various reasons, including when I upgrade the Dropbox library I am using, which is exactly what the version I am working on does. When this happens, SwiftoDo will alert the user after an upload or a download fails. Based on user reports, however, this notification doesn’t always happen, which can lead to data loss if the user does not realize you are working offline.

Once I finish my work on the Dropbox-related code, I can release this version.

What’s after that?

After I complete version 2.12.0, I plan to focus my efforts on implementing iOS 11 Files integration. Everything else, other than fixing critical bugs, will be put on hold.

The basic mechanics of Files integration are not hard, but they are not really meant for a to-do app—especially one that manages two files. I am unsure if it would require uses to re-open their todo.txt and archive files periodically, after the app is killed, or every time you wish to archive, which may be annoying to users. I am not yet sure how it will affect archiving, manual sync mode, and whether offline access would be possible.

In a best-case scenario, Files integration will eventually allow me to get rid of the Dropbox-related code within SwiftoDo, and rely on Apple’s and Dropbox’s native integration.

In a worst-case scenario, I won’t be able to get Files integration working without giving up too many features or conveniences of the current app.

So, after version 2.12.0 is released, you may not hear from me for some time about development, but I will be hard at work nonetheless.

SwiftoDo Development Notes, March 2018

Today I released the ninth update to SwiftoDo in about ten weeks. What is driving all these small (but good!) releases? Two main things:

  1. I want the app to get better
  2. 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:

  1. I have to update my knowledge of AppKit, which is the Mac’s UI framework.
  2. 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.
  3. 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.

SwiftoDo Developer Notes, February 2018

SwiftoDo is a passion project for me. I love working on it, but, due to work and family obligations, I have very little time to do so. Consequently, I am way behind schedule in adopting features introduced in iOS 11. I also learned, the hard way, that lots of minor UI-related bugs popped up when I changed the app’s target iOS framework from 9.0 to 11.0. I have been slowly discovering and cleaning up those bugs, and adding minor features here and there, for the past two and a half months.

Release cadence

I have decided to release working code as soon as possible, rather than trying to batch features and bug fixes into larger releases. Therefore, I have been issuing new releases about once per week, the past few weeks. I will not be keeping up that release cadence, but I do want to reflect to my customers that the app is actively developed. More importantly, I want bugs to be fixed for all my users. I would much rather have a rock-solid, very simple app than an unstable one with lots of bells and whistles.


That said, I do want to keep adding bells and whistles. I am working on adding drag-and-drop support at this point, and plan to look into adding clickable URLs and Siri support. I have a long list of other ideas and concepts drafted, too.

I would like to add additional data providers, other than Dropbox, but I have little exposure to coding networking code, and the third party libraries I’ve looked at look like more trouble than they are worth. For some perspective, Dropbox’s SwiftyDropbox library, which powers file sync now, is a great library, but is also the source of most of the mysterious crashes on startup that a small number of people have reported. What is frustrating to me, as a developer, is that I can’t really fix those crashes, because I don’t fully understand what causes them, and the code is in a library. I don’t want to open my app up to more instability just to add a data provider. Also, I have been loath to support iOS 11’s Files app integration, up to this point, because I don’t see how the todo.txt “Archive” function, which moves completed tasks to another file, would be able to work with it.

Current focus

I have way more ideas for features and improvements than time to complete them. My focus in the near term will be on stability and satisfying user requests that seem like they would be useful for a majority of my users. Hopefully that is good enough for now. It’s amazing how much work my simple, text-based task list app has been!

SwiftoDo Development Notes, October 2017

As an iOS developer, my job is never done, even though my app, SwiftoDo, is internally simple and focused. There are always more features to add. There is competition in the App Store to worry about. There are third party libraries that deal with that break from time to time or have APIs change. Most of all, there is the regular drumbeat of regular iOS updates, which, frustratingly, can break standard UI controls and behaviors, and new hardware to support.

What I like about having my own iOS app is the act of creating something unique, something I actually use every day, and supporting other people who want to use it to. It is a lot of work, but it is also a lot of fun—except for migrating between Swift versions every year; that part I could do without, and hopefully the changes will be more minor as time goes on.

Right now I am trying to knock out several features that have been in development since this summer, and get it all done before Apple no longer supports builds from Xcode 8.3.3. I think, when I finally upgrade to Xcode 9 and do yet another Swift version upgrade of my code, I will drop support for iOS 9, and bump the minimum supported iOS version up to iOS 10.3, or maybe even iOS 11.0. I hate to do that, but support for the older SDK is probably causing me more trouble than it is worth at this point. Still, I don’t want to leave my iOS 9 users with an app that is broken or unstable in any way. That is why I have delayed dropping support so long now.