As a mobile app developer, I use many third-party libraries in my Android and iOS applications. Most of them are open source, but a few are closed source, commercial libraries (such as Flurry, a mobile app analytics SDK).

One of the problems that I’m running into, especially as I have plenty of apps that are now past the “active development” stage, is that these third party libraries don’t necessarily function well on the latest versions of the mobile operating systems. This usually doesn’t affect the shipped version of the apps - iOS in particular does a great job of simulating older operating systems, so that an app that was compiled for iOS 4 will run fine on an iOS 9 device, although the screen size won’t be the best for the newer iPhones. Android lets you specify which SDK version you are targeting, as well as the minimum SDK version you support - you can probably safely get away with supporting Android 4.0 and above for new projects, ignoring the older Android phones running on Android 2.3 (Gingerbread).

The catch comes when it’s time to update these apps - new content, a new visual style, even just an upgrade to support the latest screen sizes. Now a lot of the libraries that may have been ok in 2012 have started to show their age, in particular with iOS’s Adaptive Layout for responsive designs on iOS. Various quirks surface that need to be worked around, and a simple project to update something can take more time than is really needed.

What if you weren’t stressed about upgrading your apps? What if you’d just made updating the app’s libraries part of an ongoing process - some upgrades are necessary (security fixes, new operating system updates), and others weren’t? It’s not like it’s terribly hard to do with either CocoaPods on iOS or Gradle on Android - but out of sight, out of mind, until you get that hard deadline.

I’m building a service that takes your CocoaPods Podfiles, and your Android build.gradle files, and monitors all of this for you. I’m starting with CocoaPods first, as I think the need is greater there due to the way iOS breaks compatibility at the view layer, and then doing Gradle later. You’ll simply get an email any time a CocoaPod or Android library gets updated at the central repository, and you can decide when to upgrade. You can monitor the status of all of your projects on a dashboard to get a quick view of any technical debt that may have started to accumulate.

If you’re using continuous integration, you’ll be able to fire off a quick API call to the service to update your Podfile.lock or build.gradle to keep your project up to date.

Are you a mobile app developer who’s currently stuck in maintenance mode? Would you like to be on top of things, instead of constantly working from behind? Email me at jlinwood@gmail.com so that I can put you into the beta version of the application. I’m just as excited about this as you are!