How do you anticipate breaking changes in iOS and Android updates?

Question

An application I'm working on was broken by an iOS non-retrocompatible update. It had a big impact on our client's business before we could fix it.

So I'm trying to find a way to anticipate breaking changes in iOS and Android updates. I've already found:

• Apple technical publications: https://developer.apple.com/library/content/navigation/
• Android behavior changes: https://developer.android.com/preview/behavior-changes.html

But it's a lot of reading and I want to make sure every developer in my company knows everything there is to know about breaking changes and that they learn about it as soon as the information is available.

• How do you do this kind of technical watch ?
• How do you go straight to the useful information ?
• Do you know any website or newsletter that might help ?

Thank you a lot for your help.

Answer 1

Update-breaking changes in iOS are rare. That having been said, a few observations:

• When there are breaking changes, it's usually in stuff about which Apple has given us ample warning. E.g.,

  • Apple has started to enforce long-standing counsel about making writing thread-safe code, making sure that certain tasks must happen on the main thread, etc.

  • Likewise, the shift from 32-bit to 64-bit code base was something that Apple warned us about years in advance.

• When Apple says something is "best practice", it's sometimes because they know that failure to do so can result in breaking changes at some future date (usually years down the line). E.g. Apple has advised autosizing masks well before new screen sizes came along. They were advising autolayout and size categories well before split screen multi-tasking was released. Etc.

  If they say something is "best practice", they're often trying to help you future-proof your product.

• Where possible, stay in the highest possible abstraction in your code. The lower level you implemented your code, the more likely it is to not gracefully handle changes you didn't anticipate. The higher-level the API is, the more likely Apple has taken care of ensuring a graceful transition.

• Avoid relying upon undocumented behavior. And definitely avoid anything in direct contravention to the existing docs. (I know it sounds crazy, but there are all sorts of situations where documentation warns you about not doing something even though you might discover empirically that you can get around it.)

  Bottom line, if you've empirically discovered some cute technique that isn't documented anywhere, that can easily break. If it's not formally outlined in the documentation, the more likely the behavior is to result in breaking changes.

• Watching the "What's New in ..." WWDC videos is a great way to not only discover what's new in every release, but there's often parenthetical remarks about "if you used to do x, consider doing y." Heed those warnings.

  I think the WWDC videos are must watch for everyone (esp the high-level "What's New" videos), but if that's too much for your team, divide them up among the team and then reconvene the group and have each person give a 5 minute précis on what's critical.

• Every time there is a new release, you should review the release notes, e.g. these should redirect you to the latest docs:

  • iOS: http://developer.apple.com/go/?id=ios-sdk-release-notes.

  • Xcode: http://developer.apple.com/go/?id=xcode-release-notes.
     

  The signal-to-noise ratio in these docs can be a bit low, but generally important stuff is covered in here.

• Listen to the compiler:

  • If API has been deprecated, the compiler will warn you. Deprecated API is at risk of being formally removed in future release. If you need deprecated API to support devices running older OS versions, then add run-time version checks, using the API most appropriate for that OS version.

  • Be wary about disabling compiler warnings. It's quite easy to disregard compiler warnings, or worse, silencing them. If there are any warnings that have been silenced, not only turn them back on, but treat them as errors.

Answer 2

A couple tips for Android development:

1. Monitor and address deprecation warnings in your build. This is generally a good practice, but especially important on Android. Deprecated methods are an indication that an API will be retired in a future version of the platform. Often this could be an indication that you will soon have to re-write a component in your application.
2. Make use of the Android support library. This will allow you to implement functionality requiring newer API levels on devices that are not yet at that level. This allows you to code to newer APIs thus helping to future-proof you app.

This is a far-from-complete list. For a much more in-depth overview of this topic see: https://developer.android.com/training/basics/supporting-devices/platforms.html