So You Want to Launch an App, Welcome to Being a Technical Writer

Launching any app means you have to do a lot of jobs that aren't programming jobs. They aren't but if you want to be an Indie and launch your own app you need to wear many hats.

Last night I did another pass through my user documentation. Included in this was a rewrite of the NewThistle LLC Privacy Policy to include information about Paddle Mate. I also tweaked it to add further clarification for the NewThistle Privacy Policy in general.

Next, I did another pass through the Paddle Mate app landing page which performs the duties of marketing material and user manual. This included lots of screenshots, information about how to use features of the app, and how Paddle Mate works with the Microsoft Band. I am happy to have those items checked off my sign-off list for app launch.

A part of running an App Business is taking care of these Technical Writing jobs, amongst the many other jobs you have to do.

I had most of this material already drafted and moved onto this task last night after I had made progress on my final few bugs. I am at a state now that another sign-off test is planned for tomorrow so I can verify that the few fixes I made tonight did not cause a regression (a regression is the introduction of a new bug or reintroduction of an old bug) which will gate the build (stop me from shipping).

I have said final few bugs more than once, I know that. The reason being that retesting sometimes brings to light new bugs. On a limited budget (my free time) I have to do the best I can with the time I have and sometimes that means days without much progress or reverse progress when I find a serious enough bug.

I am happy that this past weekend I made good progress with Paddle Mate in many areas. Not the least of those is getting these Technical Docs written for my users.

Reusing What We've Built

Do not brood over your past mistakes and failures as this will only fill your mind with grief, regret and depression. Do not repeat them in the future. 

Swami Sivananda

To often the next big project is more exciting that the current project. We want to move on and do something new so we can learn and to keep us interested.

Sometimes I run into a wall of too much work and too little time. The desire to switch streams from the current project to something new is alluring. It is much easier to switch streams than do the hard slog through the work it takes to complete the current project.

Switching off a project that you see will take longer to complete and moving onto the more exciting new project can he a hard urge to fight. But if you want to ship code then you have to stick to the current project and own up to the time it will take to launch.

It was with this in mind that I was thinking we sometimes need to stop and look at what we have learned. What have we built? What knowledge have we built? Is there something we know now that we are not taking advantage of?

I know that for myself I am always interested in learning and solving new problems. Sometimes this desire to do something new gets in the way of leveraging my knowledge to build products that I would enjoy.

With the Apple TV, 3D Touch, a new iPad Pro, I was presented with the dilemma of should I build a new app that targets those platforms?

While debating this I thought about the work I have been putting into Paddle Mate to finish that last mile from done to shipped. Though I have cut a lot of features to get V 1.0 out the door, I still have some high standards for the V1.0 when it comes to being able to track my workout. It has to work, foreground, background, pausing, etc.

A lot of work has been put into the features around the original stroke detection algorithm to convert Paddle Mate from a neat showcase app into a shipped product. It's something I would be happy to buy and use for my kayaking workouts.

With the work I have done, I started to think, how can I leverage this in another app?

It did not take long to see how I could leverage my Paddle Mate code to create another fitness app.

So, I will be enjoying my friends Apple TV creations. I will check out friends 3D Touch on their new phones. And I  will take a look at an iPar Pro and it's Pencil if I see one in public.

But for the next few months I am reinvesting my knowledge from Paddle Mate into another app.

Finding GPS Routes for Testing

To test out Paddle Mate I have been using my own routes, some tester uploads, and a selection of
routes I have found online.

The best source online I have found that I have pulled several routes from is the site GPSies: Tracks for Vagabonds.

What I like about GPSies is that I can narrow down my routes to just "On water" meaning I can find canoe and kayaking routes.

If you need to find some routes for your GPS enabled app then start at GPSies.

NewThistle LLC Turns One Year Old

NewThistle LLC is a year old at the end of September!

I just renewed NewThistle's business license and took a look at it's first year.

Here is a breakdown of my Revenue sources. As you can see, I am making the majority of NewThistle's revenue via App Dev Contracts.

To be honest, a huge push to start the company was the first contract I received. It was that contract that pushed me over the edge to start NewThistle and put more effort into app development.

For App Sales, I can say that Selfie Band, my Microsoft Band camera remote for iPhone, is my 2nd best selling app to date. It has only been in the AppStore since August 6th but it has been having steady, if not high, sales.

For NewThistle's first year, I am pretty happy with the results. I have achieved my initial goals to start a company that is profitable and which could bootstrap it's own growth. I had to start by giving the company a loan to get setup.

I then took a big contract first thing and sink a lot of after hours time into for 6 weeks.

With the close of that first contract I had made back the money I loaned the company to purchase new equipment and various web services (website hosting, domain, email). So, 90 days after I closed my first contract NewThistle LLC became profitable.

Since then, I have been trying to run a tight ship. I have decided not to purchase the new iPhone 6s+ since I can get by with the iPhone 6+ until I have a need to get the new phone or I can wait until the iPhone 7. I am on the fence about the iPad Pro but will likely stay away from it unless I have a business need to develop for it. The Apple TV I have app ideas for so that is something I plan to purchase for development purposes.

A big goal with the company has been to have it not cost my family money (though it sure eats up a lot of my time). In the money respect, the company is doing well and has cash in the bank to continue to pay business expenses.

For the coming year, here are my goals:

• Increase the share of revenue from App Sales.
• Two apps in the works and more planned.
• Introduce another source of revenue besides App Sales and Contracting.
• Continue to be self funding and not require outside financing.

Here's to the next year of NewThistle LLC.

Paddle Mate Beta Access

I made good progress on the Paddle Mate "Just Ship It" Release this past weekend. I had to step back, look at my activity state restoration code and fix a couple key problems. With that under control the app is handling backgrounding much better now.

This Beta version also includes:

• App setting persistence so that the app remembers your last used workout settings (track location, Microsoft Band pairing options)
• The DOCK view (main landing view of app) now includes a preview of the map from your last workout and some stats from the workout.
• State Restoration.

With these changes in place, the app is ready for wider Beta Testing. If you are interested in trying out Paddle Mate before I ship it then you can sign up at: Announcing Beta Access to Paddle Mate

Paddle Mate V 1.0: Just Ship It Release

Past Workout (WAKE) view on the main DOCK view.

I have a couple irons in the fire at the moment which have me spread thin.

• I'm working on a new site which I will write more about shortly (it is still baking and is not ready for prime time yet).
• Various home projects.
• I signed up for a Half Marathon at the end of October and have been ramping up training.
• Fixed a bug in Selfie Band and shipped the update.
• I have been finishing up Paddle Mate's first release.

Paddle Mate, the Just Ship It Release, has gotten some well deserved attention the past few days.

I had a couple half baked features and did some triage on those. I decided to move them out into future releases and in the process created a RoadMap. With the RoadMap I have a defined ongoing plan with a focus for each upcoming release.

I just finished off validating that the app works with/without a Microsoft Band attached. Without the Band the experience is not as rich but I am planning to support a richer experience for non-band users over time.

Paddle Mate is now down to 2 gating bugs that I am working on today. In developer lingo, gating means that the product can not pass the release gate to customers until those bugs are fixed.

I have one tester who is out today in this rain that has been testing. Once I get a handle on one of the bugs I will be going out for another test kayak.

The other bug is in the past workout view, I have a handle on the problem and will tackle that later today.

This boat still can't launch when that is all done. My list of tasks after I fix these bugs include:

• Verify I have no more gating bugs.
• Write launch page.
• Write marketing page.
• Write Privacy Policy for app.
• Record App Preview

So, with about 1 hour to go in today's dev window I need to get back to getting this app shipped.

Selfie Band V1.1 Released

Selfie Band version 1.1 is now live in the AppStore. You can download it here: Selfie Band

This update fixes the crash that occurs when your band has no remaining space for new tiles and you try to install the Selfie Band tile.

Users with auto-update turned on should get the new version automatically but if not you can follow the link above to get the latest version.

For users impacted by the crash, you should now get an appropriate warning when you try to install onto the Band and there is no remaining space.

Incremental Change

Applying Incremental Changes to Our House

A key to success with programming is learning to experiment and make incremental changes. Testing those increments is critical to understanding if your change achieved your goals or made wider reaching impacts than expected.

From year to year, environmental changes are incremental and often barely register in our lives, but from evolutionary or geological perspectives, what is happening is explosive change.


David Suzuki

Like evolution, our code evolves slowing as we add features, we break things, we fix things, and push for the release line. Many commits are required to build the bedrock of the apps we ship and the features our users take for granted.

Sometimes in the rush to ship we miss testing some of these changes. Like evolution, these missed increments can explode when they reach our customers.

I hit my first shipping crash in one of my apps in the AppStore this past week. In this case it was with Selfie Band, my camera remote for the Microsoft Band. Selfie Band tries to install the camera remote tile (it's app view) on it's paired Microsoft Band.

It looks like one user had a very bad experience when they ran into the bug. They tried repeatedly to get past the problem but it looks like they crashed multiple times during this. I know this since I use Crashlytics crash reporting in my apps.

The bug manifested itself when the Microsoft Band had no remaining space for tiles and returned an error. I had incorrectly changed some error handling code and forgot to retest it.

So, being in Swift, my null point access crashed the app instead of silently failing as many of us Objective-C programmers are used to.

It was a silly mistake and I have fixed it and shipped the update to the AppStore. I just need to pass review and the fix will be live.

This bug reminded me to slow down and verify that incremental changes don't lead to a crash.

The competing priorities to ship and to create quality software can be hard as an indie when you have no teammates looking over your shoulder to review your code. The end user will feel the brunt of your mistakes and so will the impression you give your customers.

For me here is how I am addressing this as the sole programmer:

• Commit often to git
• Review my checkin like I would someone else's code
• Why did you do this?
• Was it tested?
• Are there loose ends?
• Should this be committed or reworked/retested?
• Using branches to switch between features that I want to revisit
• Reevaluating a change when it gets too large

Don't let your incremental changes lead to explosive releases.

UX Testing, Where Bad Designs Go To Die

Bad Design Be Gone

I made some UX decisions during design that I thought would work out. They didn't.

Back to the drawing board.

While testing the app over the past few days (walking the dog, running, driving) and I realized some things did not flow well. So I took Tuesday night to reevaluate the design and work out how to solve some of the flow problems.

Two things I did:

• I reviewed multiple fitness apps to understand how they handle some of the UX I was having problems with.
• I showed the app to more people to gather feedback about the UX.

Both of those things brought to light multiple areas that could be improved.

So, I redesigned a couple views, added some missing views, and jotted down some great feature ideas I received. The features I captured for a post V1 release.

Missing Interstitial View

In particular, a problem area I had was the Paddling/Workout workflow. Here is what I had:

1. User taps PADDLE on the main view.
2. Transition to Prepare To Launch view.
3. User chooses if they want to track location and use a paired Microsoft Band.
4. User taps Play button to start paddling workout.
5. Transition to PADDLE view, the main workout view.
6. User decides to stop workout, they tap Pause button.
7. Transition to Paddle End view.

It was steps 6-7 that had a problem. Here are what the views looked like.

Missing a Pause/Stop Confirmation View

The main problem with the above design is that I am trying to do too much in the PADDLE_End view. I am trying to cover several tasks:

• CONTINUE: You paused by mistake, did you want to go back?
• DONE: End the workout.
• Upload to Strava: Did you want to upload the workout?
• Send to the Health App: Did you want to store your workout in the iOS Health App?
• SEND SESSION TO PADDLE MATE: (Too long) Are you a tester and want to submit samples?

Here is what I have done so far to fix a major flaw.

I added an interstitial view between 6&7 which is a Pause view. This will let me move the CONTINUE from PADDLE_End back to the main view.

I think this offloads the decision to end the workout to this new PADDLE_Pause interstitial view. Now the user is not thinking about should they continue or end on the next screen, lower the cognitive work on the PADDLE_End view.

New Paddle Pause with interstitial Pause/Stop Confirmation view added before Paddle End view

At first, I left the CONTINUE in but realized I needed to remove it since the decision to CONTINUE/UNPAUSE is on the interstitial view. Now, I think I have a cleaner UX for ending the workout.

Change Design, Test, Repeat

Then, on Wednesday night I completed the integration of Microsoft Band data, CoreLocation data, and workout metrics into my Realm backend. This is cool since I had implemented the code to load the DOCK view, the main view you land on when launching the app, previously when I designed the data model.

Now I have a lot of workouts showing up on the main view as I test the PADDLE workflow.

Then I released I needed a way to delete a workout on the PADDLE_End view when a user (me) wants to delete a session they do not want to track. So, for this I added a DELETE button to the PADDLE_End view.

I do not think this adds to much to the cognitive load since a review of multiple fitness apps those that many use this concept on their end workout view. I also think it fits to have the DELETE | DONE on the top so the user can choose if they want to keep/delete this workout.

They are along the same line visually and hence they are giving you two options along the same line of vision.

Now with Pause interstitial and Delete option

Now it's time to retest and see how this new design's UX feels after repeated use.

Designing Paddle Mate

Programming is my strong suit and designing does not come naturally. Though I am inclined to art and have both drawn and painted, I still find app design is something I struggle to get right.

With that in mind, here are some things I am doing as I work to make Paddle Mate useful (and non-ugly) for users in bright sunlight, while kayaking in the evening, and when reviewing past kayaks or showing the app to a friend.

I am doing some reading first off. Here are some things I have read recently on design:

• 7 Rules for Creating Gorgeous UI (Part 1)
• 7 Rules for Creating Gorgeous UI (Part 2)
• The Easy Guide To HSL Color In CSS3 - discussing how to use Hue, Saturation, and Lightness and how to understand it.
• Color Theory For Designers: Creating your Color Palettes

Here was the UI:

Here are my new designs I plan to test for bright sunlight:

Hackathon: Writing a Microsoft Band App In One Weekend - Update 4

Update 4: Hear My Heart Beat

Can you see the 20 strokes in here? Paddle Mate found 17.

It was a dark and storming night. Taylor Swift sang her heart out in downtown Seattle while I coded my heart (beat) out writing Swift in Sammamish.

But enough of that, onto the progress report. Last night I:

• Added Heart Rate Monitoring into the app.
• I said what the heck, let's grab that calorie count from the Microsoft Band.
• Then I lost my mind and decided to add a "Reset" into the app to make collecting data easier.

Oh ya, then I hooked the stroke counter. It was about time I added the feature I started this app for.

Heart Rate

I now collect the Heart Rate samples while I update the current Heart Rate label in the app. Once the workout is complete you can now view the Heart Rate in the in-app graph using the heart rate/stroke toggle icons along the right of the graph.

Calorie Counts

Just displaying the calories burnt during the workout, as reported by the Microsoft Band.

Reset

During data collection on Saturday morning I had to force close the app to clear it. I had to do this between each data collection.

We aren't animals here. Force closing apps? What will be next? Side loading apps you got from a friend off of 10x3.5" floppy disks which are really not floppy? No, we won't.

Behold the Holy Reset of Antioch!

Yes, the reset was that good.

Wet And Wild 2: Get Me Some Samples

With only one Sprint Pace sample I decided I needed more samples. Here are the results of today's collection with the Stroke Detector I worked on yesterday.

Pace	Strokes	Detected Strokes	Accuracy
Easy	30	27	83%
Sprint	10	10	100%
Easy	25	23	92%
Sprint	20	17	85%
Easy	50	47	94%
Mixed	120	96	80%
Easy	100	84	84%

Overall I am pretty happy with the new stroke detector. With an 80%+ accuracy I think that is pretty good for a one day of crash course Linear Regression, Moving Average, Classification, and Standard Deviation coding session.

My next phase of stroke detection I think will involve some machine learning to see how more accurate I can get the algorithm. At the moment I see I need to do a couple things based on the samples:

• Classify strokes and trailing strokes by pace (Slow, Medium, Fast) and then use that classification to adjust the stroke detection algorithm.
• Better rejection of garbage samples (non-strokes).

About Class Structure

You know that joke about MVC? Massive View Controller?

That's this app at the moment.

I know, I should hang my head in shame. But screw it, I will put making this an architecture marvel to knock your socks off on my "Backlog".

To be truthful it is not all a MVC. I have the following classes:

• PaddleCounter class to handle stroke analysis.
• Ring class to handle the ring buffers for moving average calculations for the PaddleCounter.

The rest of the logic at the moment is in the ViewController but will change once I extend the app.

Notes From Wet Tests

During testing on the lake I made some notes about the app:

• As we know,trying to read an iPhone in the sun sucks. I am going to need a high contrast UI with very large components if the user has a hope in hell of seeing the strokes, heart rate, etc.
• The waterproof plastic case I have is soft and as such touching one point on the screen may cause a different location to register the tap. This means that during a workout I will need to add a dialog to prompt a user "Do you really want to stop you workout?"

Launched! Selfie Band for Microsoft Band

Well, I finally completed an app (again) for the iOS AppStore and launched it. The app is called Selfie Band, a camera app for the iPhone which allows you to use a Microsoft Band as a remote control. Check out more about the app at the NewThistle Blog: Announcing Selfie App

You can also checkout the Selfie Band HomePage.

My first app was launched in 2009. My second app (with a team of 6 Cocoaheads from the Ottawa Cocoaheads) was launched in 2010.

Then I went to work for BlackBerry for a little under 4 years where the employment agreement included a non-compete clause that meant no apps in competing AppStores. Hence, I was a Mac OS X/iOS dev at BlackBerry but could not ship my own apps.

I left BlackBerry at the end of 2013 and hence that restriction was lifted. At first, my biggest problem was what to write?

When I joined the Microsoft Band team (as a contractor) there were no restrictions on releasing my own apps. In fact I have been encouraged since I work on the Public SDK and help third party developers integrate their apps with the Microsoft Band on iOS.

Selfie Band has been several months in the making, though it might not look like that to some. In that time I took on maybe too many after-hours activities. A couple include:

• Prepping and presenting 2 talks about the Microsoft Band SDK.
• Writing 3 Band Apps "almost" ready to ship.
• Starting no less than 4 other Microsoft Band Apps.
• Helped a pre-investment startup get an early prototype setup for initial integration with their Web API.

So, as time dragged on and I had not shipped anything I knew it was time to concentrate on one app, cut features and ship it. There are many things I would love Selfie Band 1.0 to have but shipping was more important than adding features users might never want/need.

About 5 weeks ago I put the final touches on Selfie Band and prepped for AppStore submission. After a month in review including one rejection, Selfie Band came out of review last Friday and it was left to me to hit Launch.

So, last night, at NSCoder I put the final pieces in place and Launched!

It feels good to be back in the AppStore with something new that I designed and wrote myself.

If you have a Microsoft Band and an iPhone then check out Selfie Band so you can take photos from your iPhone with your Band.