My current love / hate with IOS and Xcode (Apple developer stuff)

Some time ago I wrote a rather neat little app for the iPhone & iPad (IOS) called GasRad. It’s a program that assists in blending SCUBA breathing gasses using pure oxygen and helium (nitrox or trimix or heliox). You input pressures and blends you have and what you desire, and it tells you how much O2 or He to add in additon to topping the tank up with a compressor. I wrote it to replace cranky spreadsheets I used to use, which replaced pencil and paper, calculator and formulae.

The app got to the stage where I actually released version 1.0 to the App store ($0.99 – a real deal).

After a while, I wanted to update the app as there was a small bug in it, plus I wanted to allow other gas blends (i.e. heliox) and generally improve it. It’s been over two years and counting, and it’s still not ready to release version 2.

Not that it’s all my fault. I was pretty much done May 2014. However, every time I went to release the app, Apple had come out with yet another version of IOS. And the new IOS changed the Apple (mandatory) programming environment Xcode, AND the new IOS introduced new features and requirements for Apps. As each new iPhone or iPad comes out, the list of necessary “things” an App requires grows. More icons, more Launch images, more screen shots for the store… It was a moving target that a small app developer busy with other stuff simply could not manage. Apple docs for this process are virtually nonexistent, and there’s no help from Apple – after all, they are dealing with big fish in the app store, not one-shot dudes like  me.

Then my iPhone 4 went obsolete. No  more IOS upgrades. Since Aug 2014, my iPhone compiles would not run on the phone. Launch and then crash. No message, just would not work. At least the iPad version would run…. until the latest IOS upgrade.

With some resignation to the inevitable, last weekend I decided to recompile the app and see it on one of the many virtual test devices. By accident I didn’t switch the “compile to” setting from my iPhone. Imagine my shock when the program not only compiled, but RAN. On my iPhone. 4!

I tried compiling for the iPad, but now I got some semi-gibberish error message. Fortunately I’ve learned over the years. Copy the error message and plug into google, then read the top 3 hits from StackOverflow. Sure enough, there were numerous people with the same error, and the usual hoard of well-meaning folk  with advice – usually bad or involving a dozen weird steps. However I saw one that simply said “add this line to your app delegate and it will work”. I did that and low and behold, the app now compiles and runs on the iPad without errors. Better yet, it runs on the iPhone too (still!).

Why it would not run for over a year is still a mystery, but I am glad that the latest IOS/Xcode versions do again work with my devices. I can’t say I’m happy with the niggling, fiddly little changes that Apple makes to their stuff that forces a perfectly working program to require code changes to compile and run.

I hate to say it, but Apple could learn a thing or two from Microsoft. I have programs I wrote in 1990 for Windows (3.1 at the time) that STILL RUN TODAY on Windows 7 (and 8, I’m told). I can still compile a simple windows program written in C in the 1990s with a new compiler (mingw) and it still compiles and runs. Sure, I have to spend a few days figuring out compiler options with the new compiler, but it’s not that hard.

So why does Apple keep breaking WORKING PROGRAMS when new verisons of IOS come out, and then require non-trivial code changes to get them to compile and run again?

Why does Apple HATE backwards compatibility?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.