Thursday, December 11, 2014

Apple Watch Ideas

Like many iOS devs, I am playing around with Apple Watch ideas. As with most things, I have no shortage of ideas. It's the implementation that is always the hard part.
Now, why can implementation be hard? I think because we try for perfection too often.

Many devs I have spoken with, and myself included, come up with lots of features that we can add. Heck, everyone does this. Name a piece of software you could not make better with a couple features you'd love.

The problem when you are the product designer, graphic artist, programmer, and every other hat needed to ship your own product, is that you need to decide what to cut and when to ship. The inability to cut is one impediment to actually shipping.

As devs we want our apps to be perfect and have lots of neat features we would want. It has to be just right with tip-top graphics. It should have iCloud support, custom UI controls, support multiple languages, have accessibility, and the list goes on. All these things might be great but does the app really need it?

At times I have been parallelized by feature bloat as I design some apps and hence they never get built and never ship. I call this app day dreaming. Boy, wouldn't it be cool?

For example, recently I started to think about some apps I could build for smart watches. Some are for laughs with my two boys, some are jokes with coworkers as we batted around ideas, and some would solve problems I have which I would rather solve with a watch than a phone.

Like any project, I decided to capture these ideas and start to estimate how long I thought they would take. As I started to add features to the list for each app it grew longer and longer and the timeline started to crush my excitement.

As I waited for the Apple WatchKit to be released for development I started to say, maybe these ideas would not even be possible. So, I just planned more and made contingencies, "If Apple gives us support for this, then I can do this idea." etc.

Then the WatchKit came out and I realized I could actually do most of my ideas. Let's start in. But then reality hit. How am I going to build this feature set out?
  • Full iOS App to support the Watch App?
  • Ads to provide a trickle of revenue if the app gets traction?
  • In-App Purchase to add additional features/themes so I can hope to get paid a bit for my work?
  • Fully featured ability to edit content on the Watch?
  • Storage of content?
  • Graphics?
This is a lot of work for one person to pull together in their "spare" time. We all know how much of that we have.

While getting down from the work load ahead I was listening to the App Business Podcast. In particular, the episode ABP115 – Michael Dowell of App Indulge. During this episode, and others recently, I realized I am complicating things too much. 

How many of these features did I really need?
Could I design the apps differently to reduce the work but keep features?

So I started to look at how I can trim one app in particular:
  • First off, drop the content editor.
    • Instead: supply templates for users to fill in their information.
  • Drop the in-app purchase for themes.
    • Instead: re-package the app for each theme and release an app per theme instead of one app that can download the themes. Less work to create downloadable content. Increased SEO with the name of the theme being in the app name and app description.
  • Move content editing into the templates as much as possible. Then move what can not be in a template into the iOS Companion App. Then leave the remaining for the Watch. Thereby simplifying the app on the Watch which makes it easier to use and less complicated to code.
Applying this strategy to several of my ideas means I will ship more apps that do less. That is fine, since my research indicates that you have very little time to get a customer to decide if they are going to buy/download your app. So I need to optimize the discovery time and effort for ROI which means simpler apps, with streamlined descriptions in the AppStore so I can hope to capture the most customers possible.

With the AppStore having so many apps it does not pay, from what I can tell, for a single person or small shop to spend a lot of time on adding features in their app when their app may never sell enough to pay for the cost of development, let alone living expenses.

So, let's see how this experiment works as I find spare cycles to write a couple apps to scratch my itch.

Thursday, October 16, 2014

Software Development is Obviously Hard

Look at Apple's recent iOS 8.0.1 release that broke cellular.
Look at (any company's I have used) Wi-Fi or Bluetooth stack and how flaky it is every other release.

The technology we use, rely on, love, and spend a lot of money on each day is a big let down when it fails. For non-techies I hear them blaming themselves. They must not be using it right.

Here's a secret though, most times when it is not working, but it worked yesterday or 5 minutes ago, it isn't you, it's the gadget. How many times have you cycled your WiFi or Bluetooth off/on to try to fix connectivity? Too many.

I feel for the people that don't know this much (you sometimes have to reset things).

It used to be a big joke, and I made it plenty of times, that you had to restart your Windows PC daily or whenever it started to act strange.

The bigger joke today is that we have to do that to the device in our pocket more often than we care to admit.

I always think, maybe it's me and the stuff I am interfacing with each day. Bluetooth headsets, in-car bluetooth, switching multiple networks, installing/uninstalling apps. My day to day usage of mobile devices is a little more extreme than the average user I figure and so I run into "edge cases" all the time.

Or maybe, we just need to spend some more time polishing our software before pushing it out the door.

Friday, October 10, 2014

DerivedData and xcodebuild

If you use Xcode you know about DerivedData. If you don't know DerivedData, you don't know Xcode.

If you are setting up xcodebuilds from the command line, say for continuous build and integration (CI), then you want to make sure you are using that command line the best way possible. Some things I keep running into as I see people's build systems are:
  • Running out of space due to a backup of old DerivedData.
  • Build performance hanging, due to a backup of old DerivedData.
  • Unexplainable build failure, solved by deleting, you guessed it, DerivedData.

If you use the command line for builds then save yourself a lot of trouble in the future. Start using the xcodebuild option -derivedDataPath.

Here are the docs on it:
-derivedDataPath PATH                     specifies the directory where build products and other derived data will go

That one option huge significance. Here are some reasons why I use it and convert build systems over to this option:
  • I can store the DerivedData in the temporary source workspace of automated builds (like CI builds, automated test runs, etc.) When the workspace is cleaned up the DerivedData goes away and net disk space should be 0 at the end of the build.
  • With no shared DerivedData between builds the build performance does not drop due to large DerivedData folders.
  • Without a shared DerivedData folder I see much lower instances of unexplainable build errors. This means less cleanup, less build host reboots, etc.

Personally, I am very interested in how remote builds with Mac OS X Server and Xcode have improve the build process for automated builds. Until I get the chance to put such a system together, for now and for legacy build systems, I will use xcodebuild -derivedData to improve build systems I have to work with.

Wednesday, October 8, 2014

Make a Swift Based iOS App Crash

I am writing an app for a contract where one of the deliverables is that the app must demonstrate various crashes.  Of these various crashes, one must be an application crash.

On top of that I am writing the app in Swift (about 80% Swift, 20% Objective-C libraries not ported to Swift).

It shouldn't be too hard to crash a Swift app hey? Well, if you follow Swift guidelines your app should be pretty stable since the language has been designed to force devs to be safer in their use of the language. That's not to say that misunderstanding the language or forced unwrapping of optionals that could be nil will make your app any less crash prone.

So let's break the rules, get unsafe in our use of Swift and crash this app.

I decided to go with this piece of code:
var crashWithMissingValueInDicitonary = Dictionary<Int,Int>()
let crashInt = crashWithMissingValueInDicitonary[1]!
This produces a crash with the following error:
fatal error: unexpectedly found nil while unwrapping an Optional value
The reason is this:

  • Line 1 is creating an empty dictionary with Int keys and Int values.
  • Line 2 is Force Unwrapping the optional dictionary value with a key of 1. Nothing has been added to our dictionary yet though so this means we will get a nil. Assigning this nil to a constant value (let) and we get a runtime exception, crashing the app.
So, there is one way to write a bug intentionally to crash your app.

Monday, September 29, 2014

The Walking Dead

Well, I finally caught up on The Walking Dead. I read a number of the comics and figured I was
good. I read the comics, what would I get from the show. Being that I watch little to no TV I had no real desire to watch the show.

Then too many people told me it was different and it was worth seeing. I finally gave in and started to binge watch it this summer while Michele and the kids were on a trip and I was stuck home painting the house and working at a new job (no vacation time for me).

My summary of the first season is. This is just a drama with Zombies thrown in. Look, people not getting along. Tension. Zombies. Tension. Not a real, hook me season but it was good enough and I was told wait for Season 3. Also, pretty similar to the comic.

Ok, Season 2, now we are talking. Things still similar to the comic. Enough divergences that I was wondering when Shane would die. Giving me a big hook. I liked how they started to amp up the tension and the season finale was excellent. I was so glad I did not have to wait long to start Season 3.

30 seconds later, hit Season 3, Episode 1 on Netflix and we were in. Season 3 did not disappoint.

It was great. The addition to the story with the competing Woodbury was excellent. I liked the twists it added.

Now one aside. I do like to think that humanity would not turn to such shit as in the show.

What I found interesting throughout the seasons is that the characters meant to be most unlike me, Daryl and his Brother (but more Daryl) are the ones I truly connect with. They aren't stupid. While all the other "city-folks" are running around crying about the end of the world, these guys are scavenging and killing Zombies without a blink of an eye. The world has changed and you better drop your I'm too good for this quick or die is what they show. I like to think people would react this way, but maybe that is just me.

I guess by this admission, there is more Redneck in me than I figure. In reality, it's just the writers trope that people are stupid and would take a long time to adjust to a fight for survival. The counter-point for most of the characters are two guys who seem simple but in fact have their shit together. So, ya it's TV and the stupidity makes for tension and "good TV" I guess.

I finished Season 3 a week or so ago and I am getting the shakes from missing "my show." But last night, Season 4 was unleashed on Netflix in prep for the return of The Walking Dead, Season 5.

So, now I am binging again, waiting for the next season. Who will survive?

Thursday, September 25, 2014

Describe yourself in an eye-catching 150 chars or less

I just applied to a full time position that wanted me to describe what makes me unique in 150 characters or less.

Here's my shot at that:
I've flown a plane with an electrical failure at night, watched life float pass pinned to the bottom of a river, and I still got the job done.
I've written about the night flight electrical failure in an earlier post. The river story is for another day ;-)


Wednesday, September 24, 2014

Here's a Surprise, I am Behind The Tech Curve

There used to be a picture of me in the dictionary under early adopter. I stood in line for game console launches, game launches, device launches, etc. I had Model 1 of lots of products.

My wife, being a Marketer, was amazed when she discovered this. She was both surprised that Early Adopters were real and she was married to one. I never told her I played D&D until after we were married. ;-)

So, here I am, with an 8 yr old in grade 3 and we have been informed that the school is now allowing (and encouraging) BYOD (Bring Your Own Device) for grade 3 at our school. The personal computers can be used for computer time and for in class research if the teacher allows it. Our teacher is on board and so my wife and I are now left releasing we are one of the late adopters with electronics and our kids.

Part of this is our desire to reduce screen time for our kids. Part is our desire for them to be drawn to outdoor pursuits and finding fun without the need for a terminal.

But now I must admit that culture is moving on and technology is now a requirement for an 8 year old in class.

Frankly I am not surprised and also amazed at the same time that I will be sending my son to school tomorrow with a Surface RT so he can research in class. It's cool and younger me loves the idea. 

The old man in me says, "When we were kids we hauled a Dictionary and a Thesaurus in our backpacks. And no a Thesaurus is not a Dinosaur! Damn young whipper-snappers."

Oh well, technology marches on.