App:QRecordr (development lifecycle)

This was the first application for an iPhone I wrote. It started as a simple idea, I wanted to understand the basics of writing an app (in Swift), going through the Apple publishing cycle, and see how things then appeared on the App Store. The overall goal was not to write a specific application, but to exercise the production lifecycle and see what was involved.

I needed something with value, and had general goals of keeping the use case simple while creating an app that took advantage of the various layout options of iPhones. Taking the recording idea, to be able to record and playback what was recorded, I then started learning swift, or at least enough to get the app working, mocking up recording and playback information. Some time spent looking up how to toggle icons, a lot of time looking up how to get volume working properly in the Application Programming Interface (API).

The first working iteration had one button (no other icons/imagery), strictly record on first press, then toggle to stop, which then made it a play button that could toggle between play and stop (but with surprisingly low volume, at first wasn’t sure it even recorded).

It felt like a single multifunction button, while working, was too minimalist, so a second button splitting recording and playback was added. This felt better, was able to rotate the layout, and overall had simple functionality that felt universal (I didn’t have to explain what the buttons or product did).

I got back to the volume problem. Having learned various details about Swift and the various Apple APIs since this time, I think there is a fundamental gap in their information. The documentation and functionality is fairly loose, meaning the API to control volume can have a wide and flexible range of values, but in practice only specific ranges actually have a positive effect. And the documentation and guides do not do a good job of resolving strange issues. It took a while to search for the right problem, but I was able to find others who encountered the same issue, and code suggestions to resolve the volume problem. On the one hand its great that it is hard to write code that outright fails, on the other hand had it failed I would have had a better understanding of acceptable values.

With a simple working app I then had to solve the icon and name problem (didn’t realize the name problem would likely be harder than you think).

The icon wasn’t easy, that is had to pick graphics software (ultimately going with Sketch), learn basics of using it, mock up some examples, learn about all the various image sizes icons are required to be, figure out export and finally have some reasonable icons.

Naming is a minefield. That is I had an original name ‘Quick Recorder’. Simple and straightforward. This is probably the most frustrating part of this process, as using Xcode to write your software requires a name right at the start, so you have an idea for your software (probably not full developed), but name comes first. Now you have a basic commitment, perhaps spend months (or more) developing the idea, and you are finally ready to publish. But you need to create your place holder in Apples App Store connect, and this is when that simple structure falls down. Name not available. Hmmm. Okay let’s see if variations are available. Name not available. Name not available. Sigh, just the internet domain names themselves, product names have been scooped up all over the place. I’ll add, its not just visible names. I’ve searched for names in the App Store itself, found nothing, submitted the name…. Name not available. And that is why the various apps so far have ‘clever’ names. Not because that’s exactly what I thought the name should be, but because that name was close to what I preferred, and was available. The second frustrating part is now I have to change information in the app.

Now that QRecordr is the name, Xcode structure and information has to change to conform to that name, so the original name I was forced to choose from the start comes back to changing and fixing various configuration information to work with the new name. It’s an odd part of the process, as to create your code easily requires a fully formed idea and to put a stake in the ground for that idea before you even write any code. I still do it the hard way, start with an application idea, some structured name, write it, then spend frustrating time finding a name that is available and reworking my code. Hey, at least the writing and developing flowed as it should.

Once I had resolved the name problem, I was able to push my first version to the store, and I’ll save part of this process for another post….

Leave a Reply

Discover more from PartWood

Subscribe now to keep reading and get access to the full archive.

Continue reading