Jonathan Wiley, Author at LunarLincoln

Jul

When does it make sense to hire an app developer?

People talk a lot about how to hire tech and where to find good talent but not a lot of people talk about whether or not you really need to hire.

You have a fledgling company – it is based in tech. Time to hire tech people right?

200

Actually, it depends.

Let’s let Wiley run the numbers for you:

Hiring a mobile developer costs at the very least $100k a year (salary + tax/insurance/perks/bonuses)
Hiring a development shop with a $100k budget would give you around 21 weeks of development
BUT. Most mobile apps take us between 4 to 10 weeks to build

What are you doing with that extra time (money)? What do you get for that cost?

Advantages of Hiring

With an in-house developer you get one set of eyes who knows the structure of the project closely. They’re with you for the long-haul (hopefully) and they sit right next to you (assuming they’re not remote). They have a set of best practices that will hopefully set you on a course for engineering greatness.

Advantages of Partnering

With a development shop you get multiple people – and as a result the ability to speed up your project timeline if needed. You get different areas of expertise. Need someone who does Android development? iOS development? Bluetooth Low Energy? A development shop has a team with a breadth of experience and can pull a person that matches what you need at the moment. You benefit from their deep reservoir of experience and industry knowledge. LunarLincoln even offers guarantees on certain contracts, so if a bug is found, it gets fixed at no extra charge (good luck getting your employees to work extra long hours to fix their mistakes).

On CTO Full Stack Ninja Unicorns

What if I just hire a bad-ass CTO who can do our development AND manage things? Experience, vision, and skill right? With this approach you’d be committing a percentage of their time to development, but the real question here will be efficiency. Has your CTO shipped hundreds of apps and updates to the App Stores, and do they know the tricks to get that right? Will they make the right decisions the first time or will they have to rewrite things several times to get it correct? Basically, how much time will your CTO have to spend learning to get to the level of efficiency that of a seasoned developer whose sole responsibility is building apps? Plus, doesn’t your CTO have better things to do with their time? Why not focus them on the things that they’re really good at?

There are always downsides to both

What if you make the wrong hire? What if your developer only knows one language (iOS) and needs time to get the other platform down (Android)? What if your developer is sick, on vacation, quits during crunch time?

What if your dev shop doesn’t communicate well? What if they secretly put some noob on my project and the tech debt is staggering? What if they blew the budget and we’re only halfway done?

It happens. Hiring is scary. Spending money is scary. Partnering is scary. But you can do it.

tiny-potato

What does all this back and forth really mean? You’ve given me pros and cons but no assessment?

Can you just give me one of those sweet decision flow charts already?

Ok, ok, ok.

Hire an in-house dev if:

You know exactly what you need technically
You have the budget to hire the best (and know HOW to hire the best)
You’re going to need their specific skills long-term (beyond the initial push/development)

Hire an agency if:

You don’t know how to hire the best yet (we did it for you)
You have a limited budget runway
You need to get to market fast
Your project can benefit from a deep pool of technical skill
You may only need development for the initial push and then time to regroup

Hire a CTO/Dev if:

Don’t do this. Unless YOU are the CTO dev and then be prepared to be stretched really, really, thin.
Get a consultant, take someone out to coffee, you don’t need this until its time to growgrowgrow.

Jan

Squashing the Bugs and App Maintenance

No matter how much you test an app prior to launching it, IT WILL HAVE BUGS. Sneaky, weird, strange things that only appear once thousands of eyes and fingers start exploring what you have built.

With the shortened build window for CaseCollage, we had to move extremely fast. We rode the line of what is necessary to produce a functional, pleasing app, with the “just ship it” mentality. We got our MVP into the hands of as many people as possible but with a 2 week development window we only had a few days to gather feedback and iterate. Let’s hope we know what we’re doing 🙂

Once your app is in the wild, there are 2 kinds of bugs you want to look for: bugs in the code and bugs in the UX. Bugs in the code usually manifest themselves as crashes and we were pleased not to have too many of those (less than 2% of sessions resulted in a crash). Crashes are relatively easy to handle as long as you can get a stack trace. We used Flurry analytics to gather crash reports automatically and tackled the biggest offenders in each iteration until we got the crashes down to under 1%.

UX bugs on the other hand are annoying, frustrating, and eat away at a user’s app experience. They’re also hard to track down without very, very detailed explanations. “It just doesn’t work right” is not what you want to hear from a disgruntled user. What did you do? In what order? On what device? Odds are they did something you’ve never even remotely thought to try (otherwise you would have seen the issue and fixed it, right?). The main UX bug for our users happened when they exited the app to add photos to their camera roll, only to return and find they didn’t show up in the app. After many confusing emails referencing the problem we finally grokked the issue, fixed it, and got an update to our users.

My favorite part of app updates these days is the relative speed at which updates get to your users (at least after you get through app review). While its not the 100% day one adoption you get on some other platforms, the automatic app update feature introduced in iOS 7 seems to have really helped uptake. Here’s a graph of our users by version over time. Not too bad:

Fixing bugs is never the most glamorous part of app development but its extremely important if you want to keep your users happy. Happy hunting!

If you’re late to this rodeo, you may not know, we built an app and wanted to share some of the details. You can find related articles below:
Part 1: The Ah-Ha Moment And What Comes After – The idea for the CaseCollage app

Part 2: Building an App in 2 Weeks – App development process, Wiley’s analytical take

Part 3: Roller Coaster App Store Review – App store submission hurdles

Part 4: Becoming “Internet-Famous”– Prepping for launch and app marketing 101

Part 5: Squashing the Bugs and App Maintenance – When things invariably go wrong

Dec

Roller Coaster App Store Review

In my last post I covered how CaseCollage evolved from an idea to a shipped app in just 2 weeks. It took everything we had and a little more (thanks friends) but we got the job done. We started the app the day after the 5c was announced. My fingers ached (maybe an exaggeration) and my eyelids were heavy, but I felt amazing knowing we executed on something so quickly. Cloud 9 here we come!

The high quickly faded as we waited for the first version of CaseCollage to be approved by Apple. For those who haven’t experienced the awesomeness that is the App Store review process, let me tell you what I’ve learned after publishing more than a handful of apps: just about nothing. I’m not alone here. The App Store approval process is basically a black box. Apps go in, some apps get published and some apps get rejected. There are rules but they seem intentionally vague and they are inconsistently enforced. There are some moments of human interaction but they are few and far between. Most of the time you’re just looking at the beautifully designed iTunes Connect portal showing a “waiting for review” status and hoping something is moving your app closer to publication.

hd_computer_guy_meme_by_zapgod16-d4t2jh3_-_Copy

Hello? Is anyone home?

Most of the time App Store approval doesn’t worry me. It may take a while, but eventually you get through as long as you aren’t skirting the line. This time we worried that Apple wouldn’t allow an app that sort of poked fun at them. We could be rejected for a million vague reasons and be stuck in App Store purgatory forever, our hard work nothing but a battle scar. We had seen that the average review time when we submitted was around 7 days thanks to crowd-sourced data. On day 7 our app went into review as expected. I got a push notification and alerted the troops: the time had come!

A half hour later I got another push notification. The app had been rejected:

It seems the tester could not complete an IAP with our app. I had tested that feature over and over before submitting but for some reason it seemed broken (the IAP system being another Apple black box). The App Store seemed to have had some server issues during our review, so I submitted an appeal, hoping the issue was on their end. We were rejected again, this time for using “5c” in our branding. We talked about being careful with the branding from the beginning of the project but somehow in the chaos we had changed the name to “CaseCollage5c”. We had waited a week for these verdicts (half of our development time) and were now being sent to the back of the line.

We knew we had to submit an update ASAP so we rushed to put out the fire. We changed our handles on social media accounts, updated our website, and removed most of the references to 5c in our app and App Store listing. Rebranded in just 3 hours, we resubmitted the binary and went straight back to waiting. Estimates indicated we had another week to wait in review. What a roller coaster. And even if all went well this time, we’d ship 4 weeks after the launch of the 5c and may have missed our marketing window. Needless to say, I was a little disappointed.

A week later the app went into review for the 3rd time. This time we were approved! Two weeks after we finished coding the app it was finally available to the public. I can’t explain how relieved I was. It would seem the hard work was over, but we were just getting started. Now we had to figure out how to tell the world about CaseCollage.

Dec

Building an App in 2 Weeks

Me: So you have an app idea you need built? Excellent. What’s your timeline?
Client: ASAP. 1 week if you can, 2 weeks max.
Me: Okay, that’s a tight deadline. Do you have a complete design?
Client: No. We’re still working on the wireframes and may need to make adjustments as we go along. That won’t be an issue will it?
Me: *facepalm*

Normally this would be a line of conversation that shoots up red flags all over the place. App development requires a fine balance of time, quality, and scope. When you restrict the timeline and expect high quality without knowing the full scope, things can quickly get out of control. If this had been a client, I would have politely told them how stark raving mad they were and figured out a way to either extend the timeline or define and pare down the scope (knowing that most, including me, are not willing to sacrifice quality). But this wasn’t a client who asked me to do this; I had come up with an app idea with my designer, partner, and trusted advisor Jennifer, and we wanted to make this happen. So, challenge accepted! Okay, so how do we build a quality app that does what we want in 2 weeks?

Luckily we had a clear vision for what the app should do. The app was to become CaseCollage, and it would allow a user to arrange their photos into a printable collage that fit between an iPhone 5c and the new iPhone 5c case, personalizing the phone and covering up the misaligned regulation text in one fell swoop. I cannot stress enough how important it was to have a clear idea of what we wanted before we started. From firming up the wireframes and design to deciding which features to include and which to cut, we always came back and asked if it helped us reach our original goal for the app.

We were working on an extremely tight deadline, so the less development I had to do the better. I started by finding open source libraries to help us form a foundation for the app (remember, “don’t reinvent the wheel”). Grabkit fulfilled our goal of having photos in the app while giving us the added benefit of social integration with Facebook, Flickr, Instagram, and Picasa. OBDragDrop was instrumental in coding our collage editor. We even used libraries to customize progress indicators and sharing options. With the foundation in place, I set out coding the app. I worked long hours, spending every waking moment strapped to my MacBook typing like a madman. Jennifer worked just as hard rounding out the design, preparing assets, and offering constructive criticisms (some of which I was not in the mood to hear). With a prototype in hand we sent out the app to beta testers and took notes over their shoulders as they tried to use the app for the first time, biting our tongues as they fumbled their way through our hastily designed UI. With feedback in hand we quickly tweaked the app, washed, rinsed, repeated. After several iterations, a solid 2 weeks of nonstop coding and designing, and an all-nighter, we submitted our app for review. I demoed the app at Nashville CocoaHeads the next evening, got a great response, and left with an amazing elated feeling in my bones. The seemingly impossible had been accomplished! Now all we could do was wait and hope that Apple approved of our creation.

Sep

I’d Pick the “Grey” iPhone 5C Despite This

I’m super excited about the new iPhone 5C, but some of the new colors are just too much for me. Don’t get me wrong, the bright blue, yellow, green, and red 5C’s look great, but the grey (officially “white”) one matches my style a bit more. Someone over at Gizmodo penned a wonderful article this morning titled “What Your iPhone 5C Color Says About You” (cached version linked, original pulled?). What was said about my pick?

Grey: You are a hipster. The grey will go well with your Moleskin and won’t clash with ANY of your rolled-up skinny jeans. You’ve been using iOS 7 since the moment it was in beta, since you’re totes a developer. You’ll refer to the color of your iPhone as ‘slate’.

Fairly spot on, except I’m not a hipster, am I? Also, I’m making it official LunarLincoln policy that we use the term ‘space grey‘ when referring to the color instead of ‘slate’.

Sep

Customizing and Integrating WordPress Blogs

When we started designing LunarLincoln’s website we knew that we wanted to include a blog. I set out to find a blogging platform that would suit our needs; when I saw our hosting provider offered one-click WordPress installs, I was sold. I setup a subdomain to host the blog and had it up and running in no time. I wanted to fully integrate the blog into the website, so I did a quick Google search and found that I could pull content from WordPress using “The Loop“. Awesome, now I had a backend to handle managing the blog (it wasn’t properly themed, but we would be the only ones seeing it) and a beautifully themed front end for our visitors. I felt pretty good about this. I had successfully integrated WordPress into my website! Or had I? As we added blog posts, I kept having to add CSS rules to my for each new content type. Submitted a post with an image? Just a sec, let me put reasonable padding around that. Need to see more than 5 blog posts at a time on our website? Let me write a custom pager. Luckily the inherent laziness that has fueled so much of my engineering career kicked in and I decided there had to be a better way. I did another Google Search, digging a little deeper this time. It was amazing what I found in 15 minutes.

On most platforms, there’s the “right way” to do things and then there’s the “wrong way”. And I had inadvertently chosen the wrong way. An article from PressCoders set me straight (see Section 2: Rookie Mistakes). Turns out I didn’t have to hack WordPress to bend it to my whims, all I had to do was follow WordPress’s documentation to theme our blog correctly. Creating a custom theme in WordPress is fairly straightforward. First, find a theme that you like. Then create a child theme and override what you want to change. In our case a custom header and footer file combined with a bit of CSS did the trick. Once the theme was coded I rescued our stranded WordPress instance and moved it into a folder at our main domain. The finished product is what’s hosting this very blog post.

I’ve used this technique to help create a few other blogs as well. My good friend Chris Paz needed a video blog for his upcoming travel adventures. He uses certain design elements in his videos and wanted a blog theme to match. With his artwork I was able to set up a themed instance for him in under a day. Even Jennifer is getting into custom WordPress instances, employing no less than 2 on her newly redesigned portfolio page. What is perhaps most impressive about WordPress as a platform is that we’re all hosting different types of content. This blog is mainly for text, while Chris’s focuses on video and Jennifer’s includes works from her portfolio. It all looks great and is easy to manage, which lets us focus on creating content.

WordPress and I didn’t get along well at first and this project was a friendly reminder that I should research “the right way” to do things when I start working on a new platform. But all in I have to say I’m mighty impressed with WordPress at the moment. It feels good to ship, and I’ve gotten to help ship 3 of these blogs in the past month. Now I just need to write more blog posts…

Jul

Cocoa Controls is my one stop shop for open-sourced iOS and Mac UI components

“Don’t reinvent the wheel”. That’s probably one of the most important rules I follow as a developer. I save time by leveraging the hard work of other generous developers and using their open-sourced code in my apps. Simple Google searches will turn up code that can help your app do everything from simplifying network operations to leveraging GPUs for enhanced image processing.

Cocoa Controls is like a Google search on crack for custom iOS and Mac UI components. At the time of this writing there are 1,369 components listed on their site. They make it easy to search for components that are licensed appropriately and provide screenshots of the controls so you can see what they look like without having to download and run the code. In working on LunchTimer, I found I needed a UISlider with 2 handles to input the lunch window. So I browsed over to Cocoa Controls, did a quick search, and before long I had NMRangeSlider up and running. Here’s what it looked like after I customized it:

Perhaps my favorite part of Cocoa Controls is their Apps section, which lists apps using controls from Cocoa Controls. It feels good when you’re in the company of Evernote, Facebook, and Vine, just to name a few.

Power users looking to manage their favorite Cocoa Controls components may also want to check out CocoaPods. CocoaPods is a dependency management tool for iOS and Mac that makes it dead easy to include custom controls in your app. Cocoa Controls conveniently includes the pod declaration for each supported component, making the process of using custom controls in your app even easier.