Drafts and backward compatibility with OS versions

1

This is a request for comment, more than a policy statement at this time, but I want to get some thoughts out there about Drafts and OS compatibility moving forward.

Every year, Apple comes out with new releases of all its OSes (which have become too numerous to list individually :grin:).

Every year these new OSes enable new features and abilities through new APIs. Drafts has a history of being on the cutting edge of adoption of those new features and abilities, and I plan to continue in that direction.

Every year these new OSes also deprecate some APIs, fix bugs from previous releases, or simply change some behaviors in ways that are incompatible with previous releases.

These changes pose challenges to developers of how best to balance adoption of these new features with the needs of their existing user base, who may or may not be ready, willing or able to jump on the latest OS release as soon as itā€™s out.

From the developer perspective, continued support of older OSes is not free. It creates a significant burden to the app. In many cases logic and user interfaces need to be branched to make features available only where appropriate, workaround old bugs that have been fixed in newer versions, etc. It adds significant testing and quality control workloads.

I want to be as transparent as possible about how Drafts is likely to handle OS updates and compatibility so as to not catch people off-guard, so I thought I should publish a policy. Policy may be too strong a word, but at least a guideline on what to expect each year. So, Iā€™m posting the below for comment.

I will likely update this based on feedback, but my current thoughts are as follows:

On each platform on which Drafts is available, it is our goal to fully support the current version of the platformā€™s operating system, while maintaining compatibility with the most recent updates to the prior major version of the platformā€™s operating system.

I donā€™t particularly like this wording, but hopefully it gets the idea across. So, that means that as I am writing this, Drafts supports:

  • iOS 12.x and 11.4
  • watchOS 5.x and 4.3
  • macOS 10.14.x and 10.13.6

When the updates to the OS are released in the Fall, Drafts support will bump those specs up a major version on each platform.

I feel like this provides the best balance to keep the app moving forward without burdening it with too much legacy to support.

As I said, Iā€™m open to comments, positive or negative. And, even if I publish a final ā€œpolicyā€ it will be more of an expectation setter. Some years the updates to OSes do not make significant changes that make it compelling to drop support for older OSes as quickly - some years not so much.

3 Likes
2

That seems very reasonable and understandable.

Iā€™m one of those people that will try to keep a phone a long time (3 years at the moment and Iā€™d like to get 4 or more if possible) and increasingly it seems (at the moment at least) that Apple is making itā€™s latest O/S available on older devices for longer - which is great. Mine is an iPhone SE and Iā€™m pleased to know that Iā€™ve at least 1 more year on the latest version. Which, I guess, gives me confidence that Iā€™ll be able to use the latest version of Drafts for a couple of years more at least.

I donā€™t know nearly enough about these things but I can imagine that with sync now playing a bigger part in Drafts it may be hard to say butā€¦ being ā€˜left behindā€™ the latest version of an app is much easier to take/manage if one can carry on using the latest version that works.

I know itā€™s not an exact science, but for the sake of a question, would you expect the last matching pair of O/S and Drafts to be able to carry on functioning when itā€™s no longer possible to run a newer version?

[Iā€™m fully prepared for an answer of ĀÆ\_(惄)_/ĀÆ !!!]

3

I think that itā€™s reasonable to tailor this kind of policy to your expected user-base. Drafts is probably used by more ā€œpower usersā€ than your typical app, but that doesnā€™t mean that even a majority of your subscribers would put themselves in that category. Regardless, the self-labeled power users are also your most vocal supporters.

I think this policy strikes the right balance and fully support it!

2 Likes
4

Support the latest, thatā€™s enough!

5

I agree with your strategy, Greg. My hunch (you likely have the data to prove or disprove) is that the type of power user who uses Drafts is very, very likely to be on the current version of iOS. One generation back for backwards compatibility is sufficient. And, hesitating on new features to preserve further compatibility doesnā€™t make sense for your user base.

2 Likes
6

This seems very reasonable. Latest version must be supported, if any compromises must be made any losses must be on the legacy versions. Current latest OSes are supported on many legacy devices such as iPhone 7. If a user gets left behind is up to them to catch. Older device users should NOT hold the development of the app.

7

Without asking you to reveal too much, wondering if there is any way you can tell if your paid subscribers would be essentially fully covered by your policy model with regard to iOS versions?

Thatā€™s the community that probably makes the most sense to consider as ā€˜likely new subscribersā€™ should follow same pattern with regard to OS version (or so I would think).

I imagine there is a significant installed base of free users who donā€™t ever launch the app. I know I have numerous installed apps (many even paid) that I never use. I clean them up occasionally but not like I should ā€¦

8

I would leave it 6 months after a new OS release to drop support for an old one. So March 2020 to drop iOS 11, for example.

That gives people time over winter holidays / Thanksgiving / Xmas to acquire new phones or update existing ones.

9

This is fantastic. I agree. I also think supporting the beta version of an OS, to the extent that is possible, would also help us provide more feedback to you for each new OS that you have to deal with.

10

Itā€™s not possible to say you support a beta OS, and, frankly, itā€™s the job of the Beta OS to support its apps. Itā€™s not desirable to workaround bugs/changes in a beta OS, because those bugs should be reported to the platform vendor as regressions that need to be fixed before the GM release of the OS.

Itā€™s also not possible to distribute applications built for/on the beta OS.

11

I understand. I just meant that we are here for you if you need help testing things in order to report things to Apple. --Especially, if they arenā€™t listening to you during their beta periods.

Our users have test engineering backgrounds even though it is no longer their day jobs. And we all love Drafts!

1 Like