It's been a while since I posted. I spent most of my fall developing a hiking app for iOS called Hikers Assistant. You can now find it on the iTunes app store. I didn't want to talk about it before I was able to get it posted on the app store. If you want to take a look at it, go to the iTunes app store and search for Hikers Assistant. You can also see my web site's description at www.sgb-services.com.
But since this is a Google hosted blog, I won't do any advertisement here for it.
I would like to spend a few moments though describing the process of developing, testing, and getting an app accepted for use on Apple mobile devices.
Before I left the Air Force, I had worked on rolling out Apple iPhones to replace the Blackberries we were using previously. As part of that effort, I developed a mobile training app for new AF users. I was traditionally a Windows guy, and before that I had never used an Apple device. But I bought a Mac Mini, paid for an Apple Developer's account ($99/yr), downloaded Apple's development environment, Xcode, and began coding. I had experience in C, C++ and FORTRAN, but had to learn Objective C for iOS apps. I helped run the AF enterprise app store for a while, so I also learned about the Apple Developer Enterprise accounts.
I also learned about mobile security, and the more I learned, the more I liked the Apple iOS approach over the security on my Android devices. I've now converted entirely to Apple; though I may try to expand my development capabilities to also support Android.
But back to developing my app. I wasn't very satisfied with the guides and apps I had available to me on the AT this last spring. I wanted an app that could do most of my on-trail tasks with minimum battery drain. And I wanted it to be efficient to keep my use of electronics to a minimum on the trail. So I put together a general view of what I wanted the app to do for me. I've still got a list of things to add to the app, that were just lower priority.
I had to learn an awful lot. Nearly everything I wanted to do was something I didn't know how to do. Google is great! If you search a few key words and add 'xcode' to the end, you almost always get assistance from a forum called stackoverflow.com. That site is fantastic. If you add the word 'tutorial' to your search, look for a site called www.raywenderlich.com. Their tutorials are consistently high quality. I would decide on a feature I wanted to add, search online to learn how to do it, use the Xcode documentation features, test the feature with my device plugged in, and then take it to the trail and test it. Then I would add another feature with the whole process repeated.
One thing I don't like is using the iOS device simulators Apple has added to their Xcode environment. They are great simulators, they just don't give the look and feel of a real device. It's easier and quicker to keep an iPhone and an iPad plugged into my Mac Mini and test every code change on a real device.
Testing a hiking app in the field is a real effort. First, I like hiking a lot. And I don't want to stop and play around with an iPhone if I don't have to. So I pretty much had to force myself to test my code in the field once I got there. The app is built around GPS for on-trail use, so to test out the tracking capability, I really had to hike with my code. And when it didn't work right, I had to debug at home, make changes, then take it out to the trail again. It's not a timely turn-around for debugging code. Luckily, coding has developed from the early years of FORTRAN. Xcode will not let you do a formatting error. Any error is almost always due to faulty logic, or sometimes failing to initialize a variable properly.
Another complexity to the code was that I wanted the app to run on both iPhones and iPads. And I didn't want the iPad version to look like a phone window. I wanted to be able to plan routes and waypoints on a large iPad, but take a small iPhone on the trail. Apple really pushes their Auto Layout capability. But it is complicated and never seems to work up to my expectations (probably due to deficiencies in my own understanding and skills). So I've developed my own approach to laying out subviews for each screen in the app. I think it takes a little more time to do the layout, but I know what's going to happen on screen on different devices.
Related to that point is trying to make the user interface look professional enough for a commercially available app. I had to continually tweak the interface, and the in-app navigation and layout, to make the app look good and to support a simple and effective user experience.
The app is more complicated than most mapping or hiking related apps I've seen. So the complexity drove a kind of uniformity on the various screens (different features) that hopefully let the user guess what each button does, even if they haven't used that specific screen/feature before.
I also found out that on trail, it is hard to see an iPhone's screen. Its worse for me than for some folks, because I cannot see up close well without reading glasses. And I hate to get out my reading glasses on the trail. I use rotating 'pickers' to navigate through the app, but I couldn't read the selected line in the picker. And Apple restricts the size of the pickers on the screen, so I couldn't make it big enough to see easily. I decided to add colors to picker entries that I would be using on trail. Most on trail features don't require typing, and when I do have to type a new 'quick waypoint's' name, I can use an abbreviation, and then expand it at a trail stop or at the end of the day.
So I got most of my features in, tested, and working properly. The next issue that arose was when enough features were enough to post the app on the store. There's always more you want to add. And you keep finding minor bugs even as you start preparing the app for posting--they never seem to all be gone!
So I finally bit the bullet, and put the app metadata up on iTunes Connect, Apple's site for submitting apps for its store. I had to create a seemingly unending set of screen shots to post, some for nearly every class of mobile devices. And crafting the app Description was kind of like writing a self-assessment for an annual review in the Air Force. You try to make it look good without going overboard.
Once you hit the Submit for Review button, you start wondering what they will find that you missed. My app was awaiting review for nearly 8 days. Then I got an email that said it was in review. A little later, I got an email that it was rejected. I had failed to add a line to the app Description that warned potential buyers that use of GPS in the background (while logging a track) would use a lot of battery. I do have in-app warnings in bright red, so folks won't use GPS features that drain the battery. I should say most use of GPS in the app is just getting your instantaneous position, then the GPS function is disabled.
So I added the line to the app Description and hit the Submit for Review button again. About seven days later, it was again reviewed. This time it was accepted, and the app was posted on the store within 24 hours!
Now you wonder if anyone will notice the app, let alone buy it. Part of my prep for submitting the app was preparing a web site and setting up a limited liability company to protect my personal finances. What I'm probably not very effective at is marketing. That's something you should consider if you want to develop your own app.
If any of you do try out the app, please let me know what you think. I'm always open to suggestions. And would also appreciate reviews on the app store.
No comments:
Post a Comment