How are devs going to handle watchOS 1+2 and backward compatibility?

It seems reasonable to assume that it will not be possible to install watchOS 2 without also installing iOS 9. Based on that assumption I'm thinking about how I'm going to update my iOS and Watch apps. This dicsussion rambles a bit, sorry! It's difficult to concisely express my thoughts.


Xcode 7 offers to convert your watchOS 1 app into a watchOS 2 app. But if we do that, we're going to prevent our Watch apps working on watch OS 1 devices in our new version of the app.


There are lots of different combinations and I'm not sure what will happen in all cases. For example,

  • An existing user of your app running iOS 8.x downloads a new build of your app that only has watchOS 2. Would their watchOS 1 app be deleted?
  • An iOS 9 user still running watchOS 1 downloads your app.
  • An iOS 8.x user without a Watch wants to download your app.
  • The easy case - an iOS 9 and watchOS 2 user.

Perhaps it would not be possible for a user with iOS 8.x to download the latest version of an app that only contained a watch OS 2 app. But that seems an aggressive solution and would prevent the latest version of your app being downloaded by people without Watches.


Maybe there are two approaches that would work best:


  1. Go all in. Change your app to require iOS 9 and only include a watchOS 2 app. This prevents bug fix releases for iOS 8 users without Watches.
  2. Be conservative. Add a watchOS 2 app and keep the watch OS 1 app.


Is there a middle ground that would work? Remember, a small (unknown) fraction of iOS users have Watches, so we need to be careful not to optimise for the uncommon case.


I'm cautious about option 1, but maybe I shouldn't really worry about customers who don't upgrade their devices. All devices that support iOS 8 can also support iOS 9 so there's no technical reason for them not to upgrade. Users with older devices are probably the least likely to upgrade (although iOS 9 may actually be better than 8 for them!) But do we care so much about users with old devices that we let it dictate our approach? They are an increasingly smaller part of our target audience. If you're Facebook you want to reach as many users as possible. If you want to earn money, you need to focus on people who are willing to pay. People clinging on to their 4-year-old iPhone 4S probably don't spend much money on apps.


Option 2 is arguably the safest and most customer-friendly but this complicates your Xcode project, perhaps considerably. It might be possible to include your Watch storyboards in both watchOS 1 and 2 targets. If not, or if you want to change the appearance you'll need to make copies. Depending on how much iOS to Watch data sharing/communication your app does, a lot of code changes will be required for watchOS 2. Supporting both watchOS 1 and 2 in the same iOS app might increase the complexity considerably. Is it worth it?


I'm interested in hearing your thoughts and what you are planning to do.

Current apps that require a minimum version simply don't update past the version that works with the iOS on the device.

I have a 3rd generation iPod touch and apps don't update unless a version that supports 5.1 is available.

It doesn't even report the app is updated, iTunes of course does see those.


That being said, it does seem to me that there is a boundry that isn't going to be simple to cross with an app being compatible with older and newer versions.


It might be that newer ones will have to be done with the new SDK, with users not on iOS 9 not being able to update to it.

and then I realize this is watch OS 1 and 2, not swift 1 and 2.


Still there do seem to be some elements that are very hard to handle when crossing the iOS 8-9 boundry.

I've been wondering the same things. I had hoped it would be possible to package the app with both a watch OS 1 and watch OS 2 extension. At the moment, I have only a few differences related to Core Data access, and I could set up my watch extension code to detect whether it's running in iOS 8 vs 9 to pick the appropriate code path. Unfortunately, that does not look like an option. Am I correct?


If watch os 1 and 2 code cannot coexist in the same app, I guess I must force this new release to be a minimum iOS version 9, right?

If that happens and then a user reports a watch app bug in iOS 8, would I be able to publish a patch to iOS 8 after the iOS 9 version is out? I didn't think that was possible.


Fortunately, I have not gotten a single bug report for the app I'm most concerned about, although I found and fixed a few things while upgrading Swift. So, maybe forcing minimum iOS 9 is the best option for me.


Mike

An iOS app can include both a watchOS 1 and watchOS 2 app. The phone will do the correct thing and install only one of the apps on the watch.

How are devs going to handle watchOS 1+2 and backward compatibility?
 
 
Q