Is Having a Device Library an Advantage?

We think so!

When developing in the mobile space, we are always chasing that next device being released. For iOS we have the huge iPad Pro all the way down to the, still viable, iPhone 4s (or older if the client requires it). We are also trying to stay on top of the regular OS updates. There are other factors also in play across so many devices -- processor speed, firmware iterations, retina/non-retina, etc.

Apple provides software simulators in Xcode but as the name denotes, they attempt a close approximation of how your App will behave on a target device. The simulator is not the same as having a real device for testing.

Our library of devices has surpassed 35 devices with the introduction of the iPad Pro. When I type that number, I'm realizing the level of investment we have in all this hardware. Has it been worth it? We believe so and here are some of the reasons why:

  • The simulator can't emulate hardware specific features (e.g. bluetooth, camera, microphone, etc.). 
  • The simulator can't give you a good read on performance because the simulator can be as fast as the Mac you are running it on. Or in some cases a very slow. The iPhone 5 is still a very viable device, but is much slower than the newer 6's. There have been code specific considerations implemented to accommodate slower devices. The simulator would not show us these limitations. So, our older iPhone 5's are used during development.
  • Memory usage is not necessarily the same. The simulator does not enforce the same memory limitations as the device. Low memory testing needs to be on a device.
  • OS versions are limited on the simulator. Apple pushes for current OS versions. We understand that QA is easier when you have fewer OS versions to test against. We have found that users don't always keep up with maintenance releases and there are times when significants changes (the Bluetooth stack of example) happen. We want to know that our Apps are running well in OS versions a few versions back. Now that I've typed that, if there are significant enhancements to newer OS versions (the networking aspecting of iOS 8 over iOS 7 was substantial) we'll strongly recommend that a client require a newer version of the OS. 

Also, if a client has a limited budget, we may suggest that the App be released on the current OS version. This is a substantial savings in QA time. That said, we'll do a cursory test pass on an older OS version just to make sure nothing too heinous is going on.

  • Seems kinda of silly, but finger testing vs. mouse testing is important. The simulator recognizes the 1-pixel point of your mouse cursor. The last time I checked, my fingers are a little bigger than that. Gestures are also cumbersome in the simulator. Sometimes a gesture isn't possible in the simulator - 3-finger tap.

There is no substitute for using your App in a real-world environment. Just this week we took several devices into a basement to test spotty cell, gps and wi-fi services. We want to make sure our Apps fail gracefully in these sorts of situations.

Our clients may have their own personal iOS devices, but that's it. As a full service development house our clients have come to expect that we can cover a wide spectrum of device environments so the end product will be something that both we and our clients will be proud of.

We are confident that we can reproduce all the mainstream device environments for our projects. We also pride ourselves in covering some of the edge cases that clients invariably encounter once an App is "out in the wild."

July 13 Follow-up: Looks like Facebook finds value in a device library also! https://techcrunch.com/2016/07/13/facebook-lifts-the-veil-on-its-mobile-device-lab/

Take a Working Walk

We've all seen the articles telling us how important moving is for our overall health. We are desk or sofa workers. We're glued to our monitors trying to get our work done. Eric and I are in the same room and it is easy to stay seated and have our work discussions, right there, throughout the day.

We make a point of getting out for a lengthy walk most days. We find that chatting about features, timelines, app ideas, etc. much easier and more in-depth when we are away from our desks. Slack, Chat, email, etc. aren't chirping at us and the topics of conversation become a priority for that 45 minutes to an hour. It's also provides a great change of perspective. 

Working for ourselves doesn't give us a lot of opportunity to "set it aside" and we have accepted that fact. So, we change our view at least once during a work day. We may still be working, but walking gives our brains and bodies a bit of a break from the bits flowing at us through those series of tubes.

We've been rewarded with new and different ideas to old problems. We can check in with each other on what challenges we are facing in our respective roles. Most of the time the other's point-of-view is welcome. For example: I may not have intimate knowledge of Eric's coding, but I can ask layman questions that may get him thinking differently. More simply.

The challenge of the working walk is making sure you remember the outcomes and get them written down when you get back to the desk. Settling in after a walk usually involves some, "What did we decide about ...?" 

One other benefit of this routine is we tend to end up near a bar around happy hour. Cheers!

How to build a MVP App in less than 2 weeks

Start with gallons and coffee. Add no sleep. No-no-no to socializing. And definitely, no whining.

All kidding aside, you can build a solid 1.0 product, quickly, if you have a strong MVP (Minimum Value Proposition/Product) defined. It also helps to have a great client and great existing graphical assets.

We connected with DigitalPour in late March. They were preparing for the Craft Brewers Conference in Philadelphia and wanted to know if there was any chance of getting an iOS App written and available by the May 1st conference start. 

We asked what they wanted and they immediately said, "Not a ton, we just want a presence in the mobile space for the conference." We took a look at their menu API and realized it was clean and could be very consumable by a mobile App.

We said, "YES! Let's try and make it happen." We wrote a very quick little specification outlining what would be doable and still give the App enough time to get through Apple's Review cycle.

They didn't have a specific design, but their Web-based digital menu dashboard is packed with wonderful assets: good color schemes, great layout, font choices, barware graphics, etc. We wanted to match the actual digital menu as closely as possible. People are familiar with its look and feel. 

We dove in and worked through communicating with the API (Application Programming Interface) first. It's key to identify the most important and/or most difficult tasks, and tackle those first. If you burn too much time there, then the lesser important tasks naturally will fall off the initial release list.

We kind of feel like we were cheating, a little bit, on this particular project. The API was stable and debugged. And their technical resources were very quick to answer questions and make the couple of modifications we needed.

Some of the benefits of defining and executing a limited MVP are:

Establishing a bite-sized budget to test the waters. If it misses the mark, you aren't out a huge amount.

Getting to market quickly to start the response cycle. If the App is received well, you can start listening to customer needs more quickly and start responding to those needs almost immediately.

Having a smaller initial App helps both you (Client) and us establish trust and gauge how the relationship may (or may not) evolve. We want to show our competence as quickly as possible so an ongoing relationship becomes an easy choice.

Stomaching an MVP release can be challenging. You clearly know that you are releasing a product that will be screaming for added features. The good news is that you have features you can still add on a reasonable schedule and also add user feedback to the process.

We want to congratulate DigitalPour on a great team effort that resulted in a great 1.0 App with nothing but upside potential. ONWARD!

Check out the DigitalPour App @ http://bit.ly/digitalpour

Developing with a Swizzle Stick

Swizzle Stick: A stick used for stirring still drinks or taking the fizz out of sparkling ones. Or one of those really small straws for stirring cocktails or coffee.

The rack of "helpful" application tips at the UPS Store in Burley, Idaho

The rack of "helpful" application tips at the UPS Store in Burley, Idaho

As mentioned in our earlier post, most of our work can be done anywhere that has an internet connection. That said, a fairly robust connection (3+Mb down / 1.5Mb minimum up) is appreciated.

When we arrived in Burley, Idaho, for our first stay on our road adventure, we discovered that this poor town is stuck in the 1990's.

We did a speed test and our apartment's internet service was a dismal .8Mb down and .25Mb up. YIKES! Our host was willing to help us improve this, but it took a few days to explain and get what we needed.

During that time we continued working on our client's project while sniping and making jokes about dial-up and DSL. Little did we know that this connection was, in fact, a DSL connection.

Cindy was starting to test our client's App - CardFool - which had many API calls. She found some pretty interesting bugs based on network timeouts and general connectivity slowness issues -- screen redraw issues; content failing to fully load, App launch and coming from the background oddities, etc. 

We laughed and grumbled, but we were grateful for having a swizzle stick connection that we wouldn't have normally had in Portland. It's hard to replicate this environment without tools and/or knowledge of this sort of thing.

Here's to making the most of a bad situation!

Going Truly Mobile

After spending the bulk of our careers in the Portland area and own a home for 18+ years, Eric and I decided to make a change.  We were living in a home that was far too big for our empty nester life style. The housing market in the PNW was heating up. Let's sell!

We spent 18 months downsizing our life by getting rid of 2/3's of what we own. It's amazing what you accumulate throughout your life. We took ample advantage of FreeCycle and Craig's List. We also spent a lot that time getting our house in shape to sell.

We put the house on the market, in July and WHAM... it sold in less than a week. Now what?

Both of us like to travel. What if we explore the U.S.? Sound good, but we can't retire yet. Well, we really only need an internet connection and our computers to do our work. Okay, we can make that work. 

We started researching AirBnB and discovered we could rent fully furnished homes (or apts.) for one month at a time. This would give us an opportunity to get to know a community; have enough attention stability for our clients and their project needs; not having to pack and move too often was important too. Great! This is sounding pretty good.

We committed to a 6-month period, minimum and no more than 2 years maximum. Neither of us got cold feet. Done...we're off.

While figuring out what to bring with us, we knew it was important for Eric to have a comfortable and productive working environment. Bringing both his 27" workspaces (iMac+Monitor) will pack okay. We had no idea what type of table/desk space we would find in each of our locations. Hmmm... what to do? How about standing/sitting desk? Okay... but how the heck will that fit in the car? After some research we found a Jarvis desk that would break down and lay flat in the back of our Subaru Outback. The need for a comfortable chair became less important with this desk solution. With the addition of a pogo stick seat, we had Eric's workspace dialed. Done.

We had one active client wanting a new App written. After talking about our plans, they were onboard as long as they didn't feel neglected by our distractions. We definitely can do that.

We got our Subie packed, floor to ceiling, plus a roof rack. Off we go... first stop Idaho.