SwiftoDo Development Notes, September 2018

Files integration

In late August I released a version of SwiftoDo that added sync support for any cloud data provider, via integration with the Files app. I think that this integration can be improved in the future. For example, right now, you cannot create a todo.txt file in the Files app using SwiftoDo, and you cannot open an existing todo.txt from the Files app.

If I add those features, I may as well rewrite the app’s UI, so that you have to create or open a file upon SwiftoDo’s launch. I would also have to rewrite how preferences are stored, so users could define different preferences for different files they open.

Those changes would, I think, necessitate dropping the offline support features that currently exist—namely manual sync mode, and the failsafes in place for when automatic sync fails (typically due to network unavailability). I am actually not sure how other document-based apps on iOS handle things when network connectivity is lost or unavailable. I would assume they simply cannot work without a constant network connection, because they cannot access their file, but I am not sure.

I do know that a task list is not a typical document-based app, like a text editor. Users typically want it to be always available, rather than dependent on a constantly-available network connection. Because I would rather not remove offline features from my app, and because I currently have very little time for app development, I do not plan any big changes to the app related to Files integration in the near future. When they do happen, I would expect that the UI of the app would be changed pretty significantly.

iOS 12 Support for SwiftoDo

The current version of SwiftoDo runs on iOS 12 without incident. I have, however, compiled a new version of SwiftoDo on the iOS 12 SDK. It has no new features, but the SDK is newer, so it inherits upstream bug fixes from Apple, and I updated my codebase to Swift 4.2. I am dropping support for iOS 10.x, too, because iOS 12 will be released imminently, and it honestly makes no sense for anyone with an iOS device from the past four years or so not to upgrade to it (iOS 12 performance is that good). Because of the under-the-hood changes, and the dropped compatibility with iOS 10, I am bumping the version number to 3.0.0. (Don’t get too excited!)

macOS Mojave Support for SwiftoDo Desktop

I am running the MacOS Mojave beta, and have been testing out its new dark mode. I love dark mode, and it took me about two seconds to realize that dark mode support is not a nice-to-have—it is an absolute necessity. Therefore, have coded support for it in a new build of SwiftoDo Desktop. I will submit it to the App Store soon.

The next version of SwiftoDo Desktop will be compiled on the macOS 10.4 SDK, and will no longer support macOS versions lower than that. (If you are not going to upgrade to Mojave, you can continue to use the version of SwiftDo Desktop you are currently using, of course.)

Other than dark mode support, there are no new features. (Sorry!) Because of the under-the-hood changes, and the change in minimum system requirements, I am bumping the version number to 3.0.0, though. (Again, don’t get too excited, but be happy your app is being supported.)

The future of SwiftoDo Desktop

It is a weird coincidence that SwiftoDo and SwiftoDo Desktop will be on the same version number for a while, but it is only a coincidence. At present, they do not share any underlying code.

My long term plan is for SwiftoDo to resemble, and share tons of code with, the iPad version of SwiftoDo. The approach I would prefer to take would be to use the joint iOS/macOS framework that Apple said is coming next year. I will probably continue work on improving the iOS version’s codebase in preparation for eventual macOS support as well.

I am not sure if every user will want the iOS version on the desktop, but I know that I would. I have considered releasing the next-generation version, whenever it is ready, under a new name (SwiftoDo Desktop 2, maybe) and SKU, so owners of the current SwiftoDo Desktop could continue to use it until it no longer functions on macOS. I have not decided exactly what I will do just yet.

I do not expect that anyone outside Apple will learn anything about Apple’s new framework until WWDC 2019, which will be held in June. What I learn at that time will have significant impact on the direction in which I take SwiftoDo Desktop.

SwiftoDo Development Notes, July 2018

I took a break from SwiftoDo development to build a new app, Simple Call Blocker, which I posted about earlier this week. Building it was a fun diversion, and I learned a lot in the process, too. If you’re reading this, you’re probably wondering what’s up with SwiftoDo, however. I have been working on it this summer, too.

Since this spring, I have been promising everyone that I’m working on iOS 11+ Files app integration. This feature will let SwiftoDo open files from any cloud service provider that ties into the iOS 11+ Files app. That includes Dropbox, Box, NextCloud, OneDrive, Google Drive, and many others. Adding additional data providers to SwiftoDo has been a long time coming.

Some background on SwiftoDo data providers

I designed SwiftoDo data providers to be plugins that could be swapped out, which would allow me to support numerous cloud storage providers. I have had so much trouble getting the Dropbox data provider to be solid and stable, however, that I was loath to create more data providers. My thinking was that I was liable to cause more problems for my users (and myself!) than I would solve. Therefore, I concentrated on fixing up the Dropbox data provider code, which is now, after three or four rewrites, pretty solid.

(The Dropbox data provider code has always worked, but it had a rare but nasty crashing bug for some time, and some issues related to stability, ability to handle spotty network connections, and ability to handle, gracefully, Dropbox “rate limit exceeded” API responses.)

iOS 11’s Files app, which I did not anticipate being available when I first wrote SwiftoDo, obviates the need for additional “native” data providers. I just wasn’t sure if SwiftoDo would be able to tie into it.

Can Files integration be used for SwiftoDo?

I have been under the impression that integrating with the Files app would require a rewrite of major sections of the app, or would simply not work well due to sandboxing limitations. I thought this because all Files-based iOS apps that I have used follow Apple’s “Document-based app” template very closely: Think “Microsoft Word” rather than “Reminders” in terms of user interaction patterns. They open to a file browser, you open a document (typically a single document), work on the document, save it (automatically), and close the app. The life cycle of a document is fairly limited: after the app is killed, your file is closed and does not reopen on load. Most of these apps don’t work offline at all, unless you’re working with local-only files, because they can’t open your file.

In contrast, SwiftoDo works a lot differently. It manages your task list locally and syncs it to an external file. It lets you archive completed tasks to a second external file. It keeps the opening and choosing of files down to a minimum. Most users set up their todo.txt and archive files once and never touch those settings again. It lets you work offline (primarily in “manual sync mode”, but also when the network is unavailable) and sync your changes to the cloud on demand.

Integrating SwiftoDo with the Files app, without giving up anything, seemed like it might be a considerable challenge.

A “Files” data provider

To my surprise, implementing a “Files” data provider has not been as challenging as I thought it would be. Accessing documents via the iOS document picker and restoring them after the app is killed, via secure bookmarks, is actually pretty easy. It took me only a couple hours to set up a data provider that would upload and download to iCloud Drive and even Dropbox through the Files app.

That is not nearly enough to ship the feature, though. There are still some issues regarding stability and error handling that I have to work through.

Adding this feature also prompted me to display file names in Settings (rather than 2 screens deep in Settings) and atop the task list in the main view.

What is next?

After I finish the Files data provider work, and the new Xcode and iOS versions are officially released, I plan to build SwiftoDo on the iOS 12 SDK and drop iOS 10 support. I’ve been thinking of bumping the version number to 3.0 at that point, to mark the change in iOS compatibility.

I will also consider the future of Files integration in SwiftoDo. It temping for me to remove the entire “data provider” layer and just make SwiftoDo a normal iOS document-based app. That would be a big deal, and I would not make that change unless I understood fully what that would mean for users. I also have to consider how long I will continue to support the existing Dropbox data provider, as it will be somewhat redundant.

After that, I will have the opportunity to simplify the codebase quite a bit. It is tempting for me to rewrite some or all of the UI layer, to incorporate the new techniques I have learned since coding version 2, over a year ago. Any changes to the UI code will probably be related to new features or a minor redesign of the sorting/filtering interface that I have been thinking about.

Introducing: Simple Call Blocker

Recently I released a new iOS app: Simple Call Blocker.

It is a free utility that lets you block unwanted calls to your iPhone. Unlike most of the call blockers on iOS, it allows you to block whole ranges of numbers, such as your phone number’s extension, for free. You may also whitelist numbers, ranges of numbers, or all your contacts’ phone numbers, so that they will not be blocked by this app, even if they are in the blacklist.

The Simple Call Blocker website explains it in more detail.

Why did I write it?

I wanted to write a small, relatively simple app that would allow me to explore the following things:

  1. iOS application architecture: I have been reading books and articles on iOS application architecture, and decided to create a new app to practice new techniques, such as the use of coordinators for navigation rather than storyboard segues, that I have been learning.
  2. algorithms and operation queues: I started the app by writing some simple algorithms for creating sequential phone number ranges to load into an iOS CallKit directory extension. The last thing I wrote was a multi-threaded operation queue for processing blacklist and whitelist rules and refreshing the iOS call directory extension that actually blocks the phone numbers.
  3. Core Data: I avoided learning Core Data for years; that changed with this app.

Overall, the app was a lot of fun to write. It took me about a month in my after-hours “free time” to create. The overall process has made me a better iOS app developer. I’m excited to bring forward the skills and concepts I developed on this project to future work.

Why a call blocker app?

I started getting neighbor spam calls, so I downloaded nearly all the iOS call blocking apps I could find. There were fewer such apps than I thought there would be, all of them seemed amateurish in some way or another, and all of them (as of a month ago) required an in-app purchase or a subscription to block my neighborhood exchange. I wasn’t willing to pay for that feature in any of the apps that I tried, because all of those apps weren’t that good. Plus, blocking an exchange, or a continuous range of numbers, is pretty trivial, so I thought I could create an app that did that, and offer it for free to people.

So is this just a “practice” app?

No. It is well-written and works as well as iOS’s Call Directory extensions allow it to. It has a rough edge or two, though, in that it reloads its directory extension and reports success or errors back to the users, rather than trying to prevent the user from ever encountering an error from being reported by the directory extension loading process.

What that means is that you can ask Simple Call Blocker to block more numbers that iOS will allow—there is an undocumented limit—and the app has to wait for the CallKit Directory Extension’s load process to report success or failure before it can tell the user what is going on. I decided not to try to impose limits on how many numbers could be blacklisted, but instead allow the app to report the Directory Extension’s errors, if any, back to the user. I figure that the undocumented maximum number of blocked phone numbers probably is dependent on whatever hardware is in your phone, and probably is increasing in every new iPhone model.

The Simple Call Blocker directory extension is coded extremely conservatively, and it optimized for very low RAM and system usage. If iOS cannot load it, it is because the user put too many numbers in the blacklist, or because it is still loading numbers from a prior attempt.

Releasing the app for free, I think, makes it OK that it may not work exactly as users expect it to.

What is the future of this app?

I plan to support it through various iOS releases, but otherwise not improve it too much. After all, it is a free app.

I want to know more!

Go ahead and download the app in the iOS App Store (it’s free!), and check out the FAQ online.

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.