Legend of the β€œOne Day” App, Days Four to Six

A graphical representation of how interesting Days 4-6 were…

Days 4 & 5 (11th & 12th February) were a weekend. I code/do different things on weekends to avoid coding fatigue on my main project. So, already, that’s the best part of a week gone on my “one day” app.

Monday, Day 6, then, was spent on more unpleasant things: tidying & documenting code, and finding energy enough to write some of the blurb I imagined I would need for submitting Sleep Well to the App Store. Yes, Day 6 was Procrastination Day.

I did run into one rather annoying coding headache: how to close a window properly. I have several windows, you see, and, at various times, I need to close them. You might imagine the best way to do this is with [window close]; …well, it isn’t. If you do that you’ll get crashes. Clearly, the solution is to use [window orderOut:nil]; Clearly!!

The problem I have with App Store submissions is that I know they are the single most draining part of the whole project. I need to feel rested and full of vim to even open up the developer website. So Monday would be ideal, no? Well, no. By now it was Monday afternoon and I was cranky from the time spent on tidying code, that Window-close “feature” and my rather-horrifically-moribund attempt at a description (which I still needed to “translate” into three more languages).

So, instead, I worked on one of my other “almost done” big projects and prayed for more energy to find me on Tuesday…

(spoiler: I would have that energy and, by Jingo, I’d need it…)

Advertisement

Legend of the “One Day” App, Part One

Is it possible to code a good, useful app – and something that’s not been done before – in just one day? Spoiler: yes, of course it is. But the coding is the easy part – getting the app to the point of release can take considerably longer.

So, in this new series of blogs (yes, I’m not dead yet) I’ll be talking through the pitfalls I faced just to release one very simple app. An app with a single button – and how many apps are that simple?!

Background

For the past too-long-to-admit, I have been working on several medium-to-large-sized apps. About three of them are “very-almost” ready for release. The last thing I needed to do was begin work on something new. But I felt I had to code it for the sake of my sanity and, once I did, I wondered whether I could also get it onto the App Store. A small appetizer before the feast to come.

So, here was the problem: my Mac had developed a nasty habit of waking up from sleep mode by itself. Mostly this happened a second or two after I pressed “Sleep”, other times it would wait till a particularly irritating moment (once it actually woke me up while I was asleep).

My options, as I saw them, were:

  1. use a screensaver instead (wastes power, keeps the monitors on);
  2. turn the Mac off (inconvenient to do for short periods of time; often I have tasks running in the background, and I also like to use a RAM-disk);
  3. code an app to put the Mac back to sleep automatically. πŸ™‚

Why do Macs sometimes wake up randomly? Well, my research points to a malfunctioning USB device being the usual suspect, but who knows? I don’t want to replace my devices if they are otherwise-working. So, option 3 it was.

App specifics: the app must send the computer to sleep, monitor it if it wakes up, and put it back to sleep unless told not to do so.

Goodnight, Sleep Tight, Don’t Let The App Title Bite You In The Backside

My first mistake (not realized till many days later) was in the naming of my app. I called it Sleep Tight. Why was that a problem? Well, someone else had already coded an app called Sleep Tight. So Apple wouldn’t let me submit my app with that name. I’d have saved myself the hassle of a lot of renaming if I’d registered the app title with Apple in the first instance.

Above are my (slightly-redacted) work-progress notes from 8th February which, as of writing this now, is a month and eight days ago. In fact, I started mid-afternoon, as a last minute addendum to my working day. That lunchtime my Mac had auto-woken several times, and enough was enough. I was done with the app a couple of hours later. So just how does a two-hour app balloon into a five-week app? I’ll start that explanation next time… πŸ˜‰

n.b. I do want to keep these blog posts brief (both for me to write and you to read), but if you want to skip to see screenies of my finished app you can visit the product support page for Sleep Well. And, if you’re interested in buying it, here’s a link to Apple’s app store page for Sleep Well. Cheers! πŸ™‚

Philip G, 16th March 2023

Back to Apping, Part II

When people find out (I try not to mention) that I’m a programmer, invariably they chirp in with, “Oh! I’ve got a great idea for an app! It’s a doozy!” And (unprompted) they go on to tell me how, for example,

  • it calculates sums of numbers (App already included with every phone), or
  • it makes amusing noises (Apps done to death), or
  • it uses the FBI facial-recognition database to spot disguised celebrities and/or escaped convicts in your local Lidl (App requires discreetly accessing the FBI facial-recognition database), or
  • it’s like Minecraft/Fortnite/GTA X but with way better graphics/gameplay.

And then they suggest I code that for them. “We can be partners!”

Well, “app ideas” was never the problem. I already have a list as long as my arm for app ideas. The problem is always Time. And lack thereof. Yesterday, I read through Apple’s app review guidelines, which is enough to make anyone’s eyes bleed. And that’s just reading it.

I need to introduce you to one of my laws. I call it “Philip’s First Law of Coding” because I’m Mr Vain. Here it is:

Coding will always take at least three times as long to do as you say it will, even (or especially) when you try to take into account Philip’s First Law of Coding.

Philip’s First Law of Coding, (c) PBG circa 2015

Star Trek’s Scotty knew just how long it would take to repair something, multiplied that time by a factor of four in his estimations and then everyone was mightily impressed when he managed it in a quarter of the time he said it would. Scotty’s a git! If I think something will take a month, I might decide to say that it’ll take three, and then it’ll actually take nine. Yes, it can be extraordinarily tricky to guesstimate how long even a simple project can take, especially when I am confined to two-to-three hours a day to work. There are all sorts of things which crop up:

  • unexpected and mysterious memory bugs that the debugger can’t handle;
  • new OSX/iOS/XCode (old code suddenly stops working, or works differently);
  • new code A requires recoding old code B, and then B affects C, D & E, which need adapting and testing, and then D dominoes into the rest of the Roman alphabet and threatens the Cyrillic;
  • hardware problems (failing hard disks is #1);
  • problems due to stupid initial decisions (mostly from severely underestimating complexities);
  • real-life emergencies, illnesses of all flavours, mood-swings and depressions, weather too hot or too cold, rain-patter too loud against the ceiling window, and so on.

This isn’t just a problem for coders. Please do take a moment to read up on the history of the upcoming Game of Thrones book, The Winds of Winter. In case you didn‘t just do that, here’s that link again. I did say please! I am pretty sure that Mr Martin is not a slacker and that he was being entirely honest with all of his completion estimations. Finishing even a simple project is tricky and takes times to do right. I know, because I’ve been spending many, many years writing my own software library, in order to code an app that will change the world.

More about that in Part III. πŸ™‚

Back to Apping (Was Napping), Part I

Portrait of a Coding Dinosaur

I’m a coding dinosaur. I grew up with writing databases in BASIC on the ZX Spectrum 48K. I’m so old, computing was an optional afternoon hobby at my secondary school. There were no laptops there, just a dozen big beige boxes in one room hidden away from all the others. Cutting edge tech was a VGA monitor and a greyscale scanner you had to roll over a picture at just the right snail speed for it to work. My mates & I were wowed by Windows 3.0 and spent our days wrangling with autoexec.bat and config.sys in order to free enough DOS memory to play Origin games. (No, new kids, not the same Origin you know).

So I stumbled into software engineering after university, doing my best to muck up their statistics by not landing my first job till a year after my 1st-class-honours Maths degree. I went to work in an international bank making graph software for Value Added Risk (which is as much as you would probably ever want to know about that).

Then, at the turn of the new millennium, I tried to ride the wave of the Dot Com revolution. I journeyed to America, helped make a website for buying/selling sports cards. It was called thePit and, amazingly enough, I see that it’s still going. But I learnt then that you can’t ride a wave that’s actually a bubble that had already burst.

After that I learnt C++ in order to code my first computer game. It was a vector-based space shooter called Surrounded! and it was awesome, but I can’t market and can’t afford marketing and consequently nobody ever really played it. Except me and a marvellous chap called Saturn.

What was the next “Big Thing”? Well, it was the iPhone so that seemed like a good opportunity for me to find a bigger audience with its built-in App Store. I enjoyed extremely modest success there. Looking back I joined a bit too late, the same as with the Dot Com thing. Matters were further muddied by my move to Germany and having to juggle my new family life, an impossible new language, six years of lost sleep and an idiopathic chronic illness. I can cobble together more silly excuses but the truth of it probably was that my apps simply weren’t good enough to pass serious muster. When the whole tax situation became too thorny (as my dev account fed my UK bank account for my UK company, but I was in Germany), I decided it was simpler to take my apps off the store.

(And I’m breaking up this story because you surely have better things to do than read articles which are too long. Another bite-sized piece of my story coming soon!)